World: r3wp

but... not if d is fixed. (and of course n must be less than 10 ** 
d)

I guess it's whether one wishes to write a generalised solution, 
or one to solve the problem at hand.

yep... in the case at hand it's a very good solution

though a printf type of solution would be handy :)

we need the format function... people should bug Carl about it... 
:)

Graham  I think it is a slick solution to the question asked

Gabriele -- Is 'format something Carl has hinted RT have in development?
Otherwise, no reason it couldn't be a small community exercise...

it's not in development, but it has been on the list for ages.

of course it can be done in REBOL, but i think it should be native. 
also, i'm pretty sure carl has ideas about how the dialect should 
look like.

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