From octave-maintainers-request at bevo dot che dot wisc dot edu Wed Dec 18 22:00:43 2002 Subject: Re: Octave-MPI via oct-files From: Paul Kienzle To: JD Cole Cc: octave-maintainers at bevo dot che dot wisc dot edu, Andy Jacobson , "John W. Eaton" Date: Wed, 18 Dec 2002 22:59:39 -0500 On Wed, Dec 18, 2002 at 03:18:21PM -0800, JD Cole wrote: > > You'll notice after grazing the code that I have copied the > read/save_binary_data functions and their depencies into mpi_send/recv. > This was done because I wanted that functionality but currently these > functions are "static" in load-save.cc in the Octave source. Of course, > I would rather not duplicate code, if I can avoid it, so I'm wondering > if it would be wrong to expose those functions in load-save.cc? load-save is a big problem. We want to be able to allow user defined types to load and save themselves, so the serialization code should be a method in octave_value. But it would also be nice to define a new file format in an oct file and have it work as if the format was built into load/save. As an example, consider the sparse matrix package in octave-forge. How can we design octave so that sparse matrices can be loaded from and saved to octave/matlab/hdf files without modifying load-save.cc? Could someone define a separate package which for example extended load-save to handle Maple file formats (if there is such a thing)? How could the maple-file package handle sparse matrices? Could a third party write the sparse handler for maple format without modifying sparse or maple? The only way I can think to handle this is to have a mapping from {type, format} into handler. For save, if there is no handler for saving that type for that format then the format driver could either ignore it, save a value of "undefined" or maybe save the value as a "foreign" type using the octave_value serializer method which each type must define so that even though other applications wouldn't handle it correctly the file could be reloaded in octave. Of course, appropriate warnings about unsupported values should be issued. Load is tricky since you don't know what type it is in advance, so you won't know what type-format handler to call. For well defined formats you could ask each type handler for that format if it understands the type specifier. For octave files, this would be a string. For matlab binary files this would be an integer. If no handler is found for that specifier, hopefully the entry can be skipped (with an appropriate warning) and the next value loaded from the file. Presumably the format driver would recognize undefined/foreign values and restore the appropriate octave type directly without checking through each handler. Is this too complicated? > > Also, since LAM MPI is quite sensitive to the sequence of calls > lamboot->MPI_Init-> (other MPI calls), i.e. it terminates a program > without remorse, I install a global variable octave_mpi_session_flag > which allows MPI functions to tell if MPI_Init of MPI_Finalize have been > called. (I have considered implementing this variable as shared memory, > i.e. external to Octave, as to not used octave internals such as the line: > > symbol_record *sr = global_sym_tab->lookup("octave_mpi_session_flag"); > > if that practive is considered "taboo".) I believe there is a function get_global_value("name") which would continue to be part of any well defined API for octave once we defined one. Paul Kienzle pkienzle at users dot sf dot net