Re: [OctDev] convhulln options.

[Paul K. <pki...@us...>]

On Dec 18, 2003, at 3:53 AM, Rafael Laboissiere wrote:

> * Paul Kienzle <pki...@us...> [2003-12-17 20:07]:
>
>>
>> On Dec 17, 2003, at 7:00 PM, Rafael Laboissiere wrote:
>>
>> [...]
>>> would be represented in Octave like this:
>>>
>>>    A = {[3 4 2 1],
>>>         [7 4 3],
>>>         [5 7 3 1],
>>>         [4 6 2],
>>>         [6 7 5],
>>>         [7 6 4],
>>>         [6 5 1 2]}
>>>
>>>
>>> (Notice that vertex indices in Octave start at 1 instead of zero.)
>>>
>>> I do not know how backward incompatible would be such a change.
>>
>> I think the most convenient would be to return a cell-array of 
>> matrices,
>> one for each dimension of returned facet.
>
> Sorry, I did not understand the above statement.  Could you give an 
> example,
> please?

A = { [7 4 3; 4 6 2; 6 7 5; 7 6 4], [5 7 3 1; 6 5 1 2] }

This is the same information as above but you can process it with
"for i=1:2" rather than "for i=1:6".

>> I think it would also be convenient if the default were to arbitrarily
>> split those facets that are non-simplicial so that those who just want
>> triangles don't have to deal with the occasional square.  I'm 
>> guessing that
>> this is what matlab does --- convhulln returns this for the cube:
>>
>>>> convhulln(cube)
>>
>> ans =
>>
>>      3     4     1
>>      4     2     1
>>      2     4     6
>>      2     5     1
>>      5     2     6
>>      7     5     6
>>      4     7     6
>>      7     4     3
>>      7     3     1
>>      5     7     1
>
> This is the case in Octave with the "QJ" option:
>
>     octave:3> convhulln(cube,"QJ")
>     qhull warning: joggle ('QJ') always produces simplicial output.
>     Triangulated output ('Qt') does nothing.
>     ans =
>
>       7  8  6
>       4  8  6
>       5  7  1
>       5  7  6
>       2  4  1
>       2  4  6
>       2  5  1
>       2  5  6
>       3  7  8
>       3  4  8
>       3  7  1
>       3  4  1

Okay.  But aren't we supposed to be avoiding QJ?  Is there a way to
break up a non-simplicial facet which doesn't introduce errors?

>
>> So long as the default all-simplicial case is returned as a matrix,
>> backward compatibility doesn't matter.  The user will need special 
>> code to
>> handle the non-simplicial facets anyway.
>>
>> Are these two cases different enough that we need different functions?
>
> I do not think so, since the output format will be dependent on the 
> data
> and, in general, cannot be determined beforehand by the user.
>
> I have already an idea on how to implement this change (i.e., 
> returning a
> cell array instead of a matrix in the non-simplicial case.  Should I go
> ahead?

The output needs to be predictable so that users can code for it.  
Also, the
default output must be simplicial only for compatibility --- same named
functions should give the same results for the same input.

>
>> I think you are going to need an interface layer above the QHull 
>> options so
>> that users can ask for them nicely:
>>
>> [X,Y,Z] = convhulln(cube,'output',{'simplicial','ideal','geomview'})
>>
>> This says that X will contain the simplicial output (as a full 
>> matrix),
>> Y will contain a cell array of facet sizes, and Z will contain a 
>> string
>> used to control geomview.  The default for output must be 'simplicial'
>> for compatibility.
>>
>> That means you will need other options for controlling the QHull
>> algorithm, such as 'qhull','QJ' to feed a raw option string, or if 
>> you are
>> feeling creative, meaningful names for all the options.
>
> That looks like a quite nice idea.  Two questions:
>
>     * Is the option passing format you described above standard in
>       Matlab/Octave/octave-forge?

Matlab uses 'option',value pairs frequently (e.g., for all of their 
handle
graphics functions and for their optimization functions).  Many 
functions
also accept structures where x.option=value.  I wrote some code a
couple of years ago to sort out options --- I'll update it and send it
along.

Matlab also uses fn(...,'option','option','option') and  fn(...,parms), 
where
parms is an array of integers, but these are less common.

>
>     * Can I consider your suggestion as a final design or is it just a
>       sketch?  If it is the later, could you please propose a complete
>       design (so that implementation can follows easily)?

I can't propose a final design because I don't know how to use
QHull effectively.  You tell me what options you want to control
and what they mean, and I can suggest an interface.

- Paul