• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

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).
DideC
15-Apr-2013
[2408x2]
Carl blog about "Currency designator for money datatype" http://www.rebol.net/cgi-bin/r3blog.r?view=0201

Carl stated in its reply "4.  No, we are not renaming decimal. It 
will remain as is." just to remember us.

So:

1) current R3 money! datatype is not a money type as R2 define it. 
So it can be renamed.

2) Should the actual R3 money! be renamed decimal! is againt Carl 
point, but I'm not against it if we ponder the compatibility issue 
(BrianH point).

3) decimal! -> float!  I don't like it but  Icould probably leave 
with!

4) a money! type must be considered as a BCD + currency type. A "must 
hvae" would be the possibility to programmaticaly define the rules 
to apply if mathematical operations arrived between different currency 
numbers. So it can throw an error or apply a conversion or change 
the resulting currency...
A dialect would be used to specify the rules :

money-rules [* M M currency M²    / M M error     / M² M currency 
M       + EUR CDN error     + EUR USD multiply 1.30800]
Think ">> M$2.0 * M$2.0     == M²$4.0"
>> EUR$10 + USD$10
== EUR$23.08
Maxim
15-Apr-2013
[2410]
I don't think people are against a money! type per se.   we are just 
against the current datatype names assigned to implementations.

decimal! is not a decimal type
money! is not a currency type


we simply need to add a new real number type called FLOAT! and  properly 
assign the current types to what they really are.


shifting the implementation of money! to decimal!  (without its $ 
or currency designation) won't actually break any previous code a 
part from making it more precise and possibly a bit slower.


we can always keep the current money! as-is, but  I see no point 
in it.  since it doesn't actually do any type of currency management.
Gregg
15-Apr-2013
[2411x3]
Money has meaning, and was one of the things that really excited 
me when I found REBOL. It was also one of my biggest disappointments, 
in R2, when I found that it didn't work right. So I'm thrilled with 
the new implementation. Unfrotunately, I don't have any great suggestions 
for a float! sigil, which would allow us to identify all of them 
lexically. And I can see changing the name of decimal! to float!, 
and money! to decimal! as potentially causing problems in code that 
displays results. Suddenly all the code that explicitly casts to 
decimal! will show dollar signs.
~ is the best sigil I can think of for float!, but I don't know if 
it's better held in reserve for something else.
It's unfortunate that $ is U.S. centric, but is that a showstopper 
that requires a completely different approach, so we can support 
€. £, and more?
DideC
15-Apr-2013
[2414]
~ would be good for float! as it stends (for me) as an approximation 
and we know that IEEE 754 can't represent/store some decimal values.

But it is very boring to use in FR keybord as it is not displayed 
while you hit the key to allow ã or õ typing.
Gregg
15-Apr-2013
[2415x2]
I can only speak for myself, but I think think float! would rarely 
be used. Mainly if you have to use routines with other languages. 
Otherwise, I would probably be OK with eliminating it entirely.
Ladislav, do you have any idea what the performance hit is for the 
new decimal implementation, versus float (current decimal! type)? 
A very quick test here was going to make me say ~30%, but division 
seems to get hit a lot harder. And I don't know how much of that 
is extra work R3 does for money, which wouldn't be there for a straight 
decimal type (if any).
Ladislav
15-Apr-2013
[2417]
I do not understand what "straight decimal type" might be.
Gregg
15-Apr-2013
[2418]
Your new decimal implementation without the added currency/denomination 
part.
Ladislav
15-Apr-2013
[2419]
The money! implementation currently is "without the added denomination 
part"
Gregg
15-Apr-2013
[2420]
OK, so there is no internal handling in place that would add overhead 
right now, correct? And ~30% could be a valid difference (not counting 
division).
Ladislav
15-Apr-2013
[2421]
The speed difference must be at least (actually, it should be even 
greater a bit due to the deimal nature) equal to the difference between 
floating point arithmetic done by the coprocessor, versus it being 
done by an emulator.
Gregg
15-Apr-2013
[2422]
Just looking for ballpark estimates.
Ladislav
15-Apr-2013
[2423x2]
Also, division is the most demanding operation
And, let's not foget that the datatype is 96-bit, which certainly 
has to make the arithmetic slower as well.
Gregg
15-Apr-2013
[2425x2]
Yes. Division makes the biggest difference by far (again, quick test).
Still probably fast enough for me. :-)
Maxim
15-Apr-2013
[2427x3]
when we talk about changing the datatype names, I think we accept 
that decimal wouldn't have any currency or denominator. 

its the implementation behind the type which would be switched, and 
a "new type" added which would map to the current decimal! handling.
in fact, maybe the new float! could support NaN, +/- inf, etc    
 while decimal would continue to raise a bit more errors.
if speed is required (which it is rarely, for most cases in which 
rebol is optimal), then IMHO we won't mind dealing with any additional 
details like a type denominator (which other languages also use) 
to separate similar types like the use of   0.01f  in C/C++ to cast 
to float (instead of a double, used by default).
Arie
23-Apr-2013
[2430]
There is a function abs and a function absolute which seem to be 
exactly the same. Is that on purpose?
Gregg
23-Apr-2013
[2431]
Yes, ABS is just a shortcut name, like MAX and MIN.
TomBon
29-Apr-2013
[2432]
Does a face-to-face R2/R3 features & function comparison exists anywhere 
in the wiki?
Gregg
29-Apr-2013
[2433]
Not that I know of. Some time back I set up a wiki on wikidot, but 
it doesn't have to be hosted there. The main idea is to have the 
data in a REBOL format so we can use it in various places. That's 
a big job, and we need to figure out how to represent comparisons. 
e.g., is R2 the baseline, and other systems could be compatible, 
extend, restrict, or just not have that functionality? 

http://rebol.wikidot.com/rebol-like-languages
Ladislav
29-Apr-2013
[2434x2]
I wrote a comparison, but do not know whether Robert put it somewhere 
yet
(it is not as complete as you might want iit to be, but at least 
it is a start)
TomBon
29-Apr-2013
[2436]
Gregg, good starting point. I was looking for something like a simple 
diff version to identify the code parts needs to rewritten

and estimate the workload when migrating R2 to R3. Ladislav, will 
talk to Robert. Thanks for info.
NickA
29-Apr-2013
[2437]
This is a very useful project to complete.
DideC
13-May-2013
[2438x4]
Is there anything in R3 to deal with UTF-16 text (file) ?

I have to modify Windows File in UTF-16 with BOM of #{FFFE}. There 
were previously in ISO, but no more :-(
Basically this files are like .INI file and I have to change values 
inside with Rebol.
But  there are writen as UTF-16 on disk by the "normal" apps.
I have found that R3 is able to load my UTF16LE file correctly using 
'read/string (it "see" the BOM and transcode it to rebol string!).


Now I have to find a way to write to the file as a UTF-16 with a 
litle endian BOM format.
DideC
17-May-2013
[2442x3]
I think I have seen rebol code for UTF-* conversion from one to another 
format. Did I dreamed it ?
Basicaly I need UTF-8 to UTF-16LE !
Well. Don't bother. I have found another solution that just remove 
the encoding problem at the start.
Geomol
17-May-2013
[2445]
DideC, the script rebxml2xml.r has support for utf-8, if that's of 
any help:
http://www.rebol.org/view-script.r?script=rebxml2xml.r