octave-maintainers
[Top][All Lists]
Advanced

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

Re: restructuring load-save


From: David Bateman
Subject: Re: restructuring load-save
Date: Fri, 5 Dec 2003 10:13:20 +0100
User-agent: Mutt/1.3.28i

Hi Thorsten,

According to Thorsten Meyer <address@hidden> (on 12/04/03):
> Hello there,
> 
> > octave-ascii
> >
> >           Freeze this one as it is now so we don't have to support
> >           two different native file types for Octave.  Eventually
> >           this could be deprecated and removed.
> >
> 
> please do not "eventually remove" the octave-ascii format from octave. I 
> have been using it extensively as a target format for awk and (later) 
> perl conversion filters to import data from all kinds of proprietary 
> measurement and simulation software into octave.
> The simple ascii format of matlab is not nearly as useful because it 
> does only allow for one (matrix) variable. I really like the level of 
> complexity that the octave ascii format provides.
> Also, I don't really like the idea of having to deal with a complex (and 
> general purpose) binary library to get data from different (ascii) 
> sources into octave.
> Another points for ascii formats:
> if I have an ascii data file (especially one with such a clear and 
> simple structure as octave-ascii) everybody can read it and use the data 
> even if he knows nothing about octave (or hasn't got octave available).
> 

I'd also not like to see this format disappear. However, to allow user
types, an incompatiable change to the exist "string" an "string array" 
saved type will be needed. At present the octave internal type of a string 
matrix is "string", but it is saved in the file as "string array". This
seems to be to distinguish it from an older "string" type. If the name of
the internal octave type is used for all variables, the detection of the
types becomes trivial with a lookup function. 

I suspect that such a change might break your perl code in any case.

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