Re: case_data_rw()

[Ben Pfaff]

Jason Stover <address@hidden> writes:

> On Fri, Apr 14, 2006 at 10:36:37AM -0700, Ben Pfaff wrote:
>> > The LIST command shows nothing but missing values for the new
>> > variable. And gdb doesn't follow the program in the casereading
>> > loop, so it's hard to see what's going on. (But I can see
>> > *lc->residual returns the correct doubles.)
>> 
>> I think there must be some other subtlety that is causing a
>> problem.  Perhaps you can post the file diff or otherwise
>> describe the larger context.
>
> [...]
> printf("%f\n",w_val->f) just after the assignment w_val->f = ... shows
> the correct value in w_val, but after that it's lost.
>
> It's hard to see what's happening in gdb because case_data_rw() and
> case_num() are inline.  gdb doesn't follow the source well, and tells
> me w_val isn't a symbol, etc. I #define'd DEBUGGING 1 in case.h, but
> then dictionary.o would not link.  Is it necessary to have the functions
> in case.c as inline, given the hassle it causes while debugging?

It's best to define DEBUGGING globally or not at all, either by
editing config.h or passing --enable-debug to configure.  If you
do either of those, it should make debugging easier again.

Anyhow, I checked out the code after applying your patch.  The
problem is more conceptual than in the details of the code.  When
you add a variable, as you do here:[*] 
        residuals = dict_create_var_assert (default_dict, "residuals", 0); 
the only immediate effect is on the dictionary, in this case
default_dict.  It doesn't expand any cases to include room for
the new data, for example.  That only happens when a procedure
runs.  A procedure reads data from some source, then runs it
through a bunch of transformations, some of which might add data
to the case, and then writes it to some sink.  The sink then
becomes the source for the next procedure that runs.  Data in
sources or sinks is conceptually static (although some of the
sources or sinks are themselves kind of tricky, but that's sort
of beside the point here).

The most straightforward way for a procedure to add data to each
case is for it to add a transformation.  This still won't affect
the data that was written to the sink, but it has a similar
effect because it gets to modify the data as soon as it is drawn
from the source for the next procedure.  This is what the
DESCRIPTIVES procedure does for Z scores, in setup_z_trns().

Now, I just realized that the DESCRIPTIVES implementation has a
defect: it doesn't work properly if SPLIT FILE is in effect.  I
just filed a bug about it, in fact.  Oops.  I'll get around to
fixing that, and if REGRESSION ends up with the same type of bug
I'll fix it too.

[*] Actually there's a small problem with this, in that it should
be using the non-"_assert" version of that function.  As is, if
there is already a variable named "residuals", then it will
assert-fail.  You really just want it to return a null pointer
so that you can report the error (or pick another variable name).
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org