[postgis-users] st_equals strangeness

[Jan Hartmann]

I agree. 64 bits testing doesn't test on equality, it just tests for a 
smaller rounding error.

Jan

On 8-1-2010 21:25, Paragon Corporation wrote:
> Paul,
> Huh.  What do you want to change = to? A real =?
>
> If you do remember for better or worse it will have impact on -- GROUP BY,
> ORDER BY
>
> as the = operator I can only guess is baked in deeply into the PostgreSQL
> implementation of these (not sure how though).
>
> So if you ever change it to a true equality operator, I suspect these things
> may become as slow as molasses, and well I see no point
> of making it a 64-bit check because the only reason is to make it more of a
> true equality which it isn't anyway.  People should just get out of that
> mindset.
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Friday, January 08, 2010 12:51 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] st_equals strangeness
>
> Well, that brings us to the API level, no? Because operators have meanings
> in index (32-bit) terms. Should all our operators have 64-bit rechecks?
> Should some of them? Should '=' just get a special treatment, because we
> have such an in-grained understanding of what that symbol connotes, and
> other symbols be left as pure index ops?
>
> P
>
> On Fri, Jan 8, 2010 at 9:44 AM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk>  wrote:
>    
>> Paul Ramsey wrote:
>>
>>      
>>> More to the point, it's a float32 box, not a double64 box. Your two
>>> points are in fact different, waaaaaay down deep into the precision
>>> of their 64-bit double coordinates. So deep in fact that the human
>>> readable decimal representations don't show it (look at the hexewkb
>>> output, and you'll see the differences, you should be able to do
>>> that, points are small enough to eyeball in hex).
>>>
>>> So when the 32-bit box is extracted from the 64-bit doubles, the
>>> points are identical at that level of precision and = returns true,
>>> while st_equals working against the doubles does not.
>>>
>>> P
>>>        
>> Again, another demonstration as to why BOX2DFLOAT4s should never be
>> used for calculations and only for internal "within" checks :(
>>
>>
>> ATB,
>>
>> Mark.
>>
>> --
>> Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS
>> Sirius Corporation plc - control through freedom
>> http://www.siriusit.co.uk
>> t: +44 870 608 0063
>>
>> Sirius Labs: http://www.siriusit.co.uk/labs
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>      
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>