pspp-dev
[Top][All Lists]
Advanced

[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.


Attachment: pgp8BzbcUBXuW.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]