octave-maintainers
[Top][All Lists]
Advanced

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

Re: xlsread in Octave 3.6.4


From: pr . nienhuis
Subject: Re: xlsread in Octave 3.6.4
Date: Wed, 5 Jun 2013 15:53:12 +0200
User-agent: SquirrelMail

Hi Markus

(Please don't top post)

(discussion moved to maintainers list as that's the place where pkg
development stuf belongs as well)

Op Ma, 3 juni, 2013 10:35 am schreef Markus Bergholz:
> now it's faster than matlab!! matlab takes  ~100 seconds xlsxread in octave
> ~80 seconds
> http://p.osuv.de/index.php/ZuBLam/ (autodelete after 5 days)
> i will push my modifications later.
>
>
> On Sun, Jun 2, 2013 at 10:25 PM, Markus Bergholz <address@hidden>
<snip>
>>>> 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).

AFAICS it only processes .xlsx.
Pity it doesn't do .xls (BIFF8 and older BIFF5) but OK that'll die out
slooowly in the next years.

Note that the way you do this should work similarly for .ods files, as
they are mere zipped XML files, just like .xlsx (OOXML).
In fact, in the io package, in (IIRC) private/__getusedrange_ODS__.m
there's a (not-so-well vectorised) skeleton for .ods; it is only used to
explore nr of rows and columns, but could be amended to read values as
well. The office-value:<TYPE> attributes in <table-cell>s can be used to
sort on value type.

Anyway I'd love to include your stuff in the io package, but for that some
further works needs to be done:

- It should comply to the setup in the xls2oct.m and
private/__spsh2oct_<INTF>__.m files, i.e., it should be rewritten as a
mere interface just like all the others.

- It should be able to return just the contents of a user-specified range
of cells.

- It should be robust to e.g., merged cells, etc.

- Error checking should be there (proper type of file etc.).

I have no time now (I'm in the US for a conference) but if you want I can
come back to it later.

Philip



reply via email to

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