a==b "true" but a=b "false"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

a==b "true" but a=b "false"

Chris Muller-4
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?

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Dale Henrichs-3
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?

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?




Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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?
>
>

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Bert Freudenberg
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
Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Eliot Miranda-2
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?

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?

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


Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Bert Freudenberg
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
Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Chris Muller-3
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!

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Chris Muller-3
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Chris Muller-3
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.

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

Andres Valloud-4
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: a==b "true" but a=b "false"

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



On Wed, Sep 3, 2014 at 4:11 PM, 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.

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?

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



    

--

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