Re: [OctDev] convhulln options.

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

On Dec 10, 2003, at 2:37 AM, Simon Cross wrote:

> Hi,
>
>> Okay, but I would prefer 'standard' option handling.  Problem is, I
>> don't like the matlab standard: f(...,'option',val).  Passing a
>> structure x with fields option=value would be okay if octave had a
>> syntax for structure constants.
>
> If I'm reading this correctly, Paul is saying we should have a standard
> way of passing options across all of octave-forge.  I think that that 
> is
> a good idea.  Somebody pick a standard. :)

That's the idea. Except you are missing the phrase "... and implement 
it" :-)

>> Currently, the delaunay* functions of octave-forge have definitions
>> similar to this:
>>
>>    T = delaunayn (P[, OPT])
>>
>> where OPT is a string of options to be passed to the underlying qhull
>> command.  I was thinking about extending the above to the voronoi* and
>> convhull* functions.  Would it be okay?
>
> I think that would be excellent for voronoi, convhull and friends.  If
> some sort of standard option passing method is decided on, it might be
> good to follow it though.
>
> If we decide to go with some kind of struct which holds options, it
> would probably be best to just have a struct with a single member
> "qhull_options" (or something) for the particular case of the qhull
> based functions.  These options are so tightly coupled to qhull that
> specifying them individually in octave-forge would just leave the
> developers with the annoying problem of tracking qhull releases.

The best solution from the user's perspective is for us to keep a
consistent interface independent of the underlying QHull version
(as much as possible).  That way people can for example share
scripts which use QHull without having to worry about which version
is installed.  However, I don't know that QHull is changing enough for
this to be a concern, so for now I would go with Rafael's solution.

Paul Kienzle
pki...@us...