qtxie on master
FIX: avoid warning when using r… (compare)
qtxie on master
FIX: check the return from mall… (compare)
qtxie on master
Revert "FIX: simple fix `reques… (compare)
dockimbel on master
FIX: issue #4969 (Copy of error… (compare)
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,000,000? Moreover, why should we insist on localizing the decimal separator, if we don't localize everything else?
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
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.
float32!- I always thought that
pair!will be casted to
float!when one of its components overflows, the way it does with
float!, and that float-based pair will be created with
point!with optional 3rd component makes sense, and common notation for that is
(x, y, z). But I'd prefer
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.
loadable 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)are also valid? How will this form live along the
composeis 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
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
function!) and require evaluation to be created
point!constructor?) on the level of APL family, which is limited solely to
May 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
percent! (BTW, does
pair! smells fishy to you?).
point!is more like a struct, and the
vector!is more like a constrained
:point_up: September 24, 2019 1:56 PM Interesting questions @hiiamboris. If we think of
pair!, then no. They are strictly numeric in literal form. But if we think of them like parens,
compose/reduce should work just fine. Effectively, the commas are there only to identify the literal form and are invisible otherwise. So the lexer can still identify them. Boy, it's a can of worms though, isn't it? It also forces the comma-as-decimal issue.
My gut says no to a non-paren, comma-connected syntax. But I'll have to think about it more, and try to overcome my history. What is the value in supporting it, I wonder?
My original thought, long ago, was simply to extend pair syntax to allow a third, optional segment. The argument, which we face even now, is that floats are harder to read in that context. But let's think about that, along with how literal
coordinate! values would likely be written. Will we use them with placeholder words, to be composed? What are the use cases for entirely literal
coordinate! values? Integer pairs, and their primary use(s) are easy. Pixels in UIs with VID and image sizes. What other literal pair values do people use? Anyone?
Can we identify the primary use cases for literal
coordinate! values? Chime in people. Some math cases, certainly, and possibly some multipliers in 3D systems.
After literal forms that humans write, we have stored/exchanged values, which humans may see, but don't deal with too much, except in debugging. Then there are those values we never, ever see. We care about 1. We don't care about 3. 2 seems not so important to me in my current mood. Given that, I'm not likely to write floats out to a lot of decimal places by hand anyway, so the harm seems minimal when it comes to readability. That's true for either pair or paren syntax.
If that all makes sense, the value of paren syntax is being closer to mathematical notation. That's big. Is it big enough to warrant a completely separate syntax from pairs, which live in a similar domain for some uses? That's a really tough call.
float32-pairshould be fine. Every integer between -16777217 and 16777217 has an exact floating-point representation. For the use case of the
integer-pair, this is quite enough. That means we can process an image size up to 16777217x16777217 pixels without problem. We can use pair in a textarea which has up to 16777217 columns and 16777217 rows.