[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: John Darrington
Subject: Re: [patch #6071] Resing/Deleting/Inserting variables in GUI
Date: Mon, 16 Jul 2007 08:26:40 +0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Jul 15, 2007 at 08:30:45AM -0700, Ben Pfaff wrote:

     I agree that monotonicity is something we cannot assume or
     enforce in general.  But I do not think that the GUI is the
     general case.  I think that it is one specific case that we can
     deal with.  The fact that we can resize the data itself indicates
     that the data must be coming from a datasheet, which is the only
     data source that supports resizing data.  

I agree with everyting up to this point.

     So I think that we
     could maintain the dictionary's variable in the same order as the
     datasheet's columns.  If we do so, then simply compacting the
     dictionary after setting the variable width will have the same
     effect as dict_pad_values/dict_var_resized.

Consider this example:

1. A GUI user loads a system file with the following variables:

name type        dict_idx  case_idx
---- ----        --------  --------
v1   string (8)  0         0
v2   string (8)  1         1
v3   numeric     2         2
v4   numeric     3         3

2. He decides to insert a new variable (vNew) before v2.  The
   situation becomes:

v1   string (8)  0         0
vNew numeric     1         4
v2   string (8)  2         1
v3   numeric     3         2
v4   numeric     4         3

3. He decides to increase v1's width from 8 to 9 (valcnt goes from 1
   to 2).  After calling dict_compact_values we have:

v1   string (9)  0         0
vNew numeric     1         2
v2   string (8)  2         3
v3   numeric     3         4
v4   numeric     4         5

which means that all variables except v1 have case_indices indexing
into the wrong place in the datasheet.

If we can devise an implementation of dict_compact_values that
compacts/pads without re-ordering, then this would be one solution.  I
don't know if such an implementation can work in linear time. 


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

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