pspp-dev
[Top][All Lists]
Advanced

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

Re: Output format for p-values


From: John Darrington
Subject: Re: Output format for p-values
Date: Tue, 22 Apr 2014 08:40:22 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Apr 21, 2014 at 10:33:36AM -0700, Douglas Bonett wrote:
     
     1)  p-values are displayed in default F8.2 format and they need to report
     them with 3 decimal places. This will be another problem when we get to
     correlations and they need to report correlation estimates with 3 decimals
     (remember they are only using point and click options). Maybe changing to
     F7.3 for p-values and correlations would be an easy fix.


The real problem is that we don't currently have sufficient distinction between
the data displayed in the output and its presentation.  I think Ben is working
on a general solution, but it is some way off.

As an intermediate measure we could, like you suggest, hard code all p-values 
to 
display with 3 decimal places, but that would mean the user would have no 
recourse
if he decided that he wanted 4.

Right now, all the numbers displayed in the output fall into one of three cases:

1. Weights - these are displayed in the format of the weighting variable, if 
one 
   is set, otherwise in F8.0

2. Integers - in a very few places, a quantity cannot possibly take an 
non-integer
   value.  These we have hardcoded as F8.0

3. Everything else - uses the value of SET FORMAT (which by default is F8.2)

... then, the width (8 in the above examples) is ignored in most cases by the 
function data_out_stretchy - which expands the width as necessary to fill 
accomodate
the value.

None of this is very elegent.


Perhaps we could change tab_double and tab_value to take a "reported value 
class", say

enum reported_value_class {
 WEIGHT,
 INTEGER,
 P_VALUE,
 OTHER
};

and then have a map which associates each class with a function to determine 
how it should
be displayed.  We would then need to provide a means for the user to change the 
mapping 
as he desires.

Such a solution should be regarded as intermediate, until we get a better 
abstraction of
our data output, but might be solve the immediate problem without too much 
effort.

Comments?


J'


     
-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


reply via email to

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