octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Load/Save changes to Octave CVS


From: David Bateman
Subject: Load/Save changes to Octave CVS
Date: Wed, 7 Jan 2004 11:31:11 +0100
User-agent: Mutt/1.3.28i

Dear All,

John recently committed a patch to the load/save functionality from me
to the octave CVS. This code allows many more types to be correctly
saved and loaded, as well as allowing N-D arrays and user defined
types to be loaded and saved. However, as there might be some
compatiability effects, I felt it is important that those that might
be affected by these changes are made aware of exactly what they are.

My major motivation for this code was to allow user defined types to
be saved. So I'll rapidly include code and documentation into octave
forge to save the Galois field type that the sparse, symbolic, etc
types might also use as an example to get load/save functionality as
well.

The changes affect the octave ascii and binary formats as well as the
HDF5 format, and are summarized below

OCTAVE ASCII FORMAT
-------------------

* Create the functions "save_ascii" and "load_ascii" that form part of
  the octave_value and move the specific load/save functionality for the
  individual types to these functions, specifically allowing extensiblity 

* Add the ability to save the types "bool", "bool matrix", "struct"
  and "list"

* Add the ability to save N-D variables

* Save the type that was once called "string array" as "string" as this
  corresponds to the name of the type within octave

Forward compatiability is completely maintained. Backward compatibility
is maintained except for the newly introduced types, the N-D variables
with 3 or more dimensions, and for "string" types. 

OCTAVE BINARY FORMAT
--------------------

* Create the functions "save_binary" and "load_binary" that form part of
  the octave_value and move the specific load/save functionality for the
  individual types to these functions, specifically allowing extensiblity.

* The old format used a "char" with the value 1 to 7 to specific the type
  of the saved variable. This was not flexibible, and so the name of the
  type itself is now saved as a string. To maintain forward compatibility
  this format is specified by the type 255.

* Add the ability to save the types "bool", "bool matrix", "struct",
  "list" and "cell"

* Add the ability to save N-D variables

Forward compatiability is completely maintained. Backward compatibility is
lost, so you can't save with the new code and load with older versions of
octave. This might also have implications for external programs that use
files saved in the octave binary format.

HDF5 FORMAT
-----------

* Create the functions "save_hdf5" and "load_hdf5" that form part of
  the octave_value and move the specific load/save functionality for the
  individual types to these functions, specifically allowing extensiblity.

* The old HDF5 format attempted to figure out the variable type from 
  implicit information in the file. For example a dataset of rank 0
  with a scalar value in it became an octave "scalar", while a dataset
  of rank 2 with compound values with two scalars became a complex matrix.
  This implicit means of determining the type is not flexible, and so the
  HDF5 format has been changed to explicitly save the name of the octave
  type.

  The format is changed in that all variables are now saved as an HDF5
  group, containing a dataset called "type" containing the octave type 
  and a dataset/group called "value" containing the saved data.

* Add the ability to save the types "bool", "bool matrix", "struct" and
  "cell"

* Add the ability to save N-D variables

Forward compatiability is completely maintained, with a bit of cruft in
the code. This also maintains the ability to import data from external 
sources into octave. However backwards compatility is lost. This will
have implications for the use of files saved by octave with external
programs.

Regards
David

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]