On Sep 30, 2005, at 3:38 AM, David Bateman wrote:
> Paul Kienzle wrote:
>> Given the minimal time I have for maintaining octave-forge
>> and in particular, for making sure that it stays in sync with
>> octave, I propose we delete what we can.
>> mu2lin and lin2mu: check the octave mailing list for bug
>> reports. IIRC the octave-forge version is more compatible
>> with matlab.
>> tf2zp and zp2tf: check the octave mailing list for bug
>> reports. IIRC there are some cases which fail in octave
>> but not in octave-forge.
>> rand, randn, randp, rande: much faster in octave-forge than in
>> octave, more bits of randomness and longer sequence. poisson_rnd
>> or whatever it is called now should call randp.
>> grid: octave-forge allows finer control of the grid such as
>> the number of tic marks and which axes they are shown for.
>> detrend: extra/nan and extra/tsa need to be resolved by Alois
>> chol: check whether octave-forge is faster, and whether it is
>> enough faster.
> I'll be getting rid of the chol stuff in octave-forge when I get to do
> the same polymorphic solver code for the full matrices that I have for
> the sparse matrices.. So get rid of it..
>> Eliminate the following:
>> polyder, polyderiv, polygcd
> I think I ported the differences from, this to octave...
Yes I saw that. A syntax blind comparison would be nice, but it still
won't avoid the unnecessary () after if in octave or the unnecessary ,
after if in octave-forge. The issues with linebreaks are also
>> sortrows, isequal,cellstr
>> unique,ismember,setdiff, strcmpi, strmatch, strncmp, print
>> complex double char full sparse isspace. gammaln,
>> fieldnames, isfield, rmfield,isa
>> hankel, toeplitz, tril, triu: these were attempts to trade
>> memory for speed. I believe the speed gain is only for small
>> matrices which don't need it. I think we should turf these.
> Be careful dumping these, like polyder, etc there might be some
> subtile changes that are useful. They should each be examined
> carefully before dumping them.
I checked: unique, ismember, setdiff, sortrows strmatch, print, gammaln
I gave octave the benefit of the doubt on: fieldnames, isfield,
rmfield, struct, builtin, dispatch, dispatch_help, sparse, issparse,
full, complex, double, char
isequal should be checked.
> There are other problems with triu/tril in octave-forge for sparse
> matrices, which I still haven't resolved.. I had an oct-file version
> of triu/tril that did all types, and as the for-loops were in C++
> there was no trade-off speed/memory. However, John rejected this as he
> prefers to keep as much as possible in m-files.. Maybe should revisit
> David Bateman David.Bateman@...
> 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