octave-bug-tracker
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]