Date: Sun, 27 Jan 2008 20:24:11 +0100
> From: Olivier Lefevre <lefevrol@...>
> Subject: [OctDev] Probable xlsread bug
> To: octave-dev@...
> Message-ID: <fnilou$fru$1@...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> NB: This is a repost of a month-old posting on the general Octave
> mailing list, where it met with a chilly reception, on the ground
> that this is an Octave Forge and not an Octave issue.
>
> If you read in, e.g.,
>
> 6.9,5.2,6.3
> 7.3,,6.2
>
> (that is, the tabbed equivalent) the 3x3 matrix that comes out is not
>
> 6.9 5.2 6.3
> 7.3 NaN 6.2
>
> as you'd expect but
>
> 6.9 5.2 6.3
> 7.3 6.2 NaN
>
> i.e., I assume it skipped the missing value and the NaN that comes
> out in the back is the padding needed to make the array rectangular.
> Thus you'll (usually) get the right number of NaNs but in the wrong
> places! SciLab's readxls gives what you'd expect. I don't have MatLab
> at the ready to check but it sure looks like a bug: if it were a
> deviation I assume the help entry for xlsread would warn you about
> it, no?
>
> In addition xlsread is extremely slow. In fairness when I wrote my own
> version to work around that bug, it was just as slow: line tokenizing
> and number parsing seem just slow in Octave.
>
>
I too have been recently bothered by io functions in octave (forge).
See my emails here (look for "dlmread"):
http://sourceforge.net/mailarchive/forum.php?forum_name=octave-dev
I think writing xlsread or dlmread in c++ would help a lot with the
speed issue. In fact, the c++/oct version of dlmread is very fast, but
for some reason it is not accepting the tab delimiter. I may try to
re-write that function myself in c++ but am not sure when I will have
the time.
Jonathan
|