NTS 1.12: double comparison fails in high precision mode

[GoogleCodeExporter]

The AnonymousXComparerImpl in STRtree uses the AbstractSTRtree.CompareDoubles 
method to compare double values. This causes stability issues and infinite 
loops in the sort algorithm when the floating point control is set to high 
(64bits) precision instead of the normal 53bits.

http://msdn.microsoft.com/de-de/library/e9b52ceh%28v=vs.80%29.aspx

Why is there a special double compare function instead of the .net internal one?

This fixed the issue for me:

        protected int CompareDoubles(double a, double b)
        {
            return a.CompareTo(b);
            //return a > b ? 1 : a < b ? -1 : 0;
        }

Original issue reported on code.google.com by peter.w...@gmail.com on 8 Nov 2012 at 12:40

[GoogleCodeExporter]

Probably is a simple copy of the java code. The fix looks ok to me.

Original comment by diegogu...@gmail.com on 8 Nov 2012 at 12:45

[GoogleCodeExporter]

I suppose you are passing double.NaN values to a or b:
The difference in a.CompareTo(b) and  the way it is now is that the 
a.CompareTo(b) method checks for double.IsNaN().

Try this:
[Test]
public void TestNaNComparison()
{
    double d1 = double.NaN, d2 = double.NaN, d3 = 1;
    Assert.False(d1 == d2);
    Assert.False(d1 < d2);
    Assert.False(d1 > d2);
    Assert.False(d1 == d3);
    Assert.False(d1 < d3);
    Assert.False(d1 > d3);
    Assert.True(d1.CompareTo(d2) == 0);
    Assert.True(d1.CompareTo(d3) == -1);
    Assert.True(d3.CompareTo(d1) == 1);
}

Original comment by felix.ob...@netcologne.de on 8 Nov 2012 at 2:20

• Changed state: Accepted

[GoogleCodeExporter]

I did not pass any specific values. The problem can be reproduced by using the 
difference algorithm on 2 polygons. I used a rectangle and a circle, but it 
really does not matter that much.

Regarding the fix: Perhaps it's better to replace CompareDoubles with CompareTo 
instead of calling CompareTo inside CompareDoubles.

Original comment by peter.w...@gmail.com on 9 Nov 2012 at 1:12

[GoogleCodeExporter]

first fix with r950

Original comment by felix.ob...@netcologne.de on 29 Nov 2012 at 9:41

• Changed state: Fixed