Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
[snip] > Maybe, but given the way things have been working lately, it might be > better to emphasize > > (a) check the mailinglists > (b) try R-patched > (c) if in doubt, ask, rather than report as bug > > (Ideally, people would try the prerelease versions and problems like > this would be caught before the actual release, but it seems that they > prefer treating x.y.0 as a beta release...) > I am sorry but I do not agree with point (b) for the very simple fact that the average Windows user do not know how to compile the source code and might not even want to learn how to do it. The point is that since (if I am correct) the great majority of R users go Windows you would miss an important part of potential bug reports by requiring point (b) whereas (a) and (c) would suffice IMHO. Maybe if there were Win binaries of the prerelease version available some time before the release you would get much more feedback but I am just guessing. Regards Simone > > > > > On 11/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > > >> On Tue, 6 Nov 2007, Simone Giannerini wrote: > >> > >> > >>> I looked at the list of bug fixes before writing and I found that the > >>> only thing close to it is this > >>> > >>> o postscript() was not always ignoring .Postscript.Options in > >>> the workspace (where it should not have occurred). > >>> > >>> but I must admit I did not understand whether it had anything to do > >>> with this bug report. > >>> > >> It occurs on Windows only, and the src/gnuwin32/CHANGES file says > >> > >> BUG FIXES > >> > >> o Saving a plot to Postscript or PDF required the font database > >> to have been initialized: this is now done if necessary. > >> > >> See also > >> > >> https://mailman.stat.ethz.ch/pipermail/r-help/2007-October/142414.html > >> > >> (over a month ago). > >> > >> > >>> Thanks > >>> > >>> Simone > >>> > >>> On 11/6/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: > >>> > This has been reported several times before and has been fixed in > R-patched some weeks ago. > > Uwe Ligges > > > [EMAIL PROTECTED] wrote: > > > Full_Name: Jane L. Harvill > > Version: 2.6.0 > > OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 > > Submission from: (NULL) (129.62.21.93) > > > > > > PROBLEM: The ability to save the contents of an R Graphics window as a > > postscript or PDf file through the drop-down menu (File -> Save As -> > > Postscript, or File -> Save As -> PDF) results in the error message > > below being > > printed to the R Console. > > > > ERROR MESSAGE: > > - > > Error: Invalid font type > > In addition: Warning messages: > > 1: font family not found in PostScript font database > > 2: font family not found in PostScript font database > > - > > > > TO RECREATE THE PROBLEM: > > 1. Using the R Console, create some graph in R; for example, > > plot(rnorm(100)). > > 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). > > 3. Supply a file name and click the "Save" button. > > > > FOUR OTHER RELEVANT NOTES: > > 1. I checked to see if the same error results when invoking the > > functions > > pdf(file=...) or postscript(file=...). No error results, and the > > content of > > the output (.ps or .pdf) file produces a duplicate of what appears in > > the R > > Graphics window. > > > > 2. I checked, but did not see any other bug reports in the system that > > are > > relevant to this problem. > > > > 3. Before I submitted this R Bug Report, I reinstalled the PostScript > > fonts, > > and then reinstalled R Version 2.6.0. This did not change the outcome. > > > > 4. This problem did not exist in previous versions of R on any of my > > computers. > > It exists on all computers for version 2.6.0 of R. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > >>> > >>> > >> -- > >> 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 > >> > >> > > > > > > > > > -- >O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
On Wed, 7 Nov 2007, Simone Giannerini wrote: [snip] Maybe, but given the way things have been working lately, it might be better to emphasize (a) check the mailinglists (b) try R-patched (c) if in doubt, ask, rather than report as bug (Ideally, people would try the prerelease versions and problems like this would be caught before the actual release, but it seems that they prefer treating x.y.0 as a beta release...) I am sorry but I do not agree with point (b) for the very simple fact that the average Windows user do not know how to compile the source code and might not even want to learn how to do it. The point is that since (if I am correct) the great majority of R users go Windows you would miss an important part of potential bug reports by requiring point (b) whereas (a) and (c) would suffice IMHO. Maybe if there were Win binaries of the prerelease version available some time before the release you would get much more feedback but I am just guessing. Windows binaries of R-patched are available all the time via http://cran.r-project.org/bin/windows/base/ They are not always current, but only occasionally are they more than a day or two old. Same for R-devel. The biggest plus point about recommending trying R-patched is that is often the solution to the problem (as here, although there is also a workaround). Regards Simone On 11/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: On Tue, 6 Nov 2007, Simone Giannerini wrote: I looked at the list of bug fixes before writing and I found that the only thing close to it is this o postscript() was not always ignoring .Postscript.Options in the workspace (where it should not have occurred). but I must admit I did not understand whether it had anything to do with this bug report. It occurs on Windows only, and the src/gnuwin32/CHANGES file says BUG FIXES o Saving a plot to Postscript or PDF required the font database to have been initialized: this is now done if necessary. See also https://mailman.stat.ethz.ch/pipermail/r-help/2007-October/142414.html (over a month ago). Thanks Simone On 11/6/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: This has been reported several times before and has been fixed in R-patched some weeks ago. Uwe Ligges [EMAIL PROTECTED] wrote: Full_Name: Jane L. Harvill Version: 2.6.0 OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 Submission from: (NULL) (129.62.21.93) PROBLEM: The ability to save the contents of an R Graphics window as a postscript or PDf file through the drop-down menu (File -> Save As -> Postscript, or File -> Save As -> PDF) results in the error message below being printed to the R Console. ERROR MESSAGE: - Error: Invalid font type In addition: Warning messages: 1: font family not found in PostScript font database 2: font family not found in PostScript font database - TO RECREATE THE PROBLEM: 1. Using the R Console, create some graph in R; for example, plot(rnorm(100)). 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). 3. Supply a file name and click the "Save" button. FOUR OTHER RELEVANT NOTES: 1. I checked to see if the same error results when invoking the functions pdf(file=...) or postscript(file=...). No error results, and the content of the output (.ps or .pdf) file produces a duplicate of what appears in the R Graphics window. 2. I checked, but did not see any other bug reports in the system that are relevant to this problem. 3. Before I submitted this R Bug Report, I reinstalled the PostScript fonts, and then reinstalled R Version 2.6.0. This did not change the outcome. 4. This problem did not exist in previous versions of R on any of my computers. It exists on all computers for version 2.6.0 of R. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 -- 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 -- 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 Ro
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
Jari Oksanen wrote: > On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote: > >> [snip] (this is from pd = Peter Dalgaard) >> >>> Maybe, but given the way things have been working lately, it might be >>> better to emphasize >>> >>> (a) check the mailinglists >>> (b) try R-patched >>> (c) if in doubt, ask, rather than report as bug >>> >>> (Ideally, people would try the prerelease versions and problems like >>> this would be caught before the actual release, but it seems that they >>> prefer treating x.y.0 as a beta release...) >>> >>> >> I am sorry but I do not agree with point (b) for the very simple fact >> that the average Windows user do not know how to compile the source >> code and might not even want to learn how to do it. The point is that >> since (if I am correct) the great majority of R users go Windows you >> would miss an important part of potential bug reports by requiring >> point (b) whereas (a) and (c) would suffice IMHO. >> Maybe if there were Win binaries of the prerelease version available >> some time before the release you would get much more feedback but I am >> just guessing. >> > > First I must say that patched Windows binaries are available from CRAN > with one extra click -- Linux and poor MacOS users must use 'svn co' to > check out the patched version from the repository and compile from the > sources. The attribute "poor" for MacOS users was there because this is > a bigger step for Mac users than Linux users (who can easily get and > install all tools they need and tend to have a different kind of > mentality). > Actually, they can download ftp://ftp.stat.math.ethz.ch/Software/R/R-patched.tar.bz2 They do have to build it (and know how to) though. (Fedora incorporated patches in their RPM updates for a while, which I was beginning to believe was a good idea, all things considered, but they haven't done it (yet?) for 2.6.0.) > Then I must say that I do not like this policy either. I think that is > fair to file a bug report against the latest release version in good > faith without being chastised and condemned. I know (like pd says above) > that some people really do treat x.y.0 as beta releases: a friend of > mine over here even refuses to install R x.x.0 versions just for this > reason (in fact, he's pd's mate, too, but perhaps pd can talk him over > to try x.x.0 versions). Filing a bug report against latest x.x.1 > shouldn't be too bad either. > Of course that strategy just means that .0 becomes the alpha release and .1 the beta > I guess the problem here is that R bug reports are linked to the Rd > mailing list, and reports on "alredy fixed" bugs really are irritating. > In more loosely connected bug reporting systems you simply could mark a > bug as a duplicate of # and mark it as resolved without generating > awfully lot of mail. Then it would be humanly possible to adopt a more > neutral way of answering to people who reported bugs in latest releases. > Probably that won't happen in the current environment. > Someone still needs to do that, manually. But yes, a new bug tracker has been on the wish list for a while. It is not entirely trivial to set one up, though. -- 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] FYI: issue with arpa/inet.h on SunOS 5.9 (old gcc?)
On Wed, 7 Nov 2007, Don MacQueen wrote: > Of course. It was built for Solaris 2.7. > (I did look at R-admin, but not carefully and thoroughly enough.) Good to know (and I didn't expect you to know it was in the manual, was just pointing out where to look for further help). > > Thank you. > -Don > > At 7:33 AM + 11/6/07, Prof Brian Ripley wrote: >> What OS was that compiler built for? This happened when you had a version >> of gcc built for the wrong version of the OS, as gcc captures system >> headers. (There's a warning about that in the R-admin manual.) >> >> The 'report to' message is autogenerated by autoconf. >> >> SunStudio 11 is a recent version of Sun's compilers, and much to be >> preferred to gcc 3.0.4 on that platform (and probably to any version of gcc >> there). >> >> On Mon, 5 Nov 2007, Don MacQueen wrote: >> >>> This just information of my experience installing R on SunOS 5.9 >>> today, not a request for help. >>> (in case anyone cares, and if not, I apologize for the distraction) >>> >>> I am building R 2.6.0 (patched; svn revision 43319, 2007-11-01) and >>> encountered the problem described below. >>> >>> I believe the problem is an old gcc (version 3.0.4, built some 5 >>> years ago), because the warnings do not occur when I specify >>>CC = cc >>> in the environment before configuring, and building R succeeds. >>> >>> Hence I'm mailing to r-devel instead of r-bugs, as suggested in the >>> warning messages. >>> >>> I don't have much information about the cc I used (I'm not the >>> sysadmin of this or any Solaris machine), other than it resides in >>> /opt/SUNWspro, and appears to be part of "Sun Studio 11", whatever >>> that is. >>> >>> >>> The messages from R's configure were: >>> >>> configure: WARNING: arpa/inet.h: present but cannot be compiled >>> configure: WARNING: arpa/inet.h: check for missing prerequisite >>> headers? >>> configure: WARNING: arpa/inet.h: see the Autoconf documentation >>> configure: WARNING: arpa/inet.h: section "Present But Cannot Be >>> Compiled" >>> configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result >>> configure: WARNING: arpa/inet.h: in the future, the compiler will >>> take precedence >>> configure: WARNING: ## --- ## >>> configure: WARNING: ## Report this to [EMAIL PROTECTED] ## >>> configure: WARNING: ## --- ## >>> >>> And then the same set of warnings for >>> netdb.h >>> netinet/in.h >>> sys/socket.h >>> >>> At the very end configure reports: >>> >>> configure: WARNING: could not determine type of socket length >>> >>> >>> Then, make fails with: >>> >>> In file included from /usr/include/netinet/in.h:41, >>> from /usr/include/netdb.h:98, >>> from ../../../R-patched/src/main/platform.c:1586: >>> /usr/include/sys/stream.h:307: parse error before "projid_t" >>> make[3]: *** [platform.o] Error 1 >>> make[3]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>> make[2]: *** [R] Error 2 >>> make[2]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>> make[1]: *** [R] Error 1 >>> make[1]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src' >>> make: *** [R] Error 1 >>> >> >> -- >> 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 > > > -- 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] Saving Graphics File as .ps or .pdf (PR#10403)
Dear Martin, Jari, et al., Another relevant point (which I haven't seen in this discussion -- perhaps I missed it) is that one can read the CHANGES and NEWS files on CRAN without downloading or installing R-patched. Regards, John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Maechler > Sent: Wednesday, November 07, 2007 12:09 PM > To: Jari Oksanen > Cc: r-devel@r-project.org; Peter Dalgaard > Subject: Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403) > > > "JO" == Jari Oksanen <[EMAIL PROTECTED]> > > on Wed, 07 Nov 2007 12:21:10 +0200 writes: > > JO> On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote: > >> [snip] (this is from pd = Peter Dalgaard) > >> > Maybe, but given the way things have been working > lately, it might be > >> > better to emphasize > >> > > >> > (a) check the mailinglists > >> > (b) try R-patched > >> > (c) if in doubt, ask, rather than report as bug > >> > > >> > (Ideally, people would try the prerelease versions > and problems like > >> > this would be caught before the actual release, but > it seems that they > >> > prefer treating x.y.0 as a beta release...) > >> > > >> > >> I am sorry but I do not agree with point (b) for the > very simple fact > >> that the average Windows user do not know how to > compile the source > >> code and might not even want to learn how to do it. > The point is that > >> since (if I am correct) the great majority of R users > go Windows you > >> would miss an important part of potential bug reports > by requiring > >> point (b) whereas (a) and (c) would suffice IMHO. > >> Maybe if there were Win binaries of the prerelease > version available > >> some time before the release you would get much more > feedback but I am > >> just guessing. > > JO> First I must say that patched Windows binaries are > available from CRAN > [] > > JO> Then I must say that I do not like this policy > either. I think that is > JO> fair to file a bug report against the latest release > version in good > JO> faith without being chastised and condemned. > > I agree in principle. > If you do that without any of [abc] above, you do produce a > bit of work to at least one R-core member who has to deal > with the bug report (in the jitterbug archive) in addition to > the usual time consumption (of someone answering) which is > unavoidable and hence ok. > > I think we as R developers should more graciously accept such > false positives in order to get more true positives... > > > JO> I know (like pd says above) that some people really do > JO> treat x.y.0 as beta releases: a friend of mine over here > JO> even refuses to install R x.x.0 versions just for this > JO> reason (in fact, he's pd's mate, too, but perhaps pd can > JO> talk him over to try x.x.0 versions). Filing a bug > JO> report against latest x.x.1 shouldn't be too bad either. > > well, given past experience, I think people *should* adopt > c) in such and more cases, i.e. rather "ask" than "report a > bug", also in light of what you say below, but when people > don't, they still should be handled politely .. > > JO> I guess the problem here is that R bug reports are > linked to the Rd > JO> mailing list, and reports on "alredy fixed" bugs > really are irritating. > JO> In more loosely connected bug reporting systems you > simply could mark a > JO> bug as a duplicate of # and mark it as resolved > without generating > JO> awfully lot of mail. Then it would be humanly > possible to adopt a more > JO> neutral way of answering to people who reported bugs > in latest releases. > JO> Probably that won't happen in the current environment. > > JO> Cheers, Jari Oksanen > > Martin Maechler > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mean mailing list moderator ..
There is a simple solution to this kind of problem - for my non-day-job-related software stuff, I usually subscribe under my sourceforge address. Sourceforge's is simple re-direction service so I actually cannot post from it; but I like incoming e-mails to go through sourceforge for a double spam filter. So e-mails come in through sourceforge but replied under my real address if I do, and it get held occasionally in the past depending on the mailing list policies. The solution I found is this: subscribe both addresses, but disabling delivery to the real-one. (this can be done by the user, no admin required). This way I can post from the real one, but receive twice-filtered mailing-list e-mails through an alias. (For R-devel, I am receiving and posting from my day-job address, if you are wondering...) Martin Maechler wrote: > Hi Jari, > > (and interested readers) > >> "JO" == Jari Oksanen <[EMAIL PROTECTED]> >> on Wed, 07 Nov 2007 12:21:10 +0200 writes: > > [..] > [...some very good stuff...] > [..] > > JO> Cheers, Jari Oksanen > > JO> PS. Please Mr Moderator, don't treat me so mean (*): I've subscribed > to > JO> this group although you regularly reject my mail as coming from a > JO> "non-member". > > More than a year ago, I had changed R-devel policy to > > 1) subscribers can post freely > 2) everything else is on "hold" for moderator approval +) > 3) ``spam-suspicious e-mails'' are also put "on hold". > > Now your problem is that you are subscribed under a different > e-mail address than the one you are currently sending mail from > (and also use in your sig. below). > To the mailing list software (mailman) this is equivalent to a > non-subscriber. > > +) the moderator can **manually** add non-subscriber >addresses to a list which is treated as "allowed to post" >and I could do this next time ... >but my general attitude is that r-devel subscribers should >make these things work... > > Best regards, > Martin > > JO> (*) an extract from a classic song "Mr R jumped the rabbit". > JO> -- > JO> Jari Oksanen <[EMAIL PROTECTED]> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
> "JO" == Jari Oksanen <[EMAIL PROTECTED]> > on Wed, 07 Nov 2007 12:21:10 +0200 writes: JO> On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote: >> [snip] (this is from pd = Peter Dalgaard) >> > Maybe, but given the way things have been working lately, it might be >> > better to emphasize >> > >> > (a) check the mailinglists >> > (b) try R-patched >> > (c) if in doubt, ask, rather than report as bug >> > >> > (Ideally, people would try the prerelease versions and problems like >> > this would be caught before the actual release, but it seems that they >> > prefer treating x.y.0 as a beta release...) >> > >> >> I am sorry but I do not agree with point (b) for the very simple fact >> that the average Windows user do not know how to compile the source >> code and might not even want to learn how to do it. The point is that >> since (if I am correct) the great majority of R users go Windows you >> would miss an important part of potential bug reports by requiring >> point (b) whereas (a) and (c) would suffice IMHO. >> Maybe if there were Win binaries of the prerelease version available >> some time before the release you would get much more feedback but I am >> just guessing. JO> First I must say that patched Windows binaries are available from CRAN [] JO> Then I must say that I do not like this policy either. I think that is JO> fair to file a bug report against the latest release version in good JO> faith without being chastised and condemned. I agree in principle. If you do that without any of [abc] above, you do produce a bit of work to at least one R-core member who has to deal with the bug report (in the jitterbug archive) in addition to the usual time consumption (of someone answering) which is unavoidable and hence ok. I think we as R developers should more graciously accept such false positives in order to get more true positives... JO> I know (like pd says above) that some people really do JO> treat x.y.0 as beta releases: a friend of mine over here JO> even refuses to install R x.x.0 versions just for this JO> reason (in fact, he's pd's mate, too, but perhaps pd can JO> talk him over to try x.x.0 versions). Filing a bug JO> report against latest x.x.1 shouldn't be too bad either. well, given past experience, I think people *should* adopt c) in such and more cases, i.e. rather "ask" than "report a bug", also in light of what you say below, but when people don't, they still should be handled politely .. JO> I guess the problem here is that R bug reports are linked to the Rd JO> mailing list, and reports on "alredy fixed" bugs really are irritating. JO> In more loosely connected bug reporting systems you simply could mark a JO> bug as a duplicate of # and mark it as resolved without generating JO> awfully lot of mail. Then it would be humanly possible to adopt a more JO> neutral way of answering to people who reported bugs in latest releases. JO> Probably that won't happen in the current environment. JO> Cheers, Jari Oksanen Martin Maechler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mean mailing list moderator ..
Hi Jari, (and interested readers) > "JO" == Jari Oksanen <[EMAIL PROTECTED]> > on Wed, 07 Nov 2007 12:21:10 +0200 writes: [..] [...some very good stuff...] [..] JO> Cheers, Jari Oksanen JO> PS. Please Mr Moderator, don't treat me so mean (*): I've subscribed to JO> this group although you regularly reject my mail as coming from a JO> "non-member". More than a year ago, I had changed R-devel policy to 1) subscribers can post freely 2) everything else is on "hold" for moderator approval +) 3) ``spam-suspicious e-mails'' are also put "on hold". Now your problem is that you are subscribed under a different e-mail address than the one you are currently sending mail from (and also use in your sig. below). To the mailing list software (mailman) this is equivalent to a non-subscriber. +) the moderator can **manually** add non-subscriber addresses to a list which is treated as "allowed to post" and I could do this next time ... but my general attitude is that r-devel subscribers should make these things work... Best regards, Martin JO> (*) an extract from a classic song "Mr R jumped the rabbit". JO> -- JO> Jari Oksanen <[EMAIL PROTECTED]> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote: > [snip] (this is from pd = Peter Dalgaard) > > Maybe, but given the way things have been working lately, it might be > > better to emphasize > > > > (a) check the mailinglists > > (b) try R-patched > > (c) if in doubt, ask, rather than report as bug > > > > (Ideally, people would try the prerelease versions and problems like > > this would be caught before the actual release, but it seems that they > > prefer treating x.y.0 as a beta release...) > > > > I am sorry but I do not agree with point (b) for the very simple fact > that the average Windows user do not know how to compile the source > code and might not even want to learn how to do it. The point is that > since (if I am correct) the great majority of R users go Windows you > would miss an important part of potential bug reports by requiring > point (b) whereas (a) and (c) would suffice IMHO. > Maybe if there were Win binaries of the prerelease version available > some time before the release you would get much more feedback but I am > just guessing. First I must say that patched Windows binaries are available from CRAN with one extra click -- Linux and poor MacOS users must use 'svn co' to check out the patched version from the repository and compile from the sources. The attribute "poor" for MacOS users was there because this is a bigger step for Mac users than Linux users (who can easily get and install all tools they need and tend to have a different kind of mentality). Then I must say that I do not like this policy either. I think that is fair to file a bug report against the latest release version in good faith without being chastised and condemned. I know (like pd says above) that some people really do treat x.y.0 as beta releases: a friend of mine over here even refuses to install R x.x.0 versions just for this reason (in fact, he's pd's mate, too, but perhaps pd can talk him over to try x.x.0 versions). Filing a bug report against latest x.x.1 shouldn't be too bad either. I guess the problem here is that R bug reports are linked to the Rd mailing list, and reports on "alredy fixed" bugs really are irritating. In more loosely connected bug reporting systems you simply could mark a bug as a duplicate of # and mark it as resolved without generating awfully lot of mail. Then it would be humanly possible to adopt a more neutral way of answering to people who reported bugs in latest releases. Probably that won't happen in the current environment. Cheers, Jari Oksanen PS. Please Mr Moderator, don't treat me so mean (*): I've subscribed to this group although you regularly reject my mail as coming from a "non-member". (*) an extract from a classic song "Mr R jumped the rabbit". -- Jari Oksanen <[EMAIL PROTECTED]> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.6.0 make check fails on SGI origin 350 and
Hello Prof Brian Ripley and list There is no "d-p-q-r-tests.Rout" file, the following files do exists and are being sent as attachments: ./tests/d-p-q-r-tests.R , ./tests/d-p-q-r-tests.Rout.save , ./tests/d- p-q-r-tests.Rout.fail . Cheers, Kamil Kamil Marcinkowski Westgrid System Administrator [EMAIL PROTECTED] University of Alberta site Tel.780 492-0354 Research Computing Support Fax.780 492-1729 Academic ICT Edmonton, Alberta, CANADAUniversity of Alberta "This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication. If you are not the intended recipient of this communication, do not copy, distribute, or take action on it. Any communication received in error, or subsequent reply, should be deleted or destroyed." On 6-Nov-07, at 4:46 PM, Prof Brian Ripley wrote: > We need to see the d-p-q-r-tests.Rout file, and perhaps ask for some > more runs (unfortunately that line number is after massaging). Can > you make it available to us? Or at least a portion containing the > quoted line (which should only occur once)? > > On Tue, 6 Nov 2007, kamil Marcinkowski wrote: > >> Hello >> >> I am trying to install R 2.6.0 on a SGI Origin 350 running IRIX 6.5 >> 6.5.28f >> >> R was configured with the following options: >> >>> --x-includes=/usr/include/X11 >>> --x-libraries=/usr/lib/X11 >>> --includedir=/usr/freeware/include >>> --includedir=/usr/freeware/lib32 >>> --includedir=/usr/freeware/lib64 >>> --with-readline=no >>> --with-iconv=no >>> CC=cc >> >> >> gmake complied successfully, however gmake check failed on d-p-q-r- >> tests.R . >> >>> running code in 'd-p-q-r-tests.R' ... OK >>> comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ... >>> 959c959 >>> < [1] "Mean scaled difference: NaN" >>> --- [1] TRUE >>> gmake[3]: *** [d-p-q-r-tests.Rout] Error 1 >>> gmake[3]: Leaving directory `/usr/global/R-build/R-2.6.0/tests' >>> gmake[2]: *** [test-Specific] Error 2 >>> gmake[2]: Leaving directory `/usr/global/R-build/R-2.6.0/tests' >>> gmake[1]: *** [test-all-basics] Error 1 >>> gmake[1]: Leaving directory `/usr/global/R-build/R-2.6.0/tests' >>> gmake: *** [check] Error 2 >> >> >> Any ideas would be appreciated. >> >> Cheers, >> >> Kamil >> >> Kamil Marcinkowski Westgrid System Administrator >> [EMAIL PROTECTED] University of Alberta site >> Tel.780 492-0354 Research Computing Support >> Fax.780 492-1729 Academic ICT >> Edmonton, Alberta, CANADAUniversity of Alberta >> >> >> "This communication is intended for the use of the recipient to which >> it is >> addressed, and may contain confidential, personal, and/or privileged >> information. Please contact us immediately if you are not the >> intended >> recipient of this communication. If you are not the intended >> recipient of >> this communication, do not copy, distribute, or take action on it. >> Any >> communication received in error, or subsequent reply, should be >> deleted or >> destroyed." >> >> >> >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > 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] FYI: issue with arpa/inet.h on SunOS 5.9 (old gcc?)
Of course. It was built for Solaris 2.7. (I did look at R-admin, but not carefully and thoroughly enough.) Thank you. -Don At 7:33 AM + 11/6/07, Prof Brian Ripley wrote: >What OS was that compiler built for? This happened when you had a >version of gcc built for the wrong version of the OS, as gcc >captures system headers. (There's a warning about that in the >R-admin manual.) > >The 'report to' message is autogenerated by autoconf. > >SunStudio 11 is a recent version of Sun's compilers, and much to be >preferred to gcc 3.0.4 on that platform (and probably to any version >of gcc there). > >On Mon, 5 Nov 2007, Don MacQueen wrote: > >>This just information of my experience installing R on SunOS 5.9 >>today, not a request for help. >>(in case anyone cares, and if not, I apologize for the distraction) >> >>I am building R 2.6.0 (patched; svn revision 43319, 2007-11-01) and >>encountered the problem described below. >> >>I believe the problem is an old gcc (version 3.0.4, built some 5 >>years ago), because the warnings do not occur when I specify >>CC = cc >>in the environment before configuring, and building R succeeds. >> >>Hence I'm mailing to r-devel instead of r-bugs, as suggested in the >>warning messages. >> >>I don't have much information about the cc I used (I'm not the >>sysadmin of this or any Solaris machine), other than it resides in >>/opt/SUNWspro, and appears to be part of "Sun Studio 11", whatever >>that is. >> >> >>The messages from R's configure were: >> >>configure: WARNING: arpa/inet.h: present but cannot be compiled >>configure: WARNING: arpa/inet.h: check for missing prerequisite headers? >>configure: WARNING: arpa/inet.h: see the Autoconf documentation >>configure: WARNING: arpa/inet.h: section "Present But Cannot Be Compiled" >>configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result >>configure: WARNING: arpa/inet.h: in the future, the compiler will >>take precedence >>configure: WARNING: ## --- ## >>configure: WARNING: ## Report this to [EMAIL PROTECTED] ## >>configure: WARNING: ## --- ## >> >>And then the same set of warnings for >> netdb.h >> netinet/in.h >> sys/socket.h >> >>At the very end configure reports: >> >>configure: WARNING: could not determine type of socket length >> >> >>Then, make fails with: >> >>In file included from /usr/include/netinet/in.h:41, >> from /usr/include/netdb.h:98, >> from ../../../R-patched/src/main/platform.c:1586: >>/usr/include/sys/stream.h:307: parse error before "projid_t" >>make[3]: *** [platform.o] Error 1 >>make[3]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>make[2]: *** [R] Error 2 >>make[2]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>make[1]: *** [R] Error 1 >>make[1]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src' >>make: *** [R] Error 1 >> > >-- >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 -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
On Nov 7, 2007, at 5:21 AM, Jari Oksanen wrote: > > On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote: >> [snip] (this is from pd = Peter Dalgaard) >>> Maybe, but given the way things have been working lately, it might >>> be >>> better to emphasize >>> >>> (a) check the mailinglists >>> (b) try R-patched >>> (c) if in doubt, ask, rather than report as bug >>> >>> (Ideally, people would try the prerelease versions and problems like >>> this would be caught before the actual release, but it seems that >>> they >>> prefer treating x.y.0 as a beta release...) >>> >> >> I am sorry but I do not agree with point (b) for the very simple >> fact that the average Windows user do not know how to compile the >> source code and might not even want to learn how to do it. The >> point is that since (if I am correct) the great majority of R >> users go Windows you would miss an important part of potential bug >> reports by requiring point (b) whereas (a) and (c) would suffice >> IMHO. >> Maybe if there were Win binaries of the prerelease version >> available some time before the release you would get much more >> feedback but I am just guessing. > > First I must say that patched Windows binaries are available from > CRAN with one extra click -- Linux and poor MacOS users must use > 'svn co' to check out the patched version from the repository and > compile from the sources. The attribute "poor" for MacOS users was > there because this is a bigger step for Mac users than Linux users > (who can easily get and install all tools they need and tend to have > a different kind of mentality). > Ehm, you didn't even bother to look at the CRAN page, right? Why am I bothering to build nightly builds of R-patched, and R-devel nightly and even garnishing them with a full installer so they can be installed just like the release version if people don't bother to read just a single web page ... [Insert the usual "please do your homework" part here that may be considered "vitriolic" ... (vitriol is a very useful substance by the way ...)] Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hmisc for Mac OSX.
On 6/11/2007, at 10:35 PM, Ken Beath wrote:
> On 06/11/2007, at 8:59 AM, Rolf Turner wrote:
>
>>
>> I'm not sure if this is the right target to which to direct this
>> post,
>> but I couldn't think of anything more appropriate.
>>
>
> R-Sig-Mac https://stat.ethz.ch/mailman/listinfo/r-sig-mac is for
> mac specific problems
Du! Of course. Why didn't I think of that!
>
>> I just downloaded the Hmisc package to the Imac that I use. When I
>> attempted
>> to load it I got an error to the effect that it could not load the
>> library:
>>
>> /Library/Frameworks/R.framework/Versions/2.5/Resources/lib/
>> libgfortran.2.dylib
>>
>> Note the ``2.5'' in the foregoing path name; I am currently running
>> 2.6.0, and
>> I suspect that this is the problem --- i.e. the Mac binary on CRAN
>> was built
>> under 2.5.x and this does not work with 2.6.y.
>>
>> I note that the source and Windoze Hmisc packages are designated as
>> 3.4-3, but
>> the Mac package is designated as 3.4-2 which would appear to imply
>> that it's
>> a step behind.
>>
>> Could the Mac binary be updated please? Thanks.
>>
>
> The mac binary at central CRAN is a t3.4-3, so it is probably a
> mirror problem,
> CRAN works for me, but uni of melbourne has the old Hmisc, but it
> works under 2.6 anyway.
I was using the Queensland/Brisbane mirror, and the package that I
downloaded
certainly did *not* work! But this morning it appears to have been
updated
to 3.4-3 and that does work. So all is well.
Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64-bit R-build on Mac OS X 10.4 - make check failures
I am not sure why Simon thought you should ask here (and not on R-sig-mac,
say): it is almost certain these are problems with your system not R.
For the first, use your debugger to find where the segfault occurred (it
might be inadequate stack space). For the second, look at the values of
dbeta(0, 0.9, 2.2, ncp = c(0, a)), and trace the C code to find out why
you are not getting Inf (it is probably a broken libm function).
I'd be worried about the first: the second is probably esoteric.
On Wed, 7 Nov 2007, Steven McKinney wrote:
> Hi all,
>
> I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed
> make check. Simon Urbanek suggested I post results to R-devel.
>
>> On Nov 6, 2007, at 10:23 PM, Steven McKinney wrote:
>>
>
>>> Hi Simon,
>>>
>>> Would you be able to give more guidance on how to compile 64-bit
>>> libiconv for Tiger,
>>
>> You can get the sources from Apple and compile it:
>> http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-13.2.tar.gz
>>
>> If you want to save yourself the hassle, my 64-bit build can be
>> obtained and installed as follows:
>> curl -s http://r.research.att.com/libiconv-quad.tar.gz | \
>> sudo tar fvxz - -C /usr/lib
>
> Many thanks to Simon Urbanek for providing a 64-bit libiconv for
> use on the Apple Mac OS X platform. This allowed compilation
> on the Mac without having to use the '--without-iconv' switch
> (for those of us who are not yet proficient at compiling 64-bit
> libraries on the Mac).
>
> Compilation of 64-bit R succeeded, but make check did not.
>
> First failure was in ok-errors.R, and generated this output
> in ok-errors.Rout.fail
>
> > ## bad infinite recursion / on.exit / ... interactions
> > bar <- function() 1+1
> > foo <- function() { on.exit(bar()); foo() }
> > foo() # now simple "infinite recursion"
>
>*** caught segfault ***
> address 0x7fffeff7ffe30, cause 'memory not mapped'
>
> Traceback:
>1: foo()
>2: foo()
>3: foo()
> ...
> 2154: foo()
> 2155: foo()
> 2156: foo()
> aborting ...
>
> Second error was in d-p-q-r-tests.Rout from this test:
> ## dbeta(*, ncp):
> a <- rlnorm(100)
> stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
> dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
> )
> ## the first gave 0, the 2nd NaN in R <= 2.3.0
>
> and generated this
> output in d-p-q-r-tests.Rout.fail
>
> >
> > ## dbeta(*, ncp):
> > a <- rlnorm(100)
> > stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
> + dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
> + )
> Error: dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf is not all TRUE
> In addition: Warning message:
> In dnbeta(x, shape1, shape2, ncp, log) : NaNs produced
> Execution halted
>
> Everything else passed, so I'm not sure how serious these failures are.
>
> I'd appreciate any suggestions about how to figure out what caused these
> failures (an inappropriate file somewhere in the path, a possible
> bug, improper compilation commands etc.)
>
>
> version information of compiled R (compilation information at end):
>
>
>> sessionInfo()
> R version 2.6.0 Patched (2007-10-29 r43302)
> powerpc64-apple-darwin8.10.0
>
> locale:
> C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] lme4_0.99875-8Matrix_0.999375-3 lattice_0.17-2
>
> loaded via a namespace (and not attached):
> [1] grid_2.6.0 rcompgen_0.1-17
>> R.Version()
> $platform
> [1] "powerpc64-apple-darwin8.10.0"
>
> $arch
> [1] "powerpc64"
>
> $os
> [1] "darwin8.10.0"
>
> $system
> [1] "powerpc64, darwin8.10.0"
>
> $status
> [1] "Patched"
>
> $major
> [1] "2"
>
> $minor
> [1] "6.0"
>
> $year
> [1] "2007"
>
> $month
> [1] "10"
>
> $day
> [1] "29"
>
> $`svn rev`
> [1] "43302"
>
> $language
> [1] "R"
>
> $version.string
> [1] "R version 2.6.0 Patched (2007-10-29 r43302)"
>
>> .Platform
> $OS.type
> [1] "unix"
>
> $file.sep
> [1] "/"
>
> $dynlib.ext
> [1] ".so"
>
> $GUI
> [1] "X11"
>
> $endian
> [1] "big"
>
> $pkgType
> [1] "source"
>
> $path.sep
> [1] ":"
>
> $r_arch
> [1] ""
>
>>
>
> I built 64-bit R on Mac OS X 10.
[Rd] 64-bit R-build on Mac OS X 10.4 - make check failures
Hi all,
I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed
make check. Simon Urbanek suggested I post results to R-devel.
> On Nov 6, 2007, at 10:23 PM, Steven McKinney wrote:
>
> > Hi Simon,
> >
> > Would you be able to give more guidance on how to compile 64-bit
> > libiconv for Tiger,
>
> You can get the sources from Apple and compile it:
> http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-13.2.tar.gz
>
> If you want to save yourself the hassle, my 64-bit build can be
> obtained and installed as follows:
> curl -s http://r.research.att.com/libiconv-quad.tar.gz | \
> sudo tar fvxz - -C /usr/lib
Many thanks to Simon Urbanek for providing a 64-bit libiconv for
use on the Apple Mac OS X platform. This allowed compilation
on the Mac without having to use the '--without-iconv' switch
(for those of us who are not yet proficient at compiling 64-bit
libraries on the Mac).
Compilation of 64-bit R succeeded, but make check did not.
First failure was in ok-errors.R, and generated this output
in ok-errors.Rout.fail
> ## bad infinite recursion / on.exit / ... interactions
> bar <- function() 1+1
> foo <- function() { on.exit(bar()); foo() }
> foo() # now simple "infinite recursion"
*** caught segfault ***
address 0x7fffeff7ffe30, cause 'memory not mapped'
Traceback:
1: foo()
2: foo()
3: foo()
...
2154: foo()
2155: foo()
2156: foo()
aborting ...
Second error was in d-p-q-r-tests.Rout from this test:
## dbeta(*, ncp):
a <- rlnorm(100)
stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
)
## the first gave 0, the 2nd NaN in R <= 2.3.0
and generated this
output in d-p-q-r-tests.Rout.fail
>
> ## dbeta(*, ncp):
> a <- rlnorm(100)
> stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
+ dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
+ )
Error: dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf is not all TRUE
In addition: Warning message:
In dnbeta(x, shape1, shape2, ncp, log) : NaNs produced
Execution halted
Everything else passed, so I'm not sure how serious these failures are.
I'd appreciate any suggestions about how to figure out what caused these
failures (an inappropriate file somewhere in the path, a possible
bug, improper compilation commands etc.)
version information of compiled R (compilation information at end):
> sessionInfo()
R version 2.6.0 Patched (2007-10-29 r43302)
powerpc64-apple-darwin8.10.0
locale:
C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lme4_0.99875-8Matrix_0.999375-3 lattice_0.17-2
loaded via a namespace (and not attached):
[1] grid_2.6.0 rcompgen_0.1-17
> R.Version()
$platform
[1] "powerpc64-apple-darwin8.10.0"
$arch
[1] "powerpc64"
$os
[1] "darwin8.10.0"
$system
[1] "powerpc64, darwin8.10.0"
$status
[1] "Patched"
$major
[1] "2"
$minor
[1] "6.0"
$year
[1] "2007"
$month
[1] "10"
$day
[1] "29"
$`svn rev`
[1] "43302"
$language
[1] "R"
$version.string
[1] "R version 2.6.0 Patched (2007-10-29 r43302)"
> .Platform
$OS.type
[1] "unix"
$file.sep
[1] "/"
$dynlib.ext
[1] ".so"
$GUI
[1] "X11"
$endian
[1] "big"
$pkgType
[1] "source"
$path.sep
[1] ":"
$r_arch
[1] ""
>
I built 64-bit R on Mac OS X 10.4.10 with these commands:
export
PATH='/usr/local/lib64/X11/bin:/usr/local/lib64/X11/etc:/usr/local/lib64/X11/include:/usr/local/lib64/X11/lib:/usr/lib:/usr/bin:/usr/local/sbin:/usr/local/bin:/bin:/usr/sbin:/sbin:/usr/local/teTeX/bin/powerpc-apple-darwin-current:~/perl:~/bin'
./configure --host=powerpc64-apple-darwin8.10.0
--build=powerpc64-apple-darwin8.10.0 \
--prefix=/usr/local/lib64 'CC=gcc-4.0 -arch ppc64' 'CXX=g++ -arch ppc64' \
'FC=gfortran-4.0 -arch ppc64' 'F77=gfortran-4.0 -arch ppc64' \
'CFLAGS=-g -O3 -mtune=G5 -mcpu=G5' 'FFLAGS=-g -O3 -mtune=G5 -mcpu=G5' \
'LDFLAGS=-arch ppc64 -m64 -L/usr/local/lib' 'CXXFLAGS=-g -O3 -mtune=G5
-mcpu=G5' \
'FCFLAGS=-g -O3 -mtune=G5 -mcpu=G5' --disable-R-framework --enable-R-shlib \
'--with-blas=-framework vecLib' --with-lapack 1>
configure.R.ppc64.out.20071107.Run01.txt 2>&1
sudo make 1> make.R.ppc64.out.20071107.Run01.txt 2>&1
sudo make check 1> make.check.R.ppc64.out.20071107.Run01.txt 2>&1
Steve McKinney
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A suggestion for an amendment to tapply
On Wed, Nov 07, 2007 at 08:15:17AM +0100, Peter Dalgaard wrote:
> Andrew Robinson wrote:
> >These are important concerns. It seems to me that adding an argument
> >as suggested by Bill will allow the user to side-step the problem
> >identified by Brian.
> >
> >Bill, under what kinds of circumstances would you anticipate a
> >significant time penalty? I would be happy to check those out with
> >some simulations.
> >
> >If the timing seems acceptable, I can write a patch for tapply.R and
> >tapply.Rd if anyone in the core is willing to consider them. Please
> >contact me on or off list if so.
> >
> >
>
> There's another concern: tapply (et al.) has the ... args passed on to
> FUN which means that you have to be really careful with argument names.
>
> Could I just interject that we already have
>
> > airquality$Month <- factor(airquality$Month,levels=4:9) # April not there
> > unlist(lapply(
> +split(airquality$Ozone, airquality$Month, drop=F),sum, na.rm=T))
> 456789
> 0 614 265 1537 1559 912
>
> (splitting on multiple factors gets a bit involved, though)
For that matter, we have
airquality$Month <- factor(airquality$Month,levels=4:9)
air.sum <- tapply(airquality$Ozone, airquality$Month, sum, na.rm=T)
air.sum[is.na(air.sum)] <- 0
which is equivalent to what I ended up using whilst fiddling with tapply.
Andrew
> >Best wishes to all,
> >
> >Andrew
> >
> >
> >
> >
> >On Tue, Nov 06, 2007 at 07:23:56AM +, Prof Brian Ripley wrote:
> >
> >>On Tue, 6 Nov 2007, [EMAIL PROTECTED] wrote:
> >>
> >>
> >>>Unfortunately I think it would break too much existing code. tapply()
> >>>is an old function and many people have gotten used to the way it works
> >>>now.
> >>>
> >>It is also not necessarily desirable: FUN(numeric(0)) might be an error.
> >>For example:
> >>
> >>
> >>>Z <- data.frame(x=rnorm(10), f=rep(c("a", "b"), each=5))[1:5, ]
> >>>tapply(Z$x, Z$f, sd)
> >>>
> >>but sd(numeric(0)) is an error. (Similar things involving var are 'in
> >>the wild' and so would be broken.)
> >>
> >>
> >>>This is not to suggest there could not be another argument added at the
> >>>end to indicate that you want the new behaviour, though. e.g.
> >>>
> >>>tapply <- function (X, INDEX, FUN=NULL, ..., simplify=TRUE,
> >>>handle.empty.levels = FALSE)
> >>>
> >>>but this raises the question of what sort of time penalty the
> >>>modification might entail. Probably not much for most situations, I
> >>>suppose. (I know this argument name looks long, but you do need a
> >>>fairly specific argument name, or it will start to impinge on the ...
> >>>argument.)
> >>>
> >>>Just some thoughts.
> >>>
> >>>Bill Venables.
> >>>
> >>>Bill Venables
> >>>CSIRO Laboratories
> >>>PO Box 120, Cleveland, 4163
> >>>AUSTRALIA
> >>>Office Phone (email preferred): +61 7 3826 7251
> >>>Fax (if absolutely necessary): +61 7 3826 7304
> >>>Mobile: +61 4 8819 4402
> >>>Home Phone: +61 7 3286 7700
> >>>mailto:[EMAIL PROTECTED]
> >>>http://www.cmis.csiro.au/bill.venables/
> >>>
> >>>-Original Message-
> >>>From: [EMAIL PROTECTED]
> >>>[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Robinson
> >>>Sent: Tuesday, 6 November 2007 3:10 PM
> >>>To: R-Devel
> >>>Subject: [Rd] A suggestion for an amendment to tapply
> >>>
> >>>Dear R-developers,
> >>>
> >>>when tapply() is invoked on factors that have empty levels, it returns
> >>>NA. This behaviour is in accord with the tapply documentation, and is
> >>>reasonable in many cases. However, when FUN is sum, it would also
> >>>seem reasonable to return 0 instead of NA, because "the sum of an
> >>>empty set is zero, by definition."
> >>>
> >>>I'd like to raise a discussion of the possibility of an amendment to
> >>>tapply.
> >>>
> >>>The attached patch changes the function so that it checks if there are
> >>>any empty levels, and if there are, replaces the corresponding NA
> >>>values with the result of applying FUN to the empty set. Eg in the
> >>>case of sum, it replaces the NA with 0, whereas with mean, it replaces
> >>>the NA with NA, and issues a warning.
> >>>
> >>>This change has the following advantage: tapply and sum work better
> >>>together. Arguably, tapply and any other function that has a non-NA
> >>>response to the empty set will also work better together.
> >>>Furthermore, tapply shows a warning if FUN would normally show a
> >>>warning upon being evaluated on an empty set. That deviates from
> >>>current behaviour, which might be bad, but also provides information
> >>>that might be useful to the user, so that would be good.
> >>>
> >>>The attached script provides the new function in full, and
> >>>demonstrates its application in some simple test cases.
> >>>
> >>>Best wishes,
> >>>
> >>>Andrew
> >>>
> >>>
> >>--
> >>Brian D. Ripley, [EMAIL PROTECTED]
> >>Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> >>University of Oxford,
