[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: John W. Eaton
Subject: Re: Moving code from octave-forge to octave [Was: polyderiv problem?]
Date: Thu, 10 Feb 2005 10:43:30 -0500

On  9-Feb-2005, Paul Kienzle <address@hidden> wrote:

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

Yes, it is nice to be able to reproduce the same sequence when you are
debugging or producing a document where you want the figure to stay
the same from one edition/printing to the next.  But it is probably
not critical, even then.  After all, computations involving rand are
supposed to have some random component...

Perhaps we could have a way to explicitly set the random number
generator (other than "seed" vs. "state").  Would this be a bad use of
a built-in variable?

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

Probably it is best to be compatible, whatever that is, at least if
you are using the same function name(s).  If you prefer a different
representation, then maybe a separate function (or wrapper) should be

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

When I install octave-forge, it is usually done with apt-get, so I
assume I'm getting a compatible and up-to-date version.  I've never
tried installing a new version of octave-forge with an old copy of
Octave.  But I might not be a typical user.

Most of the time, I don't have octave-forge installed on the systems I
use because it replaces functions that are already in Octave,
sometimes with undesirable (or at least unexpected) results.  I'd be
much more willing to always install octave-forge if I knew that it did
not include functions that overlap with ones already in Octave.


reply via email to

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