From octave-maintainers-request at bevo dot che dot wisc dot edu Wed Jan 7 04:31:41 2004 Subject: Load/Save changes to Octave CVS From: David Bateman To: octave-maintainers at bevo dot che dot wisc dot edu Date: Wed, 7 Jan 2004 11:31:11 +0100 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 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