help-octave
[Top][All Lists]
Advanced

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

Re: xlsread in Octave 3.6.4


From: Philip Nienhuis
Subject: Re: xlsread in Octave 3.6.4
Date: Sun, 12 May 2013 21:26:52 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]