When could it happen?
A: With Float nan. Float nan == Float nan "true" Float nan = Float nan "false" It violates what I have long considered an invariant that if a==b, then a=b. Real world context: When two DB clients change the same object in the exact same way, it's not a conflict. If they change it differently, it is. They've both made the same reference to Float nan, but just asking if they made equivalent changes still reports false. So I have to put in a complicated special check for NaN first..?? Okay, I actually wrote: (a==b or: [a=b]) but who would ever write that or not "simplify it" in teh future if they saw it? Comments? Why shouldn't Float nan = Float nan? |
Chris, IIRC, by definition a NAN is not equal to itself... Dale On Wed, Sep 3, 2014 at 4:11 PM, Chris Muller <[hidden email]> wrote: When could it happen? |
In reply to this post by Chris Muller-4
IEEE-754 requires NaN != NaN.
On 9/3/14 16:11 , Chris Muller wrote: > When could it happen? > > A: With Float nan. > > Float nan == Float nan "true" > > Float nan = Float nan "false" > > It violates what I have long considered an invariant that if a==b, then a=b. > > Real world context: When two DB clients change the same object in the > exact same way, it's not a conflict. If they change it differently, > it is. > > They've both made the same reference to Float nan, but just asking if > they made equivalent changes still reports false. So I have to put in > a complicated special check for NaN first..?? > > Okay, I actually wrote: (a==b or: [a=b]) but who would ever write > that or not "simplify it" in teh future if they saw it? > > Comments? Why shouldn't Float nan = Float nan? > > |
In reply to this post by Chris Muller-4
On 04.09.2014, at 01:11, Chris Muller <[hidden email]> wrote:
> When could it happen? > > A: With Float nan. > > Float nan == Float nan "true" > > Float nan = Float nan "false" > > It violates what I have long considered an invariant that if a==b, then a=b. Yep. We might want to fix that. > Real world context: When two DB clients change the same object in the > exact same way, it's not a conflict. If they change it differently, > it is. > > They've both made the same reference to Float nan, but just asking if > they made equivalent changes still reports false. So I have to put in > a complicated special check for NaN first..?? If you want your code to work in old or current images, yes. > Okay, I actually wrote: (a==b or: [a=b]) but who would ever write > that or not "simplify it" in teh future if they saw it? Put a comment on it ;) > Comments? Why shouldn't Float nan = Float nan? As the others wrote, that's defined in the IEEE standard. We cannot change that. But we could change it so that Float nan ~~ Float nan simply by returning a clone in #nan. There should be no downside to that. Except it breaks your test. You would still need to rewrite your test as a = b or: [a isNaN = b isNaN] because NaN is special. And if you do that, then the change is not necessary. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Chris Muller-4
On Wed, Sep 3, 2014 at 4:11 PM, Chris Muller <[hidden email]> wrote: -- When could it happen? Because non-a-numbers result from overflowing or underflowing computations, and hence, just because two computations produce the same not-a-number doesn't imply that the two computations are equivalent. This is why the IEEE-754 standard requires that NaN != NaN.
best, Eliot
|
In reply to this post by Bert Freudenberg
>> A: With Float nan.
>> >> Float nan == Float nan "true" >> >> Float nan = Float nan "false" >> >> It violates what I have long considered an invariant that if a==b, then a=b. > > Yep. We might want to fix that. I'm curious now. Where did that long considered invariant come from? I also know of a real application that defined, quite on purpose, SomeDomainObject>>= anObject ^false Andres. |
In reply to this post by Eliot Miranda-2
> Because non-a-numbers result from overflowing or underflowing
> computations, and hence, just because two computations produce the same > not-a-number doesn't imply that the two computations are equivalent. > This is why the IEEE-754 standard requires that NaN != NaN. Merely to expand on the subject, and notwithstanding the above... This property of NaNs allows you to identify them quickly. Unlike other entities such as +/- INF, you can test for a NaN with something like x = x ifFalse: ["then x is a NaN"] Keep in mind that, also unlike +/- INF, there is a multitude of binary representations for NaN. So, you can't necessarily do something like x as64BitInteger = nanExpressedAs64BitInteger because it will most likely fail. Andres. |
In reply to this post by Bert Freudenberg
On 04.09.2014, at 11:30, Bert Freudenberg <[hidden email]> wrote:
> a = b or: [a isNaN = b isNaN] I meant, of course, this: a = b or: [a isNaN and: [b isNaN]] And if you do it like that than there is no need for identity checks in any case. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Andres Valloud-4
On Thu, Sep 4, 2014 at 2:39 PM, Andres Valloud
<[hidden email]> wrote: >>> A: With Float nan. >>> >>> Float nan == Float nan "true" >>> >>> Float nan = Float nan "false" >>> >>> It violates what I have long considered an invariant that if a==b, then >>> a=b. >> >> >> Yep. We might want to fix that. > > > I'm curious now. Where did that long considered invariant come from? I It comes from a normal sense that an object is "equivalent" to itself. > also know of a real application that defined, quite on purpose, > > SomeDomainObject>>= anObject > > ^false Well, I'm curious about the contexts. What app considered an object not equal to itself on purpose? I get Eliots statement that, given all the different possible origins of NaN, assuming equivalency is assuming too much. But that's a purists view; I think NaN, more generically, means, "could not be calculated", and therefore, in terms of the vision any given system has on a model, it's practical to TREAT the stuff outside its scope equivalently. We even do it as humans. What is outside the scope of our awareness is "equivalent" in terms of how we deal with it, even though it isn't. "Awareness". This seems to be getting philosophical! |
On 9/4/14 16:00 , Chris Muller wrote:
> On Thu, Sep 4, 2014 at 2:39 PM, Andres Valloud > <[hidden email]> wrote: >>>> A: With Float nan. >>>> >>>> Float nan == Float nan "true" >>>> >>>> Float nan = Float nan "false" >>>> >>>> It violates what I have long considered an invariant that if a==b, then >>>> a=b. >>> >>> >>> Yep. We might want to fix that. >> >> >> I'm curious now. Where did that long considered invariant come from? I > > It comes from a normal sense that an object is "equivalent" to itself. I think the underlying issue is that "equivalent" means different things in different contexts. The poor #= message, being only one, cannot cope with complying with multiple conflicting points of view. > I get Eliots statement that, given all the different possible origins > of NaN, assuming equivalency is assuming too much. But that's a > purists view Well, hang on, because this comes down to one of the subtle issues we end dealing with all the time. In short: we tend to reinterpret others' ideas to our liking. The issue is that in doing so we might develop our own brand of IEEE-754 which is then incompatible with the IEEE-754 understanding of everyone following the standard to the letter --- including the implementation of modern FPUs. I'm not saying I like every single little thing in IEEE-754. However, compliance gives me compatibility, portability, the ability to read Knuth without having to redo his work according to my private interpretation of IEEE-754, etc. It's a compromise: in exchange for restraining oneself, one can take advantage of the work of others. >> also know of a real application that defined, quite on purpose, >> >> SomeDomainObject>>= anObject >> >> ^false > > Well, I'm curious about the contexts. What app considered an object > not equal to itself on purpose? Hmmm. I only remember the details vaguely. It had something to do with a GUI display. I also remember being shocked by what at first seemed like a horrible hack. But, after spending a couple hours on it, I realized that accomplishing the same desired behavior in some other way would have been way, way more onerous. I suspect it had to do with the issue of "equivalence" meaning different things at different times. Maybe I'd look at it today and figure out something better. At the time, I let that hack live. To me, this brings back the issue that once you instantiate a class, it's difficult to recast the identity of the instance from a different point of view. Multiple inheritance doesn't quite work. Polymorphism is more practical, yet somehow incomplete. Andres. |
>> I get Eliots statement that, given all the different possible origins
>> of NaN, assuming equivalency is assuming too much. But that's a >> purists view > > Well, hang on, because this comes down to one of the subtle issues we end > dealing with all the time. In short: we tend to reinterpret others' ideas > to our liking. The issue is that in doing so we might develop our own brand > of IEEE-754 which is then incompatible with the IEEE-754 understanding of > everyone following the standard to the letter --- including the > implementation of modern FPUs. > > I'm not saying I like every single little thing in IEEE-754. However, > compliance gives me compatibility, portability, the ability to read Knuth > without having to redo his work according to my private interpretation of > IEEE-754, etc. It's a compromise: in exchange for restraining oneself, one > can take advantage of the work of others. Oh, absolutely yes. I hope I did not give anyone the idea I actually want to DO anything about this. Not at all. It was just the == but not = "violation" that caught my interest enough to poke out an email to y'all. This is way too low-level to change (and my image immediately locked when I tried :), and way too fraught with unknown consequences, not to mention non-standard and non-compliant in a critical part of the system. I like Berts solution because its explicit enough to not need a comment, but for my situation would require an additional type-check, since it can be any object going through there, not just Numbers. So, for now, I just went with the efficient "a==b or: [a=b]" solution and put a comment on it. - Chris |
In reply to this post by Chris Muller-3
On 9/4/14 16:00 , Chris Muller wrote:
> I get Eliots statement that, given all the different possible origins > of NaN, assuming equivalency is assuming too much. But that's a > purists view; I think NaN, more generically, means, "could not be > calculated", and therefore, in terms of the vision any given system > has on a model, it's practical to TREAT the stuff outside its scope > equivalently. All of a sudden I think I misunderstood what you meant. Are you saying it would be practical to treat all NaNs as equivalent, at least from a pragmatic point of view? Andres. |
On Thu, Sep 4, 2014 at 7:33 PM, Andres Valloud
<[hidden email]> wrote: > On 9/4/14 16:00 , Chris Muller wrote: >> >> I get Eliots statement that, given all the different possible origins >> of NaN, assuming equivalency is assuming too much. But that's a >> purists view; I think NaN, more generically, means, "could not be >> calculated", and therefore, in terms of the vision any given system >> has on a model, it's practical to TREAT the stuff outside its scope >> equivalently. > > > All of a sudden I think I misunderstood what you meant. Are you saying it > would be practical to treat all NaNs as equivalent, at least from a > pragmatic point of view? I think so. I know in pure science domains, we can't regard incalculables as equivalent. But when limited to strictly the bounds of a particular model, a software might simply want to "treat" all incalculables the same. We have explicit isNaN checking which is probably sufficient for most cases, but for a few "general object-level" cases like my commit-conflict check (on any type of object), the isNan check is easy to miss and makes the code slightly less elegant. |
Did you consider a message such as magmaEquals:, implemented in terms of
the usual equality test for most objects except for Float? On 9/4/14 18:00 , Chris Muller wrote: > On Thu, Sep 4, 2014 at 7:33 PM, Andres Valloud > <[hidden email]> wrote: >> On 9/4/14 16:00 , Chris Muller wrote: >>> >>> I get Eliots statement that, given all the different possible origins >>> of NaN, assuming equivalency is assuming too much. But that's a >>> purists view; I think NaN, more generically, means, "could not be >>> calculated", and therefore, in terms of the vision any given system >>> has on a model, it's practical to TREAT the stuff outside its scope >>> equivalently. >> >> >> All of a sudden I think I misunderstood what you meant. Are you saying it >> would be practical to treat all NaNs as equivalent, at least from a >> pragmatic point of view? > > I think so. I know in pure science domains, we can't regard > incalculables as equivalent. But when limited to strictly the bounds > of a particular model, a software might simply want to "treat" all > incalculables the same. We have explicit isNaN checking which is > probably sufficient for most cases, but for a few "general > object-level" cases like my commit-conflict check (on any type of > object), the isNan check is easy to miss and makes the code slightly > less elegant. > |
In reply to this post by Eliot Miranda-2
Old Fortran wisdom from the stone age:
never test Floats for equality A Float is an approximation; there are an infinite number of values that yield the same Float. Calculations with Floats are likely to introduce rounding errors. Always test Floats for equality within a tolerance. Float nan = Float nan is just one of the many tests that are meaningless in practical programming. Cheers --Trygve On 04.09.2014 21:33, Eliot Miranda
wrote:
--
Trygve Reenskaug mailto: [hidden email] Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27 |
Free forum by Nabble | Edit this page |