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

[David Bateman]

Paul Kienzle wrote:

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

I agree that making triu/tril oct-files is an over-kill, but it works. 
The banded types are all attributes of  a sparse matrix and so these 
aren't problems. However, I forgot to treat the integer types and the 
cell arrays, so as you say my solution isn't complete, but might be 
easily completed.

Again, so an executive decision on what to do with triu/tril, etc must 
be made.

* Dump octave-forge version, and accept fives slower speed.
* Dump octave version and take octave-forge version and accept five 
times more memory
* Write the functions as oct-files, that must be considered as a 
temporary fix, but get the combination of speed and memory efficiency
* Try and find someone willing to fix the speed problems of octave, but 
who...

> > > 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.
I'd agree there, so the fact that the random generators have evolved in 
octave-forge is a good thing as then once they are transitioned to 
octave, there will be less need to change them. However, its up to John 
to pick the preferred one of the three paths

* Dump existing and replace with octave-forge version
* Use the distinction between seed/state the use existing and octave 
forge versions
* Try and figure out the exact matlab sequences and make octave do 
exactly the same thing.

I don't see the third one as realistic though.

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

Ok.

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

I wouldn't vote for a de-cruft until the first octave-forge version 
after octave version 3.0. However, after that point I'd believe it would 
be necessary. In any case there are a large number of functions that 
already need newer versions of octave. So it would necessarily stop 
octave-forge's use on older versions of octave, it would just mean that 
some functions might not be available.



--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary