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.,
> (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"):
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