World: r3wp
[!REBOL3-OLD1]
older newer | first last |
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. | |
older newer | first last |