World: r3wp

Carl states, that time-zone precision was rised to 15 minutes. Is 
it any usefull? :-) http://www.rebol.net/r3blogs/0217.html

Any and all fixes to time would be good.

It helps us map to those few (but real) areas of the world whose 
timezone is +/-15 offset from a whole hour. That's useful to some!

Yeah, I'm not so much testing the actual random decimal function, 
but more the program logic of the implementation.

hi, renaming the EQUIVALENT? function to EQUIV? - Carl's wish

(the original name was probably too long)

anybody knowing how to rename the http://www.rebol.net/wiki/EQUIVALENT%3F_tests 
page?

OK, just found out how to do it, sorry for bothering

In CureCode ticket #870 Carl states: "Beginning in A68 PARSE/all 
is now the default when the rules are a block (not a simple string 
of delimiters). " - does it mean, that now parse is dependant upon 
the rules input? So when the input for rules is block, parse is switched 
to /all mode, while with string rule, it is not switched to /all? 
That will be confusing, no?

I would discard non /all mode completly ...

put it to R3 chat, Carl may honor your request

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 ....