[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
casefile.c revision
From: |
John Darrington |
Subject: |
casefile.c revision |
Date: |
Wed, 1 Jun 2005 12:12:49 +0800 |
User-agent: |
Mutt/1.3.28i |
I've got an update to casefile.c which I think provides everything we need
for an efficient rank implementation --- it should also make those commands
which calculate percentiles a lot easier. And it'll be essential for NPAR
Basically there are 2 issues:
1. As discussed, I added an extra member to struct ccase. Much of
the casefile implementation involves writing ccase's to disk and reading
them back. In other words serialisation. However, the details are not well
abstracted. So the first change I made was to
* rename case_to_union and case_from_union to case_serialise and
case_unserialise respectively.
* Add a function casefile_serialisation_size returning the number of bytes
needed to serialise a single case.
* Reimplemented most of the pointer arithmatic in terms of
casefile_serialisation_size.
All this makes it easy to change the definition of struct ccase (should we ever
wish to again) without breaking the casefiles.
2. Currently, casefiles can be accessed only sequentially. RANK needs random
access. Therefore, I've added two new functions:
int casereader_get_case_by_index (struct casereader *reader, int idx,
struct ccase *c);
void casefile_replace (struct casefile *cf, unsigned long idx,
const struct ccase *c) ;
The first loads C with the the IDXth case from reader->cf.
The second replaces the case at IDX with the one pointed to by C.
There were only two aspects of this which involved intrusion into the
existing casefile implementation:
* I've added a new buffer and associated variables to casefile
dedicated to random access
* I had to extend reader_open_file such that it can be safely called
on a file that is already open.
Anyway I think it suits the purpose quite nicely and doesn't IMHO make casefile
implementation inelegent. I'm holding off checking it in until I've got a
completed RANK implementation. In the meantime, if anyone wants a preview let
me know.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
pgp8BzbcUBXuW.pgp
Description: PGP signature
- casefile.c revision,
John Darrington <=
- Message not available
- Message not available
- Re: casefile.c revision, Ben Pfaff, 2005/06/02
- Re: casefile.c revision, John Darrington, 2005/06/02
- Re: casefile.c revision, Ben Pfaff, 2005/06/03
- Re: casefile.c revision, John Darrington, 2005/06/03
- Re: casefile.c revision, Ben Pfaff, 2005/06/04
- Re: casefile.c revision, John Darrington, 2005/06/04
- Re: casefile.c revision, Ben Pfaff, 2005/06/24
- Re: casefile.c revision, John Darrington, 2005/06/25