Dear list members, This has been a stimulating discussion, now spread over three lists. Although I'd like to address issues that have been raised on all three lists, I expect that more or less everyone reads r-help, so I'm just posting these comments there. (1) As everyone else, I've had experience with a number of other statistical packages and programming environments in addition to R (including, more years ago than I care to say, the mainframe predecessor of the MicrOsiris package mentioned positively in the SCW article cited by Philippe in his original message). I don't believe that extensive point-and-click GUIs for broad statistical packages/programming environments such as Stata, R, S-PLUS, or SAS are very helpful: They tend to be labyrinths that are difficult to navigate. Some of the suggestions for other kinds of GUIs (e.g., aids to command specification) seem to me more promising. Moreover, I don't think that one should expect to learn an extensive system such as R or SAS without doing some reading. My own experience is that S (i.e., encompassing R and S-PLUS) is easier, not harder, to learn than its true competitors. (2) On the other hand, one can build quite nice graphical interfaces to more limited packages. A couple of examples that I particularly like are SAS JMP and Cook's and Weisberg's Arc (built on Lisp-Stat). (3) Similarly, my Rcmdr package was meant to be a limited-purpose GUI, useful for basic-statistics classes. Its range has grown somewhat to cover linear and generalized-linear models, and I plan a few more modest extensions (including the ability to incorporate other classes of statistical models more easily). As a technical matter, I don't think that it would be hard (although it would be time-consuming) to produce a much broader extension, but the result (in my opinion) would be as dubiously useful as the GUIs for SAS or S-PLUS. By the way, if there were something I could wish for here it would be a slightly broader set of Tk widgets to be included with the Tcl/Tk that installs with R for Windows, since using widgets outside of this set creates installation obstacles for lower-level users. (4) Several people have pointed once more to the difficulty that novice users experience in locating functions to perform particular tasks or in figuring out how to use them once found. I suspect that even people who have been using R for a while occasionally have a brain-cramp that leads to a search through documentation. I know that I do. In my experience, the various facilities for searching documentation in R work pretty well. (5) I think that examples in help files and vignettes can be useful, but are not substitutes for text-books, manuals, and journal articles. It certainly should not be the job of statistical software to teach the statistics, although of course it can be used to help do that. I doubt that many list members would look favourably on the statistical-methods "decision tree" in MicrOsiris, for example. One solution is to include PDF "manuals" with packages. I've done this, for example, with my effects and Rcmdr packages. The introductory manual supplied with Thomas Lumley's survey package is another, similar example. Maybe there's a better way of integrating such non-vignette manuals with the help system -- something like help(manual=package). (6) As has been pointed out, e.g., by Duncan Murdoch, solving the function-locating problem is best done by a method or methods that automatically accommodate the growing and changing set of contributed packages on CRAN. Why not, as previously has been proposed, replace the current static (and, in my view, not very useful) set of keywords in R documentation with the requirement that package authors supply their own keywords for each documented object? I believe that this is the intent of the concept entries in Rd files, but their use certainly is not required or even actively encouraged. (They're just mentioned in passing in the Writing R Extensions manual.) -------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox
The hidden costs of GPL software?
37 messages · Philippe GROSJEAN, Jan P. Smit, (Ted Harding) +17 more
Messages 26–37 of 37
John Fox wrote:
[...] (sorry, this is long mail, and I want to comment only details) By the way, if there were something I could wish for here it would be a slightly broader set of Tk widgets to be included with the Tcl/Tk that installs with R for Windows, since using widgets outside of this set creates installation obstacles for lower-level users.
Then, take a look at the tcltk2 package in the SciViews bundle (probably, in the next version, I will take it out of the bundle). You have there tile (themable widgets with notebook tabs, progress bar, and many more... and very soon combo boxes and lists/trees). You have also the famous tkTable, and a separate combobox and a tree, and a support for tooltips everywhere... Just propose if you need more! All this runs under Windows, but I still got problems to compile it under other platforms.
I doubt that many list members would look favourably on the statistical-methods "decision tree" in MicrOsiris, for example. One solution is to include PDF "manuals" with packages. I've done this, for example, with my effects and Rcmdr packages. The introductory manual supplied with Thomas Lumley's survey package is another, similar example. Maybe there's a better way of integrating such non-vignette manuals with the help system -- something like help(manual=package).
I tend to have the same opinion than John (although I thing that both a good manual, and a better online help could be beneficial): a PDF manual is much more readable than a wiki! Why not to propose PDF manuals in the \doc section of CRAN which have a GNU Free Documentation License (http://www.gnu.org/copyleft/fdl.html), so that the manual could be progressively enhanced by many authors? Best, Philippe Grosjean
"John Fox" <jfox at mcmaster.ca> writes:
I don't think that it would be hard (although it would be time-consuming) to produce a much broader extension, but the result (in my opinion) would be as dubiously useful as the GUIs for SAS or S-PLUS.
Strategically, that might actually be a valid (and valiant) design goal! From my limited experience with Rcmdr and SAS Analyst, I'd say that Rcmdr is almost there, just a few little niggles like not remembering values from the last time a form was filled in.
By the way, if there were something I could wish for here it would be a slightly broader set of Tk widgets to be included with the Tcl/Tk that installs with R for Windows, since using widgets outside of this set creates installation obstacles for lower-level users.
Argh. Please stop poking at my guilty conscience.... Wrapping Tcl/Tk extensions as R packages has been on my wish list too for some time, with tktable as the obvious first candidate. (It's not just on Windows; the default Unix/Linux installs of Tcl/Tk tend to be pretty minimal too. On Windows we have this instructive twist on the BSD/GPL debacle, that ActiveState made a very nice Tcl/Tk distribution with all sorts of "batteries included", but we cannot bundle it with R as they are restricting redistribution.)
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
Peter, You don't need the ActiveState Tcl distribution to add extensions. If you compile extensions yourself (and these extensions have a compatible license), then you have no problems... (well, almost! You must make sure those extensions compile correctly on all supproted platforms). This is exactly what I do in the tcltk2 package. Best, Philippe Grosjean
-----Original Message----- From: r-help-bounces at stat.math.ethz.ch [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Peter Dalgaard Sent: Friday, November 19, 2004 11:46 AM To: John Fox Cc: r-help at stat.math.ethz.ch Subject: Re: [R] The hidden costs of GPL software? "John Fox" <jfox at mcmaster.ca> writes:
I don't think that it would be hard (although it would be time-consuming) to produce a much broader extension, but the result (in my opinion) would be as dubiously useful as the GUIs for SAS or S-PLUS.
Strategically, that might actually be a valid (and valiant) design goal! From my limited experience with Rcmdr and SAS Analyst, I'd say that Rcmdr is almost there, just a few little niggles like not remembering values from the last time a form was filled in.
By the way, if there were something I could wish for here it would be a slightly broader set of
Tk widgets
to be included with the Tcl/Tk that installs with R for
Windows, since
using widgets outside of this set creates installation
obstacles for
lower-level users.
Argh. Please stop poking at my guilty conscience.... Wrapping Tcl/Tk extensions as R packages has been on my wish list too for some time, with tktable as the obvious first candidate. (It's not just on Windows; the default Unix/Linux installs of Tcl/Tk tend to be pretty minimal too. On Windows we have this instructive twist on the BSD/GPL debacle, that ActiveState made a very nice Tcl/Tk distribution with all sorts of "batteries included", but we cannot bundle it with R as they are restricting redistribution.) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Peter Dalgaard wrote:
[...] Strategically, that might actually be a valid (and valiant) design goal! From my limited experience with Rcmdr and SAS Analyst, I'd say that Rcmdr is almost there, just a few little niggles like not remembering values from the last time a form was filled in.
Humm, in my view, this is a feature! The first time the user calls the form, it creates the corresponding R script. If the user needs to make corrections, or to run the analysis a second time, he is now supposed to work with this script! By not remembering last values in a dialog box, Rcmdr makes the script edition more obvious than recalling the dialog box again,... even for lazy people! Otherwise, you are sure that those lazy people will not switch to script: they will call the same dialog box again and again. Of course, one has to explain to the students that this is a feature. Otherwise, it may look like a bad design, especially in comparison with other "better designed" GUIs! Best, Philippe Grosjean
[...]
"Philippe Grosjean" <phgrosjean at sciviews.org> writes:
Peter, You don't need the ActiveState Tcl distribution to add extensions. If you compile extensions yourself (and these extensions have a compatible license), then you have no problems... (well, almost! You must make sure those extensions compile correctly on all supproted platforms). This is exactly what I do in the tcltk2 package. Best, Philippe Grosjean
I know, it's just that it feels silly that we cannot build on the fine work of ActiveState.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
At 09:45 PM 11/18/2004, John Fox wrote:
[...]
6) As has been pointed out, e.g., by Duncan Murdoch, solving the function-locating problem is best done by a method or methods that automatically accommodate the growing and changing set of contributed packages on CRAN. Why not, as previously has been proposed, replace the current static (and, in my view, not very useful) set of keywords in R documentation with the requirement that package authors supply their own keywords for each documented object? I believe that this is the intent of the concept entries in Rd files, but their use certainly is not required or even actively encouraged. (They're just mentioned in passing in the Writing R Extensions manual.) [...]
That should prove extremely helpful. Would it be practical to have the complete index installed with base R? That would help identify useful packages not yet in a user's installation.
Michael Prager, Ph.D. <Mike.Prager at noaa.gov> NOAA Beaufort Laboratory Beaufort, North Carolina 28516 http://shrimp.ccfhrb.noaa.gov/~mprager/ ***
Dear Philippe, I was aware of your tcltk2 package and will likely use it (if the standard widget set distributed with R for Windows is not expanded) when it becomes cross-platform. Thanks for this. John -------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox --------------------------------
-----Original Message----- From: Philippe Grosjean [mailto:phgrosjean at sciviews.org] Sent: Friday, November 19, 2004 3:29 AM To: 'John Fox'; r-help at stat.math.ethz.ch Subject: RE: [R] The hidden costs of GPL software? John Fox wrote:
[...] (sorry, this is long mail, and I want to comment only
details)
By the way, if there were something I could wish for here
it would be
a slightly broader set of Tk widgets to be included with the Tcl/Tk that installs with R for Windows, since using widgets
outside of this
set creates installation obstacles for lower-level users.
Then, take a look at the tcltk2 package in the SciViews bundle (probably, in the next version, I will take it out of the bundle). You have there tile (themable widgets with notebook tabs, progress bar, and many more... and very soon combo boxes and lists/trees). You have also the famous tkTable, and a separate combobox and a tree, and a support for tooltips everywhere... Just propose if you need more! All this runs under Windows, but I still got problems to compile it under other platforms.
I doubt that many list members would look favourably on the statistical-methods "decision tree" in MicrOsiris, for example. One solution is to include PDF "manuals" with packages. I've done this, for example, with
my effects
and Rcmdr packages. The introductory manual supplied with Thomas Lumley's
survey package
is another, similar example. Maybe there's a better way of
integrating
such non-vignette manuals with the help system -- something like help(manual=package).
I tend to have the same opinion than John (although I thing that both a good manual, and a better online help could be beneficial): a PDF manual is much more readable than a wiki! Why not to propose PDF manuals in the \doc section of CRAN which have a GNU Free Documentation License (http://www.gnu.org/copyleft/fdl.html), so that the manual could be progressively enhanced by many authors? Best, Philippe Grosjean
Dear Peter,
-----Original Message----- From: Peter Dalgaard [mailto:p.dalgaard at biostat.ku.dk] Sent: Friday, November 19, 2004 5:46 AM To: John Fox Cc: r-help at stat.math.ethz.ch Subject: Re: [R] The hidden costs of GPL software? "John Fox" <jfox at mcmaster.ca> writes:
I don't think that it would be hard (although it would be time-consuming) to produce a much broader extension, but the result (in my opinion) would be as dubiously useful as the GUIs for SAS or S-PLUS.
Strategically, that might actually be a valid (and valiant) design goal! From my limited experience with Rcmdr and SAS Analyst, I'd say that Rcmdr is almost there, just a few little niggles like not remembering values from the last time a form was filled in.
I've thought about remembering dialog values, but I guess so far I've been too lazy to do it or, to put a better construction on it, too distracted by other things. It shouldn't be hard to do -- just a matter of maintaining a data base of previous entries that are flushed when the active data set changes. Actually, the linear-model and generalized-linear-model dialogs already do this. I'd be interested in the other little niggles as well.
By the way, if there were something I could wish for here it would be a slightly broader set of
Tk widgets
to be included with the Tcl/Tk that installs with R for
Windows, since
using widgets outside of this set creates installation
obstacles for
lower-level users.
Argh. Please stop poking at my guilty conscience.... Wrapping Tcl/Tk extensions as R packages has been on my wish list too for some time, with tktable as the obvious first candidate. (It's not just on Windows; the default Unix/Linux installs of Tcl/Tk tend to be pretty minimal too. On Windows we have this instructive twist on the BSD/GPL debacle, that ActiveState made a very nice Tcl/Tk distribution with all sorts of "batteries included", but we cannot bundle it with R as they are restricting redistribution.)
I certainly don't want to press this issue, since I'm grateful for what you've already done (and it's surprising how much mileage one can get from the basic widget set). I see this as primarily a Windows problem because users of other computing platforms (possibly with the exception of some Mac users) tend to be more sophisticated about installing software. Regards, John
-- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
My very dear Prof. Dalgaard:
Peter Dalgaard wrote:
Argh. Please stop poking at my guilty conscience.... Wrapping Tcl/Tk extensions as R packages has been on my wish list too for some time, ...
You, of all people, should hardly have a guilty conscience about
not doing enough on R! I, and many others, are continually awed by the
accomplishments of you and the rest of the R Core Team.
spencer graves
Spencer Graves, PhD, Senior Development Engineer O: (408)938-4420; mobile: (408)655-4567
I inadvertently directed this response to the R-Gui list this morning. To those receiving a double receipt, I give my apologies. My intended list was the R list.
--- Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
On Thu, 18 Nov 2004 03:24:01 -0800 (PST), Michael Grant <mwgrant2001 at yahoo.com> wrote:
Hmmmm, interesting thread and minds will not be changed but regarding GUIs...I thought S (aka R)
...
I have to disagree with you. What you say might be true about *bad* GUIs, but I find nothing more frustrating than the lack of programming support in R. What's a nice GUI for programming? You should be able to edit code, and have R parse the code that you are editing
... [snip] [snip] [snip] ...
All of these things have existed for years in IDEs (i.e. programming GUIs), but most are not in R's GUIs.
I guess we'll just agree to disagree. :O) 1.)The LACK of programming support? Isn't that a bit of an overstatement? There are materials available, as of ciurse you are aware. At one time or another many of us may find it difficult to determine some 'key' programming information at the moment. But you know something, I've had that happen using the packages like you describe--this includes wired IDE help, original documentation, and 3rd party books. I accept that as a condition for using both free and commercial software. And if the particular burden is too great, then I don't use the product. Such is life :O) 2.)As you indicate below, R doesn't not have a VB or VC++ style IDE. R doesn't have the development environment of Smalltalk or the commercial LISPs (sigh...) But, really, an IDE is a bit more than a GUI, wouldn't you agree? A GUI is just one component of an IDE. Perhaps part of our difference is how we view programming. I view it more as a form of expression using a LANGUAGE. Like any language, e.g., English, French, Chinese, you have to develop a degree of fluency to express yourself. Some people are comfortable working with a phrase book and others put more effort in to learn to converse sans book. Both approaches are quite legitimate in that either can get the job done. (And both can fail miserably!)
From another perspective, I can not deny that having a
real GUI would be nice at times even for a grump like myself. And not having such is a cost. But in my case that cost is not the deciding factor. The fact is, I by preference do a lot of coding--both at the quick/dirty scale and the project scale--in R that I could do in C/C++, FORTRAN, BASIC. I have those tools in commerical form with IDEs Why R? The turn around is so fast by comparison. R/S is language in which I can much more easily and quickly express myself. The development team has done a lot of work developing my high-level language for me :O). (Note--my second hacking language is lisp-stat, also an interpreted, higher functionality language.) I don't use most of R's capabilities, and 'not knowing that which I do not know' is not an issue. When I need something new I am able to learn it incrementally on top of what I already know. ...
That's one sort of GUI that R could have, but it's not the only one, and it's not the one that I'd use. However, I might start out students on it. There's a big benefit to a list of suggestions as opposed to a big blank space.
Did I suggest banning GUIs? I don't think so. Your world is one where there are benefit for your clients--the students. My world is turn around and documentation. Coding is easier to document than a complex sequence of menu actions. Indeed I would get laughed out of Dodge City if I documented a set of calculations: " next I clicked ...". It's that just different requirements lead to different needs.
GUIs encourage a passive approach to using
computers
when solving problems. In addition, it is
regretable
... [snip] ...
gather 'electronic dust'.
A lot of people do incomplete or incorrect work because they don't know any better. It doesn't matter if they're using a GUI or not, they'll do what they think they know, and get it wrong.
Of course that is the case, but the limitations in a given GUI is one more thing that puts such people in rationalized comfort-zone with their actions. (Typically I see this with EXCEL apps--99.9% of the people in my trade run away from statistical software.) More than once I have seen this occur in a senior scientist review capacity after management has seen the product and 'accepted' its results. Doom, doom, doom...shoot the messenger! Oh woe, oh woe!:O(. Best regards, Duncan Michael
3 days later
FYI, just noticed that the GPL is about (="a draft of which is due next year") to be revised into GPL v3. Maybe they will solve part of the problems you mention. Not much substance yet, but see GPL 3 to Take on IP, Patents, eWeek, November 22, 2004 http://www.eweek.com/article2/0,1759,1730102,00.asp and the slashdot discussion GPL Revision Coming Soon, slashdot, November 22, 2004 http://slashdot.org/article.pl?sid=04/11/22/1746225&tid=117 Question to Martin Maechler: Is it ok to change the subject title to, say, "Problem with GPL (Was: RE: ...)" when replying to a message? This thread has covered quite a wide range of topics this far. Cheers Henrik Bengtsson
-----Original Message-----
From: r-help-bounces at stat.math.ethz.ch
[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Spencer Graves
Sent: Wednesday, November 17, 2004 7:22 PM
To: Berton Gunter
Cc: r-help at stat.math.ethz.ch; 'Patrick Burns'; 'Philippe Grosjean'
Subject: Re: [R] The hidden costs of GPL software?
I agree with Bert. Thanks to all who contributed. I'd like to
add one comment I didn't see in the thread so far:
The corporate legal where I work is deathly afraid of the GNU
General Public License (GPL), because if we touch GPL software
inappropriately with our commercial software, our copyrights are
replaced by the GPL. This in turn means we can't charge royalties,
which means we can't repay the investors who covered our initial
development costs, and we file for bankruptcy. The rabid capitalists
meet the rabid socialists and walk away, shaking their heads.
(Sec. 2.b
of the GPL: "You must cause any work that you distribute or publish,
that in whole or in part contains or is derived from the
Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License." We can get around this by
packaging accesses to GPL software as separately installed add-on(s),
because then only the add-on(s) would be covered by the GPL.) Our
corporate legal is more concerned about a possible law suit from a
possible competitor than from the R Foundation, but the
threat is still
real and still being adjudicated in other cases.
If the GPL were not so tight on this point, someone could
commercialize a GUI for R without having to offer their source code
under the GPL.
However, even without this change, R seems to be the
platform of
choice for new statistical algorithm development by a growing
portion of
the international scientific community. Moreover, from my experience
with this listserve, the technical support here is far superior to
anything I've experienced with any other software in the 40+
years since
I wrote my first Fortran code.
Best Wishes,
spencer graves
Berton Gunter wrote:
All: I have much enjoyed the discussion. Thanks to all who have
contibuted.
Two quick comments: 1. The problem of designing a GUI to make R's functionality more accessible is, I believe just one component of the larger issue of making statistical/data analysis functionality available to
those who
need to use it but do not have sufficient understanding and
background
to do so properly. I certainly include myself in this
category in many
circumstances. A willingness and commitment to learning ( =
hard work!)
is the only rational solution here, and saying that one doesn't have the time really doesn't cut it for me. Ditto for R language functionality? 2. However, R has many attractive features for data manipulation and graphics that make it attractive for common tasks that are now done most frequently with (ugh!) Excel (NOT Statistica, Systat, et. al.). For this subset of R's functionality a GUI would be attractive. However, writing a good GUI for graphing that even begins to take advantage of R's flexibility and power in this arena is an
enormous --
perhaps an impossible -- task. Witness the S-Plus graphics
GUI, which I
think is truly awful (and appears to thwart more than it helps, at least from many of the queries one sees on that news list).
So I'm not
sanguine. Again, thanks to all for a thoughful and enjoyable discussion. -- Bert Gunter Genentech Non-Clinical Statistics South San Francisco, CA "The business of the statistician is to catalyze the scientific learning process." - George E. P. Box
-----Original Message----- From: r-help-bounces at stat.math.ethz.ch [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Patrick Burns Sent: Wednesday, November 17, 2004 6:28 AM To: Jan P. Smit Cc: r-help at stat.math.ethz.ch; Philippe Grosjean; r-sig-gui at stat.math.ethz.ch Subject: Re: [R] The hidden costs of GPL software? I'm a big advocate -- perhaps even fanatic -- of making R
easier for
novices in order to spread its use, but I'm not convinced
that a GUI
(at least in the traditional form) is the most valuable approach. Perhaps an overly harsh summary of some of Ted Harding's statements is: You can make a truck easier to get into by taking off the wheels, but that doesn't make it more useful. In terms of GUIs, I think what R should focus on is the ability for user's to make their own specialized GUI. So that a knowledgeable
programmer
at an installation can create a system that is easy for unsophisticated users for the limited number of tasks that are to be done. The ultimate users may not even need to know that R exists. I think Ted Harding was on the mark when he said that it
is the help
system that needs enhancement. I can imagine a system that
gets the
user to the right function and then helps fill in the
arguments; all
of the time pointing them towards the command line rather than away from it. The author of the referenced article highlighted some hidden costs of R, but did not highlight the hidden benefits (because they were hidden from him). A big benefit of R is all of the bugs that aren't in it (which may or may not be due to its free status). Patrick Burns Burns Statistics patrick at burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Jan P. Smit wrote:
Dear Phillippe, Very interesting. The URL of the article is http://www.scientific-computing.com/scwsepoct04free_statist
ics.html.
Best regards,
Jan Smit
Philippe Grosjean wrote:
Hello,
In the latest 'Scientific Computing World' magazine (issue 78, p.
22), there
is a review on free statistical software by Felix Grant ("doesn't
have to
pay good money to obtain good statistics software"). As far as I
know, this
is the first time that R is even mentioned in this
magazine, given
that it
usually discuss commercial products.
[ ...]
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
-- Spencer Graves, PhD, Senior Development Engineer O: (408)938-4420; mobile: (408)655-4567
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html