World: r3wp

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?

I read it. I was saying that *as a hard rule* platform-specific behavior 
is reserved for only a few functions in R3. For other functions it 
is a bug. I'm not satisfied until that bug is at least reported. 
Am I clear now?

Feel free to report it.

Nobody will correct it, though, since it is generated by the MS compiler

Andreas, I am not qualified to do so. I haven't read the standard, 
don't know the code involved, and don't run Linux.

Ladislav, why can't you write your own formatter, or use a consistent 
third-party one? At least when you detect a known error during config?

Brian, you are perfectly qualified. mold/all 0.1 on Windows differs 
from mold/all 0.1 on Linux. If you are only satisfied when this is 
reported as bug, feel free to report it.

But I can't say which is the buggy one.

Ladislav, why can't you write your own formatter
 - I can do so in GCC, but not in MS C, sorry

Brian, you don't have to.

(unsupported)

Report the observed difference and the expectation that this should 
not differ. The rest is up to whoever feels qualified to contribute 
more detailed observations and/or implementing a fix.

Andreas, sorry, CureCode doesn't let you report a platform-specific 
bug without specifying the platform. I can't just say "it's not consistent" 
without it being a useless bug report. We need a report from a person 
who is qualified to make an expert decision.

At the very least, it means that any report I make would have to 
be rewritten (or comments to the same effect) by Ladislav, or someone 
equivalently qualified.

I can admit it is a bug, by I cannot really correct it in MS C without 
"too much expense"

http://www.curecode.org/rebol3/ticket.rsp?id=1633

See, that was not so hard to report, was it?

Just like I have to rewrite all of the bug reports about R3's module 
system before they can be useful. It sucks, but we need an expert.

Now it is in the system, on those more knowledgeable on the matter 
can refine it.

Ladislav?

What do you mean by "too much expense"?

Well, sure, it is a report, but, as I said, I am not going to correct 
it (would be too expensive)

That's not a problem. If it is not possible to fix, Carl or someone 
else can decide that this behaviour is ok and mark it as won't fix.

To implement my own formatter, MS disallows me to use the best datatype 
for it

So, I have to use their formatting function, which produces this 
result

Please put that in a comment of bug#1633 - it might help justify 
not using MS's compiler.

Ladislav, I would like to see how you write that formatter under 
GCC, Is that too much code that you can't show it us ?

If so, forget it

Hmm, I should not do it, I suppose.

But, the principle is quite simple: multiply the number by a "suitable" 
power of 10 and convert the result to integer. The trouble is, that 
you need to use a high precision multiplication and power.

(which is unsupported in MS compiler)

You mean, you don't do it using an incremental way, each digit separatly 
?