Re: [OctDev] De-crufting octave-forge

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

Paul Kienzle wrote:

>
> Prettty was there because disp didn't return a value.  I believe the
> current version does and pretty is no longer needed.
>
Yes the current disp returns a string if given an output arg. So
pretty.cc goes..

>
> You are correct that this patch is old and irrelevant at this point.
> Also I never completed it --- I have no interest in maintaining a
> fork of octave.  I still believe it would be nice to write, e.g.,
> (A - mean(A))./std(A)
>
> Perhaps a better alternative is to leave matrices as they are, but
> provide full numerical support for cell arrays.  That would allow the
> different data sets to have different lengths rather than relying on
> NaN and missing data functions.

I think that although the patch itself is now useless due to age, the
ideas encapsulated in it should be kept somewhere for future reference.
If the PROJECTS file is converted to an issues database based then
ideally this patch would form part of that.

>
> I've been living with the current octave-mod.

So the octave-mod in extras/patches goes..

>
>> For FIXES, the problem files are
>>
>> fsolve.cc: I've already attacked this one with the inclusion of the
>> function handles and inline functions. The multiple arguments accepted
>> by the o-f version might be easier enough to include in octave.
>
>
> This has been refused in the past.  I agree with John that it is
> an ugly hack, and with anonymous functions supported in both Octave
> and matlab, we can ask users to convert their code.

What I propose if just the additional arguments bits, not the anonymous
function handles and inline functions that cause all of the mess.

>
>> grid.m: This is a compatibility extension of grid.m to allow 1)
>> recovering the previous state with the gget function and toggling grid
>> state if no input arguments are used. It also supports minor tics if you
>> have an argument like "x#y#z#" where # is a digit. This is not
>> texinfo-fied, so based on a very old octave version of grid.m, it used
>> gget which I don't see ever going into octave as it has some possibly
>> nasty race conditions on temporary files. Perhaps with gnuplot 4.1
>> something similar might be implemented with a pipe and be accepted in
>> octave. So in its current implementation I don't see this code being
>> accepted. That being the case, the minor tick stuff might be included,
>> just not the probing of the existing settings.
>
>
> Rather than querying we could try keeping track of state on the
> octave side.

I suppose if there is a "PKG_ADD grid('off')" command in grid.m and a
persistent variable tracking its state this would make sense. Easy
enough to propose a patch.

>
> The syntax for minor tics is a bit hackish and may be rejected.

John what do you want to do about the minors tics in o-f's grid.m?

>
>> hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed
>> for memory usage. The o-f versions also have the advantage that they
>> work for user types (eg galois fields) as they don't use zeros(m,n) to
>> create the initial matrix. There's a thread about this about a year ago
>> between Paul and myself on the maintainers list. I don't think John is
>> concerned about the speed issue, but the compatibility with user types
>> is a real problem for me. In the octave versions of tril.m and triu.m
>> what is currently done is
>>
>>     if (isa (x, "sparse"))
>>       retval = sparse (nr, nc);
>>     else
>>       retval = zeros (nr, nc, class (x));
>>     endif
>>
>> however, this can't be done with the galois of fixed types, and there is
>> additional information that is not contained in the class.
>
>
> Rather than building up from zeros, can you chop down from a full
> matrix.  E.g., triu
>
>    for i = 1:columns(x)
>       x(i+1:end,i) = 0;
>    end

Yes but which value of "0"? In the implementation of galois field the
above makes sense and there is only one field for the entire matrix.
However, for the fixed-point type it does as each element of the matrix
can have a different fixed point representation.

>
> Preserving the old random number generator seems crufty.  Could it
> be made into an external package that the few people who care
> about it can download it separately?
>
John's stated he want to keep the capability to generate the same
sequences as the old generators. That being the case I don't see a way
around having both.

> That is not to say we shouldn't support different random
> number generators.  GSL supports several.  However, a
> "seed" vs. "state" selector seems like the wrong way to do it.

That is the way Matlab does it, so it made sense in a compatibility way.

>
>> tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the
>> bug should be fixed in octave. Paul what is the reason for these?
>
>
> I will have to dig through the mailing list to find the cases
> where octave's functions fail.

Ok.

>
>> Everything else in FIXES can be removed without question, including the
>> sort code, the mu2lin, lin2mu function the poly*.m functions
>
>
> Because octave now includes these functions?

Yes

D.

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary