Re: var_create_internal again

[Jason Stover]

On Sat, Jun 13, 2009 at 01:10:35AM +0000, address@hidden wrote:
> I'm of the opinion that var_create_internal should be dropped.
> 
> If you want to add an "internal variable", I think the best way
> is to iterate the cases, and write them to a new casereader which 
> has the extra variable.  A casereader-translator may make this easier.
> Currently, we have a function called casereader_create_append_numeric - 
> There is no corresponding casreader_create_append_string, but I suppose
> one can be added if necessary.
> 
> Then, one can access the "internal" data with code like...

I think casereader_create_append_numeric and a corresponding function
called, I guess, casereader_create_append_alpha, would let me eliminate
the function interaction_case_data, but I would still need an internal
variable. The reason is that design_matrix looks up columns based on
which variable the column is associated with. 

How about this: For now, patch var_create_internal to allow for a
width argument. That will let me finish an initial version of the
interaction/covariance matrix code and an initial glm.q. Then everyone
can review it and suggest changes, possibly major ones such as dropping
the need to look up columns based on particular variables.

> 
> const double x = case_data_idx (c, INDEX_OF_INTERNAL_DATA)->f;
> 
> or for alpha variables:
> 
> const char *s = value_str (case_data_idx (c, INDEX_OF_INTERNAL_DATA),
>                            WIDTH_OF_INTERNAL_DATA);
> 
> The upper case symbols are just const int, or even simple macros.
> 
> I've been doing something similar this  week, and I've found that Ben's
> new caseproto structure makes managing casereaders and their corresponding
> cases a whole lot easier.
> 
> Hope this helps.
> 
> J'
> 
> 
> On Fri, Jun 12, 2009 at 06:24:15PM -0400, Jason Stover wrote:
>      I need to be able to set an interaction_variable's internal
>      variable type to alpha.
>      
>      I need to do this in get_sum, in covariance-matrix.c. The problem
>      is that the code needs to use some of the features in category.c,
>      and that is hard to access without being able to see when an internal
>      variable's type is alpha.
>      
>      Here is the purpose: The internal "interaction variable" is a variable
>      essential to computations in GLM, but it's particular values won't be
>      useful to the user. Right now, it can only be type numeric, which is
>      causing the trouble.
>      
>      On IRC, Ben mentioned clarifying what var_create_internal is for, and
>      either changing it, or dropping it, or using something else. So:
>      What's the best way to make an "internal" variable, one whose values
>      are to be hidden from the user, but that is used for computations?
>      
>      Here is a quick fix:
>      
>      struct variable *
>      var_create_internal (int case_idx, int width)
>      {
>        struct variable *v = var_create ("$internal", width);
>      ...
>      
>      This small change will allow an internal variable to be type alpha,
>      which is OK by me.  But does it fit the idea of an "internal variable"
>      in other uses?
>      
>      -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.
> 
>