World: r3wp

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?

$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

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] 
:-)

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.

Geomol - yes, it is. And is it guaranteed that the last digits will 
be always precise?

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.

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

Write that down somewhere (other than only here). When the DocBase 
go public, there could be a place there for new ideas and suggestions.

[...] 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 
# $ %.

or we just could state, that $ is simply a unit char. And rename 
datatype from money! to unit! :-)

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

that could mean some deeper changes to parser probably, no? Well, 
that is not much of an issue ....

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

we already use # in many datatypes, no? hex, binary, special notation 
of #[none], some possible binary conversion functions were suggested 
as 16#{} etc.

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.

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

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

yes, if BCD in general would be usefull for other things than money 
and bank apps meaning, then it could be the right time to do so. 
I was inspired by dictionary! to map! rename, so it seems the team 
is open to ideas in that regard....

yes, but dictionary does not break compatibility, money! would (view 
scripts don't run in r3 but core scripts may run quite well)

I don't agree to that argument though. Even core will change, protocols, 
schemes are different, and btw - what about missing hash? I remember 
using hash, but I never used money! IMO money! is the least used 
datatype in REBOL :-)

but the issue is not really that big, so I can live with money!, 
although it will be kind of weird, if I will use it for weight or 
other unit, when the need of BCD would arise ..... well, maybe I 
will not even need BCD, so .... :-)

Petr; I use money! all the time with the contruction accounting scripts. 
 Bosses love it, until I have to pummel them for using commas in 
big money! and with construction projects it doesn't take long to 
get to a monkey.

Gabriele: Why not leave money! just as it is for compatibility for 
the people who want to use it and introduce a Fixed! type. (I didn't 
call it BCD because apparently it isn't). The following behaviour 
(modelled on IBM 360) would be ideal:

>>fixed-dec: 1.98F2
== 1.98
>>type? fixed-dec
== fixed!
>>print fixed-dec
== 1.98
>> probe fixed-dec
== 1.98F2
>>2F2 / 3F2
== 0.66
>>2F2 / 3F2 + 0.005F3
== 0.67

To keep Brian's construction bosses happy you could allow the use 
of  thousand separators eg
>>fixed-dec: 1,000F2
== 1,000.00

changing how money is implemented does not break compatibility.

also, it's not bcd, but it's not fixed point either. it is 26 decimal 
digits floating point.

why "standard" BCD aproach was not adopted? Is it binary represented 
or not? I mean - can we be sure that some weird rounding will not 
happen, and that the number stays allways the same?

I second fixed! datatype name .... or I propose unit!

I'm sure there will be notes about why standard BCD was not used.