Re: [Rd] BIC doesn't work for glm(family=binomial()) (PR#8208)
[EMAIL PROTECTED] writes: > Full_Name: Ju-Sung Lee > Version: 2.2.0 > OS: Windows XP > Submission from: (NULL) (66.93.61.221) > > > BIC() requires the attribute $nobs from the logLik object but the logLik of a > glm(formula,family=binomial()) object does not include $nobs. Adding > attr(obj,'nobs') = value, seems to allow BIC() to work. > > Reproducing the problem: > library(nmle); > BIC(logLik(glm(1~1,family=binomial(; It is not clear to me that "nobs" is a well-defined concept for arbitrary likelihood functions. In particular, binomial models are tricky: Is "13 successes in 79 trials" one (binomial) observation or 79 (Bernoulli) ones?? So BIC may not be defined. In which sense is this a bug, anyway? The BIC function is defined inside the nlme package which is not designed to work with anything but continuous data. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] BIC doesn't work for glm(family=binomial()) (PR#8208)
On Sun, 16 Oct 2005, Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > >> Full_Name: Ju-Sung Lee >> Version: 2.2.0 >> OS: Windows XP >> Submission from: (NULL) (66.93.61.221) >> >> >> BIC() requires the attribute $nobs from the logLik object but the logLik of a >> glm(formula,family=binomial()) object does not include $nobs. Adding >> attr(obj,'nobs') = value, seems to allow BIC() to work. >> >> Reproducing the problem: >> library(nmle); >> BIC(logLik(glm(1~1,family=binomial(; > > It is not clear to me that "nobs" is a well-defined concept for > arbitrary likelihood functions. In particular, binomial models are > tricky: Is "13 successes in 79 trials" one (binomial) observation or > 79 (Bernoulli) ones?? > > So BIC may not be defined. In which sense is this a bug, anyway? The > BIC function is defined inside the nlme package which is not designed > to work with anything but continuous data. Schwarz originally introduced BIC only for linear regressions (and in essentially the random regressors case as I recall). It is perhaps worth pointing out that 'nobs' (and hence BIC) is not well-defined for a linear mixed model either: the appropriate multiplier suggested by the theory depends on the type of asymptotics which are assumed. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations
Hello James, Duncan and the others, There are interesting arguments in your posts. I think I must react to one of Duncan's considerations: "Philippe, while you think that people are to individualistic in their development of GUIs, I think perhaps a better interpretation is that many of us are trying to develop GUIs quite different from what you have in mind. Your mail talks as if there is a single, yet-to-be created GUI. There is no single concept of a GUI and we have been over this many times to little avail." We probably have the same feeling about the large palette of possible GUIs (look at the page http://www.sciviews.org/_rgui/rgui/GUIs.html, that I wrote more than one year ago). However, my idea is effectively to make a single GUI, flexible enough to accomodate all situations and uses (do I need to add that it is *not* necessarily derived from SciViews, but it must certainly arise from a collaborative work between all people interested in the R-SIG-GUI list and others). There are several functions shared by the various R GUIs, and recoding the same function again and again is really a waste of time. If you carefully look at JGR, SciViews-R and R Commander, you will see that the same main paradigm is used: a script editor in top of bottom of a console window, plus "helpers" to ease beginner's work (menus & dialog boxes, object explorer, etc... Again, not the only possible GUI, but one that proves useful in some situations). For instance, the object explorer has been coded at least three times (once in JGR, once in SciViews-R, and again, a more static and basic one in R -browseEnv() in utils package-). What a waste of time that would have been avoided if there was an "R Object Explorer API" available that everybody can reuse. This is where I see too much individualism: nobody, including myself, considered that the functions they wrote for the object explorer should be done and documented in a way they would be reusable by others (exception of browseEnv(), of course). I could cite countless examples here. Where I am more surprised, it is when I proposed that idea of a reusable R GUI API one year ago, and started to write it, I found no echo at all in other developers. Nobody seems to be interested by the idea of reusable building blocks for R GUIs, although reusability is really the key of successful software development nowodays. Duncan, I am pretty sure you feel that all you did in OmegaHat is underused, probably for the same reason. Other reasons why a good and fully-featured R GUI takes very long to develop in an Open Source context: the lack of programmers. Good R programmers, those who actually make R, are more interested by enhancing R itself than by writting a GUI for it, because they don't need a GUI and are pretty satisfied with the CLI and/or ESS. Other kinds of programmers wanting to participate in the development of Open Source software are more encline to participate to widely used software like Apache, Mozilla, OpenOffice, etc... than to dedicate their free time for programming a GUI for an obscure statistical software, with marginal use compared to the previously cited software. Finally, the only programmers really interested by a R GUI have very specific needs, like the use of R for teaching (John Fox, and myself, for instance)... and it happens that the very few people ready to dedicate a part of their free time to the development of a R GUI all act as individualists, starting their own project alone and with no or little reusability between GUIs projects in mind. In such a context, the situation is pretty desperate. Open Source means software made by users for users... but in the particular case of R GUIs, users that need them (beginners), usually are those that *cannot* participate to their development, and the Open Source paradigm simply does not work as well for that particular reason. That said, we are intelligent and proactive people. So, once the situation is analyzed, could we react in a positive way? Could we decide to put each piece of experience, materialized by several half-finished R GUIs (the current R GUIs that are considered as finished are indeed less ambitious projects, satisfied with a couple of basic features, which is the same result as more ambitious projects flagged as half-finished). Some thinkings in this direction lead me to build a bridge between R Commander and SciViews-R, and in a near future, between Rpad and SciViews-R. Also, with Jose Claudio Faria, we are thinking on a reimplementation of Tinn-R in a platform-independent way, probably Java-based... a possible bridge with JGR is obvious here. These thinkings are summarized in a document: http://www.sciviews.org/EclipseAndR_Evaluation.pdf. Also, for what I tell about the idea of a R GUI API, one could read part II of the SciViews-R manual (http://www.sciviews.org/SciViews-R/Manual.pdf). I am not much interested by endless discussio
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
On Sat, 15 Oct 2005, Duncan Temple Lang wrote: > I think it is a little premature to entirely discount > Gtk2, especially if it is based on Philippe's remark > below. Philippe, did you try other applications, > different themes, different configurations, or just the vanilla GIMP? > and when? While I don't necessarily disagree with the claim that it is > different from Windows look and feel, it requires a little bit more > evidence. My main concern has been stability of gtk/gtk2 under Windows. I've used it off and on for several years, and it has always been flaky -- sometimes it works on one computer but crashes on another, for example. Personally, I have not seen any GTK2-based application that I find better than acceptable as a GUI, whereas I have seen some Qt-based ones I really liked. But I realize this is a matter of individual taste (as it seems are Tk widgets - someone must like them!). However, as an educator I see a lot of resistance to learning new tricks without good reason. If the point of adding a GUI to R is to avoid people learning to use a command-line, it needs to be a GUI with which they are comfortable. (I presume that is part of the reason why applications flocked to MS-Office style GUIs a few years ago.) People (such as me) who are not comfortable with such styles are not in a good position to judge their needs. [...] -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
On 16 October 2005 at 14:04, Prof Brian Ripley wrote: | whereas I have seen some Qt-based ones I really liked. Qt is C++, cross-platform using native widgets on OS X and Win and (since more recently) available without fee or license woes provided it is used for GPL'ed code. So it satisfies both the requirement to make it look and feel native whereever possible, and satisfies the preference for an OO paradigm for GUI programming. Would it be an alternative? Is it worth a prototype app? Regards, Dirk -- Statistics: The (futile) attempt to offer certainty about uncertainty. -- Roger Koenker, 'Dictionary of Received Ideas of Statistics' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Hi, > Qt is C++, cross-platform using native widgets on OS X and Win and (since > more recently) available without fee or license woes provided it is used > for GPL'ed code. > > So it satisfies both the requirement to make it look and feel native > whereever possible, and satisfies the preference for an OO paradigm for GUI > programming. > > Would it be an alternative? Is it worth a prototype app? If you seriously consider writing a Qt app, please have a look at RKWard (at least to find out, which portions of the code to reuse). RKWard is not a pure Qt app, however, but a KDE app. KDE 4 is promised to be cross-platform (but won't be released for another year or so), so I hope RKWard will be cross-platform, then. Also, note that RKWard uses a somewhat different approach, than most other R-GUIs (as far as I know), in that _all_ the GUI stuff is done in C++-code (or plugins). There is no API to build GUI(-elements) from R in rkward, and I don't have plans to add that in the near future. On the discussion iniated by Philippe: I don't think there will ever be a single united R GUI. It's not like this discussion has not come up before. I agree this has something to do with individualistic developers, and I'll admit to being one myself. But there are other reasons as well. What I do believe, is that there could be collaboration in some areas. Years ago I proposed a standard for defining some GUI-elements. Philippe was pretty much the only person expressing interest at that time, but now uses an entirely different approach. Another area could be drawing up a flexible output-format, and R-methods to create such output. R2HTML does a pretty good job, for the time being, but ultimately, we'll want an output format that does some more abstraction, for instance, to allow changing the number of digits to display on the fly, etc. If we could agree on a common standard for this, it could save all projects a lot of effort. (But no, I haven't worked out any specific ideas for this, yet). I think you'll have a hard time, convincing any of the projects to give up their individualistic approaches (including any agreement, even on which programming language to use). All I can see is some projects might share some common standards. Regards Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MBCS support and iconv
I am considering requiring HAVE_ICONV as part of SUPPORT_MBCS for 2.3.0. This would require the iconv from glibc or libiconv if multi-byte character sets (notably UTF-8) are to be usable. As far as I know this would only affect commercial Unixen, where libiconv could be installed. (We know that Linux, Mac OS X and Windows would be unaffected. I suspect from its man pages that FreeBSD nowadays has libiconv installed, despite comments to the contrary in libiconv propaganda.) If anyone sees a problem with this, please let me know soon. This is mainly to simplify support (including documentation) and testing. There are too many paths through the code, and only that using iconv gets more than cursory testing. Also, problems with wide-char support in some OSes are becoming apparent and we can circumvent them by using iconv to do conversions. There are already a number of new internationalization features in R-patched/R-devel (thanks in good part to Ei-ji Nakama), including support for postscript()/pdf() in non-Latin-1 languages. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations
Thomas Friedrichsmeier wrote: > Hi, > > >>Qt is C++, cross-platform using native widgets on OS X and Win and (since >>more recently) available without fee or license woes provided it is used >>for GPL'ed code. >> >>So it satisfies both the requirement to make it look and feel native >>whereever possible, and satisfies the preference for an OO paradigm for GUI >>programming. >> >>Would it be an alternative? Is it worth a prototype app? > > > If you seriously consider writing a Qt app, please have a look at RKWard (at > least to find out, which portions of the code to reuse). RKWard is not a pure > Qt app, however, but a KDE app. KDE 4 is promised to be cross-platform (but > won't be released for another year or so), so I hope RKWard will be > cross-platform, then. > Also, note that RKWard uses a somewhat different approach, than most other > R-GUIs (as far as I know), in that _all_ the GUI stuff is done in C++-code > (or plugins). There is no API to build GUI(-elements) from R in rkward, and I > don't have plans to add that in the near future. > On the discussion iniated by Philippe: I don't think there will ever be a > single united R GUI. It's not like this discussion has not come up before. I > agree this has something to do with individualistic developers, and I'll > admit to being one myself. But there are other reasons as well. > What I do believe, is that there could be collaboration in some areas. Years > ago I proposed a standard for defining some GUI-elements. Philippe was pretty > much the only person expressing interest at that time, but now uses an > entirely different approach. > Another area could be drawing up a flexible output-format, and R-methods to > create such output. R2HTML does a pretty good job, for the time being, but > ultimately, we'll want an output format that does some more abstraction, for > instance, to allow changing the number of digits to display on the fly, etc. > If we could agree on a common standard for this, it could save all projects a > lot of effort. (But no, I haven't worked out any specific ideas for this, > yet). > I think you'll have a hard time, convincing any of the projects to give up > their individualistic approaches (including any agreement, even on which > programming language to use). All I can see is some projects might share some > common standards. > > Regards > Thomas I suspect you are more interested by the challenge of making a R GUI than of having that GUI fully operational for everyday work. People like me *do need* a fully-featured R GUI for their everyday work... and miss it! I spend countless hours to achieve this goal, and I ultimately arrive to the conclusion that the entreprise is huge, and it is very difficult to reach the goal for a single person that dedicate a little bit of its free time to such a project. So, yes, I am ready to give up SciViews and all my convictions to work *collectively* on a common R GUI project. I hope there are other people out there that are more interested by the result than by the fun of starting and managing yet another project on their own,... and that they progressively arrive to the same conclusion: we need to harness several programmers on the same project to have any chance to finish a really full-featured R GUI in a reasonable amount of time. Another problem, for a slowly moving project like SciViews-R is the fast evolution of R itself. It means that almost all the available time is spend making changes just to keep the GUI compatible with the latest R version, leaving very little time for programming new features and for writting the documentation. I took a look at Qt a few times, and I was always stopped by the commercial license (at least under Windows). I just visit Qt web site. Yes, indeed, there is a GPL license now. Very good news! Best, Philippe Grosjean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Greetings all, While recognizing that "this is easier said, than done", is there any logic in suggesting that for those who might be interested, a specific R GUI session of sorts be added to the UseR! 2006 meeting schedule? Since some quorum of interested GUI users may be planning to attend the meeting or may be motivated to do so, it may be an opportunity to: 1. Leverage face to face interaction and visualize possible options 2. Define areas of commonality 3. Bring some level of focus to targeted segments of the user base that would utilize a GUI and for whom there may be differing functional requirements. 4. Identify cross-platform opportunities and technologies 5. See further notes below... Some of the preliminary work could no doubt be done in advance to better prepare and structure discussion. This could be done as a "breakout" session or if there is sufficient interest (and facility/funding issues can be resolved) perhaps a group session held the day before or perhaps the day after the main conference program. If there is a core group that is interested in pursuing this, an announcement could be made to the respective R e-mail lists (r-help, r-devel, r-sig-gui, etc.) whereby, with the sufficient lead time as we have, the requisite activities could be put in place to orchestrate the session, define specific desired outcomes and identify individuals willing to spend their time to coordinate and make this venture successful (however success would be defined). There is no business or financial motivation here for a GUI. If there was and a for profit company decided that there would be a significant return on investment, they would spend the money, hire the resources, define a team leader and put forth a single development spec for a GUI project based upon their own market research. It would be done in a relatively authoritarian fashion and if you didn't agree, you would be asked to find a job elsewhere. Here, you would need to solicit voluntary resources, reconcile the expected differences of opinion on the spectrum of matters that would have to be addressed and define some common framework for operating, perhaps based upon targeted user segments. This subject, as mentioned, has come up on the lists previously, with no common resolution, resulting of course in the individual activities that have emerged. Is there a group of motivated useRs out there, who have the time, energy, and skills and are willing to work within the framework of a design and development "team" environment, where a quid pro quo for moving forward could evolve from the User! 2006 meeting? Is there an individual, who would need to emerge from that group, who has the respect and requisite skills to drive a consensus of opinion and keep a team focused and moving in the proper direction? If so, that might be a step in the direction of evolving a GUI that might make sense for some yet to be defined range of useRs, who would not otherwise utilize the CLI or might need to evolve in that direction over time. If not, then the status quo continues... There are some 300 Linux distributions out there and multiple X based GUIs, which have evolved for reasons as varied as those behind the available R GUIs and more. Yet there are a select few base Linux distributions and largely two GUIs that have garnered any significant market share. Perhaps, over time, lacking any coordinated activity, a similar situation will evolve here, if the predicate that a broad demand for a R GUI is valid. If the predicate is false, then this process is perhaps rightly done by individuals meeting narrowly focused, local requirements. I should note, that I am not prospective GUI user, but a happy ESS user. I simply thought that I would try to provoke some discussion on this point, since I jumped into this thread earlier in the week. Best regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Interesting. So, we've got lots of people that want GUIs, lots of variants with existing prototypes, and lots of clamor for skilled collaborators. As most of the work has seemed to be of the "I know this, and this is what I want to do", it will be interesting to see how it shakes out. I've still not seen a GUI that I'd call good. There are many adequate ones, and I've finally reached the point of appreciating the adequacy of the MS approach (which is different than my previous attitude). I hope someone creates a good one that is stable. That's half the problem right there, in that the implementation is a huge component of the theory. Widget sets are less interesting than the overall approach, but unfortunately provide the basic characterizations of what might be possible. best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cross compiler taqrgeting Mac OS X
Hi, I have been asked to produce a binary of some software for somone running R on Mac OS X. I don't have a Mac and don't know anything about them. The sloution would seem to be to obtain/build a crsoo compiler on windows or probably easier on Linux i686. I would appreciate any advice on how how to go about this. I understand there are a number of different versions of Mac OS X. Are there compatability issues? also 32/64 bit issues. Dave -- David A. Fournier P.O. Box 2040, Sidney, B.C. V8l 3s3 Canada http://otter-rsch.com -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How can I use the function in "Defn.h"?
Hi, all
I am in the process of writing my first R extesion package. My extension
does not do statistics analysis. It serilizes the call, sends the call
to remote computer. The remote compuer will evaluate the call and
returns the result back to client machine. The idea is inspired by the
taskPR package, which is much more complex than what I want to
accomplish. I use some code from taskPR.
One of the function uses StrToInternal function(I copy it from taskPR
package). I noticed the StrToInternal was defined in "Defn.h".
When I load my extension and library, I got this error
---
> library("btRRTest")
Error in dyn.load(x, as.logical(local), as.logical(now)) :
unable to load shared library
'/common/apps/lib/R/library/btRRTest/libs/btRRTest.so':
/common/apps/lib/R/library/btRRTest/libs/btRRTest.so: undefined
symbol: StrToInternal
Error in library("btRRTest") : .First.lib failed for 'btRRTest'
My understand is that the "StrToInternal" should be compiled in a shared
library such as R.so. How can I use this function in my code to avoid
the "undefined symbol" error?
Thanks
-jason
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
