Re: xlsread in Octave 3.6.4

[Markus Bergholz]

On Sun, May 12, 2013 at 9:26 PM, Philip Nienhuis <address@hidden> wrote:

Markus Bergholz wrote:

On Wed, May 8, 2013 at 10:06 AM, PhilipNienhuis <address@hidden

<mailto:address@hidden>> wrote:

    E4
    Markus Bergholz wrote
     > I haven't follow this thread and it's issue, but i've wrote a
    xlsxread
     > function whitch don't need java.
     > but it's very very rudimentary, works just with linux and is a
    quick&dirty
     > write-down.
     > furthermore, you have to remove the string-analyse part, if your
    sheet
     > don't contain strings.
     > but maybe it helps someone else or someone want to improve it or
    someone
     > rewrite it in c/c++ as oct file, to get it even faster than
    matlab (for me
     > it's still faster than the java stuff atm).
     >
     > http://git.osuv.de/Octave/tree/functions/xlsxread.m

    The Java based options are relatively slow as they offer maximum
    flexibility
    as regards data types.

    Before venturing in COM/ActiveX and Java based solutions for the io
    pkg 4
    years ago I've looked at a few other solutions, similar to yours.
    IIRC the
    most promising one was posted in an OpenWatcom news group. All of
    them (i.e.
    the "free solutions") suffered from the same limitations: lack of
    flexibility, lack of documentation, dependency on some very specific
    development framework, and/or bound to specific .xls formats (BIFF5,
    BIFF8,
    OOXML, what not).

    If you want I can look if your code can somehow be absorbed in the
    io pkg as
    a sort of fall-back option.


i don't think that this is a good idea :D as i said, it just works with
linux (i'm using sed and unzip through 'system' command. furthermore, i
made quick&dirty my own tmp-dir (mktemp -d would be better). aaaaaand so
on :)

    To that end it needs a suitable license


i don't care about the licence as long as it's a free licence.

    and
    someone should support/maintain it (my C/C++ skills are rudimentary).

    Philip


my c/c++ skills are rudimentary too :)
if you like, we could code together on github on a xlsxread function e.g..
it is not so difficult but it is extremely time-consuming to parse the
shitty ms xml format!! (i don't read any specs yet, just do some lousy
reverse engineering).

Weighing the amount of work needed to build a good, robust and fool-proof C+/C-based xlsread backend versus already having available a well-tested choice of working (albeit relatively slow [1]) solutions, I just fail to see the benefits of reinventing the wheel.

Just for the record & to emphasize an important aspect, I myself don't use xlsread (or xlswrite), I usually invoke the much more flexible xlsopen-xls2oct-[parsecell-]oct2xls-xlsclose sequences. So we'd be talking about another interface in xlsopen/xls2oct/xlsclose rather than xlsread.

Philip

[1] OpenOffice / LibreOffice are really fast for large spreadsheets, I doubt a 2-person amateur team can beat the OOo/LO devs as regards speed tuning; the only problem is start-up time of OOo/LO.
Oh and there's a currently unsolvable Java-UNO issue outlined when you use it for the first time.
BTW a while ago I had a try with Starbasic (& ActiveX) invoking LibreOffice for spreadsheet I/O. I already had some success, but I had to put it away due to lack of time. Maybe next summer I can look at it again. Maybe that can be made cross-platform too.

I've do a rewrite of my xlsxread function and push it to github https://github.com/markuman/xlsxread/ 

it is ~10% faster now, (still faster than the java version, but still slow!)

Theoretical this could work in windows now too, but the unzip command in octave don't accept the .xlsx extension:

warning: unrecognized file type, .xlsx 

So i have to use a system command again (see line 47-51 https://github.com/markuman/xlsxread/blob/master/xlsxread.m )

strings are not recognized too atm. so it's still limited.

if someone has an idea how to improve it, i'd like so see some forks :D