Re: [OctDev] adopting functions from Octave-forge

[David B. <Dav...@mo...>]

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

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

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