[R-gui] (renamed) What do we do?

[A.J. Rossini]

    thomas> The only thing I'm trying to do here right now, is to
    thomas> propose a "one size fits all"-approach to the vast mass of
    thomas> uninteresting (from a creative point of view) dialogs for
    thomas> all sorts of uninteresting (from a frontend-designer's
    thomas> point of view) statistical tests. And "one size fits all"
    thomas> also means, that I'm neither interfering with any of your
    thomas> goals, nor am I introducing new ones. I don't care what
    thomas> you use as a backend, I don't care what programming
    thomas> language you use, I don't care what platforms you intend
    thomas> to be compatible with, I don't care how you pass data (or
    thomas> whether you "pass" it at all). If you don't believe me on
    thomas> this, please read my draft again (and point out where I'm
    thomas> introducing unnecessary limitations). If you think this to
    thomas> be "premature flexibility" - I say it's a realistic
    thomas> approach (and it's not even complicated or hard to
    thomas> implement - look at RKWard codebase, if you don't believe
    thomas> me).

I don't see a one-size fits all approach providing a gain.  It means
yet another language.  I'm willing to be proven wrong.

Here's an example: I can think of a number of appropriate abstract
ways to represent a t-test (and I mean it in your sense, in the
context and not in the display).  If they could be fit into a nice
linear scale, and indexed via a LOD (level of display) view, that
would be great, and would seem to fit in your model, but it's more of
a hypercube in terms of ordering (unordered, rather than strict or
partial ordered) and getting the abstraction right seems more trouble
than just doing it.

To be explicit, the components of the t-test that I'd like to see, to
make this a non-trivial example (scalable to the level of the
analyst), would be:

1. specification of the groups (2 variables, vs. 1 response and a
   grouping variable).

2. specification of the variance estimate (and corresponding adjustments)

3. approaches for resampling - data, model based.

4. approaches for sensitivity analysis (related rank-based tests,
   related 2-sample based likelihood based tests, using both same and
   different probability models, additions of noise or resampling, ala
   Gary King's Clarify).

5. a "dial-o-meter" (I don't see it as 1-d, but not sure what the
   right interface would be) to control the flexibility inherent in this
   (buttons, help settings, link-outs) based on user's skill level,
   needs, wants, etc. 

I don't think that constraining the data format, i.e. #1, would be
useful; it is precisely the issue being addressed with the GUI. #3/#4
start to become novel, at least they were when others proposed them.

#5 is what I'm hoping to see in your description of the layout,
Thomas, i.e. a statistical rather than computational description.  I'm
not seeing it at this point, but maybe I'm being obtuse.

I don't see what you are doing as particularly novel -- in fact,
numerous parts are possible as very simple extensions of ESS or
(X)Emacs tools (such as the S-Spreadsheet tool from the mid-90s, or
the widget and image tools that have been available for a while).
But to each, their own toolset...

But #5, if you can figure that specification out...!

best,
-tony

-- 
A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics		rossini@u.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW:   Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)