Re: [OctDev] De-crufting octave-forge

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

On Mar 29, 2006, at 4:53 AM, David Bateman wrote:

> Quentin Spencer wrote:
>
>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
>> are incompatibilities, as recently pointed out with the system
>> function (should be fixed in CVS now), so I think we should make
>> another release for 2.9.5+ soon. I'm willing to spend a little time
>> doing some de-crufting, but I just wanted to ask first if there is
>> anything I shouldn't touch. The obvious stuff is all of the Makefiles
>> and .m.in files for things that are now in octave, but even that is
>> incomplete (most of the stuff in the main/time directory appears to be
>> in octave now, and there are probably more examples). I also was
>> inclined to just remove the whole sparse directory, but I thought
>> David said we needed to keep the superLU stuff. Any objections?
>>
>> -Quentin
>>
> A lot of stuff is conditionally built, and that can be removed. Also 
> for
> the sparse stuff the iteration stuff should be kept for 2.9, but not 
> the
> rest. That is the pcg.m and pcr.m functions, but nothing else. You can
> also remove the extra/test directory completely but move the pretty.cc
> function somewhere else unless Paul wants to drop it.

Prettty was there because disp didn't return a value.  I believe the
current version does and pretty is no longer needed.

> I'd also like to
> eventually see the FIXES and extra/patches directories completely gone
> and anything in these should either be in octave or dropped. Though we
> can't do that completely until certain code is ported to octave. So
> there are several files in these two directories that must be treated
> before being dropped. In extra/patches these are
>
> M-v-ops-2.1.31.patch: This allows things like rand(3).*[1:3] to make
> sense and be allowed, however there is a fundamental question of 
> whether
> we want this, given the other products behavior, regardless of how
> attractive this is and further more the ages of the patch means that 
> its
> more of an idea of what needs to be done rather than a working patch
> against a current version of octave. If we had an issues database, this
> should go there but for now keep it in o-f

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.

> octave-mod-2.1.31.patch: I'm not sure the octave emacs mode has been
> updated to handle the test/assert stuff. Now that this is in octave
> itself, if it doesn't it should be adapted and included in octave. I
> think Paul has to make a call on this one. In any case the current 
> patch
> needs serious updating as it doesn't apply at all to the current CVS.

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

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

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

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

> 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

A resize function will still be needed to grow the matrix.

> rand*: These need to be included in octave, though the question of
> allowing the old sequences to be generated needs to be addressed. I
> believe the way to handle this is to keep the old generators in octave,
> include the new ones, and if the keyword "seed" is used the old
> generators will be used to maintain the old sequences for people who
> force the seed of the generator, otherwise the new generators will be
> used. Also the octave statistic functions should be updated to use 
> these
> functions

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?

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.

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

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

> Cleaning up the above and getting what should be in octave sent to John
> is on my TODO list, but relatively low priority :-). So if you want to
> at least get rid of the stuff I marked above that would be a good 
> start.


- Paul