Re: Moving code from octave-forge to octave [Was: polyderiv problem?]

[Paul Kienzle]

On Feb 10, 2005, at 10:43 AM, John W. Eaton wrote:

> On  9-Feb-2005, Paul Kienzle <address@hidden> wrote:
>
> | I'm reluctant to force lock-step upgrading of octave and octave-forge
> | which is the consequence of purging the cruft.  A community poll may 
> be
> | required here.  How many people use an old version of octave with a 
> new
> | version of octave-forge?
>
> When I install octave-forge, it is usually done with apt-get, so I
> assume I'm getting a compatible and up-to-date version.  I've never
> tried installing a new version of octave-forge with an old copy of
> Octave.  But I might not be a typical user.

That's true for me as well.  However, some systems only come with
older versions of Octave.  Rather than forcing a recompile to the
latest version of Octave in order to install octave-forge, I try
to support older versions, at least to some extent.  Moving the core
compatibility functions to octave (especially interpolation routines,
but a lot of trivial routines as well) would reduce demand for
octave-forge considerably.  I believe signal and image processing
are the next most heavily used.

> Most of the time, I don't have octave-forge installed on the systems I
> use because it replaces functions that are already in Octave,
> sometimes with undesirable (or at least unexpected) results.  I'd be
> much more willing to always install octave-forge if I knew that it did
> not include functions that overlap with ones already in Octave.

Obviously octave-forge has nothing of value to you because everything
you need you include in octave ;-)

You should not be seeing unexpected or undesirable results from
installing octave-forge.  If you are, then it is a bug in octave-forge
and should be reported.  Note that the NaN toolbox is not installed by
default because it changes the statistics functions to ignore NaNs.

- Paul