octave-maintainers
[Top][All Lists]
Advanced

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

Re: sosfilt.cc


From: David Bateman
Subject: Re: sosfilt.cc
Date: Tue, 01 Apr 2008 10:23:05 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080306)

Eric Chassande-Mottin wrote:
>>  This will prevent the code running after an error in reading the
>>  argument list. Do you want to commit this to the octave-forge signal
>>  toolbox?
>>     
>
>   
I'm moving this thread off the "sources" list as that list is officially
dead.

> hi, I already committed this code (among other things) about a month ago.
> the code now complies the coding rules you mention.
>   

Ok, I didn't notice the date on the message when I replied.. As the
sources list is dead I imagine it sat in the moderation queue for all of
the month before making it to the list.

> regarding dataread.m, i think that textread.oct in octave-forge does the job
> much better and faster than the code I sent. note that matlab has several
> functions for reading ascii data files. they are redundant. I don't
> think it is worth to have and maintain all of them in octave. cheers, eric.
>   
Unfortunately people seem to expect that Octave is compatible with
Matlab, and so we don't get to choose. We should try and support all of
the text reading functions, but we should probably try to write them in
a way that there is one core function and the others are written in
terms of this function.. This will make the maintenance of the code
easier.. I migrated the dlmread, dlmwrite, csvread  and csvwrite
functions into Octave recently. The texread function should probably be
migrated as well. However, taking a quick look at textread, I wasn't
sure that it was completely matlab compatible and needed some work to
follow the Octave coding standard. It looks like the dataread function
in matlab is the backend for strread and textread, so we should be able
to write all three with a single core function.

It looks like the preferred matlab text reading function is now textscan
and so I suppose we should implement that. However, it seems
significantly more complex than the other functions.

D.

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

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]