qtxie on master
FEAT: better handling for DPI c… (compare)
dockimbel on interp-events
FEAT: more accurate input block… (compare)
draw
used with scale
. Think of the points expressed in red/REP#34. Think of the red/red#3336 problem (computing the text size).
@pekr Here is an example of subpixel accuracy importance. (You'll need also dftc.red and coffee).
If you run the file and stop the animation (by clicking on it) and then zoom into (wheel) then you might find the end-point of all the blue lines and see that orange line is drawn actually in a bit different place than the end-point of blue vectors. Blue ones are placed with sub-pixel accuracy, but orange line with pair!
, i.e. pixel accuracy. (You can move the pic with mid-down dragging, ctrl-wheel to change rate).
Also, smallest circles are mis-sized and misplaced because there seems to be a lower limit on circle radius :)
1,234
rather than 1,000,000
? Moreover, why should we insist on localizing the decimal separator, if we don't localize everything else?so it's math.
As using floats for pairs is not always desirable (because of side-effects in float handlings), we are considering keeping the pair! as is, and introducing a new similar 2D type, but relying on floats.
The number type represents real (double-precision floating-point) numbers. Lua has no integer type, as it does not need it. There is a widespread misconception about floating-point arithmetic errors and some people fear that even a simple increment can go weird with floating-point numbers. The fact is that, when you use a double to represent an integer, there is no rounding error at all (unless the number is greater than 100,000,000,000,000). Specifically, a Lua number can represent any long integer without rounding problems. Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.
@dockimbel agreed on your points, er, comments. I believe you proposed point!
as the name initially, which I thought was fine, but coordinate!
is much more specific and perhaps better, even if longer. Other domain uses of point
may not be common, but there can really be no confusion about coordinate!
Did your original syntax proposal use parens around the numbers? e.g. (1.0, 2.0, 3.0)
My gut instinct prefers that over a non-spaced comma connector sigil. It's also a direct mapping of mathematical notation.
I'm in the U.S., so can't have an unbiased perspective on commas. I think the original intent was good on Carl's part, but I don't know that it has been a practical benefit.
pair!
with float32!
- I always thought that pair!
will be casted to float!
when one of its components overflows, the way it does with integer!
and float!
, and that float-based pair will be created with <float>x<float>
; point!
with optional 3rd component makes sense, and common notation for that is (x, y, z)
. But I'd prefer pair!
and point!
to be merged together, if possible, as it's just an implementation detail and discrete vs. continuous difference, which IMO shouldn't be user-facing.load
able lexical forms (this parallels recent discussion about JSON codec and messy external data); there's no substantial gain from ditching it... but then it makes (x, y, z)
point!
literal form a bit ambiguous.point!
in VID, Draw and View, and how to interpret its 3rd component (we're talking about 2D interfaces and images here). I also recall some ad-hoc point!
struct being used in Parse, to track internal state.
(x, y, z)
form, I suppose ,
becomes a word delimiter (like brackets), then both (x,y,z)
and (x , y , z)
are also valid? How will this form live along the paren!
and compose
is what I'm concerned with. Will comma become as sort of a composition operator that concatenates numbers into a point!
? May then words and expressions be used instead of numbers in place of x
y
and z
?
Will comma become as sort of a composition operator that concatenates numbers into a point!?
In such case parens are not strictly required and we end up with
object!
or function!
) and require evaluation to be createdpoint!
constructor?) on the level of APL family, which is limited solely to point!
valuesMay then words and expressions be used instead of numbers in place of x y and z?
That's a more general question WRT support of symbols in aggregate values, e.g. use r.g.b
in tuple!
or quantity%
in percent!
(BTW, does axb
pair!
smells fishy to you?).