World: r3wp

How RETURN works in R2

let's define the following function:

g: func [f [any-function!]] [f [return 1] 2]

now we may test what happens for different argument functions we 
may supply:

>> g :do ; == 1
== 1
>> g func [blk] [do blk]
== 2
>> g func [[throw] blk] [do blk]
== 1

poll: do you find it acceptable that for some numbers load mold number 
is an error?

example ?

the maximal or minimal possible decimal! values cannot be load molded

(while they can be computed, if you know how)

(do you really want me to present a formula here?)

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.