Re: save function

[David Bateman]

Hamish Allan wrote:

> On Mar 8, 2005, at 15:16, John W. Eaton wrote:
>
> > I don't think we want -ascii2 to mean "do the Matlab-compatible -ascii
> > thing" because it just trades one incompatibility for another.  If we
> > want compatibility, then we have to make Octave's "save -ascii" do
> > what Matlab's does [...]  We can still keep Octave's
> > old -ascii behavior, but we will need rename the option.
>
>
> On Mar 9, 2005, at 2:28, John W. Eaton wrote:
>
> > On  8-Mar-2005, Robert A. Macy <address@hidden> wrote:
> >
> > | Leave alone save function
> > |
> > | I have not experienced any problems with it.  If I don't
> > | want the header, I throw it away.
> >
> > I think that's a good solution, but apparently some people want
> > bug-for-bug(*) compatibility.
>
>
> Speaking for myself, I don't care about compatibility, I just want a 
> way to save a matrix in plain text format with having to post-process 
> it through a Perl script. And I don't think anyone is advocating 
> compatibility with Matlab's broken behaviour, so Octave will always 
> exasperate those people who really need the functionality to save 
> multiple variables or complex numbers that they can no longer load ;)
>
> No, I think Octave's save -ascii behaviour is good as it is. One final 
> compromise I would suggest is that we could make it Matlab-compatible 
> where possible, with ability to re-'load -ascii' being the benchmark. 
> Therefore 'save -ascii var1 var1' would behave differently to 'save 
> -ascii file1 var1', the former behaving like Matlab but the latter 
> saving variable name information, which should be compatible with the 
> usage that Robert described:


As I had a hand in implementing the code as it now stands, let me give 
some feedback. There are  two basic parts of the load/save functions. 
The generic part, that is responsible for generating the headers upto 
the "# type:" line and specific load/save functions for each type. 
Gettting rid of the headers could be done for the save functions, 
however the choice of which specific version of the load function that 
are part of the octave_value is called is determined by the "# type:" name.

Getting rid of the "# type:" line basically then means that we go back 
to a monolithic and non-extensible function that can only load/save 
certain types of variables ("scalar" and "matrix" only). Without the 
header how do you tell the difference between a "int8 matrix" and a 
"matrix" that just happens to have integer values betwwen -128 and 127? 
Frankly the matlab behaviour is brain-dead.

If you want to introduce a matlab compatiable function as a monolithic 
function then a new save type "-mat-ascii" in the same vain as 
"-mat-binary" makes the most sense. However, I see no reason to invest 
myself in such an effort as there are many other ways of achieving 
compatiable results between matlab and octave with fprintf, etc.

Regards
David



--
David Bateman                                address@hidden
Motorola Labs - Paris                        +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
-------------------------------------------------------------