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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel