[vwnc] About Double hash

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

[vwnc] About Double hash

Nicolas Cellier-3

In VW7.6 tiny Double won't hash that good:

(((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)])
        collect: [:e | e hash]) asSet

This is because each and every tiny Double canBeConvertedToFloat, but is
converted to 0.0e0.

A lot of hash clashes...

Nicolas

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

Andres Valloud-6
Nicolas,

Ah yes.  This is because when aDouble asFloat = aFloat, then aDouble
hash becomes aDouble asFloat hash (mod the details).

In my personal opinion one should not necessarily have to expect that

aDouble = aFloat

on the grounds that they represent the results of calculations with
varying degrees of accuracy, which are themselves subject to an
assortment of rules that make comparison via equality intention
obscuring.  If equality could be relaxed (or made more strict depending
on the POV) so that aDouble = aFloat always answered false, then it
would be straightforward to enhance Double>>hash to take all of the
bytes into account.

Nevertheless, and personal opinions aside, either changing = so it's
more strict, or changing hash without changing = on the grounds that =
is not well defined and thus hash cannot possibly be well defined
either, is a change we thought to be independent of the issue of hash
quality in general.  Thus, the behavior you see is consistent with the
behavior of VW 7.5 and earlier.

Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of nicolas cellier
Sent: Thursday, June 26, 2008 4:28 PM
To: [hidden email]
Subject: [vwnc] About Double hash


In VW7.6 tiny Double won't hash that good:

(((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)])
        collect: [:e | e hash]) asSet

This is because each and every tiny Double canBeConvertedToFloat, but is
converted to 0.0e0.

A lot of hash clashes...

Nicolas

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

Nicolas Cellier-3
Valloud, Andres a écrit :
> Nicolas,
>
> Ah yes.  This is because when aDouble asFloat = aFloat, then aDouble
> hash becomes aDouble asFloat hash (mod the details).
>

Hello Andres,

No, it does not imply changing equality for this case, because all is
converted to Double, equal would answer false:

| eps |
eps := 1.0d timesTwoPower: -52.
1.0d + eps = 1.0e. "-> false"
(1.0d + eps) asFloat = 1.0e. "-> false"

Same for tiny Double:

| eps |
eps := 1.0d timesTwoPower: -100.
(eps)  = 0.0e.
(eps) asFloat = 0.0e.

So the hash codes need not to be equal.
It's the hashing strategy that is too simplistic and has a problem.
You would have to change canBeConvertedToFloat or use another message.


> In my personal opinion one should not necessarily have to expect that
>
> aDouble = aFloat
>
> on the grounds that they represent the results of calculations with
> varying degrees of accuracy, which are themselves subject to an
> assortment of rules that make comparison via equality intention
> obscuring.  If equality could be relaxed (or made more strict depending
> on the POV) so that aDouble = aFloat always answered false, then it
> would be straightforward to enhance Double>>hash to take all of the
> bytes into account.
>

Changing equality however would not be a bad thing.

I know you are in favor of strict interpretation of inexact arithmetic:
- if arithmetic is inexact then we cannot assert equality, so the answer
should always be false when asked to an inexact

You know i'm in favour of a less strict rule:
- let equality answer true when no inexact operation takes place during
conversion (no matter inexactness of previous computations)
(See SYSBUG-FloatComparison on public store; unfortunately, i cannot
change = primitives)

Both strategies above are acceptable in Scheme implementation.

One thing we both agree is that an equality due to inexact conversions
should NEVER answer true.

Answering true is of no use and causes a bunch more problems than it
apparently solves (I would say BUGS). It's important to have sane
foundations in the kernel.

Some people more clever than us did avoid building on sand,
see http://www.lispworks.com/documentation/lcl50/aug/aug-170.html

We just HAVE to follow that path.


> Nevertheless, and personal opinions aside, either changing = so it's
> more strict, or changing hash without changing = on the grounds that =
> is not well defined and thus hash cannot possibly be well defined
> either, is a change we thought to be independent of the issue of hash
> quality in general.  Thus, the behavior you see is consistent with the
> behavior of VW 7.5 and earlier.
>

Again no, it is not necessary, these Object don't answer true to =.
Concerning compatibility, throw it away, or provide a backward
compatibility VM or an image level workaround if you are really asked
for it. I doubt it.

Nicolas

> Andres.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of nicolas cellier
> Sent: Thursday, June 26, 2008 4:28 PM
> To: [hidden email]
> Subject: [vwnc] About Double hash
>
>
> In VW7.6 tiny Double won't hash that good:
>
> (((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)])
> collect: [:e | e hash]) asSet
>
> This is because each and every tiny Double canBeConvertedToFloat, but is
> converted to 0.0e0.
>
> A lot of hash clashes...
>
> Nicolas
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

Nicolas Cellier-3
nicolas cellier a écrit :

> | eps |
> eps := 1.0d timesTwoPower: -52.
> 1.0d + eps = 1.0e. "-> false"
> (1.0d + eps) asFloat = 1.0e. "-> false"
>

Yes second answer was true of course, i messed with copy/paste again

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

Andres Valloud-3
In reply to this post by Nicolas Cellier-3
Nicolas,

> So the hash codes need not to be equal.
> It's the hashing strategy that is too simplistic and has a problem.
> You would have to change canBeConvertedToFloat or use another message.
>  

Well... let's say it is not what I would have preferred to do if I had
been given the task to make a choice.

> Changing equality however would not be a bad thing.
>
> I know you are in favor of strict interpretation of inexact arithmetic:
> - if arithmetic is inexact then we cannot assert equality, so the answer
> should always be false when asked to an inexact
>
> You know i'm in favour of a less strict rule:
> - let equality answer true when no inexact operation takes place during
> conversion (no matter inexactness of previous computations)
> (See SYSBUG-FloatComparison on public store; unfortunately, i cannot
> change = primitives)
>  

I meant the following.

aFloat asDouble = aDouble => "true"
theSameFloatAsAbove = theSameDoubleAsAbove "true, iif the values are
exactly the same"
"otherwise, false"

So you can have equality in the cases where it is asked for, but since
it's meaning is (for the most part) undefined for a whole lot of other
cases, then a = b => a hash = b hash can be allowed to fail on the
grounds that a = b is poorly defined.

But then again, that's just my personal opinion, and not necessarily the
design principles by which VW abides now.

> Again no, it is not necessary, these Object don't answer true to =.
> Concerning compatibility, throw it away, or provide a backward
> compatibility VM or an image level workaround if you are really asked
> for it. I doubt it.
>
>  

Maybe so.  As it turns out I have an AR regarding the hash of
SmallDouble... perhaps I could take a second look at this.

Perhaps.  Maybe.  Depending on circumstances.  No warranties.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

John Brant-2
In reply to this post by Nicolas Cellier-3
nicolas cellier wrote:
> nicolas cellier a écrit :
>
>> | eps |
>> eps := 1.0d timesTwoPower: -52.
>> 1.0d + eps = 1.0e. "-> false"
>> (1.0d + eps) asFloat = 1.0e. "-> false"
>>
>
> Yes second answer was true of course, i messed with copy/paste again

Things are worse:

a := 1 + (2 raisedTo: -52).
b := 1.0d + (2.0d raisedTo: -52).
c := 1.0e.
a = b "-> true"
a = c "-> true"
b = c "-> false"

#= is not transitive.


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] About Double hash

Nicolas Cellier-3
John Brant a écrit :

> nicolas cellier wrote:
>> nicolas cellier a écrit :
>>
>>> | eps |
>>> eps := 1.0d timesTwoPower: -52.
>>> 1.0d + eps = 1.0e. "-> false"
>>> (1.0d + eps) asFloat = 1.0e. "-> false"
>>>
>> Yes second answer was true of course, i messed with copy/paste again
>
> Things are worse:
>
> a := 1 + (2 raisedTo: -52).
> b := 1.0d + (2.0d raisedTo: -52).
> c := 1.0e.
> a = b "-> true"
> a = c "-> true"
> b = c "-> false"
>
> #= is not transitive.
>
>
> John Brant

Thank you very much for this support!

Cheers


http://bugs.squeak.org/view.php?id=3374
http://www.cincomsmalltalk.com/publicRepository/SYSBUG-FloatComparison.html
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/59287ffa46b28a5a/b6a6e19f5975d098?lnk=gst&q=equality+is+not&rnum=1&fwc=2
http://groups.google.fr/group/ibm.software.vasmalltalk/browse_thread/thread/b7fd34b1cec51547/f328121f29635a1e?hl=fr&lnk=st&q=#f328121f29635a1e
http://groups.google.fr/group/comp.lang.smalltalk.dolphin/browse_thread/thread/9e23918508c9c12e/d0676ec0361a7f80?hl=fr&lnk=st&q=#d0676ec0361a7f80
http://bugs.exept.de/show_bug.cgi?id=391

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc