Re: [OctDev] convhulln options.

[Simon C. <si...@li...>]

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. :)

>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.

Schiavo
Simon
-- 
Closed mouths gather no feet.
--
4979 486 380 (llec)   :leT	9383 056 120 (krow)
ten.az.noulg@nomis    :liam-E