Re: Qhull test changes

[Brad Barber]

At 08:25 PM 1/30/2012, Ben Abbott wrote:

>On Jan 30, 2012, at 7:42 PM, Brad Barber wrote:
>
>> At 07:32 PM 1/30/2012, Ben Abbott wrote:
>> 
>>> On Jan 30, 2012, at 7:15 PM, Alexander Hansen wrote:
>>> 
>>>> On 1/30/12 6:02 PM, Rik wrote:
>>>> 
>>>> <snip>
>>>> 
>>>>>> I'm not certain, but doesn't "Qt" imply that the convex hull
>>>>>> should be made up of triangles ? (perhaps I should study the
>>>>>> qhull docs a bit ?)
>>>>>> 
>>>>>> In any event, I favored the more recent qhull because it matches
>>>>>> Matlab's result.
>>>>>> 
>>>>> Yes, the output should be triangulated when we pass the 'Qt' option
>>>>> and the new post-2011 Qhull behavior is mathematically correct.
>>>>> The problem is that Qhull is not returning triangulated output for
>>>>> versions less than 2011 and users will blame Octave when they see a
>>>>> failing test in the test report.  I am proposing that Octave work
>>>>> around the different Qhull versions so we don't generate a lot of
>>>>> spurious bug reports.
>>>>> 
>>>>> On the other hand, if we want we could leave the test in and also
>>>>> put in some comments that specifically say, "If you see this test
>>>>> failing, then you must upgrade your Qhull installation."  This
>>>>> might do a bit towards pushing users and distributions to upgrade
>>>>> to a new Qhull.
>>>>> 
>>>>> --Rik
>>>> 
>>>> Excuse me jumping in, but does this indicate that I should be using
>>>> qhull>=2011 for my Octave-3.4.3 and Octave-3.6.0 Fink packages?  I've
>>>> been using 2009.3.
>>>> 
>>>> -- 
>>>> Alexander Hansen
>>>> Fink User Liaison
>>> 
>>> To use qhull 2011 a patch is needed. 2009, 2010, or 2012 should each be ok. 
>>> The problem appears to be in the tests Octave runs (i.e. make check)
>>> 
>>> Ben
>> 
>> I hope that all builds of Octave upgrade to 2012.1.  There's a serious bug 
>> with 2009.1 and other bugs fixed in 2011.2 and 2012.1.  For details, see
>>   http://gitorious.org/qhull/qhull/blobs/master/src/Changes.txt
>> 
>>                                --Brad
>
>Is there a simple way to test for the serious 2009 bug ? Something that could 
>be added to the configure process?
>
>Ben

Hi Ben,

The easiest is to check the code for qh_gethash in poly.c.  It should read
     result %= (unsigned)hashsize;
Instead of
     hash %= (ptr_intT) hashsize

See http://www.qhull.org/download/poly.c-qh_gethash.patch

The problem occurs if the set elements have the high-bit set.  This only occurs 
on 32-bit machines with more than 2G memory.   The data needs to be allocated 
in high-mem.  Typically, qhull will overwrite an arbitrary location with 
undefined results, often a segfault.

For other notes about bugs see
   http://www.qhull.org/news/qhull-news.html#bugs

                                --Brad