[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RANK
From: |
Ben Pfaff |
Subject: |
Re: RANK |
Date: |
Wed, 18 May 2005 10:24:15 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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
- RANK, John Darrington, 2005/05/17
- Re: RANK, Ben Pfaff, 2005/05/18
- Re: RANK, John Darrington, 2005/05/18
- Re: RANK,
Ben Pfaff <=
- Re: RANK, Ben Pfaff, 2005/05/18
- Re: RANK, John Darrington, 2005/05/18
- Re: RANK, John Darrington, 2005/05/26