World: r3wp

Thanks.....Obviously, it'd be much faster to run as a native.

But it may be much faster to develop as a mezzanine -- and would 
be (with a little care) backward compatible with existing and older 
versions of REBOL.

What would be useful  is some agreement on the dialect......The RT 
could schedule work on the native while others do it mezzanine as 
a usual (and b/w compatible) prototype.

well... just let Carl know that you need it, and he'll probably react 
in some way :)

Okay -- will do. Thanks.

I wrote generalised solution in the past. Dunno what Carl Read was 
complaining about, but not having 'pad by default sucks pretty much!

it is pretty common function imo for string formatting and I am not 
sure I am willing to talk about its need once again, as in the past 
I was told I could easily write some mezzanine function for that. 
But we are probably not able to learn ourselves one important thing 
- if there are repeated request and we see new ppl facing still the 
same problems, we should think twice if it would not be able to be 
included by default ;-)

also, e.g. - how to easily "form decimal"? E.g. doing 1 / 100 returns 
1E-2 ... why? Imagine you need it to output to some file - e.g.I 
do some money conversions .... 1E-2 imported into some DB is really 
not helpfull. So I wrote form-decimal function myself, but it is 
weird anyway ....

Pekr  that 1E-2 is a windows areifact , sure it should be fixed to 
be sane but the right place to fix it is the OS

0.001347 result of computation produces 1.347E-3 ..... now how to 
EASILY get it back to full format?

Tomc - are you sure about it?

solaris stares with expontal notation at E-5

it does not wound like a windows problem, have you tried the calculator 
? :-)

Btw - I know Ladislav and others worked on proper rounding. Carl 
also mentioned, BCD will be replaced by some other solution provided 
hopefully by Ladislav, but I would like to know, what is Rebol's 
precision with decimals anyway ..... write some longer one into console 
and it gets stripped down (rounded) - is that the limitation of architecture 
of OS/CPU, or?

that will mostly be IEEE floating point definition

I did not find an easier way, so I parse for E, then I distinguish 
the sign, the number -5 in above case, and then I compose the string 
:-)

Maybe there is some nice and elegant solution via dunno what - debase/base 
or some other conversions, or struct, dunno - I am not really expert 
here :-)

numbers on linux look more sane, so i guess its the os (or Carl hates 
windows?!;). althought it should not be to hard to take code from 
bsd-lib. math is ieee AFAIK.

I know carl deivated a little bit from the IEEE spec in the past 
to make things a little more neewbie friendly

no the same will happen with perl on windows

did you think that the internal type conversion may be the reason 
?

what would you think about something like "###.##e##".

they call the same underlying math libs

Volker - what is that? :-)

AFAIK he derived by comparisions, not the math itself?

hmmm propagating bad design

well it would be the display routines that are mangling not the math

#
 is a digit, gives numbers like 123.45e67

I know Volker, but what with that? Kind of templating/masking? Or 
what do you mean?

how about using that for a pad-function?

if BCD was decided to be replaced by other solution, maybe we should 
ask Ladislav to comment a bit what will happen in that regard?

hmm, i see its a path. so [pad n ###.##] would work without quotes 
:)

its path -> is issue

maybe it should be a dialect

there  is front middle and bacl padding

pad list [","]

for a comma seperated list

Pekr: "I did not find an easier way, so I parse for E, then I distinguish 
the sign, the number -5 in above case, and then I compose the string 
:-)"
!> a: 123.456 reduce[to integer! a remainder a 1]
== [123 0.456000000000003]

Maybe the base for something better (dont know how easy that parsing 
is?)

dunno ... you simply has some computation, it returns the result 
... and result may be something like 1 / 100, and you suddenly end-up 
with 1E-2, now what to do with that?

split in integer and fraction, pad integer, do something with fraction, 
join them.

fraction could be rounded, then copy/part.

Petr: <I wrote generalised solution in the past.>
Is that published?

Eric Long also did some nice work on a format.r function....I'm trying 
to find out if it is still available to the public (I have a copy 
of it)

I have my own function currently for that, it is just I dont find 
1E-2 really usefully for anything, or just maybe form should be tweaked 
to form decimals in their full representation ...

http://www.nwlink.com/~ecotope1/index.r?

ncie, rebol indexes our index.r's :) and word-browser was great to 
find "remainder".

short enough? http://polly.rebol.it/test/test/snippets/epad1.r

Looks good, Volker.
One problem: more than 9 leading zeroes:
 epad1 0 10 0
** Math Error: Math or number overflow

(There is a much larger limit on trailing zeroes after the decimal 
sign)

tricky. hmm, money should have a bigger scope?

Nine *should* be enough for most people -- I didn't have a specific 
case in mind. I was just testing the limits.

testing is good :)

Yep, money is worth its -erm, punning here.. adds more digits. (uploaded)

14 leading zeroes is probably enough for anyone :-)
One bug?
 epad1 0.09 1 2
== "0.90"   ;; 10 times too large!