On Tue, Jul 10, 2007 at 07:03:36AM -0700, Ben Pfaff wrote:
> I don't think so. axis_get_cnt returns the number of columns, not the
> highest column number ?
Right. But
datasheet_delete_columns (ds, datasheet_get_column_cnt (ds) - 1, 1)
and
datasheet_delete_columns (ds, 0, datasheet_get_column_cnt (ds))
should be valid, right?
You're probably right. I'll think about it more carefully.
> The problem with dict_compact is that it can change the order of the
> case indices, which would put the datasheet and the dictionary out of
> sync.
Hmm. One solution to that would be to keep the datasheet columns
and the dictionary variables in the same order, but I see your
point.
> I thought about this for a while and concluded that the correct
> solution would be to use libpspp/tower.c to maintain the case indices
> for dictionary.c Then dict_compact becomes obsolete. I just wasn't
> sure if it was worth the effort. What do you think ?
That's an interesting idea but I don't think it pays off for two
reasons. First, the cost of getting the level (case_index) of a
tower node is O(lg n) not O(1).
On the other hand, dict_compact_values is O(n) ...
Second, in the datasheet
case we do want deletions and resizings, etc., to have an
immediate effect on each case_index, but not in many other
cases. For example if I read a system file dictionary with
sfm_open_reader, and delete some variables from that dictionary,
I don't want the dictionary's case_indexes to be adjusted because
the cases coming from the system file would then have their
variables in positions that I don't expect them to be in.
I see. So unless we're going to somehow make the dictionary aware of
the capabilities of the data source with which it's associated (which
sounds like a nightmare to me) then we have to compromise. However,
there may other advantages to keeping the case indices monotonic with
respect to the dict indices, and accepting the O(n) overhead of
dict_compact_values (or dict_pad_values) with every
insertion/deletion.
I'll see if I can come up with a better patch.
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.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list pspp-dev@gnu.org http://lists.gnu.org/mailman/listinfo/pspp-dev
