by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:34
    bitbegin commented #4576
  • 01:16
    qtxie closed #4659
  • 01:16
    qtxie commented #4659
  • 00:19

    qtxie on master

    FIX: handle more cases in issue… (compare)

  • Sep 25 23:16
    qtxie assigned #4576
  • Sep 25 23:12

    qtxie on master

    FIX: WIN: issue #4576 (text-lis… (compare)

  • Sep 25 13:04
    dockimbel assigned #650
  • Sep 25 13:00
    dockimbel milestoned #4574
  • Sep 25 13:00
    dockimbel labeled #4574
  • Sep 25 13:00
    dockimbel labeled #4574
  • Sep 25 13:00
    dockimbel labeled #4574
  • Sep 25 13:00

    dockimbel on master

    FIX: issue #4574 (Remainder rai… TESTS: extend FLOAT! test suite… Merge pull request #4599 from 9… (compare)

  • Sep 25 13:00
    dockimbel closed #4599
  • Sep 25 13:00
    dockimbel closed #4574
  • Sep 25 12:59
    dockimbel unlabeled #734
  • Sep 25 12:58
    dockimbel labeled #734
  • Sep 25 12:58
    dockimbel labeled #734
  • Sep 25 12:58
    dockimbel labeled #734
  • Sep 25 12:58

    dockimbel on master

    FIX: issue #734 (lit-word varia… TESTS: add regression test for … Merge pull request #4600 from 9… (compare)

  • Sep 25 12:58
    dockimbel closed #4600
Qingtian
@qtxie
@Linoonphan Nope. Plan changes as usual. :sweat_smile: We should have only say what we were working on at that time in the blog article.
Gregg Irwin
@greggirwin

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.

Qingtian
@qtxie
(Continuing) Switch to float32-pair, the user should not need to update anything. While some runtime function need to be changed to support float arguement. For example, 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].
Gregg Irwin
@greggirwin
We had quite a conversation in the Ren space long ago, about the name tuplex!.
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.
Aliases sound nice, but offer a false sense of type safety, which is worse than offering none at all.
So you really want to say that the implementation is shared, but by giving it a new name, it is a new type.
Gregg Irwin
@greggirwin
But that's not perfect either. It's just all tradeoffs and, as you say, finding the best fit in Red, overall, is the goal.
Qingtian
@qtxie

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)

Gregg Irwin
@greggirwin
Sorry @qtxie, I meant the general discussion of pair/point/triple/quad/coord/loc/pos.
hiiamboris
@hiiamboris
What do we do in case of 0.0x1.0 / 0.0x0.0 ?
Paren form allows us to define such values as (1.#inf, 0). x-form does not: 1.#infx0.0
R3 didn't solve that:
>> 1e10x0 * 1e40
== I.nfinitye9998x-N.aNe9998

>> I.nfinitye9998x-N.aNe999
** Script error: I.nfinitye9998x-N.aNe999 has no value
Toomas Vooglaid
@toomasv
@greggirwin Er.. was it question to me? ("So you ...")
Gregg Irwin
@greggirwin
Rhetorical. It's late for me, so take everything in that light. :^)
Qingtian
@qtxie
@hiiamboris We support this 1.#NaNx1.#INF in the lexer, though it's ugly.
Toomas Vooglaid
@toomasv
@greggirwin If I understand the question to imply that I proposed introducing new types by just renaming , then noooo. What I meant was example of possible usage of float32-pair as complex number, like currently I might use [a i] in this way. Operations on it should be still implemented separately.
Gregg Irwin
@greggirwin
I was springboarding thoughts off of yours. :^)
linoonphan
@Linoonphan
@qtxie If this is always the case, we are losing many developers.
Qingtian
@qtxie
@Linoonphan We're improving it.
@hiiamboris
>> 0.0x1.0 / 0.0x0.0
== 1.#NaNx1.#INF
>> type? 1.#NaNx1.#INF
== pair!
hiiamboris
@hiiamboris
Yeah I get that @qtxie. Thanks :) Real ugly, but useful.
hiiamboris
@hiiamboris
@toomasv I like the 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!].
bitbegin
@bitbegin
for float32! pair!, we can use a new syntax like: #<1.0 2.0> to distinguish them ?
Qingtian
@qtxie

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!].

@hiiamboris Or just use the 3D triplet!. If it's used for 2D, the Z dimension can just be ignored.

hiiamboris
@hiiamboris

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.

Vladimir Vasilyev
@9214
So... initial proposal was to get float-based triple! / point! / whatnot, but now we have pair! that supports both integers and floats; then, what's the point (no pun intended) of triple!?
Vladimir Vasilyev
@9214
I mean, we can always squeeze an extra 4-byte value in the payload and get new datatype, but it doesn't seems like a priority to me, as we don't have any related use-cases. Not to mention the amount of design musings over lexical form that it requires.
Vladimir Vasilyev
@9214
How frequently whose coming from Rebol actually wrote float-based 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.
Vladimir Vasilyev
@9214
i.e., 1.23x45.6 looks a bit quirky if you see it, but I can live with that, because I rarely will type it by hand.
Qingtian
@qtxie

i.e., 1.23x45.6 looks a bit quirky if you see it, but I can live with that, because I rarely will type it by hand.

I'm also OK with this format.

Qingtian
@qtxie
One problem of the float32-pair is in some old code we don't always use the 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.
Gregg Irwin
@greggirwin
:point_up: September 25, 2019 5:44 AM See what happens when you hack things @qtxie? ;^)
Qingtian
@qtxie
😅
Nenad Rakocevic
@dockimbel
FYI, the refactor-lexer branch was dropped. The most useful changes from that branch were ported to master. That branch has been replaced with the fast-lexer branch now, re-implementing the Red run-time lexer in R/S.
bitbegin
@bitbegin
@dockimbel the new lexer can parse all codes, and give all errors? Also, if it return the line/column, will be very useful.
Petr Krenzelok
@pekr
Question of an uneducated - Lexer parses Red source code, during the load, or even interpretation? By rewriting lexer in R/S, will it "just" load code faster or will generally interpreter be faster?
hiiamboris
@hiiamboris
Just load. Unless you are a fan of do load "my-code" patterns :)
Still, it's a very welcome change, as sometimes you load data. After 10MBs it's unbearably slow.
And as @bitbegin notes, preserving the info about the origins (line/column) of each word would be a tremendous help in debugging. Is this planned?
Nenad Rakocevic
@dockimbel
@hiiamboris @bitbegin It's a feature I want to add since a long time, but we still haven't figure out how to do the reverse mapping between a given value and its line/column info for debugging purpose. One way would be to extend the cell! size to fit such extra info. Though, we can return that info on syntax errors, that case is trivial.
hiiamboris
@hiiamboris
Perhaps one way is to change "index in symbol table" part of a word into a pointer to a structure with that data + the actual index?
Nenad Rakocevic
@dockimbel
@hiiamboris We need a reverse-mapping to line/column (and even filename) for any value, not just words.
Maciej Łoziński
@loziniak
My thoughts on floats in pair!
  1. Every 2D point could be considered also a 3D point, also conversion between float and int could be seamless:
    >> 1x1
    == 1.0x1.0x0.0
  2. My wish - could we make possible using parens like in path!?
    >> 1x(pow 3 2)
    == 1.0x9.0x0.0
  3. In special cases (discrete image pixels, editor line hacking) we can always use vector! of integer!s.
Gregg Irwin
@greggirwin
@loziniak 2) is a significant change, which opens the question for other segmented/multi-part values, like tuples. If you could mock up some more examples using that syntax, for use cases you imagine, we can more easily weigh things. It may be that we try an as-coord helper to start, and see if paren notation still has enough value.
Dave Andersen
@dander
image.png
More of a side-note, since not everyone would have them, but with a font that has ligatures, the x-delimited ones do look a bit nicer (this is Fira Code)
Gabriele Santilli
@giesse
@loziniak 1x(something) would have to be a new block-like type. So, even though those things look like great ideas, in practice they are not.
GaryMiller
@GaryMiller

Will Fast Lexer be in tomorrows available download?
Windows red-25sep19-f753e25c.exe 1.2 MB

Will be interested to try. My Lex is running about 9 seconds now when loading into Interpreter. ~62,000 lines of Red Code

Gregg Irwin
@greggirwin
No release date announced on fast lexer.
You will be a great test case though. :^)
Maciej Łoziński
@loziniak

@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!.

Gregg Irwin
@greggirwin

@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?