On Wed, Dec 24, 2014 at 9:38 AM, Levente Uzonyi <leves at elte.hu> wrote:
> I see many reasons why the difference is smaller:
> - you're also measuring the generation of the input
> - this creates new numbers and triggers GC more often
> - you're only benchmarking numbers between 0 and 1. #asIEEE32BitWord is a
> lot slower for negative values
> - you're using #bench, which has high overhead
> - you are comparing different versions than I did
>
> About your modifications:
> self = NaN will always return false, so that comparison is wrong.

Doh!  Thanks.  I guess I burned myself again by that "invariant" that
two identical objects can be considered equal..

I see you used self = self; is that better than an identity check
against NaN?  I guess its safer just in case some other NaN instance
would be generated in the system?  I've just always had an aversion to
send #= to a Float and expect to get back true, but I guess if the arg
is itself, it should be okay..

> self == NegativeZero will almost never be true (try -0.0 == Float
> negativeZero).

Oh wow.  I had changed it to #== to avoid a different issue, but
introduced this one..!

> Use #= instead.
>
> After trying to understand what the code is about to do, I came to the
> conclusion that there's no reason to treat negative infinity and
> infinity separately.

Yes!  Something bugged me about putting +Infinity all the way up at
(2^32)-2 because of the non-symmetry with the negative side.  I like
yours better!

> hashKey32
>
>         self > 0.0 ifTrue: [
>                 ^16r80000003 + ((FloatArray basicNew: 1) at: 1 put: self;
> basicAt: 1) ].
>         self < 0.0 ifTrue: [
>                 ^16rFF800000 - ((FloatArray basicNew: 1) at: 1 put: self;
> basicAt: 1) ].
>         self = self ifFalse: [ ^16rFFFFFFFF "NaN" ].
>         (self at: 1) = 0 ifTrue: [ ^16r80000003 "Zero" ].
>         ^16r7F800000 "Negative zero"

I'm going with the above (testing 32-bit range on it now), and I even
remembered to avoid using the code-formatter to preserve the hex
representations for Eliot.

Levente, that you can do such positive critical review of this one
method makes me shiver to wonder how many improvements you could
discover for Ma-Object-Serializer!  ;)  Mucho thanks.