Re: lists and cell arrays ?

[David Bateman]

Tomer,

See my code in octave-forge/main/comm which introduces a Galois Field type.
The problem can be seen in the example

octave:1> a = gf(0,3); b= gf(1,3);
octave:2> c = [a, b];
octave:3> whos

*** local user variables:

prot  type                       rows   cols  name
====  ====                       ====   ====  ====
 rwd  galois                        1      1  a
 rwd  galois                        1      1  b
 rwd  matrix                        1      2  c

"galois" is a real octave type, not a data structure. But as a type
introduced in an oct-file, it is in the unprivledged position of not
having access to the concatenation operator, or the load/save functions
in the current scheme under Octave. This is why I was cheering John's
statement on introducing the "horizcat" and "vertcat" functions.

I've been thinking on how to fix up the load/save issue as well, and I
think this could also be fixed fairly easily by introducing into ov-base.h

void * oct_ascii_load (void);
void * oct_ascii_save (void);
void * oct_binary_load (void);
void * oct_binary_save (void);

bool have_oct_ascii_load { return false; }
bool have_oct_ascii_save { return false; }
bool have_oct_binary_load { return false; }
bool have_oct_binary_save { return false; }

and appropriate virtual functions in ov.h. Then modify ov-oct-{ascii,binary}.cc
to do something like

bool
save_ascii_data ......

{
  if (val_arg->have_oct_ascii_save()) {
     val_arg->oct_ascii_save();
  } else
    // The old version of the code
  }
}

bool
load_ascii_data ......

{
  if (val_arg->have_oct_ascii_load()) {
     val_arg->oct_ascii_load();
  } else
    // The old version of the code
  }
}

The the user type can overload the oct_* methods and setup the
have_oct_* functions appropriately. Similar things could also be done
for the Matlab and HDF file formats. This seems a means to get
load/save functionality for user type with the least pain. Eventually
all types could be converted to do load/save via this technique, but
there are cases which will need special attention, in that they currently
don't have their own load/save (notably boolMatrix, etc).

Would such a change be acceptable? If so I wouldn't might coding it up...

Regards 
David

According to address@hidden <address@hidden> (on 11/19/03):
> Please see my comments below:
> 
> On Nov 18, 2003 at 5:06pm, David Bateman wrote:
> 
> David. >Date: Tue, 18 Nov 2003 17:06:31 +0100
> David. >This is one of my pet peeves with octave, in that user defined types 
> can't
> David. >use concatenation. So I vote for a generic concatenation code. I just
> 
> I think you're talking about two things here. Built-in types
> vs. user-defined data structures. Octave's data types, namely,
> strings, matrices, cell-arrays, (deprecated) lists, and
> associative-arrays (aka "structs"), should have high-level syntax for
> concatenation & other useful functions. I don't believe that it's
> possible for a programming language to have standard operators for
> user-defined abstract data structures, since a wily user can create
> all sorts of crazy data schemes. :-)
> 
> ~Tomer

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------