From: Paul K. <pki...@us...> - 2005-09-30 03:59:28
|
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. Eliminate the following: polyder, polyderiv, polygcd, 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. - Paul On Sep 29, 2005, at 12:12 PM, John W. Eaton wrote: > Is anyone maintaining a list of functions that have been moved from > Octave to Octave-forge? If so, where is it kept? I'd like to add to > it as more functions are adopted. > > Ignoring sparse functions, we currently have the following overlap: > > builtin dispatch hankel mu2lin randn struct > cellstr dispatch_help isa ndims rmfield tf2zp > char double isequal orient setdiff toeplitz > chol fieldnames isfield polyder sortrows tril > complex full ismember polyderiv str2double triu > deal gammaln issparse polygcd strcmpi unique > detrend gammaln isunix print strmatch unix > dispatch grid lin2mu rand strncmp zp2tf > > Some of these may still be different in Octave-forge, so the list > should also keep the current status of the function so that we don't > end up with two diverging versions of each of these. > > jwe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > |