[postgis-users] snapToGrid strange behaviour

Kevin Neufeld kneufeld at refractions.net
Fri Jan 27 08:09:37 PST 2006


That's exactly what I was thinking as well. But the question remains, 
why does snapToGrid(...) not actually snap to 0.001 as instructed?


Michael Fuhr wrote:

>On Thu, Jan 26, 2006 at 02:25:58PM -0800, Kevin Neufeld wrote:
>  
>
>>Can somebody please explain why we are getting these results?
>>    
>>
>[...]
>  
>
>>-[ RECORD 1 ]----------------------------------------
>>geom     | 0101000000C3F5285C8FC2F33F1B2FDD2406C12340
>>geom     | 0101000000C2F5285C8FC2F33F1A2FDD2406C12340
>>astext   | POINT(1.235 9.877)
>>astext   | POINT(1.235 9.877)
>>equals   | f
>>?column? | f
>>    
>>
>
>I think you're encountering the usual inaccuracies of representing
>floating-point numbers in binary.  Notice the difference in the
>internal representations of the two geometries: in the first the
>y-coordinate is 1B2FDD2406C12340; in the second it's 1A2FDD2406C12340.
>Since the data is little-endian (as indicated by the leading 01),
>the values are actually 0x4023C10624DD2F1B and 0x4023C10624DD2F1A,
>which differ only in the lowest bit.  So instead of being exactly
>9.877 the values are more like 9.8770000000000007 and 9.8769999999999989.
>The calculations that yielded those numbers must have been slightly
>different, resulting in that one-bit discrepancy.
>
>  
>

-- 
Kevin Neufeld,
Refractions Research Inc.,
kneufeld at refractions.net
Phone: (250) 383-3022 
Fax:   (250) 383-2140 




More information about the postgis-users mailing list