pspp-dev
[Top][All Lists]
Advanced

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

Re: moving coefficient.[ch] and design-matrix.[ch]


From: Jason Stover
Subject: Re: moving coefficient.[ch] and design-matrix.[ch]
Date: Wed, 11 Jun 2008 12:50:18 -0400
User-agent: Mutt/1.5.10i

On Wed, Jun 11, 2008 at 09:32:50AM +0800, John Darrington wrote:
> I'm worried that src/data is becoming a dumping ground for things
> which don't fit elsewhere.  At the same time, src/math is becoming
> depleted.
> 
> I always envisaged src/data to be about the definition, storage and 
> access of data.  The manipulation of data is, as I see it, a seperate,
> higher level task.

One possibility is to just move all the code from src/math/linreg to
src/math. I think Ben suggested this in IRC. linreg has only 2 .c
files and one .h. The only trouble I foresee is that linreg/predict.c
is specific to linreg, as, say, logistic/predict.c would be specific
to logistic regression.  But the code in any file called predict.c
should be small and could be put into the source file for that model
type.

Summarizing my previous messages in this thread, I have mentioned
three possibilities:

1. Put coefficient.[ch] and design-matrix.[ch] in src/data, or
2. Put coefficient.[ch] and design-matrix.[ch] in a new directory, or
3. Move the code from src/math/linreg into src/math.

I gather John doesn't favor number 1. What about the others?

I favor 3 right now. It would be easiest, and as Ben mentioned, moving
code around using Git is easy, so we could change it later if
necessary.

-Jason

> 
> J'
> 
> On Tue, Jun 10, 2008 at 01:45:30PM -0400, Jason Stover wrote:
>      I want to move coefficient.[ch] and design-matrix.[ch] to
>      src/data. Ben and I thought this might be a good idea after discussing
>      it on IRC, so I thought I would elicit more discussion here.
>      
>      coefficient.[ch] and design-matrix.[ch] don't do any computations.
>      They're purpose to offer some common, data-shuffling functionality to
>      model-fitting procedures in src/math/. Right now the only
>      model-fitting code in src/math is linreg, but we will eventually want
>      code for logistic regression and other models. They all need design
>      matrices and coefficients to match variables to columns to
>      coefficients. That matching goes pretty much the same for each kind of
>      model.
>      
>      So it seems that a model-fitting directory in src/math should depend
>      on coefficient.[ch] and design-matrix.[ch]. coefficient.[ch] and
>      design-matrix.[ch] probably should not have to know about
>      model-fitting: there are many kinds of models, and for each of them, a
>      coefficient means the same thing, and a design matrix means the same
>      thing, independently of what kind of model it is.
>      
>      Furthermore, coefficients and design-matrix code doesn't have any math
>      in it. There is no linear algebra, or descent algorithms, etc. That
>      code just takes a coefficient and returns the variable it matches, or
>      vice versa, or takes a variable and finds its corresponding columns in
>      a design matrix.  So putting this in src/math doesn't seem as
>      appropriate as putting it in a place like src/data.
>      
>      coefficient.c depends on linreg.h, but that could be changed. By 
> contrast,
>      design-matrix.c depends on src/data/category.h, and I don't think I could
>      eliminate this dependency.
>      
>      So how does everyone feel about moving coefficient.[ch] and
>      design-matrix.[ch] to src/data? If it sounds good, I'll post a patch.
>      
>      -Jason
>      
>      
>      _______________________________________________
>      pspp-dev mailing list
>      address@hidden
>      http://lists.gnu.org/mailman/listinfo/pspp-dev
> 
> -- 
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://pgp.mit.edu or any PGP keyserver for public key.
> 
> 






reply via email to

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