[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Kienzle
Subject: Re: Moving code from octave-forge to octave [Was: polyderiv problem?]
Date: Wed, 9 Feb 2005 21:40:07 -0500

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]