Re: [OctDev] adopting functions from Octave-forge

[Paul K. <pki...@us...>]

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

>
>> sortrows, isequal,cellstr
>> unique,ismember,setdiff, strcmpi, strmatch, strncmp, print
>> complex double char full sparse isspace. gammaln,
>> builtin,dispatch,dispatch_help,
>> 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 
> this..
>
> Cheers
> David
>
>
> -- 
> David Bateman                                Dav...@mo...
> 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
>