qtxie on master
FIX: issue #4891 (First selecti… (compare)
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.
>> 1x1
== 1.0x1.0x0.0
path!
?>> 1x(pow 3 2)
== 1.0x9.0x0.0
vector!
of integer!
s.as-coord
helper to start, and see if paren notation still has enough value.
@greggirwin @giesse this proposed paren notation for me is natural consequence of having similar mechanism in defining path!
s, which is very convenient for me:
>> a: [b [c 123]]
== [b [c 123]]
>> get to path! reduce ['a (to-word "b") 'c]
== 123
>> a/(to-word "b")/c
== 123
So, for me 1x(pow 3 2)
is more easy to read/understand and shorter than as-coord 1 pow 3 2
. At first glance you see that this expression is a coord!
.
@loziniak I'm used to parens in paths from many years of Reboling, though I don't use them often. However, they are still considered an experimental feature in Red, as we are not sure they are worth keeping.
To make sure I understand your example, you have code with 2 known values and variable key between them, like accessing a keyed record's field. Here's a more efficient way to do that, which seems clearer to me:
>> a: [b [c 123]]
== [b [c 123]]
>> k: to word! "b"
== b
>> a/:k/c
== 123
Does the path approach give you some other benefit that I don't see at a glance?
x
), which is not "special" like /
, it opens up a lot more questions and potential ambiguity. Paths are specifically meant for indirect access, and have to start with a word. Do pairs in your design have to start with a literal number, or is (pow 3 2)x(pow 2 3)
valid as well? Because that's no longer Red compatible as a syntactic form. If that's not valid in your design, you can only evaluate the y
axis, which seems much less useful and general.