Re: Octave 2.2.x Was: A group in Norway ...

[Paul Kienzle]

John W. Eaton wrote:

> On 20-Jun-2003, Andy Adler <address@hidden> wrote:
>
> | The big question is: "how far out is 3.0?"
> | If 3.0 is a year or more out (realistically), then I suggest we
> | do the easy and essential stuff, and leave the rest for 3.0.
> | 
> | My ratings:
> | 
> | Easy (by taking the octave-forge implementation)
> |   * sparse matrices
>
> Is this ready to be a part of the core Octave distribution?  How much
> work would it take?
I think a higher priority is getting a packaging system
and a package repository so that things like sparse
do not have to be part of the core.  I see it as a
testament to the strength of the type system that it
does not have to be built in.

A number of people depend on functions in
octave-forge such as the interpolation functions
which are not in octave.  Unless/until these and
all the compatibility functions are made part of
octave (hence become the responsibility of those
with write access to the octave CVS repository),
many users will continue to benefit from installing
them.

> |   * inline functions (octave-forge has a "hack", but adequate)
>
> I would vote against putting in any quick hacks unless they are
> essential.  It would probably be better (and maybe not that hard) to
> go ahead and implement inline functions properly.
inline is a matlab hack.  How else do you
explain that the call inline('x*') succeeds? 
Or that inline('if x<3, 3; else x; end') fails?
Implemented properly, it would capture the
variables from the current scope which were
not explicitly named as parameters, it would
allow arbitrary statements not just expressions,
and it would evaluate to a parsed function rather than
an expression which is eval'd later.  At least
the octave-forge version creates a proper function,
so it fails when you call it with a syntax error.

BTW, I tried inline('if x<3, 3; else x; end') in
octave-forge, but it didn't work for x>=3, even
after I changed the code from
   function r=inline_func_<id>(<args>)
       r = <expr>;
   endfunction
to
   function r=inline_func_<id>(<args>)
       <expr>;
       r=ans;
   endfunction

That's because the statement
   x;
does not change ans, but the statement
   3;
does.  Bug for bug compatibility?

Skipping the r= business and setting
   return_last_computed_value = 1
didn't help.

> | Essential
> |   * clean up the load-save mess
>
> I think this might be a relatively hard problem, which is why it
> hasn't been fixed yet.  But maybe what I think cleaning up the mess
> means is different from what you are thinking about.  I mean that we
> need some reasonable way to handle loading and saving user-defined
> types, and also we need to decide whether it is worth trying to
> support N different file types (HDF5, MAT4, MAT5, Octave binary,
> Octave ASCII, etc.) in the load command.
This is something which does need to be fixed in the
core.  Of course, it would be nice to be able to allow
for user defined file types, and for the ability to serialize
types for sending across the wire to distributed applications,
so maybe it doesn't all need to be in the core.

Paul Kienzle
address@hidden