Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:47

    qtxie on master

    FIX: compiling error on macOS b… (compare)

  • Nov 22 22:41
    greggirwin commented #4717
  • Nov 22 22:30
    Travis red/red#4717 errored (5443)
  • Nov 22 21:56
    hiiamboris synchronize #4717
  • Nov 22 17:39
    Travis red/red#4717 errored (5442)
  • Nov 22 16:53
    hiiamboris synchronize #4717
  • Nov 22 05:29
    dander commented #4729
  • Nov 22 00:44
    greggirwin commented #4735
  • Nov 22 00:01
    Travis red/red (master) errored (5441)
  • Nov 21 23:59
    Travis red/red#4734 errored (5440)
  • Nov 21 23:00
    hiiamboris commented #4734
  • Nov 21 21:55
    Travis red/red (master) errored (5441)
  • Nov 21 21:26

    dockimbel on master

    FEAT: hides the GUI console if … (compare)

  • Nov 21 17:47
    Travis red/red#4734 errored (5440)
  • Nov 21 17:47
    hiiamboris commented #4734
  • Nov 21 17:08
    hiiamboris commented #4734
  • Nov 21 17:07
    hiiamboris synchronize #4734
  • Nov 20 23:36
    Oldes commented #4735
  • Nov 20 23:32
    Oldes opened #4735
  • Nov 20 23:05
    Travis red/red#4734 errored (5439)
Boleslav Březovský
@rebolek

so it's math.

As using floats for pairs is not always desirable (because of side-effects in float handlings), we are considering keeping the pair! as is, and introducing a new similar 2D type, but relying on floats.

Oldes Huhuman
@Oldes
I mean... what is wrong with having pair! based on float32 as it is in Rebol3?
When I read this, than only that No bitwise operations. (and, or, xor), which I never used.
Having float pair when dealing with images is a good thing imho.
So my opinion is, that it is definitely good to have float pair, but not two very similar types, which differ only in internal implementation.
Btw... I would like to have more dimensional points as a datatype.
Boleslav Březovský
@rebolek
@Oldes that's like saying we don't need integer! because we have float!
nedzadarek
@nedzadarek
@rebolek @Oldes it depends on the implementation of a floating numbers. According to stackoverflow answer the Lua used "floats" as it's number representation. I read that they didn't have "big problems" with "float handlings" nor speed.
As fair I remember DEC64 (implemented by @hiiamboris but I couldn't find the link) does not have that problems.

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.

Source

Petr Krenzelok
@pekr
In Czech locale, comma is used as a decimal separator too. But - I do hate it. Using it for a thousands separator looks even mor weird though. MS allowing locales and translation of function names in Excel was imo one of the worst decisions ever.
My question though is, what would we gain be freeing comma? Do you really want to see something like 1.2,1.1 instead of 1.2x1.1? I also fear that freeing comma will attract ppl to use it in arrays or vectors :-)
Galen Ivanov
@GalenIvanov
@pekr Yes, as concat/append in APL/J/K
Alvydas Vitkauskas
@avitkauskas
Supporting comma as decimal separator is really not needed and it is inconsistent in a way. When writting code you are actually writting in English (all the keywords are English anyway), so it's just normal to use "English locale". Should comma be used somewhere else and where - it's another question.
GiuseppeChillemi
@GiuseppeChillemi
point! ? What about matrix! ?
nedzadarek
@nedzadarek
@avitkauskas you can translate keywords (there were the post in the website) but if you want to share your code - yes, you should use English.
Gregg Irwin
@greggirwin

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

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.

Vladimir Vasilyev
@9214
  • pair! with float32! - I always thought that pair! will be casted to float! when one of its components overflows, the way it does with integer! and float!, and that float-based pair will be created with <float>x<float>; point! with optional 3rd component makes sense, and common notation for that is (x, y, z). But I'd prefer pair! and 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.
  • as for discussion about comma support in floats - some data is kept that way (esp. in DSV/CSV tables), so it might make sense to keep them as 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.
Respectech
@Respectech
@jeffakakaneda_twitter I'm hoping to go to FOSDEM, so if I can make it there should at least be one other. :-)
Jean-François CAUCHE
@jeffakakaneda_twitter
@Respectech Great ! I generally spend the whole weekend there.
Vladimir Vasilyev
@9214
(Continuing) another thing to consider is how to support 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.
hiiamboris
@hiiamboris
If we accept the (x, y, z) form, I suppose , becomes a word delimiter (like brackets), then both (x,y,z) and (x , y , z) are also valid? How will this form live along the paren! and compose is 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 x y and z?
Vladimir Vasilyev
@9214

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

  • value that has no direct lexical form (like e.g. object! or function!) and require evaluation to be created
  • esoteric concatenation operator (or point! constructor?) on the level of APL family, which is limited solely to point! values

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 r.g.b in tuple! or quantity% in percent! (BTW, does axb pair! smells fishy to you?).

Vladimir Vasilyev
@9214
Though, all examples are :fish:y: r.g.b is a valid word!, and in quantity% % receives a special lexical treatment.
>> type? 'r.g.b
== word!
>> [quantity%]
== [quantity %]
nedzadarek
@nedzadarek
Is it some kind of "reduced functions" enough:
r: g: b: 123 
tuple>: func [arr] [to-tuple reduce arr]
tuple> [r g b] ; == 123.123.123
?
Dave Andersen
@dander
Is there any relationship with the proposed point! type(s) and vector!? Is vector! more akin to a sequence type?
Vladimir Vasilyev
@9214
@dander what do you mean by "sequence type"? vector! is homogeneous (can keep only values of the same type) and supports scalar operations. You can, in theory, have vector! of point!s.
Dave Andersen
@dander
@9214 I was mainly thinking about whether or not it has a fixed length (but maybe didn't have that question formed in my mind), rather than the types that it can hold. I think that does answer my question, since the point! is more like a struct, and the vector! is more like a constrained block!
Vladimir Vasilyev
@9214
@dander proposed point! can keep up to 3 float32! elements, that's a hard limit on cell's payload size. Both point! and vector! are "like a struct", implementation-wise, it's just that vector! keeps a reference to external buffer with all the data.
Dave Andersen
@dander
It sounds like they fit totally different uses. Thanks for the explanation
Softknobs
@Softknobs
Hi, I was missing some web development with Red. So I ported a minimal example of libmicrohttpd server usage to Red. Bindings are minimal and the example only serves one page but it can be expanded. Code and library binaries (Windows/Linux) can be found here:
https://github.com/Softknobs/RedLibmicrohttpdPoC
Gregg Irwin
@greggirwin

: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.

linoonphan
@Linoonphan
In an article updated in June this year, the article said that it will release the Red/Android beta release in September this year. may i ask when there will be new news about Red/Android
Qingtian
@qtxie
After more reading, I think totally switch to 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.
Toomas Vooglaid
@toomasv

Some half-baked musings:

  1. 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.

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

  3. 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).

  4. 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?)

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

  6. 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.

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.