r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Geomol
17-Aug-2007
[4122]
A little update from Alpha testing. Since last time, this happened:

- POWER can now handle negative number and exponent

- Some bugs fixed regarding: money!, path, VID crash, change/part, 
read, function and closure recursion crash, compose/deep
- New dictionary! datatype (replacing hash!)
- A lot is going on in the graphics, VID and DRAW groups
- Ongoing work to get the test methods to perfection

We're now on Alpha 49.
Pekr
17-Aug-2007
[4123x2]
Carl asks about better name for dictionary!, which is a bit long. 
I think there is only one alternative, if we want the name to be 
on pair with other languages - dict! ... the thing is, that we don't 
use abbreviations in REBOL most of the time, but we have func too, 
so why not dict! ?
and I don't like percents. I don't want to open that discussion here, 
because I already seen some discussion on it, and while it might 
seem trivial, it is not :-) But generally I refuse result which is 
different from what I got from calculator. So basically how following 
could be valid escapes my basic school knowledge:

12.3 * 110% = 13.4


Of course I would expect 12.3 + (10% from the base (12.3)) = 13.53, 
which is returned also by my Windows calculator. Even if I think 
about 110% as of 1.1, still 12.3 * 1.1 = 13.53.

IMO there is a bug in the doc :-)
Rebolek
17-Aug-2007
[4125x2]
that's a docs problem, let me fix it...
r3 works as your calculator, Pekr :)
>> 12.3 * 110%
== 13.53
Also remember that main purpose of percent is to enhance sematics 
in dialects and not to work as a calculator. But you're free to write 
your own calculator dialect.
Pekr
19-Aug-2007
[4127x3]
I just read about BCD representation and money datatype. What escapes 
my understanding is, why BCD is internally tied to just money area? 
I really don't like it.
Coulldn't I just choose some mode for decimal datatype to work as 
BCD?
E.g. - just recently in one of our systems we tried to solve weigh 
unit conversions, where we needed precision on milligrams. If my 
understanding is correct, it is where I should use money. Now how 
is $ unit usefull for me here?
Sunanda
19-Aug-2007
[4130]
Maybe best to think of the $ as a BCD specifer rather than specifically 
a money one. 
   to-bcd: : to-money
  for all other uses :-)
Pekr
19-Aug-2007
[4131x2]
yes, I would come up with some new name. My question is - did anyone 
use money? I never used it in my scripts for e.g.
just recently dictionary! datatype was renamed to map! datatype ...
PeterWood
19-Aug-2007
[4133]
Using $ as a BCD specifier wouldn't be so bad if 'print ignored it. 

>>print join weight ["mg"]
== $123.45678mg
Pekr
19-Aug-2007
[4134]
some time ago we thought about allowing other chars for money. Or 
something like USD$123.123 ... the question is, if there is some 
better char to be used for amount of various units?
Sunanda
19-Aug-2007
[4135]
$123.45678mg .... That is a drawback, Peter. Will format help?
And it may still be negotiable in R3:
http://www.rebol.net/r3blogs/0092.html
Pekr
19-Aug-2007
[4136x3]
format is not enough. I don't know why we have datatype limited to 
money? Why not kg, tonnes, other units?
the trouble is, how to make such datatype look like in rebol, and 
 not complicate low level parser
we have already #[none] form etc., so maybe [kg]1234.5678, or 1234.5678[kg] 
:-)
Geomol
19-Aug-2007
[4139x2]
With 64-bit decimals, you have 15 digits precision, and it's faster. 
You can specify up to a million ton, and still have milligrams. Is 
that enough for your task?
Example: 123'456'789.123'465 is a valid decimal! with full precision.
Pekr
19-Aug-2007
[4141]
Geomol - yes, it is. And is it guaranteed that the last digits will 
be always precise?
Geomol
19-Aug-2007
[4142x4]
That's one of the things, I'm investigating for the alpha-release. 
If all your numbers are within that limit, it should be ok. But if 
you e.g. add 2 numbers like: 123'456'789'012'345.0 + 123'456'789.012'345, 
you loose presicion in the smaller number.
The precision for 64-bit IEEE decimals is 15.95 decimal digits. You 
can have results up to 17 digits (it's a parameter to be able to 
change). It's default set to 15 to always give correct result. In 
5% of the cases, the 16th digit will be wrong. See e.g.: http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html
Work is done to get around problems like:
>> (0.2 - 0.1) = 0.1
== true
>> (1.2 - 1.1) = 0.1
== false
(This is also a the results in R2.)
And in other languages like C btw.
Pekr
19-Aug-2007
[4146x2]
well, look - we've got BCD for the money, right? so there is the 
solution for those who need it. But i would vote for another kind 
of expressing units, more general. IMO money! is the most useless 
datatype in REBOL. My proposition really is 123'456.123[unit], where 
'unit would be of no meaning to not complicate things - simply 123[USD] 
+ 123[EUR] would be 246[USD] - the first occurance of the unit.
I can even imagine unit conversion table, so that we could get even 
USD + EUR result .... and if expression would contain some non transferrable 
units, e.g. USD + kg, then error would be raised ...
Geomol
19-Aug-2007
[4148]
Write that down somewhere (other than only here). When the DocBase 
go public, there could be a place there for new ideas and suggestions.
Gabriele
19-Aug-2007
[4149x6]
[...] can't be done
kg$123 is not that bad - other languages have much weirder syntax.
maybe, we can do 123#kg but i don't see a big improvement here.
kg#123 may be possible too.
or 123$kg
rebol has very few "special" characters. so you'd have to pick between 
# $ %.
Pekr
19-Aug-2007
[4155]
or we just could state, that $ is simply a unit char. And rename 
datatype from money! to unit! :-)
Gabriele
19-Aug-2007
[4156x6]
% is already used by percent! is is out of the question.
R2:
>> kg$100
== KG$100.00
so, yes, it's already that wa.
way.
maybe 123kg can be made to work, but, i don't know if it would create 
problems.
Pekr
19-Aug-2007
[4162]
that could mean some deeper changes to parser probably, no? Well, 
that is not much of an issue ....
Gabriele
19-Aug-2007
[4163x4]
>> 123kg
** Syntax Error: Invalid integer -- 123kg
** Near: (line 1) 123kg
syntax error means that we have a free spot in the parser there :-)
but, we should be careful with something like that, as it can get 
very confusing.
kg123 is a word for example.
Pekr
19-Aug-2007
[4167]
we already use # in many datatypes, no? hex, binary, special notation 
of #[none], some possible binary conversion functions were suggested 
as 16#{} etc.
Gabriele
19-Aug-2007
[4168]
yes, as i said, i think only # $ and % are "special" for the parser, 
so that you have to pick there. carl picked # for a lot of things 
because $ and % carry meaning.
Pekr
19-Aug-2007
[4169]
kg#123 and kg$123 sound equal to me. It is just that the datatype 
is called money! Dunno if english unit! term would be more descriptive/general 
...
Gabriele
19-Aug-2007
[4170x2]
#123 is an issue so kg#123 would mean that you always have to specify 
a unit... and a space by mistake becomes a subtle bug.
ok, so you basically just want to rename money! to unit! or something 
like that.