Hi Guillaume, as promised :-)
On Apr 16, 12:15 pm, "jOpenDocument, Guillaume" <g...@jopendocument.org> wrote: > Hi, > Is something goes wrong or is missing for Octave, don't hesitate to > write me about it. > We would be pleased to add Octave in the Success Stories. Oh, me too :-) Yes, sure. I'll shamelessly ask for some guidance (in the "missing for Octave" perspective): => How can I reliably check for cells with illegal values, like #Value or Err:502 etc. You know, things like log(-1), or division by zero, or a text string divided by 15, or a formula with a reference target in an other sheet that disappeared three versions of the spreadsheet ago. Obviously I can get the text value and string compare for #Value and Err:502 stuff but that is 1. ambiguous and 2. therefore unreliable. If I use <cell>.getValue ().doubleValue () I get 0 (zero). But I'd rather have an empty cell value (or a NaN) value there, or even a java exception as I can use a try...catch to do the proper thing then. For octave, a numerical 0 value is definitely wrong in these cases. => How can I get the *actual* number of columns and rows that contain data? (I've asked before) If I do <sheet>.getColumnCount or <sheet>.getRowCount, I often get 1024 or 65536, resp, as often the last cell in a row is used as a filler using the Table-Number-Columns-Repeated attribute to fill up to 1024 cols / 65536 rows. Often OO.o-generated ods spreadsheets contain these 'filler" columns/ rows; not always however. In odfdom I can access the last table-cell (not: spreadsheet cell) in a row and explicitly check for this attribute - if found I subtract its value from the last spreadsheet cell index. I still have to iterate over all rows. Yes this is slow, *but* it pays off on the octave side (see below). Similar reasoning goes for rows (table-number-rows-repeated attribute). In jOpenDocument this is all shielded away; I suppose jOpenDocument simply counts all cells and adds all (table-number-columns-repeated attributes - 1). Example: If a row contains only 10 data cells, and the 11th cell is empty save for a table-number-columns-repeated=1014, I have to access and test 1014 cells just for nothing. Only 1 % of the row is a "hit", then. Again, same goes for rows. Part of the problem is this: - For Octave I have to reserve octave data space (= an array) in advance (outside java JVM memory space BTW). It is very inefficient to start with a small one and augment rows and columns later when the initial size proved too small, as that involves copying data in memory around to keep the array contiguously. - As for execution time it is more efficient (but memory-wise, very much more INefficient) to have to needlessly reserve a 1024 X <many rows> array if in the end only 10 X <many rows> are used. - So when I want to read a spreadsheet it would be very handy to be able to know beforehand what octave array data size I should reserve. Would you have any suggestion how I can explore this occupied spreadsheet data size using jopendocument v. 1.2b3? Enough asked :-) Best wishes, Philip -- Subscription settings: http://groups.google.com/group/jopendocument/subscribe?hl=en
