Issue 77215 - CSV Import/Export is lossy due to default numerical rounding
Summary: CSV Import/Export is lossy due to default numerical rounding
Status: CLOSED DUPLICATE of issue 3687
Alias: None
Product: Calc
Classification: Application
Component: save-export (show other issues)
Version: OOo 2.2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: spreadsheet
QA Contact: issues@sc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-10 18:45 UTC by dlm
Modified: 2007-07-06 13:21 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Sample CSV file (77.22 KB, text/plain)
2007-06-08 15:18 UTC, dlm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description dlm 2007-05-10 18:45:24 UTC
I regularly use the CSV import and export features in Calc to edit simple 
parameter input files for numerical computation models. By default Calc 
displays 2 decimal point precision in all cells. This seems to be arbitrarily 
based on the notion that any floating point number is a currency. It is 
irritating to have to change the displayed precision manually (especially when 
this typically results in resized columns)

More importantly, upon export (file, save as) Calc by default outputs the 
displayed 2dp precision instead of the actual precision. I eventually figured 
out I could change this behavior by editing filter settings, but these setting 
reset upon restart. Thus, I always face the risk of losing precision if i don't 
check my export settings carefully. I do not have the same problems in 
Microsoft Excel.

My proposals are:
1. default behavior maintains full precision for non-native file types that do 
not support display formatting:
a) on display after csv import unless the user selects otherwise.
b) on output after csv export (again unless the user selects otherwise).
2. persistent text import settings be stored (output formatting, delimiters 
etc) allowing one click opening under preferred settings
Comment 1 kpalagin 2007-06-08 05:21:17 UTC
dlm,
please attach sample file.
Comment 2 dlm 2007-06-08 15:18:06 UTC
Created attachment 45759 [details]
Sample CSV file
Comment 3 dlm 2007-06-08 15:21:05 UTC
I've attached the sample. If you open this with default settings you will 
notice two annoying things: massive column widths, rounding by default. Next 
save the data using default settings then reload it and you will see that 
decimal precision is lost (check out columns O through Y before and after)
Comment 4 kpalagin 2007-06-25 05:24:55 UTC
Confirming with 2.2 on WinXP - numbers are rounded.
Big column width seems to be expected - you have that much text in column.
Comment 5 dlm 2007-06-25 11:45:46 UTC
If there were 100,000 characters before the first comma would the column width 
be 100,000 characters wide? by default, truncating the display of data to a 
standard width and running into the next column if the cells is empty is much 
more usable. If I want a quick overview of what's in a file it's painful to 
have to shrink the col width down, adjust precision etc...
Comment 6 dlm 2007-06-25 11:50:54 UTC
just to clarify: text is a second class citizen in spreadsheets. ideally column 
width should be maximum of standard width or minimum width to display "widest" 
number in the column.
Comment 7 kpalagin 2007-06-25 12:51:08 UTC
dlm,
please describe how competing spreadsheet sets column width for long strings.
Comment 8 dlm 2007-06-25 14:19:20 UTC
I'm not sure how other spreadsheet apps handle column widths for imported data, 
but excel uses a default width that is large enough to display a double in 
scientific notation with 2 dp of precision (or alternatively a date in DD-MMM-
YY/MMM-DD-YY format) at standard font size. Text that is too large to fit 
within a column will spill into the next if it is empty, or is otherwise 
truncated. Numbers that are too large (such as numbers in currency format) 
typically display as "######", although perhaps it would be better to extend 
the width to the minimum width required to display dates and numeric types in 
full.
cheers.
Comment 9 frank 2007-07-06 13:21:05 UTC
basically double to Issue 3687.

@mmp

please comment on Issue 3687 and consider this one for this case also.

Frank

*** This issue has been marked as a duplicate of 3687 ***
Comment 10 frank 2007-07-06 13:21:28 UTC
closed double