World: r3wp

>> mold/all 0.1
== "0.1"

the whole point of MOLD and SAVE is to be a pretty-printer

 - looks true for MOLD, but SAVE does not print, so this does not 
 apply in any reasonable sense

Well, that's the SAVE should be symmetric to MOLD argument. It's 
a fair point; just one I personally disagree with.

MOLD doesn't priint either. Very few pretty-printers print. It's 
a jargon term.

For that matter, PRINT doesn't really print either :)

btw, we are not really here

As I said, I can actually live with it, but, what I am unable to 
live with is, that this gotcha is nowhere documented, and it is a 
gotcha par excellence, as demonstrated

Andreas, which platform are you using? That is a serious platform-specific 
bug you are demonstrating there, and should be reported.

Linux

Brian, I would correct this "bug", if I were able to

I'll check CureCode to see if the bug is already there.

the problem is, that Microsoft does not allow me to do what I want 
in Windows

Btw, I consider my implementation to be far more correct than yours.

No need to put it to CC, the code that generates the string was written 
by me (both for Linux and for Windows), and I did my best

Linux yields a "better value", since I had more freedom in coding 
the conversion

0.10000000000000001 is not discernible from 0.1 in double precision 
IEEE754. 0.10000000000000002 is, though.

The behavior as designed in R3 is this:
>> mold 0.1
== "0.1"
>> mold/all 0.1
== "0.10000000000000001"

This is because 0.1 is not directly representable in a IEEE754 value. 
If it does not work this way on a platform, then the platform code 
is broken. And you, Ladislav, were the one who made the rule in the 
first place.

If that is intended behaviour for R3, then R3 is broken (or designed 
to use single-precision floating point).

Wow, that'"s a direct attack :-)

Well, I take that back.

Neither 0.10000000000000001, nor  0.1 violate IEEE754 norm

(as Andreas found out)

Andreas, it is the latter. The decimal! type is designed to use single-precision 
floating point. And that behavior is in the standard (according to 
Ladislav, the last time this discussion came up a year ago or so). 
I told you the decimal! type was misnamed.

0.1 and 0.10000000000000001 are represented differently in single-precision 
IEEE754.

Well, forget it.

You mean double precision, I suppose?

I am mainly about how to regain a decimal representation from IEEE754 
encoding.

(i.e. 64-bit)?

Or double, whatever. But the current behavior was argued for by Ladislav, 
and is consistent with all other IEEE754 implementations, according 
to the standard. Ladislav, if that behavior doesn't match what the 
standard says, and what you requested, then it needs reporting.

Or we can reopen your ticket.

It matches the standard

Brian, have you read IEEE754 or are you otherwise intimately familiar 
with it?

But more directly: _both_ behaviours match the standard.

The standard is, that every result shall be rounded "to the nearest 
representable number"

And, "the nearest representable number" to 0.1 and 0.10000000000000001 
is the same

Which matches the standard? Andreas's demonstrated behavior on Linux, 
or mine on Windows? Because they need to behave exactly the same. 
If they don't, one of the platforms has a platform-specific bug. 
Pick one.

Depends on what you consider the nearest representable number to 
be :)

And what FP precision you use in the process.

0.1 is 3DCCCCCD in single-precision, which is 9.9999994e-2 when converted 
to decimal representation without rounding.

Representable numbers
 are described in http://www.rebol.net/wiki/Decimals-64

http://www.rebol.net/wiki/Decimals-64#IEEE_754_Standard

I don't consider anything. Ladislav read the standards, and as an 
expert he set the rules. I am refering to what he said when he did 
so, and my experience with other languages that use IEEE754. The 
behavior needs to be exactly consistent on Windows and Linux. If 
they don't match, one of them is wrong. Pick one.

When using double precision, the current Windows behaviour is wrong. 
For now, this is just my opinion, as I seem to remember round-to-nearest 
is a single precision thing, but I'll have to re-read the standard 
for that.

And this is not a matter of Linux's or Windows' behavior, it is a 
matter of REBOL's behavior.

the behaviour of the current implementation of REBOL 3 for Windows
 -- satisfied?

No. MOLD is not supposed to be a platform-specific function. All 
platform-specific behavior is a bug.

Well, Linux is better, and I *could* get the same behaviour if using 
gcc in Windows, but not if using microsoft compiler...

So, OK, it is a bug of MS compiler, which I cannot work-around in 
any reasonable way

Brian: do you in fact read what I write? Or just single our words 
to pick on?

When using double precision, the behaviour of the current implementation 
of REBOL 3 for Windows is wrong.
 -- Do I imply anywhere in this sentence that this is not a bug?