[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch #6071] Resing/Deleting/Inserting variables in GUI

From: Ben Pfaff
Subject: Re: [patch #6071] Resing/Deleting/Inserting variables in GUI
Date: Tue, 10 Jul 2007 07:03:36 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (gnu/linux)

John Darrington <address@hidden> writes:

> On Tue, Jul 10, 2007 at 04:02:46AM +0000, Ben Pfaff wrote:
>      Is the datasheet.c assertion correct?  I think that the test
>      should be "<=" not "<".
> 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)
        datasheet_delete_columns (ds, 0, datasheet_get_column_cnt (ds))
should be valid, right?

>       It seems to me that it's only appropriate in the
>      particular case where the data is coming from something like a datasheet,
>      where the case data is automatically rearranged as the dictionary is
>      manipulated.  And in that case, I don't understand why just doing
>      set_var_width as-is and then dict_compact on its dictionary wouldn't 
> have the
>      same effect.
> 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

> 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).  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.
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
 pour encourager les autres."
--Voltaire, _Candide_

reply via email to

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