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

[Paul Kienzle]

On Feb 9, 2005, at 9:52 AM, David Bateman wrote:

> I'm move this discussion to maintainers, as that seems appropriate at 
> this point.
>
> Paul Kienzle wrote:
>
> > We should probably drop hankel, toeplitz, triu, tril, but make sure 
> > the test cases get into octave first.
> The need for these function points to a problem. I suspect the proper 
> fix is to code some of them as oct-files. In fact I include here an 
> implementation of triu/tril as an oct-file, that is against the 
> sparse-merge branch. This version is implemented in a manner similar 
> to the octave version but is twice as fast as the octave-forge version 
> and uses 5 times less memory. Perhaps this should replace the octave 
> version and we should dump the existing octave-forge and octave 
> versions. toeplitz and hankel should have the same treatment.
>
> As for the test cases, triu/tril don't have any. But toeplitz and 
> hankel do and should be ported.

I believe the correct solution is to fix whatever is making octave slow 
(probably memory management) rather than coding everything in C++.  
triu/tril could be using whatever banded matrix types you have been 
working on.

> > Rand will require some work if John wants to preserve the existing 
> > sequences for the existing seeds.  Using the 'seed'/'state' 
> > distinction will allow that.
> I'd vote to get rid of randpak completely and just dump the existing 
> sequences with existing seeds. If we were to go this path, it would be 
> better to try and get the same behavior with the same keys as matlab. 
> However that means we have to figure out what the uniform generator 
> that is used as a base to matlab is... I see this as hard to 
> impossible, so again I'd prefer to not generate the same sequences as 
> matlab.

That would be my preference as well.  However, I can understand if 
people have course materials based on octave with particular examples 
generated from particular seeds, and they want the same graphs.  
Similarly, simulations should be reproducible from the same seed.  We 
should minimize the number of times we change the sequence.

> > lin2mu and mu2lin change the interface.
> They don't seem to be basically incompatiable though. So again perhaps 
> they should be included without change.

I would prefer to return a vector in the range [-1,1] rather than 
[0,255].  John will have to decide on this one.

> > Some shadow functions exist in other parts of octave-forge, usually 
> > because Octave forge hacked something together which worked before 
> > John had a chance to add it properly to Octave.
> > admin/make_index should tell you which.
>
> These should also be treated in a general de-crufting of 
> octave-forge...

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?

- Paul