Open Siskin-Bot opened 4 years ago
@ladislav should this be implemented as natives? Or just make equal?
working internally like the prototype?
And isn't the current code good enough? https://github.com/Oldes/Rebol3/blob/22b8224e58b2c1ef4c7a2c878fc321772fd4c727/src/core/t-decimal.c#L95-L116
I think that the sorting issue may be demonstrated on:
>> sort [1 9007199254740992 9007199254740993 9007199254740992.0 9007199254740993.0]
== [1 9007199254740992 9007199254740993 9.00719925474099e15 9.00719925474099e15]
>> sort reverse [1 9007199254740992 9007199254740993 9007199254740992.0 9007199254740993.0]
== [1 9.00719925474099e15 9.00719925474099e15 9007199254740992 9007199254740993]
Useful reading on the topic: https://codewords.recurse.com/issues/one/when-is-equality-transitive-and-other-floating-point-curiosities
Submitted by: Ladislav
This may be a surprising finding for some people, but here are the arguments why non-transitive
equal?
leads to trouble:lesser-or-equal?
should be transitive for it to be a linear order on decimals. If it weren't transitive, sorting algorithms would not work correctly using it. (To see why nontransitivity is a problem, check #2251 and #2218.)greater-or-equal?
should be transitive for it to be a linear order on decimals. If it weren't transitive, existing sorting algorithms would not work correctly using it. (The same reason as above.)equal?
should be equivalent to the logical conjunction oflesser-or-equal?
andgreater-or-equal?
. (See #2256), and, since both should be transitive, their conjuction should be transitive as well.Imported from: https://github.com/rebol/rebol-issues/issues/2259
Comments: