Re: NPAR TESTS

[Ben Pfaff]

John Darrington <address@hidden> writes:

> I've started looking at the NPAR TEST command.  It has a lot of
> subcommands, most of which are unrelated (IMHO they should all be
> seperate commands), so I'll probably implement them one at a time
> and check them in as and when they're complete.

Makes sense.

>  1.  I'm intending to put in more effort (compared to other
> commands I've implemented) to seperate the parsing of the command 
> from its execution.  My idea is that the parser should produce 
> some kind of abstract base class, implementations of which can then 
> be executed by the "backend".  I'm hopefull that this idea, if 
> successful, could then be extended for all commands.

Yes, this is clearly how we should build things.  It just hasn't
usually worked out that way ;-(

>  2. In the NPAR command, spss has /SAMPLE and /METHOD subcommands, 
> which, if used, make the command do monte-carlo sampling of the 
> dataset rather than iteration.  So far as I can tell, this is a 
> hack, to avoid memory exhaustion.  PSPP's casefiles should entirely 
> avoid this problem (unless disk space is also exhausted), so I'm 
> proposing that PSPP just accepts and ignores these subcommands
> ... unless anyone can give me a good reason to do otherwise.

I know that sometimes people try comparing the results obtained
with different random samples to determine some kind of
"reliability" measure for models.  I don't, however, know if this
makes sense for these kinds of statistics or whether these
subcommands could be used for that purpose.

>  3. I've been thinking about various optimisations which NPAR can 
> make.  One significant optimisation  can only be used if 
> multiple tests are asked for and if /MISSING LISTWISE INCLUDE is 
> specified, which can avoid extra  sorting.    However, my guess
> is that few if any users will use that particular combination, so
> I'm thinking that this optimisation is probably not worth the 
> effort.  Comments?

In my opinion, don't waste time optimizing rare cases.

>  4. Many of the output tables make a lot of use of subscripted
> footnotes.  I wonder how much effort it would take to implement
> such a feature, as a stop-gap measure until we get a new output 
> subsystem?

Not too hard, I think.  I'll put it on my to-do list.

>  5. I'm becoming aware, that different developers, and indeed the
> same developers at different times, are making inconsistent use of
> style in output tables, with regards to eg: text alignment, double
> vs. single lines, bold fonts, output precision etc.  Perhaps we 
> need a "manual of style" to make some recommendations here.

Definitely.
-- 
God leaned close as mud as man sat up, looked around, and spoke.  Man blinked.
"What is the purpose of all this?" he asked politely.  "Everything must have a
purpose?" asked God.  "Certainly," said man.  "Then I leave it to you to think
of one for all this," said God.  And He went away.  --Vonnegut, _Cat's Cradle_