qtxie on master
FIX: issue #4690 (console loses… (compare)
point!
is more like a struct, and the vector!
is more like a constrained block!
:point_up: September 24, 2019 1:56 PM Interesting questions @hiiamboris. If we think of point!
like 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-pair
should 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.
Some half-baked musings:
I think conformance to mathematical notation is not too important. There are plethora of expressions and constructs in programming languages for which there are specific mathematical notations that are too cumbersome to support lexically in a PL. Think e.g. of powers and roots. Type-ability, readability and Redfitness (conformity to Red-ways) are more important.
When it is easy to support it is advantageous of cause to have lexical form which is already established in mathematics (in some variation). In case of (1.0, 2.34, 3.01234)
it is easy to type and read, but 1.0x2.34x3.01234
is not too bad also, albeit a bit harder to read. But the parens/comma version brings confusion with paren evaluation mentioned above. E.g. compose [a (b) (1.0, 2.34, 3.14)]
. It's probably mainly psychological confusion as lexer can presumably easily recognize it as a special type. But visually, it's in parens but not a paren!
.
Can other forms be considered, e.g. x(1.0 2.34 30.1234)
? But it seems even harder to read, unless longer spaces are used: x(1.0 2.34 30.1234)
.
If with three members, it is certainly not a pair!
anymore. To be semantically precise it is more of a point
than coordinate
. According to MW (geometric) point
is "a geometric element that has zero dimensions and a location determinable by an ordered set of coordinates". Coordinates are values characterising the location of a point in different dimensions. Nitpicking, coordinates determine the location or position of a point. So may-be loc!
or pos!
? But then again, it depends on interpretation, these values can also characterize not position of a point but dimensions of an object. E.g. (3, 10, 5)
may be dimensions of an ellipsod, not a point or position. Thus, to leave room for different interpretations, it should rather be triple!
analogously to pair!
. But (sorry!) then it can't have just two members (as it was proposed to have two or three members). (It is probably pointless to point out that out of geometry "point" is not particularily pointed term. Did I make my point?)
What usage might this point!/loc!/coord!
(let it be point!
for now) have besides "coordinates of the position of a point"? Complex numbers and quaternions (and tessarines and bicomplex numbers) pop into mind. Two-member point!
might be interpreted as a complex number, quaternion might be presented as a block of float!
and 3-member point!
.
If pair!
can include float!
members as @qtxie points out above, then it seems very Redfit to have "floating" triplet!
s like 1.1x2.2x3.0
or 1x2x3
too.
Good thoughts. Thanks for weighing in @toomasv. Even for the puns. :^)
3) seems like a bad path to head down.
5) leads to more thoughts, like aliasing. But this is also a slippery slope. With Red you really have to know the context to give something meaning, but the ability to alias types could enforce more strictness. I tend to lean toward pushing that enforcement up into dialects and modules, but there are arguments to be made both ways.
I like the idea of triple!
, as it is domain non-specific, but it also has a very different connotation in the RDF domain. We already have that problem with tuple in other langs and such, so it's not a big problem IMO.
pick
and poke
for image!, we need to do the conversion internally in those actions. The conversion should be safe if the range is between [-16777217, 16777217].
Issue!
is another type that spans many uses, and while the name is imperfect for many of them, nobody has come up with a better one.
So you really want to say that the implementation is shared, but by giving it a new name, it is a new type.
@greggirwin You mean the float32-pair
? No new datatype, My proposal is what this PR does. (red/red#4049)
0.0x1.0 / 0.0x0.0
?(1.#inf, 0)
. x-form does not: 1.#infx0.0
>> 1e10x0 * 1e40
== I.nfinitye9998x-N.aNe9998
>> I.nfinitye9998x-N.aNe999
** Script error: I.nfinitye9998x-N.aNe999 has no value
float32-pair
as complex number, like currently I might use [a i]
in this way. Operations on it should be still implemented separately.
>> 0.0x1.0 / 0.0x0.0
== 1.#NaNx1.#INF
>> type? 1.#NaNx1.#INF
== pair!
triplet!
+pair!
idea. Mainly because usually you expect a point of a certain dimensionality. View expects 2D pairs, while some theoretical 3D engine parts will expect 3D triplets. So it makes sense to enforce that dimensionality by the typing rather than bother with extra length checks. If there will appear a case where both 2D and 3D points should be accepted, one can always make a typeset: point!: make typeset! [pair! triplet!]
.
Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic
After skimming thru https://www.agner.org/optimize/instruction_tables.pdf I have to agree. It's on par speedwise, and float multiplication can even be twice faster than that on integers.
pair!
as a literal value, instead of encountering it as an intermediate computation result? With images we reason in terms of x
and y
amount of pixels (discrete values, integers), and rarely think of subpixel position - rather, it's almost always a result of some precise geometric computation, hidden behind graphical facade.
pair/x
and pair/y
as number. We use it a flag sometimes. For example, In a text editor, we may use pair/x
to store the line number, usepair/y
as bitset flag to store some information. In this case, we cannot use float32. But it is kind of hacking code, I think we should just 2 integers. Or use vector! if we need to record every lines in the text editor.
cell!
size to fit such extra info. Though, we can return that info on syntax errors, that case is trivial.