Re: overloaded functions

[David Bateman]

> 
> Octave doesn't (yet) support concatenation of types.
> 
> I think the only sensible way to handle it is with a new concatenation
> operator.  That means this will be a pretty big patch.
> 
> I hope we can assume that size(cat(i,a,b),i) == size(a,i)+size(b,i),
> where cat(i,a,b) is the concatenation of a and b along dimension i,
> otherwise we will need a separate operator to return the size of the
> result so we don't thrash memory when building up a matrix.
> 
> Another option would be a built-in concatenation function with the
> parser translating [ ... ] into the appropriate cat functions, then
> using dispatch to overload the cat function.  But dispatch will need to
> be extended to multiple argument dispatch for this to work, and the
> mechanism will have to go through feval which will make it slow.

I thought this was the situation since tree_matrix::rvalue seems to be
hard-coded only for the internal types. However, this is really quite an
important piece of code to have since lots of the existing scripts would
just work for new types.

I kind of like the idea of extending dispatch for multiple arguments.
Although you'd have to include a preference where the overload is
valid for ANY or ALL of the arguments of the new type, and have a
means of arbitrating between multi-arg functions that have arguments
from two different overloaded types. The fact is I also already need
this functionality for dispatch, since I overload the filter(b,a,x,si)
function for my Galois type.

> I don't think we can do it with an octave_value method because the
> type resulting from a.cat(i,b) depends on both the type of a and the
> type of b.

Why not, this way we could implicitly include which type takes priority.
That is

    class octave_foo {
        ...
        octave_matrix cat(int i, const octave_matrix& a);
        octave_foo cat(int i, const octave_bool& a);
        ...
    }

However, what might cause a problem is that the order of the
overloaded type relative to an existing Octave type. I.E. if "a" is of
type matrix and "b" is of type foo then the overloaded type will
supply b.cat(i,a) but the in-built type won't supply a.cat(b,i). This
might cause havoc if the matrix concatenation code is written
hierarchically. Perhaps if there we also had a b.prepend(i,a) function
this problem might be avoided by choosing first looking for the a.cat(i,b)
method and if it doesn't exist looking for b.prepend(i,a).

> BTW, another thing you are going to encounter is that you cannot
> save and load your new galois types.  This will require another
> largish patch.  This patch will be more tricky because the format
> for save/load will affect how the type is rendered.  Octave ascii/binary
> will be simple enough since we just need to write some serializing
> functions and attach them to the type.  As a bonus, I can use these
> for transferring data in an octave client/server application.  

In fact this was going to be one of the next issues I tried to address. If
the new types supply the operators >> and << we should be able to use them
for load/save

> Foreign file formats are a problem since the way the type is
> rendered depends both on the type and the format.  For writing we
> can finesse this with a write_<format>_<type> function.  Reading
> is trickier because we don't know what type it is until we read
> it and we can read it until we know what type it is.  Perhaps each
> format will have a readtag_<format> function which can tell us what type
> the next item is, then we can call read_<format>_<type>.  This
> will only work if the format as type tags for each of its fields
> but that must be the case otherwise we wouldn't be using the format
> as a generic load/save format.

If we can get the octave load/save itself going, the foreign file formats
would be a much lower priority issue for me.

Regards
David