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: Philip Nienhuis
Subject: Re: xlsread in Octave 3.6.4
Date: Tue, 15 Oct 2013 22:59:02 +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

Hi Markus:

Markus wrote:
Am 2013-10-04 14:50, schrieb Philip Nienhuis:
I'll start but it's not finished.
I've pushed my commits i made last week, but it's broken and now it
beats me.

xlsread('../../example/excel2010.xlsx', 1, [],{'OCT'})
Checking requested interface(s):
OCT*; (* = default interface)
error: cellfun: C must be a cell array
error: called from:
error: /home/markus/Downloads/newxlsxread/io/inst/xls2oct.m at line 219,
column 11
error: /home/markus/Downloads/newxlsxread/io/inst/xlsread.m at line 199,
column 22

I'd say the good news is that it already gets that far.

AFAIR your xlsxread.m returns a double array.
However, xls2oct.m expects the output from __OCT_xlsx2oct__.m to be a cell array. It has to because otherwise numeric and string data cannot be mixed. This was originally motivated because ActiveX/COM (= Excel behind the scenes, and the first interface I built back in 2009) returns a cell array. The separate function parsecell.m is meant to separate those data ypes outside xls2oct.

Changing this workflow is of course possible but probably an enormous hassle.
mat2cell or num2cell looks to be the solution for now.

Perhaps you have time to take a look at it. But I'm busy till sunday again.

Yep I'll have a look.

Philip


reply via email to

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