[OctDev] Re: Changes for the geometry package

[Pedro T. <pt...@te...>]

Brad,

Thank you for your comments.


> MATLAB will switch to Qhull 2003.1 for R14.

I've used these libraries too.

> ---------------------------
>   sprintf(flags,"qhull %s",options); //Notice that output options will not
> work.
>
> Missing check for buffer overflow.   flags is char[255],
>
> ----------------------

Right...

>   //  Qt won't work since it
>   // premerges the facets and only afterwards it triangulates.
>
> I noticed some inconsistent usage for Qt/QJ/Q0.  convexn currently uses Q0
> while delaunayn() and voronoin() use merged facets.
>
> I think you should use 'Qt' for convexn() and delaunayn().   If the data
> contains singularities, Qhull 'Q0' may produce garbage results.  For
> example, try rbox 1000 W1e-12 | qhull Q0
>         <clip>
>         qhull precision error: f894 is concave to f1029, since p895 (v153)
> is 5.107e015 above qhull precision error: f1060 is concave to f1115, since
> p826 (v150) is 3.664e-015 above
>
> QJ guarantees a simplicial result but it perturbs the input.   Qt is
> approximately 1000 times more accurate.  You should be able to use it.  The
> end result is a simplicial data structure just like QJ or Q0, but with some
> facets marked "tricoplanar".

When I set Qt in the options qh_new_qhull won't give a triangulated hull. As 
far as I understand your code, qh_triangulate() is called before producing 
the output, so I should just make a call to qh_triangulate(), is this right?.

...
> If 'Qt' is used for voronoin() then non-simplicial Delaunay regions
> generate multiple copies of the corresponding Voronoi vertex:  Compare the
> following Voronoi diagram of the unit cube centered at the origin.
........

In the actual implementation neither delaunayn() nor voronoin() use Qt. I 
think this option could be easily added in delaunayn.m file, once I get Qt 
working. I'm thinking that since the 'triangulate' option is SO important it 
could be passed as a third argument to octave's qhull, especially since Qt 
doesn't affect the qh_new_qhull computations and code must be writtenY to 
control it...

> --------------------------------
>     // Volume calculation. Copy-paste from geom2.c. qh_getarea didn't give
> proper results
>
> Volume computation increases run time by about 10%.  It is not needed for
> most applications.   Should it be optional?

Yes it should. I just added it because Matlab returns it in convhulln().

> I curious why you copy pasted the code.  The original code should work
> fine.  If you copy-paste, then you may miss out on future improvements to
> the original code.

You catched me here... Just because I'm not a very efficient C programmer, I 
took this "assignment" as a practice, and I couldn't make qh_getarea() do 
what I wanted it to. After three hours going nuts, following crazy pointers 
all over the code, I found a "solution". ;)

I'll look into your suggestions. Thanks again,

Pedro