Re: dict_var_resized

[Jason Stover]

On Tue, May 05, 2009 at 09:49:24AM +0800, John Darrington wrote:
> On Mon, May 04, 2009 at 10:56:02AM -0400, Jason Stover wrote:
> 
>      > Incidently, the code I posted in my previous email was possibly
>      > confusing because var_create_internal is supposed to take the
>      > casereader index as its argument, not the width of the variable as I
>      > had implied.  We'd need to create a new function in variable.c to do
>      > what Jason wants.
>      
>      I thought I needed to call var_set_width to store enough characters
>      for the variable's values. Should I stop worrying about the size of
>      the variable, and instead call value_resize on union values if
>      necessary?
> 
> Are these union values contained by any casereader? or are they just
> lying around on the heap?  If they're part of a casereader, then it's
> not safe to resize them (without special precautions).  If they're on
> the heap (in which case let's hope there's not too many of them),
> then  resizing them is ok.
> 
>      
>      I just used solution 1 by dropping var_set_width, and it ran. Given
>      the discussion, there seems to be no reason for me to call
>      var_set_width, as John suggested. It's simpler code, too.
> 
> There's a number of things I'm not sure about in the
> interactions/covariance-matrix/glm code.
> 
> interaction_variable_create creates this internal variable.  But
> the only place it seems to be used is in interaction_case_data, and
> there, the only use it has is to compare its dict_index 
> with  that of another variable.  For internal variables, the
> dict_index is merely a serial number, so comparing the dict_indexes is
> probably doing nothing more than comparing the variable pointers
> themselves.

I need to compare these internal variables to other variables,
so what is the best way? 

> The following points might help you:
> 
> 0.  The concept of "internal" variables is a convenience, but not one
>     that has been particularly well thought out (IMO).

OK.

> 1.  Are you sure this internal variable needs to be a string
>     variable?   In the past, internal variables have always been
>     numeric and used for storing some temporary value.  If you can use
>     a numeric variable I think it'll make a lot of things simpler.

An interaction variable needs to be associated with either string or,
sometimes, numeric values. The string values then need to be expanded
to bit vectors in the design matrix. If there is a way to do this with
only numeric variables, I'll do it that way, but for my first attempt,
I thought that the variable with associated string values should be a
string variable. I would be happy if there is a better way. I'm not
happy with the code as is.

> 2.  You need to understand that "internal" variables are nothing more
>     than a convenience to allow the programmer to write 
>     case_data (&c, var) instead of case_data_idx (&c, index).  The 
>     internal variable must be associated with a particular
>     casereader, otherwise it serves no purpose (that I can envisage).
> 
> 3.  Calling  var_create_internal (0) implies that you are going
>     to be creating a new casereader with new data in its first position.

Based on all these comments, I suspect I'm going to change the interaction
code a lot.