hi, Am Donnerstag, 22. Dezember 2011 10:53:18 schrieb Thomas Friedrichsmeier: > well, true. But on the other hand, for that reason, polyserial is not > really suitable for creating a classic correlation matrix at all.
right, it's more like a continuous x categorial matrix of coefficients.
> Perhaps it would make sense to split up the plugin after all?
that was actually my first idea, but then i thought it's perhaps a bit
confusing to find what you want if there's still a "correlation matrix" plugin
(as long as it's not labelled "(except polyserial)", but that would be odd
;-)).
then, if we were to split things, i think it would be much clearer to offer
product-moment vs. ranks, but that wouldn't change these dialog issues at all.
> If polyserial was moved to a separate plugin, it would indeed make a lot of
> sense to ask for ranked and numeric data, separately, thus avoiding the
> "is.numeric()" hack(*). For all other coefficients, including polychoric, a
> single variable slot should be enough, AFAICS.
i'd simply keep the second varslot invisible as long as polyserial is not
checked.
> (*) In fact, that hack, as well as any other logic based on R data types is
> always likely to cause some problems, as I think it is fairly common to
> store ranked / ordinal data in a numeric vector. That may make a purist
> shudder, but I guess we can expect users with an interest in rank
> correlations to be aware of scale type, regardless of the R data types
> they use.
i agree, that's what i meant, the used functions actually allow numeric
variables for ordinal categories. so is.numeric() just poses as a weak
heuristic check. in the current plugin, an alternative could be to check the
number of levels (after as.factor()) and consider only variables that remain
below a sane threshold. that number could be made configurable in a spinbox.
how about that?
> I must admit, I find empty else clauses a bit unusual. I think I can see
> your idea.
well, i cannot take credit for that, i got it from some "how to write good R
code" tutorial, and since then simply got used to it (i actually begin each if
clause with "if() {} else {}" and then fill in the gaps).
but if you don't agree with it, i'll try to keep it out of code for the base
distribution. i think there's even an option to toggle it in rkwarddev; if
there isn't, i'll add it (i know i had it in mind).
> But since "if" without "else" is quite common both in RKWard
> and elsewhere, I'm rather sceptical that it will help to reduce confusion
> overall. In the worst case, it might feel deceptively reassuring to others
> suffering from the same misunderstanding.
well, how about a joint empirical study on it? ;-)
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.
------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
