GNOME Bugzilla – Bug 126444
'-0' instead '0' in a exported text file
Last modified: 2010-06-30 16:41:23 UTC
If I open this .gnumeric file and save it as a text file (with configurable text export), I obtain: -0 0 as a first line. Why exporting '-0' instead of '0' ?
Created attachment 21272 [details] The gnumeric file that shows the problem
Confirmed. Looks mighty silly.
Hmm... the file contains "-0". Any ideas why that came about? <gmr:Cells> <gmr:Cell Col="0" Row="0" ValueType="40">-0</gmr:Cell> <gmr:Cell Col="1" Row="0" ValueType="40">0</gmr:Cell> <gmr:Cell Col="0" Row="1" ValueType="40">1000</gmr:Cell> <gmr:Cell Col="1" Row="1" ValueType="40">-4.5949999999998</gmr:Cell> <gmr:Cell Col="0" Row="2" ValueType="40">2000</gmr:Cell> <gmr:Cell Col="1" Row="2" ValueType="40">-8.63900000000012</gmr:Cell> <gmr:Cell Col="0" Row="3" ValueType="40">3000</gmr:Cell>
I think it comes from an xls file that somebody sent to me. I don't know more. Thanks for the quick reply. Frédéric
Would we be able to get a copy of the xls file in question ? It can be kept confidential if necessary.
In fact, it was not from an excel file. It was from a standard gnumeric file where I had imported some text data. I attach a .gnumeric file. The operations to reproduce the problem are: -go to a free cell (for example D1) enter '-1' and press 'Return' -go to celle D1 and copy it (Ctrl-C) -select cells A1-A3 -go to 'paste special', and select 'as value' and with the multiplication operation. Validate. -Now, export as configurable text => the last line is '-0 0' Sincerely. Frederic
Created attachment 21293 [details] This is the gnumeric file to reproduce the Bug.
The value really is -0 (a perfectly valid ieee bumber). stf_export_cell uses value_get_as_string (it shouldn't) and that comes down to a printf.
Morten: Why shouldn't stf_export_cell use value_get_as_string?
Andreas: value_get_as_string generates stuff whose main property is that the Gnumeric parser will take it. There is no reason to tie our text output to whatever arbitrary choices went into that. Of particular concern will be the special values like -0, +/-Inf, and the many NaNs.
This is still present in 1.6.3.
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 this fix only occurs in the "Auto" formatting. If you export "raw" we assume you want to see the numbers as they are currently stored, ie. -0 would be possible.