Hi,
On Tue, 14 Oct 2014 12:44:09 +0200
meik michalke wrote:
> Am Montag, 6. Oktober 2014, 20:28:45 schrieb Thomas Friedrichsmeier:
> > - Providing better control over which plugins are active. I'm still
> > not convinced, the level of individual plugins is (typically) the
> > right granularity of
Hi,
On Saturday 11 October 2014 21:35:54 meik michalke wrote:
> that exactly is the plan. for re-use of the ID later on (e.g., in the logic
> section), you should also store it in an object:
>
> list (
> "First option"=c (val="1"),
> "Second option"=c (val="2", chk=TRUE),
> option3
Hi,
On Tuesday 14 October 2014 12:44:09 meik michalke wrote:
> Am Montag, 6. Oktober 2014, 20:28:45 schrieb Thomas Friedrichsmeier:
> > - Providing better control over which plugins are active. I'm still not
> > convinced, the level of individual plugins is (typically) the right
> > granularity of
hi,
Am Montag, 6. Oktober 2014, 20:28:45 schrieb Thomas Friedrichsmeier:
> - Providing better control over which plugins are active. I'm still not
> convinced, the level of individual plugins is (typically) the right
> granularity of control, but in fact, control should be more fine-grained
> th
hi there,
Am Samstag, 11. Oktober 2014, 17:50:57 schrieb Thomas Friedrichsmeier:
> On Saturday 11 October 2014 17:44:33 Thomas Friedrichsmeier wrote:
> > Thus, perhaps, naming an id manually, is the way to go.
>
> > I.e rk.XML.radio() could accept options like this:
> ok, I was too slow...
sorry
Hi again,
On Saturday 11 October 2014 17:44:33 Thomas Friedrichsmeier wrote:
> Thus, perhaps, naming an id manually, is the way to go.
> I.e rk.XML.radio() could accept options like this:
ok, I was too slow...
Well, perhaps if you can make it so that rk.XML.radio() can accept a mixed
list like
On Saturday 11 October 2014 16:56:39 meik michalke wrote:
> well, in fact there is no rk.XML.option() yet ;-) all options are directly
> defined by rk.XML.radio() as a list. but if one needs the possibility of
> getting an ID from an option, adding rk.XML.option() seems to be inevitable.
> i don't
hi,
Am Samstag, 11. Oktober 2014, 14:46:39 schrieb Thomas Friedrichsmeier:
> Well, when I wanted to make that experiment, I found that rkwarddev does
> not yet handle ids on radio-options. And then I found out, that the fact
> that radio-options can be disabled, dynamically, was not really docume
Hi Meik,
On Wednesday 08 October 2014 11:49:56 meik michalke wrote:
> Am Dienstag, 7. Oktober 2014, 13:43:33 schrieb Thomas Friedrichsmeier:
> > - For the two sample tests, when estimating the size of one of the
> > samples,
> > why not always make it the second sample (i.e. first sample size
> >
Hi,
On Wednesday 08 October 2014 11:49:56 meik michalke wrote:
> > - For GLM, would it make sense to allow to specify "number of parameters
> > to
> > estimate", and "sample size (N)", instead of numerator / denominator df?
>
> i went for the wording used by ?pwr.f2.test, but i admit it sounds a
hi thomas,
Am Dienstag, 7. Oktober 2014, 13:43:33 schrieb Thomas Friedrichsmeier:
> - For the two sample tests, when estimating the size of one of the samples,
> why not always make it the second sample (i.e. first sample size provided)?
fixed (in the script).
> - Syntax error for estimating sam
Hi Meik,
On Sunday 05 October 2014 16:01:27 meik michalke wrote:
> sure, why not. would someone jump in to do write the help file? ;-)
trying to write a help file sometimes helps to spot non-intuitive controls, or
ones that could be simplified. Oh, and of course bugs...:
- For the two sample te
Hi,
On Sunday 05 October 2014 16:01:27 meik michalke wrote:
> > That might even help work around the squeezing you get when switching from
> > single sample to two samples (depending on dialog height).
>
> that's still an annoying bug, isn't it? by the way, while working on this i
> came to notic
hi,
Am Sonntag, 5. Oktober 2014, 14:49:40 schrieb Thomas Friedrichsmeier:
> On Sunday 05 October 2014 12:00:05 meik michalke wrote:
> > i also fixed the sample size controls for two sample designs, and added
> > the
> > possibility to provide eta squared instead of cohen's f.
>
> a thought on tha
Hi,
On Sunday 05 October 2014 12:00:05 meik michalke wrote:
> i also fixed the sample size controls for two sample designs, and added the
> possibility to provide eta squared instead of cohen's f.
a thought on that: For two samples, you could hide the "number of observations
_per sample_" note.
hi,
Am Samstag, 4. Oktober 2014, 12:08:49 schrieb meik michalke:
> Am Samstag, 4. Oktober 2014, 10:34:58 schrieb Thomas Friedrichsmeier:
> > - Don't forget to require(pwr)
fixed.
> > I figured out that for "less" you want to specify a _negative_ effect size
> > (and in fact, you can't enter that
hi thomas,
Am Samstag, 4. Oktober 2014, 10:34:58 schrieb Thomas Friedrichsmeier:
> looks really nice, already.
thanks :-)
> - Don't forget to require(pwr)
ouch...
> - I was rather confused by the distinction between "greater" and "less"
> alternatives for one-sided tests.
erm, yes, me too. on
Hi,
On Saturday 04 October 2014 00:40:44 meik michalke wrote:
> today i've started working on a plugin for power analysis/sample size
> calculation. most of what you can get from the pwr package is already
> implemented, open issues are handling of sample size estimation for designs
> with two sam
18 matches
Mail list logo
