John Darrington <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
web: http://benpfaff.org
_______________________________________________
pspp-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/pspp-dev
