World: r3wp

posted to R3/Parse thread on R3 Chat ...

I suppose the name change was inevitible given that noone could come 
up with a decent operator to associate with the function. Hopefully 
people will expand the name to "equivalent" in their heads and it 
will have the same psychological effect - the length of the word 
was the reason for its choice in the first place.

Is this decimal problem also found in latest release? (I'm currently 
using older OS X version.)


>> (to-decimal #{3fef ffff ffff ffff}) < to-decimal #{3ff0 0000 0000 
0000}
== false

It's also a problem in sort:

>> sort [1.0 0.9999999999999998]
== [1.0 0.9999999999999998]

The first one is the same in A68

The second one is:

>> sort [1.0 0.9999999999999998]
== [1.0 1.0]

What about

sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]

[1.0 1.0]

Try upping system/options/decimal-digits to 17.

noting that default is 15.

And the number of digits in your example is 16.

Setting it to 17 gives same wrong result here.

With 17:

>> sort [1.0 0.9999999999999998]
== [0.99999999999999978 1.0]

And what if you do:

sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]

>> sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]
== [0.99999999999999989 1.0]

>> sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]
== [0.99999999999999989 1.0]

And setting it to 17 and trying:


(to-decimal #{3fef ffff ffff ffff}) < to-decimal #{3ff0 0000 0000 
0000}

still false for that one

ok. Do you guys know, if there's a CureCode ticket about it?

If you use <= you get true. It could be within the margin of error.

I'm wondering, if it could have consequences in other functions/mezzanines.

The decimal-digits option is only used for display. All other comparisons 
use 15 digits.

I think, decimals should be treated as binary data and converted 
to integers, when doing comparison and the like.

Wait for the proposed equivalency function changes in the next version.

Like:


>> (to-integer  #{3fef ffff ffff ffff}) < to-integer #{3ff0 0000 
0000 0000}
== true

Having a margin of error is standard operating procedure for IEEE754 
floating point numbers, because anything over 15 digits are subject 
to rounding errors inherent in the encoding.

That is why the 15-digit default.

Maybe for equal, but I'm not sure with greater-than and less-than.

If you can't count on differences in the greater-than-15-digit range 
to be accurate, why should you consider them for comparisons?

Well, I see no reason, why this return false, no matter of precision:


(to-decimal #{3fef ffff ffff ffff}) < to-decimal #{3ff0 0000 0000 
0000}

But maybe I need to think about it some more.

It's like the decimal-digits have internal consequences, it shouldn't 
have.

For instance:
>> 0.3 < (0.1 + 0.1 + 0.1)
== false
>> 0.3 <= (0.1 + 0.1 + 0.1)
== true


Those values differ in the greater-than-15-digits range due to encoding 
errors.

Those encoding errors are inherent in the IEEE754 format. The standard 
way to work around this is to not consider differences in the past-15-digits 
range. This is the case for all sorts of systems.

If you want exact comparisons, use money! ot integer! - decimal! 
is not appropriate.

Or you can wait for the next version, and have EQUIV?, ==, !== and 
=? do 17-digit comparisons, and the rest do the 15-digit comparisons 
that make values like 0.1 work.

Maybe strict-lesser? is a needed function? ;-)

(I need to think about it some more.)

If you need to do exact comparisons with floating point numbers you 
need to use subtraction and comparison to 0.0 - it's the only way 
to be sure. Exact comparisons with floating point numbers have to 
take into account that the numbers themselves are not exact the vast 
majority of the time.

A little sameness oddity for Ladislav. Two identical tuples can have 
different last elements :-)
    >> (to-tuple "1") =  1.0.0
    == true
    >> (last to-tuple "1") = last 1.0.0
    == false

That's an error in TO tuple!.

hmm, also first second last give strange results. First works, but 
others don't ....

Having trouble parsing that sentence - code?

Don't understand ...

Nevermind, I got it. I'm writing the ticket now.

Carl asked me to ask, what is general opinion to my suggestion - 
to remove parse /all refinement altogether. Current proposal is to 
swith parse by default to /all mode for block rules, and to recent 
default behaviour for string rule. As for myself I don't mind compatibility, 
so I prefer removing /all refinement and switching pase internally 
to /all mode ....

I proposed an /ignore stuff option that would replace the old default 
behavior, and be more general. Then we could toss /all.

That tuple bug applies also to R2 ... will such bugs be fixed?

Not in R2, unless we can prove that code won't be broken. We have 
a lot of incompatible fixes of R2 problems in R3..

Submitted as bug#1069.

What do you think about current progress? Progress is imo great, 
but when do you think we will get to more strategic parts like Plugins, 
etc?

I think pretty soon. That got delayed because Ladislav and meijeru 
started being really thorough about reporting inconsistencies in 
the core semantics of the language, so we started working on resolving 
those in case any changes affect the rest of the system. For instance, 
the equality change includes changing the equality actions to natives, 
which changes the action list - that might affect plugins.

Removing binary! from any-string! definitely would affect plugins. 
It affected everything else - there's a lot less buggy code now :)