From help-octave-request at bevo dot che dot wisc dot edu Thu Nov 20 03:22:53 2003 Subject: Re: lists and cell arrays ? From: David Bateman To: taltman at lbl dot gov Cc: David Bateman , Michael Creel , help-octave@bevo.che.wisc.edu Date: Thu, 20 Nov 2003 11:21:40 +0100 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 taltman at lbl dot gov (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 David dot Bateman at motorola dot com 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 -------------------------------------------------------------