bug-gnu-pspp
[Top][All Lists]
Advanced

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

PSPP-BUG: [bug #59697] Unintelligible strings in PSPP 1.4.1


From: Ben Pfaff
Subject: PSPP-BUG: [bug #59697] Unintelligible strings in PSPP 1.4.1
Date: Tue, 15 Dec 2020 22:16:47 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Follow-up Comment #1, bug #59697 (project pspp):

Thanks for bringing this up.

The first two are ones that users are meant to understand:

- "Text strings in the file dictionary that the previously listed encodings
interpret differently, along with the interpretations." 

This is about .sav files.  These files contain "dictionaries" of meta-data. 
The dictionaries have strings but they don't say what encoding (e.g. ASCII,
windows-1252, UTF-8) those strings are in.  The table below this lists the
strings that would have appear differently depending on the encoding that was
chosen, and how they would appear in each of those encodings.

- "Codings" (not enough context)

I think this shows how a value of a variable is represented as part of the
output for the logistic regression.  I'll separately add an output example to
give context.

The following aren't messages that users need to understand.  They are
reported if a .sav file is corrupt in a particular way.  I am not sure whether
it makes sense to translate them, because only a PSPP developer can do
anything about it.  Do you have an opinion?

- "Value label variable index %d refers to long string continuation."

- "Weight variable index %d refers to long string continuation.  Treating file
as unweighted." 

This one I can explain:

- "%s function does not accept a minimum valid argument count." 

PSPP supports the concept of a "missing value": a placeholder for a value
whose true value is unknown.  PSPP has a bunch of mathematical functions like
SUM, MEAN, STDDEV, and so on. For some of them, you can add an option that
specifies how many of the arguments have to be valid (that is, not missing
values) before the result of the function itself is non-missing.  This message
says that the function in question doesn't accept such an option, even though
the user tried to specify one.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59697>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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