Re: RANK

[Ben Pfaff]

John Darrington <address@hidden> writes:

> I assume that you'd not want to impose the penalty of an
> additional pointer on the ccase struct ?  --- that would mean a lot of
> extra memory for very large casefiles, when it wouldn't in general be
> needed.  My idea was a "derived class" of struct ccase, but I've not yet
> thought out the details carefully.

If an extra member in ccase is the best way to do it, then let's
do it that way.  It would only be a big penalty for large
casefiles that have very few variables.

However, I don't know whether that's really the best approach.
First, do we actually need the additional pointer in all cases or
just in casefiles?  Just in casefiles, I think, and in that case
we can add it in a wrapper in the casefile instead of in the
ccase itself.  Second, how would we deal with on-disk casefiles?
I don't think a pointer makes much sense in that case; perhaps a
case number instead?

Third, a basic RANK can be implemented something like this:
       compute orig_order=#casenum.
       sort cases by var_to_rank.
       compute rank=#casenum.
       sort cases by orig_order.
       modify vars/drop=orig_order.
This makes me wonder whether we're thinking too hard.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org