From octave-maintainers-request at bevo dot che dot wisc dot edu Mon Jan 13 14:58:56 2003
Subject: Re: overloaded functions
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: David Bateman <David dot Bateman at motorola dot com>
Cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Mon, 13 Jan 2003 15:58:22 -0500

On Mon, Jan 13, 2003 at 03:07:19PM -0500, David Bateman wrote:
...
> In any case, can I ask you another question. Consider the lines
> 
> octave 1> a = gf(1:7,3);
> octave 2> b = [0 a];
> octave 3> c = [a 0];
> 
> where the first line constructs a variable in the Galois field GF(2^3).
> I'd like the next two lines to both return variables in the same Galois
> field as the input, with checking that 
> 
> 1) Matrix and scalar values are valid in the same Galois field
> 2) All Galois variables are defined in the same field.
> 
> However what I get is implicit conversion of "a" back to a Matrix and
> "b" and "c" are then matrix values. I can see some code in pt-mat.cc
> responsible for some of this action, but I'd like to know if you have
> any idea about the easiest way to get the behaviour I want.

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

Anyone have another suggestion?

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.  

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.

- Paul