Re: overloaded functions

[Andy Adler]

On Tue, 14 Jan 2003, Paul Kienzle wrote:
> On Tue, Jan 14, 2003 at 11:54:03AM +0100, David Bateman wrote:
> > > 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 like this idea. I've been wanting to support this for the
sparse matrices.

>From an efficiency point of view, "cat" should take all the arguments
to the function at the same time.

Otherwise
    [a,b,c;d,e,f]
will turn into
     cat(1, cat(2, cat(2,a,b), c) ,  cat(2, cat(2,d,e), f) )
which would potentially be much less efficient.

As a minimum, cat should pack all the elements in each direction
     cat(1, cat(2,a,b,c) , cat(2,d,e,f))

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

This sounds good too. An extension function can register the
"cat"s that it can handle with the cattype operator at load time.
This would perhaps look like:

   INSTALL_BINOP(op_mul, octave_complex_sparse, octave_matrix,         
cs_f_mul);
   INSTALL_BINOP(op_mul, octave_complex_sparse, octave_complex_matrix, 
cs_cf_mul);
   INSTALL_BINOP(op_mul, octave_sparse,         octave_complex_matrix, 
s_cf_mul);
   ...
   INSTALL_CATOP(op_cat, octave_complex_sparse, octave_matrix, my_cs_f_cat_fcn);

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

Currently I believe we have an octave text format, and the various Matlab
compatible and HDF formats. I think it would be better to enhance this support
for new types rather than add an octave binary format.

andy