[RkWard-devel] length() and na.rm

[Thomas Friedrichsmeier]

On Thursday 17 August 2006 16:19, Stefan Rödiger wrote:
> I totally consent. Moreover it makes things more handsome and the reuse of
> code should also be easier.
> I was reading the package description of "moments" and I would say it
> really makes more sense to create a separate plug-in for this.
> Anyway I found this plug-in is an very important one since this is what I
> would use first to look at my raw data. Therefore the idea behind the thumb
> images and so on. It would really describe a lot. But "keep it simple" is
> truly better. I can use "embed" anyway later on as option.

Probably it makes sense to organize the small separate plugins into a single 
sub-menu called "Descriptive Statistics" (or something like that). Then users 
will have an easy starting point for analysing their data, but still the 
functions could remain separate. Probably what we currently have as "Basic 
Statistics" will go there, too (and sooner or later we should have another 
look at reconciling some of the duplicate functionality).
I suggest we elaborate on this, when you have some plugin(s) completed or the 
next release is nearing. Changing the menu-hierarchy is easy now, and does 
not require much pre-planning.

> Yes, and this makes things inconvenient. I thinks a possibility for the
> future would be to create something like "first-run wizard" for this. Which
> means the corresponding packages are downloaded at the first run. If they
> are not available the plug-ins should be disabled. Otherwise you would get
> tons of bug reports. But I don't know how to handle package updates and the
> sever issue. Do you think my idea makes things to complicated?

I think the "first-run wizard" is probably a good idea, but also quite a bit 
of work. I'll put it on the TODO list. This could be used to pre-install the 
most common libraries. Not sure about disabling plug-ins, though, After all, 
the worst that will currently happen if a package is not installed is rkward 
asking you to install it. In contrast, I don't think it would be obvious to 
new users, how a disabled plugin can be enabled.
I'm not sure what you mean with "server issue".

> > Could possibly be optimized to
> >
> > rk.temp.freqtable <- table (x)
> > names (rk.temp.freqtable)
> > [which(table(rk.temp.freqtable)==max(table(rk.temp.freqtable)))]
> >
> > which looks even more convoluted, but avoids calculating "table (x)" over
> > and over again.

Well, just the programmer's POV. Should not make any noteable difference for 
anything but extremely large datasets.

> > png (...) would take additional arguments width, and height, so we could
> > extend rk.graph.on (), to include those parameters (or simply to accept
> > a '...'-parameter and pass it on to png ()).
> > I'll add something to CVS later, and then write back.
>
> Why not JUST doing via the GUI as parameter instead of extending
> rk.graph.on ()? That should be sufficient too.

Hm? But if at one place you want a full-size graph, and at another place just 
a thumbnail, then you'll need to be able to specify the size from within the 
plugin. Or are we talking about different things?

> Yes, but as you pointed out before. Its not simple and the question is
> what people can to with it right now. OOo doesn't support it and KWord only
> in basics. Editing is possible via inkscape and so on but finally you have
> to export them again to png or so. To be honest it's enough to keep it in
> mind as longterm project since some "geek"-knowledge is needed to work with
> svg at the moment.

Another option for a scalable graph output format would be postscript, but I'm 
not sure that's such a good idea in the long rung. Maybe we can also make it  
a (global) GUI choice, which output format is preferred.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20060817/81957c1f/attachment.sig>