[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: David Bateman
Subject: Re: Moving code from octave-forge to octave [Was: polyderiv problem?]
Date: Thu, 10 Feb 2005 09:39:12 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040923)

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.


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

reply via email to

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