Re: Fwd: Test files [WAS: Re: xlsread in Octave 3.6.4]

[Markus]

Am 2013-09-20 13:56, schrieb Philip Nienhuis:
:
<snip>
:
> 1) get rid of the named NaN cols and rows who Matlab ignores too
>
> If there are extremely many of those, and reading them from XML takes
> lots of time, sure, invest there.
> Otherwise, have a look at xls2oct.m in the io package, it has a final
> section for stripping enveloping empty rows and columns. It may do
> just what you need.

I've got already an idea how to do that. It will simplify my __readnr 
function too.

> 2) implement Date and Time interpretation. (never take a look at it)
>
> At that point (date & time) the OF io package is not compatible with
> Matlab. There are several reasons for that, but I won't digress into
> those. Just note that severe headaches are looming.
> Octave's xlsread returns numeric date "values" for dates later than 31
> Dec 1899, and text strings for earlier dates; Matlab's xlsread usually
> -not always- returns all dates as text strings. To convert numerical
> Excel date values (in the 1/1/900 date system) to Octave datenums just
> add 693960

"although I can imagine this to be a desirable option for many users 
too." :P
But I will not say it too loud :D


> 3) clean up the code
> 3.1) here and there little optimizations
> 3.2) split and merge everything for OF-io package.
>
> > specifying sheets by name and/or by index number
>
> This is implemented long time ago ;) You can do
> xlsxread('filename.xlsx','Stupid Map Name') or
> xlsxread('filename.xlsx',2) for example.
>
> What does the index stand for? ("2" in the second example)
> Is it the position of the worksheet tabs counted from the left, or
> the order in which the worksheets have been created (age)? Perusing
> the XML in expanded .xlsx files I couldn't say with certainty.
> In the io package it is the former.
>
> etc etc.

The first one. From left to right.
But I can't confirm that Excel is soring them by age (after a very 
quickly test).

:
<snip>
:
> You mean: bug #39148?
> There's an easier solution: simply including the patched unpack.m from
> Octave 3.7.x in the OF io ./inst dir, it would then shadow the "buggy"
> unpack function from core Octave 3.6.x
> The only potential harm would be a (another?) start-up message about
> shadowing that may arouse some overly cautious novice users.

By the way. I'll try a MXE build to test xlsxread in Windows. It said 
that the unzip command was not found.
That's bit strange because the mxe build include system('awk') 
successful for example.
Do you have any ideas what goes wrong?

> I do plan to make one more OF io package release (1.2.4) for Octave
> 3.6.x in the next weeks; I plan to include the Java-free odsread there
> (almost ready), hopefully also your xlsxread.
> For those two new features I'd need the patched unpack from 3.7.x as 
> well.

If you mean with "next weeks" at least two weeks, i guess yes.
Tomorrow I'll going to clone octave-io an start including it.

:
<snip>
:
> 4. Closing the spreadsheet file;
> (Extremely easy)
>
> This is the first i do in __readnr :D
>
> Yes but then you'll loose the unzipped temp dir. For each successive
> worksheet in the same file you'd have to unpack it again, imposing a
> potentially severe speed penalty.

With closig i mean fclose.
I delete the tmpdir in the last line of xlsxread function.
But i try to comprehend who octave-io is handling it.



cheers
Markus