[postgis-users] st_equals strangeness

[Paragon Corporation]

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