r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Andreas
14-Jul-2010
[17452]
And the argument is that a pair of functions with the names of LOAD 
and SAVE which pretty much cry *duality* is to be considered harmful 
if they willingly violate their implied duality.
Steeve
14-Jul-2010
[17453]
but you both use a different semantic to argue around your subject
BrianH
14-Jul-2010
[17454x2]
Taking the decimal! type as an example, the DED syntax (what LOAD 
can handle) can accept a wider range of decimals than can be represented 
in-memory. Those that can't be represented directly in memory are 
approximated. Since those approxiimations tend to happen in the 16th 
to 17th digits, they can be "undone" by ignoring those digits in 
the "friendly" output.
If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.
Andreas
14-Jul-2010
[17456]
This "unapproximation" is simply broken then.
BrianH
14-Jul-2010
[17457x2]
Yes, Andreas, that is what I have been saying.
But they are still useful, even if they are limited.
Andreas
14-Jul-2010
[17459]
They are not limited, they are broken.
Ladislav
14-Jul-2010
[17460]
Right, since it "unapproximates" all values, i.e. values, that aren't 
"approximated". Therefore, it either can be called a "broken unapproximation", 
or, more precisely, no unapproximation at all,since it actually is 
not "unapproximation"
BrianH
14-Jul-2010
[17461]
Reapproximation for MOLD, no approximation for MOLD/all, approximation 
depends on the digits for LOAD, at least for decimals.
Ladislav
14-Jul-2010
[17462]
Well, is that worh any discussion? The transformation clearly transforms 
values so, that after being transformed, additional error is introduced.
BrianH
14-Jul-2010
[17463x2]
Maxim, we can't extend the existing serialized form to represent 
everything in memory, because binding, cycles and DAGs aren't representable 
without some kind of reference index. So even rebin wouldn't do, 
we'd need something like RIF.
Ladislav, it was just an example to illustrate that the abstract 
REBOL that is accepted by LOAD doesn't exactly represent the real 
REBOL in memory. But it does represent enough to do source processing 
by a preprocessor.
Andreas
14-Jul-2010
[17465x3]
If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.
Ha, at least we got to the point. This opinion was all this discussion 
was originally about.
As a matter of fact, LOAD and SAVE/all form a far better duality 
as far as REBOL source is concerned. So Ladislav and I argued that 
making /all the default for SAVE would be a sensible thing to do.
BrianH
14-Jul-2010
[17468]
The problem with that is that opinions vary. This has been happening 
a lot lately. Just the other day, Sunanda claimed in CureCode that 
assignments were unsafe. I couldn't even answer a statement like 
that without it turning into a flame war.
Andreas
14-Jul-2010
[17469x2]
Sure, that's why we are discussing it at all. Besides getting mightily 
side-tracked in semantic debates that do mostly not pertain to this 
issue, to only argument against this suggestion I heard was that 
SAVE should behave symmetrically to MOLD, not dually to LOAD.
A nice result of this side-tracking is that I now consider mold completely 
broken for decimals, as it applies a hack that maybe once was appropriate 
for single precision floats, but certainly no longer is for double 
precision floats.
BrianH
14-Jul-2010
[17471]
SAVE and MOLD are explicitly designed to be newbie-friendly - that 
includes being able to have MOLD generate the value 0.1, which is 
not representable by the (misnamed) decimal! type in memory. And 
#[] syntax has been judged to not be newbie-friendly, or at least 
an ugly thing that only power users do. If you want to reverse that 
decision, fine, but it's unlikely.
Andreas
14-Jul-2010
[17472]
Once again, 0.1 is not the point here. That's the result of a flawed 
pretty-printer.
BrianH
14-Jul-2010
[17473]
>> mold/all 0.1
== "0.10000000000000001"

Many values that developers usually write out in decimal aren't representable 
in memory. Welcome to the wonders of IEEE754.
Andreas
14-Jul-2010
[17474x2]
Funny, what platform?
>> mold/all 0.1
== "0.1"
BrianH
14-Jul-2010
[17476]
Andreas, you are not getting that the whole point of MOLD and SAVE 
is to be a pretty-printer.
Ladislav
14-Jul-2010
[17477]
Windows
Andreas
14-Jul-2010
[17478]
What is FORM supposed to be then?
BrianH
14-Jul-2010
[17479]
A pretty-printer for users rather than developers.
Steeve
14-Jul-2010
[17480]
;-) Someone should start to write our chronicles. When I will be 
an old hag, I would be fun to read our old debates.
BrianH
14-Jul-2010
[17481]
Andreas, please use R3 when talking about MOLD/all for decimals - 
it's broken on R2.
Andreas
14-Jul-2010
[17482x2]
Fair enough. So your take is that LOAD/SAVE forms no duality because 
of MOLD is supposed to do "developer pretty printing" but for absolute 
newbie developers, not for developers familiar with e.g. #[] syntax.
>> mold/all 0.1
== "0.1"
Ladislav
14-Jul-2010
[17484]
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
Andreas
14-Jul-2010
[17485]
Well, that's the SAVE should be symmetric to MOLD argument. It's 
a fair point; just one I personally disagree with.
BrianH
14-Jul-2010
[17486x2]
MOLD doesn't priint either. Very few pretty-printers print. It's 
a jargon term.
For that matter, PRINT doesn't really print either :)
Steeve
14-Jul-2010
[17488]
btw, we are not really here
Ladislav
14-Jul-2010
[17489]
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
BrianH
14-Jul-2010
[17490]
Andreas, which platform are you using? That is a serious platform-specific 
bug you are demonstrating there, and should be reported.
Andreas
14-Jul-2010
[17491]
Linux
Ladislav
14-Jul-2010
[17492]
Brian, I would correct this "bug", if I were able to
BrianH
14-Jul-2010
[17493]
I'll check CureCode to see if the bug is already there.
Ladislav
14-Jul-2010
[17494]
the problem is, that Microsoft does not allow me to do what I want 
in Windows
Andreas
14-Jul-2010
[17495]
Btw, I consider my implementation to be far more correct than yours.
Ladislav
14-Jul-2010
[17496x2]
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
Andreas
14-Jul-2010
[17498]
0.10000000000000001 is not discernible from 0.1 in double precision 
IEEE754. 0.10000000000000002 is, though.
BrianH
14-Jul-2010
[17499]
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.
Andreas
14-Jul-2010
[17500]
If that is intended behaviour for R3, then R3 is broken (or designed 
to use single-precision floating point).
Steeve
14-Jul-2010
[17501]
Wow, that'"s a direct attack :-)