[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.
signature.asc
Description: Digital signature