GNOME Bugzilla – Bug 697107
incorrect reading of data
Last modified: 2013-04-04 16:58:26 UTC
In the attached .gnumeric file, the use of the transpose function in the definition of the chart data is supposed to imply a reading of the data by columns and not by rows. This works, but it seems only the first column is read. Is this a bug or are we suppose to specify the size of the matrix somewhere?
Created attachment 240386 [details] .gnumeric file to reproduce the problem
You have only defined one series. Why would you expect to see more than that?
Andreas, remove the transpose calls and see how things look. Some points are incorrectly displayes at (0,0) actually.
When a serie contains empty cells, these imply line breaks. Hence three different lines are expected in the example provided, since it contains 3 empty cells.
It would probably be useful to document the desired behaviour in the Gnumeric documentation. It may be true that "when a series contains empty cells, these imply line breaks" but I cannot see any reason why that would be the desired or even the target behaviour. For me the sample file looks completely reasonable. The behaviour I see if I remove the "transpose" does not look reasonable. We should also note that 'transpose' is a matrix operation. The result of that operation does not have any 'empty cells'. The 'empty cells' in the input to TRANSPOSE turn into 0s this is consistetn with this being a matrix function, rather than a function that rearranges cell regions.
There are many situations when you want missing data to be represented by line breaks in a chart. If you have to enter n different series in gnumeric, that will make charts a lot less convenient. If transpose is really a matrix operation and not a function that rearranges cell regions, then we need an option in the chart dialog to specify if cells are read by rows or by columns.
TRANSPOSE translates empties to 0 for compatibility reasons. Other than that it really is a function that rearranges cell regions. In particular it transposes strings, booleans, and errors just fine making it clearly not a matrix function.
OK, so why the transpose function does not give the expected result in the example which has been provided? Note that replacing the empty cells with 'NaN' in the 4th lines does not change the problem.
The tanspose function gives the expected result, the graph code doesn't interpret it correctly.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. Note that the arrays are always evaluated by rows for consistency.
Fixed in stable actually, of course.
Morten, if TRANSPOSE is not supposed to be a matrix function in Gnumeric, then our documentation shouldn't really call its argument a 'matrix'.
Morten was referring to a matrix in a mathematical sense (with only numbers), the documentation refers to a matrix in an informatic sense.
We are claiming compliance with regard to ODF 1.2 OpenFormula where the term matrix is very clearly used in the mathematical sense. Moreover if matrix were used in a "informatic" sense (whatever that means) then blanks would not become 0s!