qtxie on master
FIX: handle more cases in issue… (compare)
qtxie on master
FIX: WIN: issue #4576 (text-lis… (compare)
dockimbel on master
FIX: issue #4574 (Remainder rai… TESTS: extend FLOAT! test suite… Merge pull request #4599 from 9… (compare)
dockimbel on master
FIX: issue #734 (lit-word varia… TESTS: add regression test for … Merge pull request #4600 from 9… (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.
pokefor 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:
>> 1e10x0 * 1e40 == I.nfinitye9998x-N.aNe9998 >> I.nfinitye9998x-N.aNe999 ** Script error: I.nfinitye9998x-N.aNe999 has no value
float32-pairas 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!
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
yamount 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/yas number. We use it a flag sometimes. For example, In a text editor, we may use
pair/xto store the line number, use
pair/yas 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
>> 1x(pow 3 2) == 1.0x9.0x0.0
as-coordhelper 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
@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?