Re: [guppi-list] Problems with cvs goose and a new commit



On Thu, Jul 15, 1999 at 09:57:51AM +0200, Asger K. Alstrup Nielsen wrote:
> 
> I tried to compile the cvs goose, but when I run ./autogen.sh, I get
> this error:
> 
> --
> Running aclocal ...
> aclocal: configure.in: 46: macro 'AM_PATH_GLIB' not found in library
> --

It looks like you need to install glib.

> Regardless of this problem, I commited four new statistical routines to
> goose, which my co-worker Mikkel wrote:
> 
>         CochanQ
>         Kruskal-Wallis
>         Spearman
>         McNemar
> 
> Since I have the configure problem, I don't know if it compiles on
> Unix...
> 
> The routines should be pretty self-explanatory, assuming that you know
> what they are.
> Each routine will calculate a bunch of different things, and in order to
> return all of these parameters, we decided to use a structure like this:
> 
>         struct TestResult {
>                 double par1;
>                 double par2;
>                 double par3;
>         };
> 
>         TestResult test_name(parameters);

This seems like a reasonable approach.  One thing that struck me as
odd, though, was how in tests like Kruskal-Wallis and Spearman, where
special methods are required for the case of ties, the routines go
ahead and calculate the various values both with and without the
ties-corrections.  For example, 

struct FooResults {
  double foo_stat;
  double p_value;
  double foo_stat_with_ties;
  double p_value_with_ties;
};

If there are ties in our data, we don't care about the non-ties
calculation (or do we?) since it does not apply.  And if there are
not ties, computing the ties-corrected version is just extra work.
Wouldn't it make more sense to return something like:

struct FooResult {
  double foo_stat;
  double p_value;
  bool there_were_ties;
};

and have our code just "do the right thing" automatically, checking
whether or not there are ties and computing appropriately.  (There
could be some optional arg that overrides the check and specifies
whether or not to compute w/ ties, just in case someone *really*
wanted to see the alternative calculation.)

Or is there some good reason for offering both results by default that
I'm just missing?

-JT




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