[geos-devel] QD (Quad-Double) Approach to Robustness

Martin Davis mbdavis at VividSolutions.com
Wed Jun 14 15:03:34 EDT 2006


Here's the Java spec on use of FP numbers:

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.h
tml#9249

It always uses IEEE754 format.  But as I understand it, IEEE754 has some
subtle complexities involving rounding modes and hidden bits on some
platforms (e.g. Intel), so even this pretty detailed spec may not mean
that evey Java implementation computes in exactly the same way.  

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 
> Martin Davis
> Sent: June 14, 2006 11:16 AM
> To: GEOS Development List
> Subject: RE: [geos-devel] QD (Quad-Double) Approach to Robustness
> 
> 
> > 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
> > 
> _______________________________________________
> 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