[geos-devel] QD (Quad-Double) Approach to Robustness
Martin Davis
mbdavis at VividSolutions.com
Wed Jun 14 14:16:09 EDT 2006
> Ok, but equality is actually used in JTS too.
> Does Java have an automatic approximate equality ?
I've been working under the assumption that Java uses a single FP model,
so that it's safe to compare FP numbers.
In any case, I'm not sure that JTS uses FP equals for anything other
than checking whether two points are *exactly* the same. So this should
be portable, I assume. Portability would depend on the implementation
not changing the bit-pattern of a FP number wherever it is stored -
surely this is reliable? Otherwise it seems a bit insane, if the FP num
bytes change as it moves between different kinds of memory.
Martin Davis, Senior Technical Architect
Vivid Solutions Inc. www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> -----Original Message-----
> From: geos-devel-bounces at geos.refractions.net
> [mailto:geos-devel-bounces at geos.refractions.net] On Behalf Of
> strk at refractions.net
> Sent: June 14, 2006 11:11 AM
> To: GEOS Development List
> Subject: Re: [geos-devel] QD (Quad-Double) Approach to Robustness
>
>
> On Wed, Jun 14, 2006 at 08:01:53PM +0200, Mateusz Loskot wrote:
>
> > Sandro,
> >
> > Your test case is incorrect.
> > You can't compare float numbers as you are doing it in the assert:
> >
> > assert(tot_check==tot);
> >
> > especially if you're working with multiplatform library as
> GEOS. You
> > can only test how close are both numbers.
> >
> > There are many problems. float arithmetic on Intel CPUs deos not
> > follow IEEE 754, different representation of float numbers on varios
> > architectures: FPU calculations are made on 80 bits numbers (ext.
> > double) but SSE2 instructions on 64 bits.
>
> Ok, but equality is actually used in JTS too.
> Does Java have an automatic approximate equality ?
>
> Beside this, the XML testcase I have attached should
> then represent a valid testcase and should be made
> to work with the current "sloppy" fp condition.
> Problem is that I suppose JTS won't raise the same
> problem (having different fp threatment).
>
> --strk;
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>
More information about the geos-devel
mailing list