[rkward-devel] case selection

[meik michalke]

hi,

Am Freitag, 9. Dezember 2011, 10:22:30 schrieb Thomas Friedrichsmeier:
> On Thursday 08 December 2011, meik michalke wrote:
> > as of now, in RKWard it's possible to select subsets of variables
> > (columns) from a given data.frame. i was just wondering if it's also
> > possible to select cases (rows) in a similar way, already? like a
> > selector box offering the rownames/numbers. ideally, it would allow to
> > specify a column (e.g. with case numbers) as an alternative, and if the
> > column is a factor, list only the factor levels.
> 
> well, of course, it would already be possible to create e.g. an embeddable
> plugin for subsetting. Equip this with a varselector, which you can root to
> the data.frame in question, and you can easily implement selection of a key
> column.

the mentioned plugins do similar things to select valiables.

> In fact, for a number of use cases (e.g. selecting a numeric range,
> selecting all subject ids starting with a certain sub-string, etc.) manual
> keyboard input will be much more usable than visual selection.

sure, it depends on what kind/amount of data it is and what you want to do 
with it. there's still cases where a manual/visual selection is faster or more 
comfortable. i guess something like the new package installation dialog is 
almost it: you're able to use regular expressions for filtering and still do 
manual selection tasks. to save space, such a regexp box should be located 
above or below the column list.

also, we'd need a way to decide whether the row names or a certain column's 
content is the relevant stuff. perhaps it's the easiest way to just assume 
it's row names as long as no specific column was defined.

to define ranges, regular expressions are not really what you'd want, so the 
filter should have either two additional range (spin)boxes (one greater, one 
less), or a switch to toggle that with the regexp box.

this is probably what i imagine:

      [x] select cases               -> should be checkable
     _____________________________
    |_______(select column)_______|  -> if empty, row names/numbers are used

      [(un)select all]               -> refers to visible entries only
     _____________________________
    | [x] row name1 / column row1 |  -> only visible & selected entries
    | [x] row name2 / column row2 |     will be used. by default all
    | [x] row name3 / column row3 |     visible are also selected, but can
    | [x] row name4 / column row4 |     be toggled with the button above.
    | [x] row name5 / column row5 |     manual (de)selection is also possible.
    |_[x] ..._____________________|
     _____________________________
    |_*regexp*____________________|  -> to control what's visible
                   ____       ____    
      range from: |____| to: |____|  -> to control what's visible


> 1) Esp. row names and numbers can be a very long list. Users should not be
> _required_ to use visual selection. (I.e. one more reason to start working
> on a manual input solution, already.)

right, but the same is true for variables/columns as well. i don't see that 
much of a difference here. the variable selection works well as it is, and if 
at least that would be possible row-wise as well, it would already be a great 
advantage (that is, even without filters and range selection, i would 
definitely use it in some of my plugins).

> 2) Currently, it is not possible for a plugin to fetch a list of row names
> or levels from the backend.

ok, this was my main concern ;-) if also a list of rownames could be rooted to 
a varselector, that would be great.

> In the mid term, I do plan to allow plugins to fetch arbitrary info from the
> backend, interactively. However, this still needs a bit of thinking to
> arrive at a clean solution.

that sounds interesting. it would be nice if you could loop calculation 
results back to the displayed dialog, to make them more like interactive tools 
(i.e., no need to press the submit button then, similar to plot previews). a 
use case would be test power analysis -- if you want to examine the effects of 
increasing the sample size, you wouldn't want to check the HTML outcome all 
the time ;-)


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  abt. f"ur diagnostik und differentielle psychologie
  institut f"ur experimentelle psychologie
  heinrich-heine-universit"at d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20111209/9bcc85b4/attachment.sig>