PSPP-BUG: [bug #24574] Decimal point behavior in data import not so great

[Ben Pfaff]

Follow-up Comment #2, bug #24574 (project pspp):

Jeremy Lavergne <address@hidden> passed along this comment from
"Patrick Noué" <address@hidden>:
>just forgot to mention that importiation of CSVs isn't right the first
>time in PSPP. 
>
>The first issue is minor, and could well be classified under
>"ergonomics" than a bug per se. The column coming out as "VAR001" has
>to be selected as "DOT", with "2 decimal places". Point is, LibreOffice
>outputs CSV according to locale, including commas as decimal separators
>and no thousands separators. As worldwide usage of dot and comma as
>decimal separators is roughly half-and-half, and that CSV format
>doesn't store that info, it may be useful to add a "use comma as
>decimal separator" case on the "separators" choice panel, especially
>since I preferred to use the tab as column separators.
>
>Also, the "SUJET" column, despite containing mostly numbers, isn't
>numeric. Can PSPP default to "String" when more than one character type
>is detected?
>
>In both case, the goal is to avoid creating voids which may be
>difficult to detect afterwards. When a variable type is wrongly
>detected, all the file must be re-imported, which is awkward.
>
> The joined file is quite small, but I'm actually wary of what would
>have happened if I had to process 7000-lines x 30 columns of raw data
>in PSPP. Checking such a large file by hand would be impossible.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24574>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/