World: r3wp

IMO it should be moldable

they are moldable, but you cannot load the result back

Are they valid values or not ?

they are valid

Then they should be loadable, shouldn't they ? There will inevitably 
be a case where they are needed in a program.

Are they molded differently somehow ?

OK, so they should be loadable too :)

every Decimal! is "molded differently" somehow, no decimal is "exactly 
molded", example: 0.1 is a decimal! , but because the decimal! values 
are IEEE754 binary floating point, 0.1 is represented as the nearest 
IEEE754 number, which is not 0.1, because IEEE754 cannot represent 
0.1 as you probably know

Oh, I see. So to make them loadable you would have to mold them with 
an identifier on the front, (eg.  0d0.1)

OK so minimal/maximal decimal! values can be molded as nearset loadable 
decimal! or not?

nearset=nearset

grr nearest :)

The problem is, that there is some "inaccuracy" involved and the 
inaccuracy is so high, that the molded maximum is higher than the 
IEEE754 maximum, i.e. it causes overflow

this means, that 0d0.1 does not help

That means the decimal! maximum needs to be pulled back to the highest 
value which does not cause a problem.

But I am still confused - how can it be: "decimal! values are IEEE754 
*binary* floating point"  ?  I thought decimal! where using decimal 
math ?

the solution is not that easy. The problem is, that if somebody gives 
a number that is higher than all representable numbers, the overflow 
*should* occur. so we may need higher accuracy instead

 I thought decimal! where using decimal math ?
 - my favourite example: 0.3 - 0.1 - 0.1 - 0.1

in decimal math the result is exactly zero as everybody knows

Of course, sorry - confused with deci!  ..... (Probably the first 
of many confusions...)

Let me read all that again...

Yes, makes sense now.

Ok, I suppose you asked this poll question because you are looking 
for a way for the highest decimal! to be load moldable and it looks 
difficult / problematic.

the problem lies in the accuracy - we would need at least 17 digits 
from mold to be able to load back

How many digits are molded now ?

15

Maybe MOLD can be more accurate, and FORM can be less accurate ?

The trouble is, that the 16-th and 17-th digits are a bit "nonsensical", 
but they are needed for this purpose

(and this exceptional behaviour can be only for this exceptional 
datatype ?)

yes

I'd rather have non-sensical digits than not quite orthogonal loading/molding.

I think you can't hide the quirks of the decimal!

right

Another idea is that both MOLD and FORM give 17 digits, and it is 
left to another function (perhaps a FORMAT mezz) to cut off the nonsensical 
digits.

Ladislav you are hitting the Serialization/Marshalling barrier. Having 
a language where there is no difference between serialized (molded 
in rebol terms) types and source code types is big plus of Rebol. 
But on the other hand it limits you when you want to marshall the 
data becuase of the assymetry introduce to maintain accuracy for 
some types like decimal.

Usually marshalled (molded) data from other languages like Objective-C, 
Smalltalk or Java is not et all readable as rebol. So this sepparation 
helps when dealing with representation issues at the cost of making 
difficult to change the binary enconding.

Is it ok to break the rule for deci!? Hmm. I'm not sure if this belongs 
to the domain of the language designer or the public opinion.

IMO non-loadable things should not be moldable. So in this case make 
limits on mold, so that the mold fails with such values. Reason: 
IMO under no circumstances should a save destroy values (at least 
not from the inbuild side). Better throw the last changes away with 
a "cant save, internal error" than overwrite valid data with broken 
one. Specially if rebol is a "public" format like xml, where everyone 
can send data and trigger a broken save.

Volker:the console has got a problem with non-moldable value (it 
tries to mold every result)

On further thought, I think the decision to use binary floating point 
numbers in one's program is a decision which includes the understanding 
that there will be some molding inaccuracies. Whether you try to 
print all the digits including the nonsensical final digits (which 
is inconvenient for most usage), or try to hide them (moving the 
problem to load/mold non-orthgonality), either way you must accept 
a problem.

Unfortunately, we currently don't have a non-binary alternative floating 
point type.

But that seems to me what we really want; to supplant decimal! with 
deci!  (Anyone disagree ?)

What I'm trying to say is: I would be happy for the current molding 
of decimal! to remain as it is, if I had a deci! type that I could 
use instead.

You have always inaccuracies in theory. In practice all have IEEE, 
but in theory its what the c-compiler uses. If some software-emulation 
thinks something else works faster, sending data there is anaccurate.

LAdislav: Fix the console. Or at least a check 'reloadable? , which 
as meazzine molds, loads and checks for equality, and without to 
much overhead.

Fix the console
 - how would you like it to be fixed?

Good question. First thought was: report error. Second thought an 
option to mold, mold/always, and console uses that.

default should be "better error than sorry" for 'save-related things 
IMHO, a dont-bother option would be ok.

I am very sensitive with save since people learn "save often" to 
keep their data, well, safe. Calling something "save" which breaks 
happily data was totally unexpected to me when i started (in the 
times when even a "}" in a string meant trouble, much bette rnow)

It's probably just me but what is the deal with command line arguments 
via system/script/args, I can't seem to get anything returned except 
none.