World: r3wp

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 :)

That is good to hear :-) Was there any resolution to various make 
methods? Will we be able to precisely decide, what gets copied and 
what gets referenced?

That is still pending, but the discussion about that reached a consensus, 
so it will come after we finish up the equality changes.

re tuple....

....I thought it technically was  not a bug. Just a surprise that 
is explicable when you remember that tuples are padded with zeroes 
for equality tests:
    1.0.0 = 1.0.0.0
    == true
     (length? 1.0.0) = length? 1.0.0.0
    == false

It turns out that the length of a tuple is set at tuple creation 
time, and that length affects LENGTH? and PICK, which are called 
by LAST.

It was technically not either a bug or a feature - it was a side 
effect that had not been discussed. The bug ticket will start the 
discussion

The amount of space a tuple takes is fixed, as are the trailing zeros. 
The "length" is just a number.

The result of all of these discussions is that R3 is going to be 
much more rigorously thought through and consistent than R2. The 
little improvements are going to be the ones with the greatest impact 
in the long run.