Re: new delaunay

[Joao Cardoso]

Kai Habel wrote:
> 
> Hello,
> 
> The old delaunay code (from the GMT project [1]) had an error and wasn't
> usefull for other geometric operations. (voronoi diagramms, convex
> hulls, ..)

...

> My question to you (especially jwe): What do you think is the best way
> to go on?
> 
> * Keep the qhull lib and the DLD functions separate from octave
> * include the DLD-functions in octave and
>   check at the configure stage for a user installed libqhull.
> * include both in octave

I think that a 'contrib' directory should be setup in Octave
distribution. Not for m script files, but for dll ones.

Individual script files are most of the time very specific, and often
replicate each others functionalities. A package, by contrary, deserves
its own subdirectory in the scripts directory; if supplied with
reasonable test functions, the package would represent only a minor
support overhead, even if the original author disappears from Octave
scene.

Including dll functions in Octave itself puts too much overhead in its
maintenance, so I think that they should not go into Octave core. The
exception would be generally useful functionalities, such as ATLAS, HDF,
plotting, sparse matrix support, etc.

Until now, contributions from users have been split among several sites,
including Octave source mailing lists:

Kai Habel  -- http://user.berlin.de/~kai.habel/
Etienne Grossmann -- http://anonimo.isr.ist.utl.pt:8080/~etienne/octave/
Paul Kienzle  -- http://users.powernet.co.uk/kienzle/signalPAK/
GNU Octave Repository -- http://octave.sourceforge.net
Uniting the World of Numerical Analysis --
http://www.matlinks.net/index.html
Octave Software Components --
http://ideas.uqam.ca/ideas/data/bocbococt.html
between others -- http://merlin.inescn.pt/~qual/Octave/Octave_links.html

Most of the "repository" sites had a very limited success, so I think
that, for dll functions, a 'contrib' directory in Octave distribution
would be helpful. With time, perhaps some mature functions could be even
incorporated into Octave core.
Those functions could be downloaded in tar format to an 'incoming' ftp
directory, and, after unpacking, the results of a plain 'make check'
would establish if the contribution would be accepted. With no
compromise for support. This could also be done through CVS, but I think
that it would imply more administrative burden.

That's a pity that some useful functions, contributed with the GNU
philosophy in mind, would be lost by lack of adequate support, so I
think that this initiative should be centralized and advertised through
Octave home page. Even if redirected for other site.


Joao