[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.
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
- Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/09
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/09
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?],
David Bateman <=
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/10
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/10
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/10
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], John W. Eaton, 2005/02/10
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Geordie McBain, 2005/02/11
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/23
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/23
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/24