Re: qhull6 and octave

[Brad Barber]

Hi John,

Thanks for your series of comments, all good.

Replies inline.
                        --Brad

At 04:01 PM 12/13/2011, John W. Eaton wrote:
>On 21-Nov-2011, Brad Barber wrote:
>
>| Please replace #include "qhull.h" with #include "libqhull.h".  On
>| Windows systems, qhull.h got confused with the C++ Qhull.h.  For
>| 2011.2, I'm adding back qhull.h, but renamed as qhull.h-deprecated.
>
>I don't see how adding a new file called qhull.h-deprecated helps.
>Existing code that uses qhull.h will still not work properly without
>change.  So why would anyone choose to include qhull-deprecated.h
>instead of just including libqhull.h?

 From email, it appears that qhull users consist of the following groups, in 
order of size

1) Users of the standalone programs -- qhull, qconvex, qvoronoi, etc.

2) Users of packages and code that include qhull, particularly Matlab, octave, 
F, collection detection code.

3) Programmers who include qhull in their programs, but know little 
computational geometry

4) Computational geometers who call qhull from their programs.

For qhull 2010, I removed qhull.h because it conflicted (on Windows) with the 
object-oriented interface, Qhull.h.   But then users (in group (2)) complained 
about the missing file.

By having qhull.h-deprecated, these users can rename the file to qhull.h, and 
continue without other changes.

Also happy to get rid of it.  Anyone else with an opinion?

At 03:55 PM 12/13/2011, John W. Eaton wrote:
>On 30-Nov-2011, Brad Barber wrote:
>
>| qhull5 was apparently built with qh_QHpointer=0 [user.h].  The
>| global data structure for qhull is defined as a static array qh_qh
>| [libqhull.h].  qhull6 was built with qh_QHpointer=1.  The global
>| data structure for qhull is allocated on the heap with a pointer
>| from the global variable qh_qh.  This allows for multiple global
>| data structures that can be swapped by updating qh_qh.  Two other
>| pointers/static structures are similarly defined (qh_qhmem for the
>| memory allocator and qh_qhstat for statistics).
>
>Is there some way we can determine how qh_QHpointer should be defined?
>Preferably using a compile-only test instead of running a program.
>That way the test could work even when cross-compiling Octave.
>
>I also think it would be great if this level of detail was not exposed
>to the user of qhull.  As a user, I don't really care how the memory
>is allocated internally, so it would be helpful to not have to change
>my program depending on how the qhull library happens to be compiled.

Fully agreed, but I don't see a way around it.  The problem is that there are 
two very different ways of using Qhull.  It is embedded in all of the code.

1) static allocation of qh_qhT as the global variable 'qh_qhT qh_qh'.   Fastest 
code, but complicates swapping between Qhull instances.

2) heap allocation of qh_qhT, as the global variable 'qh_qhT *qh_qh'.   More 
flexible code.  Used by the C++ interface.

3) [Sometime in 2012, with some luck]  stack allocation of qh_qhT based as a 
parameter to all qhull functions that need it.  Allows simultaneous execution 
of qhull instances.

The 'qh' macro allows either to be used, or any other convention (e.g., 
thread-local storage).       Unfortunately, modern linkers do not detect the 
conflict if a program uses one convention and the qhull library the other.  On 
hindsight, I should have defined distinct names instead of qh_qh.

There does not appear to be a way to determine how qh_QHpointer should be 
defined.    You could have a flag file that indicates qh_QHpointer, but it 
wouldn't work for builds that need to create the various renditions of Qhull.   
Something like this may be a good idea for Octave and F, but I think picking 
one choice would be best.

My current plan is to ship builds that include all of variations -- static with 
and without qh_QHpointer, and dynamic with and without qh_QHpointer.  Builds 
include Makefile, simplified Makefile (libqhull/Makefile), CMake, VisualStudio, 
and Qt.

Configure/Debian/Octave build was not included because it didn't work under 
Windows, nor under the Linux system that I have available.  Also, build 
exhaustion played a role.  It took an amazing amount of time to get everything 
right.

Long term, I think the best approach is static builds for users who want speed 
(group 1, and much of group 2 above), and shared builds based on stack 
allocation for users who need flexibility (much of group 3 and group 4)..

Please let me know about alternative plans that might work better, and be 
easier to maintain.

                                --Brad