Comments on: Pairs as Floating Point?

Graphical points and sizes use a datatype called PAIR! which holds an X/Y pair of integers. However, our graphics system supports sub-pixels, and we need to ask if it makes sense to allow PAIR to be based on floating point values?

Of course, such a change creates a few deeper issues than just graphics point or size specification. For example, math operations no-longer auto-truncate to integer values. Today:

>> 5x5 / 2
== 2x2

but, that would become:

>> 5x5 / 2
== 2.5x2.5

In many cases, that's not a problem and may in fact be desirable, but in cases where real pixels are required, ambiguity arises. For example, what happens here:

>> make image! 5x5 / 2

Do fractional sizes round up or down?

And, the example above is a simplification. Floating point is a non-precise mathematical system -- that is, numbers are approximate and may be slightly larger or smaller than a desired value. This impacts operations like comparisons between values, including the meaning of "equal to zero".

Of course, most of these issues can be solved with the various "strictness" comparison operators. In addition, the use of ROUND will become important for many algorithms.

Finally, none of this is done deal yet. Over the next few days, we will build an experimental version of R3 that contains the basic change of pair! to floating point. We can then weigh the advantages of the change with the disruption it causes to our code.

10 Comments

Comments:

Maxim Olivier-Adlhoch 15-Jul-2010 15:41:55	finally! ;-) when integers are required as pair values, you should just floor() the value, as is done right now. as a heavy AGG user, I can't count the number of times I would have needed a floating pair. for example, to allow edges of width 2 to align perfectly with pixels, in order to remove fuzzyness on their edges.
Gregg Irwin 15-Jul-2010 17:22:40	How much thought has been given to coordinate values for more than two dimensions? It it worth considering for the core, or should it be pushed back to the community? Max, Cyphre, and other graphically oriented people will have better input about where we get the most value (matrix support, vectors, dialects, etc.)
Carl Sassenrath 15-Jul-2010 18:14:23	Might be easy to add a /z float coord, but beyond that, not easy. But, a small thing... if we do it's no longer really a pair! (it's more like a point or direction/size).
Endo 16-Jul-2010 10:26:56	Don't we need to specify the numbers as float by putting .0 as in >> 5000000 * 5000000 == Overflow error >> 5000000 * 5000000.0 == 25000000000000.0 >> 5x5 / 2 == 2x2 >> 5x5 / 2.0 == 2.5x2.5
Maxim Olivier-Adlhoch 16-Jul-2010 13:15:59	I think supporting more than two dimensions should be done using vector!. the reason is simple, most 3d math use 3x1 or 3x3 matrixes to represent data for vertices, transforms and such. Often, these are stored either as structs of doubles or arrays sized to multiples of length 3 or 9 It would be much more efficient to interoperate with external libs if the rebol notation for such values was usable directly within graphic libs. Having to convert to/from extended pairs or triplets all the time adds useless processing in order to marshall the data. this is even worse if we represent large datasets of vertices or surface normals. AFAICT, the vector payload could be used directly as a C double array or type cast to a struct which matches sizeof and struct alignment.
Gregg Irwin 16-Jul-2010 19:06:28	My initial thought wasn't to extend pair!, though that would nicely condense some logic. I thought about vector! and an associated dialect as well. Pair syntax is very friendly, but there are times where an object is needed (e.g. to add a Mass value to a particle). The question is how to make it easy for humans to deal with position, acceleration, and velocity but also make it fast under the hood. I'm not thinking of game engines as much as UIs. 3D audio, or multichannel is also something to think about.
Norm 16-Jul-2010 22:59:33	Linguistically, the name 'pair' is evocative of discrete data. _Two_ cents is discrete. The name space should keep its appeal to common sense. For graphics you need a name that could be extended to n ordrer (dimensions) floating points. The math domains being different, it invites you to strap the graphic system to a proper data type for that job. And its name should be more speaking than 'pair'. And a different name does gives the lattitude to devise a neat system of f.point matix math, proper to graphics. 'Surface' is the f.point equivalent to the discrete 'pair', and more evocative of what it is.
David Cope 27-Jul-2010 14:41:52	Floating pairs would be very useful for 2D geographic data. e.g. LatxLong, EastxWest.
Xavier 19-Aug-2010 7:47:07	The fact is that the notion of pair can represent different things : a pixel is by its nature different than a geographic data. The choice of rounding it or not depends of its use. It might be interesting to have a pair! and a floatingpair! with strict rules to deal with rounding when casting one to another one. If the objective is to avoid to have another datatype, it will be necessary to fix the problem of pixel with an arbitrary decision...
John Niclasen 24-Sep-2010 4:28:10	Yeah, we're talking a new datatype here, would be my guess. Like 2 is a different datatype than 2.0, so is 2x2 a different datatype than 2.5x2.5. make image! pair! would then require a pair! as the argument, not a floatingpair! (or decimalpair!), and that problem would be solved.

Post a Comment:

You can post a comment here. Keep it on-topic.