Re: [OctDev] De-crufting octave-forge

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

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

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.

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.

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.

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. That is the
primitive polynomial, etc for galois fields. If we created a new type
for every primitive polynomial, then the number of user types would
explode, which is why its done in this manner. Thinking about it further
what I propose is to create a helper function, like

DEFUN (resize, args, ,
  "-*- texinfo -*-\n\
@deftypefn {Built-in Function} {} resize (@var{x}, @var{m})\n\
@deftypefnx {Built-in Function} {} resize (@var{x}, @var{m}, @var{n})\n\
Resize @var{x} to be dimension @var{m}-by-@var{n} where @var{m}\n\
and @var{n} are scalar. If @var{n} is not supplied, then resize @var{x}\n\
to be dimension @var{m}-by-@var{m} if @var{m} is scalar, or if\n\
@var{m} is a vector, then the values of this vector respresent the\n\
dimensions of the resized matrix.\n\
@end deftypefn")
{
  octave_value retval;
  int nargin = args.length ();
  if (nargin == 2)
    {
      Array<double> vec = args(1).vector_value ();
      int ndim = vec.length ();
      if (ndim == 1)
    {
      octave_idx_type m = static_cast<octave_idx_type> (vec(0));
      retval = args (0). resize (dim_vector (m, m));
    }
      else
    {
      dim_vector dv (ndim);
      for (int i = 0; i < ndim; i++)
        {
          dv(i) = static_cast<octave_idx_type> (vec(i));
          retval = args (0). resize (dv);
        }
    }
  else if (nargin == 3)
    {
      octave_idx_type m = args(1).scalar_value();
      octave_idx_type n = args(2).scalar_value();
      if (!error_state)
    retval = args (0).resize (dim_vector (m, n))
    }
  else
    print_usage (resize);
  return retval;
}

which I wrote straight into the mailer and so is untested. Then

    if (isa (x, "sparse"))
      retval = sparse (nr, nc);
    else
      retval = zeros (nr, nc, class (x));
    endif

can be written as

      retval = resize (resize (x, 0), nr, nc);

and the o-f functions can be dropped.

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

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?

Everything else in FIXES can be removed without question, including the
sort code, the mu2lin, lin2mu function the poly*.m 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.


Regards
David

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