Killing off Floating Point PAIR!

Development Datatypes
1

Rebol2 did not have floating point pairs:

rebol2>> 10.20x3.04
** Syntax Error: Invalid tuple -- 10.20x3.04

Red is very focused on graphics and making PAIR! play a central role. Despite that, it also does not have floating point pairs:

red>> 10.20x3.04
*** Syntax Error: (line 1) invalid pair at 10.20x3.04

A particularly irksome aspect of the R3-Alpha implementation of PAIR! was that it used 32-bit floating point numbers in its math, while 64-bit double precision integers were behind DECIMAL!. This meant you had two different precisions of math being implemented. And you would lose information picking the decimal numbers out of pairs and putting them back in. :frowning:

That was also true of the integer form of PAIR! too. You couldn't store an arbitrary 64-bit INTEGER! into a PAIR!, because it only had room for 2 32-bit integers in the cell. :frowning:

I fixed these issues by making a fully generic optimized mechanic that could store any two cells together. This wound up being fairly relevant in other ways that have nothing to do with PAIR!.

In any case, in the ever present drive to simplify anything that is not mission critical, I think decimal point pairs will probably get the axe. They raise questions I simply do not feel are worth answering.

If not even Red can bring themselves to care, why on earth should I?

2 Likes
2

It seems Red faced a need to represent floating point coordinates. But they believed supporting this in PAIR! would make it unreadable, e.g. 2343.122x54239.44. To address this, they added a distinct type called POINT!:

Red Programming Language: Subpixel GUI

Their choice for representing points uses commas inside of parentheses, and can extend to any number of coordinates:

(2343.122, 54239.44)
(2343.122, 54239.44, 6309.332)
(2343.122, 54239.44, 6309.332, 442.3321)
(2.33487e9, 54239.44)
(2.33487e9, 54239.44, 9.83242e17)
(2.33487e9, 54239.44, 9.83242e17, 5223.112)
(1.#inf, 1.#inf, 1.#inf)

They observe this means they no longer support commas as decimal separators:

"Such literal forms requires the comma character to be a delimiter, so that it cannot be used anymore as a decimal separator. That was, unfortunately, a necessary decision in order to unlock such literal forms. The gains should be bigger than the loss."

Despite Ren-C's very different usage of COMMA!, I actually never killed off commas as decimal separators...so if you don't put a space after a comma, you get very different behavior:

>> length of [1, 2]
== 3

>> second [1, 2]
== ,

>> length of [1,2]
== 1

>> first [1,2]
== 1.2

Technically speaking, they wouldn't have to drop it either... so long as they were willing to eliminate the idea that 1, was an alternative representation of 1.0. Ren-C drops this general equivalence not just for commas but for periods as well--and in fact 1. is a TUPLE! (whose second element is BLANK!) while 1.0 is a DECIMAL!

(But I'd certainly shed no tears if commas as decimal representations were thrown out.)

I'm Confident Ren-C's COMMA! is the Better Design

In source dialects, you can still have slots where a GROUP! containing numbers separated by commas denotes a coordinate. But you'd have to go through some step to get a runtime object that had methods. Some pseudocode for that reality:

>> data: [(1.2, 3.4) (5.6, 7.8)]

>> data.1 + data.2
** Error: GROUP! does not support ADD operation

>> p1: make point! first data
== #[point! 1.2 3.4]  ; or some methodized rendering

>> p2: make point! second data
== #[point! 5.6 7.8]

>> p3: p1 + p2
== #[point! 6.8 11.2]

>> to group! p3  ; imagine TO as being methodized as well
== (6.8, 11.2)

There's so much more freedom in how you can use COMMA! as a generic part in dialects. And the consistency that if you see (...) you know you have a GROUP! is much more comforting.

But back to the original post topic: Red still doesn't have floating point PAIR!, so I feel no qualms about having gotten rid of it.

1 Like