[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ben Pfaff
Subject: PSPP-BUG: [bug #24574] Decimal point behavior in data import not so great
Date: Thu, 03 Nov 2011 05:41:59 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110929 Iceweasel/3.5.16 (like Firefox/3.5.16)

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:


  Message sent via/by Savannah

reply via email to

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