Re: [Pharo-users] Hash collision

2016-12-19 Thread Martin McClure
On 12/19/2016 01:27 AM, Andres Valloud wrote: At first glance, that the failure code only sees "two" things when it should see "eight" seems to be problematic. Perhaps the primitive insists on hashing byte objects, and there is a distinction between "byte" objects and "word" objects (whatever

Re: [Pharo-users] Hash collision

2016-12-18 Thread Martin McClure
On 12/18/2016 02:29 AM, Andres Valloud wrote: The primitive and the primitive failure code should behave the same? You think the primitive is faulty? I haven't looked at the primitive code, but it just fails when given a Float. From the name, I'd guess that it's designed for a byte object.

Re: [Pharo-users] Hash collision

2016-12-18 Thread stepharong
Hi andres I did not follow the discussion. My remark is just that a good discussion without code for integration does not improve Pharo and we will have people facing again the problem. Stef On Sun, 18 Dec 2016 11:29:11 +0100, Andres Valloud wrote:

Re: [Pharo-users] Hash collision

2016-12-18 Thread Andres Valloud
The primitive and the primitive failure code should behave the same? On 12/18/16 2:13 , stepharong wrote: Sorry but how can we improve the situation concretely Stef On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud wrote: Oh, ok... then the failure code

Re: [Pharo-users] Hash collision

2016-12-18 Thread stepharong
Sorry but how can we improve the situation concretely Stef On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud wrote: Oh, ok... then the failure code isn't doing what was intended :). On 12/13/16 15:16 , Martin McClure wrote: On 12/13/2016 08:39 AM,

Re: [Pharo-users] Hash collision

2016-12-13 Thread Martin McClure
On 12/13/2016 08:39 AM, Andres Valloud wrote: > I would have expected the floats to be a byte object of size 8. Why is > this conversion needed? Is somehow the primitive thinking the float has > size 2? Or is the primitive hashing 32 bits at a time? The prim used > to be a C version of the

Re: [Pharo-users] Hash collision

2016-12-13 Thread Andres Valloud
On 12/10/16 10:36 , Martin McClure wrote: On 12/09/2016 09:45 AM, Ben Coman wrote: The suggested fix depended on being willing to let go of byte ordering (which we might not want different results on different platforms) Float>>hash ^ByteArray hashBytes: self startingWith: self

Re: [Pharo-users] Hash collision

2016-12-10 Thread Martin McClure
On 12/09/2016 09:45 AM, Ben Coman wrote: The suggested fix depended on being willing to let go of byte ordering (which we might not want different results on different platforms) Float>>hash ^ByteArray hashBytes: self startingWith: self species hash This fix contains a good idea,

Re: [Pharo-users] Hash collision

2016-12-09 Thread p...@highoctane.be
If you do not really care about performance because there are not that may geometric objects (say thousands), I guess that this would work (bit pattern as string). { 0.5 binaryLiteralString hash. -0.5 binaryLiteralString hash. } Phil On Fri, Dec 9, 2016 at 6:45 PM, Ben Coman

Re: [Pharo-users] Hash collision

2016-12-09 Thread Ben Coman
On Fri, Dec 9, 2016 at 10:51 PM, Hilaire wrote: > Hi, > > In Dr. Geo I rely a lot on hash value for the geometric object. It > largely improves speed up to compare geometric items (to avoid > duplicated items). For example to detect when the user is building an > already

[Pharo-users] Hash collision

2016-12-09 Thread Hilaire
Hi, In Dr. Geo I rely a lot on hash value for the geometric object. It largely improves speed up to compare geometric items (to avoid duplicated items). For example to detect when the user is building an already created object. Also when describing geometric sketch with Smalltalk code, hundred