[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #55828] [octave-forge](io) csv2cell doesn't re
From: |
Philip Nienhuis |
Subject: |
[Octave-bug-tracker] [bug #55828] [octave-forge](io) csv2cell doesn't recognize some numeric input |
Date: |
Mon, 4 Mar 2019 15:56:34 -0500 (EST) |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 |
Update of bug #55828 (project octave):
Release: 5.1.0 => other
Summary: io csv2cell doesn't recognize some numeric input =>
[octave-forge](io) csv2cell doesn't recognize some numeric input
_______________________________________________________
Follow-up Comment #1:
I can confirm the behavior.
I can also following the logic that the field containing 3.0 would be expected
to be read as a double value.
But IMO there's _also_ something to say for treating fields containing
non-numeric chars (incl. +-.E) as text.
How does other csv reading software treat numbers enclosed in spaces in data
fields?
If I read the file with LibreOffice I get some import scheme dialog; entering
just a comma as separator and then saving the resulting spreadsheet as an .ods
file, I get the exact same results as with csv2cell:
>> [~, ~, d] = odsread ('bug55828.ods')
d =
{
[1,1] = a
[2,1] = str_a
[1,2] = b
[2,2] = 3.0
[1,3] = c
[2,3] = 18
}
>> cellfun (@class, d, "uni", 0)
ans =
{
[1,1] = char
[2,1] = char
[1,2] = char
[2,2] = char
[1,3] = char
[2,3] = double
}
But reading the file with Excel 2013 and processing the result with the Data |
Text to Columns option it does give 3.0 as a double.
Matlab r2019a's importdata also reads the " 3.0 " field as a double value.
Furthermore csv2cell reads the following file:
1 , 2 , 3
4, 5, 6
as all double values.
Just wondering if there's a formal rule or a convention as to spaces in number
fields in .csv files (apart from core dev Rik's "principle of least
surprise").
Until that is clear I'm tending to just postpone treatment. I'll gladly
conform to a common opinion.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55828>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/