World: r4wp
[!REBOL3] General discussion about REBOL 3
older newer | first last |
Andreas 13-Apr-2013 [2358x2] | Ok. |
(Or a gob, maybe.) | |
Ladislav 13-Apr-2013 [2360x2] | Yes, the reason why GOBs needed GC was that they did not fit within 128 bits. |
(GOB is 512 bits) | |
Andreas 13-Apr-2013 [2362] | So there's a "gob reference" value type? |
Ladislav 13-Apr-2013 [2363] | Yes |
Andreas 13-Apr-2013 [2364] | Ah, I see. A "gob value" is just a pointer to the real gob structure. |
Ladislav 13-Apr-2013 [2365] | REBGOB (the part needing GC) is 512 bits, while Reb_Gob (fits within 128 bits and points to a REBGOB) |
Andreas 13-Apr-2013 [2366x2] | REBGBO! :) |
Thanks for clarifying. | |
Ladislav 13-Apr-2013 [2368x3] | Yes, sorry, it is just struct Reb_Gob called REBGBO. |
BTW, REBGBO looks quite ugly to me | |
(I mean just the name) | |
Andreas 13-Apr-2013 [2371x2] | Maybe REBGBI (in analogy to REBSRI) would be better? |
Is the "index" field of REBGBO presently used? | |
Ladislav 13-Apr-2013 [2373x7] | yes |
you can write: next gob | |
So, actually, the "full GOB" is 544 bits, not just 512 | |
(when summing REBGOB and REBGBO while subtracting the pointer. | |
I am quite curious whether it would be possible to fit a Rebol value to less than 256 bits when using 64-bit memory pointers | |
I originally guessed 160 bits might suffice, but I would not bet on it now. | |
if not wanting to make some "big adjustments", it looks like absolutely necessary to go to at least 224 bits. | |
Andreas 13-Apr-2013 [2380x2] | I'd be quite interested in that as well. |
And I'd generally try to stay 64-bit aligned. | |
Ladislav 13-Apr-2013 [2382] | ...which yields exactly 256 bits :-( |
Andreas 13-Apr-2013 [2383] | 192 or 256, yes. |
Ladislav 13-Apr-2013 [2384x2] | some "values" contain 3 pointers, which gives 192 + type information + alignment = 256 |
Hi, all, a "stupid" question: R3 is still called "alpha" (and there *are* issues I want solved before moving it to beta). One of the issues is the "gotcha" represented by the DECIMAL! name. I know that it is used consistently in Rebol, but it is still a "gotcha" for any possible newcomers actually stating something like: "here mathematics is not welcome", which is not true so much as I (mathematician by the education) would say. Also, having a "truly decimal" datatype called MONEY! in R3, I would prefer a rename: MONEY! rename to DECIMAL! DECIMAL! rename to REAL! or FLOAT! (or something else that could be popular) So, how many of you prefer to keep the DECIMAL! name for the 64-bit IEEE 754 binary floating point format used in Rebol and how many of you prefer to rename the DECIMAL! datatype to something else? | |
Henrik 13-Apr-2013 [2386] | I would not mind this change. |
Andreas 13-Apr-2013 [2387] | I'm strongly in favour of this change (and would prefer float! over real!). |
Gregg 13-Apr-2013 [2388] | Not a stupid question, a hard one. 1) Keep money! as it is. 2) Use new decimal type for decimal! +1 3) Use float! (not real!) as the name for IEEE754 +1 |
Ladislav 13-Apr-2013 [2389] | Thanks for 3). As far as 1) and 2) go, it looks that you did not read www.rebol.net/wiki/Money yet? |
Robert 13-Apr-2013 [2390] | Lad: +1 |
DocKimbel 13-Apr-2013 [2391] | That should be more in line with Red's type naming. So: * Float!: +1 (though I'm not against real!, float! is more CS than maths) * Decimal! for a BCD type (could use money literal form, so, +1 for renaming money!) |
Ladislav 13-Apr-2013 [2392] | It looks www.rebol.net is down? |
Robert 13-Apr-2013 [2393] | for me too |
Gregg 13-Apr-2013 [2394] | Me too. Can't read the link. |
Gregg 14-Apr-2013 [2395] | rebol.net is back up, so I looked at the wiki artilcle. To clarify, I *did* know money changed in R3. What I meant was that I want that to stay the same as it is now, in R3. |
Rebolek 15-Apr-2013 [2396] | Good idea, Ladislav, I agree. |
Endo 15-Apr-2013 [2397] | +1 for Ladislav's idea. |
Ladislav 15-Apr-2013 [2398x3] | Clarification: as far as I know nobody plans to change the implementation of the datatype. However, it is not money in fact, it is actually better characterized as a decimal datatype. That is why I did not understand why did you suggest any new decimal type since it already exists using just an inadequate name. |
or maybe adequate... The fact is that the syntax corresponds well to the money! name, and it makes sense to keep the syntax as is. | |
If counting just the votes for/against naming the IEEE 754 binary floating point datatype as float! and adding BrianH as one who prefers the decimal! name for backward compatibility reasons (he perceives a datatype name to be influencing language syntax in a big way) I am currently getting: For float! name: Ladislav, Henrik, Andreas, Gregg, Robert, Doc, Rebolek, Endo For decimal! name: BrianH I would like to get more votes on this, though. | |
Pekr 15-Apr-2013 [2401] | Not sure if my "vote" applies, but in the early stages of R3 development, I radically protested against anything being called Money, which I found being a capital nonsense. Also the "$" char representing the datatype notation is OK mostly for US, but not e.g. EU, where EUR is represented by its own char. So - not sure what my suggestion alligns with, but: - remove Money datatype altogether, or let it be reserved for money/conversion purposes, along with $ char. - use decimal! for BCD, no $ char, but if we need to distinguish from IEEE754, I can live with that - use float! for IEEE 754 stuff |
PeterWood 15-Apr-2013 [2402] | float! instead of decimal!, decimal! instead of money! +1 (for both) |
DocKimbel 15-Apr-2013 [2403] | Pekr: how do you propose to distinguish literal forms of decimal! vs float! if you remove the $ prefix? Though I agree that the $ doesn't look nice from here (EU). |
MaxV 15-Apr-2013 [2404x3] | I love the mone! type, moreover you may use EUR$4 for EURO |
It reduce to only 2 decimal automatically, it's very useful! | |
It advice you if you are macking some mistake | |
Maxim 15-Apr-2013 [2407] | IEEE renamed to float!, money! renamed to decimal! this way, the vast majority of apps which used decimals before will simply continue to work, but be more precise (albeit a bit slower). |
older newer | first last |