Re: overloaded functions

[Paul Kienzle]

On Tue, Jan 14, 2003 at 11:54:03AM +0100, David Bateman wrote:
> > 
> > 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.

I was staring at the code last night.  The problem with a pairwise
cat operation is that there is no way preallocate a large enough array
for the resulting matrix because you don't know what type the resulting
matrix will be.  I suppose the interpreter could do a pass to make sure
that all the components are real/complex/string and do the usual
concatenation, otherwise use the cat operator supplied with the type.  
That will preserve performance in the usual case.  

To provide the same performance as builtin types, I think we need a
cattype operator which given a pair of types returns the resulting type.
Then we can tell the type to preallocate an array and use subasgn to
fill the blocks with octave values.  Or maybe a streamlined subasgn which
does not do size checking.

> 
> > 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);
>       ...
>     }

I believe cat will only see octave_value inputs and expect octave_value
outputs, but that doesn't matter.

Consider the case of a [ A, B ] where A is an octave matrix and B is
octave_foo.  If you want the result to be octave_foo, then you need to
extend the octave_matrix class, which as an add-on type you are not
privileged to do.  As an operator A cat B, you can look up in a table
the function you need to call which knows about both the type of A and
the type of B.  octave_matrix doesn't need to know about octave_foo
because you can put in the matrix cat foo operator when you install the
octave_foo type.

This even works if both A and B are extension types, assuming one or
the other of types A and B installs the foo cat bar operator.  And you
do not need the prepend suggestion I snipped out below.

<snip>


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

It may be nice to have binary serializers as well, but in that case we will
also need a way of detecting and correcting byte order.  My preference is
to make the usual case fast, which means saving the file in native order and
doing the correction on load if for some reason it is being loaded on a
different kind of machine.  

I don't know if we should concern ourselves with non-ieee floating point
representations.  If the binary files had some indicator of the
represenation they were stored in, and if all numeric data is read through
an octave supplied function which can read any format into native order
then it doesn't add any complexity to the type supplied binary serializer,
so I guess non-ieee reps aren't so bad.

Paul Kienzle
address@hidden