================================================= This is an automated collection of open reports in the R-bugs repository. ================================================= Directory: Accuracy * PR# 1228 * Subject: bug with var(rep(1e30, 3)) From: Emmanuel Paradis Date: Wed, 26 Dec 2001 13:03:31 +0100 --needs a bit of work on src/main/cov.c ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1228 <== From postmaster@franz.stat.wisc.edu Wed Dec 26 13:07:55 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id NAA13232 for ; Wed, 26 Dec 2001 13:07:55 +0100 (MET) Received: from isem.isem.univ-montp2.fr (really [162.38.183.200]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Wed, 26 Dec 2001 06:07:27 -0600 (CST) Received: from diversi (diversi.isem.univ-montp2.fr [162.38.183.45]) by isem.isem.univ-montp2.fr (8.9.1b+Sun/8.9.1) with SMTP id MAA19343 for ; Wed, 26 Dec 2001 12:58:33 +0100 (MET) Message-Id: <3.0.32.20011226130330.00910b80@162.38.183.200> X-Sender: paradis@162.38.183.200 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Dec 2001 13:03:31 +0100 To: r-bugs@r-project.org From: Emmanuel Paradis Subject: bug with var(rep(1e30, 3)) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id NAA13232 There seems to be a bug with var() when the argument is a vector with exactly three values of 1e30 (or close to this value). This does not happen with twice, four (or more) times this value, or another value. > var(rep(1e30, 3)) [1] 2.971056e+28 > var(rep(1.2e30, 3)) [1] 2.971056e+28 > var(rep(0.9e30, 3)) [1] 2.971056e+28 > var(rep(0.8e30, 3)) [1] 0 > var(rep(1e29, 3)) [1] 0 > var(rep(1e30, 2)) [1] 0 > var(rep(1e30, 4)) [1] 0 > var(rep(1e31, 3)) [1] 0 The bug is repeatable, and I got the same results with R 1.3.1 (binary from CRAN) and R 1.4.0 (binary from BD Ripley's site) both on Windows NT, and R 1.4.0 on Solaris (compiled from sources). Emmanuel Paradis Laboratoire de Paléontologie Institut des Sciences de l'Évolution Université Montpellier II F-34095 Montpellier cédex 05 France phone: +33 4 67 14 39 64 fax: +33 4 67 14 36 10 mailto:paradis@isem.univ-montp2.fr ==> 1228.reply.1 <== From p.dalgaard@biostat.ku.dk Wed Dec 26 15:32:38 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA13516; Wed, 26 Dec 2001 15:32:38 +0100 (MET) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id fBQEVRP24017; Wed, 26 Dec 2001 15:31:27 +0100 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: paradis@isem.univ-montp2.fr Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] bug with var(rep(1e30, 3)) (PR#1228) References: <200112261207.NAA13242@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 26 Dec 2001 15:31:27 +0100 In-Reply-To: <200112261207.NAA13242@pubhealth.ku.dk> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii paradis@isem.univ-montp2.fr writes: > There seems to be a bug with var() when the argument is a vector with > exactly three values of 1e30 (or close to this value). This does not happen > with twice, four (or more) times this value, or another value. > > > > var(rep(1e30, 3)) > [1] 2.971056e+28 > > var(rep(1.2e30, 3)) > [1] 2.971056e+28 > > var(rep(0.9e30, 3)) > [1] 2.971056e+28 > > var(rep(0.8e30, 3)) > [1] 0 > > var(rep(1e29, 3)) > [1] 0 > > var(rep(1e30, 2)) > [1] 0 > > var(rep(1e30, 4)) > [1] 0 > > var(rep(1e31, 3)) > [1] 0 > > > The bug is repeatable, and I got the same results with R 1.3.1 (binary from > CRAN) and R 1.4.0 (binary from BD Ripley's site) both on Windows NT, and R > 1.4.0 on Solaris (compiled from sources). Not a bug, roundoff: > (1e30+1e30+1e30)/3-1e30 [1] 1.407375e+14 > 3*((1e30+1e30+1e30)/3-1e30)^2/2 [1] 2.971056e+28 Relative errors of the order 1e-16 are completely expectable in floating point arithmetic. For illustration, look at it in octal, after removing a bunch of trailing zeroes: > x<-1e30/(8^16) > structure(x, class="octmode") [1] "144762623464043165" > structure(x+x+x, class="octmode") [1] "456730272634151540" If you look carefully, you will see that a bit is lost in the process since 5+5+5 is 17 octal. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1228.followup.1 <== From ripley@stats.ox.ac.uk Wed Dec 26 16:52:52 2001 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA13677; Wed, 26 Dec 2001 16:52:51 +0100 (MET) Received: from gannet.stats (IDENT:root@gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id PAA29226; Wed, 26 Dec 2001 15:52:25 GMT Received: from localhost (ripley@localhost) by gannet.stats (8.11.3/8.11.3) with ESMTP id fBQFqPg12750; Wed, 26 Dec 2001 15:52:25 GMT X-Authentication-Warning: gannet.stats: ripley owned process doing -bs Date: Wed, 26 Dec 2001 15:52:25 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: To: Peter Dalgaard BSA cc: , Subject: Re: [Rd] bug with var(rep(1e30, 3)) (PR#1228) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII But there are better algorithms that are not subject to this sort of rounding error. I reckon that computing a variance this way is not the quality of algorithm one should expect from R. On 26 Dec 2001, Peter Dalgaard BSA wrote: > paradis@isem.univ-montp2.fr writes: > > > There seems to be a bug with var() when the argument is a vector with > > exactly three values of 1e30 (or close to this value). This does not happen > > with twice, four (or more) times this value, or another value. > > > > > > > var(rep(1e30, 3)) > > [1] 2.971056e+28 > > > var(rep(1.2e30, 3)) > > [1] 2.971056e+28 > > > var(rep(0.9e30, 3)) > > [1] 2.971056e+28 > > > var(rep(0.8e30, 3)) > > [1] 0 > > > var(rep(1e29, 3)) > > [1] 0 > > > var(rep(1e30, 2)) > > [1] 0 > > > var(rep(1e30, 4)) > > [1] 0 > > > var(rep(1e31, 3)) > > [1] 0 > > > > > > The bug is repeatable, and I got the same results with R 1.3.1 (binary from > > CRAN) and R 1.4.0 (binary from BD Ripley's site) both on Windows NT, and R > > 1.4.0 on Solaris (compiled from sources). > > Not a bug, roundoff: > > > (1e30+1e30+1e30)/3-1e30 > [1] 1.407375e+14 > > 3*((1e30+1e30+1e30)/3-1e30)^2/2 > [1] 2.971056e+28 > > Relative errors of the order 1e-16 are completely expectable in > floating point arithmetic. > > For illustration, look at it in octal, after removing a bunch of > trailing zeroes: > > > x<-1e30/(8^16) > > structure(x, class="octmode") > [1] "144762623464043165" > > structure(x+x+x, class="octmode") > [1] "456730272634151540" > > If you look carefully, you will see that a bit is lost in the process > since 5+5+5 is 17 octal. > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1228.reply.2 <== From p.dalgaard@biostat.ku.dk Wed Dec 26 18:01:10 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA13867; Wed, 26 Dec 2001 18:01:10 +0100 (MET) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id fBQGxxE24151; Wed, 26 Dec 2001 17:59:59 +0100 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: Prof Brian Ripley Cc: Peter Dalgaard BSA , , Subject: Re: [Rd] bug with var(rep(1e30, 3)) (PR#1228) References: From: Peter Dalgaard BSA Date: 26 Dec 2001 17:59:59 +0100 In-Reply-To: Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Prof Brian Ripley writes: > But there are better algorithms that are not subject to this sort > of rounding error. > > I reckon that computing a variance this way is not the quality of > algorithm one should expect from R. Hmm. Which algorithms are there? Surely almost any kind of provisional means subtraction could avoid the the extreme case where the mean of a bunch of identical numbers is different from all of them, but will it also improve precision in the general case? Essentially our current algorithm in cov.c is xm<- sum(x)/n v <- 1/(n-1)*sum((x-xm)^2) > > > x<-1e30/(8^16) > > > structure(x, class="octmode") > > [1] "144762623464043165" > > > structure(x+x+x, class="octmode") > > [1] "456730272634151540" > > > > If you look carefully, you will see that a bit is lost in the process > > since 5+5+5 is 17 octal. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1228.reply.3 <== From maechler@stat.math.ethz.ch Tue Apr 6 12:10:15 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3A2F8EC53 for ; Tue, 6 Apr 2004 12:10:15 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27402-06 for ; Tue, 6 Apr 2004 12:10:14 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 6 Apr 2004 12:10:13 +0200 (CEST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i36AADO2017399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2004 12:10:13 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.10/8.12.8/Submit) id i36AACS5026625; Tue, 6 Apr 2004 12:10:12 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16498.33284.713813.746088@gargle.gargle.HOWL> Date: Tue, 6 Apr 2004 12:10:12 +0200 To: daheiser@gvn.net Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Accuracy Bug (PR#1228), (PR#6743) In-Reply-To: <20040406022435.4A6C0EFB4@slim.kubism.ku.dk> References: <20040406022435.4A6C0EFB4@slim.kubism.ku.dk> X-Mailer: VM 7.17 under Emacs 21.3.2 Reply-To: Martin Maechler X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >>>>> "daheiser" == daheiser >>>>> on Tue, 6 Apr 2004 04:24:35 +0200 (CEST) writes: daheiser> It is an error in the algorithm. "it" being the behavior reported in bug report PR#1228 --- [too bad you didn't use the whole string "PR#1228" in your subject; if you had, no new report would have been created, and things would have gone to the proper place in the R-bugs repository ...] namely the fact that var(rep(1e30, n)) does not always (for all n) give 0. With the following function tst.var <- function(x,nset= 2:100) { for(n in nset) { v <- var(rep(x,n)) if(v != 0) cat(sprintf("%4d: %20.12g\n", n,v)) } } Actually, on my current desktop (AMD Athlon,Linux, R 1.9.0beta) the computations seem to be more often exact than they used to: Even tst.var(1e30, 2:5000) doesn't produce any output nor do a few other 'x' arguments I tried --- but the fundamental criticism is still correct, and even on the Athlon, it's easy to find cases where tst.var() *does* produce output. daheiser> It is an excellent example of how errors and daheiser> faults occur when the programmer follows the daheiser> mathematical formula exactly. Welford's algorithm daheiser> does not produce this error. It gives correct daheiser> standard deviation and variance values. Actually, after reading @article{ChaTL97, author = {Tony F. Chan and John Gregg Lewis}, title = {Computing standard deviations: accuracy}, journal = {Commun. ACM}, volume = 22, number = 9, year = 1979, issn = {0001-0782}, pages = {526--531}, doi = {http://doi.acm.org/10.1145/359146.359152}, publisher = {ACM Press}, } @article{WesD97, author = {D. H. D. West}, title = {Updating mean and variance estimates: an improved method}, journal = {Commun. ACM}, volume = 22, number = 9, year = 1979, issn = {0001-0782}, pages = {532--535}, doi = {http://doi.acm.org/10.1145/359146.359153}, publisher = {ACM Press}, } I'd conclude (from page 531) that Welford's algorithm is a bit less accurate than the (very similar) "West" version, and we (the R developers) should rather implement the latter. Maybe for R 1.9.1 -- or even later {there are even more important numerical accuracy problems I know about!} Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ==> 1228.audit <== Fri Dec 28 20:08:08 2001 thomas moved from incoming to Accuracy Tue Apr 6 17:46:35 2004 maechler changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2894 * Subject: qbeta hang From: terra@gnome.org Date: Thu, 1 May 2003 22:43:59 +0200 (MET DST) --R 1.7.1 incorporates the two suggestions of the 2nd followup: -- r = sqrt(-2 * log (a)) and ...(log1p(-a) + log (qq))... -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2894 <== From terra@gnome.org Thu May 1 22:44:00 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h41Khx2b017785 for ; Thu, 1 May 2003 22:43:59 +0200 (MET DST) Date: Thu, 1 May 2003 22:43:59 +0200 (MET DST) Message-Id: <200305012043.h41Khx2b017785@pubhealth.ku.dk> From: terra@gnome.org To: R-bugs@biostat.ku.dk Subject: qbeta hang Full_Name: Morten Welinder Version: 1.6.1 OS: Solaris/sparc Submission from: (NULL) (65.213.85.144) qbeta(0.1, 1e-8, 0.5, TRUE, FALSE) seems to hang for me. ==> 2894.reply.1 <== From p.dalgaard@biostat.ku.dk Fri May 2 00:16:13 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h41MGD2b018113; Fri, 2 May 2003 00:16:13 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h41MK78e014746; Fri, 2 May 2003 00:20:07 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h41MK6Ja014742; Fri, 2 May 2003 00:20:06 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: terra@gnome.org Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] qbeta hang (PR#2894) References: <200305012044.h41Ki02b017789@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 02 May 2003 00:20:06 +0200 In-Reply-To: <200305012044.h41Ki02b017789@pubhealth.ku.dk> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii terra@gnome.org writes: > Full_Name: Morten Welinder > Version: 1.6.1 > OS: Solaris/sparc > Submission from: (NULL) (65.213.85.144) > > > qbeta(0.1, 1e-8, 0.5, TRUE, FALSE) seems to hang for me. confirmed on 1.7.0 Solaris 9, gcc 3.0.3 (standard build, so -O2, I assume) Morten: the gcc version is often crucial in these cases. However, the exact same thing is happening on Linux. The immediate cause is that n = fmax2(lneps/log(y), 4.0) gets large when y is in the vicinity of 1-1e-8, so the loop in src/nmath/pbeta.c:101 gets a rather high count. The algorithm isn't really stuck, it just takes a very long time. On the fastest machine that I have available: > system.time(qbeta(0.1, 1e-8, 0.5, TRUE, FALSE)) [1] 75.58 0.00 75.58 0.00 0.00 It's not really that surprising: > pbeta(1e-5, 1e-8, 0.5,, TRUE, FALSE) [1] 0.9999999 > pbeta(1e-10, 1e-8, 0.5,, TRUE, FALSE) [1] 0.9999998 > pbeta(1e-200, 1e-8, 0.5,, TRUE, FALSE) [1] 0.9999954 > pbeta(1e-309, 1e-8, 0.5,, TRUE, FALSE) [1] 0.999993 > pbeta(1e-400, 1e-8, 0.5,, TRUE, FALSE) [1] 0 and you're trying to solve pbeta(x, 1e-8, 0.5,, TRUE, FALSE) == 0.1 -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 2894.followup.1 <== From dmurdoch@pair.com Fri May 2 00:38:53 2003 Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h41Mcp2b018208 for ; Fri, 2 May 2003 00:38:52 +0200 (MET DST) Received: from djmfuj ([65.93.70.143]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030501223850.JWNE22698.tomts13-srv.bellnexxia.net@djmfuj>; Thu, 1 May 2003 18:38:50 -0400 From: Duncan Murdoch To: terra@gnome.org Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] qbeta hang (PR#2894) Date: Thu, 01 May 2003 18:38:49 -0400 Message-ID: References: <200305012044.h41Ki02b017789@pubhealth.ku.dk> In-Reply-To: <200305012044.h41Ki02b017789@pubhealth.ku.dk> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, 1 May 2003 22:44:00 +0200 (MET DST), you wrote: >Full_Name: Morten Welinder >Version: 1.6.1 >OS: Solaris/sparc >Submission from: (NULL) (65.213.85.144) > > >qbeta(0.1, 1e-8, 0.5, TRUE, FALSE) seems to hang for me. In 1.7.0-patched in Windows, it's very, very slow, but eventually produces an answer: > qbeta(0.1, 1e-8, 0.5, TRUE, FALSE) [1] 4.400784e-309 The answer should be really small (the mean is 2e-8, and it's strongly skewed to the right), so I'd guess it's giving the right answer, and is just slow to converge to it. Duncan Murdoch ==> 2894.followup.2 <== From welinder@rentec.com Fri May 2 16:03:42 2003 Received: from ram.rentec.com (ram.rentec.com [192.5.35.66]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h42E3e2b026336; Fri, 2 May 2003 16:03:41 +0200 (MET DST) Received: from robbie.rentec.com (robbie.rentec.com [192.5.35.99]) by ram.rentec.com (8.12.1/8.12.1) with ESMTP id h42E3OR5024597; Fri, 2 May 2003 10:03:24 -0400 (EDT) Received: (from welinder@localhost) by robbie.rentec.com (8.12.5+Sun/8.12.5/Submit) id h42E3NcU001790; Fri, 2 May 2003 10:03:23 -0400 (EDT) Date: Fri, 2 May 2003 10:03:23 -0400 (EDT) Message-Id: <200305021403.h42E3NcU001790@robbie.rentec.com> From: Morten Welinder To: p.dalgaard@biostat.ku.dk CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk In-reply-to: (message from Peter Dalgaard BSA on 02 May 2003 00:20:06 +0200) Subject: Re: [Rd] qbeta hang (PR#2894) References: <200305012044.h41Ki02b017789@pubhealth.ku.dk> Ok, I can confirm that it does not, in fact, loop forever. Just a close approximation. > Morten: the gcc version is often crucial in these cases. Sorry. gcc-2.7.2 (both -O2 and -O0) on Solaris 2.9 / sparc. The problems seem to be... 1. The initial guess underflows to zero. 2. That guess is replaced by the truly awful guess 0.5. 3. The root finding algorithm ignores all the nice properties of pbeta -- such as it being monotonically increasing and bounded. > and you're trying to solve pbeta(x, 1e-8, 0.5,, TRUE, FALSE) == 0.1 Not quite. What I was trying to do was the see what would happen with an insanely small alpha. Actually doing that would involve getting the arguments right, of course, :-) The not-quite-hang was an unplesant side effect of swapping the args. I notice things like r = sqrt(-log(a * a)); in the code. I fail to see why that isn't just r = sqrt(-2 * log (a)) which ought to be faster and more accurate. Then later ...log((1. - a) * qq)... which might be better as ...(log1p(-a) + log (qq))... if a is close to zero. There are lots of other places that worry me with respect to cancellation errors, for example r = 1 - pp; t = 1 - qq; Morten ==> 2894.audit <== Thu May 22 23:01:16 2003 thomas moved from incoming to Accuracy Mon Jun 16 11:24:33 2003 maechler changed notes Mon Jun 16 11:24:33 2003 maechler foobar Mon Jun 16 11:24:56 2003 maechler changed notes Mon Jun 16 11:24:56 2003 maechler foobar ==> 2894.followup.3 <== From tim.massingham@ebi.ac.uk Mon Sep 22 15:47:29 2003 Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8MDlSJH021438 for ; Mon, 22 Sep 2003 15:47:29 +0200 (MET DST) Received: from teapot.ebi.ac.uk (teapot.ebi.ac.uk [172.22.100.116]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id h8MDlJm01253 for ; Mon, 22 Sep 2003 14:47:19 +0100 (BST) From: Tim Massingham Organization: EBI Subject: PR#2894 Date: Mon, 22 Sep 2003 14:47:54 +0100 User-Agent: KMail/1.5.1 To: r-bugs@biostat.ku.dk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309221447.54338.tim.massingham@ebi.ac.uk> X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-5.8, required 5, USER_AGENT_KMAIL -5.80) >Date: Fri, 2 May 2003 10:03:23 -0400 (EDT) From: Morten Welinder >To: p.dalgaard@biostat.ku.dk >CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk >Subject: Re: [Rd] qbeta hang (PR#2894) > >Ok, I can confirm that it does not, in fact, loop forever. Just a close >approximation. ... >There are lots of other places that worry me with respect to cancellation >errors, for example > > r = 1 - pp; > t = 1 - qq; These can also be removed by changing qbeta.c:156-157 (R-1.7.1) to y = (y-a) * xinbta * (1.0-xinbta) * exp (logbeta - pp * log(xinbta) - qq * log1p(-xinbta)); I don't understand why you have qbeta.c:167 if (fabs(y)<=acu) goto L_converged which will fail for certain values of p & q, when x is close to zero as the beta density tends to infinity. Why not use an exit condition based on how far away from 'a' you are? qbeta.c:174 (prevent excess precision) Might this not just get optimized out? I doubt modern compilers respect the volatile keyword. You should probably replace this with a safe comparison. if(fabs(tx-xinbta)<=DBL_EPSILON*fabs(xinbta))... ** This should be checked with someone familiar with floating point arithmetic; I'm not and may have got the correct expression wrong. The 'infinite loop' is due to the speed of the pbeta routine, rather than the initial approximation from the qbeta. There is another algorithm available for pbeta (Algorithm 708, CACM 18. 360--373, 1992) which may be of use here. This continued fraction approximation is recommended by Numerical Recipes over the power series approximation (make of that what you will!) TimM. ==> 2894.followup.4 <== From tim.massingham@ebi.ac.uk Mon Sep 22 15:49:10 2003 Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8MDn9JH021470 for ; Mon, 22 Sep 2003 15:49:10 +0200 (MET DST) Received: from teapot.ebi.ac.uk (teapot.ebi.ac.uk [172.22.100.116]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id h8MDn4m01806 for ; Mon, 22 Sep 2003 14:49:04 +0100 (BST) From: Tim Massingham Organization: EBI Subject: Re: PR#2894 Date: Mon, 22 Sep 2003 14:49:40 +0100 User-Agent: KMail/1.5.1 To: r-bugs@biostat.ku.dk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309221449.40171.tim.massingham@ebi.ac.uk> X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-15.5, required 5, EMAIL_ATTRIBUTION -6.50, QUOTED_EMAIL_TEXT -3.20, USER_AGENT_KMAIL -5.80) On Monday 22 Sep 2003 2:36 pm, I wrote: > The 'infinite loop' is due to the speed of the pbeta routine, rather > than the initial approximation from the qbeta. There is another > algorithm available for pbeta (Algorithm 708, CACM 18. 360--373, 1992) That should be TOMS, not CACM. Sorry. > which may be of use here. This continued fraction approximation is > recommended by Numerical Recipes over the power series approximation > (make of that what you will!) TimM. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5727 * Subject: Bug in pbinom? From: Volkmar Liebscher Date: Fri, 12 Dec 2003 11:18:12 +0100 --(really on of the infamous border case problem of pbeta) ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5727 <== From mailnull@stat.math.ethz.ch Fri Dec 12 11:19:22 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id 6EDB2FC00 for ; Fri, 12 Dec 2003 11:19:21 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hBCAHamw004986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2003 11:17:36 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id hBCAHZ7F004985 for R-bugs@biostat.ku.dk; Fri, 12 Dec 2003 11:17:35 +0100 (MET) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hBCAHNmv004962 for ; Fri, 12 Dec 2003 11:17:25 +0100 (MET) Received: from servus.gsf.de ([146.107.101.11]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 1AUkO0-0001lI-00 for ; Fri, 12 Dec 2003 04:19:04 -0600 Received: from hausdorff.gsf.de (hausdorff.gsf.de [146.107.58.25]) by servus.gsf.de (8.8.6 (PHNE_17135)/8.8.6.+++) with ESMTP id LAA09567 for ; Fri, 12 Dec 2003 11:21:36 +0100 (MET) From: Volkmar Liebscher Reply-To: liebscher@gsf.de Organization: GSF To: r-bugs@r-project.org Subject: Bug in pbinom? Date: Fri, 12 Dec 2003 11:18:12 +0100 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200312121118.12004.liebscher@gsf.de> X-MIME-Autoconverted: from 8bit to quoted-printable by servus.gsf.de id LAA09567 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hypatia.math.ethz.ch id hBCAHNmv004962 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hypatia.math.ethz.ch X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Level: Dear colleagues, the command pbinom(size=1.95*10^10,prob=seq(1.02,1.03,10^-3)*10^-10,q=1,lower=F,log=T) produced the output [1] -46.0120973 -46.0101369 -46.0081784 -46.0062239 -46.0042692 -46.0023165 [7] -0.5205666 -0.5196801 -0.5187944 -0.5179102 -0.5170278 what seems strange. Has this survived in newer versions? Best regards, Volkmar Liebscher -- Dr. Volkmar Liebscher Institute of Biomathematics and Biometry GSF - National Research Centre for Environment and Health Ingolstädter Landstr.1 D--85758 Neuherberg Germany E-mail: liebscher@gsf.de URL: http://www.gsf.de/ibb/homepages/liebscher phone: +49 89 3187 2907 Fax: +49 89 3187 3369 --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 7.1 year = 2003 month = 06 day = 16 language = R Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base ==> 5727.followup.1 <== From ripley@stats.ox.ac.uk Fri Dec 12 11:44:59 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0991FFC00 for ; Fri, 12 Dec 2003 11:44:59 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id hBCAivoO002696; Fri, 12 Dec 2003 10:44:57 GMT Date: Fri, 12 Dec 2003 10:44:43 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: liebscher@gsf.de Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Bug in pbinom? (PR#5727) In-Reply-To: <20031212101923.309D2FC01@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Oh, come on: have you never heard of the Poisson approximation? > ppois(1, 1.95*seq(1.02,1.03,10^-3), lower=F,log=T) [1] -0.5259247 -0.5250276 -0.5241321 -0.5232383 -0.5223462 -0.5214557 [7] -0.5205669 -0.5196798 -0.5187943 -0.5179104 -0.5170282 Probably you believe that computers never make errors too. On Fri, 12 Dec 2003 liebscher@gsf.de wrote: > Dear colleagues, > > the command > > pbinom(size=1.95*10^10,prob=seq(1.02,1.03,10^-3)*10^-10,q=1,lower=F,log=T) > > produced the output > > [1] -46.0120973 -46.0101369 -46.0081784 -46.0062239 -46.0042692 -46.0023165 > [7] -0.5205666 -0.5196801 -0.5187944 -0.5179102 -0.5170278 > > > what seems strange. Has this survived in newer versions? > > Best regards, > Volkmar Liebscher > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 5727.audit <== Mon Dec 15 08:29:22 2003 ripley moved from incoming to Accuracy Tue Apr 6 17:44:55 2004 maechler changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6196 * Subject: Accuracy: Correct sums in rowSums(), colSums() From: Nick.Efthymiou@Schwab.com Date: Tue, 30 Dec 2003 01:57:19 +0100 (CET) --no requested patch against the current sources forthcoming. -- --Seems unlikely to be worthwhile for rowSums and not sum! ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6196 <== From Nick.Efthymiou@Schwab.com Tue Dec 30 01:57:20 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id F26811044C for ; Tue, 30 Dec 2003 01:57:19 +0100 (CET) From: Nick.Efthymiou@Schwab.com To: R-bugs@biostat.ku.dk Subject: Accuracy: Correct sums in rowSums(), colSums() Message-Id: <20031230005719.F26811044C@slim.kubism.ku.dk> Date: Tue, 30 Dec 2003 01:57:19 +0100 (CET) Full_Name: Nick Efthymiou Version: R1.5.0 and above OS: Red Hat Linux Submission from: (NULL) (162.93.14.73) With the introduction of the functions rowSums(), colSums(), rowMeans() and colMeans() in R1.5.0, function "SEXP do_colsum(SEXP call, SEXP op, SEXP args, SEXP rho)" was added to perform the fast summations. We have an excellent opportunity to improve the accuracy by implementing Kahan summation here. Kahan summation is described in @article{ goldberg91what, author = "David Goldberg", title = "What Every Computer Scientist Should Know About Floating-Point Arithmetic", journal = "ACM Computing Surveys", volume = "23", number = "1", pages = "5--48", year = "1991", url = "citeseer.nj.nec.com/goldberg91what.html" } (http://citeseer.nj.nec.com/goldberg91what.html) and in the article "Floating-point Summation", by Evan Manning, in C/C++ User's Journal, Sept. 1996. The proposed improvement has been tested in !IEEE_754 mode, the patch is attached. It is intended to be applied against R-1.7.1/src/main/array.c --------- Cut here ---------- *** array.c.old Mon Dec 15 17:33:23 2003 --- array.c Mon Dec 15 17:33:45 2003 *************** *** 1016,1022 **** int OP, n, p, cnt = 0, i, j, type; Rboolean NaRm, keepNA; int *ix; ! double *rx, sum = 0.0; checkArity(op, args); x = CAR(args); args = CDR(args); --- 1016,1022 ---- int OP, n, p, cnt = 0, i, j, type; Rboolean NaRm, keepNA; int *ix; ! double *rx, sum = 0.0, correction = 0.0; checkArity(op, args); x = CAR(args); args = CDR(args); *************** *** 1046,1062 **** switch (type) { case REALSXP: rx = REAL(x) + n*j; #ifdef IEEE_754 if (keepNA) ! for (sum = 0., i = 0; i < n; i++) sum += *rx++; else { ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} } #else ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} #endif break; --- 1046,1082 ---- switch (type) { case REALSXP: rx = REAL(x) + n*j; + sum = 0.; #ifdef IEEE_754 if (keepNA) ! for (i = 0; i < n; i++) sum += *rx++; else { ! for (cnt = 0, i = 0; i < n; i++, rx++) ! if (!ISNAN(*rx)) { ! /* TODO: Kahan summation */ ! cnt++; sum += *rx; ! } else if (keepNA) {sum = NA_REAL; break;} } #else ! i = cnt = 0; ! if (i < n) { ! if (ISNAN(*rx)) { ! if (keepNA) {sum = NA_REAL; break /* switch */;} ! } else { ! cnt++; sum = *rx; ! } ! i++; rx++; ! } ! for (; i < n; i++, rx++) ! if (!ISNAN(*rx)) { ! /* Kahan summation */ ! double yhilo = *rx - correction; ! double tsum = sum + yhilo; ! correction = (tsum - sum) - yhilo; ! sum = tsum; ! cnt++; ! } else if (keepNA) {sum = NA_REAL; break;} #endif break; *************** *** 1121,1137 **** switch (type) { case REALSXP: rx = REAL(x) + i; #ifdef IEEE_754 if (keepNA) ! for (sum = 0., j = 0; j < p; j++, rx += n) sum += *rx; else { ! for (cnt = 0, sum = 0., j = 0; j < p; j++, rx += n) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} } #else ! for (cnt = 0, sum = 0., j = 0; j < p; j++, rx += n) ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} else if (keepNA) {sum = NA_REAL; break;} #endif break; --- 1141,1177 ---- switch (type) { case REALSXP: rx = REAL(x) + i; + sum = 0.; #ifdef IEEE_754 if (keepNA) ! for (j = 0; j < p; j++, rx += n) sum += *rx; else { ! for (cnt = 0, j = 0; j < p; j++, rx += n) ! if (!ISNAN(*rx)) { ! /* TODO: Kahan summation */ ! cnt++; sum += *rx; ! } else if (keepNA) {sum = NA_REAL; break;} } #else ! j = cnt = 0; ! if (j < p) { ! if (ISNAN(*rx)) { ! if (keepNA) {sum = NA_REAL; break /* switch */;} ! } else { ! cnt++; sum = *rx; ! } ! j++; rx += n; ! } ! for (; j < p; j++, rx += n) ! if (!ISNAN(*rx)) { ! /* Kahan summation */ ! double yhilo = *rx - correction; ! double tsum = sum + yhilo; ! correction = (tsum - sum) - yhilo; ! sum = tsum; ! cnt++; ! } else if (keepNA) {sum = NA_REAL; break;} #endif break; ---------end of patch ------- Since someone is certainly wondering why I bothered to bring this up - I was trying to optimize the order of a Chebyshev approximation to a specific function so that I accomplish the most power-efficient calculation at one ulp accuracy (multiplications and additions consume battery power). The optimization was based on minimizing the relative error between the true function and the approximation. It involved a lot of sums and was not converging properly. With the patch, I got the convergence I needed. Thanks, - Nick - ==> 6196.followup.1 <== From ripley@stats.ox.ac.uk Tue Dec 30 09:30:23 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id C64B710457 for ; Tue, 30 Dec 2003 09:30:22 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id hBU8ULoO014755; Tue, 30 Dec 2003 08:30:21 GMT Date: Tue, 30 Dec 2003 08:30:21 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: Nick.Efthymiou@schwab.com Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Accuracy: Correct sums in rowSums(), colSums() (PR#6196) In-Reply-To: <20031230005720.9CEC71044D@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Could you please prepare a patch against the current R-devel sources? 1.7.1 is several versions old. I was puzzled as to why you are recommending improving the accuracy of the `fast' methods and not the slow one, applying apply() to mean() and sum(). The improvement might be larger in those cases: what Goldberg calls `a dramatic improvement' is from N eps down to 2 eps, and that is for the worst case and is only dramatic if N is dramatically bigger than 2. It is also not clear that it is effective on machines with extended-precision registers unless N is very large. Some of us are well aware of the issues of floating point arithmetic, but R is normally used for statistical computations, where errors in the data (rounding, measurement etc) normally are orders of magnitude bigger than those in floating-point arithmetic. So implementation effort has been spent on handling the statistical errors first. On Tue, 30 Dec 2003 Nick.Efthymiou@schwab.com wrote: > Full_Name: Nick Efthymiou > Version: R1.5.0 and above > OS: Red Hat Linux > Submission from: (NULL) (162.93.14.73) > > > With the introduction of the functions rowSums(), colSums(), rowMeans() and > colMeans() in R1.5.0, function "SEXP do_colsum(SEXP call, SEXP op, SEXP args, > SEXP rho)" was added to perform the fast summations. We have an excellent > opportunity to improve the accuracy by implementing Kahan summation here. > > Kahan summation is described in > > @article{ goldberg91what, > author = "David Goldberg", > title = "What Every Computer Scientist Should Know About Floating-Point > Arithmetic", > journal = "ACM Computing Surveys", > volume = "23", > number = "1", > pages = "5--48", > year = "1991", > url = "citeseer.nj.nec.com/goldberg91what.html" } > > > (http://citeseer.nj.nec.com/goldberg91what.html) > > and in the article "Floating-point Summation", by Evan Manning, in C/C++ User's > Journal, Sept. 1996. > > The proposed improvement has been tested in !IEEE_754 mode, the patch is > attached. > It is intended to be applied against R-1.7.1/src/main/array.c > > --------- Cut here ---------- > *** array.c.old Mon Dec 15 17:33:23 2003 > --- array.c Mon Dec 15 17:33:45 2003 > *************** > *** 1016,1022 **** > int OP, n, p, cnt = 0, i, j, type; > Rboolean NaRm, keepNA; > int *ix; > ! double *rx, sum = 0.0; > > checkArity(op, args); > x = CAR(args); args = CDR(args); > --- 1016,1022 ---- > int OP, n, p, cnt = 0, i, j, type; > Rboolean NaRm, keepNA; > int *ix; > ! double *rx, sum = 0.0, correction = 0.0; > > checkArity(op, args); > x = CAR(args); args = CDR(args); > *************** > *** 1046,1062 **** > switch (type) { > case REALSXP: > rx = REAL(x) + n*j; > #ifdef IEEE_754 > if (keepNA) > ! for (sum = 0., i = 0; i < n; i++) sum += *rx++; > else { > ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) > ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} > else if (keepNA) {sum = NA_REAL; break;} > } > #else > ! for (cnt = 0, sum = 0., i = 0; i < n; i++, rx++) > ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} > else if (keepNA) {sum = NA_REAL; break;} > #endif > break; > --- 1046,1082 ---- > switch (type) { > case REALSXP: > rx = REAL(x) + n*j; > + sum = 0.; > #ifdef IEEE_754 > if (keepNA) > ! for (i = 0; i < n; i++) sum += *rx++; > else { > ! for (cnt = 0, i = 0; i < n; i++, rx++) > ! if (!ISNAN(*rx)) { > ! /* TODO: Kahan summation */ > ! cnt++; sum += *rx; > ! } > else if (keepNA) {sum = NA_REAL; break;} > } > #else > ! i = cnt = 0; > ! if (i < n) { > ! if (ISNAN(*rx)) { > ! if (keepNA) {sum = NA_REAL; break /* switch */;} > ! } else { > ! cnt++; sum = *rx; > ! } > ! i++; rx++; > ! } > ! for (; i < n; i++, rx++) > ! if (!ISNAN(*rx)) { > ! /* Kahan summation */ > ! double yhilo = *rx - correction; > ! double tsum = sum + yhilo; > ! correction = (tsum - sum) - yhilo; > ! sum = tsum; > ! cnt++; > ! } > else if (keepNA) {sum = NA_REAL; break;} > #endif > break; > *************** > *** 1121,1137 **** > switch (type) { > case REALSXP: > rx = REAL(x) + i; > #ifdef IEEE_754 > if (keepNA) > ! for (sum = 0., j = 0; j < p; j++, rx += n) sum += *rx; > else { > ! for (cnt = 0, sum = 0., j = 0; j < p; j++, rx += n) > ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} > else if (keepNA) {sum = NA_REAL; break;} > } > #else > ! for (cnt = 0, sum = 0., j = 0; j < p; j++, rx += n) > ! if (!ISNAN(*rx)) {cnt++; sum += *rx;} > else if (keepNA) {sum = NA_REAL; break;} > #endif > break; > --- 1141,1177 ---- > switch (type) { > case REALSXP: > rx = REAL(x) + i; > + sum = 0.; > #ifdef IEEE_754 > if (keepNA) > ! for (j = 0; j < p; j++, rx += n) sum += *rx; > else { > ! for (cnt = 0, j = 0; j < p; j++, rx += n) > ! if (!ISNAN(*rx)) { > ! /* TODO: Kahan summation */ > ! cnt++; sum += *rx; > ! } > else if (keepNA) {sum = NA_REAL; break;} > } > #else > ! j = cnt = 0; > ! if (j < p) { > ! if (ISNAN(*rx)) { > ! if (keepNA) {sum = NA_REAL; break /* switch */;} > ! } else { > ! cnt++; sum = *rx; > ! } > ! j++; rx += n; > ! } > ! for (; j < p; j++, rx += n) > ! if (!ISNAN(*rx)) { > ! /* Kahan summation */ > ! double yhilo = *rx - correction; > ! double tsum = sum + yhilo; > ! correction = (tsum - sum) - yhilo; > ! sum = tsum; > ! cnt++; > ! } > else if (keepNA) {sum = NA_REAL; break;} > #endif > break; > ---------end of patch ------- > > > Since someone is certainly wondering why I bothered to bring this up - I was > trying to optimize the order of a Chebyshev approximation to a specific function > so that I accomplish the most power-efficient calculation at one ulp accuracy > (multiplications and additions consume battery power). The optimization was > based on minimizing the relative error between the true function and the > approximation. It involved a lot of sums and was not converging properly. With > the patch, I got the convergence I needed. > > Thanks, > > - Nick - > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6196.audit <== Thu Jan 8 15:30:46 2004 ripley moved from incoming to Accuracy Mon Mar 15 21:33:24 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6743 * Subject: Accuracy Bug 1228 From: "David Heiser" Date: Mon, 5 Apr 2004 19:23:35 -0700 --This is really bug PR#1228 (in category 'Accuracy') ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6743 <== From daheiser@gvn.net Tue Apr 6 04:24:06 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 9DE91EDF1 for ; Tue, 6 Apr 2004 04:24:06 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24016-02 for ; Tue, 6 Apr 2004 04:24:05 +0200 (CEST) Received: from rook.innercite.com (rook.innercite.com [158.222.5.8]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 6 Apr 2004 04:23:38 +0200 (CEST) Received: from f0q5g8 (host-224-114.dialup.innercite.com [158.222.224.114]) by rook.innercite.com (8.12.3/8.12.3/Debian-6.4) with SMTP id i362NZ3N018444 for ; Mon, 5 Apr 2004 19:23:36 -0700 From: "David Heiser" To: Subject: Accuracy Bug 1228 Date: Mon, 5 Apr 2004 19:23:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-0.1 required=5.0 tests=MSGID_GOOD_EXCHANGE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) It is an error in the algorithm. It is an excellent example of how errors and faults occur when the programmer follows the mathematical formula exactly. Welford's algorithm does not produce this error. It gives correct standard deviation and variance values. David Heiser ==> 6743.audit <== Tue Apr 6 17:40:49 2004 maechler changed notes Tue Apr 6 17:40:49 2004 maechler moved from incoming to Accuracy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6772 * Subject: phyper accuracy and efficiency From: terra@gnome.org Date: Thu, 15 Apr 2004 18:06:08 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6772 <== From terra@gnome.org Thu Apr 15 18:06:08 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 2D24CEFC2 for ; Thu, 15 Apr 2004 18:06:08 +0200 (CEST) From: terra@gnome.org To: R-bugs@biostat.ku.dk Subject: phyper accuracy and efficiency Message-Id: <20040415160608.2D24CEFC2@slim.kubism.ku.dk> Date: Thu, 15 Apr 2004 18:06:08 +0200 (CEST) X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_20,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Morten Welinder Version: snapshot OS: Submission from: (NULL) (65.213.85.218) Time to kick phyper's tires... The current version has very serious cancellation issues. For example, if you ask for a small right-tail you are likely to get total cancellation. For example phyper(59, 150, 150, 60, FALSE, FALSE) gives 6.372680161e-14. The right answer is dhyper(0, 150, 150, 60, FALSE) which is 5.111204798e-22. phyper is also really slow for large arguments. Therefore, I suggest using the code below. This is a sniplet from Gnumeric, so you'll have to s/gnm_float/double/ and s/gnum//, etc. The code isn't perfect. In fact, if i*(NR+NB) is close to n*NR, then this code can take a while. Not longer than the old code, though. /* * New phyper implementation. Copyright 2004 Morten Welinder. * Distributed under the GNU General Public License. * * Thanks to Ian Smith for ideas. */ /* * Calculate * * phyper (i, NR, NB, n, TRUE, FALSE) * [log] ---------------------------------- * dhyper (i, NR, NB, n, FALSE) * * without actually calling phyper. This assumes that * * i * (NR + NB) <= n * NR * */ static gnm_float pdhyper (gnm_float i, gnm_float NR, gnm_float NB, gnm_float n, gboolean log_p) { gnm_float sum = 0; gnm_float term = 1; while (i > 0 && term >= GNUM_EPSILON * sum) { term *= i * (NB - n + i) / (n + 1 - i) / (NR + 1 - i); sum += term; i--; } return log_p ? log1pgnum (sum) : 1 + sum; } gnm_float phyper (gnm_float i, gnm_float NR, gnm_float NB, gnm_float n, int lower_tail, int log_p) { gnm_float d, pd; #ifdef IEEE_754 if (isnangnum (i) || isnangnum (NR) || isnangnum (NB) || isnangnum (n)) return i + NR + NB + n; #endif i = floorgnum (i + 1e-7); NR = floorgnum (NR + 0.5); NB = floorgnum (NB + 0.5); n = floorgnum (n + 0.5); if (NR < 0 || NB < 0 || !finitegnum (NR + NB) || n < 0 || n > NR + NB) ML_ERR_return_NAN; if (i * (NR + NB) > n * NR) { /* Swap tails. */ gnm_float oldNB = NB; NB = NR; NR = oldNB; i = n - i - 1; lower_tail = !lower_tail; } if (i < 0) return R_DT_0; d = dhyper (i, NR, NB, n, log_p); pd = pdhyper (i, NR, NB, n, log_p); return log_p ? R_DT_log (d + pd) : R_D_Lval (d * pd); } ==> 6772.audit <== Fri Apr 16 18:26:36 2004 ripley moved from incoming to Accuracy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Add-ons * PR# 974 * Subject: Lattice: panel.superpose with ordered factor groups From: John Maindonald Date: Sat, 9 Jun 2001 11:08:51 +1000 (EST) --The warning is standard S and R behaviour. --Probably xyplot needs to avoid it (by unclassing?) --Still there in lattice 0.3-0, 0.6-8 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 974 <== From postmaster@franz.stat.wisc.edu Sat Jun 9 03:09:10 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id DAA20814 for ; Sat, 9 Jun 2001 03:09:09 +0200 (MET DST) Received: from leonard.anu.edu.au (really [150.203.2.15]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Fri, 8 Jun 2001 20:09:01 -0500 (CDT) Received: (from u9801539@localhost) by leonard.anu.edu.au (8.9.3/8.9.3) id LAA01081; Sat, 9 Jun 2001 11:08:51 +1000 (EST) Date: Sat, 9 Jun 2001 11:08:51 +1000 (EST) From: John Maindonald Message-Id: <200106090108.LAA01081@leonard.anu.edu.au> To: r-bugs@r-project.org Subject: Lattice: panel.superpose with ordered factor groups Cc: deepayan@stat.wisc.edu # r-bugs@r-project.org The panel.superpose() function for xyplot() complains when the groups parameter is set to be an ordered factor. > library(mass) > data(cabbages) > library(lattice) > xyplot(HeadWt~VitC|Cult, panel=panel.superpose, + groups=Date, data=cabbages) > cabbages$Date <- ordered(cabbages$Date) # Make Date an ordered factor > xyplot(HeadWt~VitC|Cult, panel=panel.superpose, + groups=Date, data=cabbages) Warning messages: 1: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" 2: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" 3: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" 4: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" 5: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" 6: Incompatible methods ("Ops.ordered", "Ops.factor") for "==" --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = x86 os = Win32 system = x86, Win32 status = major = 1 minor = 2.3 year = 2001 month = 04 day = 26 language = R Windows ME 4.90 (build 3000) Search Path: .GlobalEnv, package:grid, package:lattice, package:mass, package:ctest, Autoloads, package:base John Maindonald email: john.maindonald@anu.edu.au phone : (6125)3998 fax : (6125)5549 Statistical Consulting Unit, Room 1194, John Dedman Mathematical Sciences Building (Centre for Mathematics & Its Applications.) ==> 974.audit <== Sun Jun 17 09:39:36 2001 ripley changed notes Sun Jun 17 09:39:36 2001 ripley foobar Sun Jun 17 09:39:36 2001 ripley moved from incoming to Add-ons Sun Sep 30 15:13:56 2001 ripley changed notes Sun Sep 30 15:13:56 2001 ripley foobar Wed Jan 8 11:14:52 2003 ripley changed notes Wed Jan 8 11:14:52 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1361 * Subject: Matrix identification bug From: hyu@stats.uwo.ca Date: Tue, 5 Mar 2002 21:19:46 +0100 (MET) --seems to be about Matrix package, not solve ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1361 <== From hyu@stats.uwo.ca Tue Mar 5 21:19:46 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA08030 for ; Tue, 5 Mar 2002 21:19:46 +0100 (MET) Date: Tue, 5 Mar 2002 21:19:46 +0100 (MET) From: hyu@stats.uwo.ca Message-Id: <200203052019.VAA08030@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Matrix identification bug Full_Name: Hao Yu Version: 1.4.1 OS: Windws and Linux Submission from: (NULL) (129.100.45.161) Hi, Recently we did some benchmarks regarding matrix inverse operation and found some strange things. See the following results (the package Matrix is most updated). 1. load the function Toeplitz and library(Matrix) "Toeplitz" function(x) { matrix(x[1 + abs(outer(seq(along = x), seq(along = x), FUN = "-"))], byrow = T, ncol = length(x)) } 2. On a PIII 1.125GHz (256kb cache)desktop PC with win2k, the results are > system.time(solve(Toeplitz(.5^seq(0,999)))) [1] 38.25 0.22 42.01 NA NA > system.time(solve.Matrix(Toeplitz(.5^seq(0,999)))) [1] 28.01 0.17 30.94 NA NA On a PIII-M 1.2GHz (512kb cache) laptop PC with winxp pro, the results are > system.time(solve(Toeplitz(.5^seq(0,999)))) [1] 33.94 0.25 34.01 NA NA > system.time(solve.Matrix(Toeplitz(.5^seq(0,999)))) [1] 9.40 0.13 9.54 NA NA On a PIII Xeon 1GHz (256kb cache) RedHat 7.2 Linux, the results are > system.time(solve(Toeplitz(.5^seq(0,999)))) [1] 53.79 0.48 00.01 NA NA > system.time(solve.Matrix(Toeplitz(.5^seq(0,999)))) [1] 30.29 0.21 30.59 NA NA This was the first time that windows R outperformed linux R even PIII Xeon 1GHz is slightly faster than PIII 1.125GHz. Notice the abnormal result 9.4s from PIII-M 1.2GHz (cannot be three times faster). After using native fortran lapack (call to dpotrf and dpotri returns 9s for PIII Xeon), I realized that R may treat the matrix as a general matrix rather than symmetric except the abnormal case. To confirm this, I modified the R_LapackPP.cc in Matrix package and it turned out that is.MMatrix() failed to return true. Hence if (checkClass(classes, "Hermitian")) return new LaSymmMatDouble(x); is not executed in static LaMatDouble* asLaMatrix(SEXP x). Instead if (isMatrix(x)) { return new LaGenMatDouble(x); } is used. After replaced return new LaGenMatDouble(x); with return new LaSymmMatDouble(x); the result was (PIII Xeon 1GHz RedHat 7.2 Linux)) > system.time(solve.Matrix(Toeplitz(.5^seq(0,999)))) [1] 9.76 0.22 9.97 0.00 0.00 Clearly there are some bugs in solve() and solve.Matrix(). Notice that all have > is.Hermitian(Toeplitz(.5^seq(0,999))) [1] TRUE Thanks Hao Yu ==> 1361.followup.1 <== From ripley@stats.ox.ac.uk Tue Mar 5 22:32:30 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA08212 for ; Tue, 5 Mar 2002 22:32:30 +0100 (MET) Received: from tern.stats (pc2-oxfo4-0-cust120.oxf.cable.ntl.com [62.254.131.120]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id VAA24644; Tue, 5 Mar 2002 21:31:57 GMT Date: Tue, 5 Mar 2002 21:32:31 +0000 (GMT Standard Time) From: Prof Brian D Ripley To: hyu@stats.uwo.ca cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Matrix identification bug (PR#1361) In-Reply-To: <200203052019.VAA08035@pubhealth.ku.dk> Message-ID: Sender: ripley@stats.ox.ac.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 5 Mar 2002 hyu@stats.uwo.ca wrote: > Full_Name: Hao Yu > Version: 1.4.1 > OS: Windws and Linux > Submission from: (NULL) (129.100.45.161) [...] > the result was (PIII Xeon 1GHz RedHat 7.2 Linux)) > > system.time(solve.Matrix(Toeplitz(.5^seq(0,999)))) > [1] 9.76 0.22 9.97 0.00 0.00 > > Clearly there are some bugs in solve() and solve.Matrix(). Notice that all have Nothing in this report suggests a bug in solve(). Can you please provide some evidence for your claim (which is not `clear' to me), and > solve function (a, b, ...) UseMethod("solve") seems hard to get wrong! (It matters: solve is part of R: solve.Matrix is a contributed addon.) Incidentally, these sort of timings are crucially dependent on the BLAS library used, and in my experience that is a far larger factor that the OS used. However, that was not part of the report .... -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1361.audit <== Thu Mar 7 12:41:18 2002 ripley changed notes Thu Mar 7 12:41:18 2002 ripley foobar Thu Mar 7 12:41:18 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1662 * Subject: fisher.test FEXACT memory bug "should not occur" From: Martin Maechler Date: Thu, 13 Jun 2002 08:21:50 +0200 --The supplementary (table of sum one) is fixed for 1.5.1. --Detection code for the first problem has been added to 1.5.1 which will stop --the crash, but the underlying cause is still open. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1662 <== From maechler@stat.math.ethz.ch Thu Jun 13 08:22:43 2002 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA16033 for ; Thu, 13 Jun 2002 08:22:42 +0200 (MET DST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id IAA01485 for ; Thu, 13 Jun 2002 08:21:35 +0200 (MET DST) Received: from lynne(129.132.58.30), claiming to be "lynne.ethz.ch" via SMTP by hypatia, id smtpdAAAa000Jg; Thu Jun 13 08:21:26 2002 Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id g5D6LoC13482; Thu, 13 Jun 2002 08:21:50 +0200 X-Authentication-Warning: lynne.ethz.ch: maechler set sender to maechler@stat.math.ethz.ch using -f From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.14846.214663.363944@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 08:21:50 +0200 To: R-bugs@stat.math.ethz.ch Subject: fisher.test FEXACT memory bug "should not occur" X-Mailer: VM 7.07 under Emacs 20.7.1 Reply-To: Martin Maechler This is a bad bug as reported by Robin Hankin, it is still in "R-patched" ... ##- From: Robin Hankin ##- To: r-help@stat.math.ethz.ch ##- Subject: [R] possum sleeping: thanks and fisher.test() FEXACT error ##- Date: Thu, 13 Jun 2002 16:46:26 +1200 ## ..... ## Example slighlty modified (MM) d4 <- matrix(c(0, 0, 0, 0, 0, 0, 3, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 2, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 0, 4, 0, 2, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 2, 0, 0, 0, 2, 2, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 2, 0, 0, 0, 0, 8, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 1, 0, 0, 2, 0, 0, 0, 0, 2, 0, 0, 1, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 4, 0, 0, 0, 0), nr=50) fisher.test(d4) ##- Error in fisher.test(alldata[, 2:5]) : FEXACT error 30. ##- Stack length exceeded in f3xact. ##- This problem should not occur. ==> 1662.followup.1 <== From ligges@amadeus.statistik.uni-dortmund.de Thu Jun 13 08:58:58 2002 Received: from nx5.HRZ.Uni-Dortmund.DE (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA16332 for ; Thu, 13 Jun 2002 08:58:57 +0200 (MET DST) Received: from amadeus.statistik.uni-dortmund.de by nx5.HRZ.Uni-Dortmund.DE via smtp-local with ESMTP; Thu, 13 Jun 2002 08:56:18 +0200 Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id g5D6uH708478; Thu, 13 Jun 2002 08:56:18 +0200 (MET DST) Message-ID: <3D084237.3F455ED2@statistik.uni-dortmund.de> Date: Thu, 13 Jun 2002 08:56:55 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: maechler@stat.math.ethz.ch CC: R-bugs@biostat.ku.dk Subject: Re: fisher.test FEXACT memory bug "should not occur" (PR#1662) References: <200206130622.IAA16038@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit maechler@stat.math.ethz.ch wrote: > > This is a bad bug as reported by Robin Hankin, > it is still in "R-patched" ... > > ##- From: Robin Hankin > ##- To: r-help@stat.math.ethz.ch > ##- Subject: [R] possum sleeping: thanks and fisher.test() FEXACT error > ##- Date: Thu, 13 Jun 2002 16:46:26 +1200 > > ## ..... > > ## Example slighlty modified (MM) > > d4 <- matrix(c(0, 0, 0, 0, 0, 0, 3, 0, 1, 0, 0, 0, 0, 0, 0, > 1, 0, 0, 0, 0, 1, 0, 0, 2, 0, 0, 0, 1, 0, 0, > 0, 1, 0, 1, 0, 4, 0, 2, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 1, 0, 0, 2, 0, 0, 0, 2, 2, 0, 1, 0, 0, 0, > 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, > 1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, > 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, > 0, 0, 0, 0, 2, 0, 0, 0, 0, 8, 0, 0, 0, 3, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, > 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 1, 0, > 0, 2, 0, 0, 0, 0, 2, 0, 0, 1, 3, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 4, 0, 0, 0, 0), > nr=50) > > fisher.test(d4) > ##- Error in fisher.test(alldata[, 2:5]) : FEXACT error 30. > ##- Stack length exceeded in f3xact. > ##- This problem should not occur. Just for the record: repeat try(fisher.test(d4)) results in a crash after a few iterations (R-1.5.0 patched on WinNT 4.0). Uwe Ligges ==> 1662.reply.1 <== From maechler@stat.math.ethz.ch Thu Jun 13 12:17:02 2002 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA19850 for ; Thu, 13 Jun 2002 12:17:01 +0200 (MET DST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id MAA05039; Thu, 13 Jun 2002 12:15:37 +0200 (MET DST) Received: from lynne(129.132.58.30), claiming to be "lynne.ethz.ch" via SMTP by hypatia, id smtpdAAAa001Eg; Thu Jun 13 12:15:28 2002 Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id g5DAFsK19920; Thu, 13 Jun 2002 12:15:54 +0200 X-Authentication-Warning: lynne.ethz.ch: maechler set sender to maechler@stat.math.ethz.ch using -f From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.28889.858685.234909@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 12:15:53 +0200 To: Prof Brian D Ripley Cc: R-bugs@stat.math.ethz.ch, R-core@stat.math.ethz.ch Subject: Re: bad fisher.test() bug (PR#1662) In-Reply-To: References: <15624.23861.930057.723845@gargle.gargle.HOWL> X-Mailer: VM 7.07 under Emacs 20.7.1 Reply-To: Martin Maechler (CC'ed to R-bugs ``for the record'') >>>>> "BDR" == Prof Brian D Ripley writes: BDR> On Thu, 13 Jun 2002, Martin Maechler wrote: >> >>>>> "MM" == Martin Maechler >> writes: >> >> >>>>> "BDR" == Brian D Ripley >> writes: BDR> Martin, What makes this a `bad bug'? Are you getting a BDR> seg fault? >> MM> yes, always in the half a dozen restarts I tried. >> (in the mean time I had one case where it did not ..) >> BDR> Like Uwe this works for me the first few times and I do BDR> then get a backtrace (in memory.c, so this is almost BDR> certainly an earlier overrun). >> MM> I see. This has been different for me. >> BDR> I think we've had problems before with FEXACT BDR> incorrectly specifying the required sizes of its BDR> workspaces. >> (I'm not so sure this is the problem here.) >> >> I found that >> >> fisher.test(d4[1:30,]) >> >> gives a direct segmentation fault (without any error >> message) for me. >> BDR> I've had to compile up gdb 5.2 to get the correct BDR> information out of R on Linux compiled under gcc-3.1. BDR> That shows (on the original problem) BDR> Loaded symbols for BDR> /users/ripley/R/R-patched/library/ctest/libs/ctest.so BDR> #0 f3xact (nrow=0x40051074, irow=0x4005113c, BDR> ncol=0x40051000, icol=0x40051120, dlp=0x4041b110, BDR> mm=0x40050fc0, fact=0x4035f020, ico=0x4035f4dc, BDR> iro=0x4035f5a4, it=0x4035f66c, lb=0x4035f734, BDR> nr=0x4035f7fc, nt=0x4035f8c4, nu=0x4035f98c, BDR> itc=0x4035fa54, ist=0x40360094, stv=0x40364f18, BDR> alen=0x40365ba0, tol=0x4004f878) at BDR> /users/ripley/R/cvs/R-patched/src/library/ctest/src/fexact.c:1125 BDR> 1125 ist[itp] = -1; (gdb) print itp $1 = -3544 BDR> The same with your variant (except the value of itp). Okay, I found a much smaller table --- and a different place for the seg.fault : > fisher.test(cbind(0,c(0,0,1))) Program received signal SIGSEGV, Segmentation fault. f2xact (nrow=0x8a12ec0, ncol=0x8a12ee0, table=0x8b7bb38, ldtabl=0x8a12f00, expect=0x89dad68, percnt=0x89dad90, emin=0x89dadb8, prt=0x89dade0, pre=0x89dae08, fact=0x403b3020, ico=0x403b302c, iro=0x403b3038, kyy=0x403b3044, idif=0x403b3050, irn=0x403b3058, key=0x403b49d4, ldkey=0xbfffc398, ipoin=0x403b5d44, stp=0x403b70b0, ldstp=0xbfffc39c, ifrq=0x403ffef4, dlp=0x4046d450, dsp=0x4046fb30, tm=0x40472210, key2=0x404748f4, iwk=0x403b3060, rwk=0x403b3d30) at ../../../../../R/src/library/ctest/src/fexact.c:524 524 obs += fact[ico[j]] - dd; Martin ==> 1662.followup.2 <== From ripley@stats.ox.ac.uk Thu Jun 13 13:16:27 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id NAA20855 for ; Thu, 13 Jun 2002 13:16:27 +0200 (MET DST) Received: from auk.stats (pc1-oxfd1-4-cust16.oxf.cable.ntl.com [62.254.131.16]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id MAA15227; Thu, 13 Jun 2002 12:15:44 +0100 (BST) Date: Thu, 13 Jun 2002 12:14:46 +0100 (BST) From: Prof Brian D Ripley Sender: ripley@auk.stats To: maechler@stat.math.ethz.ch cc: R-bugs@biostat.ku.dk, Subject: Re: fisher.test FEXACT memory bug "should not occur" (PR#1662) In-Reply-To: <200206130622.IAA16038@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This occurred because integer overflow was giving negative keys. Append the following line at line 1083 of fexact.c if (ipn < 1) ipn += ldst; /* because key might be negative */ > fisher.test(d4) Fisher's Exact Test for Count Data data: d4 p-value = < 2.2e-16 alternative hypothesis: two.sided On Thu, 13 Jun 2002 maechler@stat.math.ethz.ch wrote: > This is a bad bug as reported by Robin Hankin, > it is still in "R-patched" ... > > ##- From: Robin Hankin > ##- To: r-help@stat.math.ethz.ch > ##- Subject: [R] possum sleeping: thanks and fisher.test() FEXACT error > ##- Date: Thu, 13 Jun 2002 16:46:26 +1200 > > ## ..... > > ## Example slighlty modified (MM) > > d4 <- matrix(c(0, 0, 0, 0, 0, 0, 3, 0, 1, 0, 0, 0, 0, 0, 0, > 1, 0, 0, 0, 0, 1, 0, 0, 2, 0, 0, 0, 1, 0, 0, > 0, 1, 0, 1, 0, 4, 0, 2, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 1, 0, 0, 2, 0, 0, 0, 2, 2, 0, 1, 0, 0, 0, > 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, > 1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, > 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, > 0, 0, 0, 0, 2, 0, 0, 0, 0, 8, 0, 0, 0, 3, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, > 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 1, 0, > 0, 2, 0, 0, 0, 0, 2, 0, 0, 1, 3, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 4, 0, 0, 0, 0), > nr=50) > > fisher.test(d4) > ##- Error in fisher.test(alldata[, 2:5]) : FEXACT error 30. > ##- Stack length exceeded in f3xact. > ##- This problem should not occur. > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1662.followup.3 <== From ripley@stats.ox.ac.uk Thu Jun 13 17:57:14 2002 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id RAA24468 for ; Thu, 13 Jun 2002 17:57:14 +0200 (MET DST) From: ripley@stats.ox.ac.uk Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id RAA20365; Thu, 13 Jun 2002 17:56:07 +0200 (MET DST) Received: from toucan.stats.ox.ac.uk(163.1.20.20) via SMTP by hypatia, id smtpdAAAa004wF; Thu Jun 13 17:55:59 2002 Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id QAA16075; Thu, 13 Jun 2002 16:56:21 +0100 (BST) Date: Thu, 13 Jun 2002 16:56:20 +0100 (BST) X-X-Sender: To: Martin Maechler cc: Subject: Re: bad fisher.test() bug (PR#1662) In-Reply-To: <15624.28889.858685.234909@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 13 Jun 2002, Martin Maechler wrote: > Okay, I found a much smaller table --- and a different place > for the seg.fault : > > fisher.test(cbind(0,c(0,0,1))) That one is easy: You (MM) have calculated fact[2], but fact is only of length 2 (for values 0 and 1), so ico gets overwritten. I now suspect that my fix for the original bug is merely a fix for a symptom, so am going to replace it by an error message. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1662.audit <== Thu Jun 13 19:15:42 2002 ripley changed notes Thu Jun 13 19:15:42 2002 ripley foobar Thu Jun 13 19:15:42 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1729 * Subject: problem with qq( ) From: Jarno.Tuimala@Helsinki.Fi Date: Tue, 2 Jul 2002 10:37:10 +0200 (MET DST) --A report on lattice ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1729 <== From Jarno.Tuimala@Helsinki.Fi Tue Jul 2 10:37:11 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA28248 for ; Tue, 2 Jul 2002 10:37:10 +0200 (MET DST) Date: Tue, 2 Jul 2002 10:37:10 +0200 (MET DST) From: Jarno.Tuimala@Helsinki.Fi Message-Id: <200207020837.KAA28248@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: problem with qq( ) Full_Name: Jarno Tuimala Version: 1.5.0 OS: Windows Nt Submission from: (NULL) (193.166.1.21) Running the following analysis gives as a result kukot vs. kisut. aikaero <- -27.5+5*(0:10) frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) win.graph() aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) a.ero <- data.frame(aikaero, sukupuoli=rep(c("kukot","kisut"), c(sum(frekvenssi.m),sum(frekvenssi.n)))) qq(sukupuoli ~ aikaero, data=a.ero) However, running the following analysis, gives miehet vs. miehet. aikaero <- -27.5+5*(0:10) frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) win.graph() aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) a.ero <- data.frame(aikaero, sukupuoli=rep(c("miehet","naiset"), c(sum(frekvenssi.m),sum(frekvenssi.n)))) qq(sukupuoli ~ aikaero, data=a.ero) This seems to happen everytime "sukupuoli" contains one variable name, which starts with a letter "n". If both names start with "n" or other letters the results is miehet vs naiset as expected. So this works fine: a.ero <- data.frame(aikaero, sukupuoli=rep(c("nisset","naiset"), c(sum(frekvenssi.m),sum(frekvenssi.n)))) qq(sukupuoli ~ aikaero, data=a.ero) And this also: a.ero <- data.frame(aikaero, sukupuoli=rep(c("miehet","maiset"), c(sum(frekvenssi.m),sum(frekvenssi.n)))) qq(sukupuoli ~ aikaero, data=a.ero) Where's the problem? ==> 1729.followup.1 <== From ripley@stats.ox.ac.uk Tue Jul 2 11:19:02 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA28796 for ; Tue, 2 Jul 2002 11:19:02 +0200 (MET DST) From: ripley@stats.ox.ac.uk Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id KAA21799; Tue, 2 Jul 2002 10:18:19 +0100 (BST) Date: Tue, 2 Jul 2002 10:18:18 +0100 (BST) X-X-Sender: To: cc: , Subject: Re: problem with qq( ) (PR#1729) In-Reply-To: <200207020837.KAA28253@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 1) This is a report on the lattice package, and we both need you to mention that and to give the version number of lattice that you used to be sure of beeing able to reproduce this. 2) It seems that the plots are actually correct, just the labels are wrong. You can correct that by specifying xlab and ylab in the call. 3) The error appears to be a typo: if (missing(ylab)) ylab <- if (is.f.y) unique(levels(y))[y] else paste("y:", as.character(unique(levels(y)[[2]]))) should be [2] for consistency. On Tue, 2 Jul 2002 Jarno.Tuimala@Helsinki.Fi wrote: > Full_Name: Jarno Tuimala > Version: 1.5.0 > OS: Windows Nt > Submission from: (NULL) (193.166.1.21) > > > Running the following analysis gives as a result kukot vs. kisut. > > aikaero <- -27.5+5*(0:10) > frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) > frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) > win.graph() > aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) > a.ero <- data.frame(aikaero, > sukupuoli=rep(c("kukot","kisut"), > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > qq(sukupuoli ~ aikaero, data=a.ero) > > However, running the following analysis, gives miehet vs. miehet. > > aikaero <- -27.5+5*(0:10) > frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) > frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) > win.graph() > aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) > a.ero <- data.frame(aikaero, > sukupuoli=rep(c("miehet","naiset"), > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > qq(sukupuoli ~ aikaero, data=a.ero) > > This seems to happen everytime "sukupuoli" contains one variable name, which > starts with a letter "n". If both names start with "n" or other letters the > results is miehet vs naiset as expected. > > So this works fine: > > a.ero <- data.frame(aikaero, > sukupuoli=rep(c("nisset","naiset"), > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > qq(sukupuoli ~ aikaero, data=a.ero) > > And this also: > > a.ero <- data.frame(aikaero, > sukupuoli=rep(c("miehet","maiset"), > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > qq(sukupuoli ~ aikaero, data=a.ero) > > Where's the problem? > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1729.followup.2 <== From deepayansarkar@yahoo.com Mon Jul 8 19:44:52 2002 Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28]) by pubhealth.ku.dk (8.9.3/8.9.1) with SMTP id TAA03638 for ; Mon, 8 Jul 2002 19:44:51 +0200 (MET DST) Message-ID: <20020708174408.63945.qmail@web13902.mail.yahoo.com> Received: from [202.54.53.232] by web13902.mail.yahoo.com via HTTP; Mon, 08 Jul 2002 10:44:08 PDT Date: Mon, 8 Jul 2002 10:44:08 -0700 (PDT) From: Deepayan Sarkar Subject: Re: problem with qq( ) (PR#1729) To: R-bugs@biostat.ku.dk In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- ripley@stats.ox.ac.uk wrote: > 1) This is a report on the lattice package, and we both need you to > mention that and to give the version number of lattice that you used > to be sure of beeing able to reproduce this. > > 2) It seems that the plots are actually correct, just the labels are > wrong. You can correct that by specifying xlab and ylab in the call. > > 3) The error appears to be a typo: > > if (missing(ylab)) > ylab <- if (is.f.y) > unique(levels(y))[y] > else paste("y:", as.character(unique(levels(y)[[2]]))) > > should be [2] for consistency. Thanks, fixed for future releases. > On Tue, 2 Jul 2002 Jarno.Tuimala@Helsinki.Fi wrote: > > > Full_Name: Jarno Tuimala > > Version: 1.5.0 > > OS: Windows Nt > > Submission from: (NULL) (193.166.1.21) > > > > > > Running the following analysis gives as a result kukot vs. kisut. > > > > aikaero <- -27.5+5*(0:10) > > frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) > > frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) > > win.graph() > > aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) > > a.ero <- data.frame(aikaero, > > sukupuoli=rep(c("kukot","kisut"), > > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > > qq(sukupuoli ~ aikaero, data=a.ero) > > > > However, running the following analysis, gives miehet vs. miehet. > > > > aikaero <- -27.5+5*(0:10) > > frekvenssi.m <- c(0,1,15,37,53,45,23,18,4,1,1) > > frekvenssi.n <- c(2,8,12,19,33,47,42,15,2,1,0) > > win.graph() > > aikaero <- rep(c(aikaero,aikaero), c(frekvenssi.m,frekvenssi.n)) > > a.ero <- data.frame(aikaero, > > sukupuoli=rep(c("miehet","naiset"), > > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > > qq(sukupuoli ~ aikaero, data=a.ero) > > > > This seems to happen everytime "sukupuoli" contains one variable name, > which > > starts with a letter "n". If both names start with "n" or other letters the > > results is miehet vs naiset as expected. > > > > So this works fine: > > > > a.ero <- data.frame(aikaero, > > sukupuoli=rep(c("nisset","naiset"), > > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > > qq(sukupuoli ~ aikaero, data=a.ero) > > > > And this also: > > > > a.ero <- data.frame(aikaero, > > sukupuoli=rep(c("miehet","maiset"), > > c(sum(frekvenssi.m),sum(frekvenssi.n)))) > > qq(sukupuoli ~ aikaero, data=a.ero) > > > > Where's the problem? > > > > > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > > r-devel mailing list -- Read > http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > > Send "info", "help", or "[un]subscribe" > > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > > > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > > > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > 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 272860 (secr) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ==> 1729.audit <== Tue Jul 2 21:14:42 2002 ripley moved from incoming to Add-ons Sun Aug 25 11:58:22 2002 ripley changed notes Sun Aug 25 11:58:22 2002 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1972 * Subject: lattice install From: robert.king@newcastle.edu.au Date: Mon, 2 Sep 2002 04:55:41 +0200 (MET DST) --Perhaps lattice should require(grid) and print a clearer message? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1972 <== From robert.king@newcastle.edu.au Mon Sep 2 04:55:43 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id EAA26744 for ; Mon, 2 Sep 2002 04:55:41 +0200 (MET DST) Date: Mon, 2 Sep 2002 04:55:41 +0200 (MET DST) From: robert.king@newcastle.edu.au Message-Id: <200209020255.EAA26744@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: lattice install Full_Name: Robert King Version: 1.3 OS: windows Submission from: (NULL) (134.148.4.19) This looks like a problem with package dependencies. Should be sending this to the package author, not r-bugs? An attempt to install lattice from the windows binary runs OK, but attempting to load the library an error occurs: > install.packages("D:/Software/R/lattice.zip", .lib.loc[1], CRAN = NULL) updating HTML package descriptions > library(lattice) Error in parse(file, n, text, prompt) : syntax error on line 2022 I then tried installing under linux with R 1.5.1 This installed OK, but loading the library gave another error: > library(lattice) Error in library(grid) : There is no package called `grid' Installing grid on linux resulted in lattice loading and working properly Installing grid also fixed the problem on windows. ==> 1972.audit <== Tue Sep 3 19:47:36 2002 thomas changed notes Tue Sep 3 19:47:36 2002 thomas foobar Tue Sep 3 19:47:36 2002 thomas moved from incoming to Graphics Wed Jan 8 11:27:36 2003 ripley foobar Wed Jan 8 11:27:36 2003 ripley moved from Graphics to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1974 * Subject: Rwave installation problem From: ld-temp-qt3i@pobox.com Date: Mon, 2 Sep 2002 09:27:36 +0200 (MET DST) --Instead, this should use ISO C headers, namely ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1974 <== From ld-temp-qt3i@pobox.com Mon Sep 2 09:27:37 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id JAA27886 for ; Mon, 2 Sep 2002 09:27:36 +0200 (MET DST) Date: Mon, 2 Sep 2002 09:27:36 +0200 (MET DST) From: ld-temp-qt3i@pobox.com Message-Id: <200209020727.JAA27886@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Rwave installation problem Full_Name: Linc Davis Version: 1.5.1 OS: Mac OS 10.1.5 Submission from: (NULL) (68.4.90.94) When running install.packages("Rwave") as root, I got this error: In file included from compinteg.c:12: kernel.h:22: malloc.h: No such file or directory make: *** [compinteg.o] Error 1 ERROR: compilation failed for package 'Rwave' There are 3 header files 'malloc.h' in Mac OS X: one for generic C, one for Objective-C, and a private one for the OS. The R installation script looks for C headers in /usr/include, but the actual path to this one is /usr/include/sys/malloc.h I worked around the problem by copying the file as indicated, then I deleted the copy after compiling the package. To fix the bug, the script should be changed to look for C headers in both /usr/include and /usr/include/sys. Thanks. ==> 1974.audit <== Tue Sep 17 11:20:29 2002 maechler foobar Tue Sep 17 11:20:29 2002 maechler moved from incoming to Add-ons Wed Nov 20 16:44:15 2002 ripley changed notes Wed Nov 20 16:44:15 2002 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2173 * Subject: xlim in plot.survfit() [with a discussion on "..."] From: jerome@hivnet.ubc.ca Date: Wed, 16 Oct 2002 18:46:11 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2173 <== From jerome@hivnet.ubc.ca Wed Oct 16 18:46:12 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA00603 for ; Wed, 16 Oct 2002 18:46:11 +0200 (MET DST) Date: Wed, 16 Oct 2002 18:46:11 +0200 (MET DST) From: jerome@hivnet.ubc.ca Message-Id: <200210161646.SAA00603@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: xlim in plot.survfit() [with a discussion on "..."] Full_Name: Jerome Asselin Version: 1.6.0 OS: RedHat 7.2 Submission from: (NULL) (24.83.203.63) Hello, I am trying to draw a legend on top of survival curves using plot.survfit(). As in the example below, I would like to specify a large interval for the x-axis. I can achieve such result using "xlim". However, an error occurs if I use the legend.pos and legend.text parameters as well. library(survival) TIME <- Surv(c(23,52,12,56,23,21),c(T,F,T,F,F,T)) par(mfrow=c(2,1)) plot(survfit(TIME~1),conf.int=F,xlim=c(0,100), main="xlim=c(0,100) without legend") plot(survfit(TIME~1),conf.int=F,xlim=c(0,100), legend.pos=0,legend.text="Survival Curve", main="xlim=c(0,100) with legend (ERROR!)") It looks like plot.survfit() attempts to send the "xlim" parameter to legend(), which does not accept "xlim" as a parameter. Hence, an error occurs and the legend is not plotted. I believe the problem is due to the fact that the additional parameters "..." that are supplied to plot.survfit() do not necessarily match the range of possible parameters for both plot() and legend(). In my case, "xlim" is matched by plot(), but not by legend(). I know how to plot the legend by directly using the legend() function. However, in order to correct the small problem with plot.survfit(), I would suggest that plot.survfit() be modified to perform an exact match of the parameters in "..." onto legend(). Perhaps there is already a function to perform such a task. If not, I believe it could provide a practical solution for dealing with "..." and subfunctions that do not have a built-in "..." parameter. That's just a suggestion, though. Thank you very much! Jerome Asselin ==> 2173.audit <== Wed Oct 16 22:58:03 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2322 * Subject: simplex From: george@lecompte.org Date: Sat, 23 Nov 2002 17:30:37 +0100 (MET) --report on boot, I think (not mentioned, though) ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2322 <== From george@lecompte.org Sat Nov 23 17:30:38 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id RAA16415 for ; Sat, 23 Nov 2002 17:30:37 +0100 (MET) Date: Sat, 23 Nov 2002 17:30:37 +0100 (MET) From: george@lecompte.org Message-Id: <200211231630.RAA16415@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: simplex Full_Name: George LeCompte Version: 1.6.1 (windows) OS: windows98 Submission from: (NULL) (208.8.162.135) simplex won't work with only >= constraints examples follow: this works: simplex(a=1,A1=1,b1=10,A2=1,b2=1) but this doesn't simplex(1,A2=1,b2=1) Linear Programming Results Call : simplex(a = 1, A2 = 1, b2 = 1) Minimization Problem with Objective Function Coefficients x1 1 No feasible solution could be found ==> 2322.audit <== Tue Nov 26 21:45:55 2002 ripley changed notes Tue Nov 26 21:45:55 2002 ripley foobar Tue Nov 26 21:45:55 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2352 * Subject: avas: segmentation fault on empty args From: vograno@arbitrade.com Date: Fri, 6 Dec 2002 19:41:48 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2352 <== From vograno@arbitrade.com Fri Dec 6 19:41:49 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA11396 for ; Fri, 6 Dec 2002 19:41:48 +0100 (MET) Date: Fri, 6 Dec 2002 19:41:48 +0100 (MET) From: vograno@arbitrade.com Message-Id: <200212061841.TAA11396@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: avas: segmentation fault on empty args Full_Name: Vadim Ogranovich Version: 1.6.0 OS: Red Hat 7.1 Submission from: (NULL) (209.99.241.1) Segmentation fault occurs when empty vectors passed to avas as arguments. > library("acepack") library("acepack") > avas(numeric(0),numeric(0)) avas(numeric(0),numeric(0)) Process R segmentation fault at Fri Dec 6 10:31:06 2002 ==> 2352.audit <== Sat Dec 7 09:32:42 2002 ripley foobar Sat Dec 7 09:32:42 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2369 * Subject: convergence problem with nlme() From: jerome@hivnet.ubc.ca Date: Thu, 12 Dec 2002 23:43:14 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2369 <== From jerome@hivnet.ubc.ca Thu Dec 12 23:43:15 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA27889 for ; Thu, 12 Dec 2002 23:43:14 +0100 (MET) Date: Thu, 12 Dec 2002 23:43:14 +0100 (MET) From: jerome@hivnet.ubc.ca Message-Id: <200212122243.XAA27889@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: convergence problem with nlme() Full_Name: Jerome Asselin Version: 1.6.1 OS: linux redhat 7.2 Submission from: (NULL) (142.103.173.179) I am using the nlme package version 3.1-33. I tried an example from the file "library/nlme/scripts/ch08.R" that comes with the nlme package but I did not obtain convergence. I assume that this example worked at some point in the past, but I cannot determine why it is not working anymore. So I am unable to determine whether this is a numerical bug or a documentation bug (in the file "ch08.R"). More specifically, I tried the example below (in which I added the option msVerbose=T.) library(nlme) data(Quinidine) control <- nlmeControl(msVerbose = T) fm1Quin.nlme <- nlme(conc ~ quinModel(Subject, time, conc, dose, interval, lV, lKa, lCl), data = Quinidine, fixed = lV + lKa + lCl ~ 1, random = pdDiag(lV + lCl ~ 1), groups = ~ Subject, start = list(fixed = c(5, -0.3, 2)), na.action = NULL, naPattern = ~ !is.na(conc), control = control) #Error in nlme.formula(conc ~ quinModel(Subject, time, conc, dose, interval, : # Maximum number of iterations reached without convergence Below is the trace of the calculations by nlme(). iteration = 0 Step: [1] 0 0 Parameter: [1] 0.9645714 1.2393630 Function Value [1] 1053.026 Gradient: [1] -5.1732725 -0.3194242 iteration = 10 Parameter: [1] 5.492493 1.275746 Function Value [1] 1050.678 Gradient: [1] -0.0004125939 0.0012034419 Iteration limit exceeded. Algorithm failed. iteration = 0 Step: [1] 0 0 Parameter: [1] 5.492303 0.860876 Function Value [1] 1047.32 Gradient: [1] 8.080429e-04 -8.308982e-06 iteration = 6 Parameter: [1] -1772.4732661 0.3624312 Function Value [1] 815.6329 Gradient: [1] 9.726484e-25 -2.590048e-08 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.7142093 0.8328863 Function Value [1] 1045.966 Gradient: [1] -2.701254 1.837528 iteration = 6 Parameter: [1] 1.1387817 0.8237138 Function Value [1] 1045.492 Gradient: [1] -3.297258e-08 4.558449e-08 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2190786 0.8233033 Function Value [1] 1044.609 Gradient: [1] 2.589381 -2.443006 iteration = 7 Parameter: [1] 0.6880674 0.8342263 Function Value [1] 1043.658 Gradient: [1] -5.457107e-08 -1.710382e-06 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6867763 0.8348800 Function Value [1] 1045.262 Gradient: [1] -3.318076 2.320207 iteration = 7 Parameter: [1] 1.2547275 0.8239144 Function Value [1] 1044.541 Gradient: [1] 1.496284e-08 -6.761539e-21 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2661227 0.8244986 Function Value [1] 1044.441 Gradient: [1] 2.642391 -2.502298 iteration = 1 Parameter: [1] -1509.6490716 0.8231054 Function Value [1] 826.5788 Gradient: [1] 5.044484e-19 3.488575e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6851074 0.8350764 Function Value [1] 1045.189 Gradient: [1] -3.359032 2.357977 iteration = 7 Parameter: [1] 1.2648770 0.8239819 Function Value [1] 1044.448 Gradient: [1] -1.484278e-08 -4.556966e-08 Last global step failed to locate a point lower than x. Either x is an approximate local minimum of the function, the function is too non-linear for this algorithm, or steptol is too large. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2679928 0.8245302 Function Value [1] 1044.427 Gradient: [1] 2.646834 -2.508039 iteration = 1 Parameter: [1] -1511.23183 0.82312 Function Value [1] 826.1627 Gradient: [1] 1.373859e-18 3.405617e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6849866 0.8350863 Function Value [1] 1045.184 Gradient: [1] -3.361700 2.360219 iteration = 7 Parameter: [1] 1.2654792 0.8239847 Function Value [1] 1044.442 Gradient: [1] -1.483571e-08 -2.278475e-08 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.268088 0.824533 Function Value [1] 1044.426 Gradient: [1] 2.647101 -2.508261 iteration = 1 Parameter: [1] -1511.3133956 0.8231232 Function Value [1] 827.7616 Gradient: [1] 1.046018e-18 3.410108e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6850998 0.8350804 Function Value [1] 1045.188 Gradient: [1] -3.359382 2.358456 iteration = 7 Parameter: [1] 1.2650078 0.8239839 Function Value [1] 1044.447 Gradient: [1] -1.484124e-08 2.278477e-08 Last global step failed to locate a point lower than x. Either x is an approximate local minimum of the function, the function is too non-linear for this algorithm, or steptol is too large. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2680136 0.8245307 Function Value [1] 1044.426 Gradient: [1] 2.646877 -2.508084 iteration = 1 Parameter: [1] -1511.2495885 0.8231376 Function Value [1] 827.6179 Gradient: [1] 1.473509e-19 3.477226e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6851144 0.8350799 Function Value [1] 1045.188 Gradient: [1] -3.359088 2.358286 iteration = 6 Parameter: [1] 1.2649473 0.8239835 Function Value [1] 1044.448 Gradient: [1] 2.968390e-08 -6.835435e-08 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.267994 0.824532 Function Value [1] 1044.427 Gradient: [1] 2.646853 -2.507863 iteration = 1 Parameter: [1] -1511.2336349 0.8231352 Function Value [1] 828.0258 Gradient: [1] -6.701743e-20 3.365341e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6851079 0.8350803 Function Value [1] 1045.188 Gradient: [1] -3.359215 2.358392 iteration = 7 Parameter: [1] 1.2649721 0.8239836 Function Value [1] 1044.447 Gradient: [1] 1.484166e-08 4.556957e-08 Last global step failed to locate a point lower than x. Either x is an approximate local minimum of the function, the function is too non-linear for this algorithm, or steptol is too large. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.268001 0.824530 Function Value [1] 1044.427 Gradient: [1] 2.646867 -2.508106 iteration = 1 Parameter: [1] -1511.2385145 0.8231441 Function Value [1] 825.0983 Gradient: [1] -9.146131e-19 3.823514e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6849865 0.8350865 Function Value [1] 1045.184 Gradient: [1] -3.361722 2.360234 iteration = 6 Parameter: [1] 1.265490 0.823985 Function Value [1] 1044.442 Gradient: [1] -1.254955e-20 -6.835423e-08 Successive iterates within tolerance. Current iterate is probably solution. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2681041 0.8245325 Function Value [1] 1044.426 Gradient: [1] 2.647101 -2.508336 iteration = 1 Parameter: [1] -1511.3262872 0.8231335 Function Value [1] 828.0964 Gradient: [1] 2.680533e-19 3.401084e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6850990 0.8350805 Function Value [1] 1045.188 Gradient: [1] -3.359395 2.358484 iteration = 7 Parameter: [1] 1.2650090 0.8239838 Function Value [1] 1044.447 Gradient: [1] -4.452368e-08 -2.278478e-08 Last global step failed to locate a point lower than x. Either x is an approximate local minimum of the function, the function is too non-linear for this algorithm, or steptol is too large. iteration = 0 Step: [1] 0 0 Parameter: [1] 1.2680059 0.8245313 Function Value [1] 1044.426 Gradient: [1] 2.646886 -2.508011 iteration = 1 Parameter: [1] -1511.24342 0.82312 Function Value [1] 827.5457 Gradient: [1] -1.234659e-18 3.430500e+01 Maximum step size exceeded 5 consecutive times. Either the function is unbounded below, becomes asymptotic to a finite value from above in some direction, or stepmx is too small. iteration = 0 Step: [1] 0 0 Parameter: [1] 0.6851253 0.8350791 ==> 2369.reply.1 <== From bates@bates5.stat.wisc.edu Fri Dec 13 00:13:06 2002 Received: from bates5.stat.wisc.edu (mail@bates5.stat.wisc.edu [128.105.174.135]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id AAA28071 for ; Fri, 13 Dec 2002 00:13:06 +0100 (MET) Received: from bates by bates5.stat.wisc.edu with local (Exim 3.36 #1 (Debian)) id 18McV4-0002vX-00; Thu, 12 Dec 2002 17:12:14 -0600 To: jerome@hivnet.ubc.ca Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] convergence problem with nlme() (PR#2369) References: <200212122243.XAA27894@pubhealth.ku.dk> From: Douglas Bates Date: 12 Dec 2002 17:12:14 -0600 In-Reply-To: <200212122243.XAA27894@pubhealth.ku.dk> Message-ID: <6radjade7l.fsf@bates5.stat.wisc.edu> Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Douglas Bates It turns out that you learn more if you set verbose = TRUE in the call to nlme rather than setting control = nlmeControl(msVerbose = TRUE). The verbose = TRUE option shows you that the parameter values are bouncing back and forth between two regions of the parameter space, neither of which are close to the optimum. It happens that nlm will occasionally take very large steps at the beginning of the optimization resulting in unusual parameter values. This example is a difficult optimization problem. It may be possible to stabilize it somewhat by replacing the internal calls to nlm by calls to optim but that brings its own set of difficulties. ==> 2369.audit <== Sun Dec 15 08:53:57 2002 ripley foobar Sun Dec 15 08:53:57 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2374 * Subject: quantreg package - predict method for rq objects From: John Maindonald Date: Sat, 14 Dec 2002 20:46:34 +1100 (EST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2374 <== From mailnull@stat.math.ethz.ch Sat Dec 14 10:47:34 2002 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA08577 for ; Sat, 14 Dec 2002 10:47:33 +0100 (MET) Received: from hypatia.math.ethz.ch (mailnull@localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.6/8.12.6) with ESMTP id gBE9khgo024271 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Dec 2002 10:46:44 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.6/8.12.6/Submit) id gBE9khMO024270 for R-bugs@biostat.ku.dk; Sat, 14 Dec 2002 10:46:43 +0100 (MET) Received: from franz.stat.wisc.edu (mail@www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.6/8.12.6) with ESMTP id gBE9kcgn024245 for ; Sat, 14 Dec 2002 10:46:40 +0100 (MET) Received: from anumail4.anu.edu.au ([150.203.2.44] helo=anu.edu.au) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 18N8sY-0008MD-00 for ; Sat, 14 Dec 2002 03:46:38 -0600 Received: from leonard.anu.edu.au (leonard.anu.edu.au [150.203.2.15]) by anu.edu.au (8.12.4/8.12.4) with ESMTP id gBE9kZBo015610 for ; Sat, 14 Dec 2002 20:46:35 +1100 (EST) Received: (from u9801539@localhost) by leonard.anu.edu.au (8.11.6/8.11.6) id gBE9kYl17197 for r-bugs@r-project.org; Sat, 14 Dec 2002 20:46:34 +1100 (EST) Date: Sat, 14 Dec 2002 20:46:34 +1100 (EST) From: John Maindonald Message-Id: <200212140946.gBE9kYl17197@leonard.anu.edu.au> To: r-bugs@r-project.org Subject: quantreg package - predict method for rq objects X-Sender: u9801539@leonard.anu.edu.au X-Sender-Domain: leonard.anu.edu.au X-Spam-Score: (0.4) X-Spam-Tests: FROM_ENDS_IN_NUMS X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=1.7 required=5.0 tests=FROM_ENDS_IN_NUMS,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * In help(rq.object), under Methods, it says: " The `"rq"' class of objects has methods for the following generic functions: `coef', `effects' , `formula' , `labels' , `model.frame' , `model.matrix' , `plot' , `predict' , `print' , `print.summary' , `residuals' , `summary' " There seems to be no predict method: > y <- rnorm(500) > u <- rq(y ~ 1, tau=.75) Warning message: Solution may be nonunique in: rq.fit.br(x, y, tau = tau, ...) > predict(u) Error in predict(u) : no applicable method for "predict" [I have looked both at the Windows and at the Darwin/X11 versions.] John Maindonald email : john.maindonald@anu.edu.au Centre for Bioinformation Science, phone : (6125)3473 c/o MSI, fax : (6125)5549 John Dedman Mathematical Sciences Building (Building 27) Australian National University Canberra ACT 0200 Australia ==> 2374.audit <== Sun Dec 15 08:53:15 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2386 * Subject: ace and avas in acepack From: Frank E Harrell Jr Date: Fri, 20 Dec 2002 12:59:07 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2386 <== From fharrell@virginia.edu Fri Dec 20 18:59:26 2002 Received: from cgatepro-2.mail.virginia.edu (neon.mail.Virginia.EDU [128.143.2.220]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA06856 for ; Fri, 20 Dec 2002 18:59:26 +0100 (MET) Received: from [128.143.108.90] (HELO fharrell.biostat) by cgatepro-2.mail.virginia.edu (CommuniGate Pro SMTP 3.5.9) with SMTP id 29368136; Fri, 20 Dec 2002 12:58:38 -0500 Date: Fri, 20 Dec 2002 12:59:07 -0500 From: Frank E Harrell Jr To: r-bugs@biostat.ku.dk Cc: Thomas Lumley Subject: ace and avas in acepack Message-Id: <20021220125907.57c1ad10.fharrell@virginia.edu> Organization: University of Virginia X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Under platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 1 minor 6.1 year 2002 month 11 day 01 language R and using acepack 1.3-2, ace() and avas() have checks such as if(circ[i] < 0 || circ[i] > nrow(x)) { if(mon[i] < 0 || mon[i] > nrow(x)) { if(lin[i] < 0 || lin[i] > nrow(x)) { etc. I believe that nrow should be ncol. Also, in ace() there is the follwing check: if (cat[i] == 0) { cat("response spec can only be lin or ordered (default)") return() } whereas I believe that the ace algorithm does allow for categorical response variables. -- Frank E Harrell Jr Prof. of Biostatistics & Statistics Div. of Biostatistics & Epidem. Dept. of Health Evaluation Sciences U. Virginia School of Medicine http://hesweb1.med.virginia.edu/biostat ==> 2386.audit <== Fri Dec 27 09:19:24 2002 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2480 * Subject: bug in CrossTable (package:gregmisc) From: John_Hendrickx@yahoo.com Date: Tue, 21 Jan 2003 13:51:01 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2480 <== From John_Hendrickx@yahoo.com Tue Jan 21 13:51:02 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id NAA17686 for ; Tue, 21 Jan 2003 13:51:01 +0100 (MET) Date: Tue, 21 Jan 2003 13:51:01 +0100 (MET) From: John_Hendrickx@yahoo.com Message-Id: <200301211251.NAA17686@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: bug in CrossTable (package:gregmisc) Full_Name: John Hendrickx Version: 1.6.0 OS: Windows 98 Submission from: (NULL) (137.224.174.216) CrossTable in the "gregmisc" package fails when the fisher.exact test produces an error (I suspect this is because the number of cases is too large). This can be fixed using "FTt <- try(fisher.test(t, alternative = "two.sided"))" or by making the test optional. bugtab <- array(c( 24, 31, 2, 50, 4, 101, 16, 130, 0, 29, 3, 52, 3, 39, 11, 210)) dim(bugtab)<-c(4,4) bugtab<-t(bugtab) rownames(bugtab)<-c("a","b","c","d") colnames(bugtab)<-c("A","B","C","D") bugtab thisworks<-trunc(bugtab/10) thisworks library(gregmisc) # fisher.exact test works fine on small tables CrossTable(thisworks) # I suspect the bugtab table is too large CrossTable(bugtab) ==> 2480.audit <== Tue Jan 21 14:39:22 2003 ripley moved from incoming to Add-ons ==> 2480.followup.1 <== From mschwartz@medanalytics.com Wed Jan 22 05:23:39 2003 Received: from mail12.atl.registeredsite.com (nobody@mail12.atl.registeredsite.com [64.224.219.86]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id FAA22283 for ; Wed, 22 Jan 2003 05:23:38 +0100 (MET) Received: from mail.medanalytics.com (mail.medanalytics.com [64.225.164.192]) by mail12.atl.registeredsite.com (8.12.2/8.12.6) with ESMTP id h0M4Mn0s024550; Tue, 21 Jan 2003 23:22:49 -0500 Received: from MARC [64.225.164.192] by mail.medanalytics.com with ESMTP (SMTPD32-6.06) id AC96524D00F2; Tue, 21 Jan 2003 23:22:46 -0500 Reply-To: From: "Marc Schwartz" To: , Cc: Subject: RE: [Rd] bug in CrossTable (package:gregmisc) (PR#2480) Date: Tue, 21 Jan 2003 22:22:45 -0600 Organization: MedAnalytics, Inc. Message-ID: <009801c2c1cd$eaebe5e0$0201a8c0@MARC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <200301211251.NAA17691@pubhealth.ku.dk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id FAA22283 > -----Original Message----- > From: r-devel-admin@stat.math.ethz.ch > [mailto:r-devel-admin@stat.math.ethz.ch] On Behalf Of > John_Hendrickx@yahoo.com > Sent: Tuesday, January 21, 2003 6:51 AM > To: r-devel@stat.math.ethz.ch > Cc: R-bugs@biostat.ku.dk > Subject: [Rd] bug in CrossTable (package:gregmisc) (PR#2480) > > > Full_Name: John Hendrickx > Version: 1.6.0 > OS: Windows 98 > Submission from: (NULL) (137.224.174.216) > > > CrossTable in the "gregmisc" package fails when the > fisher.exact test produces an error (I suspect this is > because the number of cases is too large). This can be fixed > using "FTt <- try(fisher.test(t, alternative = "two.sided"))" > or by making the test optional. > > bugtab <- array(c( > 24, 31, 2, 50, > 4, 101, 16, 130, > 0, 29, 3, 52, > 3, 39, 11, 210)) > dim(bugtab)<-c(4,4) > bugtab<-t(bugtab) > rownames(bugtab)<-c("a","b","c","d") > colnames(bugtab)<-c("A","B","C","D") > bugtab > > thisworks<-trunc(bugtab/10) > thisworks > > library(gregmisc) > # fisher.exact test works fine on small tables > CrossTable(thisworks) > # I suspect the bugtab table is too large > CrossTable(bugtab) John, Thank you for bringing this to my attention. I was out of town all day on a business trip and will look at this issue further with fresh eyes in the morning. I'll get an update to Greg as soon as I have a chance to incorporate a fix. I also have some pending updates for barplot2(), so I will coordinate the updates with Greg to conserve his time. Best regards, Marc Schwartz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2499 * Subject: survival bug? From: Pius Korner Date: Mon, 27 Jan 2003 17:28:11 +0100 --Needs to resubmit in more useful format. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2499 <== From korner@eco.umnw.ethz.ch Mon Jan 27 17:28:27 2003 Received: from xsmtp.ethz.ch (xsmtp.ethz.ch [129.132.97.6]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id RAA07671 for ; Mon, 27 Jan 2003 17:28:26 +0100 (MET) Received: from xfe2.d.ethz.ch ([192.168.36.11]) by xsmtp.ethz.ch with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Jan 2003 17:27:39 +0100 Received: from eco.umnw.ethz.ch ([129.132.15.199]) by xfe2.d.ethz.ch with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Jan 2003 17:27:38 +0100 Date: Mon, 27 Jan 2003 17:28:11 +0100 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: multipart/mixed; boundary=Apple-Mail-27-953181986 Subject: survival bug? From: Pius Korner To: r-bugs@biostat.ku.dk Message-Id: <5397D74A-3214-11D7-912D-000A27D7DD96@eco.umnw.ethz.ch> X-Mailer: Apple Mail (2.548) X-OriginalArrivalTime: 27 Jan 2003 16:27:38.0955 (UTC) FILETIME=[01FFB1B0:01C2C621] --Apple-Mail-27-953181986 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed a possible bug with survival analysis - either in R or in SPSS... find more details in bug.doc, and the data in bug.txt best Pius Korner --Apple-Mail-27-953181986 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-28-953181987 --Apple-Mail-28-953181987 Content-Disposition: attachment; filename=bug.doc Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="bug.doc" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAAcAAAACAAAA TwAAAR5XOEJOTVNXRAAAYnVnLmRvYwAAAQAAAAEAAAAAAAAAAB4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAB AAAAAAAAAAAeAAAAAAAAAAAAHAAe//8= --Apple-Mail-28-953181987 Content-Disposition: attachment; filename=bug.doc Content-Transfer-Encoding: base64 Content-Type: application/msword; x-mac-creator=4D535744; x-unix-mode=0644; x-mac-type=5738424E; name="bug.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAsUAJBAAA8BK/AAAAAAABEQABAAEABgAAUwkAAA4AamJqYpgKmAoAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhYAAPJoAQDyaAEAUwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKIAAAAAAAAAogAAAKIA AAAAAAAAogAAAAAAAACiAAAAAAAAAKIAAAAAAAAAogAAABQAAAAAAAAAAAAAANIAAAAAAAAA0gAA AAAAAADSAAAAAAAAANIAAAAAAAAA0gAAAAwAAADeAAAAFAAAANIAAAAAAAAAswEAAGACAAD+AAAA AAAAAP4AAAAAAAAA/gAAAAAAAAD+AAAAAAAAAP4AAAAAAAAA/gAAAAAAAAD+AAAAAAAAAP4AAAAA AAAAcAEAAAIAAAByAQAAAAAAAHIBAAAAAAAAcgEAAAAAAAByAQAAAAAAAHIBAAAAAAAAcgEAACwA AAATBAAAIAIAADMGAABiAAAAngEAABUAAAAAAAAAAAAAAAAAAAAAAAAAogAAAAAAAAD+AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+AAAAAAAAAP4AAAAAAAAA/gAAAAAAAAD+AAAAAAAAAJ4BAAAAAAAA /gAAAAAAAACiAAAAAAAAAKIAAAAAAAAA/gAAAAAAAAAAAAAAAAAAAP4AAAAAAAAA/gAAAAAAAAD+ AAAAAAAAAP4AAAAAAAAA/gAAAAAAAAD+AAAAAAAAAKIAAAAAAAAA/gAAAAAAAACiAAAAAAAAAP4A AAAAAAAAcAEAAAAAAAAAAAAAAAAAAP4AAAAAAAAAtgAAAA4AAADEAAAADgAAAKIAAAAAAAAAogAA AAAAAACiAAAAAAAAAKIAAAAAAAAA/gAAAAAAAABwAQAAAAAAAP4AAAByAAAA/gAAAAAAAAAAAAAA AAAAAHABAAAAAAAAogAAAAAAAACiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAEAAAAAAAAAAAAAAAAAAPIAAAAMAAAAiw1bugAA AADSAAAAAAAAANIAAAAAAAAA/gAAAAAAAABwAQAAAAAAAAAAAAAAAAAAcAEAAAAAAACzAQAAAAAA ALMBAAAAAAAAcAEAAAAAAACVBgAAAAAAAP4AAAAAAAAAlQYAAAAAAABwAQAAAAAAAP4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABADDAA8A5QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEZWFy IFINDWlzIHRoYXQgYSBidWc/PzoNDVItY29kZToNIyBkYXRhIHByZXBhcmF0aW9uDWQuZGF0YTwt cmVhZC50YWJsZSgiYnVnLnR4dCIsaGVhZGVyPVQpDWQuZGF0YSRmYWN0MTwtYXMuZmFjdG9yKGQu RjEkZmFjdDEpDWQuZGF0YSRmYWN0MjwtYXMuZmFjdG9yKGQuRjEkZmFjdDIpDWxpYnJhcnkoc3Vy dml2YWwpDSMgQ294IFByb3BvcnRpb25hbCBIYXphcmQNci5jb3g8LWNveHBoKFN1cnYodGltZSxk ZWx0YSl+ZmFjdDErZmFjdDIrY292YXIsZGF0YT1kLmRhdGEpDWRyb3AxKHIuY294LHRlc3Q9IkNo aXNxIikNDW91dHB1dDoNU2luZ2xlIHRlcm0gZGVsZXRpb25zDQ1Nb2RlbDoNU3Vydih0aW1lLCBk ZWx0YSkgfiBmYWN0MSArIGZhY3QyICsgY292YXINICAgICAgIERmICAgIEFJQyAgICBMUlQgICBQ cihDaGkpICAgIA08bm9uZT4gICAgODI3LjkwICAgICAgICAgICAgICAgICAgICAgDWZhY3QxICAg NyA4MjguNDkgIDE0LjU4ICAgMC4wNDE3MiAqICANZmFjdDIgICA0IDg0My41NCAgMjMuNjMgOS40 NTVlLTA1ICoqKg1jb3ZhciAgIDEgODI1Ljk4ICAgMC4wOCAgIDAuNzc3NjkgICAgDS0tLQ1TaWdu aWYuIGNvZGVzOiAgMCBgKioqJyAwLjAwMSBgKionIDAuMDEgYConIDAuMDUgYC4nIDAuMSBgICcg MQ0NDWlmIEkgZG8gdGhlIHNhbWUgb24gc3BzcywgdGhlIHAtdmFsdWUgZm9yIGZhY3QxIGlzIDAu MDIsIGZvciBmYWN0MiwgaXRzIDAuMDAxLiBJcyB0aGF0IGEgYnVnIG9yIGp1c3QgZGlmZmVyZW50 IHByb2NlZHVyZXM/DQ1hbHNvLCBpZiBOQSdzIGFyZSBpbiB0aGUgZmlsZSwgdGhlIHAtdmFsdWVz IHNlZW0gdG8gYmUgY29tcGxldGVseSBpbXBvc3NpYmxlLi4uDQ1iZXN0DVBpdXMNDQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAiBgAA JAYAADQGAABQBgAAtgYAAM8GAAAnBwAAMAcAAFIJAABTCQAAAPnx+eri6gDZ1AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAIT0oHAFFKBwAAEUIqAU9KBwBRSgcAcGgAAAAADzUIgU9KBgBQSgAA UUoGAAxPSgUAUEoAAFFKBQAADzUIgU9KBABQSgAAUUoEAAxPSgMAUEoAAFFKAwAKAAYAAAcGAAAI BgAAGQYAABoGAAAiBgAANQYAAFwGAACABgAApAYAALYGAADQBgAADQcAACcHAAAoBwAAMAcAAEYH AABHBwAATgcAAHgHAACeBwAAxAcAAOoHAAAQCAAANggAADoIAAB5CAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADhAAAAAAAA AAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAA AOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAHAAAMSQANyQAOCQASCQA DcYmAAzQAqAFcAhACxAO4BCwE4AWUBkgHPAewCEAAAAAAAAAAAAAAAAAAQAAABoABgAABwYAAAgG AAAZBgAAGgYAACIGAAA1BgAAXAYAAIAGAACkBgAAtgYAANAGAAANBwAAJwcAACgHAAAwBwAARgcA AEcHAABOBwAAeAcAAJ4HAADEBwAA6gcAABAIAAA2CAAAOggAAHkIAAB6CAAAewgAAPYIAAD3CAAA RwkAAEgJAABNCQAAUgkAAFMJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI3kIAAB6CAAAewgA APYIAAD3CAAARwkAAEgJAABNCQAAUgkAAFMJAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAJHAAfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAGkADwAC AAgACAAIADQAAEDx/wIANAAAAAYATgBvAHIAbQBhAGwAAAACAAAAFABDShgAT0oIAFBKCABRSggA bUgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQBy AGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAAAAAAUwMAAAUAABYAAAAA/////wEA AAAEIP//AQCgepkAAAAAAFMDAAAAAAAAAAAABgAAUwkAAAcAAAAABgAAeQgAAFMJAAAIAAAACgAA AAAGAABTCQAACQAAAP//AgAAAAsAcABpAHUAcwAgAGsAbwByAG4AZQByACkAVABvAHAAbwBsAGkA bgBvACAASABEACAAOgBVAHMAZQByAHMAOgBrAG8AcgBuAGUAcgA6AEQAZQBzAGsAdABvAHAAOgBi AHUAZwAuAGQAbwBjAP9AA4ABAFIDAABSAwAA3GOyAwEAAQBSAwAAAAAAAHgCAAAAAAAAAwADACMD owICEAAAAAAAAABTAwAAUAAADABAAAAJAAAARwaQAQAAAAICBgMFBAUCAwAAAAMAAAAAAAAAAAAA AAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAAIABQAAAAAA AAAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAAILBgQCAgICAgAA AAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAADsGkAEAAAACAAUAAAAAAAAAAAADAAAA AAAAAAAAAAAAAQAAAAAAAABIAGUAbAB2AGUAdABpAGMAYQAAAFEgkAFNDwAAAAAAAAAAAAAAAAAD AAAAAAAAAAAAAAAAAQAAAAAAAABIAGUAbAB2AGUAdABpAGMAYQAtAEIAbwBsAGQAAABUAGkAbQBl AHMAAABNAJABTQ0AAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAATAB1AGMAaQBkAGEA RwByAGEAbgBkAGUAAABUAGkAbQBlAHMAAABXAJABTRIAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA AAEAAAAAAAAATAB1AGMAaQBkAGEARwByAGEAbgBkAGUALQBCAG8AbABkAAAAVABpAG0AZQBzAAAA QQaQAQAAAAILBQYCAgIDAgAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAgAE4AYQBy AHIAbwB3AAAAMwaQAQAAAAIABQAAAAAAAAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUA cwAAACAABAAxCIwYAPDQAgAAaAEAAAAAVNxxJlfccSYAAAAAAQADAAAAAAAAAAAAAAABAAEAAAAE AAMQAQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAADpAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAClBsAHtAC0AIAAEjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAHICAAAAAAgAAEAA 8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAABgBEAGUAYQByACAA UgAAAAAAAAALAHAAaQB1AHMAIABrAG8AcgBuAGUAcgALAHAAaQB1AHMAIABrAG8AcgBuAGUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAA AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAXAEAABAAAAABAAAAiAAAAAIAAACQAAAAAwAAAKAA AAAEAAAArAAAAAUAAADAAAAABwAAAMwAAAAIAAAA3AAAAAkAAADwAAAAEgAAAPwAAAAKAAAAGAEA AAwAAAAkAQAADQAAADABAAAOAAAAPAEAAA8AAABEAQAAEAAAAEwBAAATAAAAVAEAAAIAAAAQJwAA HgAAAAcAAABEZWFyIFIAZh4AAAABAAAAAGVhch4AAAAMAAAAcGl1cyBrb3JuZXIAHgAAAAEAAAAA aXVzHgAAAAcAAABOb3JtYWwAch4AAAAMAAAAcGl1cyBrb3JuZXIAHgAAAAIAAAAxAHVzHgAAABQA AABNaWNyb3NvZnQgV29yZCAxMC4xAEAAAAAA0klrAAAAAEAAAAAAuHDwH8bCAUAAAAAAirpbIMbC AQMAAAABAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAAAC 1c3VnC4bEJOXCAArLPmuMAAAAPQAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACAAAAABgAAAIgA AAARAAAAkAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgAAAANAAAAwAAA AAwAAADTAAAAAgAAABAnAAAeAAAABQAAAGV0aHoAAERlAwAAAAEAAAADAAAAAQAAAAMAAAAAAAAA AwAAAHIJCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAABwAAAERlYXIg UgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAAAAAAAAAAIDfvdQoxsIBKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeFgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAAAAAAAE8AYgBqAGUAYwB0 AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAACA373UKMbCAYDfvdQoxsIBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8CAAEA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQA/v///05CNlcQAAAAV29yZC5Eb2N1bWVudC44AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --Apple-Mail-28-953181987-- --Apple-Mail-27-953181986 Content-Disposition: attachment; filename=bug.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/tab-separated-values; x-mac-creator=5843454C; x-unix-mode=0644; x-mac-type=54455854; name="bug.txt" fact1 fact2 covar time delta=0D57 1 71 100 = 0=0D24 27 73 100 0=0D54 42 74 46 1=0D24 = 27 77 100 0=0D60 42 78 100 0=0D33 1 = 78 100 0=0D60 42 79 100 0=0D54 42 79 = 100 0=0D24 1 79 100 0=0D48 27 80 78 = 1=0D54 1 80 100 0=0D54 42 81 34 1=0D24 = 27 81 48 1=0D24 1 81 100 0=0D48 40 = 81 100 0=0D58 1 82 13 1=0D60 27 82 = 100 0=0D24 27 82 100 0=0D60 1 83 14 = 1=0D24 1 83 45 1=0D54 42 83 100 0=0D60 = 42 83 100 0=0D33 1 84 41 1=0D54 42 = 84 45 1=0D60 1 84 74 1=0D57 42 84 = 100 0=0D24 27 84 100 0=0D24 27 84 100 = 0=0D24 42 84 100 0=0D60 42 85 100 0=0D57 = 42 85 100 0=0D54 1 85 100 0=0D58 27 = 86 3 1=0D60 1 86 41 1=0D54 1 86 = 58 1=0D54 1 86 100 0=0D60 27 86 100 = 0=0D24 1 86 100 0=0D24 1 86 100 0=0D24 = 27 87 25 1=0D54 1 87 100 0=0D54 42 = 87 100 0=0D54 42 87 100 0=0D57 27 87 = 100 0=0D54 40 87 100 0=0D24 42 87 100 = 0=0D24 42 87 100 0=0D24 42 87 100 0=0D24 = 40 88 63 1=0D24 42 88 68 1=0D54 42 = 88 89 1=0D54 42 88 100 0=0D54 40 88 = 100 0=0D33 27 88 100 0=0D54 1 88 100 = 0=0D54 40 88 100 0=0D54 27 88 100 0=0D54 = 1 88 100 0=0D24 1 88 100 0=0D24 27 = 88 100 0=0D24 42 88 100 0=0D24 49 88 = 100 0=0D54 40 89 10 1=0D54 1 89 43 = 1=0D60 27 89 58 1=0D60 42 89 100 0=0D54 = 42 89 100 0=0D54 40 89 100 0=0D54 1 = 89 100 0=0D54 40 89 100 0=0D54 49 89 = 100 0=0D54 42 89 100 0=0D54 1 89 100 = 0=0D24 1 89 100 0=0D33 40 89 100 0=0D24 = 49 89 100 0=0D7 42 89 100 0=0D24 27 = 89 100 0=0D24 1 89 100 0=0D33 1 90 = 3 1=0D48 42 90 7 1=0D24 42 90 7 = 1=0D24 1 90 35 1=0D48 1 90 45 1=0D24 = 40 90 52 1=0D60 1 90 58 1=0D58 42 = 90 61 1=0D60 42 90 62 1=0D60 1 90 = 63 1=0D24 42 90 82 1=0D54 27 90 100 = 0=0D60 42 90 100 0=0D54 1 90 100 0=0D54 = 27 90 100 0=0D60 40 90 100 0=0D54 27 = 90 100 0=0D54 40 90 100 0=0D33 40 90 = ==> 2499.audit <== Wed Jan 29 20:22:13 2003 thomas changed notes Wed Jan 29 20:22:13 2003 thomas foobar Wed Jan 29 20:22:13 2003 thomas moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2520 * Subject: Apparent parser problem From: "Jim Rogers" Date: Sat, 1 Feb 2003 16:51:41 -0500 --Its an ESS or XEmacs problem. I redirected him to ESS-bugs. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2520 <== From mailnull@stat.math.ethz.ch Sat Feb 1 22:52:39 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA05614 for ; Sat, 1 Feb 2003 22:52:38 +0100 (MET) Received: from hypatia.math.ethz.ch (mailnull@localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.6/8.12.6) with ESMTP id h11LpnGG028138 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 1 Feb 2003 22:51:49 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.6/8.12.6/Submit) id h11Lpm5f028137 for R-bugs@biostat.ku.dk; Sat, 1 Feb 2003 22:51:48 +0100 (MET) Received: from franz.stat.wisc.edu (mail@www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.6/8.12.6) with ESMTP id h11LpiGF028121 for ; Sat, 1 Feb 2003 22:51:45 +0100 (MET) Received: from [66.9.123.50] (helo=mercury.cantatapharm.com) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 18f5Y7-0000kV-00 for ; Sat, 01 Feb 2003 15:51:43 -0600 content-class: urn:content-classes:message Subject: Apparent parser problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 1 Feb 2003 16:51:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <99A12772DCDEEB458B996332957B0D53011749@mercury.cantatapharm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Apparent parser problem Thread-Index: AcLKPBqdX60dZahxRyWJzrWscd1tfQ== From: "Jim Rogers" To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hypatia.math.ethz.ch id h11LpiGF028121 X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: Let me first admit: I am experiencing this bug on a precompiled binary of R for windows, and I know these are not supported. I am not asking for support, but I thought the R developers would want to know about this. # Define: foo.page <- function(x) x # Then, foo.page("a") # actually invokes the pager (!) on object named "a" (if one is defined). # same thing happens if you define the function with the name .page. # Interestingly, foo.page("a" ) # will actually act as desired (returns "a") _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 1 minor 6.2 year 2003 month 01 day 10 language R Cheers, Jim Rogers James A. Rogers, Ph.D. Statistical Scientist Cantata Pharmaceuticals 3-G Gill St Woburn, MA 01801 617.225.9009 Fax 617.225.9010 ==> 2520.followup.1 <== From ripley@stats.ox.ac.uk Sat Feb 1 23:11:16 2003 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA05674 for ; Sat, 1 Feb 2003 23:11:16 +0100 (MET) From: ripley@stats.ox.ac.uk Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id WAA00664; Sat, 1 Feb 2003 22:10:28 GMT Date: Sat, 1 Feb 2003 22:10:27 +0000 (GMT) X-X-Sender: ripley@gannet.stats To: jrogers@cantatapharm.com cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Apparent parser problem (PR#2520) In-Reply-To: <200302012152.WAA05619@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That does not happen here, using the precompiled binary rw1062.exe (which BTW is supported: it is the 182 addon packages which are not). You *did* do this in a new session with --vanilla, didn't you? On Sat, 1 Feb 2003 jrogers@cantatapharm.com wrote: > Let me first admit: I am experiencing this bug on a precompiled binary > of R for windows, and I know these are not supported. I am not asking > for support, but I thought the R developers would want to know about > this. > > # Define: > > foo.page <- function(x) x > > # Then, > > foo.page("a") > > # actually invokes the pager (!) on object named "a" (if one is > defined). > # same thing happens if you define the function with the name > .page. > > # Interestingly, > > foo.page("a" ) > > # will actually act as desired (returns "a") > > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 1 > minor 6.2 > year 2003 > month 01 > day 10 > language R > > > Cheers, > Jim Rogers > > James A. Rogers, Ph.D. > Statistical Scientist > Cantata Pharmaceuticals > 3-G Gill St > Woburn, MA 01801 > 617.225.9009 > Fax 617.225.9010 > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > http://www.stat.math.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 2520.followup.2 <== From jrogers@cantatapharm.com Sun Feb 2 02:54:21 2003 Received: from mercury.cantatapharm.com ([66.9.123.50]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id CAA06281 for ; Sun, 2 Feb 2003 02:54:20 +0100 (MET) content-class: urn:content-classes:message Subject: RE: [Rd] Apparent parser problem (PR#2520) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 1 Feb 2003 20:53:28 -0500 Message-ID: <99A12772DCDEEB458B996332957B0D5301174A@mercury.cantatapharm.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rd] Apparent parser problem (PR#2520) Thread-Index: AcLKPsxV5Tm5i7xpRlacTaMmQ0IJwQAHTGlQ From: "Jim Rogers" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id CAA06281 > You *did* do this in a new session with --vanilla, didn't you? Almost. What I did was comment out all of the lines of my Rprofile, and start with a new .Rdata (this should have the same effect as --vanilla, right?). Doing that, I get the behavior I described, but... I now see that I only get the problem when running R through iESS. If I work directly with Rterm, or with Rgui, I don't get the problem. So, R is not responsible (sorry!) and perhaps I should pursue this outside of R-bugs. But may I ask if anyone can replicate my problem when working through iESS? Jim > -----Original Message----- > From: ripley@stats.ox.ac.uk [mailto:ripley@stats.ox.ac.uk] > Sent: Saturday, February 01, 2003 5:10 PM > To: Jim Rogers > Cc: R-bugs@biostat.ku.dk > Subject: Re: [Rd] Apparent parser problem (PR#2520) > > > That does not happen here, using the precompiled binary > rw1062.exe (which BTW is supported: it is the 182 addon > packages which are not). > > You *did* do this in a new session with --vanilla, didn't you? > > > On Sat, 1 Feb 2003 jrogers@cantatapharm.com wrote: > > > Let me first admit: I am experiencing this bug on a > precompiled binary > > of R for windows, and I know these are not supported. I am > not asking > > for support, but I thought the R developers would want to > know about > > this. > > > > # Define: > > > > foo.page <- function(x) x > > > > # Then, > > > > foo.page("a") > > > > # actually invokes the pager (!) on object named "a" (if one is > > defined). # same thing happens if you define the function with the > > name .page. > > > > # Interestingly, > > > > foo.page("a" ) > > > > # will actually act as desired (returns "a") > > > > _ > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status > > major 1 > > minor 6.2 > > year 2003 > > month 01 > > day 10 > > language R > > > > > > Cheers, > > Jim Rogers > > > > James A. Rogers, Ph.D. > > Statistical Scientist > > Cantata Pharmaceuticals > > 3-G Gill St > > Woburn, MA 01801 > > 617.225.9009 > > Fax 617.225.9010 > > > > ______________________________________________ > > R-devel@stat.math.ethz.ch mailing list > > http://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > > ==> 2520.audit <== Tue Feb 4 01:04:27 2003 thomas changed notes Tue Feb 4 01:04:27 2003 thomas foobar Tue Feb 4 01:04:27 2003 thomas moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2859 * Subject: bug and proposed fix in print.trellis 1.7.0 From: Rich Heiberger Date: Sun, 27 Apr 2003 01:56:30 -0400 --Lattice ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2859 <== From mailnull@stat.math.ethz.ch Sun Apr 27 07:58:02 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3R5w1pD001157 for ; Sun, 27 Apr 2003 07:58:01 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3R5vvbj002219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Apr 2003 07:57:57 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3R5vudl002218 for R-bugs@biostat.ku.dk; Sun, 27 Apr 2003 07:57:56 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3R5vkbi002193 for ; Sun, 27 Apr 2003 07:57:47 +0200 (MEST) Received: from surfer.sbm.temple.edu ([155.247.185.2]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 199fAE-0006i6-00 for ; Sun, 27 Apr 2003 00:57:26 -0500 Received: from localhost (rmh@localhost) by surfer.sbm.temple.edu (8.12.8p1/8.12.8) with ESMTP id h3R5uUG52625009 for ; Sun, 27 Apr 2003 01:56:30 -0400 (EDT) Date: Sun, 27 Apr 2003 01:56:30 -0400 From: Rich Heiberger To: Subject: bug and proposed fix in print.trellis 1.7.0 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1678264062-154654637-1051422990=:2626055" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-9.0 required=5.0 tests=QUOTED_EMAIL_TEXT,USER_AGENT_PINE version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1678264062-154654637-1051422990=:2626055 Content-Type: TEXT/PLAIN; charset=US-ASCII ---1678264062-154654637-1051422990=:2626055 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pt-R.bug.report" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: description Content-Disposition: attachment; filename="pt-R.bug.report" IyBZb3VyIG1haWxlciBpcyBzZXQgdG8gIm5vbmUiIChkZWZhdWx0IG9uIFdp bmRvd3MpLA0NCiMgaGVuY2Ugd2UgY2Fubm90IHNlbmQgdGhlIGJ1ZyByZXBv cnQgZGlyZWN0bHkgZnJvbSBSLg0NCiMgUGxlYXNlIGNvcHkgdGhlIGJ1ZyBy ZXBvcnQgKGFmdGVyIGZpbmlzaGluZyBpdCkgdG8NDQojIHlvdXIgZmF2b3Jp dGUgZW1haWwgcHJvZ3JhbSBhbmQgc2VuZCBpdCB0bw0NCiMNDQojICAgICAg IHItYnVnc0ByLXByb2plY3Qub3JnDQ0KIw0NCiMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0NCg0NCg0N ClRoZSBuZXcgZmVhdHVyZSBkZXNjcmliZWQgaW4gcncxMDcwL2xpYnJhcnkv bGF0dGljZS9DaGFuZ2VzIGlzIHZlcnkNDQp1c2VmdWwgYW5kIGlzIG5lZWRl ZCBmb3Igc2V2ZXJhbCBvZiB0aGUgZXhhbXBsZXMgSSBzaG93ZWQgYXQgRFND LTIwMDMuDQ0KDQ0KPiBzY2FsZXMNDQo+IC0tLS0tLQ0NCj4gSW4gYW50aWNp cGF0aW9uIG9mIGZ1dHVyZSB1c2UgKGluIG5sbWUsIGZvciBleGFtcGxlKSwg dGhlIGF0IGFuZA0NCj4gbGFiZWxzIGNvbXBvbmVudHMgb2Ygc2NhbGVzIGNh biBub3cgYmUgYSBsaXN0LiBFYWNoIGVsZW1lbnQNDQo+IGNvcnJlc3BvbmRz IHRvIGEgcGFuZWwuIFRoaXMgaXMgdGhvcm91Z2hseSB1bnRlc3RlZCBhbmQg bm90IGd1YXJhbnRlZWQNDQo+IHRvIHdvcmsuDQ0KDQ0KSXQgY3VycmVudGx5 IHJlamVjdHMgY29ycmVjdGx5IGZvcm1lZCB1c2VyIGxhYmVscy4gIEkgYXR0 YWNoIGFuDQ0KZXhhbXBsZSBvZiB0aGUgcHJvYmxlbSBhbmQgYSBwcm9wb3Nl ZCBmaXguDQ0KDQ0KUmljaA0NCg0NCi0tcGxlYXNlIGRvIG5vdCBlZGl0IHRo ZSBpbmZvcm1hdGlvbiBiZWxvdy0tDQ0KDQ0KVmVyc2lvbjoNDQogcGxhdGZv cm0gPSBpMzg2LXBjLW1pbmd3MzINDQogYXJjaCA9IGkzODYNDQogb3MgPSBt aW5ndzMyDQ0KIHN5c3RlbSA9IGkzODYsIG1pbmd3MzINDQogc3RhdHVzID0g DQ0KIG1ham9yID0gMQ0NCiBtaW5vciA9IDcuMA0NCiB5ZWFyID0gMjAwMw0N CiBtb250aCA9IDA0DQ0KIGRheSA9IDE2DQ0KIGxhbmd1YWdlID0gUg0NCg0N CldpbmRvd3MgWFAgSG9tZSBFZGl0aW9uIChidWlsZCAyNjAwKSBTZXJ2aWNl IFBhY2sgMS4wDQ0KDQ0KU2VhcmNoIFBhdGg6DQ0KIC5HbG9iYWxFbnYsIGZp bGU6YzovSE9NRS9ybWgvaGgvc3BsdXMubGlicmFyeS8uUkRhdGEsIHBhY2th Z2U6Z3JpZCwgcGFja2FnZTpsYXR0aWNlLCBwYWNrYWdlOm1ldGhvZHMsIHBh Y2thZ2U6Y3Rlc3QsIHBhY2thZ2U6bXZhLCBwYWNrYWdlOm1vZHJlZywgcGFj a2FnZTpubHMsIHBhY2thZ2U6dHMsIEF1dG9sb2FkcywgcGFja2FnZTpiYXNl DQ0K ---1678264062-154654637-1051422990=:2626055 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pt-test.r" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: illustration Content-Disposition: attachment; filename="pt-test.r" IyMgcHJpbnQudHJlbGxpcyBidWcgaW4gUiAxLjcuMA0KDQp0bXAgPC0gZGF0 YS5mcmFtZShhPWZhY3RvcihjKCJhIiwiYiIsImMiKSksDQogICAgICAgICAg ICAgICAgICBiPWZhY3RvcihjKCJkIiwiZSIsImYiKSksDQogICAgICAgICAg ICAgICAgICBkPWZhY3RvcihjKDEsMSwyKSkpDQoNCnh5cGxvdChhIH4gYiB8 IGQsIGRhdGE9dG1wLCAgIyMgd29ya3MNCiAgICAgICAgc2NhbGVzPWxpc3Qo YWx0ZXJuYXRpbmc9RikpDQoNCnh5cGxvdChhIH4gYiB8IGQsIGRhdGE9dG1w LCAgIyMgSW52YWxpZCB2YWx1ZSBmb3IgbGFiZWxzDQogICAgICAgc2NhbGVz PWxpc3QoeD1saXN0KGxhYmVscz1saXN0KGMoImQiLCJlIiwiIiksYygiIiwi IiwiZiIpKSwNCiAgICAgICAgICAgICAgICAgICAgIGFsdGVybmF0aW5nPUYp KSkNCg0Kc291cmNlKCJwcmludC50cmVsbGlzLnIiKSAgICAjIyBybWggcHJv cG9zZWQgZml4DQoNCnh5cGxvdChhIH4gYiB8IGQsIGRhdGE9dG1wLCAgIyMg bm93IGl0IHdvcmtzDQogICAgICAgc2NhbGVzPWxpc3QoeD1saXN0KGxhYmVs cz1saXN0KGMoImQiLCJlIiwiIiksYygiIiwiIiwiZiIpKSwNCiAgICAgICAg ICAgICAgICAgICAgIGFsdGVybmF0aW5nPUYpKSkNCg== ---1678264062-154654637-1051422990=:2626055 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="print.trellis.r" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: proposed fix Content-Disposition: attachment; filename="print.trellis.r" cHJpbnQudHJlbGxpcyA8LQ0KZnVuY3Rpb24gKHgsIHBvc2l0aW9uLCBzcGxp dCwgbW9yZSA9IEZBTFNFLCBuZXdwYWdlID0gVFJVRSwgcGFuZWwuaGVpZ2h0 ID0gbGlzdCgxLCANCiAgICAibnVsbCIpLCBwYW5lbC53aWR0aCA9IGxpc3Qo MSwgIm51bGwiKSwgLi4uKSANCnsNCiAgICBpZiAoaXMubnVsbChkZXYubGlz dCgpKSkgDQogICAgICAgIHRyZWxsaXMuZGV2aWNlKCkNCiAgICBlbHNlIGlm IChpcy5udWxsKHRyZWxsaXMucGFyLmdldCgpKSkgDQogICAgICAgIHRyZWxs aXMuZGV2aWNlKGRldmljZSA9IC5EZXZpY2UsIG5ldyA9IEZBTFNFKQ0KICAg IGJnID0gdHJlbGxpcy5wYXIuZ2V0KCJiYWNrZ3JvdW5kIikkY29sDQogICAg bmV3IDwtIFRSVUUNCiAgICBpZiAoLmxhdHRpY2UucHJpbnQubW9yZSB8fCAh bmV3cGFnZSkgDQogICAgICAgIG5ldyA8LSBGQUxTRQ0KICAgIC5sYXR0aWNl LnByaW50Lm1vcmUgPDwtIG1vcmUNCiAgICB1c3VhbCA8LSAobWlzc2luZyhw b3NpdGlvbikgJiBtaXNzaW5nKHNwbGl0KSkNCiAgICBmb250c2l6ZS5kZWZh dWx0IDwtIHRyZWxsaXMucGFyLmdldCgiZm9udHNpemUiKSRkZWZhdWx0DQog ICAgaWYgKCFtaXNzaW5nKHBvc2l0aW9uKSkgew0KICAgICAgICBpZiAobGVu Z3RoKHBvc2l0aW9uKSAhPSA0KSANCiAgICAgICAgICAgIHN0b3AoIkluY29y cmVjdCB2YWx1ZSBvZiBwb3NpdGlvbiIpDQogICAgICAgIGlmIChuZXcpIHsN CiAgICAgICAgICAgIGdyaWQubmV3cGFnZSgpDQogICAgICAgICAgICBncmlk LnJlY3QoZ3AgPSBncGFyKGZpbGwgPSBiZywgY29sID0gInRyYW5zcGFyZW50 IikpDQogICAgICAgIH0NCiAgICAgICAgcHVzaC52aWV3cG9ydCh2aWV3cG9y dCh4ID0gcG9zaXRpb25bMV0sIHkgPSBwb3NpdGlvblsyXSwgDQogICAgICAg ICAgICB3aWR0aCA9IHBvc2l0aW9uWzNdIC0gcG9zaXRpb25bMV0sIGhlaWdo dCA9IHBvc2l0aW9uWzRdIC0gDQogICAgICAgICAgICAgICAgcG9zaXRpb25b Ml0sIGp1c3QgPSBjKCJsZWZ0IiwgImJvdHRvbSIpKSkNCiAgICAgICAgaWYg KCFtaXNzaW5nKHNwbGl0KSkgew0KICAgICAgICAgICAgaWYgKGxlbmd0aChz cGxpdCkgIT0gNCkgDQogICAgICAgICAgICAgICAgc3RvcCgiSW5jb3JyZWN0 IHZhbHVlIG9mIHNwbGl0IikNCiAgICAgICAgICAgIHB1c2gudmlld3BvcnQo dmlld3BvcnQobGF5b3V0ID0gZ3JpZC5sYXlvdXQobnJvdyA9IHNwbGl0WzRd LCANCiAgICAgICAgICAgICAgICBuY29sID0gc3BsaXRbM10pKSkNCiAgICAg ICAgICAgIHB1c2gudmlld3BvcnQodmlld3BvcnQobGF5b3V0LnBvcy5yb3cg PSBzcGxpdFsyXSwgDQogICAgICAgICAgICAgICAgbGF5b3V0LnBvcy5jb2wg PSBzcGxpdFsxXSkpDQogICAgICAgIH0NCiAgICB9DQogICAgZWxzZSBpZiAo IW1pc3Npbmcoc3BsaXQpKSB7DQogICAgICAgIGlmIChsZW5ndGgoc3BsaXQp ICE9IDQpIA0KICAgICAgICAgICAgc3RvcCgiSW5jb3JyZWN0IHZhbHVlIG9m IHNwbGl0IikNCiAgICAgICAgaWYgKG5ldykgew0KICAgICAgICAgICAgZ3Jp ZC5uZXdwYWdlKCkNCiAgICAgICAgICAgIGdyaWQucmVjdChncCA9IGdwYXIo ZmlsbCA9IGJnLCBjb2wgPSAidHJhbnNwYXJlbnQiKSkNCiAgICAgICAgfQ0K ICAgICAgICBwdXNoLnZpZXdwb3J0KHZpZXdwb3J0KGxheW91dCA9IGdyaWQu bGF5b3V0KG5yb3cgPSBzcGxpdFs0XSwgDQogICAgICAgICAgICBuY29sID0g c3BsaXRbM10pKSkNCiAgICAgICAgcHVzaC52aWV3cG9ydCh2aWV3cG9ydChs YXlvdXQucG9zLnJvdyA9IHNwbGl0WzJdLCBsYXlvdXQucG9zLmNvbCA9IHNw bGl0WzFdKSkNCiAgICB9DQogICAgcGFuZWwgPC0gaWYgKGlzLmZ1bmN0aW9u KHgkcGFuZWwpKSANCiAgICAgICAgeCRwYW5lbA0KICAgIGVsc2UgaWYgKGlz LmNoYXJhY3Rlcih4JHBhbmVsKSkgDQogICAgICAgIGdldCh4JHBhbmVsKQ0K ICAgIGVsc2UgZXZhbCh4JHBhbmVsKQ0KICAgIHgkc3RyaXAgPC0gaWYgKGlz LmZ1bmN0aW9uKHgkc3RyaXApKSANCiAgICAgICAgeCRzdHJpcA0KICAgIGVs c2UgaWYgKGlzLmNoYXJhY3Rlcih4JHN0cmlwKSkgDQogICAgICAgIGdldCh4 JHN0cmlwKQ0KICAgIGVsc2UgZXZhbCh4JHN0cmlwKQ0KICAgIGF4aXMubGlu ZSA8LSB0cmVsbGlzLnBhci5nZXQoImF4aXMubGluZSIpDQogICAgbnVtYmVy Lm9mLmNvbmQgPC0gbGVuZ3RoKHgkY29uZGxldmVscykNCiAgICBsYXlvdXQu cmVzcGVjdCA8LSAheCRhc3BlY3QuZmlsbA0KICAgIGlmIChsYXlvdXQucmVz cGVjdCkgDQogICAgICAgIHBhbmVsLmhlaWdodFtbMV1dIDwtIHgkYXNwZWN0 LnJhdGlvICogcGFuZWwud2lkdGhbWzFdXQ0KICAgIGlmICghaXMubnVsbCh4 JGtleSkpIHsNCiAgICAgICAga2V5LmdmIDwtIGRyYXcua2V5KHgka2V5KQ0K ICAgICAgICBrZXkuc3BhY2UgPC0gaWYgKCJzcGFjZSIgJWluJSBuYW1lcyh4 JGtleSkpIA0KICAgICAgICAgICAgeCRrZXkkc3BhY2UNCiAgICAgICAgZWxz ZSBpZiAoIngiICVpbiUgbmFtZXMoeCRrZXkpIHx8ICJjb3JuZXIiICVpbiUg bmFtZXMoeCRrZXkpKSANCiAgICAgICAgICAgICJpbnNpZGUiDQogICAgICAg IGVsc2UgInRvcCINCiAgICB9DQogICAgZWxzZSBpZiAoIWlzLm51bGwoeCRj b2xvcmtleSkpIHsNCiAgICAgICAga2V5LmdmIDwtIGRyYXcuY29sb3JrZXko eCRjb2xvcmtleSkNCiAgICAgICAga2V5LnNwYWNlIDwtIGlmICgic3BhY2Ui ICVpbiUgbmFtZXMoeCRjb2xvcmtleSkpIA0KICAgICAgICAgICAgeCRjb2xv cmtleSRzcGFjZQ0KICAgICAgICBlbHNlICJyaWdodCINCiAgICB9DQogICAg eGF4aXMuY29sIDwtIGlmIChpcy5sb2dpY2FsKHgkeC5zY2FsZXMkY29sKSkg DQogICAgICAgIGF4aXMubGluZSRjb2wNCiAgICBlbHNlIHgkeC5zY2FsZXMk Y29sDQogICAgeGF4aXMuZm9udCA8LSBpZiAoaXMubG9naWNhbCh4JHguc2Nh bGVzJGZvbnQpKSANCiAgICAgICAgMQ0KICAgIGVsc2UgeCR4LnNjYWxlcyRm b250DQogICAgeGF4aXMuY2V4IDwtIHgkeC5zY2FsZXMkY2V4DQogICAgeGF4 aXMucm90IDwtIGlmIChpcy5sb2dpY2FsKHgkeC5zY2FsZXMkcm90KSkgDQog ICAgICAgIGMoMCwgMCkNCiAgICBlbHNlIHgkeC5zY2FsZXMkcm90DQogICAg eWF4aXMuY29sIDwtIGlmIChpcy5sb2dpY2FsKHgkeS5zY2FsZXMkY29sKSkg DQogICAgICAgIGF4aXMubGluZSRjb2wNCiAgICBlbHNlIHgkeS5zY2FsZXMk Y29sDQogICAgeWF4aXMuZm9udCA8LSBpZiAoaXMubG9naWNhbCh4JHkuc2Nh bGVzJGZvbnQpKSANCiAgICAgICAgMQ0KICAgIGVsc2UgeCR5LnNjYWxlcyRm b250DQogICAgeWF4aXMuY2V4IDwtIHgkeS5zY2FsZXMkY2V4DQogICAgeWF4 aXMucm90IDwtIGlmICghaXMubG9naWNhbCh4JHkuc2NhbGVzJHJvdCkpIA0K ICAgICAgICB4JHkuc2NhbGVzJHJvdA0KICAgIGVsc2UgaWYgKHgkeS5zY2Fs ZXMkcmVsYXRpb24gIT0gInNhbWUiICYmIGlzLmxvZ2ljYWwoeCR5LnNjYWxl cyRsYWJlbHMpKSANCiAgICAgICAgYyg5MCwgOTApDQogICAgZWxzZSBjKDAs IDApDQogICAgc3RyaXAuY29sLmRlZmF1bHQuYmcgPC0gcmVwKHRyZWxsaXMu cGFyLmdldCgic3RyaXAuYmFja2dyb3VuZCIpJGNvbCwgDQogICAgICAgIGxl bmd0aCA9IG51bWJlci5vZi5jb25kKQ0KICAgIHN0cmlwLmNvbC5kZWZhdWx0 LmZnIDwtIHJlcCh0cmVsbGlzLnBhci5nZXQoInN0cmlwLnNoaW5nbGUiKSRj b2wsIA0KICAgICAgICBsZW5ndGggPSBudW1iZXIub2YuY29uZCkNCiAgICBj b25kLm1heC5sZXZlbCA8LSBpbnRlZ2VyKG51bWJlci5vZi5jb25kKQ0KICAg IGZvciAoaSBpbiAxOm51bWJlci5vZi5jb25kKSB7DQogICAgICAgIGNvbmQu bWF4LmxldmVsW2ldIDwtIGxlbmd0aCh4JGNvbmRsZXZlbHNbW2ldXSkNCiAg ICB9DQogICAgaWYgKHgkbGF5b3V0WzFdID09IDApIHsNCiAgICAgICAgZGRp bSA8LSBwYXIoImRpbiIpDQogICAgICAgIGRldmljZS5hc3BlY3QgPC0gZGRp bVsyXS9kZGltWzFdDQogICAgICAgIHBhbmVsLmFzcGVjdCA8LSBwYW5lbC5o ZWlnaHRbWzFdXS9wYW5lbC53aWR0aFtbMV1dDQogICAgICAgIHBsb3RzLnBl ci5wYWdlIDwtIHgkbGF5b3V0WzJdDQogICAgICAgIG0gPC0gbWF4KDEsIHJv dW5kKHNxcnQoeCRsYXlvdXRbMl0gKiBkZXZpY2UuYXNwZWN0L3BhbmVsLmFz cGVjdCkpKQ0KICAgICAgICBuIDwtIGNlaWxpbmcocGxvdHMucGVyLnBhZ2Uv bSkNCiAgICAgICAgbSA8LSBjZWlsaW5nKHBsb3RzLnBlci5wYWdlL24pDQog ICAgICAgIHgkbGF5b3V0WzFdIDwtIG4NCiAgICAgICAgeCRsYXlvdXRbMl0g PC0gbQ0KICAgIH0NCiAgICBlbHNlIHBsb3RzLnBlci5wYWdlIDwtIHgkbGF5 b3V0WzFdICogeCRsYXlvdXRbMl0NCiAgICBjb2xzLnBlci5wYWdlIDwtIHgk bGF5b3V0WzFdDQogICAgcm93cy5wZXIucGFnZSA8LSB4JGxheW91dFsyXQ0K ICAgIG51bWJlci5vZi5wYWdlcyA8LSB4JGxheW91dFszXQ0KICAgIGlmIChj b2xzLnBlci5wYWdlID4gMSkgDQogICAgICAgIHguYmV0d2VlbiA8LSByZXAo eCR4LmJldHdlZW4sIGxlbmd0aCA9IGNvbHMucGVyLnBhZ2UgLSANCiAgICAg ICAgICAgIDEpDQogICAgaWYgKHJvd3MucGVyLnBhZ2UgPiAxKSANCiAgICAg ICAgeS5iZXR3ZWVuIDwtIHJlcCh4JHkuYmV0d2VlbiwgbGVuZ3RoID0gcm93 cy5wZXIucGFnZSAtIA0KICAgICAgICAgICAgMSkNCiAgICB4LmFsdGVybmF0 aW5nIDwtIHJlcCh4JHguc2NhbGVzJGFsdGVybmF0aW5nLCBsZW5ndGggPSBj b2xzLnBlci5wYWdlKQ0KICAgIHkuYWx0ZXJuYXRpbmcgPC0gcmVwKHgkeS5z Y2FsZXMkYWx0ZXJuYXRpbmcsIGxlbmd0aCA9IHJvd3MucGVyLnBhZ2UpDQog ICAgeC5yZWxhdGlvbi5zYW1lIDwtIHgkeC5zY2FsZXMkcmVsYXRpb24gPT0g InNhbWUiDQogICAgeS5yZWxhdGlvbi5zYW1lIDwtIHgkeS5zY2FsZXMkcmVs YXRpb24gPT0gInNhbWUiDQogICAgeGxvZyA8LSB4JHguc2NhbGVzJGxvZw0K ICAgIHlsb2cgPC0geCR5LnNjYWxlcyRsb2cNCiAgICBpZiAoaXMubG9naWNh bCh4bG9nKSAmJiB4bG9nKSANCiAgICAgICAgeGxvZyA8LSAxMA0KICAgIGlm IChpcy5sb2dpY2FsKHlsb2cpICYmIHlsb2cpIA0KICAgICAgICB5bG9nIDwt IDEwDQogICAgaGF2ZS54bG9nIDwtICFpcy5sb2dpY2FsKHhsb2cpIHx8IHhs b2cNCiAgICBoYXZlLnlsb2cgPC0gIWlzLmxvZ2ljYWwoeWxvZykgfHwgeWxv Zw0KICAgIHhsb2diYXNlIDwtIGlmIChpcy5udW1lcmljKHhsb2cpKSANCiAg ICAgICAgeGxvZw0KICAgIGVsc2UgZXhwKDEpDQogICAgeWxvZ2Jhc2UgPC0g aWYgKGlzLm51bWVyaWMoeWxvZykpIA0KICAgICAgICB5bG9nDQogICAgZWxz ZSBleHAoMSkNCiAgICB4bG9ncGFzdGUgPC0gaWYgKGhhdmUueGxvZykgDQog ICAgICAgIHBhc3RlKGFzLmNoYXJhY3Rlcih4bG9nKSwgIl4iLCBzZXAgPSAi IikNCiAgICBlbHNlICIiDQogICAgeWxvZ3Bhc3RlIDwtIGlmIChoYXZlLnls b2cpIA0KICAgICAgICBwYXN0ZShhcy5jaGFyYWN0ZXIoeWxvZyksICJeIiwg c2VwID0gIiIpDQogICAgZWxzZSAiIg0KICAgIGhhdmUubWFpbiA8LSAhKGlz Lm51bGwoeCRtYWluJGxhYmVsKSB8fCAoaXMuY2hhcmFjdGVyKHgkbWFpbiRs YWJlbCkgJiYgDQogICAgICAgIHgkbWFpbiRsYWJlbCA9PSAiIikpDQogICAg aGF2ZS5zdWIgPC0gIShpcy5udWxsKHgkc3ViJGxhYmVsKSB8fCAoaXMuY2hh cmFjdGVyKHgkc3ViJGxhYmVsKSAmJiANCiAgICAgICAgeCRzdWIkbGFiZWwg PT0gIiIpKQ0KICAgIGhhdmUueGxhYiA8LSAhKGlzLm51bGwoeCR4bGFiJGxh YmVsKSB8fCAoaXMuY2hhcmFjdGVyKHgkeGxhYiRsYWJlbCkgJiYgDQogICAg ICAgIHgkeGxhYiRsYWJlbCA9PSAiIikpDQogICAgaGF2ZS55bGFiIDwtICEo aXMubnVsbCh4JHlsYWIkbGFiZWwpIHx8IChpcy5jaGFyYWN0ZXIoeCR5bGFi JGxhYmVsKSAmJiANCiAgICAgICAgeCR5bGFiJGxhYmVsID09ICIiKSkNCiAg ICBuLnJvdyA8LSByb3dzLnBlci5wYWdlICogKG51bWJlci5vZi5jb25kICsg MykgKyAocm93cy5wZXIucGFnZSAtIA0KICAgICAgICAxKSArIDExDQogICAg bi5jb2wgPC0gMyAqIGNvbHMucGVyLnBhZ2UgKyAoY29scy5wZXIucGFnZSAt IDEpICsgOQ0KICAgIGlmIChsYXlvdXQucmVzcGVjdCkgew0KICAgICAgICBs YXlvdXQucmVzcGVjdCA8LSBtYXRyaXgoMCwgbi5yb3csIG4uY29sKQ0KICAg ICAgICBsYXlvdXQucmVzcGVjdFtudW1iZXIub2YuY29uZCArIDYgKyAoMTpy b3dzLnBlci5wYWdlIC0gDQogICAgICAgICAgICAxKSAqIChudW1iZXIub2Yu Y29uZCArIDQpLCAoMTpjb2xzLnBlci5wYWdlIC0gMSkgKiANCiAgICAgICAg ICAgIDQgKyA4XSA8LSAxDQogICAgfQ0KICAgIGhlaWdodHMueCA8LSByZXAo MSwgbi5yb3cpDQogICAgaGVpZ2h0cy51bml0cyA8LSByZXAoImxpbmVzIiwg bi5yb3cpDQogICAgaGVpZ2h0cy5kYXRhIDwtIGFzLmxpc3QoMTpuLnJvdykN CiAgICB3aWR0aHMueCA8LSByZXAoMSwgbi5jb2wpDQogICAgd2lkdGhzLnVu aXRzIDwtIHJlcCgibGluZXMiLCBuLmNvbCkNCiAgICB3aWR0aHMuZGF0YSA8 LSBhcy5saXN0KDE6bi5jb2wpDQogICAgaGVpZ2h0cy54W251bWJlci5vZi5j b25kICsgNiArICgxOnJvd3MucGVyLnBhZ2UgLSAxKSAqIChudW1iZXIub2Yu Y29uZCArIA0KICAgICAgICA0KV0gPC0gcGFuZWwuaGVpZ2h0W1sxXV0NCiAg ICBoZWlnaHRzLnVuaXRzW251bWJlci5vZi5jb25kICsgNiArICgxOnJvd3Mu cGVyLnBhZ2UgLSAxKSAqIA0KICAgICAgICAobnVtYmVyLm9mLmNvbmQgKyA0 KV0gPC0gcGFuZWwuaGVpZ2h0W1syXV0NCiAgICBoZWlnaHRzLnhbbnVtYmVy Lm9mLmNvbmQgKyA3ICsgKDE6cm93cy5wZXIucGFnZSAtIDEpICogKG51bWJl ci5vZi5jb25kICsgDQogICAgICAgIDQpXSA8LSAwDQogICAgaGVpZ2h0cy54 W251bWJlci5vZi5jb25kICsgOCArICgxOnJvd3MucGVyLnBhZ2UgLSAxKSAq IChudW1iZXIub2YuY29uZCArIA0KICAgICAgICA0KV0gPC0gMA0KICAgIGhl aWdodHMueFs0XSA8LSAwDQogICAgaGVpZ2h0cy54WzVdIDwtIDANCiAgICBo ZWlnaHRzLnhbbi5yb3cgLSA0XSA8LSAwDQogICAgaGVpZ2h0cy54W24ucm93 IC0gNV0gPC0gMA0KICAgIGlmIChyb3dzLnBlci5wYWdlID4gMSkgDQogICAg ICAgIGhlaWdodHMueFtudW1iZXIub2YuY29uZCArIDkgKyAoKGlmICh4JGFz LnRhYmxlKSANCiAgICAgICAgICAgIDE6KHJvd3MucGVyLnBhZ2UgLSAxKQ0K ICAgICAgICBlbHNlIChyb3dzLnBlci5wYWdlIC0gMSk6MSkgLSAxKSAqIChu dW1iZXIub2YuY29uZCArIA0KICAgICAgICAgICAgNCldIDwtIHkuYmV0d2Vl bg0KICAgIGhlaWdodHMueFsxXSA8LSAwLjUNCiAgICBoZWlnaHRzLnhbMl0g PC0gaWYgKGhhdmUubWFpbikgDQogICAgICAgIDIgKiB4JG1haW4kY2V4DQog ICAgZWxzZSAwDQogICAgaWYgKGhhdmUubWFpbikgew0KICAgICAgICBoZWln aHRzLnVuaXRzWzJdIDwtICJzdHJoZWlnaHQiDQogICAgICAgIGhlaWdodHMu ZGF0YVtbMl1dIDwtIHgkbWFpbiRsYWINCiAgICB9DQogICAgaGVpZ2h0cy54 W24ucm93XSA8LSAwLjUNCiAgICBoZWlnaHRzLnhbbi5yb3cgLSAxXSA8LSBp ZiAoaGF2ZS5zdWIpIA0KICAgICAgICAyICogeCRzdWIkY2V4DQogICAgZWxz ZSAwDQogICAgaWYgKGhhdmUuc3ViKSB7DQogICAgICAgIGhlaWdodHMudW5p dHNbbi5yb3cgLSAxXSA8LSAic3RyaGVpZ2h0Ig0KICAgICAgICBoZWlnaHRz LmRhdGFbW24ucm93IC0gMV1dIDwtIHgkc3ViJGxhYg0KICAgIH0NCiAgICBo ZWlnaHRzLnhbM10gPC0gMA0KICAgIGhlaWdodHMueFtuLnJvdyAtIDJdIDwt IDANCiAgICBoZWlnaHRzLmluc2VydGxpc3QucG9zaXRpb24gPC0gMA0KICAg IGhlaWdodHMuaW5zZXJ0bGlzdC51bml0IDwtIHVuaXQoMSwgIm51bGwiKQ0K ICAgIGlmICh4JHguc2NhbGVzJGRyYXcpIHsNCiAgICAgICAgaWYgKHgucmVs YXRpb24uc2FtZSkgew0KICAgICAgICAgICAgbGFiIDwtIGNhbGN1bGF0ZUF4 aXNDb21wb25lbnRzKHggPSB4JHgubGltaXRzLCBhdCA9IHgkeC5zY2FsZXMk YXQsIA0KICAgICAgICAgICAgICAgIGxhYmVscyA9IHgkeC5zY2FsZXMkbGFi LCBoYXZlLmxvZyA9IGhhdmUueGxvZywgDQogICAgICAgICAgICAgICAgbG9n YmFzZSA9IHhsb2diYXNlLCBsb2dwYXN0ZSA9IHhsb2dwYXN0ZSwgYWJicmV2 aWF0ZSA9IHgkeC5zY2FsZXMkYWJiciwgDQogICAgICAgICAgICAgICAgbWlu bGVuZ3RoID0geCR4LnNjYWxlcyRtaW5sLCBuID0geCR4LnNjYWxlcyR0aWNr Lm51bWJlcikkbGFiDQojIyAgICAgICAgICBpZiAoaXMuY2hhcmFjdGVyKGxh YikpIA0KICAgICAgICAgICAgaWYgKGFsbChzYXBwbHkobGFiLCBpcy5jaGFy YWN0ZXIpKSkgICMjIHJtaA0KICAgICAgICAgICAgICAgIHN0cmJhciA8LSBh cy5saXN0KGxhYikNCiAgICAgICAgICAgIGVsc2UgaWYgKGlzLmV4cHJlc3Np b24obGFiKSkgew0KICAgICAgICAgICAgICAgIHN0cmJhciA8LSBsaXN0KCkN CiAgICAgICAgICAgICAgICBmb3IgKHNzIGluIHNlcShhbG9uZyA9IGxhYikp IHN0cmJhciA8LSBjKHN0cmJhciwgDQogICAgICAgICAgICAgICAgICBsaXN0 KGxhYltzc10pKQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgZWxzZSBz dG9wKCJJbnZhbGlkIHZhbHVlIGZvciBsYWJlbHMiKQ0KICAgICAgICAgICAg aGVpZ2h0cy54WzVdIDwtIDAuNSArIG1heCgwLjAwMSwgeCR4LnNjYWxlcyR0 Y2tbMl0pICogDQogICAgICAgICAgICAgICAgMC4zDQogICAgICAgICAgICBo ZWlnaHRzLnhbbi5yb3cgLSA1XSA8LSAwLjUgKyBtYXgoMC4wMDEsIHgkeC5z Y2FsZXMkdGNrWzFdKSAqIA0KICAgICAgICAgICAgICAgIDAuMw0KICAgICAg ICAgICAgaWYgKGFueSh4LmFsdGVybmF0aW5nID09IDIgfCB4LmFsdGVybmF0 aW5nID09IDMpKSB7DQogICAgICAgICAgICAgICAgaWYgKHhheGlzLnJvdFsy XSAlaW4lIGMoMCwgMTgwKSkgew0KICAgICAgICAgICAgICAgICAgaGVpZ2h0 cy5pbnNlcnRsaXN0LnBvc2l0aW9uIDwtIGMoaGVpZ2h0cy5pbnNlcnRsaXN0 LnBvc2l0aW9uLCANCiAgICAgICAgICAgICAgICAgICAgNCkNCiAgICAgICAg ICAgICAgICAgIGhlaWdodHMuaW5zZXJ0bGlzdC51bml0IDwtIHVuaXQuYyho ZWlnaHRzLmluc2VydGxpc3QudW5pdCwgDQogICAgICAgICAgICAgICAgICAg IG1heCh1bml0KHJlcCgxICogeGF4aXMuY2V4WzJdLCBsZW5ndGgoc3RyYmFy KSksIA0KICAgICAgICAgICAgICAgICAgICAgICJzdHJoZWlnaHQiLCBzdHJi YXIpKSkNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgZWxz ZSB7DQogICAgICAgICAgICAgICAgICBoZWlnaHRzLmluc2VydGxpc3QucG9z aXRpb24gPC0gYyhoZWlnaHRzLmluc2VydGxpc3QucG9zaXRpb24sIA0KICAg ICAgICAgICAgICAgICAgICA0KQ0KICAgICAgICAgICAgICAgICAgaGVpZ2h0 cy5pbnNlcnRsaXN0LnVuaXQgPC0gdW5pdC5jKGhlaWdodHMuaW5zZXJ0bGlz dC51bml0LCANCiAgICAgICAgICAgICAgICAgICAgbWF4KHVuaXQocmVwKDEg KiB4YXhpcy5jZXhbMl0gKiBhYnMoc2luKHhheGlzLnJvdFsyXSAqIA0KICAg ICAgICAgICAgICAgICAgICAgIGJhc2U6OnBpLzE4MCkpLCBsZW5ndGgoc3Ry YmFyKSksICJzdHJ3aWR0aCIsIA0KICAgICAgICAgICAgICAgICAgICAgIHN0 cmJhcikpKQ0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAg ICAgICAgICAgIGlmIChhbnkoeC5hbHRlcm5hdGluZyA9PSAxIHwgeC5hbHRl cm5hdGluZyA9PSAzKSkgew0KICAgICAgICAgICAgICAgIGlmICh4YXhpcy5y b3RbMV0gJWluJSBjKDAsIDE4MCkpIHsNCiAgICAgICAgICAgICAgICAgIGhl aWdodHMuaW5zZXJ0bGlzdC5wb3NpdGlvbiA8LSBjKGhlaWdodHMuaW5zZXJ0 bGlzdC5wb3NpdGlvbiwgDQogICAgICAgICAgICAgICAgICAgIG4ucm93IC0g NCkNCiAgICAgICAgICAgICAgICAgIGhlaWdodHMuaW5zZXJ0bGlzdC51bml0 IDwtIHVuaXQuYyhoZWlnaHRzLmluc2VydGxpc3QudW5pdCwgDQogICAgICAg ICAgICAgICAgICAgIG1heCh1bml0KHJlcCgxICogeGF4aXMuY2V4WzFdLCBs ZW5ndGgoc3RyYmFyKSksIA0KICAgICAgICAgICAgICAgICAgICAgICJzdHJo ZWlnaHQiLCBzdHJiYXIpKSkNCiAgICAgICAgICAgICAgICB9DQogICAgICAg ICAgICAgICAgZWxzZSB7DQogICAgICAgICAgICAgICAgICBoZWlnaHRzLmlu c2VydGxpc3QucG9zaXRpb24gPC0gYyhoZWlnaHRzLmluc2VydGxpc3QucG9z aXRpb24sIA0KICAgICAgICAgICAgICAgICAgICBuLnJvdyAtIDQpDQogICAg ICAgICAgICAgICAgICBoZWlnaHRzLmluc2VydGxpc3QudW5pdCA8LSB1bml0 LmMoaGVpZ2h0cy5pbnNlcnRsaXN0LnVuaXQsIA0KICAgICAgICAgICAgICAg ICAgICBtYXgodW5pdChyZXAoMSAqIHhheGlzLmNleFsxXSAqIGFicyhzaW4o eGF4aXMucm90WzFdICogDQogICAgICAgICAgICAgICAgICAgICAgYmFzZTo6 cGkvMTgwKSksIGxlbmd0aChzdHJiYXIpKSwgInN0cndpZHRoIiwgDQogICAg ICAgICAgICAgICAgICAgICAgc3RyYmFyKSkpDQogICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgfQ0KICAgICAgICB9DQogICAgICAgIGVsc2Ugew0K ICAgICAgICAgICAgbGFiZWxDaGFycyA8LSBjaGFyYWN0ZXIoMCkNCiAgICAg ICAgICAgIGxhYmVsRXhwcnMgPC0gZXhwcmVzc2lvbigwKQ0KICAgICAgICAg ICAgZm9yIChpIGluIHNlcShhbG9uZyA9IHgkeC5saW1pdHMpKSB7DQogICAg ICAgICAgICAgICAgbGFiIDwtIGNhbGN1bGF0ZUF4aXNDb21wb25lbnRzKHgg PSB4JHgubGltaXRzW1tpXV0sIA0KICAgICAgICAgICAgICAgICAgYXQgPSBp ZiAoaXMubGlzdCh4JHguc2NhbGVzJGF0KSkgDQogICAgICAgICAgICAgICAg ICAgIHgkeC5zY2FsZXMkYXRbW2ldXQ0KICAgICAgICAgICAgICAgICAgZWxz ZSB4JHguc2NhbGVzJGF0LCBsYWJlbHMgPSBpZiAoaXMubGlzdCh4JHguc2Nh bGVzJGxhYikpIA0KICAgICAgICAgICAgICAgICAgICB4JHguc2NhbGVzJGxh YltbaV1dDQogICAgICAgICAgICAgICAgICBlbHNlIHgkeC5zY2FsZXMkbGFi LCBoYXZlLmxvZyA9IGhhdmUueGxvZywgDQogICAgICAgICAgICAgICAgICBs b2diYXNlID0geGxvZ2Jhc2UsIGxvZ3Bhc3RlID0geGxvZ3Bhc3RlLCBhYmJy ZXZpYXRlID0geCR4LnNjYWxlcyRhYmJyLCANCiAgICAgICAgICAgICAgICAg IG1pbmxlbmd0aCA9IHgkeC5zY2FsZXMkbWlubCwgbiA9IHgkeC5zY2FsZXMk dGljay5udW1iZXIpJGxhYg0KICAgICAgICAgICAgICAgIGlmIChpcy5jaGFy YWN0ZXIobGFiKSkgDQogICAgICAgICAgICAgICAgICBsYWJlbENoYXJzIDwt IGMobGFiZWxDaGFycywgbGFiKQ0KICAgICAgICAgICAgICAgIGVsc2UgaWYg KGlzLmV4cHJlc3Npb24obGFiKSkgDQogICAgICAgICAgICAgICAgICBsYWJl bEV4cHJzIDwtIGMobGFiZWxFeHBycywgbGFiKQ0KICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgbGFiZWxDaGFycyA8LSB1bmlxdWUobGFiZWxDaGFycykN CiAgICAgICAgICAgIHN0cmJhciA8LSBsaXN0KCkNCiAgICAgICAgICAgIGZv ciAoc3MgaW4gbGFiZWxDaGFycykgc3RyYmFyIDwtIGMoc3RyYmFyLCBsaXN0 KHNzKSkNCiAgICAgICAgICAgIGZvciAoc3MgaW4gc2VxKGFsb25nID0gbGFi ZWxFeHBycykpIHN0cmJhciA8LSBjKHN0cmJhciwgDQogICAgICAgICAgICAg ICAgbGlzdChsYWJlbEV4cHJzW3NzXSkpDQogICAgICAgICAgICBpZiAoeGF4 aXMucm90WzFdICVpbiUgYygwLCAxODApKSB7DQogICAgICAgICAgICAgICAg aGVpZ2h0cy54W251bWJlci5vZi5jb25kICsgNyArICgxOnJvd3MucGVyLnBh Z2UgLSANCiAgICAgICAgICAgICAgICAgIDEpICogKG51bWJlci5vZi5jb25k ICsgNCldIDwtIG1heCgwLjAwMSwgeCR4LnNjYWxlcyR0Y2tbMV0pICogDQog ICAgICAgICAgICAgICAgICAwLjMNCiAgICAgICAgICAgICAgICBoZWlnaHRz Lmluc2VydGxpc3QucG9zaXRpb24gPC0gYyhoZWlnaHRzLmluc2VydGxpc3Qu cG9zaXRpb24sIA0KICAgICAgICAgICAgICAgICAgbnVtYmVyLm9mLmNvbmQg KyA4ICsgKDE6cm93cy5wZXIucGFnZSAtIDEpICogDQogICAgICAgICAgICAg ICAgICAgIChudW1iZXIub2YuY29uZCArIDQpKQ0KICAgICAgICAgICAgICAg IGZvciAoaSBpbiAxOnJvd3MucGVyLnBhZ2UpIGhlaWdodHMuaW5zZXJ0bGlz dC51bml0IDwtIHVuaXQuYyhoZWlnaHRzLmluc2VydGxpc3QudW5pdCwgDQog ICAgICAgICAgICAgICAgICBtYXgodW5pdChyZXAoMS41ICogeGF4aXMuY2V4 WzFdLCBsZW5ndGgoc3RyYmFyKSksIA0KICAgICAgICAgICAgICAgICAgICAi c3RyaGVpZ2h0Iiwgc3RyYmFyKSkpDQogICAgICAgICAgICB9DQogICAgICAg ICAgICBlbHNlIHsNCiAgICAgICAgICAgICAgICBoZWlnaHRzLnhbbnVtYmVy Lm9mLmNvbmQgKyA3ICsgKDE6cm93cy5wZXIucGFnZSAtIA0KICAgICAgICAg ICAgICAgICAgMSkgKiAobnVtYmVyLm9mLmNvbmQgKyA0KV0gPC0gbWF4KDAu MDAxLCB4JHguc2NhbGVzJHRja1sxXSkgKiANCiAgICAgICAgICAgICAgICAg IDAuMw0KICAgICAgICAgICAgICAgIGhlaWdodHMuaW5zZXJ0bGlzdC5wb3Np dGlvbiA8LSBjKGhlaWdodHMuaW5zZXJ0bGlzdC5wb3NpdGlvbiwgDQogICAg ICAgICAgICAgICAgICBudW1iZXIub2YuY29uZCArIDggKyAoMTpyb3dzLnBl ci5wYWdlIC0gMSkgKiANCiAgICAgICAgICAgICAgICAgICAgKG51bWJlci5v Zi5jb25kICsgNCkpDQogICAgICAgICAgICAgICAgZm9yIChpIGluIDE6cm93 cy5wZXIucGFnZSkgaGVpZ2h0cy5pbnNlcnRsaXN0LnVuaXQgPC0gdW5pdC5j KGhlaWdodHMuaW5zZXJ0bGlzdC51bml0LCANCiAgICAgICAgICAgICAgICAg IG1heCh1bml0KHJlcCgxLjUgKiB4YXhpcy5jZXhbMV0gKiBhYnMoc2luKHhh eGlzLnJvdFsxXSAqIA0KICAgICAgICAgICAgICAgICAgICBiYXNlOjpwaS8x ODApKSwgbGVuZ3RoKHN0cmJhcikpLCAic3Ryd2lkdGgiLCANCiAgICAgICAg ICAgICAgICAgICAgc3RyYmFyKSkpDQogICAgICAgICAgICB9DQogICAgICAg IH0NCiAgICB9DQogICAgaGVpZ2h0cy54W24ucm93IC0gM10gPC0gaWYgKGhh dmUueGxhYikgDQogICAgICAgIDIgKiB4JHhsYWIkY2V4DQogICAgZWxzZSAw DQogICAgaWYgKGhhdmUueGxhYikgew0KICAgICAgICBoZWlnaHRzLnVuaXRz W24ucm93IC0gM10gPC0gInN0cmhlaWdodCINCiAgICAgICAgaGVpZ2h0cy5k YXRhW1tuLnJvdyAtIDNdXSA8LSB4JHhsYWIkbGFiDQogICAgfQ0KICAgIGZv ciAoY3JyIGluIDE6bnVtYmVyLm9mLmNvbmQpIGhlaWdodHMueFtudW1iZXIu b2YuY29uZCArIA0KICAgICAgICA2ICsgKDE6cm93cy5wZXIucGFnZSAtIDEp ICogKG51bWJlci5vZi5jb25kICsgNCkgLSBjcnJdIDwtIGlmIChpcy5sb2dp Y2FsKHgkc3RyaXApKSANCiAgICAgICAgMA0KICAgIGVsc2UgMS4xICogeCRw YXIuc3RyaXAudGV4dCRjZXggKiB4JHBhci5zdHJpcC50ZXh0JGxpbmVzDQog ICAgd2lkdGhzLnhbM10gPC0gaWYgKGhhdmUueWxhYikgDQogICAgICAgIDIg KiB4JHlsYWIkY2V4DQogICAgZWxzZSAwDQogICAgaWYgKGhhdmUueWxhYikg ew0KICAgICAgICB3aWR0aHMudW5pdHNbM10gPC0gInN0cmhlaWdodCINCiAg ICAgICAgd2lkdGhzLmRhdGFbWzNdXSA8LSB4JHlsYWIkbGFiDQogICAgfQ0K ICAgIHdpZHRocy54WygxOmNvbHMucGVyLnBhZ2UgLSAxKSAqIDQgKyA4XSA8 LSBwYW5lbC53aWR0aFtbMV1dDQogICAgd2lkdGhzLnVuaXRzWygxOmNvbHMu cGVyLnBhZ2UgLSAxKSAqIDQgKyA4XSA8LSBwYW5lbC53aWR0aFtbMl1dDQog ICAgd2lkdGhzLnhbKDE6Y29scy5wZXIucGFnZSAtIDEpICogNCArIDddIDwt IDANCiAgICB3aWR0aHMueFsoMTpjb2xzLnBlci5wYWdlIC0gMSkgKiA0ICsg Nl0gPC0gMA0KICAgIHdpZHRocy54WzRdIDwtIDANCiAgICB3aWR0aHMueFs1 XSA8LSAwDQogICAgd2lkdGhzLnhbbi5jb2wgLSAyXSA8LSAwDQogICAgd2lk dGhzLnhbbi5jb2wgLSAzXSA8LSAwDQogICAgaWYgKGNvbHMucGVyLnBhZ2Ug PiAxKSANCiAgICAgICAgd2lkdGhzLnhbKDE6KGNvbHMucGVyLnBhZ2UgLSAx KSAtIDEpICogNCArIDldIDwtIHguYmV0d2Vlbg0KICAgIHdpZHRocy54WzFd IDwtIDAuNQ0KICAgIHdpZHRocy54W24uY29sXSA8LSAwLjUNCiAgICB3aWR0 aHMueFsyXSA8LSAwDQogICAgd2lkdGhzLnhbbi5jb2wgLSAxXSA8LSAwDQog ICAgd2lkdGhzLmluc2VydGxpc3QucG9zaXRpb24gPC0gMA0KICAgIHdpZHRo cy5pbnNlcnRsaXN0LnVuaXQgPC0gdW5pdCgxLCAibnVsbCIpDQogICAgaWYg KHgkeS5zY2FsZXMkZHJhdykgew0KICAgICAgICBpZiAoeS5yZWxhdGlvbi5z YW1lKSB7DQogICAgICAgICAgICBsYWIgPC0gY2FsY3VsYXRlQXhpc0NvbXBv bmVudHMoeCA9IHgkeS5saW1pdHMsIGF0ID0geCR5LnNjYWxlcyRhdCwgDQog ICAgICAgICAgICAgICAgbGFiZWxzID0geCR5LnNjYWxlcyRsYWIsIGhhdmUu bG9nID0gaGF2ZS55bG9nLCANCiAgICAgICAgICAgICAgICBsb2diYXNlID0g eWxvZ2Jhc2UsIGxvZ3Bhc3RlID0geWxvZ3Bhc3RlLCBhYmJyZXZpYXRlID0g eCR5LnNjYWxlcyRhYmJyLCANCiAgICAgICAgICAgICAgICBtaW5sZW5ndGgg PSB4JHkuc2NhbGVzJG1pbmwsIG4gPSB4JHkuc2NhbGVzJHRpY2subnVtYmVy KSRsYWINCiMjICAgICAgICAgIGlmIChpcy5jaGFyYWN0ZXIobGFiKSkgDQog ICAgICAgICAgICBpZiAoYWxsKHNhcHBseShsYWIsIGlzLmNoYXJhY3Rlcikp KSAgIyMgcm1oDQogICAgICAgICAgICAgICAgc3RyYmFyIDwtIGFzLmxpc3Qo bGFiKQ0KICAgICAgICAgICAgZWxzZSBpZiAoaXMuZXhwcmVzc2lvbihsYWIp KSB7DQogICAgICAgICAgICAgICAgc3RyYmFyIDwtIGxpc3QoKQ0KICAgICAg ICAgICAgICAgIGZvciAoc3MgaW4gc2VxKGFsb25nID0gbGFiKSkgc3RyYmFy IDwtIGMoc3RyYmFyLCANCiAgICAgICAgICAgICAgICAgIGxpc3QobGFiW3Nz XSkpDQogICAgICAgICAgICB9DQogICAgICAgICAgICBlbHNlIHN0b3AoIklu dmFsaWQgdmFsdWUgZm9yIGxhYmVscyIpDQogICAgICAgICAgICB3aWR0aHMu eFs1XSA8LSAwLjUgKyBtYXgoMC4wMDEsIHgkeS5zY2FsZXMkdGNrWzFdKSAq IA0KICAgICAgICAgICAgICAgIDAuMw0KICAgICAgICAgICAgd2lkdGhzLnhb bi5jb2wgLSAzXSA8LSBtYXgoMSwgeCR5LnNjYWxlcyR0Y2tbMl0pICogDQog ICAgICAgICAgICAgICAgMC41DQogICAgICAgICAgICBpZiAoYW55KHkuYWx0 ZXJuYXRpbmcgPT0gMSB8IHkuYWx0ZXJuYXRpbmcgPT0gMykpIHsNCiAgICAg ICAgICAgICAgICBpZiAoYWJzKHlheGlzLnJvdFsxXSkgPT0gOTApIHsNCiAg ICAgICAgICAgICAgICAgIHdpZHRocy5pbnNlcnRsaXN0LnBvc2l0aW9uIDwt IGMod2lkdGhzLmluc2VydGxpc3QucG9zaXRpb24sIA0KICAgICAgICAgICAg ICAgICAgICA0KQ0KICAgICAgICAgICAgICAgICAgd2lkdGhzLmluc2VydGxp c3QudW5pdCA8LSB1bml0LmMod2lkdGhzLmluc2VydGxpc3QudW5pdCwgDQog ICAgICAgICAgICAgICAgICAgIG1heCh1bml0KDEgKiByZXAoeWF4aXMuY2V4 WzFdLCBsZW5ndGgoc3RyYmFyKSksIA0KICAgICAgICAgICAgICAgICAgICAg ICJzdHJoZWlnaHQiLCBkYXRhID0gc3RyYmFyKSkpDQogICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgIGVsc2Ugew0KICAgICAgICAgICAgICAg ICAgd2lkdGhzLmluc2VydGxpc3QucG9zaXRpb24gPC0gYyh3aWR0aHMuaW5z ZXJ0bGlzdC5wb3NpdGlvbiwgDQogICAgICAgICAgICAgICAgICAgIDQpDQog ICAgICAgICAgICAgICAgICB3aWR0aHMuaW5zZXJ0bGlzdC51bml0IDwtIHVu aXQuYyh3aWR0aHMuaW5zZXJ0bGlzdC51bml0LCANCiAgICAgICAgICAgICAg ICAgICAgbWF4KHVuaXQocmVwKDEgKiB5YXhpcy5jZXhbMV0gKiBhYnMoY29z KHlheGlzLnJvdFsxXSAqIA0KICAgICAgICAgICAgICAgICAgICAgIGJhc2U6 OnBpLzE4MCkpLCBsZW5ndGgoc3RyYmFyKSksICJzdHJ3aWR0aCIsIA0KICAg ICAgICAgICAgICAgICAgICAgIHN0cmJhcikpKQ0KICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGlmIChhbnkoeS5hbHRl cm5hdGluZyA9PSAyIHwgeS5hbHRlcm5hdGluZyA9PSAzKSkgew0KICAgICAg ICAgICAgICAgIGlmIChhYnMoeWF4aXMucm90WzJdKSA9PSA5MCkgew0KICAg ICAgICAgICAgICAgICAgd2lkdGhzLmluc2VydGxpc3QucG9zaXRpb24gPC0g Yyh3aWR0aHMuaW5zZXJ0bGlzdC5wb3NpdGlvbiwgDQogICAgICAgICAgICAg ICAgICAgIG4uY29sIC0gMikNCiAgICAgICAgICAgICAgICAgIHdpZHRocy5p bnNlcnRsaXN0LnVuaXQgPC0gdW5pdC5jKHdpZHRocy5pbnNlcnRsaXN0LnVu aXQsIA0KICAgICAgICAgICAgICAgICAgICBtYXgodW5pdChyZXAoMSAqIHlh eGlzLmNleFsyXSwgbGVuZ3RoKHN0cmJhcikpLCANCiAgICAgICAgICAgICAg ICAgICAgICAic3RyaGVpZ2h0Iiwgc3RyYmFyKSkpDQogICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgIGVsc2Ugew0KICAgICAgICAgICAgICAg ICAgd2lkdGhzLmluc2VydGxpc3QucG9zaXRpb24gPC0gYyh3aWR0aHMuaW5z ZXJ0bGlzdC5wb3NpdGlvbiwgDQogICAgICAgICAgICAgICAgICAgIG4uY29s IC0gMikNCiAgICAgICAgICAgICAgICAgIHdpZHRocy5pbnNlcnRsaXN0LnVu aXQgPC0gdW5pdC5jKHdpZHRocy5pbnNlcnRsaXN0LnVuaXQsIA0KICAgICAg ICAgICAgICAgICAgICBtYXgodW5pdChyZXAoMSAqIHlheGlzLmNleFsyXSAq IGFicyhjb3MoeWF4aXMucm90WzJdICogDQogICAgICAgICAgICAgICAgICAg ICAgYmFzZTo6cGkvMTgwKSksIGxlbmd0aChzdHJiYXIpKSwgInN0cndpZHRo IiwgDQogICAgICAgICAgICAgICAgICAgICAgc3RyYmFyKSkpDQogICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICB9DQogICAgICAg IGVsc2Ugew0KICAgICAgICAgICAgbGFiZWxDaGFycyA8LSBjaGFyYWN0ZXIo MCkNCiAgICAgICAgICAgIGxhYmVsRXhwcnMgPC0gZXhwcmVzc2lvbigwKQ0K ICAgICAgICAgICAgZm9yIChpIGluIHNlcShhbG9uZyA9IHgkeS5saW1pdHMp KSB7DQogICAgICAgICAgICAgICAgbGFiIDwtIGNhbGN1bGF0ZUF4aXNDb21w b25lbnRzKHggPSB4JHkubGltaXRzW1tpXV0sIA0KICAgICAgICAgICAgICAg ICAgYXQgPSBpZiAoaXMubGlzdCh4JHkuc2NhbGVzJGF0KSkgDQogICAgICAg ICAgICAgICAgICAgIHgkeS5zY2FsZXMkYXRbW2ldXQ0KICAgICAgICAgICAg ICAgICAgZWxzZSB4JHkuc2NhbGVzJGF0LCBsYWJlbHMgPSBpZiAoaXMubGlz dCh4JHkuc2NhbGVzJGxhYikpIA0KICAgICAgICAgICAgICAgICAgICB4JHku c2NhbGVzJGxhYltbaV1dDQogICAgICAgICAgICAgICAgICBlbHNlIHgkeS5z Y2FsZXMkbGFiLCBoYXZlLmxvZyA9IGhhdmUueWxvZywgDQogICAgICAgICAg ICAgICAgICBsb2diYXNlID0geWxvZ2Jhc2UsIGxvZ3Bhc3RlID0geWxvZ3Bh c3RlLCBhYmJyZXZpYXRlID0geCR5LnNjYWxlcyRhYmJyLCANCiAgICAgICAg ICAgICAgICAgIG1pbmxlbmd0aCA9IHgkeS5zY2FsZXMkbWlubCwgbiA9IHgk eS5zY2FsZXMkdGljay5udW1iZXIpJGxhYg0KICAgICAgICAgICAgICAgIGlm IChpcy5jaGFyYWN0ZXIobGFiKSkgDQogICAgICAgICAgICAgICAgICBsYWJl ==> 2859.followup.1 <== From mailnull@stat.math.ethz.ch Sun Apr 27 16:44:01 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3REi0pD003346 for ; Sun, 27 Apr 2003 16:44:00 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3REhvbj013995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Apr 2003 16:43:57 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3REhvfb013971 for R-bugs@biostat.ku.dk; Sun, 27 Apr 2003 16:43:57 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3REhgbi013939 for ; Sun, 27 Apr 2003 16:43:43 +0200 (MEST) Received: from surfer.sbm.temple.edu ([155.247.185.2]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 199nNW-0000Co-00 for ; Sun, 27 Apr 2003 09:43:42 -0500 Received: (from rmh@localhost) by surfer.sbm.temple.edu (8.12.8p1/8.12.8) id h3REh61C2644022; Sun, 27 Apr 2003 10:43:06 -0400 (EDT) Date: Sun, 27 Apr 2003 10:43:06 -0400 (EDT) From: Rich Heiberger Message-Id: <200304271443.h3REh61C2644022@surfer.sbm.temple.edu> To: r-bugs@r-project.org Subject: Re: [Rd] bug and proposed fix in print.trellis 1.7.0 (PR#2859) Cc: rmh@surfer.sbm.temple.edu X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,WEIRD_QUOTING version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) sent again without attachments at Peter Dalgaard's request description: # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### The new feature described in rw1070/library/lattice/Changes is very useful and is needed for several of the examples I showed at DSC-2003. > scales > ------ > In anticipation of future use (in nlme, for example), the at and > labels components of scales can now be a list. Each element > corresponds to a panel. This is thoroughly untested and not guaranteed > to work. It currently rejects correctly formed user labels. I attach an example of the problem and a proposed fix. Rich --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 7.0 year = 2003 month = 04 day = 16 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/.RData, package:grid, package:lattice, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base example: ## print.trellis bug in R 1.7.0 tmp <- data.frame(a=factor(c("a","b","c")), b=factor(c("d","e","f")), d=factor(c(1,1,2))) xyplot(a ~ b | d, data=tmp, ## works scales=list(alternating=F)) xyplot(a ~ b | d, data=tmp, ## Invalid value for labels scales=list(x=list(labels=list(c("d","e",""),c("","","f")), alternating=F))) source("print.trellis.r") ## rmh proposed fix xyplot(a ~ b | d, data=tmp, ## now it works scales=list(x=list(labels=list(c("d","e",""),c("","","f")), alternating=F))) proposed fix: print.trellis <- function (x, position, split, more = FALSE, newpage = TRUE, panel.height = list(1, "null"), panel.width = list(1, "null"), ...) { if (is.null(dev.list())) trellis.device() else if (is.null(trellis.par.get())) trellis.device(device = .Device, new = FALSE) bg = trellis.par.get("background")$col new <- TRUE if (.lattice.print.more || !newpage) new <- FALSE .lattice.print.more <<- more usual <- (missing(position) & missing(split)) fontsize.default <- trellis.par.get("fontsize")$default if (!missing(position)) { if (length(position) != 4) stop("Incorrect value of position") if (new) { grid.newpage() grid.rect(gp = gpar(fill = bg, col = "transparent")) } push.viewport(viewport(x = position[1], y = position[2], width = position[3] - position[1], height = position[4] - position[2], just = c("left", "bottom"))) if (!missing(split)) { if (length(split) != 4) stop("Incorrect value of split") push.viewport(viewport(layout = grid.layout(nrow = split[4], ncol = split[3]))) push.viewport(viewport(layout.pos.row = split[2], layout.pos.col = split[1])) } } else if (!missing(split)) { if (length(split) != 4) stop("Incorrect value of split") if (new) { grid.newpage() grid.rect(gp = gpar(fill = bg, col = "transparent")) } push.viewport(viewport(layout = grid.layout(nrow = split[4], ncol = split[3]))) push.viewport(viewport(layout.pos.row = split[2], layout.pos.col = split[1])) } panel <- if (is.function(x$panel)) x$panel else if (is.character(x$panel)) get(x$panel) else eval(x$panel) x$strip <- if (is.function(x$strip)) x$strip else if (is.character(x$strip)) get(x$strip) else eval(x$strip) axis.line <- trellis.par.get("axis.line") number.of.cond <- length(x$condlevels) layout.respect <- !x$aspect.fill if (layout.respect) panel.height[[1]] <- x$aspect.ratio * panel.width[[1]] if (!is.null(x$key)) { key.gf <- draw.key(x$key) key.space <- if ("space" %in% names(x$key)) x$key$space else if ("x" %in% names(x$key) || "corner" %in% names(x$key)) "inside" else "top" } else if (!is.null(x$colorkey)) { key.gf <- draw.colorkey(x$colorkey) key.space <- if ("space" %in% names(x$colorkey)) x$colorkey$space else "right" } xaxis.col <- if (is.logical(x$x.scales$col)) axis.line$col else x$x.scales$col xaxis.font <- if (is.logical(x$x.scales$font)) 1 else x$x.scales$font xaxis.cex <- x$x.scales$cex xaxis.rot <- if (is.logical(x$x.scales$rot)) c(0, 0) else x$x.scales$rot yaxis.col <- if (is.logical(x$y.scales$col)) axis.line$col else x$y.scales$col yaxis.font <- if (is.logical(x$y.scales$font)) 1 else x$y.scales$font yaxis.cex <- x$y.scales$cex yaxis.rot <- if (!is.logical(x$y.scales$rot)) x$y.scales$rot else if (x$y.scales$relation != "same" && is.logical(x$y.scales$labels)) c(90, 90) else c(0, 0) strip.col.default.bg <- rep(trellis.par.get("strip.background")$col, length = number.of.cond) strip.col.default.fg <- rep(trellis.par.get("strip.shingle")$col, length = number.of.cond) cond.max.level <- integer(number.of.cond) for (i in 1:number.of.cond) { cond.max.level[i] <- length(x$condlevels[[i]]) } if (x$layout[1] == 0) { ddim <- par("din") device.aspect <- ddim[2]/ddim[1] panel.aspect <- panel.height[[1]]/panel.width[[1]] plots.per.page <- x$layout[2] m <- max(1, round(sqrt(x$layout[2] * device.aspect/panel.aspect))) n <- ceiling(plots.per.page/m) m <- ceiling(plots.per.page/n) x$layout[1] <- n x$layout[2] <- m } else plots.per.page <- x$layout[1] * x$layout[2] cols.per.page <- x$layout[1] rows.per.page <- x$layout[2] number.of.pages <- x$layout[3] if (cols.per.page > 1) x.between <- rep(x$x.between, length = cols.per.page - 1) if (rows.per.page > 1) y.between <- rep(x$y.between, length = rows.per.page - 1) x.alternating <- rep(x$x.scales$alternating, length = cols.per.page) y.alternating <- rep(x$y.scales$alternating, length = rows.per.page) x.relation.same <- x$x.scales$relation == "same" y.relation.same <- x$y.scales$relation == "same" xlog <- x$x.scales$log ylog <- x$y.scales$log if (is.logical(xlog) && xlog) xlog <- 10 if (is.logical(ylog) && ylog) ylog <- 10 have.xlog <- !is.logical(xlog) || xlog have.ylog <- !is.logical(ylog) || ylog xlogbase <- if (is.numeric(xlog)) xlog else exp(1) ylogbase <- if (is.numeric(ylog)) ylog else exp(1) xlogpaste <- if (have.xlog) paste(as.character(xlog), "^", sep = "") else "" ylogpaste <- if (have.ylog) paste(as.character(ylog), "^", sep = "") else "" have.main <- !(is.null(x$main$label) || (is.character(x$main$label) && x$main$label == "")) have.sub <- !(is.null(x$sub$label) || (is.character(x$sub$label) && x$sub$label == "")) have.xlab <- !(is.null(x$xlab$label) || (is.character(x$xlab$label) && x$xlab$label == "")) have.ylab <- !(is.null(x$ylab$label) || (is.character(x$ylab$label) && x$ylab$label == "")) n.row <- rows.per.page * (number.of.cond + 3) + (rows.per.page - 1) + 11 n.col <- 3 * cols.per.page + (cols.per.page - 1) + 9 if (layout.respect) { layout.respect <- matrix(0, n.row, n.col) layout.respect[number.of.cond + 6 + (1:rows.per.page - 1) * (number.of.cond + 4), (1:cols.per.page - 1) * 4 + 8] <- 1 } heights.x <- rep(1, n.row) heights.units <- rep("lines", n.row) heights.data <- as.list(1:n.row) widths.x <- rep(1, n.col) widths.units <- rep("lines", n.col) widths.data <- as.list(1:n.col) heights.x[number.of.cond + 6 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- panel.height[[1]] heights.units[number.of.cond + 6 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- panel.height[[2]] heights.x[number.of.cond + 7 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- 0 heights.x[number.of.cond + 8 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- 0 heights.x[4] <- 0 heights.x[5] <- 0 heights.x[n.row - 4] <- 0 heights.x[n.row - 5] <- 0 if (rows.per.page > 1) heights.x[number.of.cond + 9 + ((if (x$as.table) 1:(rows.per.page - 1) else (rows.per.page - 1):1) - 1) * (number.of.cond + 4)] <- y.between heights.x[1] <- 0.5 heights.x[2] <- if (have.main) 2 * x$main$cex else 0 if (have.main) { heights.units[2] <- "strheight" heights.data[[2]] <- x$main$lab } heights.x[n.row] <- 0.5 heights.x[n.row - 1] <- if (have.sub) 2 * x$sub$cex else 0 if (have.sub) { heights.units[n.row - 1] <- "strheight" heights.data[[n.row - 1]] <- x$sub$lab } heights.x[3] <- 0 heights.x[n.row - 2] <- 0 heights.insertlist.position <- 0 heights.insertlist.unit <- unit(1, "null") if (x$x.scales$draw) { if (x.relation.same) { lab <- calculateAxisComponents(x = x$x.limits, at = x$x.scales$at, labels = x$x.scales$lab, have.log = have.xlog, logbase = xlogbase, logpaste = xlogpaste, abbreviate = x$x.scales$abbr, minlength = x$x.scales$minl, n = x$x.scales$tick.number)$lab ## if (is.character(lab)) if (all(sapply(lab, is.character))) ## rmh strbar <- as.list(lab) else if (is.expression(lab)) { strbar <- list() for (ss in seq(along = lab)) strbar <- c(strbar, list(lab[ss])) } else stop("Invalid value for labels") heights.x[5] <- 0.5 + max(0.001, x$x.scales$tck[2]) * 0.3 heights.x[n.row - 5] <- 0.5 + max(0.001, x$x.scales$tck[1]) * 0.3 if (any(x.alternating == 2 | x.alternating == 3)) { if (xaxis.rot[2] %in% c(0, 180)) { heights.insertlist.position <- c(heights.insertlist.position, 4) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1 * xaxis.cex[2], length(strbar)), "strheight", strbar))) } else { heights.insertlist.position <- c(heights.insertlist.position, 4) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1 * xaxis.cex[2] * abs(sin(xaxis.rot[2] * base::pi/180)), length(strbar)), "strwidth", strbar))) } } if (any(x.alternating == 1 | x.alternating == 3)) { if (xaxis.rot[1] %in% c(0, 180)) { heights.insertlist.position <- c(heights.insertlist.position, n.row - 4) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1 * xaxis.cex[1], length(strbar)), "strheight", strbar))) } else { heights.insertlist.position <- c(heights.insertlist.position, n.row - 4) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1 * xaxis.cex[1] * abs(sin(xaxis.rot[1] * base::pi/180)), length(strbar)), "strwidth", strbar))) } } } else { labelChars <- character(0) labelExprs <- expression(0) for (i in seq(along = x$x.limits)) { lab <- calculateAxisComponents(x = x$x.limits[[i]], at = if (is.list(x$x.scales$at)) x$x.scales$at[[i]] else x$x.scales$at, labels = if (is.list(x$x.scales$lab)) x$x.scales$lab[[i]] else x$x.scales$lab, have.log = have.xlog, logbase = xlogbase, logpaste = xlogpaste, abbreviate = x$x.scales$abbr, minlength = x$x.scales$minl, n = x$x.scales$tick.number)$lab if (is.character(lab)) labelChars <- c(labelChars, lab) else if (is.expression(lab)) labelExprs <- c(labelExprs, lab) } labelChars <- unique(labelChars) strbar <- list() for (ss in labelChars) strbar <- c(strbar, list(ss)) for (ss in seq(along = labelExprs)) strbar <- c(strbar, list(labelExprs[ss])) if (xaxis.rot[1] %in% c(0, 180)) { heights.x[number.of.cond + 7 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- max(0.001, x$x.scales$tck[1]) * 0.3 heights.insertlist.position <- c(heights.insertlist.position, number.of.cond + 8 + (1:rows.per.page - 1) * (number.of.cond + 4)) for (i in 1:rows.per.page) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1.5 * xaxis.cex[1], length(strbar)), "strheight", strbar))) } else { heights.x[number.of.cond + 7 + (1:rows.per.page - 1) * (number.of.cond + 4)] <- max(0.001, x$x.scales$tck[1]) * 0.3 heights.insertlist.position <- c(heights.insertlist.position, number.of.cond + 8 + (1:rows.per.page - 1) * (number.of.cond + 4)) for (i in 1:rows.per.page) heights.insertlist.unit <- unit.c(heights.insertlist.unit, max(unit(rep(1.5 * xaxis.cex[1] * abs(sin(xaxis.rot[1] * base::pi/180)), length(strbar)), "strwidth", strbar))) } } } heights.x[n.row - 3] <- if (have.xlab) 2 * x$xlab$cex else 0 if (have.xlab) { heights.units[n.row - 3] <- "strheight" heights.data[[n.row - 3]] <- x$xlab$lab } for (crr in 1:number.of.cond) heights.x[number.of.cond + 6 + (1:rows.per.page - 1) * (number.of.cond + 4) - crr] <- if (is.logical(x$strip)) 0 else 1.1 * x$par.strip.text$cex * x$par.strip.text$lines widths.x[3] <- if (have.ylab) 2 * x$ylab$cex else 0 if (have.ylab) { widths.units[3] <- "strheight" widths.data[[3]] <- x$ylab$lab } widths.x[(1:cols.per.page - 1) * 4 + 8] <- panel.width[[1]] widths.units[(1:cols.per.page - 1) * 4 + 8] <- panel.width[[2]] widths.x[(1:cols.per.page - 1) * 4 + 7] <- 0 widths.x[(1:cols.per.page - 1) * 4 + 6] <- 0 widths.x[4] <- 0 widths.x[5] <- 0 widths.x[n.col - 2] <- 0 widths.x[n.col - 3] <- 0 if (cols.per.page > 1) widths.x[(1:(cols.per.page - 1) - 1) * 4 + 9] <- x.between widths.x[1] <- 0.5 widths.x[n.col] <- 0.5 widths.x[2] <- 0 widths.x[n.col - 1] <- 0 widths.insertlist.position <- 0 widths.insertlist.unit <- unit(1, "null") if (x$y.scales$draw) { if (y.relation.same) { lab <- calculateAxisComponents(x = x$y.limits, at = x$y.scales$at, labels = x$y.scales$lab, have.log = have.ylog, logbase = ylogbase, logpaste = ylogpaste, abbreviate = x$y.scales$abbr, minlength = x$y.scales$minl, n = x$y.scales$tick.number)$lab ## if (is.character(lab)) if (all(sapply(lab, is.character))) ## rmh strbar <- as.list(lab) else if (is.expression(lab)) { strbar <- list() for (ss in seq(along = lab)) strbar <- c(strbar, list(lab[ss])) } else stop("Invalid value for labels") widths.x[5] <- 0.5 + max(0.001, x$y.scales$tck[1]) * 0.3 widths.x[n.col - 3] <- max(1, x$y.scales$tck[2]) * 0.5 if (any(y.alternating == 1 | y.alternating == 3)) { if (abs(yaxis.rot[1]) == 90) { widths.insertlist.position <- c(widths.insertlist.position, 4) widths.insertlist.unit <- unit.c(widths.insertlist.unit, max(unit(1 * rep(yaxis.cex[1], length(strbar)), "strheight", data = strbar))) } else { widths.insertlist.position <- c(widths.insertlist.position, 4) widths.insertlist.unit <- unit.c(widths.insertlist.unit, max(unit(rep(1 * yaxis.cex[1] * abs(cos(yaxis.rot[1] * base::pi/180)), length(strbar)), "strwidth", strbar))) } } if (any(y.alternating == 2 | y.alternating == 3)) { if (abs(yaxis.rot[2]) == 90) { widths.insertlist.position <- c(widths.insertlist.position, n.col - 2) widths.insertlist.unit <- unit.c(widths.insertlist.unit, max(unit(rep(1 * yaxis.cex[2], length(strbar)), "strheight", strbar))) } else { widths.insertlist.position <- c(widths.insertlist.position, n.col - 2) widths.insertlist.unit <- unit.c(widths.insertlist.unit, max(unit(rep(1 * yaxis.cex[2] * abs(cos(yaxis.rot[2] * base::pi/180)), length(strbar)), "strwidth", ==> 2859.audit <== Tue Apr 29 10:53:09 2003 ripley changed notes Tue Apr 29 10:53:09 2003 ripley foobar Tue Apr 29 10:53:09 2003 ripley moved from incoming to Add-ons ==> 2859.followup.2 <== From deepayan@stat.wisc.edu Tue May 13 22:26:55 2003 Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h4DKQs2b001914 for ; Tue, 13 May 2003 22:26:54 +0200 (MET DST) Received: from 192.168.0.114 (66-188-128-48.mad.wi.charter.com [66.188.128.48]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id h4DKQot21116 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 13 May 2003 15:26:50 -0500 From: Deepayan Sarkar To: rmh@surfer.sbm.temple.edu Subject: Re: [Rd] bug and proposed fix in print.trellis 1.7.0 (PR#2859) Date: Tue, 13 May 2003 15:27:05 -0500 User-Agent: KMail/1.5.1 Cc: R-bugs@biostat.ku.dk References: <200304271444.h3REi9pD003350@pubhealth.ku.dk> In-Reply-To: <200304271444.h3REi9pD003350@pubhealth.ku.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305131527.05339.deepayan@stat.wisc.edu> Hi, sorry for the delay, I didn't have time to look at this earlier. On Sunday 27 April 2003 09:44, rmh@surfer.sbm.temple.edu wrote: > The new feature described in rw1070/library/lattice/Changes is very > useful and is needed for several of the examples I showed at DSC-2003. > > > scales > > ------ > > In anticipation of future use (in nlme, for example), the at and > > labels components of scales can now be a list. Each element > > corresponds to a panel. This is thoroughly untested and not guaranteed > > to work. It's not at all clear from this entry, but I meant to do this only when relation="free" or "sliced" in scales, because those are the only cases in which different tick positions and labels can be guaranteed to be associated with each panel. In the relation = "same" case, changing the layout changes which labels go with which panel (and if alternating = 0 or 3, it's even ambiguous). I notice now that your first example (with the 'at' but no 'labels') does produce some output that seems to take the list into account, but that was unintended. My preference would be to produce an error in such cases, but I'm open to other suggestions. Do you really need this ? I think relation="free" would suit your purpose quite well, at least in the given example. Perhaps I could additionally allow 'limits' (which is ignored now for relation="free") to be a list as well. Deepayan > It currently rejects correctly formed user labels. I attach an > example of the problem and a proposed fix. > > Rich > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 1 > minor = 7.0 > year = 2003 > month = 04 > day = 16 > language = R > > Windows XP Home Edition (build 2600) Service Pack 1.0 > > Search Path: > .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/.RData, package:grid, > package:lattice, package:methods, package:ctest, package:mva, > package:modreg, package:nls, package:ts, Autoloads, package:base > > > example: > ## print.trellis bug in R 1.7.0 > > tmp <- data.frame(a=factor(c("a","b","c")), > b=factor(c("d","e","f")), > d=factor(c(1,1,2))) > > xyplot(a ~ b | d, data=tmp, ## works > scales=list(alternating=F)) > > xyplot(a ~ b | d, data=tmp, ## Invalid value for labels > scales=list(x=list(labels=list(c("d","e",""),c("","","f")), > alternating=F))) > > source("print.trellis.r") ## rmh proposed fix > > xyplot(a ~ b | d, data=tmp, ## now it works > scales=list(x=list(labels=list(c("d","e",""),c("","","f")), > alternating=F))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2865 * Subject: bug in y limits in bwplot From: Rich Heiberger Date: Mon, 28 Apr 2003 02:19:53 -0400 (EDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2865 <== From mailnull@stat.math.ethz.ch Mon Apr 28 08:20:38 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3S6KcpD006491 for ; Mon, 28 Apr 2003 08:20:38 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3S6KZbj016116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Apr 2003 08:20:35 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3S6KYeM016115 for R-bugs@biostat.ku.dk; Mon, 28 Apr 2003 08:20:34 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3S6KTbi016095 for ; Mon, 28 Apr 2003 08:20:30 +0200 (MEST) Received: from surfer.sbm.temple.edu ([155.247.185.2]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19A205-0008Hy-00 for ; Mon, 28 Apr 2003 01:20:29 -0500 Received: (from rmh@localhost) by surfer.sbm.temple.edu (8.12.8p1/8.12.8) id h3S6JrAx2647908; Mon, 28 Apr 2003 02:19:53 -0400 (EDT) Date: Mon, 28 Apr 2003 02:19:53 -0400 (EDT) From: Rich Heiberger Message-Id: <200304280619.h3S6JrAx2647908@surfer.sbm.temple.edu> To: r-bugs@r-project.org Subject: bug in y limits in bwplot Cc: rmh@surfer.sbm.temple.edu X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### ## bug in y limits in bwplot tmp <- data.frame(y=1:10, a=factor(rep(1:2,5))) ## x limits in bwplot works as expected bwplot(y ~ a, data=tmp, horizontal=F) # works bwplot(y ~ a, data=tmp, horizontal=F, # works xlim=c(-1,5)) bwplot(y ~ a, data=tmp, horizontal=F, # works scales=list(x=list(limits=c(-1,5)))) ## problem with y limits in bwplot bwplot(a ~ y, data=tmp, horizontal=T) # works bwplot(a ~ y, data=tmp, horizontal=T, # works ylim=c(-1,5)) bwplot(a ~ y, data=tmp, horizontal=T, # error message scales=list(y=list(limits=c(-1,5)))) ## transcript with error message > bwplot(a ~ y, data=tmp, horizontal=T, # error message + scales=list(y=list(limits=c(-1,5)))) Error in print.trellis(structure(list(as.table = FALSE, aspect.fill = TRUE, : Invalid value for labels In addition: Warning message: is.na() applied to non-(list or vector) in: is.na(x) > --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 7.0 year = 2003 month = 04 day = 16 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, package:grid, package:lattice, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base ==> 2865.audit <== Tue Apr 29 10:54:47 2003 ripley moved from incoming to Add-ons ==> 2865.followup.1 <== From deepayan@stat.wisc.edu Tue May 13 23:50:16 2003 Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h4DLoF2b002288 for ; Tue, 13 May 2003 23:50:15 +0200 (MET DST) Received: from 192.168.0.114 (66-188-128-48.mad.wi.charter.com [66.188.128.48]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id h4DLoEt21481 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 13 May 2003 16:50:14 -0500 From: Deepayan Sarkar To: rmh@surfer.sbm.temple.edu Subject: Re: [Rd] bug in y limits in bwplot (PR#2865) Date: Tue, 13 May 2003 16:50:29 -0500 User-Agent: KMail/1.5.1 Cc: R-bugs@biostat.ku.dk References: <200304280620.h3S6KdpD006495@pubhealth.ku.dk> In-Reply-To: <200304280620.h3S6KdpD006495@pubhealth.ku.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305131650.29426.deepayan@stat.wisc.edu> This turns out to be a long-standing bug (in all the lattice functions in fact, not only bwplot). Should be fixed in the next release. A workaround is to use xlim and ylim directly instead of limits in scale. On Monday 28 April 2003 01:20, rmh@surfer.sbm.temple.edu wrote: > ## bug in y limits in bwplot > > tmp <- data.frame(y=1:10, a=factor(rep(1:2,5))) > > ## x limits in bwplot works as expected > bwplot(y ~ a, data=tmp, horizontal=F) # works > > bwplot(y ~ a, data=tmp, horizontal=F, # works > xlim=c(-1,5)) > > bwplot(y ~ a, data=tmp, horizontal=F, # works > scales=list(x=list(limits=c(-1,5)))) > > > ## problem with y limits in bwplot > bwplot(a ~ y, data=tmp, horizontal=T) # works > > bwplot(a ~ y, data=tmp, horizontal=T, # works > ylim=c(-1,5)) > > bwplot(a ~ y, data=tmp, horizontal=T, # error message > scales=list(y=list(limits=c(-1,5)))) > > > ## transcript with error message > > > bwplot(a ~ y, data=tmp, horizontal=T, # error message > > + scales=list(y=list(limits=c(-1,5)))) > Error in print.trellis(structure(list(as.table = FALSE, aspect.fill = TRUE, > : Invalid value for labels > In addition: Warning message: > is.na() applied to non-(list or vector) in: is.na(x) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2933 * Subject: frailty models in survreg() -- survival package From: Jerome Asselin Date: Tue, 6 May 2003 15:36:23 -0700 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2933 <== From jerome@hivnet.ubc.ca Wed May 7 00:36:58 2003 Received: from hivnet.ubc.ca (hivnet.ubc.ca [142.103.173.1]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h46Mau2b029257 for ; Wed, 7 May 2003 00:36:57 +0200 (MET DST) Received: from there (jeromePC [142.103.173.13]) by hivnet.ubc.ca (8.9.0/8.9.0) with SMTP id PAA26505; Tue, 6 May 2003 15:42:06 -0700 (PDT) Message-Id: <200305062242.PAA26505@hivnet.ubc.ca> Content-Type: text/plain; charset="iso-8859-1" From: Jerome Asselin Organization: BC Centre for Excellence in HIV/AIDS To: r-bugs@biostat.ku.dk Subject: frailty models in survreg() -- survival package Date: Tue, 6 May 2003 15:36:23 -0700 X-Mailer: KMail [version 1.3.2] Cc: Thomas Lumley MIME-Version: 1.0 Content-Transfer-Encoding: 8bit I am confused on how the log-likelihood is calculated in a parametric survival problem with frailty. I see a contradiction in the frailty() help file vs. the source code of frailty.gamma(), frailty.gaussian() and frailty.t(). The function frailty.gaussian() appears to calculate the penalty as the negative log-density of independent Gaussian variables, as one would expect: > frailty.gaussian [...] list([...], penalty = 0.5 * sum(coef^2/theta + log(2 * pi * theta)), flag = FALSE) [...] Similarly, the frailty.t() appears to use the joint negative log-density of Student t random variables. HOWEVER, frailty.gamma() uses: > frailty.gamma [...] list([...], penalty = -sum(coef) * nu, flag = FALSE) [...] I would rather expect to see something like: (1) penalty=sum(coef*nu-(nu-1)*log(coef)+lgamma(nu)-nu*log(nu)) which is the joint negative log-density of gamma variables. Alternately, I could also expect to see something like this: (2) penalty=sum(coef-exp(coef))*nu which was shown to lead to the same EM solution as penalty (1) -- at least in the case of a Cox proportional hazard model (Therneau and Grambsch, 2000. Modeling Survival Data, Extending the Cox Model. Springer, New York. Page 254, Eq. (9.8).). Bare we me, I don't know whether this holds in the case of a parametric model. I also have concerns about the validity of the likelihood ratio tests obtained with the latter penalty function (2), because this penalty is NOT equal to the negative log-likelihood (1). Finally, it's not clear to me whether we gain significant convergence speed and accuracy by using the penalty (2) as opposed to (1). Furthermore, the help file for frailty() says, "The penalised likelihood method is equivalent to maximum (partial) likelihood for the gamma frailty but not for the others." In the current state of the package, I would think that this should be the other way around. That is, "The penalised likelihood method is equivalent to maximum (partial) likelihood for the gaussian and t frailty but not for the gamma." However, my current comprehension of the problem leads me to recommend to use the negative log-likelihood of gamma variables (2). Hence, both gamma, Gaussian and t frailty would be equivalent to maximum (partial) likelihood. Any comment on this issue would be much appreciated. Sincerely, Jerome Asselin R 1.6.2 on Red Hat Linux 7.2 Package: survival Version: 2.9-7 -- Jerome Asselin (Jérôme), Statistical Analyst British Columbia Centre for Excellence in HIV/AIDS St. Paul's Hospital, 608 - 1081 Burrard Street Vancouver, British Columbia, CANADA V6Z 1Y6 Email: jerome@hivnet.ubc.ca Phone: 604 806-9112 Fax: 604 806-9044 ==> 2933.audit <== Tue May 13 16:48:37 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2934 * Subject: Re: frailty models in survreg() -- survival package From: Thomas Lumley Date: Tue, 6 May 2003 15:58:37 -0700 (PDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2934 <== From tlumley@u.washington.edu Wed May 7 00:58:41 2003 Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h46Mwd2b029319 for ; Wed, 7 May 2003 00:58:40 +0200 (MET DST) Received: from homer14.u.washington.edu (homer14.u.washington.edu [140.142.8.14]) by mxout5.cac.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46Mwct7021392; Tue, 6 May 2003 15:58:38 -0700 Received: from localhost (tlumley@localhost) by homer14.u.washington.edu (8.12.1+UW03.04/8.12.1+UW02.12) with ESMTP id h46MwbSk071522; Tue, 6 May 2003 15:58:37 -0700 Date: Tue, 6 May 2003 15:58:37 -0700 (PDT) From: Thomas Lumley To: Jerome Asselin cc: r-bugs@biostat.ku.dk Subject: Re: frailty models in survreg() -- survival package In-Reply-To: <200305062242.PAA26505@hivnet.ubc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 May 2003, Jerome Asselin wrote: > > I am confused on how the log-likelihood is calculated in a parametric > survival problem with frailty. I see a contradiction in the frailty() help > file vs. the source code of frailty.gamma(), frailty.gaussian() and > frailty.t(). > > The function frailty.gaussian() appears to calculate the penalty as the > negative log-density of independent Gaussian variables, as one would > expect: > > frailty.gaussian > [...] > list([...], penalty = 0.5 * sum(coef^2/theta + > log(2 * pi * theta)), flag = FALSE) > [...] > > Similarly, the frailty.t() appears to use the joint negative log-density > of Student t random variables. HOWEVER, frailty.gamma() uses: > > frailty.gamma > [...] > list([...], penalty = -sum(coef) * > nu, flag = FALSE) > [...] > I would rather expect to see something like: > (1) penalty=sum(coef*nu-(nu-1)*log(coef)+lgamma(nu)-nu*log(nu)) > which is the joint negative log-density of gamma variables. Alternately, I > could also expect to see something like this: > (2) penalty=sum(coef-exp(coef))*nu > which was shown to lead to the same EM solution as penalty (1) -- at least > in the case of a Cox proportional hazard model (Therneau and Grambsch, > 2000. Modeling Survival Data, Extending the Cox Model. Springer, New York. > Page 254, Eq. (9.8).). Looking at a wider context in the code pfun <- function(coef, theta, ndeath) { if (theta == 0) list(recenter = 0, penalty = 0, flag = TRUE) else { recenter <- log(mean(exp(coef))) coef <- coef - recenter nu <- 1/theta list(recenter = recenter, first = (exp(coef) - 1) * nu, second = exp(coef) * nu, penalty = -sum(coef) * nu, flag = FALSE) } } so the recentering means the penalty is actually your penalty (2) -- not surprising, as the code was written by Terry Therneau. > Bare we me, I don't know whether this holds in the > case of a parametric model. I also have concerns about the validity of the > likelihood ratio tests obtained with the latter penalty function (2), > because this penalty is NOT equal to the negative log-likelihood (1). > Finally, it's not clear to me whether we gain significant convergence > speed and accuracy by using the penalty (2) as opposed to (1). > > Furthermore, the help file for frailty() says, > "The penalised likelihood method is equivalent to maximum (partial) > likelihood for the gamma frailty but not for the others." > > In the current state of the package, I would think that this should be the > other way around. That is, > "The penalised likelihood method is equivalent to maximum (partial) > likelihood for the gaussian and t frailty but not for the gamma." > > However, my current comprehension of the problem leads me to recommend to > use the negative log-likelihood of gamma variables (2). Hence, both gamma, > Gaussian and t frailty would be equivalent to maximum (partial) likelihood. > The log density penalty doesn't give maximum likelihood (which you would get by integrating out the frailties). It gives the joint likelihood of the data and the random effects. For the gamma model, as you note, they are equivalent. I believe that the current state of knowledge is that the log density penalty generally gives consistent estimates but is not equivalent to maximum likelihood. However, I have not actually seen the arguments for consistency and it isn't obvious to me how the argument would go. -thomas ==> 2934.followup.1 <== From jerome@hivnet.ubc.ca Wed May 7 01:54:08 2003 Received: from hivnet.ubc.ca (hivnet.ubc.ca [142.103.173.1]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h46Ns62b029455 for ; Wed, 7 May 2003 01:54:07 +0200 (MET DST) Received: from there (jeromePC [142.103.173.13]) by hivnet.ubc.ca (8.9.0/8.9.0) with SMTP id QAA29199; Tue, 6 May 2003 16:59:12 -0700 (PDT) Message-Id: <200305062359.QAA29199@hivnet.ubc.ca> Content-Type: text/plain; charset="iso-8859-1" From: Jerome Asselin Organization: BC Centre for Excellence in HIV/AIDS To: Thomas Lumley Subject: Re: frailty models in survreg() -- survival package (PR#2934) Date: Tue, 6 May 2003 16:53:29 -0700 X-Mailer: KMail [version 1.3.2] Cc: r-bugs@biostat.ku.dk References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit SEE ALSO ORIGINAL POSTING IN PR#2933 On May 6, 2003 03:58 pm, Thomas Lumley wrote: > > Looking at a wider context in the code > > pfun <- function(coef, theta, ndeath) { > if (theta == 0) > list(recenter = 0, penalty = 0, flag = TRUE) > else { > recenter <- log(mean(exp(coef))) > coef <- coef - recenter > nu <- 1/theta > list(recenter = recenter, first = (exp(coef) - 1) * > nu, second = exp(coef) * nu, penalty = -sum(coef) * > nu, flag = FALSE) > } > } > > so the recentering means the penalty is actually your penalty (2) -- not > surprising, as the code was written by Terry Therneau. Ok, I forgot to account for the recentering. However, correct me if I am wrong, but if Therneau and Grambsch (2000, Eq. (9.8)) are right, I think it should be: recenter <- mean(exp(coef)) instead of recenter <- log(mean(exp(coef))) > > The log density penalty doesn't give maximum likelihood (which you would > get by integrating out the frailties). It gives the joint likelihood of > the data and the random effects. I'm confused... Do you mean that the log-likelihood of all model parameters (which is maximised) is NOT the sum of the conditional log-likelihood of the data and the log-likelihood of the random effects? > > For the gamma model, as you note, they are equivalent. I believe that > the current state of knowledge is that the log density penalty generally > gives consistent estimates but is not equivalent to maximum likelihood. > However, I have not actually seen the arguments for consistency and it > isn't obvious to me how the argument would go. > Sorry, I don't understand why you say that they are equivalent for the gamma model. Therneau and Grambsch (p.254) specifically note, "... the penalized loglikelihood and the observed-data loglikelihood in equation (9.4) have the same solution, although these two equations are NOT equal to one another." For that reason, I think that the help file should read, > > "The penalised likelihood method is equivalent to maximum > > (partial) likelihood for the gaussian and t frailty but not for the > > gamma." Also, is it clear whether the current gamma penalty function remains valid even in the case of parametric survival analysis? Is it computationally better than (1)? Finally, what is the meaning of the "loglik" value in gamma frailty? Can it still be used to calculate likelihood ratio tests? Cheers, Jerome ==> 2934.audit <== Tue May 13 16:48:37 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2986 * Subject: plot.ranef.lme From: Peter Dalgaard BSA Date: 12 May 2003 18:19:28 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2986 <== From mailnull@stat.math.ethz.ch Mon May 12 18:14:24 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h4CGEN2b019376 for ; Mon, 12 May 2003 18:14:24 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h4CGEK6s005731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 May 2003 18:14:21 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h4CGEKQh005730 for R-bugs@biostat.ku.dk; Mon, 12 May 2003 18:14:20 +0200 (MEST) Received: from pubhealth.ku.dk (mail.kubism.ku.dk [192.38.18.10]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h4CGEF6r005673 for ; Mon, 12 May 2003 18:14:15 +0200 (MEST) Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h4CGED2b019373 for ; Mon, 12 May 2003 18:14:13 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h4CGJT8e024933 for ; Mon, 12 May 2003 18:19:29 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h4CGJTth024929; Mon, 12 May 2003 18:19:29 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: r-bugs@stat.math.ethz.ch Subject: plot.ranef.lme From: Peter Dalgaard BSA Date: 12 May 2003 18:19:28 +0200 Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-7.8 required=4.8 tests=USER_AGENT_GNUS_UA,X_AUTH_WARNING version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) library(nlme) data(Phenobarb) na.include <- function(x)x phe1 <- nlme(conc~phenoModel(Subject, time, dose, lCl, lV), data = Phenobarb, fixed = lCl+lV~1, random= pdDiag(lCl+lV~1), start = c(-5,0), na.action = na.include, naPattern = ~!is.na(conc)) phe.ranef <- ranef(phe1,augFrame=TRUE) plot(phe.ranef, form=lCl~Wt+ApgarInd) [Error in max(length(x0), length(x1), length(y0), length(y1)) : Argument "x0" is missing, with no default] The cause is plain to see: in plot.ranef.lme we have staple.ends <- list(x1 = c(rep(X - w, 2), rep(X + w, 2)), y1 = rep(c(Y[5], max(Y[1] - e.u, Y[2])), 2), x2 = c(rep(X - w, 2), rep(X + w, 2)), y2 = rep(c(min(Y[5] + e.l, Y[4]), Y[1]), 2)) . . . . do.call("lsegments", c(staple.ends, box.umbrella)) but lsegments expects arguments named x0,y0,x1,y1 not x1,y1,x2,y2 -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 2986.followup.1 <== From deepayan@stat.wisc.edu Mon May 12 19:43:28 2003 Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h4CHhR2b019699; Mon, 12 May 2003 19:43:27 +0200 (MET DST) Received: from bates1.stat.wisc.edu (bates1.stat.wisc.edu [128.105.5.131]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id h4CHhQ915378 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 12 May 2003 12:43:26 -0500 From: Deepayan Sarkar To: p.dalgaard@biostat.ku.dk Subject: Re: [Rd] plot.ranef.lme (PR#2986) Date: Mon, 12 May 2003 12:46:19 -0500 User-Agent: KMail/1.5.1 Cc: R-bugs@biostat.ku.dk References: <200305121614.h4CGEP2b019381@pubhealth.ku.dk> In-Reply-To: <200305121614.h4CGEP2b019381@pubhealth.ku.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305121246.19059.deepayan@stat.wisc.edu> On Monday 12 May 2003 11:14 am, p.dalgaard@biostat.ku.dk wrote: > library(nlme) > data(Phenobarb) > na.include <- function(x)x > phe1 <- nlme(conc~phenoModel(Subject, time, dose, lCl, lV), > data = Phenobarb, > fixed = lCl+lV~1, > random= pdDiag(lCl+lV~1), > start = c(-5,0), > na.action = na.include, > naPattern = ~!is.na(conc)) > > phe.ranef <- ranef(phe1,augFrame=TRUE) > plot(phe.ranef, form=lCl~Wt+ApgarInd) > > [Error in max(length(x0), length(x1), length(y0), length(y1)) : > Argument "x0" is missing, with no default] > > The cause is plain to see: in plot.ranef.lme we have > > staple.ends <- list(x1 = c(rep(X - w, 2), rep(X + > w, 2)), y1 = rep(c(Y[5], max(Y[1] - e.u, Y[2])), > 2), x2 = c(rep(X - w, 2), rep(X + w, 2)), y2 = > rep(c(min(Y[5] + e.l, Y[4]), Y[1]), 2)) . . . . > do.call("lsegments", c(staple.ends, box.umbrella)) > > but lsegments expects arguments named x0,y0,x1,y1 not x1,y1,x2,y2 I have seen this problem before and I remember fixing lsegments to work with both forms of the arguments. But the CVS doesn't have the fix, so I guess I made it somewhere temporarily and forgot to add it to CVS, sorry. I'll fix this for the next release. Deepayan ==> 2986.audit <== Tue May 13 15:12:14 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3197 * Subject: split.AffyBatch From: johannes.freudenberg@imise.uni-leipzig.de Date: Thu, 5 Jun 2003 16:05:00 +0200 (MET DST) --about BioConductor package affy ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3197 <== From johannes.freudenberg@imise.uni-leipzig.de Thu Jun 5 16:05:01 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h55E502b010233 for ; Thu, 5 Jun 2003 16:05:00 +0200 (MET DST) Date: Thu, 5 Jun 2003 16:05:00 +0200 (MET DST) Message-Id: <200306051405.h55E502b010233@pubhealth.ku.dk> From: johannes.freudenberg@imise.uni-leipzig.de To: R-bugs@biostat.ku.dk Subject: split.AffyBatch Full_Name: Johannes Freudenberg Version: Version 1.6.2 (2003-01-10) OS: Unix (SunOS 5.9 ) Submission from: (NULL) (139.18.75.39) Hi, I tried your example from the website (http://www.r-project.org/) and I get the following error message: > data(affybatch.example) > f <- factor(c("a", "a", "b")) > split(affybatch.example, f) Error in initialize(value, ...) : Invalid names for slots of class exprSet: ncol, nrow, cdfName Same with split.AffyBatch: > split.AffyBatch(affybatch.example, f) Error in initialize(value, ...) : Invalid names for slots of class exprSet: ncol, nrow, cdfName What can I do? Sincerely, Johannes Freudenberg ==> 3197.followup.1 <== From ripley@stats.ox.ac.uk Thu Jun 5 17:03:40 2003 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h55F3e2b010478 for ; Thu, 5 Jun 2003 17:03:40 +0200 (MET DST) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.9/8.12.9) with ESMTP id h55F3eUK008488; Thu, 5 Jun 2003 16:03:40 +0100 (BST) Date: Thu, 5 Jun 2003 16:03:39 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: johannes.freudenberg@imise.uni-leipzig.de cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] split.AffyBatch (PR#3197) In-Reply-To: <200306051405.h55E512b010237@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What is this referring to? At a guess it is one of the BioConductor packages, for which that is not the master URL. R-bugs is for bug reports on R, not for questions about unspecified contributed packages. On Thu, 5 Jun 2003 johannes.freudenberg@imise.uni-leipzig.de wrote: > Full_Name: Johannes Freudenberg > Version: Version 1.6.2 (2003-01-10) Not the current version of R, might well be the problem. > OS: Unix (SunOS 5.9 ) > Submission from: (NULL) (139.18.75.39) > > I tried your example from the website (http://www.r-project.org/) and I get the > following error message: > > > data(affybatch.example) > > f <- factor(c("a", "a", "b")) > > split(affybatch.example, f) > Error in initialize(value, ...) : Invalid names for slots of class exprSet: > ncol, nrow, cdfName > > Same with split.AffyBatch: > > split.AffyBatch(affybatch.example, f) > Error in initialize(value, ...) : Invalid names for slots of class exprSet: > ncol, nrow, cdfName > > What can I do? -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 3197.audit <== Thu Jun 5 18:56:52 2003 ripley changed notes Thu Jun 5 18:56:52 2003 ripley foobar Thu Jun 5 18:56:52 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3198 * From: "Johannes Freudenberg" --part of 3197 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3198 <== From johannes.freudenberg@imise.uni-leipzig.de Thu Jun 5 17:22:56 2003 Received: from news.uni-leipzig.de (news.uni-leipzig.de [139.18.25.3]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h55FMt2b010566 for ; Thu, 5 Jun 2003 17:22:56 +0200 (MET DST) Received: from hogwarts.imise.uni-leipzig.de (hogwarts.imise.uni-leipzig.de [139.18.158.153]) by news.uni-leipzig.de (Postfix) with ESMTP id 1C4EB5C0; Thu, 5 Jun 2003 17:22:56 +0200 (METDST) Received: by hogwarts.imise.uni-leipzig.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id F079D1454E; Thu, 5 Jun 2003 17:22:55 +0200 (CEST) Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 references: From: "Johannes Freudenberg" MIME-Version: 1.0 subject: Re: [Rd] split.AffyBatch (PR#3197) To: "Prof Brian Ripley" content-type: text/plain; charset="iso-8859-1" date: Thu, 05 Jun 2003 17:22:55 +0200 content-transfer-encoding: 7bit Message-Id: <20030605152255.F079D1454E@hogwarts.imise.uni-leipzig.de> > What is this referring to? > > At a guess it is one of the BioConductor packages, for which that is not > the master URL. > > R-bugs is for bug reports on R, not for questions about unspecified > contributed packages. Well, I guess I got confused with all the frames on your website. Here's the URL: http://finzi.psych.upenn.edu/R/library/affy/html/AffyBatch-class.html. I used your search engine and got directly to that page assuming that I was still on the R website and not on some unspecified contributed website. > > Version: Version 1.6.2 (2003-01-10) > > Not the current version of R, might well be the problem. I guess... -- ==> 3198.audit <== Thu Jun 5 18:57:11 2003 ripley changed notes Thu Jun 5 18:57:11 2003 ripley foobar Thu Jun 5 18:57:11 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3415 * Subject: Installing RSPerl From: nisai@lagrange.tampabaywater.org Date: Sun, 6 Jul 2003 21:28:21 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3415 <== From nisai@lagrange.tampabaywater.org Sun Jul 6 21:28:23 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h66JSLJH016347 for ; Sun, 6 Jul 2003 21:28:22 +0200 (MET DST) Date: Sun, 6 Jul 2003 21:28:21 +0200 (MET DST) Message-Id: <200307061928.h66JSLJH016347@pubhealth.ku.dk> From: nisai@lagrange.tampabaywater.org To: R-bugs@biostat.ku.dk Subject: Installing RSPerl Full_Name: Nisai Wanakule Version: 1.7.1 OS: Solaris 2.9 Submission from: (NULL) (65.32.94.36) I tried to install RSPerl with --with-in-perl option and got some errors. R was built with --enable-R-shlib as indicated in the RSPerl instructions. Here is the list output during installation: nisai@lagrange:src 102$ R CMD INSTALL -c --configure-args='--with-in-perl' RSPerl_0.5-7.tar.gz * Installing *source* package 'RSPerl' ... Using '/usr/local/bin/perl' as the perl executable Perl modules: Adding R package to list of Perl modules to enable callbacks to R from Perl modules: threads re attrs XS::Typemap XS::APItest Unicode::Normalize Time::HiRes Sys::Syslog Sys::Hostname Storable Socket SDBM_File PerlIO::via PerlIO::scalar PerlIO::encoding POSIX Opcode ODBM_File NDBM_File MIME::Base64 List::Util IPC::SysV IO I18N::Langinfo GD BM_File Filter::Util::Call File::Glob Fcntl Encode Digest::MD5 Devel::Peek Devel::PPPort Devel::DProf Data::Dumper DB_File Cwd ByteL oader Compress::Zlib Term::ReadKey Text::CSV_XS SQL::Statement DBI Time::HiRes Apache::Symbol Apache::Leak HTML::Parser HTML::Embper l DBD::Oracle DBD::ODBC NetCDF UDUNITS Storable DBD::Pg DBD::ODBC Apache::DB Apache::Symbol Apache::Leak Digest::SHA1 Digest::MD2 Di gest::MD5 MIME::Base64 HTML::Parser Image::Magick R; linking: /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/threads/threads.so /usr/ local/lib/perl5/5.8.0/sun4-solaris/auto/re/re.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/attrs/attrs.so /usr/local/lib/perl5/5. 8.0/sun4-solaris/auto/XS/Typemap/Typemap.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/XS/APItest/APItest.so /usr/local/lib/perl5/ 5.8.0/sun4-solaris/auto/Unicode/Normalize/Normalize.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Time/HiRes/HiRes.so /usr/local/l ib/perl5/5.8.0/sun4-solaris/auto/Sys/Syslog/Syslog.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Sys/Hostname/Hostname.so /usr/loc al/lib/perl5/5.8.0/sun4-solaris/auto/Storable/Storable.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Socket/Socket.so /usr/local/l ib/perl5/5.8.0/sun4-solaris/auto/SDBM_File/SDBM_File.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/PerlIO/via/via.so /usr/local/li b/perl5/5.8.0/sun4-solaris/auto/PerlIO/scalar/scalar.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/PerlIO/encoding/encoding.so /us r/local/lib/perl5/5.8.0/sun4-solaris/auto/POSIX/POSIX.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Opcode/Opcode.so /usr/local/li b/perl5/5.8.0/sun4-solaris/auto/ODBM_File/ODBM_File.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/NDBM_File/NDBM_File.so /usr/loca l/lib/perl5/5.8.0/sun4-solaris/auto/MIME/Base64/Base64.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/List/Util/Util.so /usr/local/ lib/perl5/5.8.0/sun4-solaris/auto/IPC/SysV/SysV.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/IO/IO.so /usr/local/lib/perl5/5.8.0/ sun4-solaris/auto/I18N/Langinfo/Langinfo.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/GDBM_File/GDBM_File.so /usr/local/lib/perl5 /5.8.0/sun4-solaris/auto/Filter/Util/Call/Call.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/File/Glob/Glob.so /usr/local/lib/perl 5/5.8.0/sun4-solaris/auto/Fcntl/Fcntl.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Encode/Encode.so /usr/local/lib/perl5/5.8.0/su n4-solaris/auto/Digest/MD5/MD5.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Devel/Peek/Peek.so /usr/local/lib/perl5/5.8.0/sun4-so laris/auto/Devel/PPPort/PPPort.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/Devel/DProf/DProf.so /usr/local/lib/perl5/5.8.0/sun4- solaris/auto/Data/Dumper/Dumper.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/DB_File/DB_File.so /usr/local/lib/perl5/5.8.0/sun4-s olaris/auto/Cwd/Cwd.so /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/ByteLoader/ByteLoader.so /usr/local/lib/perl5/site_perl/5.8.0/su n4-solaris/auto/Compress/Zlib/Zlib.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Term/ReadKey/ReadKey.so /usr/local/lib/ perl5/site_perl/5.8.0/sun4-solaris/auto/Text/CSV_XS/CSV_XS.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/SQL/Statement/S tatement.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/DBI/DBI.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto /Time/HiRes/HiRes.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Apache/Symbol/Symbol.so /usr/local/lib/perl5/site_perl/5 .8.0/sun4-solaris/auto/Apache/Leak/Leak.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/HTML/Parser/Parser.so /usr/local/l ib/perl5/site_perl/5.8.0/sun4-solaris/auto/HTML/Embperl/Embperl.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/DBD/Oracle /Oracle.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/DBD/ODBC/ODBC.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /auto/NetCDF/NetCDF.so /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/UDUNITS/UDUNITS.so /usr/local/lib/perl5/site_perl/auto /Storable/Storable.so /usr/local/lib/perl5/site_perl/auto/DBD/Pg/Pg.so /usr/local/lib/perl5/site_perl/auto/DBD/ODBC/ODBC.so /usr/loc al/lib/perl5/site_perl/auto/Apache/DB/DB.so /usr/local/lib/perl5/site_perl/auto/Apache/Symbol/Symbol.so /usr/local/lib/perl5/site_pe rl/auto/Apache/Leak/Leak.so /usr/local/lib/perl5/site_perl/auto/Digest/SHA1/SHA1.so /usr/local/lib/perl5/site_perl/auto/Digest/MD2/M D2.so /usr/local/lib/perl5/site_perl/auto/Digest/MD5/MD5.so /usr/local/lib/perl5/site_perl/auto/MIME/Base64/Base64.so /usr/local/lib /perl5/site_perl/auto/HTML/Parser/Parser.so /usr/local/lib/perl5/site_perl/auto/Image/Magick/Magick.so checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed Support R in Perl: yes configure: creating ./config.status config.status: creating src/Makevars config.status: creating R/RSUtils.S config.status: creating inst/scripts/RSPerl.csh config.status: creating src/RinPerlMakefile config.status: creating src/Makefile.PL making RinPerlMakefile mksh: Fatal error in reader: = missing from replacement macro reference Current working directory /tmp/R.INSTALL.3427/RSPerl/src make: Fatal error: Can't find `Makefile.perl': No such file or directory chmod: WARNING: can't access blib/lib/R.pm cp: cannot access blib Finished configuration ** libs mksh: Fatal error in reader: = missing from replacement macro reference Current working directory /tmp/R.INSTALL.3427/RSPerl/src ERROR: compilation failed for package 'RSPerl' ==> 3415.audit <== Wed Jul 23 18:15:04 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3639 * Subject: Genetics package: Heterozygosity and PIC incorrect From: gerard.tromp@sanger.med.wayne.edu Date: Mon, 4 Aug 2003 00:02:58 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3639 <== From gerard.tromp@sanger.med.wayne.edu Mon Aug 4 00:02:59 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h73M2wJH026138 for ; Mon, 4 Aug 2003 00:02:59 +0200 (MET DST) Date: Mon, 4 Aug 2003 00:02:58 +0200 (MET DST) Message-Id: <200308032202.h73M2wJH026138@pubhealth.ku.dk> From: gerard.tromp@sanger.med.wayne.edu To: R-bugs@biostat.ku.dk Subject: Genetics package: Heterozygosity and PIC incorrect Full_Name: Gerard Tromp Version: 1.7.0 OS: Windows 2000 Submission from: (NULL) (146.9.5.86) In function summary.genotype: Heterozygosity (H) and PIC are computed using af (allele frequency), however, af is derived as a frequency count whereas the computation of H and PIC are in terms of frequency as a proportion. Using the example data provided (genetics.R) H and PIC return large negative numbers whereas they are bounded 0,1. Output from buggy version: ************************************************************************* Marker: MBP2:C-104T (9q35:-104) Type: SNP Number persons typed: 100 (100%) Allele Frequency: (2 alleles) Count Proportion C 137 0.69 T 63 0.32 Genotype Frequency: Count Proportion C/C 59 0.59 C/T 19 0.19 T/T 22 0.22 Heterozygosity (Hu) = -22967 <------ Impossible Poly. Inf. Content = -1.5e+08 <------ Impossible *************************************************************************** Output from fixed version: *************************************************************************** Marker: MBP2:C-104T (9q35:-104) Type: SNP Number persons typed: 100 (100%) Allele Frequency: (2 alleles) Count Proportion C 137 0.69 T 63 0.32 Genotype Frequency: Count Proportion C/C 59 0.59 C/T 19 0.19 T/T 22 0.22 Heterozygosity (Hu) = 0.44 <--- Correct Poly. Inf. Content = 0.34 <--- Correct *************************************************************************** Fix is detailed below. ***************** 2539,2554 c 2539,2565 ******************************************** ### from code submitted by David Duffy # n.typed<-sum(gf) correction<-n.typed/max(1,n.typed-1) # Gerard Tromp 20030803 # Heterozygosity and PIC reported are incorrect. # Problem due to use of af which is a count rather than prop.table(af) a # proportion (fraction) less than 1. Definition of af changed? # ## Original # ehet<-(1-sum(af*af)) # the following produces desired result ehet<-(1-sum(prop.table(af)*prop.table(af))) ## Original # matings<- (af %*% t(af))^2 # the following produces desired result matings <- (prop.table(af) %*% t(prop.table(af)))^2 uninf.mating.freq <- sum(matings)-sum(diag(matings)) pic<- ehet - uninf.mating.freq retval$Hu <- correction * ehet retval$pic <- pic retval$n.typed <- n.typed retval$n.total <- length(object) retval$nallele <- nallele(object) # ### ********************************************************************************** ==> 3639.audit <== Mon Aug 4 16:54:16 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3642 * Subject: R package {genetics} function summary.genotype -- H and PIC return incorrect values. From: "Gerard Tromp" Date: Sun, 3 Aug 2003 22:45:06 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3642 <== From gerard.tromp@sanger.med.wayne.edu Mon Aug 4 04:45:09 2003 Received: from sanger.med.wayne.edu (sanger.med.wayne.edu [146.9.4.21]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h742j8JH027168 for ; Mon, 4 Aug 2003 04:45:08 +0200 (MET DST) Received: from WRIGHT ([146.9.5.86]) by sanger.med.wayne.edu (8.12.9/8.12.9) with SMTP id h742ikcJ021918 for ; Sun, 3 Aug 2003 22:44:47 -0400 (EDT) From: "Gerard Tromp" To: Subject: R package {genetics} function summary.genotype -- H and PIC return incorrect values. Date: Sun, 3 Aug 2003 22:45:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scanned-By: MIMEDefang 2.18 (www . roaringpenguin . com / mimedefang) Greetings! I found a bug in the function summary.genotype (details below). Essentially it appears that the original code from David Duffy used af, allele frequency, as a proportion but in the genetics package af is allele frequency as a count. I tried to submit a bug report together with the fix to CRAN (below). I am unsure of the success since the bug report does not appear in the list. I am therefore sending it by e-mail. Sincerely, Gerard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Gerard Tromp, Ph.D. vox: 313-577-8773 Center for Molecular Medicine and Genetics fax: 313-577-7736 Wayne State Univ. Schl. of Medicine 540 E. Canfield, Detroit, MI 48201 gtromp@cmb.biosci.wayne.edu mailto:tromp@sanger.med.wayne.edu http://cmmg.biosci.wayne.edu In function summary.genotype: Heterozygosity (H) and PIC are computed using af (allele frequency), however, af is derived as a frequency count whereas the computation of H and PIC are in terms of frequency as a proportion. Using the example data provided (genetics.R) H and PIC return large negative numbers whereas they are bounded 0,1. Output from buggy version: ************************************************************************* Marker: MBP2:C-104T (9q35:-104) Type: SNP Number persons typed: 100 (100%) Allele Frequency: (2 alleles) Count Proportion C 137 0.69 T 63 0.32 Genotype Frequency: Count Proportion C/C 59 0.59 C/T 19 0.19 T/T 22 0.22 Heterozygosity (Hu) = -22967 <------ Impossible Poly. Inf. Content = -1.5e+08 <------ Impossible *************************************************************************** Output from fixed version: *************************************************************************** Marker: MBP2:C-104T (9q35:-104) Type: SNP Number persons typed: 100 (100%) Allele Frequency: (2 alleles) Count Proportion C 137 0.69 T 63 0.32 Genotype Frequency: Count Proportion C/C 59 0.59 C/T 19 0.19 T/T 22 0.22 Heterozygosity (Hu) = 0.44 <--- Correct Poly. Inf. Content = 0.34 <--- Correct *************************************************************************** Fix is detailed below. ***************** 2539,2554 c 2539,2565 ******************************************** ### from code submitted by David Duffy # n.typed<-sum(gf) correction<-n.typed/max(1,n.typed-1) # Gerard Tromp 20030803 # Heterozygosity and PIC reported are incorrect. # Problem due to use of af which is a count rather than prop.table(af) a # proportion (fraction) less than 1. Definition of af changed? # ## Original # ehet<-(1-sum(af*af)) # the following produces desired result ehet<-(1-sum(prop.table(af)*prop.table(af))) ## Original # matings<- (af %*% t(af))^2 # the following produces desired result matings <- (prop.table(af) %*% t(prop.table(af)))^2 uninf.mating.freq <- sum(matings)-sum(diag(matings)) pic<- ehet - uninf.mating.freq retval$Hu <- correction * ehet retval$pic <- pic retval$n.typed <- n.typed retval$n.total <- length(object) retval$nallele <- nallele(object) # ### **************************************************************************** ****** ==> 3642.audit <== Mon Aug 4 16:53:48 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3648 * Subject: hclust() and agnes() method="average" divergence From: "Grum, Mikkel [IPGRI-SSA-Nairobi]" Date: Sun, 03 Aug 2003 23:41:39 -0700 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3648 <== From mailnull@stat.math.ethz.ch Mon Aug 4 08:51:29 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h746pTJH028087 for ; Mon, 4 Aug 2003 08:51:29 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h746oqkw000012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Aug 2003 08:50:53 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h746oqim000011 for R-bugs@biostat.ku.dk; Mon, 4 Aug 2003 08:50:52 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h746ofkv029958 for ; Mon, 4 Aug 2003 08:50:41 +0200 (MEST) Received: from 70-224.cgnet.com ([198.93.224.70] helo=smta-hub-8.cgnet.com) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19jZBZ-0001Gl-00 for ; Mon, 04 Aug 2003 01:51:14 -0500 Received: from smta-hub-3.cgnet.com ([64.95.130.11]) by smta-hub-8.cgnet.com (PMDF V6.0-025 #40131) with ESMTP id <0HJ300E1F1PCVR@smta-hub-8.cgnet.com> for r-bugs@r-project.org; Sun, 03 Aug 2003 23:51:12 -0700 (PDT) Received: from noccgiarx4.cgnet.com ([64.95.129.76]) by smta-hub-3.cgnet.com (PMDF V6.1 #39676) with SMTP id <0HJ30080J1PCH5@smta-hub-3.cgnet.com>; Sun, 03 Aug 2003 23:51:12 -0700 (PDT) Received: from 172.30.0.13 by noccgiarx4.cgnet.com (InterScan E-Mail VirusWall NT); Sun, 03 Aug 2003 23:52:49 -0700 Received: by NOCCGIARX4 with Internet Mail Service (5.5.2656.59) id ; Sun, 03 Aug 2003 23:52:49 -0700 Date: Sun, 03 Aug 2003 23:41:39 -0700 From: "Grum, Mikkel [IPGRI-SSA-Nairobi]" Subject: hclust() and agnes() method="average" divergence To: r-bugs@r-project.org Cc: maechler@stat.math.ethz.ch Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-type: multipart/mixed; boundary="----_=_NextPart_000_01C35A53.75780090" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C35A53.75780090 Content-Type: text/plain; charset="iso-8859-1" Anyone have a clue why hclust() and agnes() produce different results in the example below when both use method="average"?? I'm not able to reproduce the problem with other datasets. ereck<-read.table("Ereck.txt",header=TRUE,sep="\t") emol<-subset(ereck,select=c(11:18,20:32)) library(cluster) library(mva) daisemol<-daisy(emol,type=list(asymm=c(1:21))) layout(matrix(c(1,1,2,2),2,2,byrow=TRUE)) hclustmol<-hclust(daisemol,method="average") plot(hclustmol,cex=0.6) agnesmol<-agnes(daisemol,method="average") pltree(agnesmol,cex=0.6) coagnes<-cophenetic(agnesmol) cor(coagnes,daisemol) cohclust<-cophenetic(hclustmol) cor(cohclust,daisemol) I'm using R 1.7.1 (2003-06-16) on Windows XP. Library "cluster" version 1.7.4 and library "mva" version 1.7.1. Best wishes, Mikkel Mikkel Grum International Plant Genetic Resources Institute (IPGRI) Sub-Saharan Africa Group *** PO Box 30677 00100 Nairobi, Kenya Tel: +254 20 524505(direct)/524500(IPGRI) Fax: +254 20 524501(IPGRI)/524001(ICRAF) m.grum@cgiar.org www.ipgri.org ------_=_NextPart_000_01C35A53.75780090 Content-Type: text/plain; name="Ereck.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ereck.txt" COLLNUM NPGRC No LOCALNAME DISTRICT VILLAGE PROVINCE DISEASERESISTANCE = PLANTUSES PARTUSED FARMER V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 = V14 V15 V16 V17 V18 V19 V20 V21 V22 MMB05 1343 Nhongoro Nyanga Samakande Manicaland food "stalk, seed" Mr = Bulawayo 0 1 0 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MMB07 1345 Ipwa Nyanga Samakande Manicaland food "stalk, seed" Mr = Bulawayo 0 1 0 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MMBO8 1346 Ipwa Nyanga Samakande Manicaland food "stalk, seed" Mr = Bulawayo 0 0 0 0 1 0 0 1 1 0 0 1 0 0 1 0 0 0 0 1 1 0 MMB17 1355 Musoswe Nyanga Chibvembe Manicaland "food, beverage" = "stalk, seed" Mr Mupunwa 0 0 1 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 0 1 0 MMB40 1378 Nzende Nyanga Mangezi Manicaland grasshoppers "food, = beverage" seed Mr Kambara 0 1 0 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 0 1 0 1 MMB46 1384 Nzende Nyanga Mangezi Manicaland low resistance to rotting = food seed Mrs Chitimas 0 1 0 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB47 1385 Musoswe Nyanga Mangezi Manicaland food seed Mrs Chitimas 0 = 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB54 1392 Nhongoro Nyanga Mangezi Manicaland black sports on head food = " seed, stalk" Mrs P Mangezi 0 0 1 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 1 0 = 1 MMB57 1395 Mudhabhure Nyanga Mangezi Manicaland food seed Mrs P = Mangezi 0 1 0 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 1 0 MMB61 1399 Nzende Nyanga Mangezi Manicaland "food, beverage" seed Mrs = I Mangezi 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MMB62 1400 Nhongoro Nyanga Mangezi Manicaland "food, beverage" seed = Mrs I Mangezi 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 0 1 MMB63 1401 Musoswe Nyanga Mangezi Manicaland food seed Mrs I Mangezi = 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 0 1 0 1 MMB64 1402 Sorghum Nyanga Mangezi Manicaland food seed Mrs I Mangezi = 0 0 0 1 0 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MMB71 1409 Nhongoro Nyanga Mangezi Manicaland "food, beverage" seed = Mr & Mrs S Charachimwe 0 0 1 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 0 1 1 0 MMB74 1412 Sorghum (white) Nyanga Mangezi Manicaland food seed Mr & = Mrs S Charachimwe 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 0 1 0 1 MMB 1425 0 0 1 0 0 1 0 1 1 0 0 1 0 0 0 1 0 0 0 1 1 0 MMB90 1428 Musoswe Nyanga Kamunhukamwe Manicaland black smuts "food, = beverage" " seed, stalk" Mrs Katanganda 0 0 0 1 0 0 1 0 1 0 0 1 0 0 1 0 = 0 0 1 0 0 1 MMB92 1430 Sorghum Nyanga Kamunhukamwe Manicaland food seed Mrs = Katanganda 0 0 0 0 1 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 1 0 MMB103 1441 Musoswe Nyanga Kamunhukamwe Manicaland smuts diseases food = " seed, stalk" Mrs M Makombe 0 1 0 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 1 = 0 MMB110 1448 Musoswe Nyanga Kamunhukamwe Manicaland "food, beverage" = seed Mr & Mrs Musambidzi 0 1 0 0 0 0 0 1 1 0 0 1 0 0 1 0 0 0 1 0 0 1 MMB112 1450 Sorghum (shodhani) Nyanga Kamunhukamwe Manicaland "food, = beverage" seed Mr & Mrs Musambidzi 0 0 1 0 1 0 0 1 1 0 0 0 1 0 1 0 0 0 = 0 1 1 0 MMB117 1455 Ipwa Nyanga Kamunhukamwe Manicaland food stalk Mr & Mrs = Musambidzi 0 0 1 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 1 0 MMB121 1459 Sorghum Nyanga Renzva Manicaland smuts "food, beverage" = seed Mrs Chikwati 0 0 1 0 0 0 1 0 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB122 1460 Musoswe Nyanga Renzva Manicaland "food, beverage" seed = Mrs Chikwati 0 0 1 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 0 1 0 MMB123 1461 Sorghum Nyanga Renzva Manicaland "food, beverage" seed = Mrs Chikwati 0 0 0 1 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB134 1472 Sorghum (mutanda) Nyanga Renzva Manicaland food seed Mr & = Mrs J Tungadza 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 0 1 MMB135 1473 Sorghum (malawi) Nyanga Renzva Manicaland food seed Mr & = Mrs Tungadza 0 0 0 0 0 1 0 1 1 0 0 0 0 1 0 1 0 0 0 1 0 1 MMB136 1474 Sorghum (malawi) Nyanga Renzva Manicaland food seed Mr & = Mrs Tungadza 0 1 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 0 0 1 0 1 MMB137 1475 Sorghum (shodhani) Nyanga Renzva Manicaland "food, = beverage" seed Mr & Mrs Tungadza 0 1 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 1 = 0 1 0 MMB139 1477 Sorghum (chipemu) Nyanga Renzva Manicaland food seed Mr & = Mrs Tungadza 0 0 1 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB140 1478 Sorghum Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MMB142 1480 Sorghum Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 0 1 0 0 0 0 1 1 0 0 0 1 0 0 1 0 0 1 0 0 1 MMB143 1482 Sorghum Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 0 1 0 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 1 0 1 MMB145 1483 Nyamuwayawaya Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 1 0 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 1 0 MMB147 1485 Nzende Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 0 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 0 1 0 0 1 MMB149 1487 Sorghum Nyanga Renzva Manicaland food seed Mr & Mrs = Tungadza 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 1 0 0 0 1 1 0 MMB158 1496 Sweet sorghum Nyanga Renzva Manicaland food stalk Mr & Mrs = J Tungadza 0 1 0 0 0 0 0 1 1 0 0 1 0 0 1 0 0 0 0 1 1 0 TSH03 1499 Sorghum Tsholotsho Siyabalandela Matebeleland North high = "food, beverage" Mrs Rose Nxumalo 1 0 0 0 0 0 0 1 1 1 0 0 0 0 0 1 0 0 = 0 1 0 1 TSH25 1521 Sorghum Tsholotsho Siyabalandela Matebeleland North high = "food, beverage" seed Mrs Maggie Ndlovu 0 0 0 1 0 0 1 0 1 0 0 1 0 0 1 0 = 0 0 1 0 0 1 TSH27 1523 Sorghum (Isigobane) Tsholotsho Siyabalandela Matebeleland = North high "food, beverage" "seed, stalk" Mrs M Nxumale 0 1 0 0 0 0 0 1 = 1 0 0 0 1 0 1 0 0 0 0 1 1 0 TSH31 1527 Sorghum Tsholotsho Siyabalandela Matebeleland North high = "food, beverage" "stalk, seed" Mrs M Nxumale 0 1 0 0 0 0 0 1 1 0 0 0 1 = 0 0 0 0 1 0 1 1 1 TSH40 1535 Sorghum Tsholotsho Sizanani Matebeleland North low "food, = beverage" "seed, stalk, leaf" Mr George Ndebele 0 0 1 0 0 0 1 0 1 0 0 0 = 1 0 0 1 0 0 0 1 0 1 TSH42 1537 Sorghum Tsholotsho Sizanani Matebeleland North low "food, = beverage" "seed, stalk, leaf" Mr George Ndebele 0 0 0 1 0 0 0 1 1 0 0 0 = 1 0 0 1 0 0 0 1 1 0 TSH45 1540 Sorghum Tsholotsho Sizanani Matebeleland North low "food, = beverage" "seed, leaf" Mr George Ndebele 0 0 1 0 0 0 0 1 1 0 0 0 1 0 1 = 0 0 0 0 0 1 0 TSH55 1550 Sorghum Tsholotsho SizananiMabhanda Matebeleland North high = "food, beverage" "seed, stalk" Mrs Malethi Sibanda 0 1 0 0 0 0 0 1 1 0 = 0 0 1 0 0 1 0 0 0 1 0 1 TSH60 1555 Sorghum Tsholotsho SizananiMabhanda Matebeleland North high = "food, beverage" "seed, stalk, leaf" Mrs Malethi Sibanda 0 1 0 0 0 0 0 = 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 TSH61 1556 Sorghum Tsholotsho SizananiMabhanda Matebeleland North high = "food, beverage" "seed, stalk, leaf" Mrs Malethi Sibanda 0 0 0 0 0 1 0 = 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 TSH62 1557 Sorghum Tsholotsho SizananiMabhanda Matebeleland North low = "food, beverage" "seed, stalk, leaf" Mrs Malethi Sibanda 0 1 0 0 0 0 0 = 1 1 0 0 0 1 0 1 0 0 0 0 1 0 1 MZA10 1572 Sorghum Tsholotsho Siyazama Matebeleland North yes food seed = Mrs Mantombi Ndlovu 0 0 0 0 0 1 0 1 1 0 0 1 0 0 1 0 0 0 0 1 0 1 MZA30 1592 Sorghum Tsholotsho Siyazama Matebeleland North yes "food, = beverage" seed Mrs Selina Gumbo 0 0 0 0 0 1 0 1 1 1 0 0 0 0 1 0 0 0 0 1 = 0 1 MZA31 1593 Sorghum Tsholotsho Siyazama Matebeleland North yes "food, = beverage" seed Mrs Selina Gumbo 0 1 0 0 0 0 0 1 1 0 0 0 1 0 1 0 0 0 0 1 = 0 1 MZA73 1627 Sorghum Tsholotsho Phakamani Matebeleland North 0 0 0 0 = 1 0 0 1 1 0 1 0 0 0 1 0 0 0 0 1 0 1 ------_=_NextPart_000_01C35A53.75780090-- ==> 3648.audit <== Mon Aug 4 16:53:12 2003 ripley moved from incoming to Add-ons ==> 3648.reply.1 <== From maechler@stat.math.ethz.ch Thu Aug 14 09:25:26 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h7E7PQJH009616 for ; Thu, 14 Aug 2003 09:25:26 +0200 (MET DST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h7E7Oj0J021052; Thu, 14 Aug 2003 09:24:45 +0200 (MEST) Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id h7E7PMn20349; Thu, 14 Aug 2003 09:25:22 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16187.14690.336918.748433@gargle.gargle.HOWL> Date: Thu, 14 Aug 2003 09:25:22 +0200 To: m.grum@cgiar.org Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] hclust() and agnes() method="average" divergence (PR#3648) In-Reply-To: <200308040651.h746pUJH028091@pubhealth.ku.dk> References: <200308040651.h746pUJH028091@pubhealth.ku.dk> X-Mailer: VM 7.15 under Emacs 21.3.2 Reply-To: Martin Maechler X-Virus-Scanned: by amavisd-milter (http://amavis.org/) >>>>> "MikG" == m grum >>>>> on Mon, 4 Aug 2003 08:51:30 +0200 (MET DST) writes: MikG> Anyone have a clue why hclust() and agnes() produce MikG> different results in the example below when both use MikG> method="average"?? I'm not able to reproduce the MikG> problem with other datasets. MikG> ereck <- read.table("Ereck.txt",header=TRUE,sep="\t") MikG> emol <- subset(ereck,select=c(11:18,20:32)) MikG> library(cluster) MikG> library(mva) MikG> daisemol <- daisy(emol,type=list(asymm=c(1:21))) The reason is that most of the distances/dissimilarities are the same: there are only 20 different values in the 1326 distances. > sort(table(daisemol), decreasing=TRUE) starts as >> 0.666666666666667 0.5 0.8 0.285714285714286 >> 387 284 251 94 i.e. the distance 2/3 appears 387 times, 1/2 does 284 times, etc. With so many ties in the distances, choosing the next observation / cluster for "merging" is often chosing among many possibilities and hence the arbitrariness and the difference between too algorithms. For your situation, you might be able to use some continuous variable along with the factors and the many binary ones such that the distances won't have ties. NO bug! {i.e. you should have posted to R-help (you did have a good question!)} not R-bugs. Regards, Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3652 * Subject: Re: [Rd] R package {genetics} function summary.genotype -- H and From: Uwe Ligges Date: Mon, 04 Aug 2003 10:12:14 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3652 <== From ligges@amadeus.statistik.uni-dortmund.de Mon Aug 4 10:12:06 2003 Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h748C6JH029112 for ; Mon, 4 Aug 2003 10:12:06 +0200 (MET DST) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 77BF04AAC01; Mon, 4 Aug 2003 10:12:06 +0200 (MET DST) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id h748C6v11651; Mon, 4 Aug 2003 10:12:06 +0200 (MET DST) Message-ID: <3F2E155E.8030308@statistik.uni-dortmund.de> Date: Mon, 04 Aug 2003 10:12:14 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: gerard.tromp@sanger.med.wayne.edu Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] R package {genetics} function summary.genotype -- H and PIC return incorrect values. (PR#3642) References: <200308040245.h742j9JH027172@pubhealth.ku.dk> In-Reply-To: <200308040245.h742j9JH027172@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit gerard.tromp@sanger.med.wayne.edu wrote: > Greetings! > > I found a bug in the function summary.genotype (details below). Essentially > it appears that the original code from David Duffy used af, allele > frequency, as a proportion but in the genetics package af is allele > frequency as a count. > > I tried to submit a bug report together with the fix to CRAN (below). I am > unsure of the success since the bug report does not appear in the list. I am > therefore sending it by e-mail. Please submit bug reports related to contributed packages to the maintainer (in this case Gregory Warnes ), not to r-bugs. Uwe Ligges > Sincerely, > > Gerard > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Gerard Tromp, Ph.D. vox: 313-577-8773 > Center for Molecular Medicine and Genetics fax: 313-577-7736 > Wayne State Univ. Schl. of Medicine > 540 E. Canfield, Detroit, MI 48201 gtromp@cmb.biosci.wayne.edu > mailto:tromp@sanger.med.wayne.edu > http://cmmg.biosci.wayne.edu > > > > In function summary.genotype: > Heterozygosity (H) and PIC are computed using af (allele frequency), > however, af is derived as a frequency count whereas the computation of H and > PIC are in terms of frequency as a proportion. > > Using the example data provided (genetics.R) H and PIC return large negative > numbers whereas they are bounded 0,1. > > Output from buggy version: > ************************************************************************* > Marker: MBP2:C-104T (9q35:-104) Type: SNP > > Number persons typed: 100 (100%) > > Allele Frequency: (2 alleles) > Count Proportion > C 137 0.69 > T 63 0.32 > > > Genotype Frequency: > Count Proportion > C/C 59 0.59 > C/T 19 0.19 > T/T 22 0.22 > > Heterozygosity (Hu) = -22967 <------ Impossible > Poly. Inf. Content = -1.5e+08 <------ Impossible > *************************************************************************** > > Output from fixed version: > *************************************************************************** > Marker: MBP2:C-104T (9q35:-104) Type: SNP > > Number persons typed: 100 (100%) > > Allele Frequency: (2 alleles) > Count Proportion > C 137 0.69 > T 63 0.32 > > > Genotype Frequency: > Count Proportion > C/C 59 0.59 > C/T 19 0.19 > T/T 22 0.22 > > Heterozygosity (Hu) = 0.44 <--- Correct > Poly. Inf. Content = 0.34 <--- Correct > *************************************************************************** > > > > > Fix is detailed below. > ***************** 2539,2554 c 2539,2565 > ******************************************** > ### from code submitted by David Duffy > # > n.typed<-sum(gf) > correction<-n.typed/max(1,n.typed-1) > # Gerard Tromp 20030803 > # Heterozygosity and PIC reported are incorrect. > # Problem due to use of af which is a count rather than prop.table(af) a > # proportion (fraction) less than 1. Definition of af changed? > # > ## Original > # ehet<-(1-sum(af*af)) > # the following produces desired result > ehet<-(1-sum(prop.table(af)*prop.table(af))) > ## Original > # matings<- (af %*% t(af))^2 > # the following produces desired result > matings <- (prop.table(af) %*% t(prop.table(af)))^2 > uninf.mating.freq <- sum(matings)-sum(diag(matings)) > pic<- ehet - uninf.mating.freq > > retval$Hu <- correction * ehet > retval$pic <- pic > retval$n.typed <- n.typed > retval$n.total <- length(object) > retval$nallele <- nallele(object) > # > ### > **************************************************************************** > ****** > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel ==> 3652.audit <== Mon Aug 4 16:53:12 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4384 * Subject: wrong results in dist.binary (library ade4) From: c.duering@threads.de Date: Wed, 1 Oct 2003 22:48:23 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4384 <== From c.duering@threads.de Wed Oct 1 22:48:23 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h91KmN0P005555 for ; Wed, 1 Oct 2003 22:48:23 +0200 (MET DST) Date: Wed, 1 Oct 2003 22:48:23 +0200 (MET DST) Message-Id: <200310012048.h91KmN0P005555@pubhealth.ku.dk> From: c.duering@threads.de To: R-bugs@biostat.ku.dk Subject: wrong results in dist.binary (library ade4) MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Full_Name: Christian Düring Version: 1.6.2 OS: win32 Submission from: (NULL) (62.224.59.150) Function dist.binary in add-on library ade4 yields wrong results due to wrong association of method number and index formula. Examples: method=6 should be 5 (S7, Soerensen index) method=7 should be 6 (S9 index) Ochiai index is missing Same in current version of ade4 (ade4_1.04.zip). ==> 4384.audit <== Fri Oct 3 08:48:13 2003 maechler moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4403 * Subject: misprint in Leaps $size From: paulluo@cs.cmu.edu Date: Fri, 3 Oct 2003 22:17:24 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4403 <== From paulluo@cs.cmu.edu Fri Oct 3 22:17:27 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h93KHO0P000467 for ; Fri, 3 Oct 2003 22:17:26 +0200 (MET DST) Date: Fri, 3 Oct 2003 22:17:24 +0200 (MET DST) Message-Id: <200310032017.h93KHO0P000467@pubhealth.ku.dk> From: paulluo@cs.cmu.edu To: R-bugs@biostat.ku.dk Subject: misprint in Leaps $size Full_Name: Paul Li Version: 1.6.2 OS: Windows NT Submission from: (NULL) (128.2.203.251) The $size does not start with the models with only one variable, it starts with 2, ie, instead of 1 2 3... it starts with 2 3 4... This isn't that big of a deal cept that everything else, like $which and $Cp start with 1. Minor detail, I apologize for nit picking. $which 1 2 3 4 5 6 7 8 9 A B C D 1 FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE 1 FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE 1 FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE 2 TRUE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE 2 FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE 2 FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE 3 TRUE FALSE FALSE TRUE FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE ... $label [1] "(Intercept)" "1" "2" "3" "4" [6] "5" "6" "7" "8" "9" [11] "A" "B" "C" "D" $size [1] 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 10 10 [28] 11 11 11 12 12 12 13 13 13 14 $Cp [1] 10.3556013 20.9834809 36.1314911 3.3146028 5.3535009 6.8232717 0.2356971 [8] ==> 4403.audit <== Mon Oct 6 12:24:55 2003 maechler moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4688 * Subject: bug in fisher test---p-value cannot be Inf From: kjetil@entelnet.bo Date: Mon, 20 Oct 2003 14:17:42 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4688 <== From mailnull@stat.math.ethz.ch Mon Oct 20 20:18:10 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9KIIA0P018313 for ; Mon, 20 Oct 2003 20:18:10 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h9KIGlq6008533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Oct 2003 20:16:48 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id h9KIGk1J008526 for R-bugs@biostat.ku.dk; Mon, 20 Oct 2003 20:16:46 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h9KIGWq5008462 for ; Mon, 20 Oct 2003 20:16:33 +0200 (MEST) Received: from mailgate.entelnet.bo ([200.87.100.12]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 1ABebD-0008Qj-00 for ; Mon, 20 Oct 2003 13:17:47 -0500 Received: from personal-apzxmv ([166.114.85.51]) by mailgate.entelnet.bo (8.12.9/8.12.9) with ESMTP id h9K9nr7r028601 for ; Mon, 20 Oct 2003 13:49:55 +0400 From: kjetil@entelnet.bo To: r-bugs@r-project.org Date: Mon, 20 Oct 2003 14:17:42 -0400 MIME-Version: 1.0 Subject: bug in fisher test---p-value cannot be Inf Message-ID: <3F93EE86.6818.19B8D6@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=ISO-8859-1 Content-description: Mail message body X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by stat.math.ethz.ch id h9KIGWq5008462 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hypatia X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 X-Spam-Level: I just found a bug in fisher.test(). This is rw1080, on windows XP. A p-value can certainly not be Inf, but: > religion Costumbres rel orig Religion Si Algunas veces Nunca católica 2121 4700 6234 prot/evan 100 216 2461 otra C 27 67 502 otra 0 0 14 > fisher.test(religion, workspace=2000000) Fisher's Exact Test for Count Data data: religion p-value = Inf alternative hypothesis: two.sided Kjetil Halvorsen ==> 4688.reply.1 <== From maechler@stat.math.ethz.ch Wed Oct 22 17:44:48 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9MFil0P015638 for ; Wed, 22 Oct 2003 17:44:48 +0200 (MET DST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h9MFhTq6023518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2003 17:43:29 +0200 (MEST) Received: (from maechler@localhost) by lynne.ethz.ch (8.12.8/8.12.8/Submit) id h9MFiiJ7003947; Wed, 22 Oct 2003 17:44:44 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <16278.42476.104364.931683@gargle.gargle.HOWL> Date: Wed, 22 Oct 2003 17:44:44 +0200 To: kjetil@entelnet.bo Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] bug in fisher test---p-value cannot be Inf (PR#4688) In-Reply-To: <200310201818.h9KIIB0P018317@pubhealth.ku.dk> References: <200310201818.h9KIIB0P018317@pubhealth.ku.dk> X-Mailer: VM 7.17 under Emacs 21.3.2 Reply-To: Martin Maechler X-Virus-Scanned: by amavisd-milter (http://amavis.org/) >>>>> "kjetil" == kjetil halvorsen >>>>> on Mon, 20 Oct 2003 20:18:11 +0200 (MET DST) writes: kjetil> I just found a bug in fisher.test(). This is rw1080, on windows XP. kjetil> A p-value can certainly not be Inf, but: Thank you, Kjetil. The bug does not seem to be version or platform dependent, I see the same on Linux R versions 1.8.0, 1.7.1, 1.5.x. >> religion kjetil> Costumbres rel orig kjetil> Religion Si Algunas veces Nunca kjetil> católica 2121 4700 6234 kjetil> prot/evan 100 216 2461 kjetil> otra C 27 67 502 kjetil> otra 0 0 14 Please use something like dput() for example data in bug reports. That way, others can easily use the same data; alternatively, the following is sufficient to reproduce the bug : religion <- cbind(Si = c(2121, 100, 27, 0), av = c(4700, 216, 67, 0), Nc = c(6234,2461,502,14)) >> fisher.test(religion, workspace=2000000) kjetil> Fisher's Exact Test for Count Data kjetil> data: religion kjetil> p-value = Inf kjetil> alternative hypothesis: two.sided Note that this is not the first bug report on fisher.test()... we have more cases that don't behave as desired, but these at least give error messages instead of non-sensical results. I have ordered the original papers and started reading them.. Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ==> 4688.audit <== Wed Nov 5 09:11:55 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4724 * Subject: Core dump when calling tclvalue From: mckay@gmr.com Date: Wed, 22 Oct 2003 19:10:02 +0200 (MET DST) --it would seem that we're just not failing gracefully ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4724 <== From mckay@gmr.com Wed Oct 22 19:10:03 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9MHA20P016147 for ; Wed, 22 Oct 2003 19:10:03 +0200 (MET DST) Date: Wed, 22 Oct 2003 19:10:02 +0200 (MET DST) Message-Id: <200310221710.h9MHA20P016147@pubhealth.ku.dk> From: mckay@gmr.com To: R-bugs@biostat.ku.dk Subject: Core dump when calling tclvalue Full_Name: Neil McKay Version: 1.8.0 OS: Linux (RedHat 7.1) Submission from: (NULL) (129.124.42.210) I get a core dump when executing the following code: > library("tcltk") > zzz<-tclArray() > tclvalue(zzz) Running under gdb gives this output: Program received signal SIGSEGV, Segmentation fault. makeRTclObject (tclobj=0x0) at tcltk.c:48 48 Tcl_IncrRefCount(tclobj); ==> 4724.reply.1 <== From p.dalgaard@biostat.ku.dk Wed Oct 22 19:58:12 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9MHwB0P016470; Wed, 22 Oct 2003 19:58:12 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h9MI1nxl015816; Wed, 22 Oct 2003 20:01:49 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h9MI1m6I015812; Wed, 22 Oct 2003 20:01:48 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: mckay@gmr.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Core dump when calling tclvalue (PR#4724) References: <200310221710.h9MHA40P016151@pubhealth.ku.dk> From: Peter Dalgaard Date: 22 Oct 2003 20:01:48 +0200 In-Reply-To: <200310221710.h9MHA40P016151@pubhealth.ku.dk> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii mckay@gmr.com writes: > Full_Name: Neil McKay > Version: 1.8.0 > OS: Linux (RedHat 7.1) > Submission from: (NULL) (129.124.42.210) > > > I get a core dump when executing the following code: > > > library("tcltk") > > zzz<-tclArray() > > tclvalue(zzz) > > Running under gdb gives this output: > > Program received signal SIGSEGV, Segmentation fault. > makeRTclObject (tclobj=0x0) at tcltk.c:48 > 48 Tcl_IncrRefCount(tclobj); Hmm. That's not supposed to happen. I'm not sure it is supposed to do anything useful either though. The wish equivalent is % array set x "" % puts $x can't read "x": variable is array so it would seem that we're just not failing gracefully. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 4724.audit <== Sun Nov 9 14:40:38 2003 ripley moved from incoming to Add-ons Thu Jun 17 01:46:33 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5315 * Subject: O2 optimization produces wrong code From: jean.coursol@math.u-psud.fr Date: Tue, 25 Nov 2003 15:51:21 +0100 (CET) --report on akima ... known problem ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5315 <== From jean.coursol@math.u-psud.fr Tue Nov 25 15:51:22 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id E7469EFC5 for ; Tue, 25 Nov 2003 15:51:21 +0100 (CET) From: jean.coursol@math.u-psud.fr To: R-bugs@biostat.ku.dk Subject: O2 optimization produces wrong code Message-Id: <20031125145121.E7469EFC5@slim.kubism.ku.dk> Date: Tue, 25 Nov 2003 15:51:21 +0100 (CET) Full_Name: jean coursol Version: 1.7.1, 1.8.0 OS: linux & Windows-XP Submission from: (NULL) (129.175.52.7) Binary MS-Windows akima module from CRAN (1.8.0 version) produces wrong results with some data. Installing akima source in linux, with same data: -with gcc-2.95.3 -O2 : give correct results (under R 1.7.1); -with gcc-3.2.3 -O2 : give wrong results (under R-1.7.1 and R-1.8.0); -with gcc-3.2.3 (no optimization) give correct results (under R-1.7.1 and R-1.8.0); Installing akima module made by RCrossBuild (with gcc-2.95.3, R-1.7.1) in Windows-XP and R-1.8.0 gives correct results (it is possible to use cross-compiled akima module using R-1.7.1, because there is no call from akima to R...). It would be better to use RCrossBuild and R-1.8.0, but actually, RCrossBuild is not running with gcc-3.2.3 and R-1.8.0... ==> 5315.followup.1 <== From dmurdoch@pair.com Tue Nov 25 16:29:15 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from fisher.stats.uwo.ca (fisher.stats.uwo.ca [129.100.45.201]) by slim.kubism.ku.dk (Postfix) with ESMTP id 2AFBCF329 for ; Tue, 25 Nov 2003 16:29:14 +0100 (CET) Received: from djm.stats.uwo.ca (djm.stats.uwo.ca [129.100.45.113]) by fisher.stats.uwo.ca (8.11.6/linuxconf) with SMTP id hAPFTPc30166; Tue, 25 Nov 2003 10:29:25 -0500 From: Duncan Murdoch To: jean.coursol@math.u-psud.fr Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] O2 optimization produces wrong code (PR#5315) Date: Tue, 25 Nov 2003 10:29:39 -0500 Message-ID: References: <20031125145122.7E437F7E3@slim.kubism.ku.dk> In-Reply-To: <20031125145122.7E437F7E3@slim.kubism.ku.dk> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, 25 Nov 2003 15:51:22 +0100 (CET), jean.coursol@math.u-psud.fr wrote : >Full_Name: jean coursol >Version: 1.7.1, 1.8.0 >OS: linux & Windows-XP >Submission from: (NULL) (129.175.52.7) > > >Binary MS-Windows akima module from CRAN (1.8.0 version) produces wrong results >with some data. This isn't an R bug, it's a contributed package bug. You should write to the package maintainer Albrecht Gebhardt and the Windows binary package maintainer Uwe Ligges , including code to reproduce the bug. I'd suggest trying it with 1.8.1 first; it's possible you were seeing the effects of some other bug that has been fixed. Duncan Murdoch ==> 5315.followup.2 <== From ripley@stats.ox.ac.uk Tue Nov 25 16:47:10 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id E5A49EDF1 for ; Tue, 25 Nov 2003 16:47:09 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id hAPFl7oO014608; Tue, 25 Nov 2003 15:47:07 GMT Date: Tue, 25 Nov 2003 15:47:01 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: Duncan Murdoch Cc: jean.coursol@math.u-psud.fr, , Subject: Re: [Rd] O2 optimization produces wrong code (PR#5315) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a long-known problem: one example is the MASS example in the script ch15.R, and that has gone wrong on platforms other than Windows. It has been reported to the maintainer in the past. On Tue, 25 Nov 2003, Duncan Murdoch wrote: > On Tue, 25 Nov 2003 15:51:22 +0100 (CET), jean.coursol@math.u-psud.fr > wrote : > > >Full_Name: jean coursol > >Version: 1.7.1, 1.8.0 > >OS: linux & Windows-XP > >Submission from: (NULL) (129.175.52.7) > > > > > >Binary MS-Windows akima module from CRAN (1.8.0 version) produces wrong results > >with some data. > > This isn't an R bug, it's a contributed package bug. You should write > to the package maintainer Albrecht Gebhardt > and the Windows binary package > maintainer Uwe Ligges , including > code to reproduce the bug. > > I'd suggest trying it with 1.8.1 first; it's possible you were seeing > the effects of some other bug that has been fixed. > > Duncan Murdoch > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 5315.audit <== Mon Dec 8 13:51:24 2003 ripley changed notes Mon Dec 8 13:51:24 2003 ripley foobar Mon Dec 8 13:51:24 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5476 * Subject: memory leak From: schiessler@agere.com Date: Wed, 3 Dec 2003 06:01:57 +0100 (CET) --report on R-Excel, it seems. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5476 <== From schiessler@agere.com Wed Dec 3 06:01:58 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id B4CD2EC44 for ; Wed, 3 Dec 2003 06:01:57 +0100 (CET) From: schiessler@agere.com To: R-bugs@biostat.ku.dk Subject: memory leak Message-Id: <20031203050157.B4CD2EC44@slim.kubism.ku.dk> Date: Wed, 3 Dec 2003 06:01:57 +0100 (CET) Full_Name: g. schiessler Version: 1.8.1 OS: Windows 2000 Pro Submission from: (NULL) (24.229.106.55) Appears to be memory leak with =RApply("qnorm",K56)*-1 function from within Excel 2000. Have spreadsheet with between 100 and 500 of above references. When spreadsheet first opened system using about 200MB but very quickly grows to over 600MB and appears to be unlimited. Is there another way to run qnorm from within Excel with less memory? ==> 5476.followup.1 <== From ripley@stats.ox.ac.uk Wed Dec 3 08:52:02 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id D66E1EDF5 for ; Wed, 3 Dec 2003 08:52:01 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id hB37pvoO021217; Wed, 3 Dec 2003 07:51:57 GMT Date: Wed, 3 Dec 2003 07:51:49 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: schiessler@agere.com Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] memory leak (PR#5476) In-Reply-To: <20031203050158.86615EC53@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That appears to have been garbled en route. Could you please take a look at the FAQ and submit a reproducible example along the lines suggested there. On the face of it this appears to be a bug report on Excel 2000, but you may be using an R addin without mentioning it. On Wed, 3 Dec 2003 schiessler@agere.com wrote: > Full_Name: g. schiessler > Version: 1.8.1 > OS: Windows 2000 Pro > Submission from: (NULL) (24.229.106.55) > > > Appears to be memory leak with > =RApply("qnorm",K56)*-1 function Is that line really correct? If so, what does it have to do with R? > from within Excel 2000. > Have spreadsheet with between > 100 and 500 of above references. > When spreadsheet first opened > system using about 200MB but > very quickly grows to over 600MB > and appears to be unlimited. > Is there another way to run qnorm > from within Excel with less memory? > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 5476.followup.2 <== From schiessler@agere.com Wed Dec 3 17:11:43 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from alageremail1.agere.com (alageremail1.agere.com [192.19.192.106]) by slim.kubism.ku.dk (Postfix) with ESMTP id 804CCEFC4 for ; Wed, 3 Dec 2003 17:11:42 +0100 (CET) Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail1.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hB3GBfM03954; Wed, 3 Dec 2003 11:11:41 -0500 (EST) Received: from pai820exchag02.ags.agere.com (pai820exchag02.agere.com [135.14.2.213]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hB3GBfw01948; Wed, 3 Dec 2003 11:11:41 -0500 (EST) Received: by pai820exchag02.agere.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 11:11:41 -0500 Message-ID: <3FCE0B37.89A2D4C7@agere.com> From: "Schiessler, Gary E (Gary)" To: Prof Brian Ripley Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] memory leak (PR#5476) Date: Wed, 3 Dec 2003 11:11:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3B9B8.1F7E5580" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3B9B8.1F7E5580 Content-Type: text/plain; charset="iso-8859-1" Prof Ripley, I have attached a sample Excel spreadsheet containing approx 500 RApply("qnorm"... references. When I repeatedly re-calc cell references, either automatically or manually (F9), the memory usage on my system increases with each re-calc seemingly without bound. The more RApply references the greater the incremental memory consumption. I'm using Excel 2000 (9.0.4402 SR-1) runnning under Microsoft Windows 2000 5.00.2195 SP3 on an IBM T21 laptop with 256MB of memory. I'm running R 1.8.1 > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 1 minor 8.1 year 2003 month 11 day 21 language R with RExcel version 1.0 and R DCOM server version 1.2 If you need any additional information please let me know. Thanks, Gary Schiessler Agere Systems Prof Brian Ripley wrote: > That appears to have been garbled en route. > Could you please take a look at the FAQ and submit > a reproducible example along the lines suggested there. > > On the face of it this appears to be a bug report on Excel 2000, > but you may be using an R addin without mentioning it. > > On Wed, 3 Dec 2003 schiessler@agere.com wrote: > > > Full_Name: g. schiessler > > Version: 1.8.1 > > OS: Windows 2000 Pro > > Submission from: (NULL) (24.229.106.55) > > > > > > Appears to be memory leak with > > =RApply("qnorm",K56)*-1 function > > Is that line really correct? If so, what does it have to do with R? > > > from within Excel 2000. > > Have spreadsheet with between > > 100 and 500 of above references. > > When spreadsheet first opened > > system using about 200MB but > > very quickly grows to over 600MB > > and appears to be unlimited. > > Is there another way to run qnorm > > from within Excel with less memory? > > > > ______________________________________________ > > R-devel@stat.math.ethz.ch mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 ------_=_NextPart_000_01C3B9B8.1F7E5580 Content-Type: application/vnd.ms-excel; name="RApply mem leak.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RApply mem leak.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAFIAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAP4czQfJQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAACgAAc2NoaWVzc2xlciAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQYA AQACAAMAnAACAA4AGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAFgCwgFsOfsiOAAA AAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAGgDIAAAA/3+QAQAA AAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+Q AQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAEA /3+8AgAAAAIAAAUBQQByAGkAYQBsADEAGgBoAQEA/3+8AgAAAAIAAAUBQQByAGkAYQBsAB4EHAAF ABcAACIkIiMsIyMwXyk7XCgiJCIjLCMjMFwpHgQhAAYAHAAAIiQiIywjIzBfKTtbUmVkXVwoIiQi IywjIzBcKR4EIgAHAB0AACIkIiMsIyMwLjAwXyk7XCgiJCIjLCMjMC4wMFwpHgQnAAgAIgAAIiQi IywjIzAuMDBfKTtbUmVkXVwoIiQiIywjIzAuMDBcKR4ENwAqADIAAF8oIiQiKiAjLCMjMF8pO18o IiQiKiBcKCMsIyMwXCk7XygiJCIqICItIl8pO18oQF8pHgQuACkAKQAAXygqICMsIyMwXyk7Xygq IFwoIywjIzBcKTtfKCogIi0iXyk7XyhAXykeBD8ALAA6AABfKCIkIiogIywjIzAuMDBfKTtfKCIk IiogXCgjLCMjMC4wMFwpO18oIiQiKiAiLSI/P18pO18oQF8pHgQ2ACsAMQAAXygqICMsIyMwLjAw Xyk7XygqIFwoIywjIzAuMDBcKTtfKCogIi0iPz9fKTtfKEBfKR4EDwCkAAoAADAuMDAwMEUrMDAe BAwApQAHAAAwLjAwMDAwHgQNAKYACAAAMC4wMDAwMDDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDg ABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/ IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAA AAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA 9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAA AAEAIAAAAAAAAAAAAAAAwCDgABQAAQArAPX/IAAA+AAAAAAAAAAAwCDgABQAAQApAPX/IAAA+AAA AAAAAAAAwCDgABQAAQAsAPX/IAAA+AAAAAAAAAAAwCDgABQAAQAqAPX/IAAA+AAAAAAAAAAAwCDg ABQAAQAJAPX/IAAA+AAAAAAAAAAAwCDgABQAAAAAAAEAIgAAEAAAAAAAAAAAwCDgABQABQAAAAEA IgAAGAAAAAAAAAAAwCDgABQAAAALAAEAIgAAFAAAAAAAAAAAwCDgABQAAACmAAEAIgAAFAAAAAAA AAAAwCDgABQABgAAAAEAIQAAGAAAAAAAAAAAwCCTAgQAEIAD/5MCBAARgAb/kwIEABKABP+TAgQA E4AH/5MCBAAAgAD/kwIEABSABf9gAQIAAACFAA4A0wcAAAAABgBTaGVldDGFAA4AzYEAAAAABgBT aGVldDKFAA4A1IIAAAAABgBTaGVldDOMAAQAAQABAK4BaAAFAC4AAAECUHJvZ3JhbSBGaWxlcwNS AyhEKUNPTSBTZXJ2ZXIDeGxzA1JFeGNlbC54bGEGAABTaGVldDEKAABSQ29weVNoZWV0BgAAU2hl ZXQyCgAAUkljb25TaGVldAYAAENvbmZpZyMAEAAAAAAAAAAGAFJBcHBseQAAWQAEAAAAAABZAAQA AAABAFkABAAAAAIAWQAEAAAAAwBZAAQAAAAEAK4BBAADAAEEFwAOAAIAAAD+//7/AQAAAAAAGAAb ACAAAAELAAAAAQAAAAAAAAY7AQAAADcAAAABAMEBCADBAQAAYGkBAPwAdAAXAAAABQAAAAUAAHFu b3JtBwAAUiAxLjguMQUAAChCRVIpBQAAUHJvYi5HAABUZXN0IGNhc2UgZm9yIGFwcGFyZW50IG1l bW9yeSBsZWFrIGluIFJBcHBseSBmdW5jdGlvbiBlbWJlZGRlZCBpbiBFeGNlbP8ACgAIAFUHAAAM AAAACgAAAAkIEAAABhAA/hzNB8lAAAAGAQAACwIwAAAAAAAAAAAA5AAAAG0QAAAOTQAAxn8AAP5/ AAAGgAAADoAAABaAAADwgAAAfoEAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQ P18AAgABACoAAgAAACsAAgABAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEFFAAAABUA AACDAAIAAQCEAAIAAQAmAAgAAAAAAAAAAAAnAAgAAAAAAAAAAAAoAAgAAAAAAAAA4D8pAAgAAAAA AAAA4D9NAI4HAABoAHAAIABkAGUAcwBrAGoAZQB0ACAAOQA5ADAAYwAgAHMAZQByAGkAZQBzACAA TABQAFQAAAAAAAAAAAAAAAAAAQQdQNwAsAYD34AHAgABAAAAAABkAAEABwBYAgIAAwAAAAMAAABy AHYAQwBvAG4AdgBlAHIAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAADAAAAEQQAAAEAAAAAAAAAAAAAAAAAAAAA AAAAPoNlhwHM2roAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMzaugAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8BAAAAQAAAAAAAAABSAwAATAQAAAAAAAAAAAAA AQAAAAAAAABkAAAAAAAAAAEAAAD7/wAAAAAAAGgAcAAgAGQAZQBzAGsAagBlAHQAIAA5ADkAMABj ACAAcwBlAHIAaQBlAHMAIABMAFAAVAAAACAAOQA5ADAAYwAgAHMAZQByAGkAZQBzACwATABvAGMA YQBsAE8AbgBsAHkALABEAHIAdgBDAG8AbgB2AGUAcgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD6DZYehACIAAQA/AAEAAQABAAAAWAJYAgAAAAAAAOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAAA SQsVAAIAAAB9AAwAAQABANsLFQACAAAAfQAMAAIACgDbCw8ABgAAAAACDgAAAAAA5AAAAAAACwAA AAgCEAAAAAAACwDRAQAAAAAAAQ8ACAIQAAEAAAALAP8AAAAAAAABDwAIAhAAAgAAAAsA/wAAAAAA AAEPAAgCEAADAAAACwD/AAAAAACAARYACAIQAAQAAAALAP8AAAAAAAABDwAIAhAABQAAAAsA/wAA AAAAAAEPAAgCEAAGAAAACwD/AAAAAAAAAQ8ACAIQAAcAAAALAP8AAAAAAAABDwAIAhAACAAAAAsA /wAAAAAAAAEPAAgCEAAJAAAACwD/AAAAAAAAAQ8ACAIQAAoAAAALAP8AAAAAAAABDwAIAhAACwAA AAsA/wAAAAAAAAEPAAgCEAAMAAAACwD/AAAAAAAAAQ8ACAIQAA0AAAALAP8AAAAAAAABDwAIAhAA DgAAAAsA/wAAAAAAAAEPAAgCEAAPAAAACwD/AAAAAAAAAQ8ACAIQABAAAAALAP8AAAAAAAABDwAI AhAAEQAAAAsA/wAAAAAAAAEPAAgCEAASAAAACwD/AAAAAAAAAQ8ACAIQABMAAAALAP8AAAAAAAAB DwAIAhAAFAAAAAsA/wAAAAAAAAEPAAgCEAAVAAAACwD/AAAAAAAAAQ8ACAIQABYAAAALAP8AAAAA AAABDwAIAhAAFwAAAAsA/wAAAAAAAAEPAAgCEAAYAAAACwD/AAAAAAAAAQ8ACAIQABkAAAALAP8A AAAAAAABDwAIAhAAGgAAAAsA/wAAAAAAAAEPAAgCEAAbAAAACwD/AAAAAAAAAQ8ACAIQABwAAAAL AP8AAAAAAAABDwAIAhAAHQAAAAsA/wAAAAAAAAEPAAgCEAAeAAAACwD/AAAAAAAAAQ8ACAIQAB8A AAALAP8AAAAAAAABDwD9AAoAAAAAABkABAAAAAECBgABAAAAFgD9AAoAAgAAABYAAwAAAP0ACgAC AAEAFgABAAAA/QAKAAIAAgAWAAEAAAD9AAoAAgADABYAAQAAAP0ACgACAAQAFgABAAAA/QAKAAIA BQAWAAEAAAD9AAoAAgAGABYAAQAAAP0ACgACAAcAFgABAAAA/QAKAAIACAAWAAEAAAD9AAoAAgAJ ABYAAQAAAP0ACgACAAoAFgABAAAA/QAKAAMAAAAWAAIAAAD9AAoAAwABABYAAAAAAP0ACgADAAIA FgAAAAAA/QAKAAMAAwAWAAAAAAD9AAoAAwAEABYAAAAAAP0ACgADAAUAFgAAAAAA/QAKAAMABgAW AAAAAAD9AAoAAwAHABYAAAAAAP0ACgADAAgAFgAAAAAA/QAKAAMACQAWAAAAAAD9AAoAAwAKABYA AAAAAH4CCgAEAAAAFwABACRABgAuAAQAAQAYADNt4jY8gfS/AQAAAOD9GAA5AAABAAAAFwUAcW5v cm0kBAAAgEID/wAGAC4ABAACABgAM23iNjyB9L8BADcAAf8YADkAAAEAAAAXBQBxbm9ybSQEAACA QgP/AAYALgAEAAMAGAAzbeI2PIH0vwEANwAC/xgAOQAAAQAAABcFAHFub3JtJAQAAIBCA/8ABgAu AAQABAAYADNt4jY8gfS/AQA3AAP/GAA5AAABAAAAFwUAcW5vcm0kBAAAgEID/wAGAC4ABAAFABgA M23iNjyB9L8BADcABP8YADkAAAEAAAAXBQBxbm9ybSQEAACAQgP/AAYALgAEAAYAGAAzbeI2PIH0 vwEANwAF/xgAOQAAAQAAABcFAHFub3JtJAQAAIBCA/8ABgAuAAQABwAYADNt4jY8gfS/AQA3AAb/ GAA5AAABAAAAFwUAcW5vcm0kBAAAgEID/wAGAC4ABAAIABgAM23iNjyB9L8BADcAB/8YADkAAAEA AAAXBQBxbm9ybSQEAACAQgP/AAYALgAEAAkAGAAzbeI2PIH0vwEANwAI/xgAOQAAAQAAABcFAHFu b3JtJAQAAIBCA/8ABgAuAAQACgAYADNt4jY8gfS/AQA3AAn/GAA5AAABAAAAFwUAcW5vcm0kBAAA gEID/wB+AgoABQAAABcAAQDwPwYALgAFAAEAGAAO/zBGXJwCwAEABAAB/xgAOQAAAQAAABcFAHFu b3JtJAUAAIBCA/8ABgAuAAUAAgAYAA7/MEZcnALAAQAEAAL/GAA5AAABAAAAFwUAcW5vcm0kBQAA gEID/wAGAC4ABQADABgADv8wRlycAsABAAQAA/8YADkAAAEAAAAXBQBxbm9ybSQFAACAQgP/AAYA LgAFAAQAGAAO/zBGXJwCwAEABAAE/xgAOQAAAQAAABcFAHFub3JtJAUAAIBCA/8ABgAuAAUABQAY AA7/MEZcnALAAQAEAAX/GAA5AAABAAAAFwUAcW5vcm0kBQAAgEID/wAGAC4ABQAGABgADv8wRlyc AsABAAQABv8YADkAAAEAAAAXBQBxbm9ybSQFAACAQgP/AAYALgAFAAcAGAAO/zBGXJwCwAEABAAH /xgAOQAAAQAAABcFAHFub3JtJAUAAIBCA/8ABgAuAAUACAAYAA7/MEZcnALAAQAEAAj/GAA5AAAB AAAAFwUAcW5vcm0kBQAAgEID/wAGAC4ABQAJABgADv8wRlycAsABAAQACf8YADkAAAEAAAAXBQBx bm9ybSQFAACAQgP/AAYALgAFAAoAGAAO/zBGXJwCwAEABAAK/xgAOQAAAQAAABcFAHFub3JtJAUA AIBCA/8AAwIOAAYAAAAXAPyp8dJNYlA/BgAuAAYAAQAYAHBEILfLuAjAAQAFAAH/GAA5AAABAAAA FwUAcW5vcm0kBgAAgEID/wAGAC4ABgACABgAcEQgt8u4CMABAAUAAv8YADkAAAEAAAAXBQBxbm9y bSQGAACAQgP/AAYALgAGAAMAGABwRCC3y7gIwAEABQAD/xgAOQAAAQAAABcFAHFub3JtJAYAAIBC A/8ABgAuAAYABAAYAHBEILfLuAjAAQAFAAT/GAA5AAABAAAAFwUAcW5vcm0kBgAAgEID/wAGAC4A BgAFABgAcEQgt8u4CMABAAUABf8YADkAAAEAAAAXBQBxbm9ybSQGAACAQgP/AAYALgAGAAYAGABw RCC3y7gIwAEABQAG/xgAOQAAAQAAABcFAHFub3JtJAYAAIBCA/8ABgAuAAYABwAYAHBEILfLuAjA AQAFAAf/GAA5AAABAAAAFwUAcW5vcm0kBgAAgEID/wAGAC4ABgAIABgAcEQgt8u4CMABAAUACP8Y ADkAAAEAAAAXBQBxbm9ybSQGAACAQgP/AAYALgAGAAkAGABwRCC3y7gIwAEABQAJ/xgAOQAAAQAA ABcFAHFub3JtJAYAAIBCA/8ABgAuAAYACgAYAHBEILfLuAjAAQAFAAr/GAA5AAABAAAAFwUAcW5v cm0kBgAAgEID/wADAg4ABwAAABcALUMc6+I2Gj8GAC4ABwABABgAOokSt4vADcABAAYAAf8YADkA AAEAAAAXBQBxbm9ybSQHAACAQgP/AAYALgAHAAIAGAA6iRK3i8ANwAEABgAC/xgAOQAAAQAAABcF AHFub3JtJAcAAIBCA/8ABgAuAAcAAwAYADqJEreLwA3AAQAGAAP/GAA5AAABAAAAFwUAcW5vcm0k BwAAgEID/wAGAC4ABwAEABgAOokSt4vADcABAAYABP8YADkAAAEAAAAXBQBxbm9ybSQHAACAQgP/ AAYALgAHAAUAGAA6iRK3i8ANwAEABgAF/xgAOQAAAQAAABcFAHFub3JtJAcAAIBCA/8ABgAuAAcA BgAYADqJEreLwA3AAQAGAAb/GAA5AAABAAAAFwUAcW5vcm0kBwAAgEID/wAGAC4ABwAHABgAOokS t4vADcABAAYAB/8YADkAAAEAAAAXBQBxbm9ybSQHAACAQgP/AAYALgAHAAgAGAA6iRK3i8ANwAEA BgAI/xgAOQAAAQAAABcFAHFub3JtJAcAAIBCA/8ABgAuAAcACQAYADqJEreLwA3AAQAGAAn/GAA5 AAABAAAAFwUAcW5vcm0kBwAAgEID/wAGAC4ABwAKABgAOokSt4vADcABAAYACv8YADkAAAEAAAAX BQBxbm9ybSQHAACAQgP/AAMCDgAIAAAAFwDxaOOItfjkPgYALgAIAAEAGADZo0OIPw8RwAEABwAB /xgAOQAAAQAAABcFAHFub3JtJAgAAIBCA/8ABgAuAAgAAgAYANmjQ4g/DxHAAQAHAAL/GAA5AAAB AAAAFwUAcW5vcm0kCAAAgEID/wAGAC4ACAADABgA2aNDiD8PEcABAAcAA/8YADkAAAEAAAAXBQBx bm9ybSQIAACAQgP/AAYALgAIAAQAGADZo0OIPw8RwAEABwAE/xgAOQAAAQAAABcFAHFub3JtJAgA AIBCA/8ABgAuAAgABQAYANmjQ4g/DxHAAQAHAAX/GAA5AAABAAAAFwUAcW5vcm0kCAAAgEID/wAG AC4ACAAGABgA2aNDiD8PEcABAAcABv8YADkAAAEAAAAXBQBxbm9ybSQIAACAQgP/AAYALgAIAAcA GADZo0OIPw8RwAEABwAH/xgAOQAAAQAAABcFAHFub3JtJAgAAIBCA/8ABgAuAAgACAAYANmjQ4g/ DxHAAQAHAAj/GAA5AAABAAAAFwUAcW5vcm0kCAAAgEID/wAGAC4ACAAJABgA2aNDiD8PEcABAAcA Cf8YADkAAAEAAAAXBQBxbm9ybSQIAACAQgP/AAYALgAIAAoAGADZo0OIPw8RwAEABwAK/xgAOQAA AQAAABcFAHFub3JtJAgAAIBCA/8AAwIOAAkAAAAXAI3ttaD3xrA+BgAuAAkAAQAYAH6feamBAxPA AQAIAAH/GAA5AAABAAAAFwUAcW5vcm0kCQAAgEID/wAGAC4ACQACABgAfp95qYEDE8ABAAgAAv8Y ADkAAAEAAAAXBQBxbm9ybSQJAACAQgP/AAYALgAJAAMAGAB+n3mpgQMTwAEACAAD/xgAOQAAAQAA ABcFAHFub3JtJAkAAIBCA/8ABgAuAAkABAAYAH6feamBAxPAAQAIAAT/GAA5AAABAAAAFwUAcW5v cm0kCQAAgEID/wAGAC4ACQAFABgAfp95qYEDE8ABAAgABf8YADkAAAEAAAAXBQBxbm9ybSQJAACA QgP/AAYALgAJAAYAGAB+n3mpgQMTwAEACAAG/xgAOQAAAQAAABcFAHFub3JtJAkAAIBCA/8ABgAu AAkABwAYAH6feamBAxPAAQAIAAf/GAA5AAABAAAAFwUAcW5vcm0kCQAAgEID/wAGAC4ACQAIABgA fp95qYEDE8ABAAgACP8YADkAAAEAAAAXBQBxbm9ybSQJAACAQgP/AAYALgAJAAkAGAB+n3mpgQMT wAEACAAJ/xgAOQAAAQAAABcFAHFub3JtJAkAAIBCA/8ABgAuAAkACgAYAH6feamBAxPAAQAIAAr/ GAA5AAABAAAAFwUAcW5vcm0kCQAAgEID/wADAg4ACgAAABcASK+8mvLXej4GAC4ACgABABgABoex Jh/MFMABAAkAAf8YADkAAAEAAAAXBQBxbm9ybSQKAACAQgP/AAYALgAKAAIAGAAGh7EmH8wUwAEA CQAC/xgAOQAAAQAAABcFAHFub3JtJAoAAIBCA/8ABgAuAAoAAwAYAAaHsSYfzBTAAQAJAAP/GAA5 AAABAAAAFwUAcW5vcm0kCgAAgEID/wAGAC4ACgAEABgABoexJh/MFMABAAkABP8YADkAAAEAAAAX BQBxbm9ybSQKAACAQgP/AAYALgAKAAUAGAAGh7EmH8wUwAEACQAF/xgAOQAAAQAAABcFAHFub3Jt JAoAAIBCA/8ABgAuAAoABgAYAAaHsSYfzBTAAQAJAAb/GAA5AAABAAAAFwUAcW5vcm0kCgAAgEID /wAGABsACgAHABgAAAAAAAAAAAAAADcACv4FAEQQAA3ABgAuAAoACAAYAAaHsSYfzBTAAQAJAAj/ GAA5AAABAAAAFwUAcW5vcm0kCgAAgEID/wAGAC4ACgAJABgABoexJh/MFMABAAkACf8YADkAAAEA AAAXBQBxbm9ybSQKAACAQgP/AAYALgAKAAoAGAAGh7EmH8wUwAEACQAK/xgAOQAAAQAAABcFAHFu b3JtJAoAAIBCA/8AAwIOAAsAAAAXADqMMOKOeUU+BgAuAAsAAQAYAD1eQ3SwchbAAQAKAAH/GAA5 AAABAAAAFwUAcW5vcm0kCwAAgEID/wAGAC4ACwACABgAPV5DdLByFsABAAoAAv8YADkAAAEAAAAX BQBxbm9ybSQLAACAQgP/AAYALgALAAMAGAA9XkN0sHIWwAEACgAD/xgAOQAAAQAAABcFAHFub3Jt JAsAAIBCA/8ABgAuAAsABAAYAD1eQ3SwchbAAQAKAAT/GAA5AAABAAAAFwUAcW5vcm0kCwAAgEID /wAGAC4ACwAFABgAPV5DdLByFsABAAoABf8YADkAAAEAAAAXBQBxbm9ybSQLAACAQgP/AAYALgAL AAYAGAA9XkN0sHIWwAEACgAG/xgAOQAAAQAAABcFAHFub3JtJAsAAIBCA/8ABgAuAAsABwAYAD1e Q3SwchbAAQAJAAf/GAA5AAABAAAAFwUAcW5vcm0kCwAAgEID/wAGAC4ACwAIABgAPV5DdLByFsAB AAoACP8YADkAAAEAAAAXBQBxbm9ybSQLAACAQgP/AAYALgALAAkAGAA9XkN0sHIWwAEACgAJ/xgA OQAAAQAAABcFAHFub3JtJAsAAIBCA/8ABgAuAAsACgAYAD1eQ3SwchbAAQAKAAr/GAA5AAABAAAA FwUAcW5vcm0kCwAAgEID/wADAg4ADAAAABcAldYm6AsuET4GAC4ADAABABgAp7VEH8H9F8ABAAsA Af8YADkAAAEAAAAXBQBxbm9ybSQMAACAQgP/AAYALgAMAAIAGACntUQfwf0XwAEACwAC/xgAOQAA AQAAABcFAHFub3JtJAwAAIBCA/8ABgAuAAwAAwAYAKe1RB/B/RfAAQALAAP/GAA5AAABAAAAFwUA cW5vcm0kDAAAgEID/wAGAC4ADAAEABgAp7VEH8H9F8ABAAsABP8YADkAAAEAAAAXBQBxbm9ybSQM AACAQgP/AAYALgAMAAUAGACntUQfwf0XwAEACwAF/xgAOQAAAQAAABcFAHFub3JtJAwAAIBCA/8A BgAuAAwABgAYAKe1RB/B/RfAAQALAAb/GAA5AAABAAAAFwUAcW5vcm0kDAAAgEID/wAGAC4ADAAH ABgAp7VEH8H9F8ABAAsAB/8YADkAAAEAAAAXBQBxbm9ybSQMAACAQgP/AAYALgAMAAgAGACntUQf wf0XwAEACwAI/xgAOQAAAQAAABcFAHFub3JtJAwAAIBCA/8ABgAuAAwACQAYAKe1RB/B/RfAAQAL AAn/GAA5AAABAAAAFwUAcW5vcm0kDAAAgEID/wAGAC4ADAAKABgAp7VEH8H9F8ABAAsACv8YADkA AAEAAAAXBQBxbm9ybSQMAACAQgP/AAMCDgANAAAAFwC7vdfZ33zbPQYALgANAAEAGABUIXpZA3IZ wAEADAAB/xgAOQAAAQAAABcFAHFub3JtJA0AAIBCA/8ABgAuAA0AAgAYAFQhelkDchnAAQAMAAL/ GAA5AAABAAAAFwUAcW5vcm0kDQAAgEID/wAGAC4ADQADABgAVCF6WQNyGcABAAwAA/8YADkAAAEA AAAXBQBxbm9ybSQNAACAQgP/AAYALgANAAQAGABUIXpZA3IZwAEADAAE/xgAOQAAAQAAABcFAHFu b3JtJA0AAIBCA/8ABgAuAA0ABQAYAFQhelkDchnAAQAMAAX/GAA5AAABAAAAFwUAcW5vcm0kDQAA gEID/wAGAC4ADQAGABgAVCF6WQNyGcABAAwABv8YADkAAAEAAAAXBQBxbm9ybSQNAACAQgP/AAYA LgANAAcAGABUIXpZA3IZwAEADAAH/xgAOQAAAQAAABcFAHFub3JtJA0AAIBCA/8ABgAuAA0ACAAY AFQhelkDchnAAQAMAAj/GAA5AAABAAAAFwUAcW5vcm0kDQAAgEID/wAGAC4ADQAJABgAVCF6WQNy GcABAAwACf8YADkAAAEAAAAXBQBxbm9ybSQNAACAQgP/AAYALgANAAoAGABUIXpZA3IZwAEADAAK /xgAOQAAAQAAABcFAHFub3JtJA0AAIBCA/8AAwIOAA4AAAAXAJVkeeF//aU9BgAuAA4AAQAYAAVI 7Lv30hrAAQANAAH/GAA5AAABAAAAFwUAcW5vcm0kDgAAgEID/wAGAC4ADgACABgABUjsu/fSGsAB AA0AAv8YADkAAAEAAAAXBQBxbm9ybSQOAACAQgP/AAYALgAOAAMAGAAFSOy799IawAEADQAD/xgA OQAAAQAAABcFAHFub3JtJA4AAIBCA/8ABgAuAA4ABAAYAAVI7Lv30hrAAQANAAT/GAA5AAABAAAA FwUAcW5vcm0kDgAAgEID/wAGAC4ADgAFABgABUjsu/fSGsABAA0ABf8YADkAAAEAAAAXBQBxbm9y bSQOAACAQgP/AAYALgAOAAYAGAAFSOy799IawAEADQAG/xgAOQAAAQAAABcFAHFub3JtJA4AAIBC A/8ABgAuAA4ABwAYAAVI7Lv30hrAAQANAAf/GAA5AAABAAAAFwUAcW5vcm0kDgAAgEID/wAGAC4A DgAIABgABUjsu/fSGsABAA0ACP8YADkAAAEAAAAXBQBxbm9ybSQOAACAQgP/AAYALgAOAAkAGAAF SOy799IawAEADQAJ/xgAOQAAAQAAABcFAHFub3JtJA4AAIBCA/8ABgAuAA4ACgAYAAVI7Lv30hrA AQANAAr/GAA5AAABAAAAFwUAcW5vcm0kDgAAgEID/wADAg4ADwAAABcAEeotgZmXcT0GAC4ADwAB ABgAKaNXuk8jHMABAA4AAf8YADkAAAEAAAAXBQBxbm9ybSQPAACAQgP/AAYALgAPAAIAGAApo1e6 TyMcwAEADgAC/xgAOQAAAQAAABcFAHFub3JtJA8AAIBCA/8ABgAuAA8AAwAYACmjV7pPIxzAAQAO AAP/GAA5AAABAAAAFwUAcW5vcm0kDwAAgEID/wAGAC4ADwAEABgAKaNXuk8jHMABAA4ABP8YADkA AAEAAAAXBQBxbm9ybSQPAACAQgP/AAYALgAPAAUAGAApo1e6TyMcwAEADgAF/xgAOQAAAQAAABcF AHFub3JtJA8AAIBCA/8ABgAuAA8ABgAYACmjV7pPIxzAAQAOAAb/GAA5AAABAAAAFwUAcW5vcm0k DwAAgEID/wAGAC4ADwAHABgAKaNXuk8jHMABAA4AB/8YADkAAAEAAAAXBQBxbm9ybSQPAACAQgP/ AAYALgAPAAgAGAApo1e6TyMcwAEADgAI/xgAOQAAAQAAABcFAHFub3JtJA8AAIBCA/8ABgAuAA8A CQAYACmjV7pPIxzAAQAOAAn/GAA5AAABAAAAFwUAcW5vcm0kDwAAgEID/wAGAC4ADwAKABgAKaNX uk8jHMABAA4ACv8YADkAAAEAAAAXBQBxbm9ybSQPAACAQgP/AAMCDgAQAAAAFwCCdklowiU8PQYA LgAQAAEAGAAxATrOKmUdwAEADwAB/xgAOQAAAQAAABcFAHFub3JtJBAAAIBCA/8ABgAuABAAAgAY ADEBOs4qZR3AAQAPAAL/GAA5AAABAAAAFwUAcW5vcm0kEAAAgEID/wAGAC4AEAADABgAMQE6zipl HcABAA8AA/8YADkAAAEAAAAXBQBxbm9ybSQQAACAQgP/AAYALgAQAAQAGAAxATrOKmUdwAEADwAE /xgAOQAAAQAAABcFAHFub3JtJBAAAIBCA/8ABgAuABAABQAYADEBOs4qZR3AAQAPAAX/GAA5AAAB AAAAFwUAcW5vcm0kEAAAgEID/wAGAC4AEAAGABgAMQE6ziplHcABAA8ABv8YADkAAAEAAAAXBQBx bm9ybSQQAACAQgP/AAYALgAQAAcAGAAxATrOKmUdwAEADwAH/xgAOQAAAQAAABcFAHFub3JtJBAA AIBCA/8ABgAuABAACAAYADEBOs4qZR3AAQAPAAj/GAA5AAABAAAAFwUAcW5vcm0kEAAAgEID/wAG AC4AEAAJABgAMQE6ziplHcABAA8ACf8YADkAAAEAAAAXBQBxbm9ybSQQAACAQgP/AAYALgAQAAoA GAAxATrOKmUdwAEADwAK/xgAOQAAAQAAABcFAHFub3JtJBAAAIBCA/8AAwIOABEAAAAXAJsroYab hAY9BgAuABEAAQAYADUQNEA+mh7AAQAQAAH/GAA5AAABAAAAFwUAcW5vcm0kEQAAgEID/wAGAC4A EQACABgANRA0QD6aHsABABAAAv8YADkAAAEAAAAXBQBxbm9ybSQRAACAQgP/AAYALgARAAMAGAA1 EDRAPpoewAEAEAAD/xgAOQAAAQAAABcFAHFub3JtJBEAAIBCA/8ABgAuABEABAAYADUQNEA+mh7A AQAQAAT/GAA5AAABAAAAFwUAcW5vcm0kEQAAgEID/wAGAC4AEQAFABgANRA0QD6aHsABABAABf8Y ADkAAAEAAAAXBQBxbm9ybSQRAACAQgP/AAYALgARAAYAGAA1EDRAPpoewAEAEAAG/xgAOQAAAQAA ABcFAHFub3JtJBEAAIBCA/8ABgAuABEABwAYADUQNEA+mh7AAQAQAAf/GAA5AAABAAAAFwUAcW5v cm0kEQAAgEID/wAGAC4AEQAIABgANRA0QD6aHsABABAACP8YADkAAAEAAAAXBQBxbm9ybSQRAACA QgP/AAYALgARAAkAGAA1EDRAPpoewAEAEAAJ/xgAOQAAAQAAABcFAHFub3JtJBEAAIBCA/8ABgAu ABEACgAYADUQNEA+mh7AAQAQAAr/GAA5AAABAAAAFwUAcW5vcm0kEQAAgEID/wADAg4AEgAAABcA Flbnnq8D0jwGAC4AEgABABgAaJZ4B/DDH8ABABEAAf8YADkAAAEAAAAXBQBxbm9ybSQSAACAQgP/ AAYALgASAAIAGABolngH8MMfwAEAEQAC/xgAOQAAAQAAABcFAHFub3JtJBIAAIBCA/8ABgAuABIA AwAYAGiWeAfwwx/AAQARAAP/GAA5AAABAAAAFwUAcW5vcm0kEgAAgEID/wAGAC4AEgAEABgAaJZ4 B/DDH8ABABEABP8YADkAAAEAAAAXBQBxbm9ybSQSAACAQgP/AAYALgASAAUAGABolngH8MMfwAEA EQAF/xgAOQAAAQAAABcFAHFub3JtJBIAAIBCA/8ABgAuABIABgAYAGiWeAfwwx/AAQARAAb/GAA5 AAABAAAAFwUAcW5vcm0kEgAAgEID/wAGAC4AEgAHABgAaJZ4B/DDH8ABABEAB/8YADkAAAEAAAAX BQBxbm9ybSQSAACAQgP/AAYALgASAAgAGABolngH8MMfwAEAEQAI/xgAOQAAAQAAABcFAHFub3Jt JBIAAIBCA/8ABgAuABIACQAYAGiWeAfwwx/AAQARAAn/GAA5AAABAAAAFwUAcW5vcm0kEgAAgEID /wAGAC4AEgAKABgAaJZ4B/DDH8ABABEACv8YADkAAAEAAAAXBQBxbm9ybSQSAACAQgP/AAMCDgAT AAAAFwC8idiXstKcPAYALgATAAEAGABam57CtHEgwAEAEgAB/xgAOQAAAQAAABcFAHFub3JtJBMA AIBCA/8ABgAuABMAAgAYAFqbnsK0cSDAAQASAAL/GAA5AAABAAAAFwUAcW5vcm0kEwAAgEID/wAG AC4AEwADABgAWpuewrRxIMABABIAA/8YADkAAAEAAAAXBQBxbm9ybSQTAACAQgP/AAYALgATAAQA GABam57CtHEgwAEAEgAE/xgAOQAAAQAAABcFAHFub3JtJBMAAIBCA/8ABgAuABMABQAYAFqbnsK0 cSDAAQASAAX/GAA5AAABAAAAFwUAcW5vcm0kEwAAgEID/wAGAC4AEwAGABgAWpuewrRxIMABABIA Bv8YADkAAAEAAAAXBQBxbm9ybSQTAACAQgP/AAYALgATAAcAGABam57CtHEgwAEAEgAH/xgAOQAA AQAAABcFAHFub3JtJBMAAIBCA/8ABgAuABMACAAYAFqbnsK0cSDAAQASAAj/GAA5AAABAAAAFwUA cW5vcm0kEwAAgEID/wAGAC4AEwAJABgAWpuewrRxIMABABIACf8YADkAAAEAAAAXBQBxbm9ybSQT AACAQgP/AAYALgATAAoAGABam57CtHEgwAEAEgAK/xgAOQAAAQAAABcFAHFub3JtJBMAAIBCA/8A AwIOABQAAAAXAJfURkb1Dmc8BgAuABQAAQAYAAITKXfS/CDAAQATAAH/GAA5AAABAAAAFwUAcW5v cm0kFAAAgEID/wAGAC4AFAACABgAAhMpd9L8IMABABMAAv8YADkAAAEAAAAXBQBxbm9ybSQUAACA QgP/AAYALgAUAAMAGAACEyl30vwgwAEAEwAD/xgAOQAAAQAAABcFAHFub3JtJBQAAIBCA/8ABgAu ABQABAAYAAITKXfS/CDAAQATAAT/GAA5AAABAAAAFwUAcW5vcm0kFAAAgEID/wAGAC4AFAAFABgA AhMpd9L8IMABABMABf8YADkAAAEAAAAXBQBxbm9ybSQUAACAQgP/AAYALgAUAAYAGAACEyl30vwg wAEAEwAG/xgAOQAAAQAAABcFAHFub3JtJBQAAIBCA/8ABgAuABQABwAYAAITKXfS/CDAAQATAAf/ GAA5AAABAAAAFwUAcW5vcm0kFAAAgEID/wAGAC4AFAAIABgAAhMpd9L8IMABABMACP8YADkAAAEA AAAXBQBxbm9ybSQUAACAQgP/AAYALgAUAAkAGAACEyl30vwgwAEAEwAJ/xgAOQAAAQAAABcFAHFu b3JtJBQAAIBCA/8ABgAuABQACgAYAAITKXfS/CDAAQATAAr/GAA5AAABAAAAFwUAcW5vcm0kFAAA gEID/wADAg4AFQAAABcArEPS0V1yMjwGAC4AFQABABgAZTGDj7uDIcABABQAAf8YADkAAAEAAAAX BQBxbm9ybSQVAACAQgP/AAYALgAVAAIAGABlMYOPu4MhwAEAFAAC/xgAOQAAAQAAABcFAHFub3Jt JBUAAIBCA/8ABgAuABUAAwAYAGUxg4+7gyHAAQAUAAP/GAA5AAABAAAAFwUAcW5vcm0kFQAAgEID /wAGAC4AFQAEABgAZTGDj7uDIcABABQABP8YADkAAAEAAAAXBQBxbm9ybSQVAACAQgP/AAYALgAV AAUAGABlMYOPu4MhwAEAFAAF/xgAOQAAAQAAABcFAHFub3JtJBUAAIBCA/8ABgAuABUABgAYAGUx g4+7gyHAAQAUAAb/GAA5AAABAAAAFwUAcW5vcm0kFQAAgEID/wAGAC4AFQAHABgAZTGDj7uDIcAB ABQAB/8YADkAAAEAAAAXBQBxbm9ybSQVAACAQgP/AAYALgAVAAgAGABlMYOPu4MhwAEAFAAI/xgA OQAAAQAAABcFAHFub3JtJBUAAIBCA/8ABgAuABUACQAYAGUxg4+7gyHAAQAUAAn/GAA5AAABAAAA FwUAcW5vcm0kFQAAgEID/wAGAC4AFQAKABgAZTGDj7uDIcABABQACv8YADkAAAEAAAAXBQBxbm9y bSQVAACAQgP/AAMCDgAWAAAAFwCs0rZPyYP9OwYALgAWAAEAGACMUQF6ywYiwAEAFQAB/xgAOQAA AQAAABcFAHFub3JtJBYAAIBCA/8ABgAuABYAAgAYAIxRAXrLBiLAAQAVAAL/GAA5AAABAAAAFwUA cW5vcm0kFgAAgEID/wAGAC4AFgADABgAjFEBessGIsABABUAA/8YADkAAAEAAAAXBQBxbm9ybSQW AACAQgP/AAYALgAWAAQAGACMUQF6ywYiwAEAFQAE/xgAOQAAAQAAABcFAHFub3JtJBYAAIBCA/8A BgAuABYABQAYAIxRAXrLBiLAAQAVAAX/GAA5AAABAAAAFwUAcW5vcm0kFgAAgEID/wAGAC4AFgAG ABgAjFEBessGIsABABUABv8YADkAAAEAAAAXBQBxbm9ybSQWAACAQgP/AAYALgAWAAcAGACMUQF6 ywYiwAEAFQAH/xgAOQAAAQAAABcFAHFub3JtJBYAAIBCA/8ABgAuABYACAAYAIxRAXrLBiLAAQAV AAj/GAA5AAABAAAAFwUAcW5vcm0kFgAAgEID/wAGAC4AFgAJABgAjFEBessGIsABABUACf8YADkA AAEAAAAXBQBxbm9ybSQWAACAQgP/AAYALgAWAAoAGACMUQF6ywYiwAEAFQAK/xgAOQAAAQAAABcF AHFub3JtJBYAAIBCA/8AAwIOABcAAAAXACNCkgyhnMc7BgAuABcAAQAYAEw6tHBRhiLAAQAWAAH/ GAA5AAABAAAAFwUAcW5vcm0kFwAAgEID/wAGAC4AFwACABgATDq0cFGGIsABABYAAv8YADkAAAEA AAAXBQBxbm9ybSQXAACAQgP/AAYALgAXAAMAGABMOrRwUYYiwAEAFgAD/xgAOQAAAQAAABcFAHFu b3JtJBcAAIBCA/8ABgAuABcABAAYAEw6tHBRhiLAAQAWAAT/GAA5AAABAAAAFwUAcW5vcm0kFwAA gEID/wAGAC4AFwAFABgATDq0cFGGIsABABYABf8YADkAAAEAAAAXBQBxbm9ybSQXAACAQgP/AAYA LgAXAAYAGABMOrRwUYYiwAEAFgAG/xgAOQAAAQAAABcFAHFub3JtJBcAAIBCA/8ABgAuABcABwAY AEw6tHBRhiLAAQAWAAf/GAA5AAABAAAAFwUAcW5vcm0kFwAAgEID/wAGAC4AFwAIABgATDq0cFGG IsABABYACP8YADkAAAEAAAAXBQBxbm9ybSQXAACAQgP/AAYALgAXAAkAGABMOrRwUYYiwAEAFgAJ /xgAOQAAAQAAABcFAHFub3JtJBcAAIBCA/8ABgAuABcACgAYAEw6tHBRhiLAAQAWAAr/GAA5AAAB AAAAFwUAcW5vcm0kFwAAgEID/wADAg4AGAAAABcAT5sOCrTjkjsGAC4AGAABABgAIzZwopICI8AB ABcAAf8YADkAAAEAAAAXBQBxbm9ybSQYAACAQgP/AAYALgAYAAIAGAAjNnCikgIjwAEAFwAC/xgA OQAAAQAAABcFAHFub3JtJBgAAIBCA/8ABgAuABgAAwAYACM2cKKSAiPAAQAXAAP/GAA5AAABAAAA FwUAcW5vcm0kGAAAgEID/wAGAC4AGAAEABgAIzZwopICI8ABABcABP8YADkAAAEAAAAXBQBxbm9y bSQYAACAQgP/AAYALgAYAAUAGAAjNnCikgIjwAEAFwAF/xgAOQAAAQAAABcFAHFub3JtJBgAAIBC A/8ABgAuABgABgAYACM2cKKSAiPAAQAXAAb/GAA5AAABAAAAFwUAcW5vcm0kGAAAgEID/wAGAC4A GAAHABgAIzZwopICI8ABABcAB/8YADkAAAEAAAAXBQBxbm9ybSQYAACAQgP/AAYALgAYAAgAGAAj NnCikgIjwAEAFwAI/xgAOQAAAQAAABcFAHFub3JtJBgAAIBCA/8ABgAuABgACQAYACM2cKKSAiPA AQAXAAn/GAA5AAABAAAAFwUAcW5vcm0kGAAAgEID/wAGAC4AGAAKABgAIzZwopICI8ABABcACv8Y ADkAAAEAAAAXBQBxbm9ybSQYAACAQgP/AAMCDgAZAAAAFwDmXhcQIDleOwYALgAZAAEAGACLJzTk y3sjwAEAGAAB/xgAOQAAAQAAABcFAHFub3JtJBkAAIBCA/8ABgAuABkAAgAYAIsnNOTLeyPAAQAY AAL/GAA5AAABAAAAFwUAcW5vcm0kGQAAgEID/wAGAC4AGQADABgAiyc05Mt7I8ABABgAA/8YADkA AAEAAAAXBQBxbm9ybSQZAACAQgP/AAYALgAZAAQAGACLJzTky3sjwAEAGAAE/xgAOQAAAQAAABcF AHFub3JtJBkAAIBCA/8ABgAuABkABQAYAIsnNOTLeyPAAQAYAAX/GAA5AAABAAAAFwUAcW5vcm0k GQAAgEID/wAGAC4AGQAGABgAiyc05Mt7I8ABABgABv8YADkAAAEAAAAXBQBxbm9ybSQZAACAQgP/ AAYALgAZAAcAGACLJzTky3sjwAEAGAAH/xgAOQAAAQAAABcFAHFub3JtJBkAAIBCA/8ABgAuABkA CAAYAIsnNOTLeyPAAQAYAAj/GAA5AAABAAAAFwUAcW5vcm0kGQAAgEID/wAGAC4AGQAJABgAiyc0 5Mt7I8ABABgACf8YADkAAAEAAAAXBQBxbm9ybSQZAACAQgP/AAYALgAZAAoAGACLJzTky3sjwAEA GAAK/xgAOQAAAQAAABcFAHFub3JtJBkAAIBCA/8AAwIOABoAAAAXAFGyEkCzLSg7BgAuABoAAQAY ABN6FQkz8iPAAQAZAAH/GAA5AAABAAAAFwUAcW5vcm0kGgAAgEID/wAGAC4AGgACABgAE3oVCTPy I8ABABkAAv8YADkAAAEAAAAXBQBxbm9ybSQaAACAQgP/AAYALgAaAAMAGAATehUJM/IjwAEAGQAD /xgAOQAAAQAAABcFAHFub3JtJBoAAIBCA/8ABgAuABoABAAYABN6FQkz8iPAAQAZAAT/GAA5AAAB AAAAFwUAcW5vcm0kGgAAgEID/wAGAC4AGgAFABgAE3oVCTPyI8ABABkABf8YADkAAAEAAAAXBQBx bm9ybSQaAACAQgP/AAYALgAaAAYAGAATehUJM/IjwAEAGQAG/xgAOQAAAQAAABcFAHFub3JtJBoA AIBCA/8ABgAuABoABwAYABN6FQkz8iPAAQAZAAf/GAA5AAABAAAAFwUAcW5vcm0kGgAAgEID/wAG AC4AGgAIABgAE3oVCTPyI8ABABkACP8YADkAAAEAAAAXBQBxbm9ybSQaAACAQgP/AAYALgAaAAkA GAATehUJM/IjwAEAGQAJ/xgAOQAAAQAAABcFAHFub3JtJBoAAIBCA/8ABgAuABoACgAYABN6FQkz 8iPAAQAZAAr/GAA5AAABAAAAFwUAcW5vcm0kGgAAgEID/wADAg4AGwAAABcAp46omcJX8zoGAC4A GwABABgA2RRC9vdlJMABABoAAf8YADkAAAEAAAAXBQBxbm9ybSQbAACAQgP/AAYALgAbAAIAGADZ FEL292UkwAEAGgAC/xgAOQAAAQAAABcFAHFub3JtJBsAAIBCA/8ABgAuABsAAwAYANkUQvb3ZSTA AQAaAAP/GAA5AAABAAAAFwUAcW5vcm0kGwAAgEID/wAGAC4AGwAEABgA2RRC9vdlJMABABoABP8Y ADkAAAEAAAAXBQBxbm9ybSQbAACAQgP/AAYALgAbAAUAGADZFEL292UkwAEAGgAF/xgAOQAAAQAA ABcFAHFub3JtJBsAAIBCA/8ABgAuABsABgAYANkUQvb3ZSTAAQAaAAb/GAA5AAABAAAAFwUAcW5v cm0kGwAAgEID/wAGAC4AGwAHABgA2RRC9vdlJMABABoAB/8YADkAAAEAAAAXBQBxbm9ybSQbAACA QgP/AAYALgAbAAgAGADZFEL292UkwAEAGgAI/xgAOQAAAQAAABcFAHFub3JtJBsAAIBCA/8ABgAu ABsACQAYANkUQvb3ZSTAAQAaAAn/GAA5AAABAAAAFwUAcW5vcm0kGwAAgEID/wAGAC4AGwAKABgA 2RRC9vdlJMABABoACv8YADkAAAEAAAAXBQBxbm9ybSQbAACAQgP/AAMCDgAcAAAAFwDZfdr10PK+ OgYALgAcAAEAGAAI9seCRdckwAEAGwAB/xgAOQAAAQAAABcFAHFub3JtJBwAAIBCA/8ABgAuABwA AgAYAAj2x4JF1yTAAQAbAAL/GAA5AAABAAAAFwUAcW5vcm0kHAAAgEID/wAGAC4AHAADABgACPbH gkXXJMABABsAA/8YADkAAAEAAAAXBQBxbm9ybSQcAACAQgP/AAYALgAcAAQAGAAI9seCRdckwAEA GwAE/xgAOQAAAQAAABcFAHFub3JtJBwAAIBCA/8ABgAuABwABQAYAAj2x4JF1yTAAQAbAAX/GAA5 AAABAAAAFwUAcW5vcm0kHAAAgEID/wAGAC4AHAAGABgACPbHgkXXJMABABsABv8YADkAAAEAAAAX BQBxbm9ybSQcAACAQgP/AAYALgAcAAcAGAAI9seCRdckwAEAGwAH/xgAOQAAAQAAABcFAHFub3Jt JBwAAIBCA/8ABgAuABwACAAYAAj2x4JF1yTAAQAbAAj/GAA5AAABAAAAFwUAcW5vcm0kHAAAgEID /wAGAC4AHAAJABgACPbHgkXXJMABABsACf8YADkAAAEAAAAXBQBxbm9ybSQcAACAQgP/AAYALgAc AAoAGAAI9seCRdckwAEAGwAK/xgAOQAAAQAAABcFAHFub3JtJBwAAIBCA/8AAwIOAB0AAAAXAKDC 6/5LSLQ5BgAuAB0AAQAYAMjN2qSU7SbAAQAcAAH/GAA5AAABAAAAFwUAcW5vcm0kHQAAgEID/wAG AC4AHQACABgAyM3apJTtJsABABwAAv8YADkAAAEAAAAXBQBxbm9ybSQdAACAQgP/AAYALgAdAAMA GADIzdqklO0mwAEAHAAD/xgAOQAAAQAAABcFAHFub3JtJB0AAIBCA/8ABgAuAB0ABAAYAMjN2qSU 7SbAAQAcAAT/GAA5AAABAAAAFwUAcW5vcm0kHQAAgEID/wAGAC4AHQAFABgAyM3apJTtJsABABwA Bf8YADkAAAEAAAAXBQBxbm9ybSQdAACAQgP/AAYALgAdAAYAGADIzdqklO0mwAEAHAAG/xgAOQAA AQAAABcFAHFub3JtJB0AAIBCA/8ABgAuAB0ABwAYAMjN2qSU7SbAAQAcAAf/GAA5AAABAAAAFwUA cW5vcm0kHQAAgEID/wAGAC4AHQAIABgAyM3apJTtJsABABwACP8YADkAAAEAAAAXBQBxbm9ybSQd AACAQgP/AAYALgAdAAkAGADIzdqklO0mwAEAHAAJ/xgAOQAAAQAAABcFAHFub3JtJB0AAIBCA/8A BgAuAB0ACgAYAMjN2qSU7SbAAQAcAAr/GAA5AAABAAAAFwUAcW5vcm0kHQAAgEID/wADAg4AHgAA ABcAD3r4t6WVqjgGAC4AHgABABgAag2fUcPXKMABAB0AAf8YADkAAAEAAAAXBQBxbm9ybSQeAACA QgP/AAYALgAeAAIAGABqDZ9Rw9cowAEAHQAC/xgAOQAAAQAAABcFAHFub3JtJB4AAIBCA/8ABgAu AB4AAwAYAGoNn1HD1yjAAQAdAAP/GAA5AAABAAAAFwUAcW5vcm0kHgAAgEID/wAGAC4AHgAEABgA ag2fUcPXKMABAB0ABP8YADkAAAEAAAAXBQBxbm9ybSQeAACAQgP/AAYALgAeAAUAGABqDZ9Rw9co wAEAHQAF/xgAOQAAAQAAABcFAHFub3JtJB4AAIBCA/8ABgAuAB4ABgAYAGoNn1HD1yjAAQAdAAb/ GAA5AAABAAAAFwUAcW5vcm0kHgAAgEID/wAGAC4AHgAHABgAag2fUcPXKMABAB0AB/8YADkAAAEA AAAXBQBxbm9ybSQeAACAQgP/AAYALgAeAAgAGABqDZ9Rw9cowAEAHQAI/xgAOQAAAQAAABcFAHFu b3JtJB4AAIBCA/8ABgAuAB4ACQAYAGoNn1HD1yjAAQAdAAn/GAA5AAABAAAAFwUAcW5vcm0kHgAA gEID/wAGAC4AHgAKABgAag2fUcPXKMABAB0ACv8YADkAAAEAAAAXBQBxbm9ybSQeAACAQgP/AAMC DgAfAAAAFwCcV3cnJmyhNwYALgAfAAEAGAASzAMWMZ8qwAEAHgAB/xgAOQAAAQAAABcFAHFub3Jt JB8AAIBCA/8ABgAuAB8AAgAYABLMAxYxnyrAAQAeAAL/GAA5AAABAAAAFwUAcW5vcm0kHwAAgEID /wAGAC4AHwADABgAEswDFjGfKsABAB4AA/8YADkAAAEAAAAXBQBxbm9ybSQfAACAQgP/AAYALgAf AAQAGAASzAMWMZ8qwAEAHgAE/xgAOQAAAQAAABcFAHFub3JtJB8AAIBCA/8ABgAuAB8ABQAYABLM AxYxnyrAAQAeAAX/GAA5AAABAAAAFwUAcW5vcm0kHwAAgEID/wAGAC4AHwAGABgAEswDFjGfKsAB AB4ABv8YADkAAAEAAAAXBQBxbm9ybSQfAACAQgP/AAYALgAfAAcAGAASzAMWMZ8qwAEAHgAH/xgA OQAAAQAAABcFAHFub3JtJB8AAIBCA/8ABgAuAB8ACAAYABLMAxYxnyrAAQAeAAj/GAA5AAABAAAA FwUAcW5vcm0kHwAAgEID/wAGAC4AHwAJABgAEswDFjGfKsABAB4ACf8YADkAAAEAAAAXBQBxbm9y bSQfAACAQgP/AAYALgAfAAoAGAASzAMWMZ8qwAEAHgAK/xgAOQAAAQAAABcFAHFub3JtJB8AAIBC A/8A1wBEAFk8AABsAg4ACgCaAJoAAgICAgYCBgIGAgYC8wEGAgYCBgIGAgYCBgIGAgYCBgIGAgYC BgIGAgYCBgIGAgYCBgIGAgYCCAIQACAAAAALAP8AAAAAAAABDwAIAhAAIQAAAAsA/wAAAAAAAAEP AAgCEAAiAAAACwD/AAAAAAAAAQ8ACAIQACMAAAALAP8AAAAAAAABDwAIAhAAJAAAAAsA/wAAAAAA AAEPAAgCEAAlAAAACwD/AAAAAAAAAQ8ACAIQACYAAAALAP8AAAAAAAABDwAIAhAAJwAAAAsA/wAA AAAAAAEPAAgCEAAoAAAACwD/AAAAAAAAAQ8ACAIQACkAAAALAP8AAAAAAAABDwAIAhAAKgAAAAsA /wAAAAAAAAEPAAgCEAArAAAACwD/AAAAAAAAAQ8ACAIQACwAAAALAP8AAAAAAAABDwAIAhAALQAA AAsA/wAAAAAAAAEPAAgCEAAuAAAACwD/AAAAAAAAAQ8ACAIQAC8AAAALAP8AAAAAAAABDwAIAhAA MAAAAAsA/wAAAAAAAAEPAAgCEAAxAAAACwD/AAAAAAAAAQ8ACAIQADIAAAALAP8AAAAAAAABDwAI AhAAMwAAAAsA/wAAAAAAAAEPAAgCEAA0AAAACwD/AAAAAAAAAQ8ACAIQADUAAAALAP8AAAAAAAAB DwAIAhAANgAAAAsA/wAAAAAAAAEPAAgCEAA3AAAACwD/AAAAAAAAAQ8AAwIOACAAAAAXALlqN60B 1pY2BgAuACAAAQAYAN6+hDpVSizAAQAfAAH/GAA5AAABAAAAFwUAcW5vcm0kIAAAgEID/wAGAC4A IAACABgA3r6EOlVKLMABAB8AAv8YADkAAAEAAAAXBQBxbm9ybSQgAACAQgP/AAYALgAgAAMAGADe voQ6VUoswAEAHwAD/xgAOQAAAQAAABcFAHFub3JtJCAAAIBCA/8ABgAuACAABAAYAN6+hDpVSizA AQAfAAT/GAA5AAABAAAAFwUAcW5vcm0kIAAAgEID/wAGAC4AIAAFABgA3r6EOlVKLMABAB8ABf8Y ADkAAAEAAAAXBQBxbm9ybSQgAACAQgP/AAYALgAgAAYAGADevoQ6VUoswAEAHwAG/xgAOQAAAQAA ABcFAHFub3JtJCAAAIBCA/8ABgAuACAABwAYAN6+hDpVSizAAQAfAAf/GAA5AAABAAAAFwUAcW5v cm0kIAAAgEID/wAGAC4AIAAIABgA3r6EOlVKLMABAB8ACP8YADkAAAEAAAAXBQBxbm9ybSQgAACA ==> 5476.audit <== Mon Dec 8 13:57:36 2003 ripley changed notes Mon Dec 8 13:57:36 2003 ripley foobar Mon Dec 8 13:57:37 2003 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6005 * Subject: [R] lattice: levelplot: error: min not meaningful for factor From: Wolfram Fischer Date: Mon, 22 Dec 2003 17:29:49 +0100 --Not documented to work, but intended to. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6005 <== From mailnull@stat.math.ethz.ch Mon Dec 22 17:30:49 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5320A104AB for ; Mon, 22 Dec 2003 17:30:49 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hBMGSuFG004764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Dec 2003 17:28:57 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id hBMGSuA4004761 for R-bugs@biostat.ku.dk; Mon, 22 Dec 2003 17:28:56 +0100 (MET) Received: from fischer-zim.ch (adsl-62-167-54-112.adslplus.ch [62.167.54.112]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hBMGSkFF004731 for ; Mon, 22 Dec 2003 17:28:46 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by fischer-zim.ch (Postfix) with ESMTP id 9A6B63F727 for ; Mon, 22 Dec 2003 17:29:51 +0100 (CET) Received: by fischer-zim.ch (Postfix, from userid 100) id 7ECF232B37; Mon, 22 Dec 2003 17:29:49 +0100 (CET) Date: Mon, 22 Dec 2003 17:29:49 +0100 From: Wolfram Fischer To: r-bugs@stat.math.ethz.ch Subject: [R] lattice: levelplot: error: min not meaningful for factor Message-ID: <20031222162949.GA19171@s1x.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hypatia.math.ethz.ch X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.61 X-Spam-Level: R 1.8.1: ___COMMAND____________________________________________ levelplot( yield ~ year * variety | site, barley ) ___ERROR_MESSAGE______________________________________ Error in Summary.factor(..., na.rm = na.rm) : "min" not meaningful for factors ___COMMENT____________________________________________ levelplot( yield ~ as.numeric(year) * as.numeric(variety) | site, barley ) is working but the labels are nasty. Best regards Wolfram ==> 6005.followup.1 <== From ripley@stats.ox.ac.uk Mon Dec 22 17:52:08 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id A9D20104AC for ; Mon, 22 Dec 2003 17:52:07 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id hBMGq7oO011564; Mon, 22 Dec 2003 16:52:07 GMT Date: Mon, 22 Dec 2003 16:52:06 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: wolfram@fischer-zim.ch Cc: r-devel@stat.math.ethz.ch, Subject: (PR#6005) Re: [Rd] [R] lattice: levelplot: error: min not meaningful In-Reply-To: <20031222163049.BFEB4104AC@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From the help page: formula: a formula of the form 'z ~ x * y | g1 * g2 * ...', where 'z' is a numeric response, and 'x, y' are numeric values evaluated on a rectangular grid. Please explain why you think that acting as documented necessitates a bug report? On Mon, 22 Dec 2003 wolfram@fischer-zim.ch wrote: > R 1.8.1: > > ___COMMAND____________________________________________ > > levelplot( yield ~ year * variety | site, barley ) > > > ___ERROR_MESSAGE______________________________________ > > Error in Summary.factor(..., na.rm = na.rm) : > "min" not meaningful for factors > > ___COMMENT____________________________________________ > > levelplot( yield ~ as.numeric(year) * as.numeric(variety) | site, barley ) > is working but the labels are nasty. > > Best regards > Wolfram > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6005.followup.2 <== From deepayan@stat.wisc.edu Mon Dec 22 18:22:20 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by slim.kubism.ku.dk (Postfix) with ESMTP id A31F2FC0C for ; Mon, 22 Dec 2003 18:22:19 +0100 (CET) Received: from 192.168.2.69 (66-191-117-85.mad.wi.charter.com [66.191.117.85]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id hBMHM8210786 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 22 Dec 2003 11:22:14 -0600 From: Deepayan Sarkar To: Prof Brian Ripley , wolfram@fischer-zim.ch Subject: Re: (PR#6005) Re: [Rd] [R] lattice: levelplot: error: min not meaningful Date: Mon, 22 Dec 2003 11:22:08 -0600 User-Agent: KMail/1.5.3 Cc: R-bugs@biostat.ku.dk References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312221122.08583.deepayan@stat.wisc.edu> Actually, this is supposed to work (and is given as an example in my DSC-2003 paper), and at some point, did. It seems this was broken as a consequence of a careless change in panel.levelplot. The first 5 lines should have been label.style <- match.arg(label.style) x <- as.numeric(x[subscripts]) y <- as.numeric(y[subscripts]) minXwid <- min(diff(sort(unique(x)))) minYwid <- min(diff(sort(unique(y)))) instead of label.style <- match.arg(label.style) minXwid <- min(diff(sort(unique(x)))) minYwid <- min(diff(sort(unique(y)))) x <- as.numeric(x[subscripts]) y <- as.numeric(y[subscripts]) I'll fix it eventually, for now a workaround is to have levelplot( yield ~ year * variety | site, barley, panel = function(x, y, ...) { x <- as.numeric(x) y <- as.numeric(y) panel.levelplot(x, y, ...) }) Deepayan On Monday 22 December 2003 10:52, Prof Brian Ripley wrote: > From the help page: > > formula: a formula of the form 'z ~ x * y | g1 * g2 * ...', where 'z' > is a numeric response, and 'x, y' are numeric values > evaluated on a rectangular grid. > > Please explain why you think that acting as documented necessitates a bug > report? > > On Mon, 22 Dec 2003 wolfram@fischer-zim.ch wrote: > > R 1.8.1: > > > > ___COMMAND____________________________________________ > > > > levelplot( yield ~ year * variety | site, barley ) > > > > > > ___ERROR_MESSAGE______________________________________ > > > > Error in Summary.factor(..., na.rm = na.rm) : > > "min" not meaningful for factors > > > > ___COMMENT____________________________________________ > > > > levelplot( yield ~ as.numeric(year) * as.numeric(variety) | site, barley > > ) is working but the labels are nasty. > > > > Best regards > > Wolfram > > > > ______________________________________________ > > R-devel@stat.math.ethz.ch mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel ==> 6005.audit <== Thu Jan 8 15:32:29 2004 ripley changed notes Thu Jan 8 15:32:29 2004 ripley moved from incoming to Add-ons Sun Apr 18 13:42:42 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6701 * Subject: lookup.xport in foreign ignoring some datasets From: Svetlana Eden Date: Fri, 26 Mar 2004 15:45:18 -0600 --SAS version*5* is probably not supported. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6701 <== From mail@stat.math.ethz.ch Fri Mar 26 22:44:04 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id E00631042E for ; Fri, 26 Mar 2004 22:44:04 +0100 (CET) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30002-02 for ; Fri, 26 Mar 2004 22:26:28 +0100 (CET) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 26 Mar 2004 22:26:28 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i2QLi3aJ022352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Mar 2004 22:44:03 +0100 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i2QLi3rX022350 for R-bugs@biostat.ku.dk; Fri, 26 Mar 2004 22:44:03 +0100 Received: from smtp1.mail.vanderbilt.edu (smtp1.mail.Vanderbilt.Edu [129.59.1.75]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i2QLi1NY022331 for ; Fri, 26 Mar 2004 22:44:02 +0100 Received: from smtp1.mail.vanderbilt.edu (localhost [127.0.0.1]) by smtp1.mail.vanderbilt.edu (8.12.10/8.12.10/VU-3.7.5C+d3.7.5) with ESMTP id i2QLi0YU027853 for ; Fri, 26 Mar 2004 15:44:00 -0600 (CST) Received: from biostat032 ([160.129.129.73]) by smtp1.mail.vanderbilt.edu (8.12.10/8.12.10/VU-3.7.5B+d3.7.5) with SMTP id i2QLhxTa027836 for ; Fri, 26 Mar 2004 15:43:59 -0600 (CST) Date: Fri, 26 Mar 2004 15:45:18 -0600 From: Svetlana Eden To: R-bugs@R-project.org Subject: lookup.xport in foreign ignoring some datasets Message-Id: <20040326154518.6613fcec.svetlana.eden@vanderbilt.edu> Organization: Vanderbilt University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) The Details. In the following version. > version _ platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major 1 minor 8.1 year 2003 month 11 day 21 language R > lookup.xport ignores some datasets in sas export file. File "emptySasData3.xpt" (available at http://biostat.mc.vanderbilt.edu/tmp/emptySasData3.xpt) is a recreation of sensitive data. It was generated in SAS as an export file containing 51 empty datasets, but it has a structure of the non-empty data that revealed the problem (and can not be shared). It means that lookup.xport ignores non-empty datasets also. The file "emptySasData3.xpt" has 51 empty datasets. lookup.xport reads only 37 first datasets. (In non-empty data lookup.xport ignored datasets in the middle (not in the end) ) > look <- lookup.xport("emptySasData3.xpt") > names(look) [1] "AE" "BII" "BIO" "BLI" "BP" "C" "D" "DEA" "DEM" "DHT" [11] "DIS" "DP" "E" "EC" "EL" "G" "HS" "HU" "IN" "IP" [21] "L" "LT" "MC" "MO" "NO" "PAS" "PAT" "PATH" "PO" "PR" [31] "PS" "PV" "Q" "RA" "RE" "SA" "SL" The following datasets were not read by lookup.xport UR, URN, VIS, VIT, VO. The example of the SAS code used to builds the empty data from the non-empty data in "export.xpt". options nofmterr; proc options;run; libname x sasv5xpt "H:\projects\export.xpt"; libname y sasv5xpt "H:\projects\emptySasData3.xpt"; data ae; set x.ae(obs = 0); run; ... data vit; set x.vital(obs = 0); run; data vo; set x.volume(obs = 0); run; proc copy in = work out = y; run; I think I did not miss anything, thank you, Svetlana -- Svetlana Eden Biostatistician II School of Medicine Department of Biostatistics Vanderbilt University ==> 6701.reply.1 <== From p.dalgaard@biostat.ku.dk Fri Mar 26 23:40:00 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from turmalin.kubism.ku.dk (turmalin.kubism.ku.dk [192.38.18.18]) by slim.kubism.ku.dk (Postfix) with ESMTP id E326CEDF2; Fri, 26 Mar 2004 23:40:00 +0100 (CET) Received: from turmalin.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by turmalin.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i2QMeBRF018186; Fri, 26 Mar 2004 23:40:11 +0100 Received: (from pd@localhost) by turmalin.kubism.ku.dk (8.12.8/8.12.8/Submit) id i2QMe7FB018182; Fri, 26 Mar 2004 23:40:07 +0100 X-Authentication-Warning: turmalin.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: svetlana.eden@vanderbilt.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] lookup.xport in foreign ignoring some datasets (PR#6701) References: <20040326214433.3D2A010438@slim.kubism.ku.dk> From: Peter Dalgaard Date: 26 Mar 2004 23:40:07 +0100 In-Reply-To: <20040326214433.3D2A010438@slim.kubism.ku.dk> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) svetlana.eden@vanderbilt.edu writes: > The following datasets were not read by lookup.xport > UR, URN, VIS, VIT, VO. > > > The example of the > SAS code used to builds the empty data > from the non-empty data in "export.xpt". > > options nofmterr; > proc options;run; > libname x sasv5xpt "H:\projects\export.xpt"; > libname y sasv5xpt "H:\projects\emptySasData3.xpt"; ******** SAS version 5 XPORT libraries? Why? Does it work any different with libname x xport "H:\what\ever"; ? > data ae; set x.ae(obs = 0); run; > ... > data vit; set x.vital(obs = 0); run; > data vo; set x.volume(obs = 0); run; > proc copy in = work out = y; run; -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6701.audit <== Sun Mar 28 11:03:42 2004 ripley changed notes Sun Mar 28 11:03:42 2004 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6819 * Subject: package fdim slopeopt error From: phddas@yahoo.com Date: Sun, 25 Apr 2004 00:23:42 +0200 (CEST) --`Fred J.' claims that the maintainer's email address does not work. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6819 <== From phddas@yahoo.com Sun Apr 25 00:23:43 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 61D10EB64 for ; Sun, 25 Apr 2004 00:23:42 +0200 (CEST) From: phddas@yahoo.com To: R-bugs@biostat.ku.dk Subject: package fdim slopeopt error Message-Id: <20040424222342.61D10EB64@slim.kubism.ku.dk> Date: Sun, 25 Apr 2004 00:23:42 +0200 (CEST) X-Spam-Status: No, hits=2.5 required=5.0 tests=BAYES_30,FORGED_YAHOO_RCVD,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Fred J. Version: 1.8.1 OS: windows 2000 Submission from: (NULL) (203.26.24.216) platform i386-pc-mingw32 the error can be duplicated as follows > rt <- data.frame(8:15, 7:14, 6:13, 5:12, 4:11, 3:10, 2:9, 1:8) > library(fdim) > FD <- (fdim(rt,q=2)) Error in slopeopt(AllPoints, Alpha) : Object "LineP" not found ==> 6819.audit <== Mon Apr 26 08:19:01 2004 ripley changed notes Mon Apr 26 08:19:01 2004 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6895 * Subject: foreign package: reading epiinfo From: giles.crane@doh.state.nj.us Date: Wed, 19 May 2004 19:30:34 +0200 (CEST) --request for example file met no response ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6895 <== From giles.crane@doh.state.nj.us Wed May 19 19:30:35 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5F730105C8 for ; Wed, 19 May 2004 19:30:34 +0200 (CEST) From: giles.crane@doh.state.nj.us To: R-bugs@biostat.ku.dk Subject: foreign package: reading epiinfo Message-Id: <20040519173034.5F730105C8@slim.kubism.ku.dk> Date: Wed, 19 May 2004 19:30:34 +0200 (CEST) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Giles L. Crane Version: 1.9 OS: Windows 98 Submission from: (NULL) (199.20.71.17) The foreign package enables R users to read datasets from other software. The read.epiinfo module works well for most EPI6 (EPI-INFO) .REC files. However, when the .REC file has an underline in column one, read.epiinfo seems to pick this underline and make the underline the first character in the variable name. In the ASCII text .REC files, the first character is used to indicate a how a variable is displayed when entering data -- the first character is not part of the variables name. The EPI6 variable name begins in column 2. I think read.epiinfo could be fixed easily. Cordially, Giles Crane ==> 6895.followup.1 <== From tlumley@u.washington.edu Wed May 19 20:55:23 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 98D651053F for ; Wed, 19 May 2004 20:55:23 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00921-08 for ; Wed, 19 May 2004 20:55:22 +0200 (CEST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 19 May 2004 20:55:21 +0200 (CEST) Received: from homer06.u.washington.edu (homer06.u.washington.edu [140.142.15.40]) by mxout1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4JItEe5031115; Wed, 19 May 2004 11:55:15 -0700 Received: from localhost (tlumley@localhost) by homer06.u.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4JItDqd200948; Wed, 19 May 2004 11:55:13 -0700 Date: Wed, 19 May 2004 11:55:13 -0700 (PDT) From: Thomas Lumley To: giles.crane@doh.state.nj.us Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] foreign package: reading epiinfo (PR#6895) In-Reply-To: <20040519173103.8B94A10618@slim.kubism.ku.dk> Message-ID: References: <20040519173103.8B94A10618@slim.kubism.ku.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Wed, 19 May 2004 giles.crane@doh.state.nj.us wrote: > > The read.epiinfo module works well > for most EPI6 (EPI-INFO) .REC files. > However, when the .REC file has > an underline in column one, > read.epiinfo seems to pick this underline > and make the underline the first character > in the variable name. > If you could make an example file available it would be easier to fix this. -thomas. ==> 6895.audit <== Mon May 24 08:37:17 2004 ripley moved from incoming to Add-ons Thu Jun 17 01:46:03 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6904 * Subject: Failure to preserve package attribute when coercing S4 objects From: "Swinton, Jonathan" Date: Fri, 21 May 2004 15:04:10 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6904 <== From mail@stat.math.ethz.ch Fri May 21 16:08:49 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 9554B1058E for ; Fri, 21 May 2004 16:08:49 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13413-04 for ; Fri, 21 May 2004 16:08:48 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 21 May 2004 16:08:47 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i4LE8lG8021577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2004 16:08:47 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i4LE8kpJ021575 for R-bugs@biostat.ku.dk; Fri, 21 May 2004 16:08:47 +0200 Received: from zcsn04.astrazeneca.com (zcsn04.astrazeneca.com [193.132.159.175]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i4LE8g2k021556 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 21 May 2004 16:08:45 +0200 Received: from zcsn14.ukhx.astrazeneca.net (zcsn14.ukhx.astrazeneca.net [192.168.199.14]) by zcsn04.astrazeneca.com (8.12.11/8.12.11) with ESMTP id i4LE8YPr008757 for ; Fri, 21 May 2004 15:08:41 +0100 (BST) Received: from zcsn24.ukhx.astrazeneca.net (zcsn24.ukhx.astrazeneca.net [156.71.247.47]) by zcsn14.ukhx.astrazeneca.net (8.12.11/8.12.11/AZ-def_main_in.12.11.0) with ESMTP id i4LE4GE5014483 for ; Fri, 21 May 2004 15:04:16 +0100 (BST) Received: from ukapzcmsxhub01.ukap.astrazeneca.net (ukapzcmsxhub01.ukap.astrazeneca.net [156.71.158.135]) by zcsn24.ukhx.astrazeneca.net (8.12.11/8.12.11) with ESMTP id i4LE4GlL020086 for ; Fri, 21 May 2004 15:04:16 +0100 (BST) Received: by ukapzcmsxhub01.ukap.astrazeneca.net with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 15:04:15 +0100 Message-ID: From: "Swinton, Jonathan" To: "'r-bugs@lists.r-project.org'" Subject: Failure to preserve package attribute when coercing S4 objects Date: Fri, 21 May 2004 15:04:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of jonathan.swinton@astrazeneca.com does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) If a class is derived from a superclass using 'contains', then coercion of an object from the class to the superclass fails to preserve the 'package' attribute of class of the object. This occurs only when the derived class has no additional slots. This is a problem because the 'new' function relies on the exact identity of the class, including the package attribute. This can clearly be worked around by the introduction of dummy slots, but it took me some time to track down. > setClass("baseClass",representation(a="numeric")) [1] "baseClass" > setClass("fancyClass",contains="baseClass") [1] "fancyClass" > setClass("fancyClassExtraSlots",representation(b="numeric"),contains="baseCl ass") [1] "fancyClassExtraSlots" > > > aFP <- new("fancyClass",a=2) > aFP2 <- new("fancyClassExtraSlots",a=2,b=3) > > aBP <- new("baseClass",a=1) > aBPcast <- as(aFP,"baseClass") > aBPcast2 <- as(aFP2,"baseClass") > # all the baseClass objects have the right class > sapply(list(aBP,aBPcast,aBPcast2),class) [1] "baseClass" "baseClass" "baseClass" > # however the object cast from a fancy class with no slots has a different package attribute > sapply(list(aBP,aBPcast,aBPcast2),function(x)attr(class(x),"package")) [[1]] [1] ".GlobalEnv" [[2]] NULL [[3]] [1] ".GlobalEnv" > new("baseClass",aBP) # works An object of class "baseClass" Slot "a": [1] 1 > new("baseClass",aBPcast) # fails. Note the error message! Error in initialize(value, ...) : Initialize method returned an object of class "baseClass" instead of the required class "baseClass" > new("baseClass",aBPcast2) # works An object of class "baseClass" Slot "a": [1] 2 platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 1 minor 9.0 year 2004 month 04 day 12 language R Jonathan Swinton, Statistical Scientist, Computational Biology, Pathway Analysis, Global Sciences and Information, x29400, 19F44 Mereside Alderley Park. ==> 6904.audit <== Thu Jul 1 09:34:51 2004 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6978 * Subject: inheritance problem in multcomp package From: "Richard M. Heiberger" Date: Sun, 13 Jun 2004 21:35:50 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6978 <== From mail@stat.math.ethz.ch Mon Jun 14 03:35:55 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 085D5F309 for ; Mon, 14 Jun 2004 03:35:55 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03915-06 for ; Mon, 14 Jun 2004 03:35:54 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 14 Jun 2004 03:35:54 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5E1ZrSc006289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jun 2004 03:35:53 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i5E1ZrcP006287 for R-bugs@biostat.ku.dk; Mon, 14 Jun 2004 03:35:53 +0200 Received: from po-smtp2.temple.edu (po-smtp2.temple.edu [155.247.166.196]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5E1Zo7x006263 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 14 Jun 2004 03:35:52 +0200 Received: from po-d.temple.edu (po-d.temple.edu [155.247.166.222]) by po-smtp2.temple.edu (MOS 3.4.5-GR) with ESMTP id BOH27212; Sun, 13 Jun 2004 21:35:50 -0400 (EDT) Received: from 155.247.229.6 by po-d.temple.edu (MOS 3.4.5-GR) with HTTPS/1.1; Sun, 13 Jun 2004 21:35:50 -0400 Date: Sun, 13 Jun 2004 21:35:50 -0400 From: "Richard M. Heiberger" Subject: inheritance problem in multcomp package To: r-bugs@r-project.org X-Mailer: Webmail Mirapoint Direct 3.4.5-GR MIME-Version: 1.0 Message-Id: <1113bf18.50141914.830c100@po-d.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=po-smtp2.temple.edu Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of rmh@temple.edu does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### The multcomp functions work on "lm" objects as anticipated. They do not work on "aov" objects. Somehow the inheritance isn't being acknowledged. I can't spot where in the code the problem lies. Somewhere the df argument for "aov" objects is not defined. My workaround is to change the class of the "aov" object to "lm". Rich > search() [1] ".GlobalEnv" "package:multcomp" "package:mvtnorm" "package:methods" [5] "package:stats" "package:utils" "package:graphics" "package:lattice" [9] "package:grid" "Autoloads" "package:base" > ## from R/rw1091alpha/library/multcomp/R-ex/simint.R > data(recovery) > lmmod <- lm(minutes ~ blanket, data=recovery, contrasts=list(blanket = + "contr.Dunnett")) > summary(simint(lmmod, psubset=2:4, conf.level=0.9, + alternative="less",eps=0.0001)) Simultaneous 90% confidence intervals: model contrasts model contrasts for factor Contrast matrix: [,1] [,2] [,3] [1,] 1 0 0 [2,] 0 1 0 [3,] 0 0 1 Absolute Error Tolerance: 1e-04 90 % quantile: 1.8431 Coefficients: Estimate -- 90 % t value Std.Err. p raw p Bonf p adj blanketb1-b0 -2.1333 -Inf 0.8226 -1.3302 1.6038 0.0958 0.2874 0.2412 blanketb2-b0 -7.4667 -Inf -4.5108 -4.6556 1.6038 0.0000 0.0001 0.0001 blanketb3-b0 -1.6667 -Inf -0.0360 -1.8837 0.8848 0.0337 0.1012 0.0924 > ## change lm to aov > aovmod <- aov(minutes ~ blanket, data=recovery, contrasts=list(blanket = + "contr.Dunnett")) > aovmod Call: aov(formula = minutes ~ blanket, data = recovery, contrasts = list(blanket = "contr.Dunnett")) Terms: blanket Residuals Sum of Squares 151.9772 248.2667 Deg. of Freedom 3 37 Residual standard error: 2.590349 Estimated effects may be unbalanced > simint(aovmod) Error in floor(df) : Non-numeric argument to mathematical function > names(aovmod) [1] "coefficients" "residuals" "effects" "rank" [5] "fitted.values" "assign" "qr" "df.residual" [9] "contrasts" "xlevels" "call" "terms" [13] "model" > names(lmmod) [1] "coefficients" "residuals" "effects" "rank" [5] "fitted.values" "assign" "qr" "df.residual" [9] "contrasts" "xlevels" "call" "terms" [13] "model" > all.equal(lmmod, aovmod) [1] "Attributes: < Component 1: Lengths (1, 2) differ (string compare on first 1) >" [2] "Attributes: < Component 1: 1 string mismatches >" [3] "Component 11: target, current don't match when deparsed" > attributes(lmmod) $names [1] "coefficients" "residuals" "effects" "rank" [5] "fitted.values" "assign" "qr" "df.residual" [9] "contrasts" "xlevels" "call" "terms" [13] "model" $class [1] "lm" > attributes(aovmod) $names [1] "coefficients" "residuals" "effects" "rank" [5] "fitted.values" "assign" "qr" "df.residual" [9] "contrasts" "xlevels" "call" "terms" [13] "model" $class [1] "aov" "lm" > lmmod$call lm(formula = minutes ~ blanket, data = recovery, contrasts = list(blanket = "contr.Dunnett")) > aovmod$call aov(formula = minutes ~ blanket, data = recovery, contrasts = list(blanket = "contr.Dunnett")) > ### play games > class(aovmod) <- "lm" > summary(simint(aovmod, psubset=2:4, conf.level=0.9, + alternative="less",eps=0.0001)) Simultaneous 90% confidence intervals: model contrasts model contrasts for factor Contrast matrix: [,1] [,2] [,3] [1,] 1 0 0 [2,] 0 1 0 [3,] 0 0 1 Absolute Error Tolerance: 1e-04 90 % quantile: 1.8431 Coefficients: Estimate -- 90 % t value Std.Err. p raw p Bonf p adj blanketb1-b0 -2.1333 -Inf 0.8226 -1.3302 1.6038 0.0958 0.2874 0.2412 blanketb2-b0 -7.4667 -Inf -4.5107 -4.6556 1.6038 0.0000 0.0001 0.0001 blanketb3-b0 -1.6667 -Inf -0.0359 -1.8837 0.8848 0.0337 0.1012 0.0924 > bug.report("inheritance problem in multcomp package") --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = alpha major = 1 minor = 9.1 year = 2004 month = 05 day = 25 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/.RData, file:c:/HOME/rmh/hh/splus.library/HH/.RData, package:multcomp, package:mvtnorm, package:methods, package:stats, package:utils, package:graphics, package:lattice, package:grid, Autoloads, package:base ==> 6978.audit <== Thu Jun 17 01:39:24 2004 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6989 * Subject: read.epiinfo makes field char part of variable name From: giles.crane@doh.state.nj.us Date: Thu, 17 Jun 2004 17:52:32 +0200 (CEST) --part of foreign ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6989 <== From giles.crane@doh.state.nj.us Thu Jun 17 17:52:33 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id F3B1CE968 for ; Thu, 17 Jun 2004 17:52:32 +0200 (CEST) From: giles.crane@doh.state.nj.us To: R-bugs@biostat.ku.dk Subject: read.epiinfo makes field char part of variable name Message-Id: <20040617155232.F3B1CE968@slim.kubism.ku.dk> Date: Thu, 17 Jun 2004 17:52:32 +0200 (CEST) X-Spam-Status: No, hits=2.2 required=5.0 tests=BAYES_30,DEAR_SOMETHING,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Giles L. Crane Version: 1.9 OS: Windows 98 Submission from: (NULL) (199.20.71.17) Dear Sir, The foreign library function read.epiinfo incorrectly makes the field character part of the variable name. When the field character is space, the variable name is not affected. However, when the field character is underline (_) the variable name has the underline as the first character. This is incorrect. I would guess that when reading or scanning a line in the heading, the first character is sometimes picked up incorrectly as part of the variable name. In the heading of the EPI6 .REC file, which is a text file, after the first line, the first character in the next lines contain a field character as the first characters. (The "field character" is used by the data entry program ENTER.EXE or ENTERX.EXE as the character initially filling the variable on the data entry screen.) Thank you for your attention. Cordially, GLC ==> 6989.audit <== Fri Jun 18 14:24:07 2004 ripley changed notes Fri Jun 18 14:24:07 2004 ripley moved from incoming to Add-ons ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7007 * Subject: lme4 fails to install on R-1.9/FreeBSD-5.2 From: wb@arb-phys.uni-dortmund.de Date: Tue, 22 Jun 2004 20:53:01 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7007 <== From wb@arb-phys.uni-dortmund.de Tue Jun 22 20:53:05 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3A9B0D622 for ; Tue, 22 Jun 2004 20:53:01 +0200 (CEST) From: wb@arb-phys.uni-dortmund.de To: R-bugs@biostat.ku.dk Subject: lme4 fails to install on R-1.9/FreeBSD-5.2 Message-Id: <20040622185301.3A9B0D622@slim.kubism.ku.dk> Date: Tue, 22 Jun 2004 20:53:01 +0200 (CEST) X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: W.B.Kloke Version: 1.9.1 OS: FreeBSD-5.2.1 Submission from: (NULL) (195.253.16.182) Subject line says it. I had problems installing lme4. 1. The dependency on package Matrix was not resolved (I am not sure that this is really a bug; but it is annoying, anyway). 2. Installing Matrix failed with a message saying something like "no rule for %_D.o" after compiling a lot of sources and combining them into an archive. I traced this down to a Linuxism. I found the string _D.o in subdirectory taucs of Matrix. Forcing GNU make by adding MAKE=gmake to the environment of R installed the package successfully. I consider this a real non-portability bug. ==> 7007.audit <== Wed Jun 23 10:52:24 2004 ripley moved from incoming to Add-ons ==> 7007.followup.1 <== From ripley@stats.ox.ac.uk Wed Jun 23 14:30:07 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0A7D3F473 for ; Wed, 23 Jun 2004 14:30:07 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11573-03 for ; Wed, 23 Jun 2004 14:30:06 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 23 Jun 2004 14:30:05 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i5NCU4rt019321; Wed, 23 Jun 2004 13:30:04 +0100 (BST) Date: Wed, 23 Jun 2004 13:30:04 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: wb@arb-phys.uni-dortmund.de Cc: r-devel@stat.math.ethz.ch, , Douglas Bates Subject: Re: [Rd] lme4 fails to install on R-1.9/FreeBSD-5.2 (PR#7007) In-Reply-To: <20040622185306.A1225EC53@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Please send reports on contributed packages to the package maintainer (Cc:ed here, but he is on leave this summer so don't expect a fast response). On Tue, 22 Jun 2004 wb@arb-phys.uni-dortmund.de wrote: > Full_Name: W.B.Kloke > Version: 1.9.1 What about the package versions? > OS: FreeBSD-5.2.1 > Submission from: (NULL) (195.253.16.182) > > > Subject line says it. I had problems installing lme4. Actually not (especially as there is no R-1.9). I gather you had problems installing Matrix, and the bug you found is in Matrix. > 1. The dependency on package Matrix was not resolved (I am not sure that this is > really a bug; but it is annoying, anyway). I am not sure what you mean here. It seems you did not install Matrix first? Did you expect install.packages() to do that for you? > 2. Installing Matrix failed with a message saying something like "no rule for > %_D.o" > after compiling a lot of sources and combining them into an archive. I traced > this down to a Linuxism. I found the string _D.o in subdirectory taucs of > Matrix. Forcing GNU make by adding MAKE=gmake to the environment of R installed > the package successfully. I consider this a real non-portability bug. GNUism, I suspect. There seem to be similar problems on Solaris. make: Fatal error in reader: Makefile, line 32: Extra `:', `::', or `:=' on dependency line Current working directory /tmp/R.INSTALL.28676/Matrix/src/taucs I managed to get this to compile and check (apart from some documentation problems) with %_D.o: %.c $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) $(TDFLAGS) -c $< -o $@ %.o: %.c $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) $(TGFLAGS) -c $< -o $@ (there is no TAUCS_G to worry about). I am sure Dr Bates will appreciate your sending him a tested patch when you get it working. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Analyses * PR# 3325 * Subject: optim with constraints From: aa@tango.stat.unipd.it (Adelchi Azzalini) Date: Mon, 23 Jun 2003 17:51:19 +0200 (CEST) --deep inside the L-BFGS-B code, but looks a badly scaled problem. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3325 <== From mailnull@stat.math.ethz.ch Mon Jun 23 17:52:57 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h5NFquJH026936 for ; Mon, 23 Jun 2003 17:52:57 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5NFqkU3013122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jun 2003 17:52:47 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h5NFqkK2013121 for R-bugs@biostat.ku.dk; Mon, 23 Jun 2003 17:52:46 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5NFqaU2013095 for ; Mon, 23 Jun 2003 17:52:37 +0200 (MEST) Received: from tango.stat.unipd.it ([147.162.23.130]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19UTck-0002jy-00 for ; Mon, 23 Jun 2003 10:52:54 -0500 Received: by tango.stat.unipd.it (Postfix, from userid 1000) id B11BF7CA824; Mon, 23 Jun 2003 17:51:19 +0200 (CEST) To: r-bugs@r-project.org Subject: optim with constraints Cc: aa@tango.stat.unipd.it Message-Id: <20030623155119.B11BF7CA824@tango.stat.unipd.it> Date: Mon, 23 Jun 2003 17:51:19 +0200 (CEST) From: aa@tango.stat.unipd.it (Adelchi Azzalini) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) The source code listed below (just before the system information) makes "optim" to ignore the bounds on one of the parameters; this is detected by the function to be optimized (sn.dev) and the program stops. On my computer the numeric optput which I obtain is: sn.dev: (cp,dev)=[1] -1.3222 0.3738 0.3263 42.1824 sn.dev.gh: gradient=[1] 2.092 4.059 -4.039 sn.dev: (cp,dev)=[1] -2.2611 0.2060 0.6266 686.3262 sn.dev.gh: gradient=[1] -1208.1 -5719.7 -287.1 sn.dev: (cp,dev)=[1] -1.3632 0.3665 0.3394 42.6260 sn.dev.gh: gradient=[1] -27.758 1.067 -4.431 sn.dev: (cp,dev)=[1] -1.3279 0.3728 0.3281 42.1705 sn.dev.gh: gradient=[1] -1.976 3.989 -4.090 sn.dev: (cp,dev)=[1] -1.3279 0.3667 0.3348 42.1461 sn.dev.gh: gradient=[1] -0.4494 -4.9931 -4.0685 sn.dev: (cp,dev)=[1] -1.3280 0.3671 0.3403 42.1219 sn.dev.gh: gradient=[1] -0.5089 -4.4250 -4.0727 sn.dev: (cp,dev)=[1] -1.3282 0.3686 0.3623 42.0268 sn.dev.gh: gradient=[1] -0.7684 -2.2082 -4.0932 sn.dev: (cp,dev)=[1] -1.3290 0.3748 0.4506 41.6734 sn.dev.gh: gradient=[1] -2.128 5.823 -4.226 sn.dev: (cp,dev)=[1] -1.3341 0.3927 0.9953 25934.9488 sn.dev.gh: gradient=[1] 219013 -312643 441647332 [1] -1.3546 0.4645 3.1741 Error in fn(par, ...) : cp outside bounds The code looks somewhat involved.. however, what it does is to set up ingredients to run the final statement: opt<- optim(cp, fn=sn.dev, gr=sn.dev.gh, method="L-BFGS-B", lower=c(-rep(Inf,m),1e-10, -0.99527), upper=c(rep(Inf,m), Inf, 0.99527), control=list(iter.max=100, abs.tol=1e-5), X=X, y=y, trace=TRUE, hessian=FALSE) The above sequence stoped because the last component of vector cp is 3.1741, which exceeds the bound 0.99527. Notice that the problem occurs "with 0 probability", in the sense that 1. if you change some of the data below (in vector monica2), then it is most likely to run fine; 2. if you change the starting point, then again it works; specifically I changed cp <- c(qr.coef(qrX,y), s, gamma1) to cp <- c(-1.322168500, 0.373810085, 0.326283975) which differ by [1] 2.666e-10 -3.154e-10 -3.033e-10 and it worked from the second starting vector; sn.dev: (cp,dev)=[1] -1.3222 0.3738 0.3263 42.1824 sn.dev.gh: gradient=[1] 2.092 4.059 -4.039 sn.dev: (cp,dev)=[1] -2.2611 0.2060 0.6266 686.3263 sn.dev.gh: gradient=[1] -1208.1 -5719.7 -287.1 sn.dev: (cp,dev)=[1] -1.3632 0.3665 0.3394 42.6260 sn.dev.gh: gradient=[1] -27.758 1.067 -4.431 sn.dev: (cp,dev)=[1] -1.3279 0.3728 0.3281 42.1705 sn.dev.gh: gradient=[1] -1.976 3.989 -4.090 sn.dev: (cp,dev)=[1] -1.3279 0.3667 0.3348 42.1461 sn.dev.gh: gradient=[1] -0.4494 -4.9931 -4.0685 sn.dev: (cp,dev)=[1] -1.3280 0.3671 0.3403 42.1219 sn.dev.gh: gradient=[1] -0.5089 -4.4250 -4.0727 sn.dev: (cp,dev)=[1] -1.3282 0.3686 0.3623 42.0268 sn.dev.gh: gradient=[1] -0.7684 -2.2082 -4.0932 sn.dev: (cp,dev)=[1] -1.3290 0.3748 0.4506 41.6734 sn.dev.gh: gradient=[1] -2.128 5.823 -4.226 sn.dev: (cp,dev)=[1] -1.3341 0.3927 0.9953 25934.8747 sn.dev.gh: gradient=[1] 219013 -312642 441646067 sn.dev: (cp,dev)=[1] -1.3307 0.3808 0.6321 40.9462 sn.dev.gh: gradient=[1] -2.806 8.579 -4.256 sn.dev: (cp,dev)=[1] -1.3324 0.3867 0.8137 40.3288 <..snip..> sn.dev: (cp,dev)=[1] -1.3505 0.4184 0.9953 35.7271 sn.dev.gh: gradient=[1] 12.18 -13.92 -13349.90 > opt $par [1] -1.3505 0.4184 0.9953 $value [1] 35.73 $counts function gradient 44 44 $convergence [1] 0 $message [1] "CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH" 3. when I run the same code on my MS-windows 2000 laptop (R 1.7.0), again it runs fine. Hope to have provided a complete description. With best regards, Adelchi Azzalini Dipart.Scienze Statistiche, Università di Padova, Italia http://azzalini.stat.unipd.it/ #-------------------------------------------- # code which produced the above output, you can just source() it rm(list=ls()) sn.dev <- function(cp, X, y, trace=FALSE) { # -2*logL for centred parameters m <- ncol(X) if(abs(cp[length(cp)])> 0.99527) {print(cp); stop("cp outside bounds")} dp <- as.vector(cp.to.dp(cp)) location <- X %*% as.matrix(dp[1:m]) scale <- dp[m+1] # AVOID: logL <- sum(log(dsn(y,location,dp[m+1],dp[m+2]))) z <- (y-location)/scale nlogL <- (length(y)*log(2.506628274631*scale) + 0.5*sum(z^2) - sum(zeta(0,dp[m+2]*z))) if(trace) {cat("sn.dev: (cp,dev)="); print(c(cp,2*nlogL))} return(2*nlogL) } sn.dev.gh <- function(cp, X, y, trace=FALSE, hessian=FALSE) { # computes gradient and hessian of dev=-2*logL for centred parameters # (and observed information matrix); m <- ncol(X) n <- nrow(X) np <- m+2 score <- rep(NA,np) info <- matrix(NA,np,np) beta <- cp[1:m] sigma <- cp[m+1] gamma1 <- cp[m+2] lambda <- gamma1.to.lambda(gamma1) # dp<-cp.to.dp(c(beta,sigma,gamma1)) # info.dp <- sn.info(dp,y)$info.dp mu <- as.vector(X %*% as.matrix(beta)) d <- y-mu r <- d/sigma E.Z<- lambda*sqrt(2/(pi*(1+lambda^2))) s.Z<- sqrt(1-E.Z^2) z <- E.Z+s.Z*r p1 <- as.vector(zeta(1,lambda*z)) p2 <- as.vector(zeta(2,lambda*z)) omega<- sigma/s.Z w <- lambda*p1-E.Z DE.Z <- sqrt(2/pi)/(1+lambda^2)^1.5 Ds.Z <- (-E.Z/s.Z)*DE.Z Dz <- DE.Z + r*Ds.Z DDE.Z<- (-3)*E.Z/(1+lambda^2)^2 DDs.Z<- -((DE.Z*s.Z-E.Z*Ds.Z)*DE.Z/s.Z^2+E.Z*DDE.Z/s.Z) DDz <- DDE.Z + r*DDs.Z score[1:m] <- omega^(-2)*t(X) %*% as.matrix(y-mu-omega*w) score[m+1] <- (-n)/sigma+s.Z*sum(d*(z-p1*lambda))/sigma^2 score[m+2] <- score.l <- n*Ds.Z/s.Z-sum(z*Dz)+sum(p1*(z+lambda*Dz)) Dg.Dl <-1.5*(4-pi)*E.Z^2*(DE.Z*s.Z-E.Z*Ds.Z)/s.Z^4 R <- E.Z/s.Z T <- sqrt(2/pi-(1-2/pi)*R^2) Dl.Dg <- 2*(T/(T*R)^2+(1-2/pi)/T^3)/(3*(4-pi)) R. <- 2/(3*R^2 * (4-pi)) T. <- (-R)*R.*(1-2/pi)/T DDl.Dg <- (-2/(3*(4-pi))) * (T./(R*T)^2+2*R./(T*R^3)+3*(1-2/pi)*T./T^4) score[m+2] <- score[m+2]/Dg.Dl # convert deriv wrt lamda to gamma1 gradient <- (-2)*score if(hessian){ info[1:m,1:m] <- omega^(-2) * t(X) %*% ((1-lambda^2*p2)*X) info[1:m,m+1] <- info[m+1,1:m] <- s.Z* t(X) %*% as.matrix((z-lambda*p1)+d*(1-lambda^2*p2)* s.Z/sigma)/sigma^2 info[m+1,m+1] <- (-n)/sigma^2+2*s.Z*sum(d*(z-lambda*p1))/sigma^3 + s.Z^2*sum(d*(1-lambda^2*p2)*d)/sigma^4 info[1:m,m+2] <- info[m+2,1:m] <- t(X)%*%(-2*Ds.Z*d/omega+Ds.Z*w+s.Z*(p1+lambda*p2*(z+lambda*Dz) -DE.Z))/sigma info[m+1,m+2] <- info[m+2,m+1] <- -sum(d*(Ds.Z*(z-lambda*p1)+s.Z*(Dz-p1-p2*lambda*(z+lambda*Dz)) ))/sigma^2 info[m+2,m+2] <- (n*(-DDs.Z*s.Z+Ds.Z^2)/s.Z^2+sum(Dz^2+z*DDz)- sum(p2*(z+lambda*Dz)^2)- sum(p1*(2*Dz+lambda*DDz))) info[np,] <- info[np,]/Dg.Dl # convert info wrt lamda to gamma1 info[,np] <- info[,np]*Dl.Dg # an equivalent form of the above info[np,np] <- info[np,np]-score.l*DDl.Dg } attr(gradient,"hessian") <- 2*info if(trace) {cat("sn.dev.gh: gradient="); print(-2*score)} return(gradient) } cp.to.dp <- function(param){ # converts centred parameters cp=(mu,sigma,gamma1) # to direct parameters dp=(xi,omega,lambda) # Note: mu can be m-dimensional, the other must be scalars b <- sqrt(2/pi) m <- length(param)-2 gamma1 <- param[m+2] if(abs(gamma1)>0.9952719) stop("abs(gamma1)>0.9952719 ") A <- sign(gamma1)*(abs(2*gamma1/(4-pi)))^(1/3) delta <- A/(b*sqrt(1+A^2)) lambda <- delta/sqrt(1-delta^2) E.Z <- b*delta sd.Z <- sqrt(1-E.Z^2) location <- param[1:m] location[1] <- param[1]-param[m+1]*E.Z/sd.Z scale <- param[m+1]/sd.Z dp <- c(location,scale,lambda) names(dp)[(m+1):(m+2)] <- c("scale","shape") if(m==1) names(dp)[1] <- "location" dp } zeta <- function(k,x){# k integer \in (0,4) k <- as.integer(k) na <- is.na(x) x <- replace(x,na,0) if(any(abs(x)==Inf)) stop("Inf not allowed") # funzionerebbe per k=0 e 1, ma non per k>1 ok <- (-352 & sum(!ok)>0) na<- (na | x < (-35)) if(k==0) {ax <- (-x[!ok]) ay <- (-0.918938533204673)-0.5*ax^2-log(ax) y <- rep(NA,length(x)) y[ok] <- log(2*pnorm(x[ok])) y[!ok]<- ay } else {if(k==1) {y <- (-x)*(1+1/x^2) y[ok]<-dnorm(x[ok])/pnorm(x[ok]) } else { if(k==2) y<-(-zeta(1,x)*(x+zeta(1,x))) else{ if(k==3) y<-(-zeta(2,x)*(x+zeta(1,x))-zeta(1,x)*(1+zeta(2,x))) else{ if(k==4) y<-(-zeta(3,x)*(x+2*zeta(1,x))-2*zeta(2,x)*(1+zeta(2,x))) else stop("k must be integer in (0,4)") }}}} replace(y,na,NA) } gamma1.to.lambda<- function(gamma1){ max.gamma1 <- 0.5*(4-pi)*(2/(pi-2))^1.5 na <- (abs(gamma1)>max.gamma1) if(any(na)) warning("NAs generated") gamma1<-replace(gamma1,na,NA) a <- sign(gamma1)*(2*abs(gamma1)/(4-pi))^0.33333 delta<- sqrt(pi/2)*a/sqrt(1+a^2) lambda<-delta/sqrt(1-delta^2) as.vector(lambda) } monica2 <- structure(c(-1.13886379255452, -1.49413719201167, -1.87841064955904, -0.513738594928947, -1.00896950224601, -1.6532307897784, -1.30938967543405, -1.06041025293133, -1.81471688461199, -1.33766295196981, -1.64330728995432, -1.06469899752166, -1.00001063084463, -1.39630202884595, -0.69585045438959, -1.69203796703315, -1.52865988854611, -1.62709073708234, -0.934436685805195, -1.11123590657362, -1.67332502980791, -1.16134216754217, -1.27483304830845, -1.83766242751329, -1.56429386551254, -0.70663591112117, -0.806879736670856, -1.39706539761330, -1.48444503984765, -1.48192041745309, -0.763350185813698, -1.42340943250413, -1.5034850496403, -0.916057843936642, -0.797650717731944, -1.90218776624194, -1.89573584905280, -1.55031254908193, -1.55488970245028, -1.17137569123985, -1.81490209565657, -1.82974300222698, -0.797407302025425, -1.16514651844490, -1.31007112485982, -1.71325589588157, -1.54253707834837, -1.28190616471927, -1.28990272862791, -0.593534374170964), parameters = c(-1.71631422551004, 0.5, 2)) #---- # cp <- c(-1.322168500, 0.373810085, 0.326283975) y <- monica2 X <- matrix(1, nrow=length(monica2)) n <- length(y) m <- ncol(X) qrX <- qr(X) s <- sqrt(sum(qr.resid(qrX, y)^2)/n) gamma1 <- sum(qr.resid(qrX, y)^3)/(n*s^3) if(abs(gamma1)>0.99527) gamma1<- sign(gamma1)*0.95 cp <- c(qr.coef(qrX,y), s, gamma1) opt<- optim(cp, fn=sn.dev, gr=sn.dev.gh, method="L-BFGS-B", lower=c(-rep(Inf,m),1e-10, -0.99527), upper=c(rep(Inf,m), Inf, 0.99527), control=list(iter.max=100, abs.tol=1e-5), X=X, y=y, trace=TRUE, hessian=FALSE) --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 7.0 year = 2003 month = 04 day = 16 language = R Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, file:/home/aa/SW/R-misc/local-def.save, Autoloads, package:base ==> 3325.audit <== Tue Sep 2 08:05:31 2003 ripley changed notes Tue Sep 2 08:05:31 2003 ripley foobar Tue Sep 2 08:05:31 2003 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3666 * Subject: wilcox.test, CI From: d.a.wooff@durham.ac.uk Date: Wed, 6 Aug 2003 11:31:37 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3666 <== From d.a.wooff@durham.ac.uk Wed Aug 6 11:31:38 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h769VbJH023799 for ; Wed, 6 Aug 2003 11:31:38 +0200 (MET DST) Date: Wed, 6 Aug 2003 11:31:37 +0200 (MET DST) Message-Id: <200308060931.h769VbJH023799@pubhealth.ku.dk> From: d.a.wooff@durham.ac.uk To: R-bugs@biostat.ku.dk Subject: wilcox.test, CI Full_Name: David Wooff Version: 1.7.0 OS: i686-pc-linux-gnu Submission from: (NULL) (129.234.4.10) wilcox.test exits with error message when confidence interval required, under some situations. I suspect this occurs when the data contain a zero and for some data lengths only: print(wilcox.test(c(2,1,4,3,6,-5,0),conf.int=T)) fails print(wilcox.test(c(2,1,4,3,6,-5,0,1),conf.int=T)) works print(wilcox.test(c(2,1,4,3,6,-5,1),conf.int=T)) works Apologies if this is known - did search bug lists first. David. ==> 3666.audit <== Thu Aug 7 21:05:10 2003 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4757 * Subject: NLME: gls parameter evaluation inconsistency From: wb@arb-phys.uni-dortmund.de Date: Fri, 24 Oct 2003 14:52:26 +0200 (MET DST) --It's a known problem. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4757 <== From wb@arb-phys.uni-dortmund.de Fri Oct 24 14:52:27 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9OCqQ0P011905 for ; Fri, 24 Oct 2003 14:52:27 +0200 (MET DST) Date: Fri, 24 Oct 2003 14:52:26 +0200 (MET DST) Message-Id: <200310241252.h9OCqQ0P011905@pubhealth.ku.dk> From: wb@arb-phys.uni-dortmund.de To: R-bugs@biostat.ku.dk Subject: NLME: gls parameter evaluation inconsistency Full_Name: W.B.Kloke Version: 1.8.0 OS: FreeBSD-4.7 Submission from: (NULL) (195.253.22.63) I found a parameter evaluation inconsistency in NLME package. I tried to use gls() inside a function, and I wanted use gls() for different subsets of a data frame: prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t ,pr,subset=subject==name)} Applying this function with a string as parameter like prgls("VM") yields an error Error in eval(expr, envir, enclos) : Object "name" not found The same definition with lm() instead of gls() works fine. Of course I want to use the correlation features of gls(). It looks like a wrong environment at the place of subset evaluation (the local variables and function paramaters are not available). Probably lme(), ngls() and nlme() have the same inconsistency. ==> 4757.reply.1 <== From bates@bates4.stat.wisc.edu Fri Oct 24 18:16:30 2003 Received: from bates4.stat.wisc.edu (mail@bates4.stat.wisc.edu [128.105.174.134]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9OGGT0P014375 for ; Fri, 24 Oct 2003 18:16:30 +0200 (MET DST) Received: from bates by bates4.stat.wisc.edu with local (Exim 3.36 #1 (Debian)) id 1AD4by-0002kW-00; Fri, 24 Oct 2003 11:16:26 -0500 To: wb@arb-phys.uni-dortmund.de Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] NLME: gls parameter evaluation inconsistency (PR#4757) References: <200310241252.h9OCqS0P011909@pubhealth.ku.dk> From: Douglas Bates Date: 24 Oct 2003 11:16:25 -0500 In-Reply-To: <200310241252.h9OCqS0P011909@pubhealth.ku.dk> Message-ID: <6rwuau4nmu.fsf@bates4.stat.wisc.edu> Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Douglas Bates wb@arb-phys.uni-dortmund.de writes: > Full_Name: W.B.Kloke > Version: 1.8.0 > OS: FreeBSD-4.7 > Submission from: (NULL) (195.253.22.63) > > > I found a parameter evaluation inconsistency in NLME package. I tried to use > gls() inside a function, and I wanted use gls() for different subsets of a data > frame: > > prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t > ,pr,subset=subject==name)} > > Applying this function with a string as parameter like prgls("VM") > yields an error Error in eval(expr, envir, enclos) : Object "name" > not found > > The same definition with lm() instead of gls() works fine. Of course > I want to use the correlation features of gls(). It looks like a > wrong environment at the place of subset evaluation (the local > variables and function paramaters are not available). Probably > lme(), ngls() and nlme() have the same inconsistency. Yes. It's the old "standard non-standard evaluation" problem. The model.frame function is (and has to be) very peculiar in the way that it determines the value of variable names without local bindings. That's the non-standard evaluation part. Because it is difficult to get this right, it helps if it only needs to be done in one place so we have what Thomas Lumley described as a "standard non-standard evaluation" function in the current model.frame function. However, model.frame expects to have only one argument called "formula" (the first argument) containing a formula that will need to be evaluated in the frame. The model fitting functions in the nlme package can have formulas in multiple arguments. Arranging for the proper call to model.frame to be evaluated is not easy. A workaround is to use subset on the data frame passed as an argument prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t ,subset(pr,subject==name))} -- Douglas Bates bates@stat.wisc.edu Statistics Department 608/262-2598 University of Wisconsin - Madison http://www.stat.wisc.edu/~bates/ ==> 4757.audit <== Sat Nov 1 07:51:00 2003 ripley changed notes Sat Nov 1 07:51:00 2003 ripley foobar Sat Nov 1 07:51:00 2003 ripley moved from incoming to Analyses ==> 4757.followup.1 <== From gregory_r_warnes@groton.pfizer.com Wed Nov 5 15:56:13 2003 Received: from mail2-haw-R.bigfish.com (mail-haw.bigfish.com [12.129.199.61]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id hA5EuC0P008558 for ; Wed, 5 Nov 2003 15:56:13 +0100 (MET) Received: from mail2-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-haw-R.bigfish.com (Postfix) with ESMTP id 02FD8234CB9 for ; Wed, 5 Nov 2003 14:56:07 +0000 (UCT) Received: by mail2-haw (MessageSwitch) id 1068044166947634_30642; Wed, 5 Nov 2003 14:56:06 +0000 (UCT) Received: from gsun56.pfizer.com (unknown [12.18.36.49]) by mail2-haw.bigfish.com (Postfix) with ESMTP id 0268A22D730 for ; Wed, 5 Nov 2003 14:55:21 +0000 (UCT) Received: from groexms01.pfizer.com (localhost [127.0.0.1]) by gsun56.pfizer.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id hA5EtJBs025671 for ; Wed, 5 Nov 2003 09:55:20 -0500 (EST) Received: from groexcn04.pfizer.com (unverified) by groexms01.pfizer.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 5 Nov 2003 09:55:15 -0500 Received: by groexcn04.pfizer.com with Internet Mail Service (5.5.2654.89) id ; Wed, 5 Nov 2003 09:55:15 -0500 Message-ID: From: "Warnes, Gregory R" To: "'Douglas Bates'" , wb@arb-phys.uni-dortmund.de Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch Subject: RE: [Rd] NLME: gls parameter evaluation inconsistency (PR#4757) Date: Wed, 5 Nov 2003 09:55:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-BigFish: cv > -----Original Message----- > From: Douglas Bates [mailto:bates@stat.wisc.edu] > Sent: Friday, October 24, 2003 12:16 PM [...] > Yes. It's the old "standard non-standard evaluation" problem. The > model.frame function is (and has to be) very peculiar in the way > that it determines the value of variable names without local > bindings. That's the non-standard evaluation part. Because it is > difficult to get this right, it helps if it only needs to be done in > one place so we have what Thomas Lumley described as a "standard > non-standard evaluation" function in the current model.frame function. > > However, model.frame expects to have only one argument called > "formula" (the first argument) containing a formula that will need to > be evaluated in the frame. The model fitting functions in the nlme > package can have formulas in multiple arguments. Arranging for the > proper call to model.frame to be evaluated is not easy. > > A workaround is to use subset on the data frame passed as an argument > > prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t > ,subset(pr,subject==name))} Why don't we extend model.frame to allow for multiple 'formula-like' arguments? Perhaps by adding an argument that allows the call to specify which paramters are 'formula-like'? -G LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5360 * Subject: ks.test From: pbtud@yahoo.com Date: Thu, 27 Nov 2003 18:43:23 +0100 (CET) --Documentation issue ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5360 <== From pbtud@yahoo.com Thu Nov 27 18:43:24 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id DD25BEDF1 for ; Thu, 27 Nov 2003 18:43:23 +0100 (CET) From: pbtud@yahoo.com To: R-bugs@biostat.ku.dk Subject: ks.test Message-Id: <20031127174323.DD25BEDF1@slim.kubism.ku.dk> Date: Thu, 27 Nov 2003 18:43:23 +0100 (CET) Full_Name: Pieter Ober Version: 1.8 OS: win 2000 Submission from: (NULL) (62.166.32.225) In ks.test, the names of the test statistics that are returned (D^-) and (D^+) seem to correspond to the test statistics (T+) and (T-) in the Conover reference (I use the 2d edition of the book) and are thus reversed - this is slightly confusing! ==> 5360.audit <== Mon Dec 8 13:59:06 2003 ripley changed notes Mon Dec 8 13:59:06 2003 ripley foobar Mon Dec 8 13:59:06 2003 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5461 * Subject: xtabs or model.frame From: Rich Heiberger From: "Francis Hsuan" Add To Address Book Date: Tue, 2 Dec 2003 01:20:08 -0500 (EST) Date: Mon, 1 Dec 2003 21:53:06 -0500 --model.frame() fails on character input: should it coerce to factor? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5461 <== From mailnull@stat.math.ethz.ch Tue Dec 2 07:22:12 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id 149CCED8F for ; Tue, 2 Dec 2003 07:22:12 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hB26KYCg025845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2003 07:20:34 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id hB26KXJM025844 for R-bugs@biostat.ku.dk; Tue, 2 Dec 2003 07:20:33 +0100 (MET) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hB26KOCf025822 for ; Tue, 2 Dec 2003 07:20:25 +0100 (MET) Received: from www.fox.temple.edu ([155.247.186.2] helo=surfer.sbm.temple.edu) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 1AR3v6-0004u8-00 for ; Tue, 02 Dec 2003 00:22:00 -0600 Received: (from rmh@localhost) by surfer.sbm.temple.edu (8.12.8p1/8.12.8) id hB26K8dO4480942; Tue, 2 Dec 2003 01:20:08 -0500 (EST) Date: Tue, 2 Dec 2003 01:20:08 -0500 (EST) From: Rich Heiberger Message-Id: <200312020620.hB26K8dO4480942@surfer.sbm.temple.edu> To: r-bugs@r-project.org Subject: xtabs or model.frame Cc: francis.hsuan@temple.edu, rmh@surfer.sbm.temple.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hypatia.math.ethz.ch X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Level: # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### Here is the bug report I got from Professor Hsuan, and my exploration of it. The cause of the problem is that a character vector is not coerced to factor by xtabs or model.frame. Is it a bug? I think yes. Character vectors are so frequently coerced to factor that it is reasonable to assume that it will happen here. The documentation is ambiguous as ?xtabs says formula: a formula object with the cross-classifying variables, separated by `+', on the right hand side. Interactions are not allowed. It says "variables", not "factors", implying to us that the coercion to factor will take place. Rich ###################### Date: Mon, 1 Dec 2003 21:53:06 -0500 From: "Francis Hsuan" Add To Address Book To: Cc: "Francis Hsuan" Rich, I got some strange output from R. Does this indicate a bug in the xtabs() function? Thanks, Francis > rm(list=ls(all=TRUE)) > Freq <- c(9, 2, 5, 4, 16, 26, 10, 28) > H <- rep(c("yes", " no"), each=4) > S <- rep(rep(c("yes", " no"), each=2), 2) > A <- rep(c("yes", " no"), 4) > xtabs(Freq~H+S+A) Error in model.frame(formula, rownames, variables, varnames, extras, extranames, : invalid variable type > Data3 <- data.frame(H, S, A, Freq) > xtabs(Freq~H+S+A, Data3) , , A = no S H no yes no 28 26 yes 4 2 , , A = yes S H no yes no 10 16 yes 5 9 ###################### The bug is generated in model.frame.default by the line data <- .Internal(model.frame(formula, rownames, variables, varnames, extras, extranames, subset, na.action)) #### ## Here is one repair > H <- factor(H) > S <- factor(S) > A <- factor(A) > xtabs(Freq~H+S+A) , , A = no S H no yes no 28 26 yes 4 2 , , A = yes S H no yes no 10 16 yes 5 9 > ## Here is another way to generate the error > class(Data3$H) [1] "factor" > Data3$H <- H > class(Data3$H) [1] "character" > xtabs(Freq~H+S+A, Data3) Error in model.frame(formula, rownames, variables, varnames, extras, extranames, : invalid variable type > #### --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 7.1 year = 2003 month = 06 day = 16 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, file:c:/HOME/rmh/hh/splus.library/.RData, package:grid, package:lattice, Autoloads, package:base ==> 5461.audit <== Mon Dec 8 14:00:09 2003 ripley foobar Mon Dec 8 14:00:09 2003 ripley moved from incoming to Analyses Tue Mar 23 03:47:14 2004 thomas changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6750 * Subject: Incorrect handling of NA's in cor() From: msa@biostat.mgh.harvard.edu Date: Fri, 9 Apr 2004 18:45:40 +0200 (CEST) --matter of debate ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6750 <== From msa@biostat.mgh.harvard.edu Fri Apr 9 18:45:46 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id DADA01046B for ; Fri, 9 Apr 2004 18:45:40 +0200 (CEST) From: msa@biostat.mgh.harvard.edu To: R-bugs@biostat.ku.dk Subject: Incorrect handling of NA's in cor() Message-Id: <20040409164540.DADA01046B@slim.kubism.ku.dk> Date: Fri, 9 Apr 2004 18:45:40 +0200 (CEST) X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Marek Ancukiewicz Version: 1.8.1 OS: Linux Submission from: (NULL) (132.183.12.87) Function cor() incorrectly handles missing observation with method="spearman": > x <- c(1,2,3,NA,5,6) > y <- c(4,NA,2,5,1,3) > cor(x,y,use="complete.obs",method="s") [1] -0.1428571 > cor(x[!is.na(x)&!is.na(y)],y[!is.na(x)&!is.na(y)],method="s") [1] -0.4 These two results should be the same. ==> 6750.followup.1 <== From ligges@amadeus.statistik.uni-dortmund.de Fri Apr 9 19:06:36 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 124B3FB9A for ; Fri, 9 Apr 2004 19:06:36 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22369-04 for ; Fri, 9 Apr 2004 19:06:35 +0200 (CEST) Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 19:06:35 +0200 (CEST) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id D9BB81B734; Fri, 9 Apr 2004 19:06:34 +0200 (MET DST) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id i39H6Y505443; Fri, 9 Apr 2004 19:06:34 +0200 (MET DST) Message-ID: <4076D827.9070201@statistik.uni-dortmund.de> Date: Fri, 09 Apr 2004 19:06:47 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: msa@biostat.mgh.harvard.edu Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409164614.9E0AD10478@slim.kubism.ku.dk> In-Reply-To: <20040409164614.9E0AD10478@slim.kubism.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) msa@biostat.mgh.harvard.edu wrote: > Full_Name: Marek Ancukiewicz > Version: 1.8.1 > OS: Linux > Submission from: (NULL) (132.183.12.87) > > > Function cor() incorrectly handles missing observation with method="spearman": > > >>x <- c(1,2,3,NA,5,6) >>y <- c(4,NA,2,5,1,3) >>cor(x,y,use="complete.obs",method="s") > > [1] -0.1428571 > >>cor(x[!is.na(x)&!is.na(y)],y[!is.na(x)&!is.na(y)],method="s") > > [1] -0.4 > > These two results should be the same. > No! Please read at least the help file, ?cor, before submitting a bug report: "If use is "complete.obs" then missing values are handled by casewise deletion. Finally, if use has the value "pairwise.complete.obs" then the correlation between each pair of variables is computed using all complete pairs of observations on those variables." Hence cor(x, y, use="pairwise.complete.obs", method="s") is what you expect ... Uwe Ligges ==> 6750.followup.2 <== From msa@biostat.mgh.harvard.edu Fri Apr 9 19:22:07 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 410F7FB9A for ; Fri, 9 Apr 2004 19:22:07 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22463-06 for ; Fri, 9 Apr 2004 19:22:06 +0200 (CEST) Received: from biostat.mgh.harvard.edu (biostat.mgh.harvard.edu [132.183.12.110]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 19:22:06 +0200 (CEST) Received: by biostat.mgh.harvard.edu (Postfix, from userid 500) id 673F35E197; Fri, 9 Apr 2004 13:22:05 -0400 (EDT) From: Marek Ancukiewicz To: ligges@statistik.uni-dortmund.de Cc: R-bugs@biostat.ku.dk In-reply-to: <4076D827.9070201@statistik.uni-dortmund.de> (message from Uwe Ligges on Fri, 09 Apr 2004 19:06:47 +0200) Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409164614.9E0AD10478@slim.kubism.ku.dk> <4076D827.9070201@statistik.uni-dortmund.de> Message-Id: <20040409172205.673F35E197@biostat.mgh.harvard.edu> Date: Fri, 9 Apr 2004 13:22:05 -0400 (EDT) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Dear Uwe, You are wrong. First, I've read the help file before submitting the report. For two variables, use="pairwise.complete.obs" and use="complete.obs" should be equivalent, shouldn't it? Of sourse, the results will be different when we have more than 2 variables. Second, with the call you proposed I am also getting incorrect result: > cor(x, y, use="pairwise.complete.obs", method="s") [1] -0.1428571 The correct result is -0.4, as correctly calculated by cor.test() Regards Marek Ancukiewicz > X-Original-To: msa@biostat.mgh.harvard.edu > Date: Fri, 09 Apr 2004 19:06:47 +0200 > From: Uwe Ligges > Organization: Fachbereich Statistik, Universitaet Dortmund > X-Accept-Language: en-us, en, de-de, de > Cc: R-bugs@biostat.ku.dk > > msa@biostat.mgh.harvard.edu wrote: > > Full_Name: Marek Ancukiewicz > > Version: 1.8.1 > > OS: Linux > > Submission from: (NULL) (132.183.12.87) > > > > > > Function cor() incorrectly handles missing observation with method="spearman": > > > > > >>x <- c(1,2,3,NA,5,6) > >>y <- c(4,NA,2,5,1,3) > >>cor(x,y,use="complete.obs",method="s") > > > > [1] -0.1428571 > > > >>cor(x[!is.na(x)&!is.na(y)],y[!is.na(x)&!is.na(y)],method="s") > > > > [1] -0.4 > > > > These two results should be the same. > > > > > No! Please read at least the help file, ?cor, before submitting a bug > report: > > > "If use is "complete.obs" then missing values are handled by casewise > deletion. Finally, if use has the value "pairwise.complete.obs" then the > correlation between each pair of variables is computed using all > complete pairs of observations on those variables." > > > Hence > cor(x, y, use="pairwise.complete.obs", method="s") > is what you expect ... > > Uwe Ligges > ==> 6750.followup.3 <== From ligges@amadeus.statistik.uni-dortmund.de Fri Apr 9 19:34:55 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 86C14FB9A for ; Fri, 9 Apr 2004 19:34:55 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22463-10 for ; Fri, 9 Apr 2004 19:34:54 +0200 (CEST) Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 19:34:54 +0200 (CEST) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 48F8C1B75E; Fri, 9 Apr 2004 19:34:54 +0200 (MET DST) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id i39HYs505847; Fri, 9 Apr 2004 19:34:54 +0200 (MET DST) Message-ID: <4076DECB.9020207@statistik.uni-dortmund.de> Date: Fri, 09 Apr 2004 19:35:07 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: Marek Ancukiewicz Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409164614.9E0AD10478@slim.kubism.ku.dk> <4076D827.9070201@statistik.uni-dortmund.de> <20040409172205.673F35E197@biostat.mgh.harvard.edu> In-Reply-To: <20040409172205.673F35E197@biostat.mgh.harvard.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Marek Ancukiewicz wrote: > Dear Uwe, > > You are wrong. Whoops. My apologies!!! In R-1.9.0 beta I get: cor(x[!is.na(x)&!is.na(y)],y[!is.na(x)&!is.na(y)],method="s") # [1] -0.4 cor(x,y,use="complete.obs", method="s") # [1] -0.5291503 I'll take a look! Uwe > First, I've read the help file before > submitting the report. For two variables, > use="pairwise.complete.obs" and use="complete.obs" should be > equivalent, shouldn't it? Of sourse, the results will be > different when we have more than 2 variables. Second, with the > call you proposed I am also getting incorrect result: > > >>cor(x, y, use="pairwise.complete.obs", method="s") > > [1] -0.1428571 > > The correct result is -0.4, as correctly calculated by > cor.test() > > Regards > > Marek Ancukiewicz > > > > >>X-Original-To: msa@biostat.mgh.harvard.edu >>Date: Fri, 09 Apr 2004 19:06:47 +0200 >>From: Uwe Ligges >>Organization: Fachbereich Statistik, Universitaet Dortmund >>X-Accept-Language: en-us, en, de-de, de >>Cc: R-bugs@biostat.ku.dk >> >>msa@biostat.mgh.harvard.edu wrote: >> >>>Full_Name: Marek Ancukiewicz >>>Version: 1.8.1 >>>OS: Linux >>>Submission from: (NULL) (132.183.12.87) >>> >>> >>>Function cor() incorrectly handles missing observation with method="spearman": >>> >>> >>> >>>>x <- c(1,2,3,NA,5,6) >>>>y <- c(4,NA,2,5,1,3) >>>>cor(x,y,use="complete.obs",method="s") >>> >>>[1] -0.1428571 >>> >>> >>>>cor(x[!is.na(x)&!is.na(y)],y[!is.na(x)&!is.na(y)],method="s") >>> >>>[1] -0.4 >>> >>>These two results should be the same. >>> >> >> >>No! Please read at least the help file, ?cor, before submitting a bug >>report: >> >> >>"If use is "complete.obs" then missing values are handled by casewise >>deletion. Finally, if use has the value "pairwise.complete.obs" then the >>correlation between each pair of variables is computed using all >>complete pairs of observations on those variables." >> >> >>Hence >> cor(x, y, use="pairwise.complete.obs", method="s") >>is what you expect ... >> >>Uwe Ligges >> ==> 6750.followup.4 <== From tlumley@u.washington.edu Fri Apr 9 19:43:05 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id B96A4FB9A for ; Fri, 9 Apr 2004 19:43:05 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22559-03 for ; Fri, 9 Apr 2004 19:43:04 +0200 (CEST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 19:43:03 +0200 (CEST) Received: from homer32.u.washington.edu (homer32.u.washington.edu [140.142.8.42]) by mxout1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i39Hh0Ya012013; Fri, 9 Apr 2004 10:43:01 -0700 Received: from localhost (tlumley@localhost) by homer32.u.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i39Hh0mJ027868; Fri, 9 Apr 2004 10:43:00 -0700 Date: Fri, 9 Apr 2004 10:42:59 -0700 (PDT) From: Thomas Lumley To: msa@biostat.mgh.harvard.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) In-Reply-To: <20040409172243.B026310476@slim.kubism.ku.dk> Message-ID: References: <20040409172243.B026310476@slim.kubism.ku.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Fri, 9 Apr 2004 msa@biostat.mgh.harvard.edu wrote: > > Dear Uwe, > > You are wrong. First, I've read the help file before > submitting the report. For two variables, > use="pairwise.complete.obs" and use="complete.obs" should be > equivalent, shouldn't it? Of sourse, the results will be > different when we have more than 2 variables. Second, with the > call you proposed I am also getting incorrect result: > I think it's more complicated than either of you are considering. For the Pearson correlation everything is straightforward, and pairwise.complete is the same as complete, which is the same as dropping the NAs manually. For the rank correlations the question is when the ranking should be done. The cor() function ranks the observations and then drops missing values, the manual approach drops missing values and then ranks. I'm not convinced that it is obvious which of these is right, though certainly the help page should document whichever is being done. -thomas ==> 6750.followup.5 <== From msa@biostat.mgh.harvard.edu Fri Apr 9 20:08:19 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 364061046B for ; Fri, 9 Apr 2004 20:08:19 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22609-09 for ; Fri, 9 Apr 2004 20:08:18 +0200 (CEST) Received: from biostat.mgh.harvard.edu (biostat.mgh.harvard.edu [132.183.12.110]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 20:08:18 +0200 (CEST) Received: by biostat.mgh.harvard.edu (Postfix, from userid 500) id D6C275E197; Fri, 9 Apr 2004 14:08:17 -0400 (EDT) From: Marek Ancukiewicz To: tlumley@u.washington.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk In-reply-to: (message from Thomas Lumley on Fri, 9 Apr 2004 10:42:59 -0700 (PDT)) Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409172243.B026310476@slim.kubism.ku.dk> Message-Id: <20040409180817.D6C275E197@biostat.mgh.harvard.edu> Date: Fri, 9 Apr 2004 14:08:17 -0400 (EDT) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REMOVE_IN_QUOTES,REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Dear Thomas, The question becomes: how do we rank missing values? In version 1.8.1 at least, cor () uses default handling of missing values by rank() [by na.last parameter], that is missing values are assigned the highest rank. However, if nothing is known about the meaning of NA what would be the basis of such an assumption? Assigning the NAs highest, lowest values, or any other values requires some additional information. It seems that the default handling on missing values should be to assign them missing ranks: within cor(), rank() should be called with na.last="keep". However, cor() could have an additional parameter, such as na.rank which would allow to account for known ranking of missing values, and which would be passed to rank() By the way, if this were possible [and probably it isn't because of compatibility with Splus] I would change, in rank() the naming of "na.last" parameter to "na.rank" with values such as "last", "first","remove", and "na". That would seem easier to remember. Also, perhaps the default value should be "na". Regards, Marek > X-Original-To: msa@biostat.mgh.harvard.edu > Date: Fri, 9 Apr 2004 10:42:59 -0700 (PDT) > From: Thomas Lumley > Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk > > On Fri, 9 Apr 2004 msa@biostat.mgh.harvard.edu wrote: > > > > > Dear Uwe, > > > > You are wrong. First, I've read the help file before > > submitting the report. For two variables, > > use="pairwise.complete.obs" and use="complete.obs" should be > > equivalent, shouldn't it? Of sourse, the results will be > > different when we have more than 2 variables. Second, with the > > call you proposed I am also getting incorrect result: > > > > I think it's more complicated than either of you are considering. > > For the Pearson correlation everything is straightforward, and > pairwise.complete is the same as complete, which is the same as dropping > the NAs manually. > > For the rank correlations the question is when the ranking should be done. > The cor() function ranks the observations and then drops missing values, > the manual approach drops missing values and then ranks. > > I'm not convinced that it is obvious which of these is right, though > certainly the help page should document whichever is being done. > > > -thomas > ==> 6750.followup.6 <== From tlumley@u.washington.edu Fri Apr 9 20:21:52 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 22F131046B for ; Fri, 9 Apr 2004 20:21:52 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22711-02 for ; Fri, 9 Apr 2004 20:21:51 +0200 (CEST) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 20:21:50 +0200 (CEST) Received: from homer32.u.washington.edu (homer32.u.washington.edu [140.142.8.42]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i39ILmZs000432; Fri, 9 Apr 2004 11:21:48 -0700 Received: from localhost (tlumley@localhost) by homer32.u.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i39ILl8v048044; Fri, 9 Apr 2004 11:21:47 -0700 Date: Fri, 9 Apr 2004 11:21:47 -0700 (PDT) From: Thomas Lumley To: Marek Ancukiewicz Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) In-Reply-To: <20040409180817.D6C275E197@biostat.mgh.harvard.edu> Message-ID: References: <20040409172243.B026310476@slim.kubism.ku.dk> <20040409180817.D6C275E197@biostat.mgh.harvard.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Fri, 9 Apr 2004, Marek Ancukiewicz wrote: > > Dear Thomas, > > The question becomes: how do we rank missing values? That's one of the questions. It's not the only question. Suppose x has no missing values but y has a missing value. Should the ranks for x be based on the whole vector or just on the values where y isn't missing? -thomas ==> 6750.reply.1 <== From p.dalgaard@biostat.ku.dk Fri Apr 9 20:39:59 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id B711E1046B; Fri, 9 Apr 2004 20:39:59 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i39IbOYg026350; Fri, 9 Apr 2004 20:37:24 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i39IbNBY026346; Fri, 9 Apr 2004 20:37:23 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: Marek Ancukiewicz Cc: tlumley@u.washington.edu, R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409172243.B026310476@slim.kubism.ku.dk> <20040409180817.D6C275E197@biostat.mgh.harvard.edu> From: Peter Dalgaard Date: 09 Apr 2004 20:37:23 +0200 In-Reply-To: <20040409180817.D6C275E197@biostat.mgh.harvard.edu> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Marek Ancukiewicz writes: > Dear Thomas, > > The question becomes: how do we rank missing values? In > version 1.8.1 at least, cor () uses default handling of > missing values by rank() [by na.last parameter], that is > missing values are assigned the highest rank. However, if > nothing is known about the meaning of NA what would be the > basis of such an assumption? Assigning the NAs highest, > lowest values, or any other values requires some additional > information. > > It seems that the default handling on missing values should be > to assign them missing ranks: within cor(), rank() should be > called with na.last="keep". Yes, and that is what 1.9.0beta is doing (it's not like this issue hasn't been brought up before, just that the fix didn't quite fix it). I think what we have now is still buggy, but at least it isn't biasing rho towards +1 whenever x and y tend to be both missing at the same time. It's fairly easy to do something more sensible in the complete.cases case, but getting pairwise.complete.cases right is tricky. 1.9.0 is in deep code freeze, so I don't think we should change things at this point, except perhaps add a note to the help page. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6750.followup.7 <== From msa@biostat.mgh.harvard.edu Fri Apr 9 21:49:41 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 2EEB71046F for ; Fri, 9 Apr 2004 21:49:41 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23067-02 for ; Fri, 9 Apr 2004 21:49:40 +0200 (CEST) Received: from biostat.mgh.harvard.edu (biostat.mgh.harvard.edu [132.183.12.110]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Apr 2004 21:49:40 +0200 (CEST) Received: by biostat.mgh.harvard.edu (Postfix, from userid 500) id B7B385E197; Fri, 9 Apr 2004 15:49:39 -0400 (EDT) From: Marek Ancukiewicz To: tlumley@u.washington.edu Cc: R-bugs@biostat.ku.dk In-reply-to: (message from Thomas Lumley on Fri, 9 Apr 2004 11:21:47 -0700 (PDT)) Subject: Re: [Rd] Incorrect handling of NA's in cor() (PR#6750) References: <20040409172243.B026310476@slim.kubism.ku.dk> <20040409180817.D6C275E197@biostat.mgh.harvard.edu> Message-Id: <20040409194939.B7B385E197@biostat.mgh.harvard.edu> Date: Fri, 9 Apr 2004 15:49:39 -0400 (EDT) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) > X-Original-To: msa@biostat.mgh.harvard.edu > Date: Fri, 9 Apr 2004 11:21:47 -0700 (PDT) > From: Thomas Lumley > Cc: R-bugs@biostat.ku.dk > > On Fri, 9 Apr 2004, Marek Ancukiewicz wrote: > > > > > Dear Thomas, > > > > The question becomes: how do we rank missing values? > > That's one of the questions. It's not the only question. Suppose x has > no missing values but y has a missing value. Should the ranks for x be > based on the whole vector or just on the values where y isn't missing? > > -thomas I see what you mean. One could give an argument in favour of each of these approaches. If we treat data primarily as pairs of values (or more generally, cases) then we should discard incomplete pairs (records) first and rank afterwards. If we consider x and y primarily as separate from each other (especially with regard to how the missing values arise) then a more natural approach would be to do ranking before dropping incomplete pairs. In the later approach we use more information in the data; in the former approach we ignore the information which might be spurious, especially when missing y values tend to coincide with high (low) x values. Dropping NAs first and ranking later seems to be a conservative approach; with the other approach on should probably always check if NAs in one variable are correlated with other variables. My understanding is that cor() in 1.9.0 will do ranking independently, before dropping missing pairs/cases. It would be good to have this documented in help(), it might be also good to add a warning on perils of the analysis with missing values when occurrences of NAs in one variable are correlated with other variables. Marek ==> 6750.audit <== Sat May 1 21:55:26 2004 ripley changed notes Sat May 1 21:55:26 2004 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6986 * Subject: Bug in FEXACT: gave negative key From: Francis Clark Date: Thu, 17 Jun 2004 20:00:31 +1000 (EST) --From fisher.test! --Probably just a poor error message ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6986 <== From fc@maths.uq.edu.au Thu Jun 17 12:00:46 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id E622510555 for ; Thu, 17 Jun 2004 12:00:45 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26410-09 for ; Thu, 17 Jun 2004 12:00:44 +0200 (CEST) Received: from mailhub2.uq.edu.au (mailhub2.uq.edu.au [130.102.149.128]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Thu, 17 Jun 2004 12:00:42 +0200 (CEST) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub2.uq.edu.au (8.12.11/8.12.11) with ESMTP id i5HA0ZVa045661; Thu, 17 Jun 2004 20:00:35 +1000 (EST) Received: from aristotle.maths.uq.edu.au (aristotle.maths.uq.edu.au [130.102.160.1]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id i5HA0Ym6019238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jun 2004 20:00:35 +1000 (EST) Received: from socrates.maths.uq.edu.au (socrates.maths.uq.edu.au [130.102.160.47]) by aristotle.maths.uq.edu.au (8.12.8/8.12.8) with ESMTP id i5HA0VPE025095; Thu, 17 Jun 2004 20:00:32 +1000 Date: Thu, 17 Jun 2004 20:00:31 +1000 (EST) From: Francis Clark To: r-bugs@biostat.ku.dk Cc: fc@ebi.ac.uk Subject: Bug in FEXACT: gave negative key Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-By: SpamAssassin 2.55 http://spamassassin.org X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello, I'm using R to apply Fishers exact test to a whole pile of contingency tables, and I've run into the bug shown below. regards, Francis -- > dat1 = matrix(c(0,1,0,1,0,0,1,0,0,0,1,0,1,0,0,1,0,0,0,1,0,1,0,0,1,0,0,0,0, 1,1,0,0,1,0,0,1,0,0,1,0,0,3,0,0,2,0,0,1,0,0,0,1,0,0,2,0,0, 2,0,0,1,0,1,0,0,3,0,0,2,0,0,0,1,0,5,0,0,0,1,0,1,0,0), nrow=3) > fisher.test( dat1 ) Error in fisher.test(dat1) : Bug in FEXACT: gave negative key ==> 6986.reply.1 <== From p.dalgaard@biostat.ku.dk Thu Jun 17 12:33:08 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 16D341057B; Thu, 17 Jun 2004 12:33:08 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i5HAPcYg002189; Thu, 17 Jun 2004 12:25:38 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i5HAPbUS002185; Thu, 17 Jun 2004 12:25:37 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: fc@maths.uq.edu.au Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Bug in FEXACT: gave negative key (PR#6986) References: <20040617100047.B13DB1057B@slim.kubism.ku.dk> From: Peter Dalgaard Date: 17 Jun 2004 12:25:36 +0200 In-Reply-To: <20040617100047.B13DB1057B@slim.kubism.ku.dk> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) fc@maths.uq.edu.au writes: > Hello, > > I'm using R to apply Fishers exact test to a whole pile of > contingency tables, and I've run into the bug shown below. > > regards, > > Francis > > -- > > > dat1 = matrix(c(0,1,0,1,0,0,1,0,0,0,1,0,1,0,0,1,0,0,0,1,0,1,0,0,1,0,0,0,0, > 1,1,0,0,1,0,0,1,0,0,1,0,0,3,0,0,2,0,0,1,0,0,0,1,0,0,2,0,0, > 2,0,0,1,0,1,0,0,3,0,0,2,0,0,0,1,0,5,0,0,0,1,0,1,0,0), nrow=3) > > > fisher.test( dat1 ) > > Error in fisher.test(dat1) : Bug in FEXACT: gave negative key I suppose it counts as a bug when FEXACT says so. However it is most likely caused by integer overrun, and so really a code for "problem too large". I.e. we can probably fix the error message, put not get fisher.test to do the problem. Consider instead > chisq.test(dat1,sim=T,B=50000) Pearson's Chi-squared test with simulated p-value (based on 50000 replicates) data: dat1 X-squared = 80, df = NA, p-value = 2e-05 BTW, a line with "-- " at the start means beginning of signature, and mail readers may do funny things with the subsequent text. Mine just puts it in italics, but others might elect to discard the signature completely or chop it to four lines, etc. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6986.audit <== Fri Jun 18 14:26:03 2004 ripley changed notes Fri Jun 18 14:26:03 2004 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7037 * Subject: R crashes From: cornulier@cebc.cnrs.fr Date: Wed, 30 Jun 2004 22:06:27 +0200 (CEST) --crash in cor, reproducible on Linux ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7037 <== From cornulier@cebc.cnrs.fr Wed Jun 30 22:06:28 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id ADBD210941 for ; Wed, 30 Jun 2004 22:06:27 +0200 (CEST) From: cornulier@cebc.cnrs.fr To: R-bugs@biostat.ku.dk Subject: R crashes Message-Id: <20040630200627.ADBD210941@slim.kubism.ku.dk> Date: Wed, 30 Jun 2004 22:06:27 +0200 (CEST) X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_10,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: thomas cornulier Version: 1.9.0 and 1.9.1 OS: Win XP Submission from: (NULL) (194.254.155.62) the following function produces R crashes under windows XP platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 1 minor 9.1 year 2004 month 06 day 21 language R start code----- ts.cor<- function(Variable, Xcoord, Ycoord, Year){ ts<- tapply(Variable, list(Year, paste(Xcoord, Ycoord)), mean) for(j in 1:500) { samp<- sample(seq(ncol(ts)), replace= T) cor.ts.boot<- cor(ts[, samp], use= "p", method= "spearman") cor.ts.boot<- cor.ts.boot[lower.tri(cor.ts.boot)] } } V<- rpois(180, 0.05) X<- rep.int(runif(20), 9) Y<- rep.int(runif(20), 9) Yr<- rep(1:9, each= 20) b<- ts.cor(V, X, Y, Yr) end code------ use= "c" or use= "a" in cor() cause systematic crash, whereas use= "p" produces crashes or inconsistent error messages: Error in cor.ts.boot[lower.tri(cor.ts.boot)] : object is not subsettable In addition: There were 50 or more warnings (use warnings() to see the first 50) Error in as.vector(x, mode) : cannot coerce to vector In addition: There were 22 warnings (use warnings() to see them) Error: invalid type/length (4/399) in vector allocation In addition: There were 50 or more warnings (use warnings() to see the first 50) Error in cor.ts.boot[lower.tri(cor.ts.boot)] : Unimplemented feature in type2str In addition: There were 50 or more warnings (use warnings() to see the first 50) Error in cor.ts.boot[lower.tri(cor.ts.boot)] : Unimplemented feature in type2str In addition: There were 22 warnings (use warnings() to see them) Behaviour similar whatever the method specification in cor(), but V has to contain many ties for the errors/crashes being produced. (problems fixed by jittering V) V<- jitter(rpois(180, 0.05), a=0.001) Crash occured at line 6 of the function when using debug() Hope I didn't miss something obvious, Thomas ==> 7037.audit <== Thu Jul 1 09:32:46 2004 ripley changed notes Thu Jul 1 09:32:46 2004 ripley moved from incoming to Analyses ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Documentation * PR# 988 * Subject: input for R-intro From: "Paul E. Johnson" Date: Mon, 18 Jun 2001 13:57:10 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 988 <== From pauljohn@ku.edu Mon Jun 18 21:03:09 2001 Received: from lark.cc.ku.edu (root@lark.cc.ku.edu [129.237.34.2]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA14694 for ; Mon, 18 Jun 2001 21:03:08 +0200 (MET DST) Received: from ku.edu by lark.cc.ku.edu (8.8.8/1.1.8.2/12Jan95-0207PM) id OAA0000024737; Mon, 18 Jun 2001 14:02:11 -0500 (CDT) Sender: pauljohn@lark.cc.ku.edu Message-ID: <3B2E4F06.F3198537@ku.edu> Date: Mon, 18 Jun 2001 13:57:10 -0500 From: "Paul E. Johnson" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs@biostat.ku.dk Subject: input for R-intro Content-Type: multipart/mixed; boundary="------------1C95DB321C5D7CBC643B8CA3" This is a multi-part message in MIME format. --------------1C95DB321C5D7CBC643B8CA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I asked Prof. Brian Ripley if I might submit some text/input for the R-intro writers, he said this is the place to do it. I was on a plane a couple of weeks ago reading R-intro as I plan for a course and made these notes, some of which I think will help my students if you incorporate them. I've attached a raw text file I wrote in Emacs to this message "Rintrochanges.txt". I have written documents like R-intro before and understand it is difficult to please everybody, and I thank you for your effort on the project. Paul Johnson Assoc. Professor Dept. of Political Science University of Kansas --------------1C95DB321C5D7CBC643B8CA3 Content-Type: text/plain; charset=us-ascii; name="Rintrochanges.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Rintrochanges.txt" R-intro comments/enhancements Part I. I think something more verbose like this would help under "Ordered and Unordered factors" Texts on research design emphasize that variables have different levels of measurement. Typically, there are three levels. If a measurement is taken with a precise scale (one on which it is meaningful to say new_value = b*old_value, as with readings of a thermometer), it is considered an "interval" level variable. Many statistical models were originally designed for interval level variables. If a measurement is not so precise, but only provides an ordered categorization of observations, such as "low" "medium" and "high", it is called an ordinal variable. If a measurement is categorical and implies no sense of ordering, such as "European", "Asian", or "South American", then it is typically called an ordinal variable. Assigning the values of "1", "2", and "3" to these observations has no substantive significance, as we might as well number them "3","2","1". Many statistical models are designed for interval level data, but with appropriate recoding of input, they can also be made to work with nominal and ordinal data. In the "old days" of statistical computing, users were forced to create a lot of indicator (or "dummy") variables, thereby converting information from nominal or ordinal measurements into variables that have only values 0 and 1. For example, to represent the information about the home continents of survey respondents, we might create two dummy variables, one for Asia (coded 1 if respondent is from Asia, 0 otherwise) and one for South America (likewise 0 and 1). A respondent for whom we find both of these dummy variables equal to 0 is sure to be from Europe, so we don't usually need to create three dummy variables. Doing so would be redundant. With a modern language like R, much of the drudgery of creating the indicator variables is handled automatically if the user declares the variables properly. In R, and S before it, the term "factor" is used to refer to a variable that is not measured at the interval level. An "unordered factor" is a nominal (or categorical) variable, while an "ordered factor" is the term for an ordinal measurement. Many statistical procedures in R have builtin procedures for handling factors. Beyond handling coding of noninterval variables, factors play a vital role in many R procedures. Procedures can be designed to do a chore for each value of a factor. Many procedures will in fact insist that a variable be designated as a factor. ------------------ In this section "Named arguments and defaults", I am left in a confusion about a few things. This confusion has bothered me a while. Can you do more to explain which arguments must be specified, which are optional, and under what conditions is it necessary to include the parameter= which calling a function. 1. When I use a function, and I look in its help page, how do I know which input variables must be declared and which can be ignored? This is quite mysterious. When invocations leave out some arguments, how does R "sift through" the ones that are provided to know which is which? For example, consider the page on "update.packages". Under Usage, I find: update.packages(lib.loc = .lib.loc, CRAN = getOption("CRAN"), contriburl = contrib.url(CRAN), method = "auto", instlib = NULL, ask=TRUE, available=NULL, destdir=NULL) I've been using computers a long time, and I use this function every two months or so. Between times I forget, come back to this page, and still this one leaves me totally confused. After fiddling a while, I find this works on Linux: >update.packages(lib="/usr/lib/R/library",CRAN="http://lib.stat.cmu.edu/R/CRAN") but what bothered me thd most is the "getOption("CRAN") option for CRAN. I tried many variations on that and never figured how to make it work. Maybe any clarifications could be related to the section "Getting help with functions and features" In this section, I think it would be nice to have a paragraph about "how to read a help page." Some things are not obvious to all new users. Some things in help pages are tough to describe... Maybe I'd say How to read a help page. If you find a help page, notice that it is made up of different parts. 1. "Description". These are usually terse, so read every word carefully. 2. Look for the "Value" heading. That tells you what this procedure is going to return when you call it. If this procedure doesn't return what you need, you should find out immediately. 3. Under "Usage", most help pages list a number of possible commands that can be used. These are not commands to be typed literally. Many of them contain abstract references which provide information about the nature of the variables that might be entered. Here is a simple case. The coefficients help page has this: Usage coef(object, ...) coefficients(object, ...) Clearly, coef and coefficients are going to do the same thing, and you must supply the appropriate object. 4. Under "Arguments," the help page indicates what inputs this procedure wants. The inputs are described line-by-line, and often the comments indicate of parameters are optional or what their default value might be. Many help pages have the infamous "...", which is something like "fill in the appropriately, depending on whatever context you find." In some situations this is easy to understand . Many help pages will eplicitly say that "..." refers to any options that might be used with a particular kind of object, and in that case one must find the help page for that other object. For example, the dev.copy help page clearly indicates that "..." refers to any options that might be used with the particular device in question. Other help pages are not so informative. Consider the output from ?coefficients: Arguments object an object for which the extraction of model coefficients is meaningful. ... other arguments. Here it is clear you need to give a statistical object to have coefficients removed. The "..." is a mystery, and most R users will try to use the coefficients command without worrying about it, and then backtrack if an error occurs. And, if an error occurs, there may be no recourse but to read the source code for this command or ask about it in the r-help email list. --------------1C95DB321C5D7CBC643B8CA3-- ==> 988.audit <== Tue Jun 19 09:07:09 2001 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1011 * Subject: R-intro suggestions part II From: "Paul E. Johnson" Date: Tue, 03 Jul 2001 15:50:06 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1011 <== From pauljohn@ukans.edu Tue Jul 3 22:55:21 2001 Received: from lark.cc.ku.edu (root@lark.cc.ku.edu [129.237.34.2]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA25420 for ; Tue, 3 Jul 2001 22:55:20 +0200 (MET DST) Received: from ukans.edu by lark.cc.ku.edu (8.8.8/1.1.8.2/12Jan95-0207PM) id PAA0000007085; Tue, 3 Jul 2001 15:55:12 -0500 (CDT) Sender: pauljohn@lark.cc.ku.edu Message-ID: <3B422FFE.F4450D57@ukans.edu> Date: Tue, 03 Jul 2001 15:50:06 -0500 From: "Paul E. Johnson" X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs@biostat.ku.dk Subject: R-intro suggestions part II Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Ripley said that, if I sent these here, they might find their way to the R-intro team. So, here is another installment: Concerning this section: Data permanency and removing objects. This is the first place R-intro discusses objects. I was thinking a better discussion of objects and syntax is needed, perhaps here, or in the later section "Objects, their modes and attributes." I suggest this: The fact that R is an object-oriented approach to programming for statistical analysis has pervasive implications. If one has studied a programming language like Java or C++, the notions of object and method are not new. For readers who have not studied languages like that, perhaps we can offer a brief explanation. An object is a "self contained data holder" that can follow instructions (do calculations, provide values). One intention of this design is to keep things separate if they belong that way, to reduce the risk that one calculation accidentally influences the result of another. Object-orientation also has important implications for the way the different parts of a program fit together. Since an object is supposed to be able to carry out a certain set of actions (which are called methods, but in R one often says "functions" or "procedures"), then both the user and the programmer understand what the object can be expected to do. There are numerous implications of object orientation that come into play "under the hood" of the R statistical engine, but it is not important to delve into them from a user's point of view. There is one wrinkle about the syntax of R that we hasten to emphasize. In object-oriented computer languages, syntax typically puts the object first, followed by the instruction, followed any needed parameters. In Java, to tell the object "regression" to calculate estimates for vectors y and x, one would write something like: regression.estimate(y,x); Assuming that object's class has an "estimate" method which knows how to handle the input, we would be in business. In R, the syntax is totally different. Instead of thinking of the object itself as the primary thing, the syntax in R is designed to use the method name--the instruction--as the leading concept, and then the object that is being acted upon is given as a parameter. When a model gives a result in R, the result is almost invariably an object, which can then be "poked and prodded" with other methods. If a linear regression is calculated, for example: resultObject <- lm(y~x) the return value is an object. But, unlike other object-oriented languages, in R one would write summary(resultObject), or coefficients(resultObject), rather than the Java style result_object.summary() or some such thing, in order to investigate the result. Paul E. Johnson Political Science University of Kansas ==> 1011.audit <== Fri Aug 3 11:30:05 2001 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1772 * Subject: bug(?) in R FAQ - Should I run R from within Emacs? From: Tim.Harrold@csiro.au Date: Thu, 11 Jul 2002 18:21:42 +1000 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1772 <== From Tim.Harrold@csiro.au Thu Jul 11 10:22:31 2002 Received: from bastion1.vic.csiro.au (bastion1.vic.CSIRO.AU [138.194.2.8]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA17393 for ; Thu, 11 Jul 2002 10:22:29 +0200 (MET DST) From: Tim.Harrold@csiro.au Received: from bastion1.vic.csiro.au (localhost [127.0.0.1]) by bastion1.vic.csiro.au (8.11.4/8.11.4) with ESMTP id g6B8Ljv13431 for ; Thu, 11 Jul 2002 18:21:45 +1000 (EST) Received: from pcexch.dar.csiro.au (pcexch.dar.csiro.au [138.194.146.21]) by bastion1.vic.csiro.au (8.11.4/8.11.4) with ESMTP id g6B8Lit13427; Thu, 11 Jul 2002 18:21:45 +1000 (EST) Received: by pcexch.dar.csiro.au with Internet Mail Service (5.5.2653.19) id <33DQ5CHV>; Thu, 11 Jul 2002 18:21:43 +1000 Message-ID: To: r-bugs@biostat.ku.dk Cc: ripley@stats.ox.ac.uk Subject: bug(?) in R FAQ - Should I run R from within Emacs? Date: Thu, 11 Jul 2002 18:21:42 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" I have a small request re. R FAQ Frequently Asked Questions on R Version 1.5-10, 2002-06-13 ISBN 3-901167-51-X Kurt Hornik In section 6.2 Should I run R from within Emacs? The faq says "Yes, definitely." This led me to install emacs, and to install ess. However, I use a windows environment (mswindows2000) and I had some difficulty installing, linking and launching these applications. After several hours I had launched emacs but had failed to link it with either ess or r, partly because of platform problems. (As a dedicated windows user, I am reluctant to tinker with autoexec.bat and the like). I spent several hours doing this, and in hindsight, I decided to uninstall emacs and ess. I would prefer if the faq could be changed to say: "This is optional." And perhaps some comment could be made about platforms. I found the documentation for emacs and ess to be a bit of a hair-pulling exercise. NOT one of the "plug and play" applications that MS windows is so fond of! By the way, I like the r gui very much. I used splus for some time as a PhD student, and I was pleasantly surprised to find that my scripts run in r!! I intend to use r from now onwards, and to encourage my colleagues to use it too. Kind regards, Tim Harrold CSIRO Atmospheric Research 107 Station Street Aspendale Vic 3195 Phone: 03 9239 4411 Fax: 03 9239 4688 Home: 03 9571 2736 email tim.harrold@csiro.au "Give thanks to the Lord, for he is good." Psalm 106:1 ==> 1772.audit <== Wed Jul 17 09:19:26 2002 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4982 * Subject: Suggestions to the man page From: Axel Noetzold Date: Fri, 7 Nov 2003 18:18:35 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4982 <== From mailnull@stat.math.ethz.ch Fri Nov 7 18:18:59 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (localhost [127.0.0.1]) by slim.kubism.ku.dk (Postfix) with ESMTP id 2164AF437 for ; Fri, 7 Nov 2003 18:18:59 +0100 (CET) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id A7D26F42A for ; Fri, 7 Nov 2003 18:18:58 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hA7HHWPX019958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2003 18:17:32 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id hA7HHUBT019953 for R-bugs@biostat.ku.dk; Fri, 7 Nov 2003 18:17:31 +0100 (MET) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hA7HHBPW019852 for ; Fri, 7 Nov 2003 18:17:12 +0100 (MET) Received: from vscanner.rz.uni-luebeck.de ([141.83.55.77]) by franz.stat.wisc.edu with smtp (Exim 3.35 #1 (Debian)) id 1AIAFo-0001Ck-00 for ; Fri, 07 Nov 2003 11:18:36 -0600 Received: from mail.uni-luebeck.de ([141.83.200.111]) by vscanner.rz.uni-luebeck.de (SAVSMTP 3.0.0.44) with SMTP id M2003110718182000967 for ; Fri, 07 Nov 2003 18:18:20 +0100 Received: from pc12 (pc12.herzchir.mu-luebeck.de [141.83.14.152]) by mail.uni-luebeck.de (Postfix) with ESMTP id 6C2B111F705 for ; Fri, 7 Nov 2003 18:19:32 +0100 (CET) Received: from assi by pc12 with local (Exim 3.36 #1 (Debian)) id 1AIAFn-0000in-00 for ; Fri, 07 Nov 2003 18:18:35 +0100 Date: Fri, 7 Nov 2003 18:18:35 +0100 To: r-bugs@r-project.org Subject: Suggestions to the man page Message-ID: <20031107171835.GA2709@pc12.herzchir.mu-luebeck.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: Debian GNU/Linux testing/unstable (Kernel 2.4.20-686) X-GPG: 62E6373E X-GPG-FP: C04C 6886 88F5 4019 A77C CCF0 6FCA 6566 62E6 373E X-Editor: Vim-602 http://www.vim.org User-Agent: Mutt/1.5.4i From: Axel Noetzold X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hypatia.math.ethz.ch X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Level: X-Virus-Scanned: by AMaViS snapshot-20020531 #Wishlist bug I like to suggest to add a hint regarding the system and local 'Renviron' file to the man page of R. Also, a 'man Renviron' could be of value especially for a sysadmin, who is not familar with R. sincerely Axel Nötzold Version r-base 1.8.0 on Debian GNU/Linux ==> 4982.audit <== Mon Nov 10 05:28:04 2003 ripley foobar Mon Nov 10 05:28:04 2003 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5095 * Subject: documentation of "scope": possible error + cleanup From: htang@hpl.hp.com Date: Sat, 15 Nov 2003 00:00:17 +0100 (CET) --Comments on R-lang ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5095 <== From htang@hpl.hp.com Sat Nov 15 00:00:18 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id F2423ED8F for ; Sat, 15 Nov 2003 00:00:17 +0100 (CET) From: htang@hpl.hp.com To: R-bugs@biostat.ku.dk Subject: documentation of "scope": possible error + cleanup Message-Id: <20031114230017.F2423ED8F@slim.kubism.ku.dk> Date: Sat, 15 Nov 2003 00:00:17 +0100 (CET) Full_Name: Hsiu-Khuern Tang Version: 1.8.0 OS: Debian GNU/Linux unstable Submission from: (NULL) (156.153.255.243) While reading the R lang info pages, I came across the following paragraphs in the node "Scope": >> A simple example, >> >> f <- function(x) { >> y <- 10 >> g <- function(x) x + y >> return(g) >> } >> h <- f() >> h(3) >> >> A rather interesting question is what happens when `h' is evaluated . >> To describe this we need a bit more notation. Within a function body >> variables can be bound, local or unbound. The bound variables are those >> that match the formal arguments to the function. The local variables are >> those that were created or defined within the function body. The unbound >> variables are those that are neither local or bound . When a function >> body is evaluated there is no problem determining values for local >> variables or for bound variables. Scoping rules determine how the >> language will find values for the unbound variables. >> >> When `h(3)' is evaluated we see that its body is that of `g'. >> Within that body `x' and `y' are unbound. In a language with lexical >> scope `x' will be associated with the value 3 and `y' with the value 1 >> 0 >> so `h()' should return the value 13. In R this is indeed what happens >> . Possible error: it says in the last paragraph that `x' and `y' are unbound. Shouldn't it be that `x' is bound, since it is a formal argument of `h', and `y' is unbound? Also, in the previous paragraph, the portion "To describe this we need a bit more notation ... neither local or [sic] bound" should be removed, since the explanation of bound, local, and unbound variables had just been given a few paragraphs earlier. Best, Hsiu-Khuern. ==> 5095.audit <== Mon Nov 17 08:32:41 2003 ripley changed notes Mon Nov 17 08:32:41 2003 ripley foobar Mon Nov 17 08:32:41 2003 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6424 * Subject: return() undocumented From: Scot@Wilcoxon.Org Date: Sat, 10 Jan 2004 16:12:16 +0100 (CET) --He meant in R-lang ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6424 <== From Scot@Wilcoxon.Org Sat Jan 10 16:12:16 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 7D1C21040C for ; Sat, 10 Jan 2004 16:12:16 +0100 (CET) From: Scot@Wilcoxon.Org To: R-bugs@biostat.ku.dk Subject: return() undocumented Message-Id: <20040110151216.7D1C21040C@slim.kubism.ku.dk> Date: Sat, 10 Jan 2004 16:12:16 +0100 (CET) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Scot Wilcoxon Version: 1.8.1 OS: Linux Submission from: (NULL) (209.98.144.16) return() is not documented. It should also be mentioned in the R Reference section for function(). Apparently the last result of a function is the return value from a function, except when the function is terminated with a return() with an argument. ==> 6424.followup.1 <== From ligges@amadeus.statistik.uni-dortmund.de Sat Jan 10 16:31:47 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3B21510439 for ; Sat, 10 Jan 2004 16:31:43 +0100 (CET) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id A43E54ACC38; Sat, 10 Jan 2004 16:31:42 +0100 (MET) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id i0AFVg521161; Sat, 10 Jan 2004 16:31:42 +0100 (MET) Message-ID: <40001AD8.9040307@statistik.uni-dortmund.de> Date: Sat, 10 Jan 2004 16:31:36 +0100 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: Scot@wilcoxon.org Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] return() undocumented (PR#6424) References: <20040110151249.285AF10456@slim.kubism.ku.dk> In-Reply-To: <20040110151249.285AF10456@slim.kubism.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Scot@wilcoxon.org wrote: > Full_Name: Scot Wilcoxon > Version: 1.8.1 > OS: Linux > Submission from: (NULL) (209.98.144.16) > > > return() is not documented. No, it is documented: on the same help page as function()! Try ?return. > It should also be mentioned in the R Reference section for function(). > Apparently the last result of a function is the return value from a function, > except when the function is terminated with a return() with an argument. See the "Details" Section of ?return. Also, there s no "Reference" Section, but a "References" Section for citing articles and books (not help pages), and a "See Also" Section for citing help pages, but it doesn't make sense to cite the help page itself. Uwe Ligges > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel ==> 6424.reply.1 <== From mailnull@stat.math.ethz.ch Sat Jan 10 16:32:37 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id E403010439 for ; Sat, 10 Jan 2004 16:32:36 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id i0AFUZki020764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Jan 2004 16:30:35 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id i0AFUYuL020763 for R-bugs@biostat.ku.dk; Sat, 10 Jan 2004 16:30:34 +0100 (MET) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id i0AFUKki020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Jan 2004 16:30:21 +0100 (MET) Received: (from maechler@localhost) by lynne.ethz.ch (8.12.8/8.12.8/Submit) id i0AFWHbh011956; Sat, 10 Jan 2004 16:32:17 +0100 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16384.6913.576161.228940@gargle.gargle.HOWL> Date: Sat, 10 Jan 2004 16:32:17 +0100 To: Scot@wilcoxon.org Cc: R-bugs@stat.math.ethz.ch Subject: Re: [Rd] return() undocumented (PR#6424) In-Reply-To: <20040110151249.285AF10456@slim.kubism.ku.dk> References: <20040110151249.285AF10456@slim.kubism.ku.dk> X-Mailer: VM 7.17 under Emacs 21.3.2 Reply-To: Martin Maechler X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_00,IN_REP_TO,REFERENCES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >>>>> "Scot" == Scot >>>>> on Sat, 10 Jan 2004 16:12:49 +0100 (CET) writes: Scot> Full_Name: Scot Wilcoxon Version: 1.8.1 OS: Linux Scot> Submission from: (NULL) (209.98.144.16) Scot> return() is not documented. huuuh ? (see below) Scot> It should also be mentioned in the R Reference section Scot> for function(). Scot> Apparently the last result of a Scot> function is the return value from a function, except Scot> when the function is terminated with a return() with Scot> an argument. ?return does give the correct page, and the "Details" section does talk about this, right ? ==> 6424.reply.2 <== From p.dalgaard@biostat.ku.dk Sat Jan 10 16:37:21 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from turmalin.kubism.ku.dk (turmalin.kubism.ku.dk [192.38.18.18]) by slim.kubism.ku.dk (Postfix) with ESMTP id 6ACDC10439; Sat, 10 Jan 2004 16:37:21 +0100 (CET) Received: from turmalin.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by turmalin.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i0AFbc3H029373; Sat, 10 Jan 2004 16:37:38 +0100 Received: (from pd@localhost) by turmalin.kubism.ku.dk (8.12.8/8.12.8/Submit) id i0AFbcBJ029369; Sat, 10 Jan 2004 16:37:38 +0100 X-Authentication-Warning: turmalin.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: Scot@wilcoxon.org Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] return() undocumented (PR#6424) References: <20040110151249.285AF10456@slim.kubism.ku.dk> From: Peter Dalgaard Date: 10 Jan 2004 16:37:38 +0100 In-Reply-To: <20040110151249.285AF10456@slim.kubism.ku.dk> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Scot@wilcoxon.org writes: > Full_Name: Scot Wilcoxon > Version: 1.8.1 > OS: Linux > Submission from: (NULL) (209.98.144.16) > > > return() is not documented. > > It should also be mentioned in the R Reference section for function(). > Apparently the last result of a function is the return value from a function, > except when the function is terminated with a return() with an argument. Eh??? What does help(return) say on your system? Mine has Usage: function( arglist ) expr return(value) ...... If 'value' is missing, 'NULL' is returned. If it is a single expression, the value of the evaluated expression is returned. If the end of a function is reached without calling 'return', the value of the last evaluated expression is returned. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6424.followup.2 <== From Scot@Wilcoxon.Org Sat Jan 10 20:02:04 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from wilcoxon.org (wilcoxon.org [209.98.144.16]) by slim.kubism.ku.dk (Postfix) with ESMTP id 7C4B21040C; Sat, 10 Jan 2004 20:02:04 +0100 (CET) Received: from localhost.localdomain (unknown [192.168.1.164]) by wilcoxon.org (Postfix) with ESMTP id 6A5976A590; Sat, 10 Jan 2004 13:16:18 -0600 (CST) Subject: Re: [Rd] return() undocumented (PR#6424) From: Scot Wilcoxon To: Peter Dalgaard Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk In-Reply-To: References: <20040110151249.285AF10456@slim.kubism.ku.dk> Content-Type: text/plain Message-Id: <1073760948.31351.1108.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Jan 2004 12:55:48 -0600 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Sat, 2004-01-10 at 09:37, Peter Dalgaard wrote: > Scot@wilcoxon.org writes: > > > Full_Name: Scot Wilcoxon > > Version: 1.8.1 > > OS: Linux > > Submission from: (NULL) (209.98.144.16) > > > > > > return() is not documented. > > > > It should also be mentioned in the R Reference section for function(). > > Apparently the last result of a function is the return value from a function, > > except when the function is terminated with a return() with an argument. > > Eh??? What does help(return) say on your system? Mine has > > Usage: > > function( arglist ) expr > return(value) > ...... > If 'value' is missing, 'NULL' is returned. If it is a single > expression, the value of the evaluated expression is returned. > > If the end of a function is reached without calling 'return', the > value of the last evaluated expression is returned. > Oh. It didn't occur to me to ask help(), which I could have because I know what I need. I was looking at the R Language Definition (draft). Excuse me for a moment. A moment which you won't notice, as I must build a time machine and change my bug report to "not documented in the R Language Definition (draft)". ==> 6424.audit <== Sun Jan 11 09:27:37 2004 ripley changed notes Mon Jan 12 10:04:36 2004 ripley moved from incoming to Documentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Graphics * PR# 202 * Subject: persp box occlusion bug From: wsi@gcal.ac.uk Date: Wed, 2 Jun 1999 15:02:03 +0200 (MET DST) --The persp algorithm does not apply the occlusion rules to the frame, --which is always plotted first. --A bug, but not very simple to fix. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 202 <== From wsi@gcal.ac.uk Wed Jun 2 15:02:10 1999 Received: from localhost (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA27126 for ; Wed, 2 Jun 1999 15:02:03 +0200 (MET DST) Date: Wed, 2 Jun 1999 15:02:03 +0200 (MET DST) From: wsi@gcal.ac.uk Message-Id: <199906021302.PAA27126@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: persp box occlusion bug Full_Name: Bill Simpson Version: 64.1 OS: linux Submission from: (NULL) (193.62.250.209) Bug in persp() bounding box: If the surface being plotted extends below the lower z-axis boundary, the box is drawn with the wrong occlusion. The box is shown as being occluded by the surface even though it should be in front of the surface. The box is correct for surface extending above the box. Problem is only for surface extending below the box. This exhibits the bug: std<-rep(seq(-32,32,8),9)/1000 * 60 cf<-rep(seq(-32,32,8),rep(9,9))/1000 *60 dp<-(cf-std)/.6 std<-unique(std) cf<-unique(cf) dp<-t(matrix(dp,length(cf),length(std))) persp(std,cf,dp, xlim=c(-2,2), ylim=c(-2,2), zlim=c(0,5),theta=-40, phi=45, box=TRUE,ltheta=-120, lphi=120, d=1.5, shade=.7) ==> 202.audit <== Wed Jun 30 19:31:18 1999 pd moved from incoming to Graphics Thu Jul 01 18:19:48 1999 pd changed notes Sun Feb 20 10:07:11 2000 ripley changed notes Mon Feb 28 17:17:51 2000 pd changed notes Mon Feb 28 17:18:28 2000 pd changed notes Mon Feb 28 17:19:35 2000 pd changed notes Mon Feb 28 17:20:17 2000 pd changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 660 * Subject: identify.default ignores any setting of cex. From: Prof Brian Ripley Date: Fri, 15 Sep 2000 10:23:39 +0100 (BST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 660 <== From postmaster@franz.stat.wisc.edu Fri Sep 15 11:23:32 2000 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA13327 for ; Fri, 15 Sep 2000 11:23:32 +0200 (MET DST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id LAA17846 for ; Fri, 15 Sep 2000 11:23:49 +0200 (MET DST) Received: from franz.stat.wisc.edu(128.105.174.95) via SMTP by hypatia, id smtpdAAAa004Mn; Fri Sep 15 11:23:42 2000 Received: from toucan.stats.ox.ac.uk (really [163.1.20.20]) by franz.stat.wisc.edu via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Fri, 15 Sep 2000 04:25:51 -0500 (CDT) Received: from localhost (ripley@localhost) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id KAA14892 for ; Fri, 15 Sep 2000 10:23:39 +0100 (BST) X-Authentication-Warning: toucan.stats: ripley owned process doing -bs Date: Fri, 15 Sep 2000 10:23:39 +0100 (BST) From: Prof Brian Ripley X-Sender: ripley@toucan.stats To: R-bugs@r-project.org Subject: identify.default ignores any setting of cex. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII R 1.1.1 on Windows, but I think this is widespread. Using either par(cex=0.5) plot(1:10) identify(1:10) or plot(1:10) identify(1:10, cex=0.5) ignores the cex setting. The root cause is that par(cex=0.5) alters cexbase for the device but sets cex=1.0, and the internal text plotting routines use cex and not cexbase. The obvious fix is to set cex to cexbase in do_identify. However, if this is fixed, there is another problem, The offset of the label is related to the cex in use for the label, and not for the symbol. So plot(1:10, type="n") points(1:10, cex=5) identify(1:10) is not sensible in placing the labels. That may be hard to anticipate, but plot(1:10) identify(1:10, cex=0.5) needs to use cex=1 not cex=0.5 for the adjustment. Perhaps identify is trying too hard, and should give the user more control over the precise position of the label (as S-PLUS does). -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 660.audit <== Wed Oct 25 06:57:35 2000 ripley moved from incoming to Graphics ==> 660.followup.1 <== From ligges@statistik.uni-dortmund.de Wed Apr 25 17:24:42 2001 Received: from nx5.HRZ.Uni-Dortmund.DE (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id RAA02114 for ; Wed, 25 Apr 2001 17:24:42 +0200 (MET DST) Received: from amadeus.statistik.uni-dortmund.de by nx5.HRZ.Uni-Dortmund.DE via smtp-local with ESMTP; Wed, 25 Apr 2001 17:24:51 +0200 Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.9.3+Sun/8.9.3) with ESMTP id RAA01760; Wed, 25 Apr 2001 17:24:50 +0200 (MET DST) Message-ID: <3AE6EC55.6C1D8C7A@statistik.uni-dortmund.de> Date: Wed, 25 Apr 2001 17:25:09 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs CC: "Brian D. Ripley" Subject: Re: identify.default ignores any setting of cex (PR#660) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A follow-up to PR#660 (15 Sep 2000) from Brian Ripley: > R 1.1.1 on Windows, but I think this is widespread. > > Using either > > par(cex=0.5) > plot(1:10) > identify(1:10) > > or > > plot(1:10) > identify(1:10, cex=0.5) > > ignores the cex setting. The root cause is that par(cex=0.5) > alters cexbase for the device but sets cex=1.0, and the internal > text plotting routines use cex and not cexbase. > > The obvious fix is to set cex to cexbase in do_identify. However, > if this is fixed, there is another problem, The offset of the label > is related to the cex in use for the label, and not for the symbol. > So > > plot(1:10, type="n") > points(1:10, cex=5) > identify(1:10) > > is not sensible in placing the labels. That may be hard to anticipate, > but > > plot(1:10) > identify(1:10, cex=0.5) > > needs to use cex=1 not cex=0.5 for the adjustment. Perhaps identify is > trying too hard, and should give the user more control over the precise > position of the label (as S-PLUS does). The same with par(cex=1); plot(1:10); text(4, 5, "Hello World") # OK par(cex=2); plot(1:10); text(4, 5, "Hello World") # OK par(cex=2); plot(1:10); text(4, 5, "Hello World", cex = 1) # NOT OK par(cex=2); plot(1:10); text(4, 5, "Hello World", cex = 0.5) So the scaling with cex in text() is relative to the par() settings, which is not the expected behaviour. [R-1.2.2 on WinNT 4.0] Uwe Ligges ==> 660.followup.2 <== From ripley@stats.ox.ac.uk Wed Apr 25 20:00:09 2001 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA03187 for ; Wed, 25 Apr 2001 20:00:09 +0200 (MET DST) Received: from max166.public.ox.ac.uk (max166.public.ox.ac.uk [192.76.27.166]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id SAA06061; Wed, 25 Apr 2001 18:56:30 +0100 (BST) Date: Wed, 25 Apr 2001 18:55:47 +0100 (GMT Daylight Time) From: Prof Brian D Ripley To: cc: , Subject: Re: [Rd] Re: identify.default ignores any setting of cex (PR#660) In-Reply-To: <200104251524.RAA02124@pubhealth.ku.dk> Message-ID: Sender: ripley@stats.ox.ac.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Apr 2001 ligges@statistik.uni-dortmund.de wrote: > A follow-up to PR#660 (15 Sep 2000) from Brian Ripley: [...] > The same with > > par(cex=1); plot(1:10); text(4, 5, "Hello World") # OK > par(cex=2); plot(1:10); text(4, 5, "Hello World") # OK > par(cex=2); plot(1:10); text(4, 5, "Hello World", cex = 1) # NOT OK > par(cex=2); plot(1:10); text(4, 5, "Hello World", cex = 0.5) > > So the scaling with cex in text() is relative to the par() settings, > which is not the expected behaviour. It is the documented behaviour, though: see the description of cex in ?help. cex: numeric character expansion factor; multiplied by `par("cex")' yields the final character size. Brian -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 776 * Subject: strwidth does not take font into account From: Martyn Plummer Date: Tue, 19 Dec 2000 14:56:01 +0100 (CET) --This needs a substantial redesign. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 776 <== From postmaster@franz.stat.wisc.edu Tue Dec 19 14:53:40 2000 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA05819 for ; Tue, 19 Dec 2000 14:53:39 +0100 (MET) Received: from smtp02.iarc.fr (really [212.157.236.234]) by franz.stat.wisc.edu via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Tue, 19 Dec 2000 07:58:02 -0600 (CST) Received: from xena.iarc.fr ([10.10.150.125]) by smtp02.iarc.fr (8.9.3/8.9.3) with ESMTP id OAA21720 for ; Tue, 19 Dec 2000 14:53:55 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 19 Dec 2000 14:56:01 +0100 (CET) Organization: International Agency for Research on Cancer Sender: martyn@xena.iarc.fr From: Martyn Plummer To: r-bugs@r-project.org Subject: strwidth does not take font into account One for the wishlist. The text() function permits the use of different fonts with the arguments "font" or "vfont". These create text strings of the same height as the default font, but of different widths: bold face is slightly wider; vector fonts are usually much wider. I think the strwidth() function needs to take the font into account by also having "font" and "vfont" arguments. Currently it reports the string width using the default font, which can be quite different. Here is a little test function you can use to see how far off the reported string width is. test.strwidth <- function(text, vfont=NULL, cex=NULL, ...) { plot(0,0,xlim=c(-1,1),ylim=c(-1,1), type="n") text(0,0, text, adj=c(0,0), offset=0, cex=cex, vfont=vfont, ...) abline(h=c(0, strheight(text, cex=cex)), lty=2) abline(v=c(0, strwidth(text, cex=cex)), lty=2) } e.g. test.strwidth("This is some text", cex=2) test.strwidth("This is some text", cex=2, font=2) test.strwidth("This is some text", vfont=c("sans serif", "plain")) Martyn Please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 2.0 year = 2000 month = 12 day = 15 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base ==> 776.audit <== Tue Dec 26 10:31:10 2000 ripley moved from incoming to Graphics Sat Feb 24 08:55:28 2001 ripley changed notes Sat Feb 24 08:55:28 2001 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 791 * Subject: par(lab= *) / axis(*) bug From: maechler@stat.math.ethz.ch Date: Fri, 22 Dec 2000 10:59:26 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 791 <== From postmaster@franz.stat.wisc.edu Fri Dec 22 10:59:23 2000 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA08619 for ; Fri, 22 Dec 2000 10:59:23 +0100 (MET) Received: from stat.math.ethz.ch (really [129.132.58.23]) by franz.stat.wisc.edu via in.smtpd with esmtp (ident daemon using rfc1413) id (Debian Smail3.2.0.102) for ; Fri, 22 Dec 2000 03:59:36 -0600 (CST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id KAA02617; Fri, 22 Dec 2000 10:59:34 +0100 (MET) Received: from UNKNOWN(129.132.58.33), claiming to be "florence.ethz.ch" via SMTP by hypatia, id smtpdAAAa000cp; Fri Dec 22 10:59:26 2000 Received: (maechler@localhost) by florence.ethz.ch (8.9.3/D-MATH-client) id KAA23075; Fri, 22 Dec 2000 10:59:26 +0100 Date: Fri, 22 Dec 2000 10:59:26 +0100 From: maechler@stat.math.ethz.ch Message-Id: <200012220959.KAA23075@florence.ethz.ch> To: r-bugs@r-project.org Subject: par(lab= *) / axis(*) bug Cc: maechler@stat.math.ethz.ch As the subject says, here is example code (with comments) showing the problem: p1 <- function(lab = c(8,12,7)) { ## This `fails' (on a virgin device) clab <- paste(lab,collapse=",") plot(1,1, xlim = c(0,15), ylim = c(-.8,1), type ="n", axes = FALSE, main=paste("plot(*,axes=F); par(lab= c(",clab,")); axis(*) x 2",sep="")) box(col="gray80") op <- par(lab = lab) ; on.exit(par(op)) axis(1, pos = 0) axis(2, pos = 0, las = 1) par(op) op } p2 <- function(lab = c(8,12,7)) { ## This works [par() *BEFORE* plot() ] clab <- paste(lab,collapse=",") op <- par(lab = lab) ; on.exit(par(op)) plot(1,1, xlim = c(0,15), ylim = c(-.8,1), type ="n", axes = FALSE, main=paste("par(lab= c(",clab,")); plot(*,axes=F); axis(*) x 2",sep="")) box(col="gray80") axis(1, pos = 0) axis(2, pos = 0, las = 1) op ## lab 5 5 7 } dev.off() par(mfrow=c(2,1), mar=c(2,2,3,1)) p1() p2() --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = Patched major = 1 minor = 2.0 year = 2000 month = 12 day = 19 language = R Search Path: .GlobalEnv, package:nls, package:splines, package:lqs, package:modreg, package:stepfun, package:mva, package:eda, package:ts, package:VLMC, package:ctest, package:SfS, Autoloads, package:base ==> 791.reply.1 <== From: paul murrell To: maechler@stat.math.ethz.ch Subject: Re: par(lab= *) / axis(*) bug (PR#791) Date: Mon Sep 22 04:58:03 2003 Hi This is a complete mess. Both par([xy]axp) and par(lab) specify the approx number of ticks on the axes (lab says how many ticks, [xy]axp says how many intervals between ticks). Different parts of the C code refer to either [xy]axp or lab to determine the current setting. e.g., GSetupAxis refers to lab (called by par("usr")), but CreateAtVector (called by axis()) (mostly) refers to xaxp. (I think) The effect below happens because the plot() call triggers a par("usr") call which transfers the lab settings to the xaxp settings. In any case, the axis() calls refer to [xy]axp. So when plot() is called after par(lab) you get the lab settings taking effect. Otherwise the lab settings are ignored. Here's a possibly revealing little sequence ... > par("xaxp") [1] 0 1 5 > par("lab") [1] 5 5 7 > par(lab=c(8, 12, 7)) > par("xaxp") [1] 0 1 5 > plot(1:10) # could just be a par("usr") ?? > par("xaxp") [1] 1 10 9 ... a fix requires a careful look at S-Plus behaviour to determine what should be expected to happen. Have I mentioned my dislike for par()? Paul > As the subject says, > here is example code (with comments) showing the problem: > > p1 <- function(lab = c(8,12,7)) > { > ## This `fails' (on a virgin device) > clab <- paste(lab,collapse=",") > plot(1,1, xlim = c(0,15), ylim = c(-.8,1), type ="n", axes = FALSE, > main=paste("plot(*,axes=F); par(lab= c(",clab,")); axis(*) x > 2",sep="")) > box(col="gray80") > op <- par(lab = lab) ; on.exit(par(op)) > axis(1, pos = 0) > axis(2, pos = 0, las = 1) > par(op) > op > } > > p2 <- function(lab = c(8,12,7)) > { > ## This works [par() *BEFORE* plot() ] > clab <- paste(lab,collapse=",") > op <- par(lab = lab) ; on.exit(par(op)) > > plot(1,1, xlim = c(0,15), ylim = c(-.8,1), type ="n", axes = FALSE, > main=paste("par(lab= c(",clab,")); plot(*,axes=F); axis(*) x > 2",sep="")) > box(col="gray80") > axis(1, pos = 0) > axis(2, pos = 0, las = 1) > op ## lab 5 5 7 > } > > dev.off() > par(mfrow=c(2,1), mar=c(2,2,3,1)) > p1() > p2() > > > > > --please do not edit the information below-- > > Version: > platform = i686-pc-linux-gnu > arch = i686 > os = linux-gnu > system = i686, linux-gnu > status = Patched > major = 1 > minor = 2.0 > year = 2000 > month = 12 > day = 19 > language = R > > Search Path: > .GlobalEnv, package:nls, package:splines, package:lqs, package:modreg, > package:stepfun, package:mva, package:eda, package:ts, package:VLMC, > package:ctest, package:SfS, Autoloads, package:base > ==> 791.audit <== Tue Dec 26 10:31:10 2000 ripley moved from incoming to Graphics Mon Sep 22 04:58:03 2003 paul sent reply 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 816 * Subject: dotplot: character size of labels From: RINNER Heinrich Date: Thu, 18 Jan 2001 14:54:32 +0100 --Suggested fix is incorporated in 1.2.2. -- --There is a deeper problem: mtext() ignores par(cex=.5) in general. --To see the problem try: par(cex=.5); mtext("hi") --Paul thinks the right fix is to change the argument list for mtext so that --cex=par(cex) by default rather than cex=NA by default (plus corresponding --internal changes to do_mtext in plot.c). --This needs to be done very carefully because (i) the change suggested above --mayhave side-effects in many other pieces of interpreted code --(ii) do_mtext ignores dd->gp.cexbase unlike, for example, do_plot_xy --and anything to do with cexbase needs extreme care. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 816 <== From postmaster@franz.stat.wisc.edu Thu Jan 18 16:57:16 2001 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA13627 for ; Thu, 18 Jan 2001 16:57:15 +0100 (MET) Received: from ingw1.tirol.gv.at (really [212.183.27.1]) by franz.stat.wisc.edu via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Thu, 18 Jan 2001 09:57:24 -0600 (CST) Received: from xms.tirol.gv.at (xms.tirol.gv.at [10.11.128.200]) by ingw1.tirol.gv.at (Mailer) with ESMTP id 22ADE2825 for ; Thu, 18 Jan 2001 14:49:47 +0100 (NFT) Received: from xms.tirol.gv.at (unverified) by xms.tirol.gv.at (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 18 Jan 2001 14:54:33 +0100 Received: by xms.tirol.gv.at with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 14:54:33 +0100 Message-ID: From: RINNER Heinrich To: "'r-bugs@r-project.org'" Subject: dotplot: character size of labels Date: Thu, 18 Jan 2001 14:54:32 +0100 Return-Receipt-To: RINNER Heinrich MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id QAA13627 There seems to be a bug in "dotplot" concerning the "cex" parameter. Setting cex has no effect on the character size of the labels of the points. This problem was posted to r-help today (Thu, 18 Jan 2001); the solution given by Brian Ripley (and Uwe Ligges) seems to work for me. Heinrich Rinner. > version _ platform i386-pc-mingw32 arch x86 os Win32 system x86, Win32 status major 1 minor 2.0 year 2000 month 12 day 15 language R > ---------- > Von: Prof Brian Ripley[SMTP:ripley@stats.ox.ac.uk] > Gesendet: Donnerstag, 18. Jänner 2001 10:35 > An: RINNER Heinrich > Cc: 'r-help@stat.math.ethz.ch' > Betreff: Re: [R] dotplot: character size of labels > > On Thu, 18 Jan 2001, RINNER Heinrich wrote: > > > Dear R users, > > > > using dotplot (R1.2.0, WinNT4.0), I am trying to change the character > size > > of the labels of the points: > > > > > # example > > > data(VADeaths) > > > dotplot(VADeaths, main = "Death Rates in Virginia - 1940") > > > # I'd like to have smaller character size of the labels (for age and > > population groups) > > > ?dotplot > > > # for argument "cex", this says: "Setting cex to a value smaller than > one > > can be a useful way of avoiding label overlap." > > > dotplot(VADeaths, main = "Death Rates in Virginia - 1940", cex = 0.5) > > > # the main title and the plotting characters are smaller now, but not > the > > labels > > > # trying to set other graphics parameters seems to have no effect: > > > dotplot(VADeaths, main = "Death Rates in Virginia - 1940", cex.axis = > 0.5) > > > dotplot(VADeaths, main = "Death Rates in Virginia - 1940", cex.lab = > 0.5) > > > > I'd be grateful for any hint how to do this correctly; > > Looks like a bug. Inside dotplot alter to > > for (i in 1:n) mtext(labs[i], side = 2, line = loffset, > at = y[i], adj = 0, col = color, las = 2, cex = cex, ...) > > for (i in 1:nlevels(groups)) mtext(glabels[i], side = 2, > line = goffset, at = gpos[i], adj = 0, col = gcolor, > las = 2, cex = cex, ...) > > However, it really needs more than that to calculate the spaces for the > labels correctly. > > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > 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 272860 (secr) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > ==> 816.audit <== Sat Jan 20 10:24:14 2001 ripley moved from incoming to Graphics Tue Jan 23 03:38:23 2001 paul changed notes Tue Jan 23 03:38:23 2001 paul foobar Sun Feb 18 10:11:12 2001 ripley changed notes Sun Feb 18 10:11:12 2001 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 831 * Subject: screen can't go back to (split) screen with log="y" plot From: Thomas Vogels Date: 30 Jan 2001 00:39:41 -0500 --Still there. Suggested fix included in followups, but we didn't get around to --try it in time for 1.2.3. -- --Fix doesn't work. One problem is that the opar<-par();par(opar) idiom updates --xaxp before xlog, and the new value of xaxp may only be valid under the new --value of xlog. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 831 <== From postmaster@franz.stat.wisc.edu Tue Jan 30 06:39:31 2001 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id GAA28455 for ; Tue, 30 Jan 2001 06:39:30 +0100 (MET) Received: from infiniti.ece.cmu.edu (really [128.2.216.84]) by franz.stat.wisc.edu via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Mon, 29 Jan 2001 23:39:42 -0600 (CST) Received: (from tov@localhost) by infiniti.ece.cmu.edu (AIX4.3/UCB 8.8.8/8.8.8) id AAA26672; Tue, 30 Jan 2001 00:39:42 -0500 X-Authentication-Warning: infiniti.ece.cmu.edu: tov set sender to tov@ece.cmu.edu using -f Sender: tov@infiniti.ece.cmu.edu To: r-bugs@r-project.org Cc: Thomas Vogels Subject: screen can't go back to (split) screen with log="y" plot Reply-To: Thomas Vogels X-URI: http://www.ece.cmu.edu/~tov From: Thomas Vogels User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 Date: 30 Jan 2001 00:39:41 -0500 Message-ID: Lines: 76 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi. Let's try to explain the subject line with some code: > split.screen (c(2,1)) [1] 1 2 > screen(1) > plot (1:2, 1:2, log="y", main="1") > screen (2) > plot (1:2, 1:2, main="2") > screen (1) Error in par(.split.screens[[n]]) : invalid value specified for graphics parameter "yaxp". > close.screen(all=TRUE) Let's add comments: > split.screen (c(2,1)) [1] 1 2 OK, plot in the top half screen: > screen(1) > plot (1:2, 1:2, log="y", main="1") > par("yaxp") [1] 1 2 -5 OK, switch to bottom half: > screen (2) > plot (1:2, 1:2, main="2") > par("yaxp") [1] 1 2 5 OK, looks fine, let's go back up: > screen (1) Error in par(.split.screens[[n]]) : invalid value specified for graphics parameter "yaxp". Bummer. > close.screen(all=TRUE) Somehow I'm hoping you'll tell me I'm doing something wrong, because I'd really would like to be able to do the following: repeat { #calculate screen(1) #fancy plot screen (2) #even fancier plot ;-) if (user.bored()) break } Which is roughly what I was doing when the error messages started popping up. Thanks, -tom --please do not edit the information below-- Version: platform = i386-pc-linux-gnu arch = i386 os = linux-gnu system = i386, linux-gnu status = major = 1 minor = 2.1 year = 2001 month = 01 day = 15 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base -- mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204 ==> 831.followup.1 <== From ripley@stats.ox.ac.uk Tue Jan 30 08:40:46 2001 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA28901 for ; Tue, 30 Jan 2001 08:40:46 +0100 (MET) Received: from max144.public.ox.ac.uk (max144.public.ox.ac.uk [192.76.27.144]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id HAA21509; Tue, 30 Jan 2001 07:40:54 GMT Date: Tue, 30 Jan 2001 07:39:25 +0000 (GMT) From: Prof Brian D Ripley Sender: To: cc: Subject: Re: [Rd] screen can't go back to log="y" plot (PR#831) In-Reply-To: <200101300539.GAA28465@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [I have abbreviated the subject as jitterbug has been having probems with long subjects.] The issue here is that one cannot mix log/non-log axes in the calls to screen(), as the appropriate par() parameter is read-only, but the meaning of yaxp depends on it. But beyond that you can't set x/yaxp for log axes. You should be able to do this: you can in the S original. A simpler version: plot (1:2, 1:2, log="y", main="1") zz <- par("yaxp") zz [1] 1 2 -5 par(yaxp=zz) Error in par(yaxp = zz) : invalid value specified for graphics parameter "yaxp". So you can't reset the yaxp parameter to what it is reported as! Additional bug: the meaning of x/yaxp for log axes is not defined in help(par). On Tue, 30 Jan 2001 tov@ece.cmu.edu wrote: > > Hi. Let's try to explain the subject line with some code: > > > split.screen (c(2,1)) > [1] 1 2 > > screen(1) > > plot (1:2, 1:2, log="y", main="1") > > screen (2) > > plot (1:2, 1:2, main="2") > > screen (1) > Error in par(.split.screens[[n]]) : invalid value specified for graphics parameter "yaxp". > > close.screen(all=TRUE) > > Let's add comments: > > > split.screen (c(2,1)) > [1] 1 2 > > OK, plot in the top half screen: > > screen(1) > > plot (1:2, 1:2, log="y", main="1") > > par("yaxp") > [1] 1 2 -5 > > OK, switch to bottom half: > > screen (2) > > plot (1:2, 1:2, main="2") > > par("yaxp") > [1] 1 2 5 > > OK, looks fine, let's go back up: > > screen (1) > Error in par(.split.screens[[n]]) : invalid value specified for graphics parameter "yaxp". > > Bummer. > > close.screen(all=TRUE) > > Somehow I'm hoping you'll tell me I'm doing something wrong, because > I'd really would like to be able to do the following: > repeat { > #calculate > screen(1) > #fancy plot > screen (2) > #even fancier plot ;-) > if (user.bored()) break > } > Which is roughly what I was doing when the error messages started > popping up. > > Thanks, > -tom > > --please do not edit the information below-- > > Version: > platform = i386-pc-linux-gnu > arch = i386 > os = linux-gnu > system = i386, linux-gnu > status = > major = 1 > minor = 2.1 > year = 2001 > month = 01 > day = 15 > language = R > > Search Path: > .GlobalEnv, package:ctest, Autoloads, package:base > > > > -- > mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204 > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 831.followup.2 <== From tov@ece.cmu.edu Thu Feb 1 02:13:08 2001 Received: from infiniti.ece.cmu.edu (INFINITI.ECE.CMU.EDU [128.2.133.84]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id CAA25173 for ; Thu, 1 Feb 2001 02:13:07 +0100 (MET) Received: (from tov@localhost) by infiniti.ece.cmu.edu (AIX4.3/UCB 8.8.8/8.8.8) id UAA19026; Wed, 31 Jan 2001 20:12:41 -0500 X-Authentication-Warning: infiniti.ece.cmu.edu: tov set sender to tov@ece.cmu.edu using -f Sender: tov@infiniti.ece.cmu.edu To: Prof Brian D Ripley Cc: Subject: Re: [Rd] screen can't go back to log="y" plot (PR#831) References: Reply-To: Thomas Vogels X-URI: http://www.ece.cmu.edu/~tov From: Thomas Vogels Date: 31 Jan 2001 20:12:41 -0500 In-Reply-To: Prof Brian D Ripley's message of "Tue, 30 Jan 2001 07:39:25 +0000 (GMT)" Message-ID: Lines: 81 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Prof Brian D Ripley writes: > [I have abbreviated the subject as jitterbug has been having probems > with long subjects.] > > The issue here is that one cannot mix log/non-log axes in the calls to > screen(), as the appropriate par() parameter is read-only, but the > meaning of yaxp depends on it. But beyond that you can't set > x/yaxp for log axes. > > You should be able to do this: you can in the S original. > > A simpler version: > > plot (1:2, 1:2, log="y", main="1") > zz <- par("yaxp") > zz > [1] 1 2 -5 > par(yaxp=zz) > Error in par(yaxp = zz) : invalid value specified for graphics parameter > "yaxp". > > So you can't reset the yaxp parameter to what it is reported as! [snip] The code in main/par.c ignores the value of xlog (or ylog) when setting xaxp (or yaxp). Right now you have in Specify (and Specify2): ... else if (streql(what, "xaxp")) { value = coerceVector(value, REALSXP); lengthCheck(what, value, 3); naRealCheck(REAL(value)[0], what); naRealCheck(REAL(value)[1], what); posIntCheck((int) (REAL(value)[2]), what); Shouldn't that be something like: ... else if (streql(what, "xaxp")) { value = coerceVector(value, REALSXP); lengthCheck(what, value, 3); naRealCheck(REAL(value)[0], what); naRealCheck(REAL(value)[1], what); if (dd->gp.xlog) logAxpCheck((int) (REAL(value)[2]), what); else posIntCheck((int) (REAL(value)[2]), what); Where logAxpCheck is suitably defined as: static void logAxpCheck(int x, char *s) { if (x == NA_INTEGER || x == 0 || x > 4) par_error(s); } since only values < 0 or the values 1, 2, 3 are allowed? > Additional bug: the meaning of x/yaxp for log axes is not defined > in help(par). excerpt from help(par): xaxp: A vector of the form `c(x1, x2, n)' giving the coordinates of the extreme tick marks and the number of intervals between tick-marks. Could you add: The value of n must be positive for linear scale axes. For logarithmic scale axes n must be either negative (then there will be (1-n) ticks at a linear distance) or one of 1, 2, or 3 where n then indicates the number of ticks per decade. similar for yaxp? What am I missing? Regards, -tom -- mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204 ==> 831.audit <== Wed Feb 7 08:51:14 2001 ripley moved from incoming to Graphics Thu Apr 26 12:13:40 2001 pd changed notes Thu Apr 26 12:13:40 2001 pd foobar Thu Jun 7 19:13:15 2001 thomas changed notes Thu Jun 7 19:13:15 2001 thomas foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 837 * Subject: screen doesn't handle redrawing properly From: Thomas Vogels Date: 01 Feb 2001 14:20:52 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 837 <== From tov@ece.cmu.edu Thu Feb 1 20:20:40 2001 Received: from infiniti.ece.cmu.edu (INFINITI.ECE.CMU.EDU [128.2.133.84]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA08721 for ; Thu, 1 Feb 2001 20:20:39 +0100 (MET) Received: (from tov@localhost) by infiniti.ece.cmu.edu (AIX4.3/UCB 8.8.8/8.8.8) id OAA30464; Thu, 1 Feb 2001 14:20:52 -0500 X-Authentication-Warning: infiniti.ece.cmu.edu: tov set sender to tov@ece.cmu.edu using -f Sender: tov@infiniti.ece.cmu.edu To: r-bugs@biostat.ku.dk Cc: Thomas Vogels Subject: screen doesn't handle redrawing properly Reply-To: Thomas Vogels X-URI: http://www.ece.cmu.edu/~tov From: Thomas Vogels Date: 01 Feb 2001 14:20:52 -0500 Message-ID: Lines: 74 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi. As far as I understand it, there is a list of graphic primitives stored for a device. So for example, when I iconify/deiconify an X11 window, the plot will be redrawn. Now screen (split.screen and friends) appear not to handle this list properly, the list is reset or not reset at odd times. The commands below will show clearly what I mean. There are two effects: - After splitting the device real estate into two screens, I can plot on these screens, alternating between them. When I then touch the window to force a redraw, *all* the plots are redrawn, not just the last (and visible) ones. [This happens when the X server runs on AIX, R runs on AIX or Sun.] - Again, after splitting, plotting on one screen can affect the other screen. I.e. plot(...); plot (...) on the left screen can erase the *right* screen. [This happens for all platforms I have access to, AIX, Linux, Sun.] The first effect may be due to a bad interaction with the X server, but the second effect is surely not desirable, is it? Am I mis-using 'screen' here? R> split.screen (c(1,2)) [1] 1 2 R> # Draw 10000 points to make the effect obvious R> screen (1) R> plot (1:10000, 1:10000, main="1") R> screen (2) R> plot (1:10000, 1:10000, main="2") R> # Ok, go back to screen 1, draw plots 3 and 4 R> screen (1) R> plot (1:10000, 10000:1, main="3") R> screen (2) R> plot (1:10000, 10000:1, main="4") R> R> ######################################## R> # NOW lower/raise window, do something to force device to redraw itself. R> # You'll see again plot 1 (!), 2 (!), 3, and 4. Why 1 and 2? R> ######################################## R> R> # Here's how to erase screen 2 from screen 1 (!) R> screen (1) R> plot (1:10, 1:10, main="3a") R> ######################################## R> # The following plot will erase screen 2 R> ######################################## R> plot (1:10, 1:10, main="3b") R> R> # The good news is that this resets the list of graphic ops: R> screen (2) R> plot (1:10, 1:10, main="4") R> # Now if you touch the window, you'll see only plot 3b and 4. Regards, -tom R> R.version _ platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status Patched major 1 minor 2.1 year 2001 month 01 day 31 language R -- mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204 ==> 837.audit <== Wed Feb 7 08:51:14 2001 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 887 * Subject: axis(adj=anything) has no effect From: jhallman@frb.gov Date: Wed, 28 Mar 2001 20:51:05 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 887 <== From jhallman@frb.gov Wed Mar 28 20:51:06 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA23265 for ; Wed, 28 Mar 2001 20:51:05 +0200 (MET DST) Date: Wed, 28 Mar 2001 20:51:05 +0200 (MET DST) From: jhallman@frb.gov Message-Id: <200103281851.UAA23265@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: axis(adj=anything) has no effect Full_Name: Jeff Hallman Version: 1.2.2 OS: SunOS5.6 Submission from: (NULL) (132.200.32.33) Giving an adj argument to axis() seems to have no effect. In Splus, adj = 0 left-justifies the labels under the ticks, adj = 1 right justifies them, and numbers in between can also be used. I like to use adj = 0.9 to get something that looks like this: -----------+-----------+-----------+------------+--------- 1980 1981 1982 1983 as an axis for a plot of monthly time series data. ==> 887.audit <== Sat Apr 7 10:29:17 2001 ripley moved from incoming to Graphics ==> 887.followup.1 <== From paul@stat.auckland.ac.nz Tue Jun 19 06:05:35 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4] (may be forged)) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id GAA16140 for ; Tue, 19 Jun 2001 06:05:33 +0200 (MET DST) Received: from stat1.stat.auckland.ac.nz (stat1.stat.auckland.ac.nz [130.216.93.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA00412; Tue, 19 Jun 2001 16:05:26 +1200 (NZST) Received: from murrell (murrell.stat.auckland.ac.nz [130.216.93.23]) by stat1.stat.auckland.ac.nz (8.9.3+Sun/8.8.8) with SMTP id QAA24826; Tue, 19 Jun 2001 16:05:25 +1200 (NZST) Message-ID: <020401c0f877$becbd540$175dd882@stat.auckland.ac.nz> From: "Paul Murrell" To: Cc: Subject: Re: axis(adj=anything) has no effect (PR#887) Date: Tue, 19 Jun 2001 16:24:35 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Hi ----Bug summary:---- Giving an adj argument to axis() seems to have no effect. In Splus, adj = 0 left-justifies the labels under the ticks, adj = 1 right justifies them, and numbers in between can also be used. I like to use adj = 0.9 to get something that looks like this: -----------+-----------+-----------+------------+--------- 1980 1981 1982 1983 as an axis for a plot of monthly time series data. ----Bug summary:---- Are missing features bugs or wish-list items ? Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 943 * Subject: legend() with xpd=T; omission of initial plot character From: John Maindonald Date: Sun, 20 May 2001 10:35:16 +1000 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 943 <== From postmaster@franz.stat.wisc.edu Sun May 20 02:32:40 2001 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id CAA02494 for ; Sun, 20 May 2001 02:32:39 +0200 (MET DST) Received: from mail.anu.edu.au (really [150.203.2.7]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Sat, 19 May 2001 19:32:31 -0500 (CDT) Received: from anugpo.anu.edu.au (anugpo.anu.edu.au [150.203.2.6]) by mail.anu.edu.au (8.9.3/8.9.3) with ESMTP id KAA18515 for ; Sun, 20 May 2001 10:32:27 +1000 (EST) Received: from soda.anu.edu.au (soda.anu.edu.au [150.203.33.17]) by anugpo.anu.edu.au (8.9.3+Sun/8.9.3) with ESMTP id KAA22405 for ; Sun, 20 May 2001 10:32:27 +1000 (EST) Message-Id: <5.0.2.1.1.20010520103337.00ac8b10@pophost.anu.edu.au> X-Sender: u9801539@pophost.anu.edu.au (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 20 May 2001 10:35:16 +1000 To: r-bugs@r-project.org From: John Maindonald Subject: legend() with xpd=T; omission of initial plot character Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In the following: plot(0:1, 0:1) legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) the first plot character is omitted when plotting to the screen. I obtained the same behaviour when placing a legend in the margin following use of pairs() -please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = x86 os = Win32 system = x86, Win32 status = major = 1 minor = 2.3 year = 2001 month = 04 day = 26 language = R Windows 98 SE 4.10 (build 2222) A Search Path: .GlobalEnv, package:ctest, Autoloads, package:base John Maindonald email : john.maindonald@anu.edu.au Statistical Consulting Unit, phone : (6125)3998 c/o CMA, SMS, fax : (6125)5549 John Dedman Mathematical Sciences Building Australian National University Canberra ACT 0200 Australia ==> 943.reply.1 <== From: paul@stat.auckland.ac.nz To: r-core@r-project.org Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943) Date: Tue Jun 19 05:58:40 2001 CC: r-bugs@r-project.org; john.maindonald@anu.edu.au Hi Bug summary:---- par(xpd=T) plot(0:1, 0:1) legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) the first plot character is omitted when plotting to the screen. Bug summary:---- I cannot reproduce this bug, BUT it did show up a bug in rect() -- in the example above, the border around the legend is not drawn. This is because rect() ignores par(xpd). The default is rect(xpd=FALSE). This is at odds with text(xpd=NULL) and polygon(xpd=NULL) which use par(xpd) by default. arrows(xpd=FALSE) has the same problem as rect(). I propose modifying rect() and arrows() to use par(xpd) by default like text() and polygon(). There will, as usual, be a small risk that someone's code will produce different output after this change, but this risk should be pretty small. Any objections ... ? Paul ==> 943.followup.1 <== From postmaster@franz.stat.wisc.edu Tue Jun 19 05:56:22 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id FAA16092 for ; Tue, 19 Jun 2001 05:56:21 +0200 (MET DST) Received: from pubhealth.ku.dk (really [130.225.108.10]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Mon, 18 Jun 2001 22:56:15 -0500 (CDT) Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id FAA16087; Tue, 19 Jun 2001 05:55:27 +0200 (MET DST) From: paul@stat.auckland.ac.nz Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [130.225.108.193]) by blueberry.kubism.ku.dk (8.9.3/8.9.3) with ESMTP id FAA32381; Tue, 19 Jun 2001 05:58:35 +0200 Date: Tue, 19 Jun 2001 05:58:35 +0200 Message-Id: <200106190358.FAA32381@blueberry.kubism.ku.dk> To: r-core@r-project.org Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943) CC: r-bugs@r-project.org;john.maindonald@anu.edu.au;;; X-Loop: R-bugs@biostat.ku.dk Hi Bug summary:---- par(xpd=T) plot(0:1, 0:1) legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) the first plot character is omitted when plotting to the screen. Bug summary:---- I cannot reproduce this bug, BUT it did show up a bug in rect() -- in the example above, the border around the legend is not drawn. This is because rect() ignores par(xpd). The default is rect(xpd=FALSE). This is at odds with text(xpd=NULL) and polygon(xpd=NULL) which use par(xpd) by default. arrows(xpd=FALSE) has the same problem as rect(). I propose modifying rect() and arrows() to use par(xpd) by default like text() and polygon(). There will, as usual, be a small risk that someone's code will produce different output after this change, but this risk should be pretty small. Any objections ... ? Paul ==> 943.reply.2 <== From postmaster@franz.stat.wisc.edu Tue Jun 19 08:43:07 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA16819 for ; Tue, 19 Jun 2001 08:43:07 +0200 (MET DST) Received: from stat.math.ethz.ch (really [129.132.58.23]) by franz.stat.wisc.edu via smail with esmtp (ident daemon using rfc1413) id (Debian Smail3.2.0.111) for ; Tue, 19 Jun 2001 01:42:54 -0500 (CDT) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id IAA02705; Tue, 19 Jun 2001 08:42:52 +0200 (MET DST) Received: from lynne(129.132.58.30), claiming to be "lynne.ethz.ch" via SMTP by hypatia, id smtpdAAAa000eE; Tue Jun 19 08:42:50 2001 Received: (maechler@localhost) by lynne.ethz.ch (8.9.3/D-MATH-client) id IAA08111; Tue, 19 Jun 2001 08:42:50 +0200 X-Authentication-Warning: lynne.ethz.ch: maechler set sender to maechler@stat.math.ethz.ch using -f From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15150.62570.490993.741070@gargle.gargle.HOWL> Date: Tue, 19 Jun 2001 08:42:50 +0200 To: paul@stat.auckland.ac.nz Cc: r-bugs@r-project.org, john.maindonald@anu.edu.au Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943) In-Reply-To: <200106190358.FAA32381@blueberry.kubism.ku.dk> References: <200106190358.FAA32381@blueberry.kubism.ku.dk> X-Mailer: VM 6.92 under Emacs 20.7.1 Reply-To: Martin Maechler >>>>> "Paul" == Paul Murrell writes: Paul> Hi Paul> Bug summary:---- Paul> par(xpd=T) Paul> plot(0:1, 0:1) Paul> legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) Paul> the first plot character is omitted when plotting to Paul> the screen. Paul> Bug summary:---- Paul> I cannot reproduce this bug, BUT it did show up a bug in rect() Paul> -- in the example above, the border around the legend is not Paul> drawn. Coincidence, I *did* look at that bug only yesterday. My experience: I *could* reproduce the bug {X11(), Linux-386}, but only a few times. Then, it didn't show anymore. Even restarting R wouldn't show it again. My ``explanation'' was that it might be (a bug) inside X11 / Window manager handling of things... ?? Paul> This is because rect() ignores par(xpd). The default is Paul> rect(xpd=FALSE). This is at odds with text(xpd=NULL) and Paul> polygon(xpd=NULL) which use par(xpd) by default. Paul> arrows(xpd=FALSE) has the same problem as rect(). Paul> I propose modifying rect() and arrows() to use par(xpd) by Paul> default like text() and polygon(). There will, as usual, be a Paul> small risk that someone's code will produce different output Paul> after this change, but this risk should be pretty small. Paul> Any objections ... ? not at all, but please fix abline(*) at the same time. It doesn't obey xpd either (PR#750). Martin ==> 943.reply.3 <== From: paul murrell To: paul@stat.auckland.ac.nz Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943) Date: Tue Jul 17 04:28:44 2001 CC: John Maindonald Hi > Bug summary:---- > par(xpd=T) > plot(0:1, 0:1) > legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) > > the first plot character is omitted when plotting to > the screen. > Bug summary:---- > > I cannot reproduce this bug, BUT it did show up a bug in rect() -- in the > example above, the border around the legend is not drawn. Still can't reproduce original bug, so no progress there. > This is because rect() ignores par(xpd). The default is rect(xpd=FALSE). This > is at odds with text(xpd=NULL) and polygon(xpd=NULL) which use par(xpd) by > default. arrows(xpd=FALSE) has the same problem as rect(). > > I propose modifying rect() and arrows() to use par(xpd) by default like text() > and polygon(). There will, as usual, be a small risk that someone's code will > produce different output after this change, but this risk should be pretty > small. Both of these changes made now (for 1.3.1). The following code should demonstrate the bugs (in pre-1.3.1 R) and the fixes: par(mfrow=c(2,1), xpd=FALSE) plot(1:10) plot(1:10) # rect() and arrow() ignored par(xpd=) rect(1, 9, 2, 20, col="red") arrows(1.5, 20, 1.5, 10) par(xpd=TRUE) rect(3, 9, 4, 20, col="blue") arrows(3.5, 20, 3.5, 10) par(xpd=NA) rect(5, 9, 6, 20, col="green") arrows(5.5, 20, 5.5, 10) Paul ==> 943.audit <== Mon May 21 08:54:07 2001 ripley moved from incoming to Graphics Tue Jun 19 05:58:40 2001 paul sent reply 1 Tue Jul 17 04:28:44 2001 paul sent reply 3 ==> 943.followup.2 <== From MAILER-DAEMON Tue Jul 17 04:21:22 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id EAA16216 for ; Tue, 17 Jul 2001 04:21:21 +0200 (MET DST) Received: from localhost (localhost) by blueberry.kubism.ku.dk (8.9.3/8.9.3) with internal id EAA21901; Tue, 17 Jul 2001 04:28:45 +0200 Date: Tue, 17 Jul 2001 04:28:45 +0200 From: Mail Delivery Subsystem Message-Id: <200107170228.EAA21901@blueberry.kubism.ku.dk> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAA21901.995336925/blueberry.kubism.ku.dk" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --EAA21901.995336925/blueberry.kubism.ku.dk The original message was received at Tue, 17 Jul 2001 04:28:44 +0200 from blueberry.kubism.ku.dk [130.225.108.193] ----- The following addresses had permanent fatal errors ----- (expanded from: ) (expanded from: ) ----- Transcript of session follows ----- ... while talking to mail.kubism.ku.dk.: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown --EAA21901.995336925/blueberry.kubism.ku.dk Content-Type: message/delivery-status Reporting-MTA: dns; blueberry.kubism.ku.dk Received-From-MTA: DNS; blueberry.kubism.ku.dk Arrival-Date: Tue, 17 Jul 2001 04:28:44 +0200 Final-Recipient: RFC822; john@blueberry.kubism.ku.dk X-Actual-Recipient: RFC822; john@mail.kubism.ku.dk Action: failed Status: 5.1.1 Remote-MTA: DNS; mail.kubism.ku.dk Diagnostic-Code: SMTP; 550 ... User unknown Last-Attempt-Date: Tue, 17 Jul 2001 04:28:44 +0200 Final-Recipient: RFC822; maindonald@blueberry.kubism.ku.dk X-Actual-Recipient: RFC822; maindonald@mail.kubism.ku.dk Action: failed Status: 5.1.1 Remote-MTA: DNS; mail.kubism.ku.dk Diagnostic-Code: SMTP; 550 ... User unknown Last-Attempt-Date: Tue, 17 Jul 2001 04:28:44 +0200 --EAA21901.995336925/blueberry.kubism.ku.dk Content-Type: message/rfc822 Return-Path: Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [130.225.108.193]) by blueberry.kubism.ku.dk (8.9.3/8.9.3) with ESMTP id EAA21899; Tue, 17 Jul 2001 04:28:44 +0200 Date: Tue, 17 Jul 2001 04:28:44 +0200 Message-Id: <200107170228.EAA21899@blueberry.kubism.ku.dk> From: paul murrell To: paul@stat.auckland.ac.nz Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943) CC: John Maindonald X-Loop: R-bugs@biostat.ku.dk Hi > Bug summary:---- > par(xpd=T) > plot(0:1, 0:1) > legend(x=0, y=1.2, pch=c(1,2), legend=c("May","June")) > > the first plot character is omitted when plotting to > the screen. > Bug summary:---- > > I cannot reproduce this bug, BUT it did show up a bug in rect() -- in the > example above, the border around the legend is not drawn. Still can't reproduce original bug, so no progress there. > This is because rect() ignores par(xpd). The default is rect(xpd=FALSE). This > is at odds with text(xpd=NULL) and polygon(xpd=NULL) which use par(xpd) by > default. arrows(xpd=FALSE) has the same problem as rect(). > > I propose modifying rect() and arrows() to use par(xpd) by default like text() > and polygon(). There will, as usual, be a small risk that someone's code will > produce different output after this change, but this risk should be pretty > small. Both of these changes made now (for 1.3.1). The following code should demonstrate the bugs (in pre-1.3.1 R) and the fixes: par(mfrow=c(2,1), xpd=FALSE) plot(1:10) plot(1:10) # rect() and arrow() ignored par(xpd=) rect(1, 9, 2, 20, col="red") arrows(1.5, 20, 1.5, 10) par(xpd=TRUE) rect(3, 9, 4, 20, col="blue") arrows(3.5, 20, 3.5, 10) par(xpd=NA) rect(5, 9, 6, 20, col="green") arrows(5.5, 20, 5.5, 10) Paul --EAA21901.995336925/blueberry.kubism.ku.dk-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 997 * Subject: las=1 with log axis From: Peter Dalgaard BSA Date: Wed, 27 Jun 2001 11:54:06 +0200 --Paul in reply 1: I'm leaving this bug active until these other issues are --resolved ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 997 <== From postmaster@franz.stat.wisc.edu Wed Jun 27 11:50:00 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA01987 for ; Wed, 27 Jun 2001 11:49:59 +0200 (MET DST) Received: from pubhealth.ku.dk (really [130.225.108.10]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Wed, 27 Jun 2001 04:49:52 -0500 (CDT) Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA01969; Wed, 27 Jun 2001 11:49:40 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.9.3/8.9.3) id LAA25776; Wed, 27 Jun 2001 11:54:06 +0200 Date: Wed, 27 Jun 2001 11:54:06 +0200 From: Peter Dalgaard BSA Message-Id: <200106270954.LAA25776@blueberry.kubism.ku.dk> To: r-bugs@r-project.org Subject: las=1 with log axis Cc: pd@pubhealth.ku.dk This just came in: plot(c(0.1,100),log="y", las=1) (Numbers and tick marks are unaligned) Same thing with mtext(), try mtext("x",2,at=0.1) mtext("x",2,at=0.1,las=1) --please do not edit the information below-- Version: platform = i586-pc-linux-gnu arch = i586 os = linux-gnu system = i586, linux-gnu status = major = 1 minor = 3.0 year = 2001 month = 06 day = 22 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base ==> 997.followup.1 <== From paul@stat.auckland.ac.nz Fri Jun 29 00:19:03 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4] (may be forged)) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id AAA21935; Fri, 29 Jun 2001 00:19:01 +0200 (MET DST) Received: from stat1.stat.auckland.ac.nz (stat1.stat.auckland.ac.nz [130.216.93.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA24932; Fri, 29 Jun 2001 10:18:52 +1200 (NZST) Received: from murrell (murrell.stat.auckland.ac.nz [130.216.93.23]) by stat1.stat.auckland.ac.nz (8.9.3+Sun/8.8.8) with SMTP id KAA25180; Fri, 29 Jun 2001 10:18:52 +1200 (NZST) Message-ID: <00fc01c10023$19a40700$175dd882@stat.auckland.ac.nz> From: "Paul Murrell" To: , Cc: References: <200106270950.LAA01997@pubhealth.ku.dk> Subject: Re: [Rd] las=1 with log axis (PR#997) Date: Fri, 29 Jun 2001 10:38:49 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Hi > This just came in: > > plot(c(0.1,100),log="y", las=1) > > (Numbers and tick marks are unaligned) > > Same thing with mtext(), try > > mtext("x",2,at=0.1) > mtext("x",2,at=0.1,las=1) This is related to bug #865, which I have discovered is a problem with some of the very basic transformation code in R graphics (for transforming widths or heights when there are log scales). I have a fix for this particular mtext() problem, but I'm still working on the more general transformation bug. Paul ==> 997.reply.1 <== From: paul murrell To: pd@pubhealth.ku.dk Subject: Re: las=1 with log axis (PR#997) Date: Tue Jul 17 06:05:49 2001 Hi > plot(c(0.1,100),log="y", las=1) > > (Numbers and tick marks are unaligned) > > Same thing with mtext(), try > > mtext("x",2,at=0.1) > mtext("x",2,at=0.1,las=1) This is now fixed (which also fixes PR#865). Also fixed for mtext() when side=1, log="x", and las=2 (and for corresponding siutations on sides 3 and 4). Also fixed for mtext() when text is an expression (i.e., mathematical annotation). Unfortunately, the problem goes pretty deep -- it is to do with transformation of widths and heights to or from USER coordinates when the axis is logged. There are a couple of other places where this causes a problem: (i) strwidth() and strheight() (ii) symbols() I'm leaving this bug active until these other issues are resolved. Paul ==> 997.audit <== Sat Jun 30 08:57:44 2001 ripley moved from incoming to Graphics Tue Jul 17 06:05:49 2001 paul sent reply 1 Thu Sep 4 18:55:01 2003 thomas changed notes Thu Sep 4 18:55:01 2003 thomas foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1045 * Subject: Palette changes on redraw From: Peter Dalgaard BSA Date: 08 Aug 2001 19:08:01 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1045 <== From postmaster@franz.stat.wisc.edu Wed Aug 8 19:07:59 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA11349 for ; Wed, 8 Aug 2001 19:07:58 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (really [130.225.108.193]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Wed, 8 Aug 2001 12:07:53 -0500 (CDT) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id f78H81o29218; Wed, 8 Aug 2001 19:08:01 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: r-bugs@r-project.org Subject: Palette changes on redraw From: Peter Dalgaard BSA Date: 08 Aug 2001 19:08:01 +0200 Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Try this example(palette) then trigger a redraw e.g. by resizing the window. Shouldn't the palette be stored as part of the display list? (This only happens because the palette was reset at the end of the example, but still...) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1045.reply.1 <== From ihaka@stat.auckland.ac.nz Wed Aug 8 22:36:29 2001 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4] (may be forged)) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA12009; Wed, 8 Aug 2001 22:36:26 +0200 (MET DST) Received: from stat1.stat.auckland.ac.nz (stat1.stat.auckland.ac.nz [130.216.93.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA21626; Thu, 9 Aug 2001 08:36:20 +1200 (NZST) Received: from stat.auckland.ac.nz (g.ihaka.slip.auckland.ac.nz [130.216.9.243]) by stat1.stat.auckland.ac.nz (8.10.2+Sun/8.8.8) with ESMTP id f78KaJ720404; Thu, 9 Aug 2001 08:36:19 +1200 (NZST) Sender: ihaka@stat.auckland.ac.nz Message-ID: <3B71A31A.8BB29F85@stat.auckland.ac.nz> Date: Thu, 09 Aug 2001 08:37:46 +1200 From: Ross Ihaka Organization: University of Auckland X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: p.dalgaard@biostat.ku.dk CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Palette changes on redraw (PR#1045) References: <200108081708.TAA11359@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit p.dalgaard@biostat.ku.dk wrote: > > Try this > > example(palette) > > then trigger a redraw e.g. by resizing the window. Shouldn't the > palette be stored as part of the display list? > > (This only happens because the palette was reset at the end of the > example, but still...) I could argue either way on this. I agree that its nasty to have plot colours change in mid-stream, but I suspect that adding the palette to the display list may not be the "right" solution. A different approach would be to map the colour indices (and names) to RGB values at a slightly higher level. That way it would be the RGB values which would be captured in the display list, not the indices. [ I'm afraid that I think that the whole display list mechanism is "wrong". We need a much higher level way of describing plots. ] Ross ==> 1045.audit <== Sat Aug 11 09:57:42 2001 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1147 * Subject: postscript problem From: kjetil halvorsen Date: Fri, 26 Oct 2001 15:23:45 -0400 --This seems to be a problem with screen/layout rather than postscript. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1147 <== From postmaster@franz.stat.wisc.edu Fri Oct 26 21:23:17 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA03528 for ; Fri, 26 Oct 2001 21:23:16 +0200 (MET DST) Received: from jupiter.umsanet.edu.bo (really [166.114.17.11]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 26 Oct 2001 14:23:11 -0500 (CDT) Received: from umsanet.edu.bo (pc69.umsanet.edu.bo [166.114.17.69]) by jupiter.umsanet.edu.bo (8.11.0/8.9.3) with ESMTP id f9QJZjK01812 for ; Fri, 26 Oct 2001 15:35:47 -0400 Message-ID: <3BD9B841.215F6DB3@umsanet.edu.bo> Date: Fri, 26 Oct 2001 15:23:45 -0400 From: kjetil halvorsen Reply-To: kjetilh@umsanet.edu.bo Organization: UMSA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs@r-project.org Subject: postscript problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I reported this earlier, and have got reports that others have the same promlem on UNIX machines, so it is not only a windows problem S I file a bug report. The function (boot.stat) given at the end produces a postscript file, which cannot be included correctly in LaTeX. Specifically, the image in LaTeX (when translated by dvips to postscript) becomes very small, not using the bounding box, and turned on its head! Kjetil Halvorsen boot.stat <- function (x, B = 1000, norm = FALSE) { xname <- deparse(substitute(x)) means <- meds <- numeric(B) for (i in 1:B) { s <- sample(x, replace = TRUE) means[i] <- mean(s) meds[i] <- median(s) } CImedian <- quantile(meds, c(0.025, 0.5, 0.975)) CImean <- quantile(means, c(0.025, 0.5, 0.975)) hmean <- hist(means, freq = FALSE, plot = FALSE) hmeds <- hist(meds, freq = FALSE, plot = FALSE) split.screen(c(1, 2)) xlims <- range(c(hmean$breaks, hmeds$breaks)) ymax <- max(c(hmean$density, hmeds$density)) screen(1) plot(hmean, freq = FALSE, col = "red", xlim = xlims, ylim = c(0, ymax), xlab = paste("Sampling dist. of mean of ", xname), main = "") if (norm) { n <- length(x) mu <- mean(x) sd <- sqrt(var(x)/n) ps <- seq(xlims[1], xlims[2], len = 100) lines(ps, dnorm(ps, mu, sd), col = "darkgreen") } lines(CImean, rep(ymax/2, 3)) points(CImean[2], ymax/2, cex = 2, col = "black") screen(2) plot(hmeds, freq = FALSE, col = "lightblue", xlim = xlims, ylim = c(0, ymax), xlab = paste("Sampling dist. of median of ", xname), main = "") if (norm) { n <- length(x) p <- 1/2 mu <- median(x) d <- density(x, n = 1, from = mu, to = mu)$y sd <- sqrt(p * (1 - p)/n)/d ps <- seq(xlims[1], xlims[2], len = 100) lines(ps, dnorm(ps, mu, sd), col = "darkgreen") } lines(CImedian, rep(ymax/2, 3)) points(CImedian[2], ymax/2, cex = 2, col = "black") names(B) <- "Number of bootstrap replicactions" invisible(list(CImean = CImean, CImedian = CImedian, B, means = means, meds = meds)) } call with for example boot.stat( rnorm(100), norm=TRUE) ==> 1147.audit <== Wed Oct 31 15:17:18 2001 ripley changed notes Wed Oct 31 15:17:18 2001 ripley foobar Wed Oct 31 15:17:18 2001 ripley moved from incoming to Graphics ==> 1147.followup.1 <== From postmaster@franz.stat.wisc.edu Thu Feb 7 16:39:12 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA05430 for ; Thu, 7 Feb 2002 16:39:09 +0100 (MET) Received: from jupiter.umsanet.edu.bo (really [166.114.17.11]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Thu, 7 Feb 2002 09:38:36 -0600 (CST) Received: from umsanet.edu.bo (antiguo31.umsanet.edu.bo [192.168.14.31]) by jupiter.umsanet.edu.bo (8.11.0/8.9.3) with ESMTP id g17FqWW23666 for ; Thu, 7 Feb 2002 11:52:33 -0400 Message-ID: <3C629F2F.71DBBE02@umsanet.edu.bo> Date: Thu, 07 Feb 2002 11:37:19 -0400 From: kjetil halvorsen Reply-To: kjetilh@umsanet.edu.bo Organization: UMSA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs@r-project.org Subject: PR# 1147 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 328 Status: RO Apropops todays automatic bug report: The bug #1147 I reported (postscript, problems with screen layout) which I treported some time ago, does not anymore occur R1.4.0, windows 98, when I test with the same code that caused the original problem. Fixed as a by-product of the internal changes to graphics code? Kjetil Halvorsen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1161 * Subject: x-axis label in persp() From: Rolf Turner Date: Wed, 7 Nov 2001 18:07:22 +0800 (WST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1161 <== From postmaster@franz.stat.wisc.edu Wed Nov 7 11:07:32 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA22526 for ; Wed, 7 Nov 2001 11:07:32 +0100 (MET) Received: from madvax.maths.uwa.edu.au (really [130.95.16.1]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Wed, 7 Nov 2001 04:07:26 -0600 (CST) Received: from salvia.maths.uwa.edu.au (salvia.maths.uwa.edu.au [130.95.16.72]) by madvax.maths.uwa.edu.au (8.12.0/8.12.0) with ESMTP id fA7A7M7Z209411 for ; Wed, 7 Nov 2001 18:07:23 +0800 (WST) From: Rolf Turner Date: Wed, 7 Nov 2001 18:07:22 +0800 (WST) Message-Id: <200111071007.SAA21120@salvia.maths.uwa.edu.au> To: r-bugs@r-project.org Subject: x-axis label in persp() If the surface to be plotted by persp() is supplied as a list, the x-axis label defaults to the name, in the call, of this list --- which is usually silly. I would suggest changing the first four lines of persp.default() (where the x-axis label gets set) from if (is.null(xlab)) xlab <- if (!missing(x)) deparse(substitute(x)) else "X" to if (is.null(xlab)) xlab <- if (!missing(x) && !is.list(x) && !is.matrix(x)) deparse(substitute(x)) else "X" which makes the x-axis label default to "X" if the surface is specified as a list. cheers, Rolf Turner Current email address: rolf@maths.uwa.edu.au Usual email address: rolf@math.unb.ca ==> 1161.audit <== Sun Nov 11 17:22:03 2001 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1235 * Subject: Axes labelling with logarithmic scales From: tobias.hoevekamp@ilw.agrl.ethz.ch Date: Thu, 3 Jan 2002 15:29:02 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1235 <== From tobias.hoevekamp@ilw.agrl.ethz.ch Thu Jan 3 15:29:03 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA25589 for ; Thu, 3 Jan 2002 15:29:02 +0100 (MET) Date: Thu, 3 Jan 2002 15:29:02 +0100 (MET) From: tobias.hoevekamp@ilw.agrl.ethz.ch Message-Id: <200201031429.PAA25589@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Axes labelling with logarithmic scales Full_Name: Tobias Hoevekamp Version: 1.4.0 OS: Debian GNU/Linux Submission from: (NULL) (129.132.139.109) There seems to be a problem with the labelling of axes when logarithmic scales are used. More than half of both axes are not labeled in the following example: x <- c(0.12, 0.3, 0.53, 1.1, 1.8, 2.6, 4.5) y <- c(0.012, 0.021, 0.032, 0.055, 0.1, 0.2, 0.35) plot(x, y, log="xy", main="Problem with axes labelling on logarithmic scales", xlab="x, why aren't 0.5, or even smaller tic-values displyed?", ylab="y, why isn't 0.05 diplayed?") ==> 1235.audit <== Mon Jan 7 10:33:27 2002 ripley foobar Mon Jan 7 10:33:27 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1395 * Subject: mgp parameter in par() From: mh.smith@niwa.cri.nz Date: Tue, 19 Mar 2002 06:11:49 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1395 <== From mh.smith@niwa.cri.nz Tue Mar 19 06:11:51 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id GAA29491 for ; Tue, 19 Mar 2002 06:11:49 +0100 (MET) Date: Tue, 19 Mar 2002 06:11:49 +0100 (MET) From: mh.smith@niwa.cri.nz Message-Id: <200203190511.GAA29491@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: mgp parameter in par() Full_Name: Murray H Smith Version: 1.4.1 OS: Windows 2000 Submission from: (NULL) (202.36.29.1) The mgp parameter in par() does not allow negative values. That is, it does not allow plots with axes ticks and labels inside the plot. The help document, Introduction to R, under Graphics: Axes and tick marks, specifically mentions negative values for mgp as a way to achieve internal ticks and labels. Code: > par(mgp=c(-3,-1,0)) Error in par(mgp = c(-3, -1, 0)) : invalid value specified for graphics parameter "mgp" > par(mgp=c(3,-1,0)) Error in par(mgp = c(3, -1, 0)) : invalid value specified for graphics parameter "mgp". > par(mgp=c(3,1,-1)) Error in par(mgp = c(3, 1, -1)) : invalid value specified for graphics parameter "mgp". > par(mgp=c(-3,1,0)) Error in par(mgp = c(-3, 1, 0)) : invalid value specified for graphics parameter "mgp". ==> 1395.audit <== Wed Mar 20 09:15:03 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1505 * Subject: pictex From: luchini@ehess.cnrs-mrs.fr Date: Thu, 2 May 2002 12:23:21 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1505 <== From luchini@ehess.cnrs-mrs.fr Thu May 2 12:23:22 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA03886 for ; Thu, 2 May 2002 12:23:21 +0200 (MET DST) Date: Thu, 2 May 2002 12:23:21 +0200 (MET DST) From: luchini@ehess.cnrs-mrs.fr Message-Id: <200205021023.MAA03886@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: pictex Full_Name: Stephane Luchini Version: 1.4.1 OS: Redhat 7.2 Submission from: (NULL) (193.50.233.43) I want to use R to plot an histogram of a vector of size 759 with min=-63260e+06 and max=3.700646. When I use X11 as the output device, there is no problem to obtain the desired graphics using the following instructions: hist(VED,br=60,prob=TRUE) lines(density(VED,bw=7.668e+05)) Now, if I use the pictex driver : pictex(file = "test.pictex") The whole pictex code is not generated. It stops after line 760. When I put debug = TRUE, it stops after 243 lines. ==> 1505.audit <== Tue May 7 09:07:02 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1654 * Subject: R 1.5.0: axis() does not honor the xaxp argument From: "Robert D. Merithew" Date: Tue, 11 Jun 2002 09:29:39 -0400 (EDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1654 <== From postmaster@franz.stat.wisc.edu Tue Jun 11 16:33:40 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA04905 for ; Tue, 11 Jun 2002 16:33:40 +0200 (MET DST) Received: from mercury.ccmr.cornell.edu (really [128.84.231.97]) by franz.stat.wisc.edu via smail with esmtp (ident 0 using rfc1413) id (Debian Smail3.2.0.114) for ; Tue, 11 Jun 2002 09:25:39 -0500 (CDT) Received: from magic.ccmr.cornell.edu (IDENT:0@magic.ccmr.cornell.edu [128.84.231.181]) by mercury.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id JAA21476 for ; Tue, 11 Jun 2002 09:33:13 -0400 Received: from localhost (merithew@localhost) by magic.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id JAA12487 for ; Tue, 11 Jun 2002 09:29:39 -0400 X-Authentication-Warning: magic.ccmr.cornell.edu: merithew owned process doing -bs Date: Tue, 11 Jun 2002 09:29:39 -0400 (EDT) From: "Robert D. Merithew" Reply-To: rdm28@cornell.edu To: r-bugs@r-project.org Subject: R 1.5.0: axis() does not honor the xaxp argument Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ----------------------- transcript -------------------------- $ R --vanilla R : Copyright 2002, The R Development Core Team Version 1.5.0 (2002-04-29) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type `license()' or `licence()' for distribution details. R is a collaborative project with many contributors. Type `contributors()' for more information. Type `demo()' for some demos, `help()' for on-line help, or `help.start()' for a HTML browser interface to help. Type `q()' to quit R. > plot(c(0,1),c(0.2,0.3),xaxt="n") > axis(1,xaxp=c(0,1,4)) > version _ platform i586-pc-linux-gnu arch i586 os linux-gnu system i586, linux-gnu status major 1 minor 5.0 year 2002 month 04 day 29 language R > ------------------------end transcript --------------------- I expect only 4 intervals on the x-axis, but find 5 intervals. The same problem seems to exist for axis() with a yaxp argument. The sequence: > plot(c(0,1),c(0.2,0.3),xaxt="n") > par(xaxp=c(0,1,4)) > axis(1) does draw an axis with four intervals, though. On R-Help, in response to my question about this, Paul Murrell wrote: > This appears to be a bug. axis() should respond to an "in-line" xaxp > setting. > > I can see a place in the C code where the problem appears to be, but an > attempted quick fix failed. > > Could you please submit a bug report so that I (or someone else) will > remember to have a proper look later? > > Thanks > > Paul Thanks, -- Robert Merithew ==> 1654.followup.1 <== From p.murrell@auckland.ac.nz Wed Jun 12 00:04:30 2002 Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.191.4] (may be forged)) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id AAA06582 for ; Wed, 12 Jun 2002 00:04:28 +0200 (MET DST) Received: from stat1.stat.auckland.ac.nz (stat1.stat.auckland.ac.nz [130.216.93.1]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA25770 for ; Wed, 12 Jun 2002 10:03:45 +1200 (NZST) Received: from stat.auckland.ac.nz (murrell.stat.auckland.ac.nz [130.216.50.118]) by stat1.stat.auckland.ac.nz (8.11.6+Sun/8.8.8) with ESMTP id g5BM3jI03971; Wed, 12 Jun 2002 10:03:45 +1200 (NZST) Message-ID: <3D067451.59949C1C@stat.auckland.ac.nz> Date: Wed, 12 Jun 2002 10:06:09 +1200 From: Paul Murrell X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: R-bugs@biostat.ku.dk Subject: Re: R 1.5.0: axis() does not honor the xaxp argument (PR#1654) References: <200206111433.QAA04910@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi > ----------------------- transcript -------------------------- > $ R --vanilla > > R : Copyright 2002, The R Development Core Team > Version 1.5.0 (2002-04-29) > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to redistribute it under certain conditions. > Type `license()' or `licence()' for distribution details. > > R is a collaborative project with many contributors. > Type `contributors()' for more information. > > Type `demo()' for some demos, `help()' for on-line help, or > `help.start()' for a HTML browser interface to help. > Type `q()' to quit R. > > > plot(c(0,1),c(0.2,0.3),xaxt="n") > > axis(1,xaxp=c(0,1,4)) > > version > _ > platform i586-pc-linux-gnu > arch i586 > os linux-gnu > system i586, linux-gnu > status > major 1 > minor 5.0 > year 2002 > month 04 > day 29 > language R > > > ------------------------end transcript --------------------- > > I expect only 4 intervals on the x-axis, but find 5 intervals. The same > problem seems to exist for axis() with a yaxp argument. > > The sequence: > > > plot(c(0,1),c(0.2,0.3),xaxt="n") > > par(xaxp=c(0,1,4)) > > axis(1) > > does draw an axis with four intervals, though. > > On R-Help, in response to my question about this, Paul Murrell > wrote: > > > This appears to be a bug. axis() should respond to an "in-line" xaxp > > setting. > > > > I can see a place in the C code where the problem appears to be, but an > > attempted quick fix failed. For the record, the place in the C code is in plot.c in do_axis where there appear to be two problems: (i) the code sets a local variable from the dpptr(dd)->xaxp rather than the gpptr(dd)->xaxp, and (ii) the code sets this local variable BEFORE calling ProcessInlinePars(). So there are two obstacles to fix before do_axis will respond to an in-line xaxp setting. NOTE also that several other local variables are set from dpptr(dd)-> in the same place, so these should be fixed as well. Paul ==> 1654.audit <== Wed Jun 12 17:36:35 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1659 * Subject: mtext() alignment of perpendicular text From: p.murrell@auckland.ac.nz Date: Wed, 12 Jun 2002 13:29:45 +1200 (NZST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1659 <== From postmaster@franz.stat.wisc.edu Wed Jun 12 03:30:31 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id DAA06869 for ; Wed, 12 Jun 2002 03:30:30 +0200 (MET DST) Received: from mailhost2.auckland.ac.nz (really [130.216.191.4]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Tue, 11 Jun 2002 20:29:48 -0500 (CDT) Received: from stat1.stat.auckland.ac.nz (stat1.stat.auckland.ac.nz [130.216.93.1]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA27667 for ; Wed, 12 Jun 2002 13:29:46 +1200 (NZST) Received: (from paul@localhost) by stat1.stat.auckland.ac.nz (8.11.6+Sun/8.8.8) id g5C1TjS23236; Wed, 12 Jun 2002 13:29:45 +1200 (NZST) Date: Wed, 12 Jun 2002 13:29:45 +1200 (NZST) Message-Id: <200206120129.g5C1TjS23236@stat1.stat.auckland.ac.nz> From: p.murrell@auckland.ac.nz To: r-bugs@r-project.org Cc: paul@stat1.stat.auckland.ac.nz Subject: mtext() alignment of perpendicular text mtext() does a poor job of placing text when it is perpendicular (e.g., side=1, las=3) and the font size is not the default. The following code snippet demonstrates the problem ... plot(1:10) abline(v=1:10, col="grey") axis(3, at=1:10, las=3, labels=FALSE) mtext(1:10, at=1:10, side=3, line=1, las=3) axis(3, line=-2, at=1:10, las=3, labels=FALSE) mtext(1:10, at=1:10, side=3, line=-1, las=3, cex=.5) axis(3, line=-5, at=1:10, las=3, labels=FALSE) mtext(1:10, at=1:10, side=3, line=-4, las=3, cex=2) The ugliness varies a bit across devices. In GMtext() in graphics.c there is a hardcoded adjustment of 0.3 which is described as "purely visual tuning". I think this needs to be replaced with a more general solution. Paul --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = Under development (unstable) major = 1 minor = 6.0 year = 2002 month = 06 day = 10 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base ==> 1659.audit <== Wed Jun 12 17:36:35 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1878 * Subject: close.screen From: Martin.Schlather@uni-bayreuth.de Date: Mon, 5 Aug 2002 22:35:02 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1878 <== From Martin.Schlather@uni-bayreuth.de Mon Aug 5 22:35:03 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA18778 for ; Mon, 5 Aug 2002 22:35:02 +0200 (MET DST) Date: Mon, 5 Aug 2002 22:35:02 +0200 (MET DST) From: Martin.Schlather@uni-bayreuth.de Message-Id: <200208052035.WAA18778@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: close.screen Full_Name: Martin Schlather Version: 1.5.1 OS: Linux Submission from: (NULL) (132.180.72.150) Hi, As a user it is not obvious to me why "close.screen" should return a warning message in split.screen(figs=c(1,2)) i <- 2  screen(i) close.screen(i) whereas no warning message appears for i <- 1. In fact, the warning message appears since the condition .split.valid.screens > temp in close.screen is not satisfied by any element of .split.valid.screens Replacing if (temp %in% n) temp <- min(.split.valid.screens[.split.valid.screens > temp]) if (temp > max(.split.valid.screens)) temp <- min(.split.valid.screens) by if (temp > max(.split.valid.screens)) temp <- min(.split.valid.screens) else if (temp %in% n) temp <- min(.split.valid.screens[.split.valid.screens > temp]) should avoid the warning message without any other changings in the functionality of close.screen. Cheers, Martin ==> 1878.audit <== Thu Aug 8 09:04:26 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1933 * Subject: dev2eps() prints ticks with wrong length! From: Timur Elzhov Date: Fri, 23 Aug 2002 17:22:15 +0400 --dev.copy problem ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1933 <== From postmaster@franz.stat.wisc.edu Fri Aug 23 15:15:27 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA23911 for ; Fri, 23 Aug 2002 15:15:26 +0200 (MET DST) Received: from nfsun5.jinr.ru (really [159.93.21.8]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 23 Aug 2002 08:14:46 -0500 (CDT) Received: from pcf004.jinr.ru (pcf004.jinr.ru [159.93.29.4]) by nfsun5.jinr.ru (8.11.2/8.11.6) with ESMTP id g7NDEZX20985 for ; Fri, 23 Aug 2002 17:14:36 +0400 (MSK-DST) Received: from etv by pcf004.jinr.ru with local (Exim 3.32 #1 (Debian)) id 17iEOH-0003OH-00 for ; Fri, 23 Aug 2002 17:22:17 +0400 Date: Fri, 23 Aug 2002 17:22:15 +0400 From: Timur Elzhov To: r-bugs@r-project.org Subject: dev2eps() prints ticks with wrong length! Message-ID: <20020823132214.GA13023@pcf004.jinr.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4i Sender: Timur Elzhov Hello R experts! I've tried to make single plot, but with changed ticks length, and then copy them to file by dev.copy2eps(). Here is the code: x11 ( , 5, 5) par (tcl = +5) plot (0) # that's ugly plot with great ticks # on the graph viewport. cool :) dev.copy2eps (file = "out.eps") Hm.. I had a look at "out.ps" and wondered that ticks look like as they would being set to there *default* value, "tcl" = -0.5! =-O Ok, I tried then to make same thing by slightly different way: postscript (file = "out1.eps", onefile = FALSE) par (tcl = +5) plot (0) dev.off () Beautiful -- all the ticks have an appropriate length, tcl == +5! Why? -------------- == -------------- R> version _ platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major 1 minor 5.1 -------------- == -------------- With best regards, Timur V. Elzhov ==> 1933.audit <== Sun Aug 25 11:54:31 2002 ripley changed notes Sun Aug 25 11:54:31 2002 ripley foobar Sun Aug 25 11:54:31 2002 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2069 * Subject: split.screen problem From: cbodily@att.net Date: Thu, 26 Sep 2002 19:37:40 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2069 <== From cbodily@att.net Thu Sep 26 19:37:41 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA21297 for ; Thu, 26 Sep 2002 19:37:40 +0200 (MET DST) Date: Thu, 26 Sep 2002 19:37:40 +0200 (MET DST) From: cbodily@att.net Message-Id: <200209261737.TAA21297@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: split.screen problem Full_Name: Chris Bodily Version: 1.5.1 OS: W2K Submission from: (NULL) (63.106.106.2) I took the following code directly from the 'split.screen' help page in R and modified one line to highlight the problem I encountered. Basically, it appears that when plotting in split screens and attempting to return to a particular screen to add or update points, the axes from the original plot are not remembered, causing the new points to plot incorrectly. A workaround seem to be storing the original plot range and issuing 'plot(x,y,type="n")' where x and y are data vectors with ranges that match the original plot in the screen of interest. Then a 'points' command draws in the correct locations. I found this by moving working code from S-Plus 2000 into R v1.5.1 and noticed that a particular interactive plot I use began drawing incorrectly. Thanks, Chris Bodily #-------------------------------------------------------------------------------------- if (interactive()) { par(bg = "white") # default is likely to be transparent split.screen(c(2,1)) # split display into two screens split.screen(c(1,2),2) # split bottom half in two plot(1:10) # screen 3 is active, draw plot erase.screen() # forgot label, erase and redraw plot(1:10, ylab= "ylab 3") screen(1) # prepare screen 1 for output plot(1:10) screen(4) # prepare screen 4 for output plot(1:10, ylab="ylab 4") screen(1, FALSE) # return to screen 1, but do not clear # plot(10:1,axes=FALSE, pch=2,col=5, lty=2, ylab="") # overlay second plot ## Problem here as the following points get plotted incorrectly ## ## it seems that the axes are reset ## points(rep(3,10),1:10,col=2,pch=2) # add a few more points for a test axis(4) # add tic marks to right-hand axis title("Plot 1") close.screen(all = TRUE) # exit split-screen mode } ==> 2069.audit <== Tue Oct 1 00:20:40 2002 thomas moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2283 * Subject: Wandering usr values in par(no.readonly=TRUW) From: Jari Oksanen Date: Tue, 12 Nov 2002 13:50:44 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2283 <== From jarioksa@pc112145.oulu.fi Tue Nov 12 12:51:40 2002 Received: from franz.stat.wisc.edu (mail@www.omegahat.org [128.105.174.32]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA07314 for ; Tue, 12 Nov 2002 12:51:39 +0100 (MET) Received: from pc112145.oulu.fi ([130.231.112.145] ident=[s96AW+1Zs9cPBqGskCg5J6XRkFQbLqG1]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 18BZZG-0003mQ-00 for ; Tue, 12 Nov 2002 05:50:54 -0600 Received: from pc112145.oulu.fi (jarioksa@localhost) by pc112145.oulu.fi (8.11.6/8.11.6) with ESMTP id gACBojB14813 for ; Tue, 12 Nov 2002 13:50:45 +0200 Message-Id: <200211121150.gACBojB14813@pc112145.oulu.fi> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: r-bugs@r-project.org X-Face: #1;E;(IH&rRlD$\T&b}/by1WC%wv7r>$1u@~pvXzPr(bZ,*,8?599t;]Ue=S@~'(F$Ah{m; BM$8X.TeSEUi_~Qi(O?JlUI$0q"}Vt#6j*0I'**nSd+QtbA:I>U-%j0?%E=WxEA~!41E".)PPt:%*X U/exl1Z5QF(f65[(R+V/QccPRZgw1sracNQTeLL=j2?fYdu-z --==_Exmh_1801894504P Content-Type: text/plain; charset=us-ascii Dear R folks, Initially I had a plotting routine using logarithmic y-axes that failed after repeated calls if I tried to restore the graphical parameters (which I wanted to do because I used `layout' within the routine. I tried to isolate the problem and found out that the following code with logarithmic axis is sufficient for reproducing the failure: > plot2.log function (x=1:2,y=1:2) { op <- par(no.readonly=TRUE) on.exit(par(op)) cat(op$usr, "\n") plot(x, y, log="y") #par(op) invisible(op) } Here is a session with the typical error message (Infinite axis extents): > op <- par(no.readonly=TRUE) > op$usr [1] 0 1 0 1 > plot2.log()$usr 0 1 0 1 [1] 0 1 0 1 > plot2.log()$usr 0 1 1 10 [1] 0 1 1 10 > plot2.log()$usr 0 1 10 1e+10 Error in par(op) : Infinite axis extents [GPretty(1e+10,inf,5)] So this happens only with a repeated call to logarithmic axes. I found out this feature sometimes back in R-1.5*, but I regarded that as my own bug. It started to disturb me yesterday when I had a live R session in my lectures, and got to edit away the par-restoring code to continue. Best wishes, Jari Oksanen --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 6.1 year = 2002 month = 11 day = 01 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base -- Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061 email jari.oksanen@oulu.fi, homepage http://cc.oulu.fi/~jarioksa/ --==_Exmh_1801894504P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE90OsUWnxFzE9NjaURAcwSAJwJdXXP/qgUyCFahR4GsWbBxVl0YACeKBPe AFIwTfrg/l7H0fr0HJONcaI= =mkza -----END PGP SIGNATURE----- --==_Exmh_1801894504P-- ==> 2283.audit <== Wed Nov 13 00:07:23 2002 thomas moved from incoming to Graphics ==> 2283.reply.1 <== From maechler@stat.math.ethz.ch Wed Nov 13 18:48:25 2002 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA23631 for ; Wed, 13 Nov 2002 18:48:24 +0100 (MET) Received: from lynne.ethz.ch (IDENT:root@lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.6/8.12.6) with ESMTP id gADHldL9004377; Wed, 13 Nov 2002 18:47:39 +0100 (MET) Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id gADHlcO21499; Wed, 13 Nov 2002 18:47:38 +0100 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15826.36921.839490.28287@gargle.gargle.HOWL> Date: Wed, 13 Nov 2002 18:47:37 +0100 To: R-bugs@stat.math.ethz.ch Cc: , Subject: RE: Wandering usr values in par(no.readonly=TRUE) (PR#2283) In-Reply-To: <008f01c28b36$5ccf75b0$0201a8c0@MARC> References: <008f01c28b36$5ccf75b0$0201a8c0@MARC> X-Mailer: VM 7.07 under Emacs 21.2.1 Reply-To: Martin Maechler >>>>> "Marc" == Marc Schwartz >>>>> on Wed, 13 Nov 2002 11:01:49 -0600 writes: Marc> Marc Schwartz wrote: >> SNIP >> >> I am guessing that this may be the result of par("ylog") >> and par("xlog") being read only and perhaps impacting the >> restoration of the par("usr") values when the plotting >> device is still open, but that may be incorrect. Marc> In follow up to my own note from last evening on this Marc> and now that I have had a couple of cups of coffee Marc> this morning, I need to partially correct my above Marc> statement and point to a presumed typo in the ?par Marc> help file. For confirmation, this is R 1.6.1 under Marc> WinXP Pro. Marc> par("xlog") and par("ylog") are not Read Only Marc> parameters as listed in the help file and can be set Marc> by the user. Indeed this is confirmed in the comments Marc> in par.r: Marc> #.Pars.readonly <- c("cin","cra","csi","cxy","din") Marc> I noted this today as I was comparing the output of Marc> par() with par(no.readonly = TRUE) and noted that the Marc> latter returns '$xlog' and $ylog' as being Marc> settable. The other 5 par values listed in ?par as Marc> "R.O." (cin, cra, csi, cxy and din) return errors when Marc> one attempts to set them with par(args), however xlog Marc> and ylog do not. Yes, indeed, and I -- as an R-core member -- am astonished:. I didn't know it really worked, but it does, e.g., > plot(1:10); par("usr") [1] 0.64 10.36 0.64 10.36 > par(xlog = TRUE); par(c("xlog","usr")) $xlog [1] TRUE $usr [1] -0.1938200 1.0153598 0.6400000 10.3600000 > points(10^(1:9), 1 + 1:9, col = "red") # draws red points above I'm now re-directing this back to R-bugs to make sure that the only (right?) remaining bug, documentation in par.Rd, will be fixed -- and hope to close this as a bug report. Marc> .......... Marc> Thank you Marc! Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ==> 2283.followup.1 <== From mschwartz@medanalytics.com Wed Nov 13 20:09:33 2002 Received: from mail7.atl.registeredsite.com (nobody@mail7.atl.registeredsite.com [64.224.219.81]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA23868 for ; Wed, 13 Nov 2002 20:09:32 +0100 (MET) Received: from mail.medanalytics.com (mail.medanalytics.com [64.225.164.192]) by mail7.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id gADJ8jjx025585; Wed, 13 Nov 2002 14:08:45 -0500 Received: from MARC [64.225.164.192] by mail.medanalytics.com with ESMTP (SMTPD32-6.06) id A33BDAD400F0; Wed, 13 Nov 2002 14:08:43 -0500 Reply-To: From: "Marc Schwartz" To: , Cc: Subject: RE: Wandering usr values in par(no.readonly=TRUE) (PR#2283) Date: Wed, 13 Nov 2002 13:08:42 -0600 Organization: MedAnalytics, Inc. Message-ID: <000201c28b48$15c93810$0201a8c0@MARC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200211131748.SAA23636@pubhealth.ku.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id UAA23868 Martin wrote: > SNIP > > Thank you Marc! Glad to be of help Martin. For the sake of completeness, I ran the same examples on my Linux (RH 8) install of R 1.6.1 and observed the same behavior. Best regards, Marc Schwartz ==> 2283.followup.2 <== From mschwartz@medanalytics.com Thu Nov 14 00:06:53 2002 Received: from mail11.atl.registeredsite.com (nobody@mail11.atl.registeredsite.com [64.224.219.85]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id AAA24689 for ; Thu, 14 Nov 2002 00:06:52 +0100 (MET) Received: from mail.medanalytics.com (mail.medanalytics.com [64.225.164.192]) by mail11.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id gADN64ii008429; Wed, 13 Nov 2002 18:06:05 -0500 Received: from MARC [64.225.164.192] by mail.medanalytics.com with ESMTP (SMTPD32-6.06) id AADAF334002C; Wed, 13 Nov 2002 18:06:02 -0500 Reply-To: From: "Marc Schwartz" To: , Cc: Subject: RE: Wandering usr values in par(no.readonly=TRUE) (PR#2283) Date: Wed, 13 Nov 2002 17:06:00 -0600 Organization: MedAnalytics, Inc. Message-ID: <001901c28b69$3cbef650$0201a8c0@MARC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200211131748.SAA23636@pubhealth.ku.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id AAA24689 Martin wrote: > I'm now re-directing this back to R-bugs to make sure that > the only (right?) remaining bug, documentation in par.Rd, > will be fixed -- and hope to close this as a bug report. Martin, My apologies, as I may have missed this in my first reading of your reply, but I wanted to be sure that it was clear that there are two separate bugs here. The first, which I found this morning in the process of tracking down Jari's issue and the second which Jari observed in his initial post, which started this thread yesterday. Bug 1. The documentation in par.Rd needs to be corrected in that par("xlog") and par("ylog") are not R.O. I presume that this is what you are referring to above. Bug 2. The improper restoration of par("usr") from saved values after using log scaled axes. This is a result of the sequence of the code in the par.c Specify() function (ie. par("usr") being set before par("xlog") and par("ylog") are being set back to FALSE). Possible solutions: A. The code in par.c needs to be changed (possibly as I suggested earlier) to enable the proper restoration of par("usr") after log scaled axes are used OR B. If this is not possible due to causing other problems, par.Rd needs to have a warning note added to inform users that par("usr") will not be properly restored after log scales are used and that a possible solution would be to explicitly set par(xlog = FALSE) and par(ylog = FALSE) before restoring 'par' from saved values. This solution of course falls short if a function using this approach exits prematurely. One could include code in the on.exit() function to reset 'xlog' and 'ylog' before restoring 'par'. For example, using Jari's initial function plot2.log(): plot2.log <- function(x=1:2,y=1:2) { op <- par(no.readonly = TRUE) exit.restore <- function() { par(xlog =FALSE) par(ylog = FALSE) par(op) } on.exit(exit.restore()) plot(x, y, log = "y") } Again, my apologies if I am mis-reading the section from your reply above. Regards, Marc Schwartz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2630 * Subject: plot() with type="s" and lty=2 From: jerome@hivnet.ubc.ca Date: Wed, 12 Mar 2003 23:35:59 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2630 <== From jerome@hivnet.ubc.ca Wed Mar 12 23:35:59 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2CMZxn9021097 for ; Wed, 12 Mar 2003 23:35:59 +0100 (MET) Date: Wed, 12 Mar 2003 23:35:59 +0100 (MET) Message-Id: <200303122235.h2CMZxn9021097@pubhealth.ku.dk> From: jerome@hivnet.ubc.ca To: R-bugs@biostat.ku.dk Subject: plot() with type="s" and lty=2 Full_Name: Jerome Asselin Version: 1.6.2 OS: RedHat Linux 7.2 Submission from: (NULL) (142.103.173.179) In the following example, the line type lty=2 does not show properly across the entire line. x <- c(seq(0,.5,.001),seq(.6,1,.1)) y <- rep(1,length(x)) plot(x,y,type="s",lty=2) Sincerely, Jerome Asselin ==> 2630.followup.1 <== From gb@stat.umu.se Thu Mar 13 08:33:26 2003 Received: from tal.stat.umu.se (tal.stat.umu.se [130.239.56.32]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2D7XQn9023441 for ; Thu, 13 Mar 2003 08:33:26 +0100 (MET) Received: from tal.stat.umu.se (localhost.localdomain [127.0.0.1]) by tal.stat.umu.se (8.12.8/8.12.8) with ESMTP id h2D7ZhJd002147; Thu, 13 Mar 2003 08:35:43 +0100 Received: from localhost (gb@localhost) by tal.stat.umu.se (8.12.8/8.12.8/Submit) with ESMTP id h2D7Zgbg002143; Thu, 13 Mar 2003 08:35:43 +0100 X-Authentication-Warning: tal.stat.umu.se: gb owned process doing -bs Date: Thu, 13 Mar 2003 08:35:42 +0100 (CET) From: =?ISO-8859-1?Q?G=C3=B6ran_Brostr=C3=B6m?= To: jerome@hivnet.ubc.ca cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] plot() with type="s" and lty=2 (PR#2630) In-Reply-To: <200303122236.h2CMa0n9021101@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 12 Mar 2003 jerome@hivnet.ubc.ca wrote: > Full_Name: Jerome Asselin > Version: 1.6.2 > OS: RedHat Linux 7.2 > Submission from: (NULL) (142.103.173.179) > > > > In the following example, the line type lty=2 does not show properly > across the entire line. > > x <- c(seq(0,.5,.001),seq(.6,1,.1)) > y <- rep(1,length(x)) > plot(x,y,type="s",lty=2) > > Sincerely, > Jerome Asselin Right. I reported this two days ago on 'r-help' (maybe the wrong place). In the copy of my report below you also see the (a?) solution. Göran ------------------------------------------------------------------- Consider the following two ways of stair steps plotting: plo <- function(ty = 2, steps = 200){ old.par <- par(mfrow = c(2, 1)) x <- seq(1, 100, length = steps) y <- seq(1, 10, length = steps) plot(x, y, type = "s", lty = ty, main = "Stair steps") x <- rep(x, each = 2)[-1] y <- rep(y, each = 2)[-2*steps] plot(x, y, type = "l", lty = ty, main = "Line steps") par(old.par) } [...] --------------------------------------------------------------------- --- Göran Broström tel: +46 90 786 5223 Department of Statistics fax: +46 90 786 6614 Umeå University http://www.stat.umu.se/egna/gb/ SE-90187 Umeå, Sweden e-mail: gb@stat.umu.se ______________________________________________ R-help@stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > -- --- Göran Broström tel: +46 90 786 5223 Department of Statistics fax: +46 90 786 6614 Umeå University http://www.stat.umu.se/egna/gb/ SE-90187 Umeå, Sweden e-mail: gb@stat.umu.se ==> 2630.reply.1 <== From: paul murrell To: gb@stat.umu.se Subject: Re: plot() with type="s" and lty=2 (PR#2630) Date: Mon Sep 22 02:51:05 2003 Hi The problem is that type="s" is implemented in C by drawing each step as a separate polyline. This means that the line pattern starts anew for each step. If the steps are close together and the line type is, for example, "dashed", then every step starts with a dash (and ends before we get to a "gap"), so it looks like the line is being drawn solid (whereas it is in fact a whole lot of [partial] dashes drawn end-to-end). This needs a change in C code so that type="s" (and type="S" btw) effectively do the R-level workaround suggested by Goran. Paul > On Wed, 12 Mar 2003 jerome@hivnet.ubc.ca wrote: > >> Full_Name: Jerome Asselin >> Version: 1.6.2 >> OS: RedHat Linux 7.2 >> Submission from: (NULL) (142.103.173.179) >> >> >> >> In the following example, the line type lty=2 does not show properly >> across the entire line. >> >> x <- c(seq(0,.5,.001),seq(.6,1,.1)) >> y <- rep(1,length(x)) >> plot(x,y,type="s",lty=2) >> >> Sincerely, >> Jerome Asselin > > Right. I reported this two days ago on 'r-help' (maybe the wrong place). > In the copy of my report below you also see the (a?) solution. > > Göran > ------------------------------------------------------------------- > Consider the following two ways of stair steps plotting: > > plo <- function(ty = 2, steps = 200){ > old.par <- par(mfrow = c(2, 1)) > x <- seq(1, 100, length = steps) > y <- seq(1, 10, length = steps) > plot(x, y, type = "s", lty = ty, main = "Stair steps") > > x <- rep(x, each = 2)[-1] > y <- rep(y, each = 2)[-2*steps] > plot(x, y, type = "l", lty = ty, main = "Line steps") > par(old.par) > } > [...] > --------------------------------------------------------------------- > --- > Göran Broström tel: +46 90 786 5223 > Department of Statistics fax: +46 90 786 6614 > Umeå University http://www.stat.umu.se/egna/gb/ > SE-90187 Umeå, Sweden e-mail: gb@stat.umu.se > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > >> >> ______________________________________________ >> R-devel@stat.math.ethz.ch mailing list >> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel >> > > -- > --- > Göran Broström tel: +46 90 786 5223 > Department of Statistics fax: +46 90 786 6614 > Umeå University http://www.stat.umu.se/egna/gb/ > SE-90187 Umeå, Sweden e-mail: gb@stat.umu.se > > ==> 2630.audit <== Fri Mar 14 19:37:16 2003 ripley moved from incoming to Graphics Mon Sep 22 02:51:05 2003 paul sent reply 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4731 * Subject: persp - incorrect shading of triangular facets From: ihaka@stat.auckland.ac.nz Date: Thu, 23 Oct 2003 02:19:26 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4731 <== From ihaka@stat.auckland.ac.nz Thu Oct 23 02:19:27 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h9N0JQ0P018928 for ; Thu, 23 Oct 2003 02:19:26 +0200 (MET DST) Date: Thu, 23 Oct 2003 02:19:26 +0200 (MET DST) Message-Id: <200310230019.h9N0JQ0P018928@pubhealth.ku.dk> From: ihaka@stat.auckland.ac.nz To: R-bugs@biostat.ku.dk Subject: persp - incorrect shading of triangular facets Full_Name: Ross Ihaka Version: all versions containing persp OS: linux Submission from: (NULL) (130.216.191.167) When is persp is invoked on a matrix of heights which contains missing values, the surface which is drawn will contain triangular facets. The shading computations for these facets are incorrect and always produce black facets. (I plan to fix this - the report is just in case I forget or get hit by a bus). ==> 4731.audit <== Mon Nov 10 05:24:21 2003 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6758 * Subject: axis annotation issue From: dgrove@fhcrc.org Date: Tue, 13 Apr 2004 01:45:28 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6758 <== From dgrove@fhcrc.org Tue Apr 13 01:45:29 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id E6714EAC0 for ; Tue, 13 Apr 2004 01:45:28 +0200 (CEST) From: dgrove@fhcrc.org To: R-bugs@biostat.ku.dk Subject: axis annotation issue Message-Id: <20040412234528.E6714EAC0@slim.kubism.ku.dk> Date: Tue, 13 Apr 2004 01:45:28 +0200 (CEST) X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_20,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Doug Grove Version: 1.8.1 Patched (1-11-04) OS: Linux, RedHat 9.0 Submission from: (NULL) (140.107.156.61) The issue may be broader than this, but I'm finding that when I specify that the axis annotation be perpendicular to the axes, and I change the annotation size (using cex.axis) the character size inflation/deflation occurs in only one direction, from the bottom up. More precisely, if you were to plot using cex.axis all is good, but if you shrink or expand, the position of the bottom of the character(s) stay fixed and the top of the character(s) move to create the appropriate size. The end effect is a annotation that is not centered about the tick mark. In the particular case of decreasing the size, it gives the appearance that the label is shifted (I spent a few hours one day trying to "fix" my code thinking I had done something wrong). To see the issue just compare these three plots: plot(1:5, 1:5, cex.axis=1, las=2) plot(1:5, 1:5, cex.axis=.5, las=2) plot(1:5, 1:5, cex.axis=2, las=2) I'm not sure that this is a "bug", but I was not able to find a simple way to correct this behaviour. Thanks, Doug Grove ==> 6758.audit <== Fri Apr 16 18:27:52 2004 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6763 * Subject: postscript image problem From: jonathan_lees@unc.edu Date: Tue, 13 Apr 2004 23:38:56 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6763 <== From jonathan_lees@unc.edu Tue Apr 13 23:38:57 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 91E6CF123 for ; Tue, 13 Apr 2004 23:38:56 +0200 (CEST) From: jonathan_lees@unc.edu To: R-bugs@biostat.ku.dk Subject: postscript image problem Message-Id: <20040413213856.91E6CF123@slim.kubism.ku.dk> Date: Tue, 13 Apr 2004 23:38:56 +0200 (CEST) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Jonathan Lees Version: 1.8.1 OS: GNU/Linux 2.4.20-20.8smp #1 SMP Submission from: (NULL) (152.2.75.114) I am having trouble with the postscript output of images. They have lines on them that are not supposed to be there. I have noticed this on numerous trials of printing various images. I looked at the postscript and I see that it appears to plot each individual block - so perhaps occasionally the space between the blocks "leaks" through do to round off, thus contaminating the image. this could be solved if the image software used postscript image plotting functions. Here is an example of some code: postscript(file ="test.ps" , onefile=FALSE, print.it=FALSE) w<-5 #width of central square m=w xn<- 128; yn<- 128 im<- matrix(0,nrow=yn,ncol=xn) xc<-floor(xn/2)+1; yc<- floor(yn/2)+1 # centers of the image im[(-m:m)+xc,(-m:m)+yc]<- 1 image(im , col = cmap ); title('im=Original image') dev.off() view this output with any postscript viewer (or printer) and you will see extra lines on the plot. Does this bother anyone else? Joanthan Lees ==> 6763.reply.1 <== From: paul murrell To: jonathan_lees@unc.edu Subject: Re: postscript image problem (PR#6763) Date: Tue Apr 27 23:57:12 2004 Hi > Full_Name: Jonathan Lees > I am having trouble with the postscript output of images. > They have lines on them that are not supposed to be there. > I have noticed this on numerous trials of printing various images. > I looked at the postscript and I see that it > appears to plot each individual block - so perhaps occasionally the > space between the blocks "leaks" through do to round off, > thus contaminating the image. > this could be solved if the image software used postscript > image plotting functions. > > Here is an example of some code: > > postscript(file ="test.ps" , onefile=FALSE, print.it=FALSE) > > > w<-5 #width of central square > m=w > xn<- 128; yn<- 128 > im<- matrix(0,nrow=yn,ncol=xn) > xc<-floor(xn/2)+1; > yc<- floor(yn/2)+1 # centers of the image > im[(-m:m)+xc,(-m:m)+yc]<- 1 > > image(im , col = cmap ); title('im=Original image') > > > dev.off() > > view this output with any postscript viewer (or printer) > and you will see extra lines on the plot. Is this just caused by antialiasing on the postscript viewer. I see this with anti-aliasing on, but it goes away if I turn antialiasing off. Of course, that wouldn't explain the effect when a document is printed, but I don't get that. Paul ==> 6763.followup.1 <== From jonathan_lees@unc.edu Wed Apr 28 14:06:49 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id CFB15EFB8 for ; Wed, 28 Apr 2004 14:06:49 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32296-08 for ; Wed, 28 Apr 2004 14:06:48 +0200 (CEST) Received: from smtp.unc.edu (listserv0.isis.unc.edu [152.2.0.38]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 28 Apr 2004 14:06:41 +0200 (CEST) Received: from unc.edu (nanno.geosci.unc.edu [152.2.75.85]) (authenticated bits=0) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id i3SC6IMX007562 for ; Wed, 28 Apr 2004 08:06:18 -0400 (EDT) Message-ID: <408F9E39.8070809@unc.edu> Date: Wed, 28 Apr 2004 08:06:17 -0400 From: Jonathan Lees User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: paul murrell Subject: Re: postscript image problem (PR#6763) References: <20040427220105.9FDCCEFCF@slim.kubism.ku.dk> In-Reply-To: <20040427220105.9FDCCEFCF@slim.kubism.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) It is true that if you turn antialiasing off on GV then the effect seems to disappear but that is just a cosmetic thing. Other aspects of the figure are subsequently degraded, however. I am really interested in converting the postscript to good JPEG images and I can't get rid of the annoying lines when I use display or convert (in LINUX). If I could figure our how to get a good JPEG figure I would be satisfied. Thanks for any help. paul murrell wrote: >Hi > > > > >>Full_Name: Jonathan Lees >>I am having trouble with the postscript output of images. >>They have lines on them that are not supposed to be there. >>I have noticed this on numerous trials of printing various images. >>I looked at the postscript and I see that it >>appears to plot each individual block - so perhaps occasionally the >>space between the blocks "leaks" through do to round off, >>thus contaminating the image. >>this could be solved if the image software used postscript >>image plotting functions. >> >>Here is an example of some code: >> >>postscript(file ="test.ps" , onefile=FALSE, print.it=FALSE) >> >> >>w<-5 #width of central square >>m=w >>xn<- 128; yn<- 128 >>im<- matrix(0,nrow=yn,ncol=xn) >>xc<-floor(xn/2)+1; >>yc<- floor(yn/2)+1 # centers of the image >>im[(-m:m)+xc,(-m:m)+yc]<- 1 >> >>image(im , col = cmap ); title('im=Original image') >> >> >>dev.off() >> >>view this output with any postscript viewer (or printer) >>and you will see extra lines on the plot. >> >> > > >Is this just caused by antialiasing on the postscript viewer. I see this with >anti-aliasing on, but it goes away if I turn antialiasing off. Of course, that >wouldn't explain the effect when a document is printed, but I don't get that. > >Paul > > -- =============================== Jonathan M. Lees Associate Professor University of North Carolina Department of Geological Sciences CB#3315, Mitchell Hall Chapel Hill, NC 27599-3315 VOICE: (919) 962-0695 FAX: (919) 966-4519 EMAIL: jonathan.lees@unc.edu http://www.unc.edu/~leesj ==> 6763.followup.2 <== From kleiweg@let.rug.nl Wed Apr 28 14:36:12 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 559861048D for ; Wed, 28 Apr 2004 14:36:12 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32523-09 for ; Wed, 28 Apr 2004 14:36:11 +0200 (CEST) Received: from kleigh.nl (pebbe.xs4all.nl [213.84.55.218]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 28 Apr 2004 14:36:10 +0200 (CEST) Received: from kleigh.nl (localhost [127.0.0.1]) by kleigh.nl (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id i3SCa0Fw003904; Wed, 28 Apr 2004 14:36:05 +0200 Received: from localhost (peter@localhost) by kleigh.nl (8.12.3/8.12.2/Submit) with ESMTP id i3SCZmOu003901; Wed, 28 Apr 2004 14:35:54 +0200 X-Authentication-Warning: kleigh.nl: peter owned process doing -bs Date: Wed, 28 Apr 2004 14:35:48 +0200 (CEST) From: Peter Kleiweg X-X-Sender: peter@kleigh.nl To: jonathan_lees@unc.edu Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Re: postscript image problem (PR#6763) In-Reply-To: <20040428120725.D150B10481@slim.kubism.ku.dk> Message-ID: Organization: Alfa-Informatica, Rijksuniversiteit Groningen X-Accept-Language: nl,af,da,de,en,ia,nds,no,sv,fr,it X-Alert: http://www.opensource.org/halloween/ X-Face: "K~X:~!ydgSdjNy;]_+BCb\OM^pqyg_q*Le84$l46M\-mL=.^,L4B}bDK>`o#r4_>O* X-Mailer: Pine 4.44, Linux 2.4.18-64GB-SMP, i686 X-Reason: http://www.interlingua.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE, X_AUTH_WARNING version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) # aldus jonathan_lees@unc.edu : > I am really interested in converting the postscript to good JPEG images and > I can't get rid of the annoying lines when I use display or > convert (in LINUX). > If I could figure our how to get a good JPEG figure I would be > satisfied. http://odur.let.rug.nl/~kleiweg/postscript/postscript.html#conversion -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ ==> 6763.reply.2 <== From: paul murrell To: jonathan_lees@unc.edu Subject: Re: postscript image problem (PR#6763) Date: Wed Apr 28 23:16:44 2004 Hi > It is true that if you turn antialiasing > off on GV then the effect seems to disappear but that is just a cosmetic > thing. > Other aspects of the figure are subsequently degraded, however. Just for the record, I'm afraid this problem won't be fixed in a hurry from within R. R's graphics passes through a common "engine" before being sent to a particular device and this engine has a pretty lowest-common-denominator approach. For example, the engine has no separate "image" primitive - it only knows about things like lines, text, rectangles, ... This is why the output from the image() function is produced using lots of rectangles in postscript (rather than anything more sophisticated/sensible). Paul ==> 6763.audit <== Fri Apr 16 18:25:47 2004 ripley moved from incoming to Graphics Tue Apr 27 23:57:12 2004 paul sent reply 1 Wed Apr 28 23:16:44 2004 paul sent reply 2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7031 * Subject: vfont and title() From: "Warnes, Gregory R" Date: Tue, 29 Jun 2004 10:23:47 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7031 <== From mail@stat.math.ethz.ch Tue Jun 29 16:24:10 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 50226F32C for ; Tue, 29 Jun 2004 16:24:10 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23504-08 for ; Tue, 29 Jun 2004 16:24:09 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 29 Jun 2004 16:24:09 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5TEO8RT012720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jun 2004 16:24:08 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i5TEO8mN012718 for R-bugs@biostat.ku.dk; Tue, 29 Jun 2004 16:24:08 +0200 Received: from mail9-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5TEO6hU012697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Jun 2004 16:24:07 +0200 Received: from mail9-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail9-red-R.bigfish.com (Postfix) with ESMTP id 2450D17C616 for ; Tue, 29 Jun 2004 14:24:06 +0000 (UCT) Received: by mail9-red (MessageSwitch) id 1088519046127697_29958; Tue, 29 Jun 2004 14:24:06 +0000 (UCT) Received: from mailrelay4.pfizer.com (ns11.pfizer.com [192.77.198.11]) by mail9-red.bigfish.com (Postfix) with ESMTP id D9EA917933B for ; Tue, 29 Jun 2004 14:24:05 +0000 (UCT) Received: from groexms01.pfizer.com (localhost [127.0.0.1]) by mailrelay4.pfizer.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i5TEO4qU021194 for ; Tue, 29 Jun 2004 10:24:05 -0400 (EDT) Received: from groexcn04.pfizer.com (unverified) by groexms01.pfizer.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 29 Jun 2004 10:23:49 -0400 Received: by groexcn04.pfizer.com with Internet Mail Service (5.5.2654.89) id ; Tue, 29 Jun 2004 10:23:49 -0400 Message-ID: From: "Warnes, Gregory R" To: "'R-Bugs (E-mail)'" Subject: vfont and title() Date: Tue, 29 Jun 2004 10:23:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-BigFish: vc Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of gregory_r_warnes@groton.pfizer.com does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) The "Hershey" help page states: If the 'vfont' argument to one of the text-drawing functions ('text', 'mtext', 'title', 'axis', and 'contour') is a character vector of length 2, Hershey vector fonts are used to render the text. However, title() issues warnings and does not use the vfont information if provided: > title(main="test",vfont=c("sans serif","bold")) NULL Warning message: parameter "vfont" couldn't be set in high-level plot() function > -Greg Gregory R. Warnes Manager, Non-Clinical Statistics Pfizer Global Research and Development LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}} ==> 7031.audit <== Thu Jul 1 09:34:28 2004 ripley moved from incoming to Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: In-Out * PR# 1688 * Subject: Maybe a problem in binary read/write From: accot@free.fr Date: Tue, 18 Jun 2002 22:51:17 +0200 (MET DST) --I don't think file() is said to work with devices! ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1688 <== From accot@free.fr Tue Jun 18 22:51:17 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA26479 for ; Tue, 18 Jun 2002 22:51:17 +0200 (MET DST) Date: Tue, 18 Jun 2002 22:51:17 +0200 (MET DST) From: accot@free.fr Message-Id: <200206182051.WAA26479@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Maybe a problem in binary read/write Full_Name: Johnny Accot Version: 1.5.1 OS: Linux Submission from: (NULL) (198.4.83.52) Hi. I'm having a problem with the binary read/write functions. I'm writing a device driver in R (why not?) and of course I have to send a couple commands to the device. Typically, I send one byte, receive one acknowledgement byte, send another byte, receive an ACK, and so on. At least this is what I would like to do. Instead, after writing one byte, reading its acknowledgement byte, and writing a second byte, R hangs on the next read for an unknown reason. I guess this is a bug in the read/write functions. If you have a PS/2 device you may try to run the following code: ascii <- sapply(1:255, function(i) parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) dev <- file("/dev/psaux") open(dev, "w+b") writeChar(ascii[246], dev, eos=NULL) readBin(dev, what=integer(), n=1, size=1, signed=FALSE) writeChar(ascii[246], dev, eos=NULL) readBin(dev, what=integer(), n=1, size=1, signed=FALSE) close(dev) which gives: > ascii <- sapply(1:255, function(i) parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > dev <- file("/dev/psaux") > open(dev, "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) [1] 250 > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) [...R hangs here...] It first creates an ascii table, opens the PS/2 device for binary read&write, writes the byte 0xF6 (246 in decimal, which means: set default; it is harmless), reads the acknowledgement byte 0xFA (250 in decimal), writes another 0xF6, and then hangs when reading the second acknowledgement byte. If, instead, you close the device between the two writes, it's fine: > ascii <- sapply(1:255, function(i) parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > > dev <- file("/dev/psaux", "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) [1] 250 > close(dev) > > dev <- file("/dev/psaux", "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) [1] 250 > close(dev) This is not a feature, is it? :-) The behavior is the same in versions 1.4.1, 1.5.0 and 1.5.1 on my computer. I don't have to send bytes very often, so I'll stick with the open-each-time strategy, but it is not very clean. I also tried to write bytes using the writeBin command, but it says the "size=1" is not available on my computer. This is why I'm using the writeChar function. Please let me know if I'm doing something wrong. I hope not. And thanks for the great software! :-) Johnny PS: if you try to run the code and don't get 250 as acknowledgement byte, it means the PS/2 controller is not in idle state. Very unlikely though. Try again as the set-default command should bring it back to its idle state. ==> 1688.audit <== Wed Jun 19 11:08:36 2002 ripley changed notes Wed Jun 19 11:08:36 2002 ripley foobar Wed Jun 19 11:08:36 2002 ripley moved from incoming to In-Out ==> 1688.followup.1 <== From ripley@stats.ox.ac.uk Wed Jun 19 11:15:35 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA29635 for ; Wed, 19 Jun 2002 11:15:34 +0200 (MET DST) Received: from auk.stats (pc1-oxfd1-4-cust16.oxf.cable.ntl.com [62.254.131.16]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id KAA04893; Wed, 19 Jun 2002 10:14:51 +0100 (BST) Date: Wed, 19 Jun 2002 10:13:45 +0100 (BST) From: Prof Brian D Ripley Sender: ripley@auk.stats To: accot@free.fr cc: R-bugs@biostat.ku.dk Subject: Re: Maybe a problem in binary read/write (PR#1688) In-Reply-To: <200206182051.WAA26484@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Not a bug: check the documentation of file(), which is documented to work for files but not for devices. No attempt is made to cope with e.g. blocking on non-files. It's a pretty extreme view of the world to consider /dev/psaux to be a file, and R is just using standard C I/O. However, this is a great opportunity for you to contribute a device() function to R. On Tue, 18 Jun 2002 accot@free.fr wrote: > Full_Name: Johnny Accot > Version: 1.5.1 > OS: Linux > Submission from: (NULL) (198.4.83.52) > > > Hi. > > I'm having a problem with the binary read/write functions. I'm writing a device > driver in R (why not?) and of course I have to send a couple commands to the > device. Typically, I send one byte, receive one acknowledgement byte, send > another byte, receive an ACK, and so on. At least this is what I would like to > do. Instead, after writing one byte, reading its acknowledgement byte, and > writing a second byte, R hangs on the next read for an unknown reason. I guess > this is a bug in the read/write functions. If you have a PS/2 device you may > try to run the following code: > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > dev <- file("/dev/psaux") > open(dev, "w+b") > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > writeChar(ascii[246], dev, eos=NULL) > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > close(dev) > > which gives: > > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > > dev <- file("/dev/psaux") > > open(dev, "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [...R hangs here...] > > It first creates an ascii table, opens the PS/2 device for binary read&write, > writes the byte 0xF6 (246 in decimal, which means: set default; it is harmless), > reads the acknowledgement byte 0xFA (250 in decimal), writes another 0xF6, and > then hangs when reading the second acknowledgement byte. If, instead, you close > the device between the two writes, it's fine: > > > ascii <- sapply(1:255, function(i) > parse(text=paste("\"\\",structure(i,class="octmode"),"\"",sep=""))[[1]]) > > > > dev <- file("/dev/psaux", "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > close(dev) > > > > dev <- file("/dev/psaux", "w+b") > > writeChar(ascii[246], dev, eos=NULL) > > readBin(dev, what=integer(), n=1, size=1, signed=FALSE) > [1] 250 > > close(dev) > > This is not a feature, is it? :-) The behavior is the same in versions 1.4.1, > 1.5.0 and 1.5.1 on my computer. I don't have to send bytes very often, so I'll > stick with the open-each-time strategy, but it is not very clean. > > I also tried to write bytes using the writeBin command, but it says the "size=1" > is not available on my computer. This is why I'm using the writeChar function. > > Please let me know if I'm doing something wrong. I hope not. > > And thanks for the great software! :-) > > Johnny > > PS: if you try to run the code and don't get 250 as acknowledgement byte, it > means the PS/2 controller is not in idle state. Very unlikely though. Try > again as the set-default command should bring it back to its idle state. > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1688.followup.2 <== From accot@free.fr Thu Jun 20 20:07:49 2002 Received: from mailhub2.almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA15261 for ; Thu, 20 Jun 2002 20:07:47 +0200 (MET DST) Received: from free.fr (dhcp10136.almaden.ibm.com [9.1.10.136]) by mailhub2.almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA22084; Thu, 20 Jun 2002 11:06:01 -0700 Message-ID: <3D121989.509@free.fr> Date: Thu, 20 Jun 2002 11:06:01 -0700 From: Johnny Accot User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, fr, en MIME-Version: 1.0 To: Prof Brian D Ripley CC: R-bugs@biostat.ku.dk Subject: Re: Maybe a problem in binary read/write (PR#1688) References: Content-Type: multipart/mixed; boundary="------------010901020707080002040305" This is a multi-part message in MIME format. --------------010901020707080002040305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, Prof Brian D Ripley wrote: > Not a bug: check the documentation of file(), which is documented to work > for files but not for devices. No attempt is made to cope with e.g. > blocking on non-files. > > It's a pretty extreme view of the world to consider /dev/psaux to be a > file, and R is just using standard C I/O. > > However, this is a great opportunity for you to contribute a device() > function to R. I finally checked the code and "wrote" the functions to "handle devices". Well, in fact I more or less duplicated the code for FIFOs, removed the option for encoding, added an option for synchronous I/O, and added a test to check that the file is indeed a character or block special file. This works great for me but I'm afraid it is a bit simple and does not cover much of device handling in general. Especially I don't know if anybody would want to use it for block devices, and what they would need. The psaux device is one of the simplest device one could think of, that's why it works so well. For other devices one would need at least an ioctl function, which I didn't write. But still I have no idea whether anybody would use it and what for. Anyway. Please let me know if you think this is useful. If yes, I will try to familiarize myself with the structure of the R code and make the device handling more general. Thanks, Johnny --------------010901020707080002040305 Content-Type: text/plain; name="R-1.5.1-device.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="R-1.5.1-device.patch" diff -ur R-1.5.1.orig/configure R-1.5.1/configure --- R-1.5.1.orig/configure 2002-06-17 04:20:30.000000000 -0700 +++ R-1.5.1/configure 2002-06-19 19:33:22.000000000 -0700 @@ -17238,8 +17238,9 @@ + for ac_func in access chdir expm1 fcntl finite ftruncate getcwd \ - getgrgid getpwuid getuid hypot isascii isnan log1p matherr mkfifo \ + getgrgid getpwuid getuid hypot isascii isnan log1p matherr mkfifo mknod \ popen putenv rint setenv strcoll stat strptime system times unsetenv do as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh` diff -ur R-1.5.1.orig/configure.ac R-1.5.1/configure.ac --- R-1.5.1.orig/configure.ac 2002-04-30 11:04:05.000000000 -0700 +++ R-1.5.1/configure.ac 2002-06-19 19:25:04.000000000 -0700 @@ -982,7 +982,7 @@ AC_FUNC_ALLOCA AC_CHECK_FUNCS(access chdir expm1 fcntl finite ftruncate getcwd \ - getgrgid getpwuid getuid hypot isascii isnan log1p matherr mkfifo \ + getgrgid getpwuid getuid hypot isascii isnan log1p matherr mkfifo mknod \ popen putenv rint setenv strcoll stat strptime system times unsetenv) ## ## No need checking for bcopy bzero memcpy mempcpy even though ifnames diff -ur R-1.5.1.orig/src/include/config.h.in R-1.5.1/src/include/config.h.in --- R-1.5.1.orig/src/include/config.h.in 2002-04-24 02:54:05.000000000 -0700 +++ R-1.5.1/src/include/config.h.in 2002-06-19 19:35:10.000000000 -0700 @@ -216,6 +216,9 @@ /* Define to 1 if you have the `mkfifo' function. */ #undef HAVE_MKFIFO +/* Define to 1 if you have the `mknod' function. */ +#undef HAVE_MKNOD + /* Define to 1 if you have the header file, and it defines `DIR'. */ #undef HAVE_NDIR_H diff -ur R-1.5.1.orig/src/include/Internal.h R-1.5.1/src/include/Internal.h --- R-1.5.1.orig/src/include/Internal.h 2002-04-03 22:51:04.000000000 -0800 +++ R-1.5.1/src/include/Internal.h 2002-06-19 19:25:06.000000000 -0700 @@ -439,6 +439,7 @@ SEXP do_isseekable(SEXP, SEXP, SEXP, SEXP); SEXP do_close(SEXP, SEXP, SEXP, SEXP); SEXP do_fifo(SEXP, SEXP, SEXP, SEXP); +SEXP do_device(SEXP, SEXP, SEXP, SEXP); SEXP do_pipe(SEXP, SEXP, SEXP, SEXP); SEXP do_url(SEXP, SEXP, SEXP, SEXP); SEXP do_gzfile(SEXP, SEXP, SEXP, SEXP); diff -ur R-1.5.1.orig/src/include/Rconnections.h R-1.5.1/src/include/Rconnections.h --- R-1.5.1.orig/src/include/Rconnections.h 2002-03-10 05:20:42.000000000 -0800 +++ R-1.5.1/src/include/Rconnections.h 2002-06-19 20:09:26.000000000 -0700 @@ -28,7 +28,7 @@ char* class; char* description; char mode[5]; - Rboolean text, isopen, incomplete, canread, canwrite, canseek, blocking; + Rboolean text, isopen, incomplete, canread, canwrite, canseek, blocking, sync; Rboolean (*open)(struct Rconn *); void (*close)(struct Rconn *); /* routine closing after auto open */ void (*destroy)(struct Rconn *); /* when closing connection */ @@ -58,6 +58,10 @@ int fd; } *Rfifoconn; +typedef struct deviceconn { + int fd; +} *Rdeviceconn; + typedef struct gzfileconn { void *fp; int cp; diff -ur R-1.5.1.orig/src/library/base/man/connections.Rd R-1.5.1/src/library/base/man/connections.Rd --- R-1.5.1.orig/src/library/base/man/connections.Rd 2002-03-10 05:20:42.000000000 -0800 +++ R-1.5.1/src/library/base/man/connections.Rd 2002-06-20 10:48:13.000000000 -0700 @@ -4,6 +4,7 @@ \alias{file} \alias{pipe} \alias{fifo} +\alias{device} \alias{gzfile} \alias{unz} \alias{bzfile} @@ -31,6 +32,7 @@ pipe(description, open = "", encoding = getOption("encoding")) fifo(description = "", open = "", blocking = FALSE, encoding = getOption("encoding")) +device(description = "", open = "", blocking = TRUE, sync = TRUE) gzfile(description, open = "", encoding = getOption("encoding"), compression = 6) unz(description, filename, open = "", encoding = getOption("encoding")) @@ -62,6 +64,7 @@ \item{open}{character. A description of how to open the connection (if at all). See Details for possible values.} \item{blocking}{logical. See `Blocking' section below.} + \item{sync}{logical. Should the device be opened for synchronous I/O?} \item{encoding}{An integer vector of length 256.} \item{compression}{integer in 0--9. The amount of compression to be applied when writing, from none to maximal. The default is a good @@ -74,7 +77,7 @@ \item{\dots}{arguments passed to or from other methods.} } \details{ - The first eight functions create connections. By default the + The first nine functions create connections. By default the connection is not opened (except for \code{socketConnection}), but may be opened by setting a non-empty value of argument \code{open}. @@ -135,8 +138,8 @@ characters are mapped to a space in these encodings. } \value{ - \code{file}, \code{pipe}, \code{fifo}, \code{url}, \code{gzfile} and - \code{socketConnection} return a connection object + \code{file}, \code{pipe}, \code{fifo}, \code{device}, \code{url}, + \code{gzfile} and \code{socketConnection} return a connection object which inherits from class \code{"connection"} and has a first more specific class. diff -ur R-1.5.1.orig/src/main/connections.c R-1.5.1/src/main/connections.c --- R-1.5.1.orig/src/main/connections.c 2002-04-30 04:04:02.000000000 -0700 +++ R-1.5.1/src/main/connections.c 2002-06-19 20:12:34.000000000 -0700 @@ -640,6 +640,181 @@ #endif } +/* ------------------- device connections --------------------- */ + +#if defined(HAVE_MKNOD) && defined(HAVE_FCNTL_H) + +#ifdef HAVE_STAT +# ifndef Macintosh +# ifdef HAVE_SYS_TYPES_H +# include +# endif +# ifdef HAVE_SYS_STAT_H +# include +# endif +# else /* Macintosh */ +# include +# ifndef __MRC__ +# include +# else +# include +# endif +# endif /* Macintosh */ +#endif /* HAVE_STAT */ + +#ifdef HAVE_ERRNO_H +# include +#endif + +static Rboolean device_open(Rconnection con) +{ + char *name; + Rdeviceconn this = con->private; + int fd, flags, res; + int mlen = strlen(con->mode); + struct stat sb; + + name = R_ExpandFileName(con->description); + con->canwrite = (con->mode[0] == 'w' || con->mode[0] == 'a'); + con->canread = !con->canwrite; + if(mlen >= 2 && con->mode[1] == '+') con->canread = TRUE; + + /* check if the device exists and if it is a character or block device */ + if(con->canwrite) { + res = stat(name, &sb); + if(res) { /* error, does not exist? */ + if(errno == ENOENT) warning("device `%s' does not exist", name); + else warning("cannot find device `%s'", name); + return FALSE; + } else { + if(!(sb.st_mode & S_IFCHR) && !(sb.st_mode & S_IFBLK)) { + warning("`%s' exists but is neither a character special file nor a block special file", name); + return FALSE; + } + } + } + + if(con->canread && con->canwrite) flags = O_RDWR; + else if(con->canread) flags = O_RDONLY; + else flags = O_WRONLY; + if(!con->blocking) flags |= O_NONBLOCK; + if(con->sync) flags |= O_SYNC; + if(con->mode[0] == 'a') flags |= O_APPEND; + fd = open(name, flags); + if(fd < 0) { + if(errno == ENXIO) warning("device `%s' is not ready", name); + else warning("cannot open device `%s'", name); + return FALSE; + } + + this->fd = fd; + con->isopen = TRUE; + + if(mlen >= 2 && con->mode[mlen-1] == 'b') con->text = FALSE; + else con->text = TRUE; + con->save = -1000; + return TRUE; +} + +static int device_fgetc(Rconnection con) +{ + Rdeviceconn this = (Rdeviceconn)con->private; + unsigned char c; + int n; + + n = read(this->fd, (char *)&c, 1); + return (n == 1) ? c : R_EOF; +} + +static Rconnection newdevice(char *description, char *mode) +{ + Rconnection new; + new = (Rconnection) malloc(sizeof(struct Rconn)); + if(!new) error("allocation of device connection failed"); + new->class = (char *) malloc(strlen("device") + 1); + if(!new->class) { + free(new); + error("allocation of device connection failed"); + } + strcpy(new->class, "device"); + new->description = (char *) malloc(strlen(description) + 1); + if(!new->description) { + free(new->class); free(new); + error("allocation of device connection failed"); + } + init_con(new, description, mode); + new->open = &device_open; + new->close = &fifo_close; + new->vfprintf = &dummy_vfprintf; + new->fgetc = &device_fgetc; + new->seek = &null_seek; + new->truncate = &null_truncate; + new->fflush = &null_fflush; + new->read = &fifo_read; + new->write = &fifo_write; + new->private = (void *) malloc(sizeof(struct deviceconn)); + if(!new->private) { + free(new->description); free(new->class); free(new); + error("allocation of device connection failed"); + } + return new; +} +#endif + +SEXP do_device(SEXP call, SEXP op, SEXP args, SEXP env) +{ +#if defined(HAVE_MKNOD) && defined(HAVE_FCNTL_H) + SEXP sfile, sopen, ans, class; + char *file, *open; + int i, ncon, block, sync; + Rconnection con = NULL; + + checkArity(op, args); + sfile = CAR(args); + if(!isString(sfile) || length(sfile) < 1) + errorcall(call, "invalid `description' argument"); + if(length(sfile) > 1) + warning("only first element of `description' argument used"); + file = CHAR(STRING_ELT(sfile, 0)); + sopen = CADR(args); + if(!isString(sopen) || length(sopen) != 1) + error("invalid `open' argument"); + block = asLogical(CADDR(args)); + if(block == NA_LOGICAL) + error("invalid `block' argument"); + sync = asLogical(CADDDR(args)); + if(sync == NA_LOGICAL) + error("invalid `sync' argument"); + open = CHAR(STRING_ELT(sopen, 0)); + ncon = NextConnection(); + con = Connections[ncon] = newdevice(file, strlen(open) ? open : "r"); + con->blocking = block; + con->sync = sync; + + /* open it if desired */ + if(strlen(open)) { + Rboolean success = con->open(con); + if(!success) { + con_close(ncon); + error("unable to open connection"); + } + } + + PROTECT(ans = allocVector(INTSXP, 1)); + INTEGER(ans)[0] = ncon; + PROTECT(class = allocVector(STRSXP, 2)); + SET_STRING_ELT(class, 0, mkChar("device")); + SET_STRING_ELT(class, 1, mkChar("connection")); + classgets(ans, class); + UNPROTECT(2); + + return ans; +#else + error("device connections are not available on this system"); + return R_NilValue; /* -Wall */ +#endif +} + /* ------------------- pipe connections --------------------- */ #ifdef HAVE_POPEN diff -ur R-1.5.1.orig/src/main/names.c R-1.5.1/src/main/names.c --- R-1.5.1.orig/src/main/names.c 2002-04-04 14:11:31.000000000 -0800 +++ R-1.5.1/src/main/names.c 2002-06-20 10:38:39.000000000 -0700 @@ -692,9 +692,6 @@ {"dev.control", do_devcontrol, 0, 111, 0, PP_FUNCALL}, {"dev.copy", do_devcopy, 0, 111, 1, PP_FUNCALL}, {"dev.cur", do_devcur, 0, 111, 0, PP_FUNCALL}, -/* -{"device", do_device, 0, 111, 3, PP_FUNCALL}, -*/ {"dev.next", do_devnext, 0, 111, 1, PP_FUNCALL}, {"dev.off", do_devoff, 0, 111, 1, PP_FUNCALL}, {"dev.prev", do_devprev, 0, 111, 1, PP_FUNCALL}, @@ -793,6 +790,7 @@ {"url", do_url, 0, 11, 4, PP_FUNCALL}, {"pipe", do_pipe, 0, 11, 3, PP_FUNCALL}, {"fifo", do_fifo, 0, 11, 4, PP_FUNCALL}, +{"device", do_device, 0, 11, 4, PP_FUNCALL}, {"gzfile", do_gzfile, 0, 11, 4, PP_FUNCALL}, {"unz", do_unz, 0, 11, 3, PP_FUNCALL}, {"bzfile", do_bzfile, 0, 11, 3, PP_FUNCALL}, --------------010901020707080002040305-- ==> 1688.followup.3 <== From ripley@stats.ox.ac.uk Thu Jun 20 20:44:01 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA15376 for ; Thu, 20 Jun 2002 20:44:01 +0200 (MET DST) From: ripley@stats.ox.ac.uk Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id TAA10803; Thu, 20 Jun 2002 19:43:18 +0100 (BST) Date: Thu, 20 Jun 2002 19:43:18 +0100 (BST) X-X-Sender: To: Johnny Accot cc: Subject: Re: Maybe a problem in binary read/write (PR#1688) In-Reply-To: <3D121989.509@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jun 2002, Johnny Accot wrote: > Hello, > > Prof Brian D Ripley wrote: > > Not a bug: check the documentation of file(), which is documented to work > > for files but not for devices. No attempt is made to cope with e.g. > > blocking on non-files. > > > > It's a pretty extreme view of the world to consider /dev/psaux to be a > > file, and R is just using standard C I/O. > > > > However, this is a great opportunity for you to contribute a device() > > function to R. > > I finally checked the code and "wrote" the functions to "handle devices". > Well, in fact I more or less duplicated the code for FIFOs, removed the > option for encoding, added an option for synchronous I/O, and added a > test to check that the file is indeed a character or block special file. > This works great for me but I'm afraid it is a bit simple and does not > cover much of device handling in general. Especially I don't know if > anybody would want to use it for block devices, and what they would need. > The psaux device is one of the simplest device one could think of, that's > why it works so well. For other devices one would need at least an > ioctl function, which I didn't write. But still I have no idea whether > anybody would use it and what for. Anyway. Please let me know if you > think this is useful. If yes, I will try to familiarize myself with > the structure of the R code and make the device handling more general. Yes, I do think it would be useful, but I know little about it, Thank you for the offer. > > Thanks, > Johnny > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Installation * PR# 1222 * Subject: configure: sed: Function s%@PDFLATEX@%/usr/local/bin/pdflatex%g From: Peter Kleiweg Date: Thu, 20 Dec 2001 14:09:42 +0100 (CET) --problem is on hppa2.0-hp-hpux10.20: may be HP-UX specific ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1222 <== From postmaster@franz.stat.wisc.edu Thu Dec 20 14:10:13 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA13749 for ; Thu, 20 Dec 2001 14:10:12 +0100 (MET) Received: from kleigh.nl (really [213.84.55.218]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Thu, 20 Dec 2001 07:09:45 -0600 (CST) Received: from kleigh.nl (kleigh [127.0.0.1]) by kleigh.nl (8.12.0/8.12.0) with ESMTP id fBKD9goQ007981 for ; Thu, 20 Dec 2001 14:09:43 +0100 Received: from localhost (peter@localhost) by kleigh.nl (8.12.0/8.12.0/Submit) with ESMTP id fBKD9gPQ007978 for ; Thu, 20 Dec 2001 14:09:42 +0100 X-Authentication-Warning: kleigh.nl: peter owned process doing -bs Date: Thu, 20 Dec 2001 14:09:42 +0100 (CET) From: Peter Kleiweg X-X-Sender: To: Subject: configure: sed: Function s%@PDFLATEX@%/usr/local/bin/pdflatex%g cannot be parsed. Message-ID: Organization: Alfa-Informatica, Rijksuniversiteit Groningen X-Accept-Language: nl,en,ia,af,de,da,no,sv,fr,it X-Alert: http://www.opensource.org/halloween/ X-Face: "K~X:~!ydgSdjNy;]_+BCb\OM^pqyg_q*Le84$l46M\-mL=.^,L4B}bDK>`o#r4_>O* X-Mailer: Pine 4.33, Linux 2.0.36, i586 X-Reason: http://www.interlingua.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sometimes, configure isn't able to create the makefiles. It produces errors like: sed: Function s%@PDFLATEX@%/usr/local/bin/pdflatex%g cannot be parsed. This happens when I use a combination of arguments to configure like: --prefix=$HOME/R-tst --with-tcl-config=/opt_local/opt/tcl/lib/tclConfig.sh --with-tk-config=/opt_local/opt/tk/lib/tkConfig.sh If I leave out the last two arguments, the problem does not occur. If I change the first argument to --prefix=$HOME/Rtst, the problem does not occur. --please do not edit the information below-- Version: platform = hppa2.0-hp-hpux10.20 arch = hppa2.0 os = hpux10.20 system = hppa2.0, hpux10.20 status = major = 1 minor = 4.0 year = 2001 month = 12 day = 19 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base ==> 1222.audit <== Fri Dec 21 06:19:29 2001 ripley changed notes Fri Dec 21 06:19:29 2001 ripley foobar Fri Dec 21 06:19:29 2001 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1268 * Subject: Solaris 2.6 Compile From: gm81640@development.nssmb.com Date: Thu, 17 Jan 2002 06:28:26 +0100 (MET) --Most likely a compiler installation problem ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1268 <== From gm81640@development.nssmb.com Thu Jan 17 06:28:36 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id GAA21618 for ; Thu, 17 Jan 2002 06:28:26 +0100 (MET) Date: Thu, 17 Jan 2002 06:28:26 +0100 (MET) From: gm81640@development.nssmb.com Message-Id: <200201170528.GAA21618@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Solaris 2.6 Compile Full_Name: Geordon Marchak Version: R-1.3.1 OS: Solaris 2.6 Submission from: (NULL) (199.67.239.91) Got the following error when compiling on Solaris 2.6 with the standard GNU gcc package (from the Sun site). BTW - linux compiles no problem (and fast too :-) # make `Makedeps' is up to date. gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c lbfgsb.c -o lbfgsb.o /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: unknown opcode ".subsection" /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: statement syntax /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: unknown opcode ".previous" /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: statement syntax *** Error code 1 make: Fatal error: Command failed for target `lbfgsb.o' Current working directory /home/gm81640/R-1.3.1/src/appl *** Error code 1 make: Fatal error: Command failed for target `R' Current working directory /home/gm81640/R-1.3.1/src/appl *** Error code 1 make: Fatal error: Command failed for target `R' Current working directory /home/gm81640/R-1.3.1/src *** Error code 1 make: Fatal error: Command failed for target `R' ==> 1268.followup.1 <== From ripley@stats.ox.ac.uk Thu Jan 17 09:37:45 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id JAA23207 for ; Thu, 17 Jan 2002 09:37:45 +0100 (MET) Received: from gannet.stats (IDENT:root@gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id IAA21901; Thu, 17 Jan 2002 08:37:15 GMT Received: from localhost (ripley@localhost) by gannet.stats (8.11.3/8.11.3) with ESMTP id g0H8bFj02561; Thu, 17 Jan 2002 08:37:15 GMT X-Authentication-Warning: gannet.stats: ripley owned process doing -bs Date: Thu, 17 Jan 2002 08:37:15 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: To: cc: Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268) In-Reply-To: <200201170528.GAA21628@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Jan 2002 gm81640@development.nssmb.com wrote: > Full_Name: Geordon Marchak > Version: R-1.3.1 > OS: Solaris 2.6 > Submission from: (NULL) (199.67.239.91) > > > Got the following error when compiling on Solaris 2.6 with the standard GNU > gcc package (from the Sun site). BTW - linux compiles no problem (and fast > too :-) You sent this twice, for some reason. It's hard to tell what `the standard GNU gcc package (from the Sun site)' actually is. However, R 1.3.1 did compile under Solaris 2.6 with gcc 2.95.3 compiled under Solaris 2.6. The error appears to be a mismatch between your compiler and your assembler. I don't think that qualifies as a bug in R, and definitely is one we can do nothing about. lbfgsb.c does seem to be valid C that is accepted by a wide range of compilers on Solaris and elsewhere. > # make > `Makedeps' is up to date. > gcc -I. -I../../src/include -I../../src/include -I/usr/local/include > -DHAVE_CONFIG_H -g -O2 -c lbfgsb.c -o lbfgsb.o > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: unknown opcode > ".subsection" > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: statement syntax > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: unknown opcode > ".previous" > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: statement syntax > *** Error code 1 > make: Fatal error: Command failed for target `lbfgsb.o' > Current working directory /home/gm81640/R-1.3.1/src/appl > *** Error code 1 > make: Fatal error: Command failed for target `R' > Current working directory /home/gm81640/R-1.3.1/src/appl > *** Error code 1 > make: Fatal error: Command failed for target `R' > Current working directory /home/gm81640/R-1.3.1/src > *** Error code 1 > make: Fatal error: Command failed for target `R' > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1268.reply.1 <== From p.dalgaard@biostat.ku.dk Thu Jan 17 11:46:44 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA25668; Thu, 17 Jan 2002 11:46:44 +0100 (MET) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id g0HAjXh15735; Thu, 17 Jan 2002 11:45:33 +0100 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: ripley@stats.ox.ac.uk Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268) References: <200201170837.JAA23228@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 17 Jan 2002 11:45:33 +0100 In-Reply-To: <200201170837.JAA23228@pubhealth.ku.dk> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ripley@stats.ox.ac.uk writes: > > Got the following error when compiling on Solaris 2.6 with the standard GNU > > gcc package (from the Sun site). BTW - linux compiles no problem (and fast > > too :-) > > You sent this twice, for some reason. > > It's hard to tell what `the standard GNU gcc package (from the Sun site)' > actually is. However, R 1.3.1 did compile under Solaris 2.6 with gcc > 2.95.3 compiled under Solaris 2.6. The error appears to be a mismatch > between your compiler and your assembler. I don't think that qualifies as > a bug in R, and definitely is one we can do nothing about. lbfgsb.c does > seem to be valid C that is accepted by a wide range of compilers on > Solaris and elsewhere. Assuming that the "Sun site" means www.sunfreeware.com, I seem to recall that you get in trouble if you use gcc3 without GNU binutils. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1268.followup.2 <== From geordon.marchak@nssmb.com Mon Jan 21 09:27:58 2002 Received: from issaspam-ny01.ssmb.com (mail1.ssmb.COM [199.67.139.25]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id JAA26346 for ; Mon, 21 Jan 2002 09:27:56 +0100 (MET) Received: from issny6.ny.ssmb.com (issny6.ny.ssmb.com [162.124.150.21]) by issaspam-ny01.ssmb.com (8.12.0/8.12.0/SSMB_EXT/1.4) with ESMTP id g0L8QXbE027462; Mon, 21 Jan 2002 03:26:50 -0500 (EST) Received: from mailhub.nssmb.com (mailhubb.nssmb.com [169.180.188.120]) by issny6.ny.ssmb.com (8.11.0/8.11.0/SSMB_QQQ_IN/1.1) with ESMTP id g0L8PFT01212; Mon, 21 Jan 2002 03:25:15 -0500 (EST) Received: from lx22z001.nssmb.com (lx22z001.nssmb.com [169.180.162.41]) by mailhub.nssmb.com (8.9.3/8.9.3/SSMB-HUB) with ESMTP id RAA08319; Mon, 21 Jan 2002 17:25:14 +0900 (JST) Received: by lx22z001.nssmb.com (Postfix, from userid 81640) id 3B1E9BFE83; Mon, 21 Jan 2002 17:25:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by lx22z001.nssmb.com (Postfix) with ESMTP id 0A901BFE82; Mon, 21 Jan 2002 17:25:14 +0900 (JST) Date: Mon, 21 Jan 2002 17:25:13 +0900 (JST) From: Joe Marchak X-X-Sender: To: Prof Brian Ripley Cc: , Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As you mentioned below, R 1.3.1 does compile on Solaris with gcc 2.95. I've tried both Solaris 2.5.1 and Solaris 2.6 with this, and they are fine. Moving to gcc 3.03 however causes the problem. Thanks for you help earlier. -Joe. > Date: Thu, 17 Jan 2002 08:37:15 +0000 (GMT) > From: Prof Brian Ripley > To: geordon.marchak@nssmb.com > Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268) > > On Thu, 17 Jan 2002 gm81640@development.nssmb.com wrote: > > > Full_Name: Geordon Marchak > > Version: R-1.3.1 > > OS: Solaris 2.6 > > Submission from: (NULL) (199.67.239.91) > > > > > > Got the following error when compiling on Solaris 2.6 with the standard GNU > > gcc package (from the Sun site). BTW - linux compiles no problem (and fast > > too :-) > > You sent this twice, for some reason. > > It's hard to tell what `the standard GNU gcc package (from the Sun site)' > actually is. However, R 1.3.1 did compile under Solaris 2.6 with gcc > 2.95.3 compiled under Solaris 2.6. The error appears to be a mismatch > between your compiler and your assembler. I don't think that qualifies as > a bug in R, and definitely is one we can do nothing about. lbfgsb.c does > seem to be valid C that is accepted by a wide range of compilers on > Solaris and elsewhere. > > > > # make > > `Makedeps' is up to date. > > gcc -I. -I../../src/include -I../../src/include -I/usr/local/include > > -DHAVE_CONFIG_H -g -O2 -c lbfgsb.c -o lbfgsb.o > > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: unknown opcode > > ".subsection" > > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12959: error: statement syntax > > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: unknown opcode > > ".previous" > > /usr/ccs/bin/as: "/var/tmp/cccbNfee.s", line 12971: error: statement syntax > > *** Error code 1 > > make: Fatal error: Command failed for target `lbfgsb.o' > > Current working directory /home/gm81640/R-1.3.1/src/appl > > *** Error code 1 > > make: Fatal error: Command failed for target `R' > > Current working directory /home/gm81640/R-1.3.1/src/appl > > *** Error code 1 > > make: Fatal error: Command failed for target `R' > > Current working directory /home/gm81640/R-1.3.1/src > > *** Error code 1 > > make: Fatal error: Command failed for target `R' > > > > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > > Send "info", "help", or "[un]subscribe" > > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > > > > ==> 1268.audit <== Fri Jan 18 09:06:39 2002 ripley changed notes Fri Jan 18 09:06:39 2002 ripley foobar Fri Jan 18 09:06:39 2002 ripley moved from incoming to System-specific Sun Apr 21 09:41:09 2002 ripley moved from System-specific to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1291 * Subject: Installation problem : SunOS From: brendan_mcmahon@prusec.com Date: Thu, 31 Jan 2002 18:00:55 +0100 (MET) --looks like gcc compiled under different OS version. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1291 <== From brendan_mcmahon@prusec.com Thu Jan 31 18:00:56 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA07547 for ; Thu, 31 Jan 2002 18:00:55 +0100 (MET) Date: Thu, 31 Jan 2002 18:00:55 +0100 (MET) From: brendan_mcmahon@prusec.com Message-Id: <200201311700.SAA07547@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: Installation problem : SunOS Full_Name: Brendan McMahon Version: 1.3 OS: SunOS Submission from: (NULL) (12.42.50.51) Probably just a configuration problem but ... fails to compile. configure completed without a problem. Any help appreciated!! SunOS flexdev1 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10 `Makedeps' is up to date. gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c arithmetic.c -o arithmetic.o arithmetic.c:58: warning: `struct exception' declared inside parameter list arithmetic.c:58: warning: its scope is only this definition or declaration, arithmetic.c:58: warning: which is probably not what you want. arithmetic.c: In function `matherr': arithmetic.c:60: dereferencing pointer to incomplete type arithmetic.c:61: `DOMAIN' undeclared (first use this function) arithmetic.c:61: (Each undeclared identifier is reported only once arithmetic.c:61: for each function it appears in.) arithmetic.c:62: `SING' undeclared (first use this function) arithmetic.c:65: `OVERFLOW' undeclared (first use this function) arithmetic.c:68: `UNDERFLOW' undeclared (first use this function) arithmetic.c:69: dereferencing pointer to incomplete type arithmetic.c: In function `do_math1': arithmetic.c:984: `acosh' undeclared (first use this function) arithmetic.c:985: `asinh' undeclared (first use this function) arithmetic.c:986: `atanh' undeclared (first use this function) *** Error code 1 make: Fatal error: Command failed for target `arithmetic.o' Current working directory /export/home/flexapp/R/R-1.3.0/src/main *** Error code 1 make: Fatal error: Command failed for target `R' ==> 1291.followup.1 <== From ripley@stats.ox.ac.uk Thu Jan 31 18:46:28 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA07809 for ; Thu, 31 Jan 2002 18:46:28 +0100 (MET) Received: from gannet.stats (IDENT:root@gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id RAA10317; Thu, 31 Jan 2002 17:45:57 GMT Received: from localhost (ripley@localhost) by gannet.stats (8.11.3/8.11.3) with ESMTP id g0VHjv312467; Thu, 31 Jan 2002 17:45:57 GMT X-Authentication-Warning: gannet.stats: ripley owned process doing -bs Date: Thu, 31 Jan 2002 17:45:57 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: To: cc: Subject: Re: [Rd] Installation problem : SunOS (PR#1291) In-Reply-To: <200201311700.SAA07558@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 31 Jan 2002 brendan_mcmahon@prusec.com wrote: > Full_Name: Brendan McMahon > Version: 1.3 > OS: SunOS > Submission from: (NULL) (12.42.50.51) > > > > Probably just a configuration problem but ... fails to compile. > configure completed without a problem. We need to know your compiler system. This is I seem to remember a symptom of using gcc made on SunOS 5.5 under 5.6/7, so if this is gcc, was it built under 5.7? BTW, R is now at 1.4.1, not 1.3.0. > Any help appreciated!! > > SunOS flexdev1 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10 > > `Makedeps' is up to date. > gcc -I. -I../../src/include -I../../src/include -I/usr/local/include > -DHAVE_CONFIG_H -g -O2 -c arithmetic.c -o arithmetic.o > arithmetic.c:58: warning: `struct exception' declared inside parameter list > arithmetic.c:58: warning: its scope is only this definition or declaration, > arithmetic.c:58: warning: which is probably not what you want. > arithmetic.c: In function `matherr': > arithmetic.c:60: dereferencing pointer to incomplete type > arithmetic.c:61: `DOMAIN' undeclared (first use this function) > arithmetic.c:61: (Each undeclared identifier is reported only once > arithmetic.c:61: for each function it appears in.) > arithmetic.c:62: `SING' undeclared (first use this function) > arithmetic.c:65: `OVERFLOW' undeclared (first use this function) > arithmetic.c:68: `UNDERFLOW' undeclared (first use this function) > arithmetic.c:69: dereferencing pointer to incomplete type > arithmetic.c: In function `do_math1': > arithmetic.c:984: `acosh' undeclared (first use this function) > arithmetic.c:985: `asinh' undeclared (first use this function) > arithmetic.c:986: `atanh' undeclared (first use this function) > *** Error code 1 > make: Fatal error: Command failed for target `arithmetic.o' > Current working directory /export/home/flexapp/R/R-1.3.0/src/main > *** Error code 1 > make: Fatal error: Command failed for target `R' > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1291.audit <== Fri Feb 1 21:53:20 2002 ripley changed notes Fri Feb 1 21:53:20 2002 ripley foobar Fri Feb 1 21:53:20 2002 ripley moved from incoming to System-specific Sun Apr 21 09:41:20 2002 ripley moved from System-specific to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1500 * Subject: configure script fails on comment in tkConfig.sh From: Peter Kleiweg Date: Tue, 30 Apr 2002 16:41:51 +0200 (CEST) --Looks like a conspiracy between a shell problem and an oddity in Tk 8.0 rather --than an R problem. Good to know for the workaround though. The comment in --TK_XINCLUDES has since disappeared, at least in Tk 8.3.3. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1500 <== From postmaster@franz.stat.wisc.edu Tue Apr 30 16:42:34 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA22070 for ; Tue, 30 Apr 2002 16:42:33 +0200 (MET DST) Received: from kleigh.nl (really [213.84.55.218]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Tue, 30 Apr 2002 09:41:53 -0500 (CDT) Received: from kleigh.nl (kleigh [127.0.0.1]) by kleigh.nl (8.12.0/8.12.0) with ESMTP id g3UEfpS7030242 for ; Tue, 30 Apr 2002 16:41:51 +0200 Received: from localhost (peter@localhost) by kleigh.nl (8.12.0/8.12.0/Submit) with ESMTP id g3UEfpgv030239 for ; Tue, 30 Apr 2002 16:41:51 +0200 X-Authentication-Warning: kleigh.nl: peter owned process doing -bs Date: Tue, 30 Apr 2002 16:41:51 +0200 (CEST) From: Peter Kleiweg X-X-Sender: To: Subject: configure script fails on comment in tkConfig.sh Message-ID: Organization: Alfa-Informatica, Rijksuniversiteit Groningen X-Accept-Language: nl,en,ia,af,de,da,no,sv,fr,it X-Alert: http://www.opensource.org/halloween/ X-Face: "K~X:~!ydgSdjNy;]_+BCb\OM^pqyg_q*Le84$l46M\-mL=.^,L4B}bDK>`o#r4_>O* X-Mailer: Pine 4.33, Linux 2.0.36, i586 X-Reason: http://www.interlingua.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The configure script failed on tk on several platforms. One is given below. This did not happen on versions of R older than 1.5.0. Message from configure: configure: WARNING: /opt_local/opt/tk-8.0/include/tk.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: /opt_local/opt/tk-8.0/include/tk.h: proceeding with the preprocessor's result This was in config.log, the command on a single line: configure:21361: cc -E -I/opt_local/opt/readline/include -I/opt_local/opt/tk/include -I/opt_local/opt/tcl/include -I/opt_local/opt/jpeg6/inclu de -I/opt_local/opt/png/include -I/opt_local/opt/ncurses/include -I/opt_local/opt/zlib/include -I/opt_local/opt/R/include # no special path needed -I/opt_local/opt/tcl-8.0/include conftest.c cc: warning 485: Can't open "#". cc: warning 485: Can't open "no". cc: warning 485: Can't open "special". cc: warning 485: Can't open "path". cc: warning 485: Can't open "needed". I had to edit tkConfig.sh to solve this problem. This line: TK_XINCLUDES='# no special path needed' changed to this: TK_XINCLUDES= After this fix, R was configured for tcl/tk, and the package tcltk seems to work OK (at least on this platform). # Tk's version number. TK_VERSION='8.3' TK_MAJOR_VERSION='8' TK_MINOR_VERSION='3' TK_PATCH_LEVEL='.3' Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 5.0 year = 2002 month = 04 day = 29 language = R Search Path: .GlobalEnv, package:tcltk, package:ctest, Autoloads, package:base ==> 1500.audit <== Tue May 7 09:05:09 2002 ripley moved from incoming to Installation Mon Sep 16 12:45:53 2002 pd changed notes Mon Sep 16 12:45:53 2002 pd foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1658 * Subject: make install fails - index.html not found From: dhouston@bio.ri.ccf.org Date: Tue, 11 Jun 2002 22:14:07 +0200 (MET DST) --Missing perl?? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1658 <== From dhouston@bio.ri.ccf.org Tue Jun 11 22:14:08 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA06194 for ; Tue, 11 Jun 2002 22:14:07 +0200 (MET DST) Date: Tue, 11 Jun 2002 22:14:07 +0200 (MET DST) From: dhouston@bio.ri.ccf.org Message-Id: <200206112014.WAA06194@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: make install fails - index.html not found Full_Name: Dale Houston Version: 1.5.0 OS: Solaris 8 Submission from: (NULL) (192.35.79.70) I am trying to get RT-1.5.0 installed on Solaris 8. The programs compile fine and 'make check' seems to work. But when I do a 'make install' I see this: /home/dhouston/R-1.5.0 grieg> make install installing afm ... installing doc ... installing doc/html ... install: index.html does not exist *** Error code 1 make: Fatal error: Command failed for target `install' Current working directory /home/dhouston/R-1.5.0/doc/html *** Error code 1 make: Fatal error: Command failed for target `install' Current working directory /home/dhouston/R-1.5.0/doc *** Error code 1 make: Fatal error: Command failed for target `install' I do not see index.html in doc/html. I made a fake one for testing purposes, but when I do a make install it now fails trying to find SearchEngine.html. I did a 'make html' but to no avail. dale ==> 1658.followup.1 <== From ripley@stats.ox.ac.uk Tue Jun 11 22:50:13 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA06330 for ; Tue, 11 Jun 2002 22:50:13 +0200 (MET DST) From: ripley@stats.ox.ac.uk Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id VAA09492; Tue, 11 Jun 2002 21:40:27 +0100 (BST) Date: Tue, 11 Jun 2002 21:40:26 +0100 (BST) X-X-Sender: To: cc: , Subject: Re: make install fails - index.html not found (PR#1658) In-Reply-To: <200206112014.WAA06199@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Jun 2002 dhouston@bio.ri.ccf.org wrote: > Full_Name: Dale Houston > Version: 1.5.0 > OS: Solaris 8 > Submission from: (NULL) (192.35.79.70) > > > I am trying to get RT-1.5.0 installed on Solaris 8. > > The programs compile fine and 'make check' seems to work. > > But when I do a 'make install' I see this: > > /home/dhouston/R-1.5.0 grieg> make install > installing afm ... > installing doc ... > installing doc/html ... > install: index.html does not exist > *** Error code 1 > make: Fatal error: Command failed for target `install' > Current working directory /home/dhouston/R-1.5.0/doc/html > *** Error code 1 > make: Fatal error: Command failed for target `install' > Current working directory /home/dhouston/R-1.5.0/doc > *** Error code 1 > make: Fatal error: Command failed for target `install' > > I do not see index.html in doc/html. I made a fake one for testing purposes, but > when I do a make install it now fails trying to find SearchEngine.html. Those should have been generated during the build, by the Makefile's in doc/html and doc/html/search. Do you perchance not have Perl installed? -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1658.audit <== Wed Jun 12 17:37:16 2002 ripley moved from incoming to Installation Mon Sep 16 13:27:14 2002 pd changed notes Mon Sep 16 13:27:14 2002 pd foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1676 * Subject: R configure.in makes bad alpha assumptions From: mcmahill@mtl.mit.edu Date: Sat, 15 Jun 2002 19:21:09 -0400 (EDT) --Probably fixed in 1.5.1 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1676 <== From postmaster@franz.stat.wisc.edu Sun Jun 16 01:21:52 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id BAA07423 for ; Sun, 16 Jun 2002 01:21:51 +0200 (MET DST) Received: from mtl.mit.edu (really [18.62.0.45]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Sat, 15 Jun 2002 18:21:10 -0500 (CDT) Received: from bitter.mit.edu (BITTER.MIT.EDU [18.62.6.13]) by mtl.mit.edu (8.9.3/8.9.3) with SMTP id TAA27047 for ; Sat, 15 Jun 2002 19:21:09 -0400 (EDT) Date: Sat, 15 Jun 2002 19:21:09 -0400 (EDT) From: mcmahill@mtl.mit.edu X-Sender: mcmahill@bitter.mit.edu Reply-To: mcmahill@mtl.mit.edu To: r-bugs@r-project.org Subject: R configure.in makes bad alpha assumptions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I was looking at configure.in for R-1.4.1 and in the case "${host_cpu}" in part under alpha CPU's, the switch of -mieee for g77 and -fpe3 otherwise is an OSF specific, not alpha specific issue. In particular, if someone used f2c-f77 (shell script which emulates a fortran compiler with f2c and the c compiler), they'd get the broken -fpe3. I'd probably either test for OSF before adding -fpe3 -dan ==> 1676.followup.1 <== From hornik@ci.tuwien.ac.at Mon Jun 17 12:07:32 2002 Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA12993 for ; Mon, 17 Jun 2002 12:07:31 +0200 (MET DST) Received: from mithrandir.hornik.net (mail@wu057056.wu-wien.ac.at [137.208.57.56]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id MAA58780emf hornik@ci.tuwien.ac.at; Mon, 17 Jun 2002 12:06:48 +0200 Received: from hornik by mithrandir.hornik.net with local (Exim 3.35 #1 (Debian)) id 17JtNQ-0002x1-00; Mon, 17 Jun 2002 12:04:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15629.46143.876111.705355@mithrandir.hornik.net> Date: Mon, 17 Jun 2002 12:04:47 +0200 To: mcmahill@mtl.mit.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: R configure.in makes bad alpha assumptions (PR#1676) In-Reply-To: <200206152321.BAA07428@pubhealth.ku.dk> References: <200206152321.BAA07428@pubhealth.ku.dk> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik >>>>> mcmahill writes: > Hi, > I was looking at configure.in for R-1.4.1 and in the > case "${host_cpu}" in > part under alpha CPU's, the switch of -mieee for g77 and -fpe3 otherwise > is an OSF specific, not alpha specific issue. In particular, if someone > used f2c-f77 (shell script which emulates a fortran compiler with f2c and > the c compiler), they'd get the broken -fpe3. I'd probably either test > for OSF before adding -fpe3 This was changed for R 1.5.0, can you pls try with this? (Or with 1.5.1 which will be released in a few moments ...) -k ==> 1676.audit <== Mon Jun 17 08:59:57 2002 ripley moved from incoming to Installation Mon Sep 16 13:28:22 2002 pd changed notes Mon Sep 16 13:28:22 2002 pd foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1829 * Subject: R config failure on solaris From: "Siva Ginjupalli" Date: Wed, 24 Jul 2002 20:08:49 +0000 --Missing info on R version and compilers. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1829 <== From postmaster@franz.stat.wisc.edu Wed Jul 24 22:09:46 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA15079 for ; Wed, 24 Jul 2002 22:09:45 +0200 (MET DST) Received: from hotmail.com (really [216.33.237.9]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Wed, 24 Jul 2002 15:09:05 -0500 (CDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Jul 2002 13:08:49 -0700 Received: from 66.12.38.242 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 24 Jul 2002 20:08:49 GMT X-Originating-IP: [66.12.38.242] From: "Siva Ginjupalli" To: r-bugs@r-project.org Subject: R config failure on solaris Date: Wed, 24 Jul 2002 20:08:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jul 2002 20:08:49.0356 (UTC) FILETIME=[EC86F0C0:01C2334D] Dear sir, This is siva Ginjupalli. I am getting following error while configuring my Solaris for "R" software. checking size of int... configure: error: cannot compute sizeof (int), 77. My solaris information as follows: uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_108528-01 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Release = 5.8 KernelID = Generic_108528-01 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 I really appreciate if you could guide me to resolve this problem. Please let me know, if you need config.log file to debug Thanks Siva _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ==> 1829.audit <== Tue Jul 30 11:53:41 2002 ripley foobar Tue Jul 30 11:53:41 2002 ripley moved from incoming to Installation Mon Sep 16 13:28:55 2002 pd changed notes Mon Sep 16 13:28:55 2002 pd foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2808 * Subject: building R 1.7.0 under RH7.3 From: Tim Hoar Date: Mon, 21 Apr 2003 13:16:16 -0600 (MDT) --This is with foreign compilers ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2808 <== From mailnull@stat.math.ethz.ch Mon Apr 21 21:17:03 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3LJH3pD003490 for ; Mon, 21 Apr 2003 21:17:03 +0200 (MET DST) Received: from hypatia.math.ethz.ch (mailnull@localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3LJH0Ua017506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Apr 2003 21:17:00 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3LJGxvE017505 for R-bugs@biostat.ku.dk; Mon, 21 Apr 2003 21:16:59 +0200 (MEST) Received: from franz.stat.wisc.edu (mail@www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3LJGmUZ017480 for ; Mon, 21 Apr 2003 21:16:49 +0200 (MEST) Received: from tablemtn.cgd.ucar.edu ([128.117.21.12]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 197gmW-0008MQ-00 for ; Mon, 21 Apr 2003 14:16:48 -0500 Received: from sunray2.cgd.ucar.edu (sunray2.cgd.ucar.edu [128.117.24.201]) by tablemtn.cgd.ucar.edu (8.12.8/8.12.8) with ESMTP id h3LJGAJT002255 for ; Mon, 21 Apr 2003 13:16:10 -0600 (MDT) Received: from localhost (thoar@localhost) by sunray2.cgd.ucar.edu (8.11.6+Sun/8.11.6) with ESMTP id h3LJGGZ24809 for ; Mon, 21 Apr 2003 13:16:16 -0600 (MDT) X-Authentication-Warning: sunray2.cgd.ucar.edu: thoar owned process doing -bs Date: Mon, 21 Apr 2003 13:16:16 -0600 (MDT) From: Tim Hoar X-Sender: Reply-To: Tim Hoar To: Subject: building R 1.7.0 under RH7.3 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-1050952576=:23064" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-7.3 required=5.0 tests=USER_AGENT_PINE,X_AUTH_WARNING version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-959030623-1050952576=:23064 Content-Type: TEXT/PLAIN; charset=US-ASCII The configure process does not seem to be working as well as it had for previous versions ... constantly seems to complain about being unable to determine environment variables. I am trying to use the PG set of compilers (because the netCDF library was built with them, and I will need to use it. I have had problems with this in the past, although particularly with the Intel Compilers). setenv R_PAPERSIZE letter setenv CC pgcc setenv F77 pgf90 setenv CXX pgCC [note ALL other environment vars are "undefined", including LD_LIBRARY_PATH] Linux poorman 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 i686 unknown RH 7.3, on a 1.7Ghz Pentium ./configure --prefix=/contrib/R-1.7.0 >& configure.attempt.1 results in two things -- The first is that there seems to be a "-x" getting fed to the PG compilers, which is not a valid option. I don't know if this is the root problem ... The second (and seemingly fatal one) is "unable to determine CPICFLAGS". So -- I set it and try again ... setenv CPICFLAGS -kpic ./configure --prefix=/contrib/R-1.7.0 >& configure.attempt.2 which generates "unable to determine FPICFLAGS" ... and the same scenario is repeated several more times, with "the next" environment variable not getting useful default values ... Anyone else report this? Thanks -- Tim ## Tim Hoar, Associate Scientist email: thoar@ucar.edu ## ## Geophysical Statistics Project phone: 303-497-1708 ## ## National Center for Atmospheric Research FAX : 303-497-1333 ## ## Boulder, CO 80307 http://www.cgd.ucar.edu/~thoar ## ---559023410-959030623-1050952576=:23064 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="configure.attempt.1" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="configure.attempt.1" Y2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGlibGUgaW5zdGFsbC4uLiAvdXNy L2Jpbi9pbnN0YWxsIC1jDQpjaGVja2luZyB3aGV0aGVyIGJ1aWxkIGVudmly b25tZW50IGlzIHNhbmUuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIG1ha2Ug c2V0cyAkKE1BS0UpLi4uIHllcw0KY2hlY2tpbmcgZm9yIHdvcmtpbmcgYWNs b2NhbC0xLjQuLi4gZm91bmQNCmNoZWNraW5nIGZvciB3b3JraW5nIGF1dG9j b25mLi4uIGZvdW5kDQpjaGVja2luZyBmb3Igd29ya2luZyBhdXRvbWFrZS0x LjQuLi4gZm91bmQNCmNoZWNraW5nIGZvciB3b3JraW5nIGF1dG9oZWFkZXIu Li4gZm91bmQNCmNoZWNraW5nIGZvciB3b3JraW5nIG1ha2VpbmZvLi4uIGZv dW5kDQpjaGVja2luZyBidWlsZCBzeXN0ZW0gdHlwZS4uLiBpNjg2LXBjLWxp bnV4LWdudQ0KY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLiBpNjg2LXBj LWxpbnV4LWdudQ0KbG9hZGluZyBzaXRlIHNjcmlwdCAnLi9jb25maWcuc2l0 ZScNCmxvYWRpbmcgYnVpbGQgc3BlY2lmaWMgc2NyaXB0ICcuL2NvbmZpZy5z aXRlJw0KY2hlY2tpbmcgZm9yIHB3ZC4uLiAvYmluL3B3ZA0KY2hlY2tpbmcg d2hldGhlciBidWlsZGRpciBpcyBzcmNkaXIuLi4geWVzDQpjaGVja2luZyBm b3IgZ2F3ay4uLiBnYXdrDQpjaGVja2luZyBmb3IgZWdyZXAuLi4gZ3JlcCAt RQ0KY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3Jrcy4uLiB5ZXMNCmNoZWNr aW5nIGZvciByYW5saWIuLi4gcmFubGliDQpjaGVja2luZyBmb3IgYmlzb24u Li4gYmlzb24gLXkNCmNoZWNraW5nIGZvciBhci4uLiBhcg0KY2hlY2tpbmcg Zm9yIGphdmFjLi4uIG5vDQpjaGVja2luZyBmb3IgbGVzcy4uLiAvdXNyL2Jp bi9sZXNzDQpjaGVja2luZyBmb3IgcGVybC4uLiAvdXNyL2xvY2FsL2Jpbi9w ZXJsDQpjaGVja2luZyB3aGV0aGVyIHBlcmwgdmVyc2lvbiBpcyBhdCBsZWFz dCA1LjAwNC4uLiB5ZXMNCmNoZWNraW5nIGZvciBkdmlwcy4uLiAvdXNyL2Jp bi9kdmlwcw0KY2hlY2tpbmcgZm9yIHRleC4uLiAvdXNyL2Jpbi90ZXgNCmNo ZWNraW5nIGZvciBsYXRleC4uLiAvdXNyL2Jpbi9sYXRleA0KY2hlY2tpbmcg Zm9yIG1ha2VpbmRleC4uLiAvdXNyL2Jpbi9tYWtlaW5kZXgNCmNoZWNraW5n IGZvciBwZGZ0ZXguLi4gL3Vzci9iaW4vcGRmdGV4DQpjaGVja2luZyBmb3Ig cGRmbGF0ZXguLi4gL3Vzci9iaW4vcGRmbGF0ZXgNCmNoZWNraW5nIGZvciBt YWtlaW5mby4uLiAvdXNyL2Jpbi9tYWtlaW5mbw0KY2hlY2tpbmcgZm9yIHVu emlwLi4uIG5vDQpjaGVja2luZyBmb3IgemlwLi4uIG5vDQpjaGVja2luZyBm b3IgZ2NjLi4uIHBnY2MNCmNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1 bHQgb3V0cHV0Li4uIGEub3V0DQpjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv bXBpbGVyIHdvcmtzLi4uIHllcw0KY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUg Y3Jvc3MgY29tcGlsaW5nLi4uIG5vDQpjaGVja2luZyBmb3Igc3VmZml4IG9m IGV4ZWN1dGFibGVzLi4uIA0KY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBvYmpl Y3QgZmlsZXMuLi4gbw0KY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcg dGhlIEdOVSBDIGNvbXBpbGVyLi4uIG5vDQpjaGVja2luZyB3aGV0aGVyIHBn Y2MgYWNjZXB0cyAtZy4uLiB5ZXMNCmNoZWNraW5nIGZvciBwZ2NjIG9wdGlv biB0byBhY2NlcHQgQU5TSSBDLi4uIG5vbmUgbmVlZGVkDQpjaGVja2luZyBm b3Igbm9uLUdOVSBsZC4uLiAvdXNyL2Jpbi9sZA0KY2hlY2tpbmcgaWYgdGhl IGxpbmtlciAoL3Vzci9iaW4vbGQpIGlzIEdOVSBsZC4uLiB5ZXMNCmNoZWNr aW5nIGZvciAvdXNyL2Jpbi9sZCBvcHRpb24gdG8gcmVsb2FkIG9iamVjdCBm aWxlcy4uLiAtcg0KY2hlY2tpbmcgZm9yIEJTRC1jb21wYXRpYmxlIG5tLi4u IC91c3IvYmluL25tIC1CDQpjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2Vz IG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4gL2Jpbi9zZWQNCmNoZWNraW5nIGhv dyB0byByZWNvZ25pc2UgZGVwZW5kZW50IGxpYnJhcmllcy4uLiBwYXNzX2Fs bA0KY2hlY2tpbmcgY29tbWFuZCB0byBwYXJzZSAvdXNyL2Jpbi9ubSAtQiBv dXRwdXQuLi4gb2sNCmNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJv Y2Vzc29yLi4uIHBnY2MgLUUNCmNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVy IGZpbGVzLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN5cy90eXBlcy5oLi4uIHll cw0KY2hlY2tpbmcgZm9yIHN5cy9zdGF0LmguLi4geWVzDQpjaGVja2luZyBm b3Igc3RkbGliLmguLi4geWVzDQpjaGVja2luZyBmb3Igc3RyaW5nLmguLi4g eWVzDQpjaGVja2luZyBmb3IgbWVtb3J5LmguLi4geWVzDQpjaGVja2luZyBm b3Igc3RyaW5ncy5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIGludHR5cGVzLmgu Li4geWVzDQpjaGVja2luZyBmb3Igc3RkaW50LmguLi4geWVzDQpjaGVja2lu ZyBmb3IgdW5pc3RkLmguLi4geWVzDQpjaGVja2luZyBkbGZjbi5oIHVzYWJp bGl0eS4uLiB5ZXMNCmNoZWNraW5nIGRsZmNuLmggcHJlc2VuY2UuLi4geWVz DQpjaGVja2luZyBmb3IgZGxmY24uaC4uLiB5ZXMNCmNoZWNraW5nIGZvciBy YW5saWIuLi4gKGNhY2hlZCkgcmFubGliDQpjaGVja2luZyBmb3Igc3RyaXAu Li4gc3RyaXANCmNoZWNraW5nIGZvciBvYmpkaXIuLi4gLmxpYnMNCmNoZWNr aW5nIGZvciBwZ2NjIG9wdGlvbiB0byBwcm9kdWNlIFBJQy4uLiBub25lDQpj aGVja2luZyBpZiBwZ2NjIHN0YXRpYyBmbGFnICB3b3Jrcy4uLiB5ZXMNCmNo ZWNraW5nIGlmIHBnY2Mgc3VwcG9ydHMgLWMgLW8gZmlsZS5vLi4uIHllcw0K Y2hlY2tpbmcgaWYgcGdjYyBzdXBwb3J0cyAtYyAtbyBmaWxlLmxvLi4uIHll cw0KY2hlY2tpbmcgd2hldGhlciB0aGUgbGlua2VyICgvdXNyL2Jpbi9sZCkg c3VwcG9ydHMgc2hhcmVkIGxpYnJhcmllcy4uLiB5ZXMNCmNoZWNraW5nIGhv dyB0byBoYXJkY29kZSBsaWJyYXJ5IHBhdGhzIGludG8gcHJvZ3JhbXMuLi4g aW1tZWRpYXRlDQpjaGVja2luZyB3aGV0aGVyIHN0cmlwcGluZyBsaWJyYXJp ZXMgaXMgcG9zc2libGUuLi4geWVzDQpjaGVja2luZyBkeW5hbWljIGxpbmtl ciBjaGFyYWN0ZXJpc3RpY3MuLi4gR05VL0xpbnV4IGxkLnNvDQpjaGVja2lu ZyBpZiBsaWJ0b29sIHN1cHBvcnRzIHNoYXJlZCBsaWJyYXJpZXMuLi4gbm8N CmNoZWNraW5nIHdoZXRoZXIgdG8gYnVpbGQgc2hhcmVkIGxpYnJhcmllcy4u LiBubw0KY2hlY2tpbmcgd2hldGhlciB0byBidWlsZCBzdGF0aWMgbGlicmFy aWVzLi4uIHllcw0KY3JlYXRpbmcgbGlidG9vbA0KY2hlY2tpbmcgd2hldGhl ciBtYWtlaW5mbyB2ZXJzaW9uIGlzIGF0IGxlYXN0IDQuLi4geWVzDQpjaGVj a2luZyBmb3IgbmV0c2NhcGUuLi4gL3Vzci9iaW4vbmV0c2NhcGUNCnVzaW5n IGRlZmF1bHQgYnJvd3NlciAuLi4gL3Vzci9iaW4vbmV0c2NhcGUNCmNoZWNr aW5nIGZvciBhY3JvcmVhZC4uLiAvdXNyL2xvY2FsL2Jpbi9hY3JvcmVhZA0K Y2hlY2tpbmcgZm9yIGdjYy4uLiAoY2FjaGVkKSBwZ2NjDQpjaGVja2luZyB3 aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIuLi4gKGNh Y2hlZCkgbm8NCmNoZWNraW5nIHdoZXRoZXIgcGdjYyBhY2NlcHRzIC1nLi4u IChjYWNoZWQpIHllcw0KY2hlY2tpbmcgZm9yIHBnY2Mgb3B0aW9uIHRvIGFj Y2VwdCBBTlNJIEMuLi4gKGNhY2hlZCkgbm9uZSBuZWVkZWQNCmNoZWNraW5n IGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yLi4uIHBnY2MgLUUNCmRl ZmluaW5nIEY3NyB0byBiZSBwZ2Y5MA0KY2hlY2tpbmcgd2hldGhlciB3ZSBh cmUgdXNpbmcgdGhlIEdOVSBGb3J0cmFuIDc3IGNvbXBpbGVyLi4uIG5vDQpj aGVja2luZyB3aGV0aGVyIHBnZjkwIGFjY2VwdHMgLWcuLi4geWVzDQpjaGVj a2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMrKyBjb21waWxl ci4uLiBubw0KY2hlY2tpbmcgd2hldGhlciBwZ0NDIGFjY2VwdHMgLWcuLi4g eWVzDQpjaGVja2luZyBob3cgdG8gcnVuIHRoZSBDKysgcHJlcHJvY2Vzc29y Li4uIHBnQ0MgLUUNCmNoZWNraW5nIGZvciBtYWluIGluIC1sbS4uLiB5ZXMN CmNoZWNraW5nIGZvciBzaW4gaW4gLWxtLi4uIHllcw0KY2hlY2tpbmcgZm9y IG1haW4gaW4gLWxuY3Vyc2VzLi4uIHllcw0KY2hlY2tpbmcgZm9yIGRsb3Bl biBpbiAtbGRsLi4uIHllcw0KY2hlY2tpbmcgZm9yIHJsX2NhbGxiYWNrX3Jl YWRfY2hhciBpbiAtbHJlYWRsaW5lLi4uIHllcw0KY2hlY2tpbmcgZm9yIEFO U0kgQyBoZWFkZXIgZmlsZXMuLi4gKGNhY2hlZCkgeWVzDQpjaGVja2luZyB3 aGV0aGVyIHRpbWUuaCBhbmQgc3lzL3RpbWUuaCBtYXkgYm90aCBiZSBpbmNs dWRlZC4uLiB5ZXMNCmNoZWNraW5nIGZvciBkaXJlbnQuaCB0aGF0IGRlZmlu ZXMgRElSLi4uIHllcw0KY2hlY2tpbmcgZm9yIGxpYnJhcnkgY29udGFpbmlu ZyBvcGVuZGlyLi4uIG5vbmUgcmVxdWlyZWQNCmNoZWNraW5nIGZvciBzeXMv d2FpdC5oIHRoYXQgaXMgUE9TSVguMSBjb21wYXRpYmxlLi4uIHllcw0KY2hl Y2tpbmcgYXJwYS9pbmV0LmggdXNhYmlsaXR5Li4uIHllcw0KY2hlY2tpbmcg YXJwYS9pbmV0LmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3IgYXJw YS9pbmV0LmguLi4geWVzDQpjaGVja2luZyBkbC5oIHVzYWJpbGl0eS4uLiBu bw0KY2hlY2tpbmcgZGwuaCBwcmVzZW5jZS4uLiBubw0KY2hlY2tpbmcgZm9y IGRsLmguLi4gbm8NCmNoZWNraW5nIGZvciBkbGZjbi5oLi4uIChjYWNoZWQp IHllcw0KY2hlY2tpbmcgZWxmLmggdXNhYmlsaXR5Li4uIHllcw0KY2hlY2tp bmcgZWxmLmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3IgZWxmLmgu Li4geWVzDQpjaGVja2luZyBmY250bC5oIHVzYWJpbGl0eS4uLiB5ZXMNCmNo ZWNraW5nIGZjbnRsLmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3Ig ZmNudGwuaC4uLiB5ZXMNCmNoZWNraW5nIGZsb2F0aW5ncG9pbnQuaCB1c2Fi aWxpdHkuLi4gbm8NCmNoZWNraW5nIGZsb2F0aW5ncG9pbnQuaCBwcmVzZW5j ZS4uLiBubw0KY2hlY2tpbmcgZm9yIGZsb2F0aW5ncG9pbnQuaC4uLiBubw0K Y2hlY2tpbmcgZnB1X2NvbnRyb2wuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVj a2luZyBmcHVfY29udHJvbC5oIHByZXNlbmNlLi4uIHllcw0KY2hlY2tpbmcg Zm9yIGZwdV9jb250cm9sLmguLi4geWVzDQpjaGVja2luZyBncnAuaCB1c2Fi aWxpdHkuLi4geWVzDQpjaGVja2luZyBncnAuaCBwcmVzZW5jZS4uLiB5ZXMN CmNoZWNraW5nIGZvciBncnAuaC4uLiB5ZXMNCmNoZWNraW5nIGllZWU3NTQu aCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyBpZWVlNzU0LmggcHJlc2Vu Y2UuLi4geWVzDQpjaGVja2luZyBmb3IgaWVlZTc1NC5oLi4uIHllcw0KY2hl Y2tpbmcgaWVlZWZwLmggdXNhYmlsaXR5Li4uIG5vDQpjaGVja2luZyBpZWVl ZnAuaCBwcmVzZW5jZS4uLiBubw0KY2hlY2tpbmcgZm9yIGllZWVmcC5oLi4u IG5vDQpjaGVja2luZyBsb2NhbGUuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVj a2luZyBsb2NhbGUuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBs b2NhbGUuaC4uLiB5ZXMNCmNoZWNraW5nIG5ldGRiLmggdXNhYmlsaXR5Li4u IHllcw0KY2hlY2tpbmcgbmV0ZGIuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNr aW5nIGZvciBuZXRkYi5oLi4uIHllcw0KY2hlY2tpbmcgbmV0aW5ldC9pbi5o IHVzYWJpbGl0eS4uLiB5ZXMNCmNoZWNraW5nIG5ldGluZXQvaW4uaCBwcmVz ZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBuZXRpbmV0L2luLmguLi4geWVz DQpjaGVja2luZyBwd2QuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyBw d2QuaCBwcmVzZW5jZS4uLiB5ZXMNCmNoZWNraW5nIGZvciBwd2QuaC4uLiB5 ZXMNCmNoZWNraW5nIHJlYWRsaW5lL2hpc3RvcnkuaCB1c2FiaWxpdHkuLi4g eWVzDQpjaGVja2luZyByZWFkbGluZS9oaXN0b3J5LmggcHJlc2VuY2UuLi4g eWVzDQpjaGVja2luZyBmb3IgcmVhZGxpbmUvaGlzdG9yeS5oLi4uIHllcw0K Y2hlY2tpbmcgcmVhZGxpbmUvcmVhZGxpbmUuaCB1c2FiaWxpdHkuLi4geWVz DQpjaGVja2luZyByZWFkbGluZS9yZWFkbGluZS5oIHByZXNlbmNlLi4uIHll cw0KY2hlY2tpbmcgZm9yIHJlYWRsaW5lL3JlYWRsaW5lLmguLi4geWVzDQpj aGVja2luZyBmb3Igc3RyaW5ncy5oLi4uIChjYWNoZWQpIHllcw0KY2hlY2tp bmcgc3lzL3BhcmFtLmggdXNhYmlsaXR5Li4uIHllcw0KY2hlY2tpbmcgc3lz L3BhcmFtLmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3Igc3lzL3Bh cmFtLmguLi4geWVzDQpjaGVja2luZyBzeXMvc2VsZWN0LmggdXNhYmlsaXR5 Li4uIHllcw0KY2hlY2tpbmcgc3lzL3NlbGVjdC5oIHByZXNlbmNlLi4uIHll cw0KY2hlY2tpbmcgZm9yIHN5cy9zZWxlY3QuaC4uLiB5ZXMNCmNoZWNraW5n IHN5cy9zb2NrZXQuaCB1c2FiaWxpdHkuLi4geWVzDQpjaGVja2luZyBzeXMv c29ja2V0LmggcHJlc2VuY2UuLi4geWVzDQpjaGVja2luZyBmb3Igc3lzL3Nv Y2tldC5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN5cy9zdGF0LmguLi4gKGNh Y2hlZCkgeWVzDQpjaGVja2luZyBzeXMvdGltZS5oIHVzYWJpbGl0eS4uLiB5 ZXMNCmNoZWNraW5nIHN5cy90aW1lLmggcHJlc2VuY2UuLi4geWVzDQpjaGVj a2luZyBmb3Igc3lzL3RpbWUuaC4uLiB5ZXMNCmNoZWNraW5nIHN5cy90aW1l cy5oIHVzYWJpbGl0eS4uLiB5ZXMNCmNoZWNraW5nIHN5cy90aW1lcy5oIHBy ZXNlbmNlLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN5cy90aW1lcy5oLi4uIHll cw0KY2hlY2tpbmcgc3lzL3V0c25hbWUuaCB1c2FiaWxpdHkuLi4geWVzDQpj aGVja2luZyBzeXMvdXRzbmFtZS5oIHByZXNlbmNlLi4uIHllcw0KY2hlY2tp bmcgZm9yIHN5cy91dHNuYW1lLmguLi4geWVzDQpjaGVja2luZyBmb3IgdW5p c3RkLmguLi4gKGNhY2hlZCkgeWVzDQpjaGVja2luZyBlcnJuby5oIHVzYWJp bGl0eS4uLiB5ZXMNCmNoZWNraW5nIGVycm5vLmggcHJlc2VuY2UuLi4geWVz DQpjaGVja2luZyBmb3IgZXJybm8uaC4uLiB5ZXMNCmNoZWNraW5nIHN0ZGFy Zy5oIHVzYWJpbGl0eS4uLiB5ZXMNCmNoZWNraW5nIHN0ZGFyZy5oIHByZXNl bmNlLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0ZGFyZy5oLi4uIHllcw0KY2hl Y2tpbmcgZm9yIHN0cmluZy5oLi4uIChjYWNoZWQpIHllcw0KY2hlY2tpbmcg d2hldGhlciBzZXRqbXAuaCBpcyBQT1NJWC4xIGNvbXBhdGlibGUuLi4geWVz DQpjaGVja2luZyBmb3IgR05VIEMgbGlicmFyeSB3aXRoIHZlcnNpb24gPj0g Mi4uLiB5ZXMNCmNoZWNraW5nIHJldHVybiB0eXBlIG9mIHNpZ25hbCBoYW5k bGVycy4uLiB2b2lkDQpjaGVja2luZyBmb3IgcGlkX3QuLi4geWVzDQpjaGVj a2luZyBmb3Igc2l6ZV90Li4uIHllcw0KY2hlY2tpbmcgZm9yIGJsa2NudF90 Li4uIHllcw0KY2hlY2tpbmcgZm9yIHR5cGUgb2Ygc29ja2V0IGxlbmd0aC4u LiBzb2NrbGVuX3QgKg0KY2hlY2tpbmcgd2hldGhlciBieXRlIG9yZGVyaW5n IGlzIGJpZ2VuZGlhbi4uLiBubw0KY2hlY2tpbmcgZm9yIGFuIEFOU0kgQy1j b25mb3JtaW5nIGNvbnN0Li4uIHllcw0KY2hlY2tpbmcgZm9yIGludC4uLiB5 ZXMNCmNoZWNraW5nIHNpemUgb2YgaW50Li4uIDQNCmNoZWNraW5nIGZvciBs b25nLi4uIHllcw0KY2hlY2tpbmcgc2l6ZSBvZiBsb25nLi4uIDQNCmNoZWNr aW5nIGZvciBsb25nIGxvbmcuLi4geWVzDQpjaGVja2luZyBzaXplIG9mIGxv bmcgbG9uZy4uLiA4DQpjaGVja2luZyBmb3IgbG9uZyBkb3VibGUuLi4geWVz DQpjaGVja2luZyBzaXplIG9mIGxvbmcgZG91YmxlLi4uIDgNCmNoZWNraW5n IHdoZXRoZXIgd2UgY2FuIGNvbXB1dGUgQyBNYWtlIGRlcGVuZGVuY2llcy4u LiB5ZXMsIHVzaW5nIGNwcCAtTQ0KY2hlY2tpbmcgd2hldGhlciBwZ2NjIHN1 cHBvcnRzIC1jIC1vIEZJTEUubG8uLi4geWVzDQpjaGVja2luZyBob3cgdG8g Z2V0IHZlcmJvc2UgbGlua2luZyBvdXRwdXQgZnJvbSBwZ2Y5MC4uLiAtdg0K Y2hlY2tpbmcgZm9yIEZvcnRyYW4gNzcgbGlicmFyaWVzLi4uICAtTC91c3Iv bG9jYWwvbGliIC1ML3Vzci9sb2NhbC9wZ2kvbGludXg4Ni9saWIgLUwvdXNy L2xpYiAtTC91c3IvbGliL2djYy1saWIvaTM4Ni1yZWRoYXQtbGludXgvMi45 NiAtbHBnZjkwIC1scGdmOTBfcnBtMSAtbHBnZjkwMiAtbHBnZjkwcnRsIC1s cGdmdG5ydGwgLWxtIC1scGdjDQpjaGVja2luZyBmb3IgZHVtbXkgbWFpbiB0 byBsaW5rIHdpdGggRm9ydHJhbiA3NyBsaWJyYXJpZXMuLi4gbm9uZQ0KY2hl Y2tpbmcgZm9yIEZvcnRyYW4gNzcgbmFtZS1tYW5nbGluZyBzY2hlbWUuLi4g bG93ZXIgY2FzZSwgdW5kZXJzY29yZSwgbm8gZXh0cmEgdW5kZXJzY29yZQ0K Y2hlY2tpbmcgd2hldGhlciBwZ2Y5MCBhcHBlbmRzIHVuZGVyc2NvcmVzIHRv IGV4dGVybmFsIG5hbWVzLi4uIHllcw0KY2hlY2tpbmcgd2hldGhlciBtaXhl ZCBDL0ZvcnRyYW4gY29kZSBjYW4gYmUgcnVuLi4uIHllcw0KY2hlY2tpbmcg d2hldGhlciBwZ2Y5MCBhbmQgcGdjYyBhZ3JlZSBvbiBpbnQgYW5kIGRvdWJs ZS4uLiB5ZXMNCmNoZWNraW5nIHdoZXRoZXIgcGdmOTAgYW5kIHBnY2MgYWdy ZWUgb24gZG91YmxlIGNvbXBsZXguLi4geWVzDQpjaGVja2luZyB3aGV0aGVy IHBnZjkwIHN1cHBvcnRzIC1jIC1vIEZJTEUubG8uLi4geWVzDQpjaGVja2lu ZyB3aGV0aGVyIHBnQ0MgYWNjZXB0cyAtTSBmb3IgZ2VuZXJhdGluZyBkZXBl bmRlbmNpZXMuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIHBnQ0Mgc3VwcG9y dHMgLWMgLW8gRklMRS5sby4uLiB5ZXMNCmNoZWNraW5nIHdoZXRoZXIgcGdj YyBhY2NlcHRzIC1taWVlZS1mcC4uLiB5ZXMNCmNoZWNraW5nIHdoZXRoZXIg cGdmOTAgYWNjZXB0cyAtbWllZWUtZnAuLi4geWVzDQpjaGVja2luZyB3aGV0 aGVyIHBnQ0MgYWNjZXB0cyAtbWllZWUtZnAuLi4geWVzDQpjaGVja2luZyBm b3IgeG1rbWYuLi4gL3Vzci9YMTFSNi9iaW4veG1rbWYNCnBnY2MtV2Fybmlu Zy1Vbmtub3duIHN3aXRjaDogLXgNCnBnY2MtV2FybmluZy1Vbmtub3duIHN3 aXRjaDogLQ0KRmlsZSB3aXRoIHVua25vd24gc3VmZml4IHBhc3NlZCB0byBs aW5rZXI6IGMNCi91c3IvYmluL2xkOiBjYW5ub3Qgb3BlbiBjOiBObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5DQovdXNyL1gxMVI2L2Jpbi94bWttZjogbGlu ZSA3MDogIDcyMDcgQWJvcnRlZCAgICAgICAgICAgICAgICAgKGNvcmUgZHVt cGVkKSBpbWFrZSAkaW1ha2VfZGVmaW5lcyAkYXJncw0KVXNhZ2U6IHdoaWNo IFtvcHRpb25zXSBbLS1dIHByb2dyYW1uYW1lIFsuLi5dDQpPcHRpb25zOiAt LXZlcnNpb24sIC1bdlZdIFByaW50IHZlcnNpb24gYW5kIGV4aXQgc3VjY2Vz c2Z1bGx5Lg0KICAgICAgICAgLS1oZWxwLCAgICAgICAgICBQcmludCB0aGlz IGhlbHAgYW5kIGV4aXQgc3VjY2Vzc2Z1bGx5Lg0KICAgICAgICAgLS1za2lw LWRvdCAgICAgICBTa2lwIGRpcmVjdG9yaWVzIGluIFBBVEggdGhhdCBzdGFy dCB3aXRoIGEgZG90Lg0KICAgICAgICAgLS1za2lwLXRpbGRlICAgICBTa2lw IGRpcmVjdG9yaWVzIGluIFBBVEggdGhhdCBzdGFydCB3aXRoIGEgdGlsZGUu DQogICAgICAgICAtLXNob3ctZG90ICAgICAgIERvbid0IGV4cGFuZCBhIGRv dCB0byBjdXJyZW50IGRpcmVjdG9yeSBpbiBvdXRwdXQuDQogICAgICAgICAt LXNob3ctdGlsZGUgICAgIE91dHB1dCBhIHRpbGRlIGZvciBIT01FIGRpcmVj dG9yeSBmb3Igbm9uLXJvb3QuDQogICAgICAgICAtLXR0eS1vbmx5ICAgICAg IFN0b3AgcHJvY2Vzc2luZyBvcHRpb25zIG9uIHRoZSByaWdodCBpZiBub3Qg b24gdHR5Lg0KICAgICAgICAgLS1hbGwsIC1hICAgICAgICBQcmludCBhbGwg bWF0Y2hlcyBpbiBQQVRILCBub3QganVzdCB0aGUgZmlyc3QNCiAgICAgICAg IC0tcmVhZC1hbGlhcywgLWkgUmVhZCBsaXN0IG9mIGFsaWFzZXMgZnJvbSBz dGRpbi4NCiAgICAgICAgIC0tc2tpcC1hbGlhcyAgICAgSWdub3JlIG9wdGlv biAtLXJlYWQtYWxpYXM7IGRvbid0IHJlYWQgc3RkaW4uDQogICAgICAgICAt LXJlYWQtZnVuY3Rpb25zIFJlYWQgc2hlbGwgZnVuY3Rpb25zIGZyb20gc3Rk aW4uDQogICAgICAgICAtLXNraXAtZnVuY3Rpb25zIElnbm9yZSBvcHRpb24g LS1yZWFkLWZ1bmN0aW9uczsgZG9uJ3QgcmVhZCBzdGRpbi4NClVzYWdlOiB3 aGljaCBbb3B0aW9uc10gWy0tXSBwcm9ncmFtbmFtZSBbLi4uXQ0KT3B0aW9u czogLS12ZXJzaW9uLCAtW3ZWXSBQcmludCB2ZXJzaW9uIGFuZCBleGl0IHN1 Y2Nlc3NmdWxseS4NCiAgICAgICAgIC0taGVscCwgICAgICAgICAgUHJpbnQg dGhpcyBoZWxwIGFuZCBleGl0IHN1Y2Nlc3NmdWxseS4NCiAgICAgICAgIC0t c2tpcC1kb3QgICAgICAgU2tpcCBkaXJlY3RvcmllcyBpbiBQQVRIIHRoYXQg c3RhcnQgd2l0aCBhIGRvdC4NCiAgICAgICAgIC0tc2tpcC10aWxkZSAgICAg U2tpcCBkaXJlY3RvcmllcyBpbiBQQVRIIHRoYXQgc3RhcnQgd2l0aCBhIHRp bGRlLg0KICAgICAgICAgLS1zaG93LWRvdCAgICAgICBEb24ndCBleHBhbmQg YSBkb3QgdG8gY3VycmVudCBkaXJlY3RvcnkgaW4gb3V0cHV0Lg0KICAgICAg ICAgLS1zaG93LXRpbGRlICAgICBPdXRwdXQgYSB0aWxkZSBmb3IgSE9NRSBk aXJlY3RvcnkgZm9yIG5vbi1yb290Lg0KICAgICAgICAgLS10dHktb25seSAg ICAgICBTdG9wIHByb2Nlc3Npbmcgb3B0aW9ucyBvbiB0aGUgcmlnaHQgaWYg bm90IG9uIHR0eS4NCiAgICAgICAgIC0tYWxsLCAtYSAgICAgICAgUHJpbnQg YWxsIG1hdGNoZXMgaW4gUEFUSCwgbm90IGp1c3QgdGhlIGZpcnN0DQogICAg ICAgICAtLXJlYWQtYWxpYXMsIC1pIFJlYWQgbGlzdCBvZiBhbGlhc2VzIGZy b20gc3RkaW4uDQogICAgICAgICAtLXNraXAtYWxpYXMgICAgIElnbm9yZSBv cHRpb24gLS1yZWFkLWFsaWFzOyBkb24ndCByZWFkIHN0ZGluLg0KICAgICAg ICAgLS1yZWFkLWZ1bmN0aW9ucyBSZWFkIHNoZWxsIGZ1bmN0aW9ucyBmcm9t IHN0ZGluLg0KICAgICAgICAgLS1za2lwLWZ1bmN0aW9ucyBJZ25vcmUgb3B0 aW9uIC0tcmVhZC1mdW5jdGlvbnM7IGRvbid0IHJlYWQgc3RkaW4uDQpjb25m aWd1cmU6IFdBUk5JTkc6IEkgY291bGQgbm90IGRldGVybWluZSBDUElDRkxB R1MuDQpjb25maWd1cmU6IGVycm9yOiBTZWUgdGhlIGZpbGUgSU5TVEFMTCBm b3IgbW9yZSBpbmZvcm1hdGlvbi4NCg== ---559023410-959030623-1050952576=:23064-- ==> 2808.audit <== Thu May 29 09:42:14 2003 ripley changed notes Thu May 29 09:42:14 2003 ripley foobar Thu May 29 09:42:14 2003 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2878 * Subject: Problem with R CMD INSTALL and package versions From: rpeng@stat.ucla.edu Date: Wed, 30 Apr 2003 08:23:12 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2878 <== From rpeng@stat.ucla.edu Wed Apr 30 08:23:13 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3U6NC2b000284 for ; Wed, 30 Apr 2003 08:23:13 +0200 (MET DST) Date: Wed, 30 Apr 2003 08:23:12 +0200 (MET DST) Message-Id: <200304300623.h3U6NC2b000284@pubhealth.ku.dk> From: rpeng@stat.ucla.edu To: R-bugs@biostat.ku.dk Subject: Problem with R CMD INSTALL and package versions Full_Name: Roger Peng Version: 1.7.0 OS: Linux (Red Hat 8.0) Submission from: (NULL) (68.64.112.179) There seems to be a problem with R CMD INSTALL using --with-package-versions. First, when using --save and --with-package-versions together, I get the following output (in this case, for the `snow' package): -- marla:> R CMD INSTALL --save --with-package-versions snow_0.1-1.tar.gz * Installing *source* package 'snow' as 'snow_0.1-1' ... ** R ** inst ** save image cat: /home/rpeng/install/R-1.7.0/lib/R/library/snow_0.1-1/R/snow: No such file or directory mv: cannot stat `/home/rpeng/install/R-1.7.0/lib/R/library/snow_0.1-1/R/snow': No such file or directory ** help >>> Building/Updating help pages for package 'snow' Formats: text html latex example snow-cluster text html latex example snow-internal text html latex snow-parallel text html latex example snow-rand text html latex example snow-startstop text html latex example * DONE (snow) * DONE (INSTALL) -- When trying to load the package in R, I get: > library(snow, version = "0.1-1") Error in .path.package("snow") : none of the packages are loaded Error in library(snow, version = "0.1-1") : .First.lib failed Using install.packages() with `installWithVers = TRUE' produces the same problem. Removing the --with-package-versions flag makes the package install as expected. Removing the --save flag (but keeping the --with-package-versions flag) gets rid of the complaint during the install process, but I get the same error when trying to load the package in R. I haven't tried this with too many packages but I alwasy get the same behavior. I first noticed this when trying to install `pixmap' and `gpclib' packages with versions since they are both installed using --save. -roger ==> 2878.audit <== Thu May 22 23:01:16 2003 thomas moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3282 * Subject: 1.7.1 make check fails From: "Richard A. O'Keefe" Date: Wed, 18 Jun 2003 17:31:21 +1200 (NZST) --problem with tcltk--await further information ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3282 <== From mailnull@stat.math.ethz.ch Wed Jun 18 07:32:04 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h5I5W3JH010771 for ; Wed, 18 Jun 2003 07:32:03 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5I5Vt4U016515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2003 07:31:56 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h5I5VtGV016514 for R-bugs@biostat.ku.dk; Wed, 18 Jun 2003 07:31:55 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5I5Vn4T016494 for ; Wed, 18 Jun 2003 07:31:50 +0200 (MEST) Received: from mailhub1.otago.ac.nz ([139.80.64.218]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19SVYA-0007iY-00 for ; Wed, 18 Jun 2003 00:32:02 -0500 Received: (from root@localhost) by mailhub1.otago.ac.nz (8.12.9/8.12.9) id h5I5VM1a021671 for r-bugs@r-project.org; Wed, 18 Jun 2003 17:31:22 +1200 Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250]) by mailhub1.otago.ac.nz (8.12.9/8.12.9) with ESMTP id h5I5VMJ7021645 for ; Wed, 18 Jun 2003 17:31:22 +1200 Received: (from ok@localhost) by atlas.otago.ac.nz (8.12.9/8.12.9) id h5I5VLRj448487 for r-bugs@r-project.org; Wed, 18 Jun 2003 17:31:21 +1200 (NZST) Date: Wed, 18 Jun 2003 17:31:21 +1200 (NZST) From: "Richard A. O'Keefe" Message-Id: <200306180531.h5I5VLRj448487@atlas.otago.ac.nz> To: r-bugs@r-project.org Subject: 1.7.1 make check fails X-scanner: scanned by Inflex 1.0.12.7 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) uname -a => SunOS frege 5.9 Generic_112233-04 sun4u sparc SUNW,Sun-Blade-100 Today I downloaded R-1.7.1.tgz, unpacked it, did ./configure and ran make. All apparently went well. Then I did make check. On rerunning make check (because I forgot to save the output the first time), I get f% make check `Makedeps' is up to date. `base-Ex.Rout' is up to date. `ctest-Ex.Rout' is up to date. `eda-Ex.Rout' is up to date. `lqs-Ex.Rout' is up to date. `methods-Ex.Rout' is up to date. `modreg-Ex.Rout' is up to date. `mva-Ex.Rout' is up to date. `nls-Ex.Rout' is up to date. `splines-Ex.Rout' is up to date. `stepfun-Ex.Rout' is up to date. running code in 'tcltk-Ex.R' ...*** Error code 1 make: Fatal error: Command failed for target `tcltk-Ex.Rout' Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests/Examples *** Error code 1 make: Fatal error: Command failed for target `test-Examples-Base' Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests/Examples *** Error code 1 make: Fatal error: Command failed for target `test-Examples' Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests *** Error code 1 make: Fatal error: Command failed for target `test-all-basics' Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests *** Error code 1 make: Fatal error: Command failed for target `check' What's going on here? How worried should I be? What do I need to fix? Will R work if I tell it to use Sun's C, C++, and Fortran compilers? How do I tell it to do that? ==> 3282.followup.1 <== From ripley@stats.ox.ac.uk Wed Jun 18 08:08:59 2003 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h5I68wJH010919 for ; Wed, 18 Jun 2003 08:08:59 +0200 (MET DST) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.9/8.12.9) with ESMTP id h5I68wVh002660; Wed, 18 Jun 2003 07:08:58 +0100 (BST) Date: Wed, 18 Jun 2003 07:08:58 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: ok@cs.otago.ac.nz cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] 1.7.1 make check fails (PR#3282) In-Reply-To: <200306180532.h5I5W5JH010775@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Where is the bug? Please ask on R-help for help installing R, after reading the R-admin manual to which the INSTALL file refers you. On Wed, 18 Jun 2003 ok@cs.otago.ac.nz wrote: > uname -a => SunOS frege 5.9 Generic_112233-04 sun4u sparc SUNW,Sun-Blade-100 > Today I downloaded R-1.7.1.tgz, > unpacked it, > did ./configure > and ran make. > All apparently went well. > Then I did make check. > On rerunning make check (because I forgot to save the output the first > time), I get > > f% make check > `Makedeps' is up to date. > `base-Ex.Rout' is up to date. > `ctest-Ex.Rout' is up to date. > `eda-Ex.Rout' is up to date. > `lqs-Ex.Rout' is up to date. > `methods-Ex.Rout' is up to date. > `modreg-Ex.Rout' is up to date. > `mva-Ex.Rout' is up to date. > `nls-Ex.Rout' is up to date. > `splines-Ex.Rout' is up to date. > `stepfun-Ex.Rout' is up to date. > running code in 'tcltk-Ex.R' ...*** Error code 1 > make: Fatal error: Command failed for target `tcltk-Ex.Rout' > Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests/Examples > *** Error code 1 > make: Fatal error: Command failed for target `test-Examples-Base' > Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests/Examples > *** Error code 1 > make: Fatal error: Command failed for target `test-Examples' > Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests > *** Error code 1 > make: Fatal error: Command failed for target `test-all-basics' > Current working directory /home/users/okeefe_r/commands.d/sources/stats/R-1.7.1/tests > *** Error code 1 > make: Fatal error: Command failed for target `check' > > What's going on here? How worried should I be? What do I need to fix? You need to read tests/Examples/tcltk-Ex.Rout.fail to find out. My guess is that your Tcl/Tk installation is not complete/compatible with your compilers/.... You could build without Tcl/Tk if you don't want it. > Will R work if I tell it to use Sun's C, C++, and Fortran compilers? > How do I tell it to do that? Yes. This is in the R-admin manual, which the INSTALL file asks you to read. It discusses Tcl/Tk compatibility issues too, and how to build without it. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 3282.audit <== Wed Jun 18 17:18:52 2003 ripley changed notes Wed Jun 18 17:18:52 2003 ripley foobar Wed Jun 18 17:18:52 2003 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3485 * Subject: Undefined subroutine &R::Rdconv::fill From: michael.t.klinglesmith@intel.com Date: Tue, 15 Jul 2003 18:56:23 +0200 (MET DST) --This was perl 5.004_4 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3485 <== From michael.t.klinglesmith@intel.com Tue Jul 15 18:56:24 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h6FGuNJH000871 for ; Tue, 15 Jul 2003 18:56:23 +0200 (MET DST) Date: Tue, 15 Jul 2003 18:56:23 +0200 (MET DST) Message-Id: <200307151656.h6FGuNJH000871@pubhealth.ku.dk> From: michael.t.klinglesmith@intel.com To: R-bugs@biostat.ku.dk Subject: Undefined subroutine &R::Rdconv::fill Full_Name: michael klinglemsith Version: R-1.7.1 OS: linux Submission from: (NULL) (134.134.136.4) I run: (note: ] is my unix prompt) ]./configure It seems to work, here are the messages I get from the end of configure: R is now configured for i686-pc-linux-gnu Source directory: . Installation directory: /usr/local C compiler: gcc -D__NO_MATH_INLINES -mieee-fp -g -O2 C++ compiler: g++ -mieee-fp -g -O2 Fortran compiler: g77 -mieee-fp -g -O2 Interfaces supported: X11, tcltk External libraries: readline Additional capabilities: PNG, JPEG, bzip2, PCRE Options enabled: R profiling Recommended packages: yes configure: WARNING: you cannot build info versions of the R manuals configure: WARNING: you cannot build PDF versions of the R manuals Next I run: ]make I get this error (many times -- this is the first one): make[1]: Leaving directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/doc' make[1]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' building all R object docs (text, HTML, LaTeX, examples) make[2]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' Undefined subroutine &R::Rdconv::fill called at /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm line 1955, chunk 381. The make continues inspite of the errors until this point: make[2]: Leaving directory `/tmp/R.INSTALL.11978/survival/src' ** R ** data ** inst ** help Undefined subroutine &R::Rdconv::fill called at /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm line 1955, chunk 436. make[1]: *** [survival.ts] Error 6 >>> Building/Updating help pages for package 'survival' Formats: text html latex example ERROR: building help failed for package 'survival' make[1]: Leaving directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library/Recommended' make: *** [stamp-recommended] Error 2 ] Here are the OS and tool versions I have: ]uname -a Linux plxc1679 2.4.9-41lxset1 #1 Mon Mar 31 11:19:02 PST 2003 i686 unknown ]make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-redhat-linux-gnu Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . ]perl -v This is perl, version 5.004_04 built for i386_linux22 Copyright 1987-1997, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5.0 source kit. ]gcc -v Reading specs from /usr/intel/pkgs/gcc/3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs Configured with: ../gcc-3.1/configure --prefix=/usr/intel/pkgs/gcc/3.1 --enable-shared --enable-threads --with-gnu-as --with-as=/usr/intel/pkgs/gcc/3.1/bin/gas --with-gnu-ld --with-ld=/usr/intel/pkgs/gcc/3.1/bin/gld Thread model: posix gcc version 3.1 ] ==> 3485.reply.1 <== From p.dalgaard@biostat.ku.dk Wed Jul 16 00:28:06 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h6FMS6JH002708; Wed, 16 Jul 2003 00:28:06 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h6FMVP8e017196; Wed, 16 Jul 2003 00:31:25 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h6FMVP6M017192; Wed, 16 Jul 2003 00:31:25 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: michael.t.klinglesmith@intel.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) References: <200307151656.h6FGuOJH000875@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 16 Jul 2003 00:31:24 +0200 In-Reply-To: <200307151656.h6FGuOJH000875@pubhealth.ku.dk> Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii michael.t.klinglesmith@intel.com writes: > make[1]: Leaving directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/doc' > make[1]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' > building all R object docs (text, HTML, LaTeX, examples) > make[2]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' > Undefined subroutine &R::Rdconv::fill called at > /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm line 1955, > chunk 381. .... > ]perl -v > > This is perl, version 5.004_04 built for i386_linux22 > > Copyright 1987-1997, Larry Wall I would suspect that this is the culprit. We do check that the perl version is at least 5.004 so we expect your version to work, but on the other hand it is quite old (~ 6 years it would seem) and quite likely noone actually checked against that version when making changes to Rdconv. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 3485.followup.1 <== From michael.t.klinglesmith@intel.com Wed Jul 16 01:54:05 2003 Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h6FNs3JH003086; Wed, 16 Jul 2003 01:54:04 +0200 (MET DST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h6FNmCS10473; Tue, 15 Jul 2003 23:48:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h6FNJAA01017; Tue, 15 Jul 2003 23:19:10 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003071516535212725 ; Tue, 15 Jul 2003 16:53:55 -0700 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Jul 2003 16:53:39 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) Date: Tue, 15 Jul 2003 16:53:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) Thread-Index: AcNLIGR+GWQkRGuOSY+ViN6qnCwACwAC9o8w From: "Klinglesmith, Michael T" To: "Peter Dalgaard BSA" Cc: , X-OriginalArrivalTime: 15 Jul 2003 23:53:39.0681 (UTC) FILETIME=[50722D10:01C34B2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id h6FNs3JH003086 Yes you do seem to be correct. I have pointed to a new version of perl (v5.6.1) and it builds cleanly Thank you, Michael. -----Original Message----- From: Peter Dalgaard BSA [mailto:p.dalgaard@biostat.ku.dk] Sent: Tuesday, July 15, 2003 3:31 PM To: Klinglesmith, Michael T Cc: r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk Subject: Re: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) michael.t.klinglesmith@intel.com writes: > make[1]: Leaving directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/doc' > make[1]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' > building all R object docs (text, HTML, LaTeX, examples) > make[2]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' > Undefined subroutine &R::Rdconv::fill called at > /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm line 1955, > chunk 381. .... > ]perl -v > > This is perl, version 5.004_04 built for i386_linux22 > > Copyright 1987-1997, Larry Wall I would suspect that this is the culprit. We do check that the perl version is at least 5.004 so we expect your version to work, but on the other hand it is quite old (~ 6 years it would seem) and quite likely noone actually checked against that version when making changes to Rdconv. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 3485.followup.2 <== From hornik@ci.tuwien.ac.at Wed Jul 16 07:38:46 2003 Received: from rumba.wu-wien.ac.at (rumba.wu-wien.ac.at [137.208.3.45]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h6G5cjJH004549; Wed, 16 Jul 2003 07:38:46 +0200 (MET DST) Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by rumba.wu-wien.ac.at (8.12.6p2/8.12.6) with ESMTP id h6G5cibq077763; Wed, 16 Jul 2003 07:38:44 +0200 (CEST) (envelope-from hornik@ci.tuwien.ac.at) Received: from mithrandir.hornik.net (mail@wu057056.wu-wien.ac.at [137.208.57.56]) by isis.wu-wien.ac.at (8.12.8/8.12.6) with ESMTP id h6G5ce80031600; Wed, 16 Jul 2003 07:38:41 +0200 (envelope-from hornik@ci.tuwien.ac.at) Received: from hornik by mithrandir.hornik.net with local (Exim 3.36 #1 (Debian)) id 19cexw-0000S0-00; Wed, 16 Jul 2003 07:36:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16148.58458.680003.755101@mithrandir.hornik.net> Date: Wed, 16 Jul 2003 07:36:26 +0200 To: Peter Dalgaard BSA Cc: michael.t.klinglesmith@intel.com, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) In-Reply-To: References: <200307151656.h6FGuOJH000875@pubhealth.ku.dk> X-Mailer: VM 7.16 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik X-WU-uvscan-status: clean v4.2.40/v4276 charon 75346027d80530bce8d063efadbe0800 >>>>> Peter Dalgaard BSA writes: > michael.t.klinglesmith@intel.com writes: >> make[1]: Leaving directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/doc' >> make[1]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' >> building all R object docs (text, HTML, LaTeX, examples) >> make[2]: Entering directory `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' >> Undefined subroutine &R::Rdconv::fill called at >> /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm line 1955, >> chunk 381. > .... >> ]perl -v >> >> This is perl, version 5.004_04 built for i386_linux22 >> >> Copyright 1987-1997, Larry Wall > I would suspect that this is the culprit. We do check that the perl > version is at least 5.004 so we expect your version to work, but on > the other hand it is quite old (~ 6 years it would seem) and quite > likely noone actually checked against that version when making changes > to Rdconv. Actually ... It seems that Text::Wrap::fill() was added between 5.004_04 and 5.004_05. I had not realized that the former was an official release. We can * Try to special-case 5.004_04 and provide the version of fill() indicated in the Text::Wrap documentation; * Decide we've played enough with this and require either 5.004_05 (can we do this?) or 5.005. -k ==> 3485.reply.2 <== From maechler@stat.math.ethz.ch Wed Jul 16 10:22:37 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h6G8MaJH005822; Wed, 16 Jul 2003 10:22:37 +0200 (MET DST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h6G8MAeE023702; Wed, 16 Jul 2003 10:22:10 +0200 (MEST) Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id h6G8MVp17247; Wed, 16 Jul 2003 10:22:31 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16149.2887.426868.742734@gargle.gargle.HOWL> Date: Wed, 16 Jul 2003 10:22:31 +0200 To: Kurt.Hornik@wu-wien.ac.at Cc: Peter Dalgaard BSA , r-devel@stat.math.ethz.ch, michael.t.klinglesmith@intel.com, R-bugs@biostat.ku.dk Subject: Re: [Rd] Undefined subroutine &R::Rdconv::fill (PR#3485) In-Reply-To: <16148.58458.680003.755101@mithrandir.hornik.net> References: <200307151656.h6FGuOJH000875@pubhealth.ku.dk> <16148.58458.680003.755101@mithrandir.hornik.net> X-Mailer: VM 7.15 under Emacs 21.3.2 Reply-To: Martin Maechler X-Virus-Scanned: by amavisd-milter (http://amavis.org/) >>>>> "KH" == Kurt Hornik >>>>> on Wed, 16 Jul 2003 07:36:26 +0200 writes: >>>>> Peter Dalgaard BSA writes: >> michael.t.klinglesmith@intel.com writes: >>> make[1]: Leaving directory >>> `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/doc' make[1]: >>> Entering directory >>> `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' >>> building all R object docs (text, HTML, LaTeX, examples) >>> make[2]: Entering directory >>> `/fs38/odc.arch.3/mtklingl/R/R-1.7.1/src/library' >>> Undefined subroutine &R::Rdconv::fill called at >>> /fs38/odc.arch.3/mtklingl/R/R-1.7.1/share/perl/R/Rdconv.pm >>> line 1955, chunk 381. >> .... >>> ]perl -v >>> >>> This is perl, version 5.004_04 built for i386_linux22 >>> >>> Copyright 1987-1997, Larry Wall >> I would suspect that this is the culprit. We do check >> that the perl version is at least 5.004 so we expect your >> version to work, but on the other hand it is quite old (~ >> 6 years it would seem) and quite likely noone actually >> checked against that version when making changes to >> Rdconv. KH> Actually ... KH> It seems that Text::Wrap::fill() was added between KH> 5.004_04 and 5.004_05. I had not realized that the KH> former was an official release. KH> We can KH> * Try to special-case 5.004_04 and provide the version KH> of fill() indicated in the Text::Wrap documentation; KH> * Decide we've played enough with this and require KH> either 5.004_05 (can we do this?) or 5.005. I'd go for the latter. We will do people a favor (in the longer term at least) by urging them to upgrade such old perl versions. Martin ==> 3485.audit <== Mon Aug 4 17:05:53 2003 ripley moved from incoming to Installation Thu Apr 1 16:15:25 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4314 * Subject: Re: [Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc From: Kurt Hornik Date: Fri, 26 Sep 2003 20:28:51 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4314 <== From Kurt.Hornik@wu-wien.ac.at Fri Sep 26 20:30:18 2003 Received: from rumba.wu-wien.ac.at (rumba.wu-wien.ac.at [137.208.3.45]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8QIUH0P014675 for ; Fri, 26 Sep 2003 20:30:17 +0200 (MET DST) Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by rumba.wu-wien.ac.at (8.12.6p2/8.12.6) with ESMTP id h8QIUG90007690; Fri, 26 Sep 2003 20:30:16 +0200 (CEST) (envelope-from Kurt.Hornik@wu-wien.ac.at) Received: from mithrandir.hornik.net (mail@wu057056.wu-wien.ac.at [137.208.57.56]) by isis.wu-wien.ac.at (8.12.8/8.12.6) with ESMTP id h8QIUCaR053884; Fri, 26 Sep 2003 20:30:13 +0200 (envelope-from Kurt.Hornik@wu-wien.ac.at) Received: from hornik by mithrandir.hornik.net with local (Exim 3.36 #1 (Debian)) id 1A2xKw-0005QY-00; Fri, 26 Sep 2003 20:29:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16244.34147.349298.186981@mithrandir.hornik.net> Date: Fri, 26 Sep 2003 20:28:51 +0200 To: Saikat DebRoy Cc: CanisMaior@web.de, R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch Subject: Re: [Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295) In-Reply-To: References: <200309250926.h8P9QG0P023078@pubhealth.ku.dk> X-Mailer: VM 7.17 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik X-WU-uvscan-status: clean v4.2.40/v4295 charon cc3b40a804e8c0fb5351dc33b59027c1 >>>>> Saikat DebRoy writes: > On Thursday, Sep 25, 2003, at 05:26 US/Eastern, CanisMaior@web.de wrote: >> Bugs compiling R-1.7.1 with Intel compilers icc and ifc, >> on x86-computer (Pentium IV) and linux operating system >> > Many of those bugs can be fixed by using appropriate configure options. > Some of the warnings are serious, but they quite a few of them or fixed > yesterday. > ... >> 2) delete a wrong path in some Makefiles: >> -L/usr/local/lib" >> The quotation mark is the wrong thing. Delete it! >> > The problem is in the AC_F77_LIBRARY_LDFLAGS macro. It guesses the > linker flags by passing a verbose option (-v for ifc) to the compiler. > For ifc this produces a multiline output, one line continued to the > next by a \ character. It also contains some " characters. These > together produces the wrong results. We can fix this by removing all \ > and " from the variable ac_f77_v_output in that macro. I am not sure > if this breaks anything in other compilers. Yep, the problem is the "-mGLOB_options_string=......" one gets, and AC_F77_LIBRARY_LDFLAGS() cannot handle this. I tend to avoid overloading stuff from Autoconf (and am not a fan of unconditionally removing double quotes either), and we have a macro for postprocessing the AC_F77_LIBRARY_LDFLAGS results anyways. I've added -[a-zA-Z]/*\" | -[a-zA-Z]*\\) # ifc ;; to this, which worked on the system I tried. Can people with ifc pls try again? Also, it would be nice if someone could donate a few lines on using the Intel compilers for R-admin. Thanks, -k ==> 4314.audit <== Thu Oct 2 08:24:12 2003 maechler moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 5536 * Subject: R 1.8.1 ./configure with "," in working directory From: Wolfram Fischer Date: Fri, 5 Dec 2003 10:19:16 +0100 --Well, so users expect the earth ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5536 <== From mailnull@stat.math.ethz.ch Fri Dec 5 10:11:45 2003 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slim.kubism.ku.dk (Postfix) with ESMTP id 4D59BED90 for ; Fri, 5 Dec 2003 10:11:45 +0100 (CET) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hB59A6Cg011016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Dec 2003 10:10:07 +0100 (MET) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.10/8.12.10/Submit) id hB59A5Di011015 for R-bugs@biostat.ku.dk; Fri, 5 Dec 2003 10:10:05 +0100 (MET) Received: from fischer-zim.ch (adsl-62-167-208-163.adslplus.ch [62.167.208.163]) by hypatia.math.ethz.ch (8.12.10/8.12.10) with ESMTP id hB599xCf010992 for ; Fri, 5 Dec 2003 10:10:00 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by fischer-zim.ch (Postfix) with ESMTP id 5C27E53DF0 for ; Fri, 5 Dec 2003 10:19:17 +0100 (CET) Received: by fischer-zim.ch (Postfix, from userid 100) id CB90353DEF; Fri, 5 Dec 2003 10:19:16 +0100 (CET) Date: Fri, 5 Dec 2003 10:19:16 +0100 From: Wolfram Fischer To: r-bugs@stat.math.ethz.ch Subject: R 1.8.1 ./configure with "," in working directory Message-ID: <20031205091916.GA16577@s1x.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hypatia.math.ethz.ch X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Level: PROBLEM ``./configure'' creates empty Makefiles and the following error messages if there is a ``,'' in the name of the working directory. REMARK As I have seen, ``,'' is used as separator for the sed statements in config.status. Would it be possible to use instead a character which cannot be used in a pathname, e.g. ``;''? ERROR MESSAGES ... checking for lpr... lpr checking for paperconf... false checking for recommended packages... yes configure: creating ./config.status config.status: creating Makeconf sed: -e expression #1, char 295: Unknown option to `s' config.status: creating Makefile sed: -e expression #1, char 295: Unknown option to `s' config.status: creating afm/Makefile sed: -e expression #1, char 299: Unknown option to `s' config.status: creating doc/Makefile ... Wolfram ==> 5536.audit <== Mon Dec 8 13:52:33 2003 ripley changed notes Mon Dec 8 13:52:33 2003 ripley foobar Mon Dec 8 13:52:33 2003 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6482 * Subject: Installation From: a0108661@unet.univie.ac.at Date: Tue, 27 Jan 2004 18:51:04 +0100 (CET) --Mandrake RPM installation problem. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6482 <== From a0108661@unet.univie.ac.at Tue Jan 27 18:51:04 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 271901054B for ; Tue, 27 Jan 2004 18:51:04 +0100 (CET) From: a0108661@unet.univie.ac.at To: R-bugs@biostat.ku.dk Subject: Installation Message-Id: <20040127175104.271901054B@slim.kubism.ku.dk> Date: Tue, 27 Jan 2004 18:51:04 +0100 (CET) X-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Wilhelm Dollmann Version: R-1.8.1-1mdk.i586.rpm OS: Mandrake 9.0 Submission from: (NULL) (131.130.203.149) I use the KPackage installation-program. I get this message: rpm -U --replacepkgs //home2/R-1.8.1-1mdk.i586.rpm;echo RESULT=$? Fehler: unpacking of archive failed on file /usr/lib/R/bin/libR.so;4016a58d: cpio: read RESULT=1 ==> 6482.audit <== Wed Jan 28 06:48:52 2004 ripley changed notes Wed Jan 28 06:48:52 2004 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6797 * Subject: R.spec From: joachim.geiger@ipp.mpg.de Date: Tue, 20 Apr 2004 11:51:40 +0200 (CEST) --About the source RPM for 1.9.0 under RedHat 8.0. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6797 <== From joachim.geiger@ipp.mpg.de Tue Apr 20 11:51:40 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 45DCC1046B for ; Tue, 20 Apr 2004 11:51:40 +0200 (CEST) From: joachim.geiger@ipp.mpg.de To: R-bugs@biostat.ku.dk Subject: R.spec Message-Id: <20040420095140.45DCC1046B@slim.kubism.ku.dk> Date: Tue, 20 Apr 2004 11:51:40 +0200 (CEST) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Joachim Geiger Version: 1.9.0-1 OS: redhat 8.0 Submission from: (NULL) (194.94.233.87) Hello, the bug concerns the source-rpm of the 1.9.0 version on my redhat 8.0 system. The specfile requires tk-devel for compilation, but on RedHat8.0 the headers are already in the tk-rpm included. After changing tk-devel to tk, compilation runs smoothly. Best regards and thanx that U R to provide R Joachim P.S.: Any interest in the rpm-package? ==> 6797.reply.1 <== From p.dalgaard@biostat.ku.dk Tue Apr 20 12:24:07 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 03C671048D; Tue, 20 Apr 2004 12:24:06 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i3KAKdYg007808; Tue, 20 Apr 2004 12:20:39 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i3KAKdmI007804; Tue, 20 Apr 2004 12:20:39 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: joachim.geiger@ipp.mpg.de Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] R.spec (PR#6797) References: <20040420095209.EE86810478@slim.kubism.ku.dk> From: Peter Dalgaard Date: 20 Apr 2004 12:20:38 +0200 In-Reply-To: <20040420095209.EE86810478@slim.kubism.ku.dk> Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) joachim.geiger@ipp.mpg.de writes: > Full_Name: Joachim Geiger > Version: 1.9.0-1 > OS: redhat 8.0 > Submission from: (NULL) (194.94.233.87) > > > Hello, > the bug concerns the source-rpm of the 1.9.0 version on my redhat 8.0 system. > The specfile requires tk-devel for compilation, but on RedHat8.0 the headers are > already in the tk-rpm included. After changing tk-devel to tk, compilation runs > smoothly. > Best regards and thanx that U R to provide R > Joachim > P.S.: Any interest in the rpm-package? Hmm, ask Martyn. However, the FC1 RPM installed flawlessly on my RH8 laptop... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6797.audit <== Wed Apr 21 14:58:39 2004 ripley changed notes Thu Apr 29 12:45:39 2004 ripley changed notes Tue May 11 14:29:10 2004 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6862 * Subject: Fortran compiler dependency missing in gentoo ebuild script From: mc@austrian-mint.at Date: Fri, 7 May 2004 16:45:01 +0200 (CEST) --Gentoo Linux-specific problem ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6862 <== From mc@austrian-mint.at Fri May 7 16:45:07 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id F411BEDF1 for ; Fri, 7 May 2004 16:45:01 +0200 (CEST) From: mc@austrian-mint.at To: R-bugs@biostat.ku.dk Subject: Fortran compiler dependency missing in gentoo ebuild script Message-Id: <20040507144501.F411BEDF1@slim.kubism.ku.dk> Date: Fri, 7 May 2004 16:45:01 +0200 (CEST) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Markus Cozowicz Version: 1.9.0 OS: Gentoo Linux Submission from: (NULL) (81.223.31.120) Fortran compiler dependency missing in gentoo ebuild script Workaround: emerge f2c ==> 6862.reply.1 <== From p.dalgaard@biostat.ku.dk Fri May 7 16:54:34 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id EED53EDF1; Fri, 7 May 2004 16:54:33 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i47EnwYg016776; Fri, 7 May 2004 16:49:59 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i47Enww5016772; Fri, 7 May 2004 16:49:58 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: mc@austrian-mint.at Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Fortran compiler dependency missing in gentoo ebuild script (PR#6862) References: <20040507144536.CFAF5F0E7@slim.kubism.ku.dk> From: Peter Dalgaard Date: 07 May 2004 16:49:58 +0200 In-Reply-To: <20040507144536.CFAF5F0E7@slim.kubism.ku.dk> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) mc@austrian-mint.at writes: > Full_Name: Markus Cozowicz > Version: 1.9.0 > OS: Gentoo Linux > Submission from: (NULL) (81.223.31.120) > > > Fortran compiler dependency missing in gentoo ebuild script > > Workaround: emerge f2c Er, in which sense is this an R bug? There is nothing we can do about missing dependencies in packages for Linux distributions, and we're not even likely to be informed when (if) the issue is resolved. You need to tell Gentoo or whoever maintains the R package for it. BTW, are you sure you wouldn't rather install g77 than f2c? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6862.audit <== Tue May 11 14:28:58 2004 ripley changed notes Tue May 11 14:28:58 2004 ripley moved from incoming to Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6896 * Subject: R with shared library support: 'make check' fails with unresolved symbol From: garvin@cs.rice.edu Date: Wed, 19 May 2004 23:38:53 +0200 (CEST) --OSF1 Alpha, not detials of how install was done. --Was R-admin actually read? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6896 <== From garvin@cs.rice.edu Wed May 19 23:38:54 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id A7D4D1058F for ; Wed, 19 May 2004 23:38:53 +0200 (CEST) From: garvin@cs.rice.edu To: R-bugs@biostat.ku.dk Subject: R with shared library support: 'make check' fails with unresolved symbol Message-Id: <20040519213853.A7D4D1058F@slim.kubism.ku.dk> Date: Wed, 19 May 2004 23:38:53 +0200 (CEST) X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_20,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: John Garvin Version: 1.9.0 OS: OSF1 Alpha ev6 Submission from: (NULL) (128.42.129.78) I configured R 1.9.0 with --enable-R-shlib on Alpha. 'make check' fails with an unresolved symbol. Here's the relevant output: running code in 'reg-tests-1.R' ...529442:/home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/bin/R.bin: /sbin/loader: Fatal Error: call to unresolved symbol from /home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/modules/lapack.so (pc=0x3ffbfde345c) I'm using Compaq cc version V6.4-009 and ld version 5.1. ==> 6896.followup.1 <== From ripley@stats.ox.ac.uk Sat May 22 10:38:03 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id ACA201058A for ; Sat, 22 May 2004 10:38:03 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18220-06 for ; Sat, 22 May 2004 10:38:03 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 22 May 2004 10:38:02 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i4M8c1rt020208; Sat, 22 May 2004 09:38:01 +0100 (BST) Date: Sat, 22 May 2004 09:38:00 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: garvin@cs.rice.edu Cc: r-devel@stat.math.ethz.ch, Subject: (PR#6896) Re: [Rd] R with shared library support: 'make check' fails with unresolved symbol (PR#6896) In-Reply-To: <20040519213922.AE69C10593@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I am sorry, but that is not a platform the core team has easy access to, and no one responded with any changes in the beta-testing period so we can reasonably assume that users on that platform were succeeding. First check: you DID read the R-admin manual and follow the advice there? This looks like a broken BLAS library and you are advised to use --without-blas .... On Wed, 19 May 2004 garvin@cs.rice.edu wrote: > Full_Name: John Garvin > Version: 1.9.0 > OS: OSF1 Alpha ev6 > Submission from: (NULL) (128.42.129.78) > > > I configured R 1.9.0 with --enable-R-shlib on Alpha. 'make check' fails with an > unresolved symbol. Here's the relevant output: > > running code in 'reg-tests-1.R' > ...529442:/home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/bin/R.bin: > /sbin/loader: Fatal Error: call to unresolved symbol from > /home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/modules/lapack.so > (pc=0x3ffbfde345c) > > I'm using Compaq cc version V6.4-009 and ld version 5.1. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6896.audit <== Sat May 22 22:02:59 2004 ripley changed notes Sat May 22 22:02:59 2004 ripley moved from incoming to Installation ==> 6896.followup.2 <== From garvin@rice.edu Mon May 24 17:00:59 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0773AEAC1 for ; Mon, 24 May 2004 17:00:59 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00652-03 for ; Mon, 24 May 2004 17:00:56 +0200 (CEST) Received: from hpc3.cs.rice.edu (hpc3.cs.rice.edu [128.42.129.78]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 24 May 2004 17:00:55 +0200 (CEST) Received: from hpc3.cs.rice.edu (localhost [127.0.0.1]) by hpc3.cs.rice.edu (8.12.8/8.12.8) with ESMTP id i4OF0rD8015264; Mon, 24 May 2004 10:00:53 -0500 Received: from localhost (garvin@localhost) by hpc3.cs.rice.edu (8.12.8/8.12.8/Submit) with ESMTP id i4OF0q6q015260; Mon, 24 May 2004 10:00:52 -0500 X-Authentication-Warning: hpc3.cs.rice.edu: garvin owned process doing -bs Date: Mon, 24 May 2004 10:00:52 -0500 (CDT) From: John Garvin X-X-Sender: garvin@hpc3.cs.rice.edu To: Prof Brian Ripley Cc: r-devel@stat.math.ethz.ch, Subject: Re: (PR#6896) Re: [Rd] R with shared library support: 'make check' fails with unresolved symbol (PR#6896) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-7.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) That was my first thought, but the same error occurs when configured --without-blas as well as --with-blas; also both --with-lapack and --without-lapack. (There are users who ask questions without reading the manual? I'm shocked! ;-) ) JLG On Sat, 22 May 2004, Prof Brian Ripley wrote: > I am sorry, but that is not a platform the core team has easy access to, > and no one responded with any changes in the beta-testing period so we can > reasonably assume that users on that platform were succeeding. > > First check: you DID read the R-admin manual and follow the advice there? > This looks like a broken BLAS library and you are advised to use > --without-blas .... > > On Wed, 19 May 2004 garvin@cs.rice.edu wrote: > > > Full_Name: John Garvin > > Version: 1.9.0 > > OS: OSF1 Alpha ev6 > > Submission from: (NULL) (128.42.129.78) > > > > > > I configured R 1.9.0 with --enable-R-shlib on Alpha. 'make check' fails with an > > unresolved symbol. Here's the relevant output: > > > > running code in 'reg-tests-1.R' > > ...529442:/home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/bin/R.bin: > > /sbin/loader: Fatal Error: call to unresolved symbol from > > /home/garvin/research/tel/R-alpha/unpatched/R-1.9.0/lib/R/modules/lapack.so > > (pc=0x3ffbfde345c) > > > > I'm using Compaq cc version V6.4-009 and ld version 5.1. > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Language * PR# 408 * Subject: convolution bug From: wsimpson@gcal.ac.uk Date: Fri, 28 Jan 2000 11:17:36 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 408 <== From wsimpson@gcal.ac.uk Fri Jan 28 11:17:36 2000 Received: from localhost (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA11325 for ; Fri, 28 Jan 2000 11:17:36 +0100 (MET) Date: Fri, 28 Jan 2000 11:17:36 +0100 (MET) From: wsimpson@gcal.ac.uk Message-Id: <200001281017.LAA11325@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: convolution bug Full_Name: Bill Simpson Version: 65.1 , 0.90.1 OS: Linux Submission from: (NULL) (193.62.250.209) I reported this on r-help, but here is official bug report. The present convolve() does not do convolution by default. Its default behaviour is correlation. This is a bug. The default argument conj should be set to FALSE. The zero-padding should be on the right for linear convolution (don't ask me why you call this type="open"; I suggest type="linear"). Here is what I expect linear convolution to do: myconvolve<-function (x,h) { nx <- length(x) nh <- length(h) #zero pad if(nx>nh) { x <- c(x,rep(0, nh-1)) h<-c(h,rep(0,nx-1)) } else { h <- c(h,rep(0, nx-1)) x<-c(x,rep(0,nh-1)) } x <- fft(fft(x) * fft(h), inv = TRUE) Re(x)/length(x) #I am not sure about this, the R IFFT is weird } What "circular" convolution should do is just eliminate the zero-padding: myconvolve2<-function (x,h) { #no padding, circular convolution nx <- length(x) nh <- length(h) x <- fft(fft(x) * fft(h), inv = TRUE) Re(x)/(nx) } I suggest that you create two functions, convolve() and correlate(), and get rid of the conj argument in convolve(). ==> 408.audit <== Wed Feb 16 19:28:42 2000 ripley moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 412 * Subject: anomalies with call objects From: Peter Dalgaard BSA Date: 06 Feb 2000 01:18:50 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 412 <== From postmaster@franz.stat.wisc.edu Sun Feb 6 01:16:33 2000 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id BAA26868 for ; Sun, 6 Feb 2000 01:16:31 +0100 (MET) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id BAA18080 for ; Sun, 6 Feb 2000 01:16:38 +0100 (MET) Received: from franz.stat.wisc.edu(128.105.174.95) via SMTP by hypatia, id smtpdAAAa004QS; Sun Feb 6 01:16:33 2000 Received: from pubhealth.ku.dk (really [130.225.108.10]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.102) for ; Sat, 5 Feb 2000 18:16:31 -0600 (CST) Received: from biostat.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id BAA26864 for ; Sun, 6 Feb 2000 01:16:18 +0100 (MET) Received: (from pd@localhost) by biostat.ku.dk (8.9.3/8.9.3) id BAA12311; Sun, 6 Feb 2000 01:18:51 +0100 Sender: pd@blueberry.kubism.ku.dk To: r-bugs@r-project.org Subject: anomalies with call objects From: Peter Dalgaard BSA Date: 06 Feb 2000 01:18:50 +0100 Message-ID: Lines: 51 X-Mailer: Gnus v5.7/Emacs 20.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Call objects don't always behave as you'd expect. They're mostly list-like, but with exceptions: > f<-function(x,y,...)match.call(expand.dots=FALSE) > xx <- f(y=1,2,z=3,4) > dd <- xx$... > xx$... <- NULL > c(xx,dd) [[1]] f(x = 2, y = 1) $z [1] 3 [[3]] [1] 4 > as.call(c(as.list(xx),dd)) f(x = 2, y = 1, z = 3, 4) (Splus has this rather differently, since dd becomes a call to list() rather than a list of promises: S> c(xx,dd) f(x = 2, y = 1, list, z = 3, 4) S> as.call(c(as.list(xx),dd)) f(x = 2, y = 1, list, z = 3, 4) ...but at least gives the same in both cases) Also, the names of arguments added with [[<- is getting dropped if a new element is required: > xx[["abc"]]<-123 > xx f(x = 2, y = 1, 123) S has what I'd expect there: S> xx[["abc"]]<-123 S> xx f(x = 2, y = 1, abc = 123) [R-0.99.0 prerelease on RedHat6.1, but this is likely not a new thing.] -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 412.audit <== Wed Feb 16 19:26:57 2000 ripley moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 669 * Subject: Bug(s) w/ rbind.data.frame(); fix also read.table(*, as.is = TRUE) ? From: Martin Maechler Date: Mon, 25 Sep 2000 10:17:15 +0200 --status of AsIs columns ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 669 <== From maechler@stat.math.ethz.ch Mon Sep 25 10:17:01 2000 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA01907 for ; Mon, 25 Sep 2000 10:17:01 +0200 (MET DST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id KAA07627 for ; Mon, 25 Sep 2000 10:17:19 +0200 (MET DST) Received: from lynne(129.132.58.30), claiming to be "lynne.ethz.ch" via SMTP by hypatia, id smtpdAAAa001r9; Mon Sep 25 10:17:15 2000 Received: (maechler@localhost) by lynne.ethz.ch (8.9.3/D-MATH-client) id KAA01475; Mon, 25 Sep 2000 10:17:15 +0200 X-Authentication-Warning: lynne.ethz.ch: maechler set sender to maechler@stat.math.ethz.ch using -f From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14799.2571.494467.836722@gargle.gargle.HOWL> Date: Mon, 25 Sep 2000 10:17:15 +0200 To: R-bugs@stat.math.ethz.ch Subject: Bug(s) w/ rbind.data.frame(); fix also read.table(*, as.is = TRUE) ? X-Mailer: VM 6.76 under Emacs 20.7.1 Reply-To: Martin Maechler This is not only bug report, but also a RFC (request for comments): The basic problem is that there are (at least) two ways of easily getting non-factor character columns in data.frames. The first is read.table(*, as.is = TRUE) and the second is data.frame(.., I(...), ..) which differ in their result. Whereas the first produces `pure' character columns in the data.frame, the second approach gives `AsIs' classed columns (character, or, e.g. logical). Now, as the following shows, rbind.data.frame() *is* buggy anyway, I wonder if we shouldn't change read.table(*, as.is = TRUE) such that the non-numeric columns of its result become "AsIs" classed as well: ----------- str(d1 <- data.frame(a=1:3, b = I(letters[1:3]))) ## d1 is `alright' ## d0: The same but a `character' *not* protected by AsIs: d0 <- d1 d0$b <- unclass(d0$b) str(d0) ## Note that this is *really* the same as a what you get from ## read.table(*, as.is = TRUE) ## ---------- ## R's read.table() is S+ compatible; however I wonder if ## we shouldn't add "AsIs" classes to all non-numeric components... ## the classes, shouldn't harm, but ensure consistency of treatment.. str(d11 <- rbind(d1, new = c(7, "N"))) ## alright str(d01 <- rbind(d0, new = c(7, "N"))) ## all wrong : ## Both columns were coerced to factors !! ##-- S-PLUS 5 coerces both to "character" -- which is better, ## since the new row *is* all character ## R makes nonsense with 'b' [factor w/ 1 level "N": NA NA NA 1] ## S+ 5.1 does exactly the right thing [both a & b still look like in d0,d1 : str(d12 <- rbind(d1, new = data.frame(a= 7, b="N")))## str(d02 <- rbind(d0, new = data.frame(a= 7, b="N")))## --------- Martin Maechler http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO D10 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< ==> 669.audit <== Wed Oct 25 20:31:21 2000 ripley changed notes Wed Oct 25 20:31:21 2000 ripley foobar Wed Oct 25 20:31:21 2000 ripley moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1073 * Subject: Wierd problem comparing numeric values and list using == From: "Warnes, Gregory R" Date: Fri, 24 Aug 2001 22:07:41 -0400 --see also PR#1076 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1073 <== From postmaster@franz.stat.wisc.edu Sat Aug 25 04:08:02 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id EAA03646 for ; Sat, 25 Aug 2001 04:08:01 +0200 (MET DST) Received: from mailrelay1.pfizer.com (really [192.77.198.2]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.111) for ; Fri, 24 Aug 2001 21:07:59 -0500 (CDT) Received: from gsun56.pfizer.com (localhost [127.0.0.1]) by mailrelay1.pfizer.com (8.9.3/Pro-8.9.3) with ESMTP id WAA09177 for ; Fri, 24 Aug 2001 22:07:43 -0400 (EDT) Received: from groexms01.pfizer.com (localhost [127.0.0.1]) by gsun56.pfizer.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id WAA24921 for ; Fri, 24 Aug 2001 22:08:07 -0400 (EDT) Received: from groexcncr05.pfizer.com (unverified) by groexms01.pfizer.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 22:07:41 -0400 Received: by groexcncr05.pfizer.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Aug 2001 22:07:41 -0400 Message-ID: <5429125E11E4D411AF7300805FE603A8014CED55@groexmbcr02.pfizer.com> From: "Warnes, Gregory R" To: "'r-bugs@r-project.org'" Subject: Wierd problem comparing numeric values and list using == Date: Fri, 24 Aug 2001 22:07:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Under R 1.3.0 on Solaris and Windows NT there seems to be a bug in == when applied to elements of a list, particularly when one of the elements is of mode integer: > list(1) == list(1) [1] FALSE > 1 == list(1) [1] TRUE > as.integer(1)==list(as.integer(1)) [1] FALSE > as.integer(1)==list(as.double(1)) [1] FALSE > list(as.integer(1))==list(as.integer(1)) [1] FALSE > list(as.integer(1))==as.integer(1) [1] FALSE > list(as.double(1))==list(as.double(1)) [1] FALSE However, these cases work: > as.double(1)==list(as.integer(1)) [1] TRUE > list(as.integer(1))==as.double(1) [1] TRUE Replacing the bare integer/double with a vector constructed with c() doesn't change the results, and comparing between vectors created with c() appears correct. -Greg --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = x86 os = Win32 system = x86, Win32 status = major = 1 minor = 3.0 year = 2001 month = 06 day = 22 language = R Windows NT 4.0 (build 1381) Service Pack 5 Search Path: .GlobalEnv, package:ctest, Autoloads, package:base LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. ==> 1073.reply.1 <== From p.dalgaard@biostat.ku.dk Sat Aug 25 15:58:26 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA04833; Sat, 25 Aug 2001 15:58:25 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id f7PDv9r21975; Sat, 25 Aug 2001 15:57:09 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: gregory_r_warnes@groton.pfizer.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Wierd problem comparing numeric values and list using == (PR#1073) References: <200108250208.EAA03656@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 25 Aug 2001 15:57:09 +0200 In-Reply-To: <200108250208.EAA03656@pubhealth.ku.dk> Message-ID: Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii gregory_r_warnes@groton.pfizer.com writes: > Under R 1.3.0 on Solaris and Windows NT there seems to be a bug in == when > applied to elements of a list, particularly when one of the elements is of > mode integer: > > > list(1) == list(1) > [1] FALSE > > 1 == list(1) > [1] TRUE > > as.integer(1)==list(as.integer(1)) > [1] FALSE > > as.integer(1)==list(as.double(1)) > [1] FALSE > > list(as.integer(1))==list(as.integer(1)) > [1] FALSE > > list(as.integer(1))==as.integer(1) > [1] FALSE > > list(as.double(1))==list(as.double(1)) > [1] FALSE > > However, these cases work: > > > as.double(1)==list(as.integer(1)) > [1] TRUE > > list(as.integer(1))==as.double(1) > [1] TRUE > > Replacing the bare integer/double with a vector constructed with c() doesn't > change the results, and comparing between vectors created with c() appears > correct. It is not entirely clear what we *should* be doing here. S (-PLUS 3.4) is at least consistent: > list(1) == list(1) Error in list(1) == list(1): == operation on mode "list" undefined Dumped > 1 == list(1) Error in 1 == list(1): == operation on mode "list" undefined Dumped > as.integer(1)==list(as.integer(1)) Error in as.integer(1) == list(as.integer(1)): == operation on mode "list" undefined Dumped ... so one might argue that you shouldn't do that in the first place... (or that the bug is that we do not expressly forbid doing this.) -p -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1073.audit <== Tue Aug 28 10:14:14 2001 ripley moved from incoming to Language Tue Aug 28 10:16:19 2001 ripley changed notes Tue Aug 28 10:16:19 2001 ripley foobar Sun Oct 19 09:33:54 2003 ripley changed notes Sun Oct 19 09:33:54 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1076 * Subject: Re: [Rd] Wierd problem comparing numeric values and list using == From: John Chambers Date: Mon, 27 Aug 2001 08:44:22 -0400 --part of PR#1073 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1076 <== From jmc@research.bell-labs.com Mon Aug 27 14:45:38 2001 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by pubhealth.ku.dk (8.9.3/8.9.1) with SMTP id OAA16860; Mon, 27 Aug 2001 14:45:37 +0200 (MET DST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Aug 27 08:40:52 EDT 2001 Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7RCiOl07715; Mon, 27 Aug 2001 08:44:24 -0400 (EDT) Received: from research.bell-labs.com (IDENT:jmc@newton.research.bell-labs.com [135.104.13.158]) by jessie.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id IAA18247; Mon, 27 Aug 2001 08:44:23 -0400 (EDT) Sender: jmc@research.bell-labs.com Message-ID: <3B8A40A6.15AF96C2@research.bell-labs.com> Date: Mon, 27 Aug 2001 08:44:22 -0400 From: John Chambers Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Dalgaard BSA CC: gregory_r_warnes@groton.pfizer.com, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Wierd problem comparing numeric values and list using == (PR#1073) References: <200108250208.EAA03656@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Dalgaard BSA wrote: > > gregory_r_warnes@groton.pfizer.com writes: > > > Under R 1.3.0 on Solaris and Windows NT there seems to be a bug in == when > > applied to elements of a list, particularly when one of the elements is of > > mode integer: > > > > > list(1) == list(1) > > [1] FALSE > > > 1 == list(1) > > [1] TRUE > > > as.integer(1)==list(as.integer(1)) > > [1] FALSE > > > as.integer(1)==list(as.double(1)) > > [1] FALSE > > > list(as.integer(1))==list(as.integer(1)) > > [1] FALSE > > > list(as.integer(1))==as.integer(1) > > [1] FALSE > > > list(as.double(1))==list(as.double(1)) > > [1] FALSE > > > > However, these cases work: > > > > > as.double(1)==list(as.integer(1)) > > [1] TRUE > > > list(as.integer(1))==as.double(1) > > [1] TRUE > > > > Replacing the bare integer/double with a vector constructed with c() doesn't > > change the results, and comparing between vectors created with c() appears > > correct. > > It is not entirely clear what we *should* be doing here. S (-PLUS 3.4) > is at least consistent: > > > list(1) == list(1) > Error in list(1) == list(1): == operation on mode "list" undefined > Dumped > > 1 == list(1) > Error in 1 == list(1): == operation on mode "list" undefined > Dumped > > as.integer(1)==list(as.integer(1)) > Error in as.integer(1) == list(as.integer(1)): == operation on mode "list" > undefined > Dumped > ... > > so one might argue that you shouldn't do that in the first place... > (or that the bug is that we do not expressly forbid doing this.) > > -p > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 As of 1.4, we will have the `identical' function, which is the right way to do such comparisons in any case. So I'd vote for making a use of the comparison operators an error unless the type is correct (or there is a method defined). There is even code in relop.c (commented out) that looks like the right test. Any objections? John -- John M. Chambers jmc@bell-labs.com Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc ==> 1076.reply.1 <== From p.dalgaard@biostat.ku.dk Mon Aug 27 15:36:50 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA17663; Mon, 27 Aug 2001 15:36:49 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id f7RDZHZ03790; Mon, 27 Aug 2001 15:35:17 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: jmc@research.bell-labs.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Wierd problem comparing numeric values and list using == (PR#1076) References: <200108271245.OAA16874@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 27 Aug 2001 15:35:17 +0200 In-Reply-To: <200108271245.OAA16874@pubhealth.ku.dk> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii jmc@research.bell-labs.com writes: > > > > list(1) == list(1) > > > [1] FALSE > > > > 1 == list(1) > > > [1] TRUE > > > > as.integer(1)==list(as.integer(1)) > > > [1] FALSE > > > > as.integer(1)==list(as.double(1)) > > > [1] FALSE > > > > list(as.integer(1))==list(as.integer(1)) > > > [1] FALSE > > > > list(as.integer(1))==as.integer(1) > > > [1] FALSE > > > > list(as.double(1))==list(as.double(1)) > > > [1] FALSE > > > > > > However, these cases work: > > > > > > > as.double(1)==list(as.integer(1)) > > > [1] TRUE > > > > list(as.integer(1))==as.double(1) > > > [1] TRUE .... > As of 1.4, we will have the `identical' function, which is the right way > to do such comparisons in any case. > > So I'd vote for making a use of the comparison operators an error unless > the type is correct (or there is a method defined). There is even code > in relop.c (commented out) that looks like the right test. Any > objections? Not really, except that I get the usual nagging suspicion that someone (who?) meant something by doing it this way... The current logic seems to be that if either side of the == is a vector of atomic type, try to coerce the list on the other side to a similar object and then test. However this has a clear bug in that the coercion is to double even when the atomic vector is integer. If there are lists on both sides, a pointer comparison is done: > x<-2 > list(x)==list(x) [1] FALSE > list(.Alias(x))==list(.Alias(x)) [1] TRUE The latter seems highly dubious to me. I'd rather have a recursive pairwise application of "==" there. However, none of this is what identical does, is it? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1076.audit <== Tue Aug 28 10:14:14 2001 ripley moved from incoming to Language Tue Aug 28 10:15:49 2001 ripley changed notes Tue Aug 28 10:15:49 2001 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1186 * Subject: a patch to tapply From: Vadim Ogranovich Date: Thu, 29 Nov 2001 14:48:35 -0600 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1186 <== From postmaster@franz.stat.wisc.edu Thu Nov 29 21:48:55 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA14928 for ; Thu, 29 Nov 2001 21:48:54 +0100 (MET) Received: from syn.arbitrade.com (really [208.47.220.70]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Thu, 29 Nov 2001 14:48:48 -0600 (CST) Received: from urg.arbitrade.com (urg.arbitrade.com [10.0.9.25]) by syn.arbitrade.com (8.11.1/8.11.1) with ESMTP id fATKlSE29652 for ; Thu, 29 Nov 2001 14:47:28 -0600 (CST) Received: from mnmail.arbitrade.com (mnmail.arbitrade.com [38.156.36.157]) by urg.arbitrade.com (8.11.1/8.11.1) with ESMTP id fATKmf519971 for ; Thu, 29 Nov 2001 14:48:41 -0600 (CST) Received: by mnmail.arbitrade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 14:48:41 -0600 Message-ID: From: Vadim Ogranovich To: "'r-bugs@r-project.org'" Subject: a patch to tapply Date: Thu, 29 Nov 2001 14:48:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Though tapply(x, factor, fun, simplify =TRUE) should be equivalent to sapply(split(x, factor), fun, simplify=TRUE), note simplify=TRUE, it is not so if fun() returns a vector rather than a scalar, e.g. > tapply(1:6, c(0,0,0,1,1,1), function(x) c(min=min(x), max=max(x)), simplify=TRUE) $"0" min max 1 3 $"1" min max 4 6 > sapply(split(1:6, c(0,0,0,1,1,1)), function(x) c(min=min(x), max=max(x)), simplify=TRUE) 0 1 min 1 4 max 3 6 The patch submitted below fixes this problem > tapply.new(1:6, c(0,0,0,1,1,1), function(x) c(min=min(x), max=max(x)), simplify=TRUE) 0 1 min 1 4 max 3 6 Another potential problem, which I am not able to verify at the moment, is that whenever simplification is possible S-Plus returns a TRANSPOSE of that of R, i.e. min max 0 1 3 1 4 6 Fixing this would require small changes to both tapply and sapply and I'll be happy to provide the patches if requested. R Version > sapply(R.Version(), I) platform arch os system "i686-pc-linux-gnu" "i686" "linux-gnu" "i686, linux-gnu" status major minor year "" "1" "3.1" "2001" month day language "08" "31" "R" ************** The patch: "tapply.new" <- function (X, INDEX, FUN = NULL, ..., simplify = TRUE) { FUN <- if (!is.null(FUN)) match.fun(FUN) if (!is.list(INDEX)) INDEX <- list(INDEX) nI <- length(INDEX) namelist <- vector("list", nI) names(namelist) <- names(INDEX) extent <- integer(nI) nx <- length(X) one <- as.integer(1) group <- rep(one, nx) ngroup <- one for (i in seq(INDEX)) { index <- as.factor(INDEX[[i]]) if (length(index) != nx) stop("arguments must have same length") namelist[[i]] <- levels(index) extent[i] <- nlevels(index) group <- group + ngroup * (as.integer(index) - one) ngroup <- ngroup * nlevels(index) } if (is.null(FUN)) return(group) ans <- lapply(split(X, group), FUN, ...) if (simplify && length(common.len <- unique(unlist(lapply(ans, length)))) == 1) { if (common.len > 1) { extent <- c(common.len, extent) namelist <- c(list(names(ans[[1]])), namelist) } ansmat <- array(unlist(ans, recursive = FALSE), dim = extent, dimnames = namelist) return(ansmat) } index <- as.numeric(names(ans)) ansmat <- array(vector("list", prod(extent)), dim = extent, dimnames = namelist) names(ans) <- NULL ansmat[index] <- ans ansmat } -------------------------------------------------- DISCLAIMER This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Trading Group may, at its discretion, monitor and review the content of all e-mail communications. ==> 1186.audit <== Fri Dec 28 20:08:08 2001 thomas moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1241 * Subject: Problem with "missing" in "local" From: J.C.Rougier@durham.ac.uk Date: Fri, 4 Jan 2002 13:34:34 GMT -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1241 <== From postmaster@franz.stat.wisc.edu Fri Jan 4 14:41:56 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA07662 for ; Fri, 4 Jan 2002 14:41:55 +0100 (MET) Received: from hermes.dur.ac.uk (really [129.234.4.9]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Fri, 4 Jan 2002 07:41:27 -0600 (CST) Received: from euclid (euclid.dur.ac.uk [129.234.21.53]) by hermes.dur.ac.uk (8.11.1/8.11.1) with ESMTP id g04DYZr02195 for ; Fri, 4 Jan 2002 13:34:35 GMT Received: from arrow.dur.ac.uk by euclid id ; Fri, 4 Jan 2002 13:34:34 GMT From: J.C.Rougier@durham.ac.uk Date: Fri, 4 Jan 2002 13:34:34 GMT Message-Id: <28125.200201041334@arrow.dur.ac.uk> To: r-bugs@r-project.org Subject: Problem with "missing" in "local" Cc: dma0jcr@arrow.dur.ac.uk X-ECS-MailScanner: Found to be clean Hi everyone, I encountered unexpected behaviour when calling "missing" within a "local" environment, namely fred <- function(x, y) { x <- as.vector(x) local({ dontwantme <- 1:100 if (missing(y)) print("No \"y\" today") }) x } whereupon I get > fred(1:10) Error in eval(expr, envir, enclos) : "missing" illegal use of missing I think it is reasonable to expect missing to work in this context (I suspect the problem relates to lazy evaluation): if not, it might be helpful to amend the help file. Cheers, Jonathan. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 4.0 year = 2001 month = 12 day = 19 language = R Search Path: .GlobalEnv, Autoloads, package:base ==> 1241.followup.1 <== From ripley@stats.ox.ac.uk Fri Jan 4 14:51:24 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA07830 for ; Fri, 4 Jan 2002 14:51:23 +0100 (MET) Received: from gannet.stats (IDENT:root@gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id NAA03055; Fri, 4 Jan 2002 13:50:56 GMT Received: from localhost (ripley@localhost) by gannet.stats (8.11.3/8.11.3) with ESMTP id g04Doui08194; Fri, 4 Jan 2002 13:50:56 GMT X-Authentication-Warning: gannet.stats: ripley owned process doing -bs Date: Fri, 4 Jan 2002 13:50:56 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: To: cc: Subject: Re: [Rd] Problem with "missing" in "local" (PR#1241) In-Reply-To: <200201041341.OAA07672@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Jan 2002 J.C.Rougier@durham.ac.uk wrote: > Hi everyone, > > I encountered unexpected behaviour when calling "missing" within a > "local" environment, namely > > fred <- function(x, y) > { > x <- as.vector(x) > local({ > dontwantme <- 1:100 > if (missing(y)) print("No \"y\" today") > }) > x > } > > whereupon I get > > > fred(1:10) > Error in eval(expr, envir, enclos) : "missing" illegal use of missing > > I think it is reasonable to expect missing to work in this context (I > suspect the problem relates to lazy evaluation): if not, it might be > helpful to amend the help file. Why do you think it reasonable? You've take a function from Evaluate an R expression in a specified environment. and evaluated it somewhere where missing() is not defined. If you had used eval() explicitly, would you think it reasonable? I doubt it. Which help file did you have in mind? -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1241.followup.2 <== From J.C.Rougier@durham.ac.uk Fri Jan 4 15:48:01 2002 Received: from hermes.dur.ac.uk (hermes.dur.ac.uk [129.234.4.9]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA09042 for ; Fri, 4 Jan 2002 15:48:01 +0100 (MET) Received: from euclid (euclid.dur.ac.uk [129.234.21.53]) by hermes.dur.ac.uk (8.11.1/8.11.1) with ESMTP id g04EbSr02994; Fri, 4 Jan 2002 14:37:29 GMT Received: from durham.ac.uk by euclid id ; Fri, 4 Jan 2002 14:37:28 GMT Sender: dma0jcr@durham.ac.uk Message-ID: <3C35BE28.DFA1C500@durham.ac.uk> Date: Fri, 04 Jan 2002 14:37:28 +0000 From: Jonathan Rougier Organization: Maths Dept., Univ. of Durham X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: Prof Brian Ripley CC: R-bugs@biostat.ku.dk Subject: Re: [Rd] Problem with "missing" in "local" (PR#1241) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ECS-MailScanner: Found to be clean Hi Brian, Prof Brian Ripley wrote: > > On Fri, 4 Jan 2002 J.C.Rougier@durham.ac.uk wrote: > > > Hi everyone, > > > > I encountered unexpected behaviour when calling "missing" within a > > "local" environment, namely > > > > fred <- function(x, y) > > { > > x <- as.vector(x) > > local({ > > dontwantme <- 1:100 > > if (missing(y)) print("No \"y\" today") > > }) > > x > > } > > > > whereupon I get > > > > > fred(1:10) > > Error in eval(expr, envir, enclos) : "missing" illegal use of missing > > > > I think it is reasonable to expect missing to work in this context (I > > suspect the problem relates to lazy evaluation): if not, it might be > > helpful to amend the help file. > > Why do you think it reasonable? You've take a function from > > Evaluate an R expression in a specified environment. > > and evaluated it somewhere where missing() is not defined. If you had > used eval() explicitly, would you think it reasonable? I doubt it. By "reasonable" in this context I mean that the operation would appear to be well-defined and useful. I can access x within the local() environment, ie it is found in the enclosing environment, and I do not think that y should be treated any differently. If I modify my function to read fred <- function(x, y) { x <- as.vector(x) local({ print(x) print(y) if (missing(y)) print("No \"y\" today") }) x } then I get the error message > fred(1:10) [1] 1 2 3 4 5 6 7 8 9 10 Error in print(y) : Argument "y" is missing, with no default This error message suggests to me that "missing(y)" would evaluate correctly. > > Which help file did you have in mind? > The help file for "missing". This points out that "missing" is not always reliable, eg after "x <- match.arg(x)". Perhaps this could be another example of "unreliability". Cheers, Jonathan. -- Jonathan Rougier Science Laboratories Department of Mathematical Sciences South Road University of Durham Durham DH1 3LE tel: +44 (0)191 374 2361, fax: +44 (0)191 374 7388 http://www.maths.dur.ac.uk/stats/people/jcr/jcr.html ==> 1241.audit <== Mon Jan 7 10:33:01 2002 ripley moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1556 * Subject: lib.fixup, .GlobalEnv, and R1.5.0 From: mark.bravington@csiro.au Date: Wed, 15 May 2002 08:30:50 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1556 <== From mark.bravington@csiro.au Wed May 15 08:30:50 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA24614 for ; Wed, 15 May 2002 08:30:50 +0200 (MET DST) Date: Wed, 15 May 2002 08:30:50 +0200 (MET DST) From: mark.bravington@csiro.au Message-Id: <200205150630.IAA24614@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: lib.fixup, .GlobalEnv, and R1.5.0 Full_Name: Mark Bravington Version: 1.5.0 OS: Windows 2000 Submission from: (NULL) (140.79.2.3) In R1.3.1, I used the following code inside a function to set a "path" attribute to .GlobalEnv: env_ pos.to.env( 1) attr( env, 'path')_ .Path # .Path is a named char vector of length 1 .Internal( lib.fixup( env, .GlobalEnv)) # adds the attribute And this works fine. But in R1.5.0, the same code (executed e.g. within a call to "local" from the command line) removes all the objects in .GlobalEnv (note, though, that the 'path' attribute does get set OK). For various reasons, this feature is crucial to me, so I can't actually use R1.5.0 without it! Oddly, my code used to explicitly set a path attribute for newly-attached things using this mechanism, and this has now been incorporated into R1.5.0 "library" command. So I'm clearly not doing anything naughty here! A suggestion: wouldn't it be easier if we could use attr( env, <>) # where env is an environment and attr( env, <>)_ 45 instead of having to go via "lib.fixup"? cheers Mark ==> 1556.followup.1 <== From Mark.Bravington@csiro.au Thu May 16 08:48:23 2002 Received: from bastion.tas.csiro.au (bastion.tas.csiro.au [140.79.2.8]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id IAA04149 for ; Thu, 16 May 2002 08:48:21 +0200 (MET DST) From: Mark.Bravington@csiro.au Received: from bastion.tas.csiro.au (localhost [127.0.0.1]) by bastion.tas.csiro.au (8.11.4/8.11.4) with ESMTP id g4G6le813565 for ; Thu, 16 May 2002 16:47:41 +1000 (EST) Received: from molly.tas.csiro.au (molly.tas.csiro.au [140.79.3.40]) by bastion.tas.csiro.au (8.11.4/8.11.4) with ESMTP id g4G6leO13554 for ; Thu, 16 May 2002 16:47:40 +1000 (EST) Received: by molly.tas.csiro.au with Internet Mail Service (5.5.2655.55) id ; Thu, 16 May 2002 16:47:30 +1000 Message-ID: To: r-bugs@biostat.ku.dk Subject: (PR#1556) Date: Thu, 16 May 2002 16:47:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" lib.fixup My previous post mentions a problem encountered when calling ".Internal( lib.fixup..." in R1.5.0. I have since found a workaround. It's possible in R1.5.0 to set attributes of search path environments directly, like so: > env_ pos.to.env( 3) > attr( env, 'any.attr')_ 'any.value' > pos.to.env( 3) attr(,"name") [1] "package:tcltk" attr(,"path") [1] "C:/R/rw1050/library/tcltk" attr(,"any.attr") [1] "any.value" In R1.3.1, it used to be necessary to use lib.fixup to achieve this. It's still not possible to call > attr( pos.to.env( 3), 'any.attr')_ 'any.value' directly, but this doesn't matter. My (mis-typed) wish-lish-suggestion in the last post, is therefore irrelevant, and personally I no longer need lib.fixup. NB that it can still cause problems if it is used-- but as it's undocumented, I don't suppose this will be a major issue. Nevertheless, calls to ".Internal( lib.fixup..." are not things of beauty, and I wonder whether the current usage in "library" is actually necessary? The code currently reads loadenv <- new.env(hash = TRUE, parent = .GlobalEnv) <<...>> sys.source(codeFile, loadenv, keep.source = keep.source) <<...>> env <- attach(NULL, name = pkgname) on.exit(do.call("detach", list(name = pkgname))) attr(env, "path") <- file.path(which.lib.loc, package) .Internal(lib.fixup(loadenv, env)) but I seem to get satisfactory results with env_ attach( NULL, name = pkgname) on.exit(do.call("detach", list(name = pkgname))) attr( env, "path") <- file.path(which.lib.loc, package) <<...>> sys.source(codeFile, env, keep.source = keep.source) # i.e. straight into "env" not into "loadenv" <<...>> which does away with the calls to "new.env" and "lib.fixup". As far as I can see, the "parent=.GlobalEnv" argument to "new.env" doesn't have any effect after "lib.fixup"; I'm not sure about the "hash=TRUE". cheers Mark ******************************* Mark Bravington CSIRO (CMIS) PO Box 1538 Castray Esplanade Hobart TAS 7001 phone (61) 3 6232 5118 fax (61) 3 6232 5012 Mark.Bravington@csiro.au ==> 1556.audit <== Thu Jan 16 10:19:58 2003 ripley moved from incoming to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4051 * Subject: completeSubclasses() methods bug From: colin@colinsmith.org Date: Tue, 2 Sep 2003 22:15:26 +0200 (MET DST) --methods package ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4051 <== From colin@colinsmith.org Tue Sep 2 22:15:26 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h82KFQJH015006 for ; Tue, 2 Sep 2003 22:15:26 +0200 (MET DST) Date: Tue, 2 Sep 2003 22:15:26 +0200 (MET DST) Message-Id: <200309022015.h82KFQJH015006@pubhealth.ku.dk> From: colin@colinsmith.org To: R-bugs@biostat.ku.dk Subject: completeSubclasses() methods bug Full_Name: Colin A. Smith Version: 1.8.0 OS: Mac OS X 10.2.6 Submission from: (NULL) (128.102.184.81) annaffy 1.0.1 (in BioC CVS) fails to load. annaffy 1.0 (on the BioC web site) has the same problem. It looks like the load is failing because of a bug in completeSubclasses() in r-devel. It calls setIs() and doesn't specify an environment via the "where" argument. setIs() "where" defaults to topEnv() and fails because "aafGO" doesn't exist in that environment and "list" is sealed. completeSubclasses should be specifying my package for "where" instead of using the default. > library(annaffy) Error in setIs(class2, obji@superClass, extensionObject = obji, doComplete = FALSE) : Cannot create a setIs relation when neither of the classes ("aafGO" and "list") is local and modifiable in this package Error in setClass("aafGO", "aafList", prototype = list(), where = where) : Error in contained classes ("aafList") for class "aafGO"; class definition removed from "annaffy" Error in library(annaffy) : .First.lib failed ==> 4051.followup.1 <== From jmc@research.bell-labs.com Wed Sep 3 14:30:33 2003 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h83CUWJH023186 for ; Wed, 3 Sep 2003 14:30:32 +0200 (MET DST) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h83CUVHa042481; Wed, 3 Sep 2003 08:30:31 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h83CUP2e057610; Wed, 3 Sep 2003 08:30:25 -0400 (EDT) Received: from research.bell-labs.com (guinan.cs.bell-labs.com [135.104.50.225]) by jessie.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h83CUOD8018455; Wed, 3 Sep 2003 08:30:24 -0400 (EDT) Sender: jmc@research.bell-labs.com Message-ID: <3F55DEB8.990C1A88@research.bell-labs.com> Date: Wed, 03 Sep 2003 08:29:44 -0400 From: John Chambers Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: colin@colinsmith.org CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] completeSubclasses() methods bug (PR#4051) References: <200309022015.h82KFRJH015010@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, thanks. I have a corrected version checked out. It has some other changes--as soon as I make a cleaned-up version with this fix only, I'll commit it. John colin@colinsmith.org wrote: > > Full_Name: Colin A. Smith > Version: 1.8.0 > OS: Mac OS X 10.2.6 > Submission from: (NULL) (128.102.184.81) > > annaffy 1.0.1 (in BioC CVS) fails to load. annaffy 1.0 (on the BioC web site) > has the same problem. > > It looks like the load is failing because of a bug in completeSubclasses() in > r-devel. It calls setIs() and doesn't specify an environment via the "where" > argument. setIs() "where" defaults to topEnv() and fails because "aafGO" doesn't > exist in that environment and "list" is sealed. > > completeSubclasses should be specifying my package for "where" instead of using > the default. > > > library(annaffy) > Error in setIs(class2, obji@superClass, extensionObject = obji, doComplete = > FALSE) : > Cannot create a setIs relation when neither of the classes ("aafGO" and > "list") is local and modifiable in this package > Error in setClass("aafGO", "aafList", prototype = list(), where = where) : > Error in contained classes ("aafList") for class "aafGO"; class > definition removed from "annaffy" > Error in library(annaffy) : .First.lib failed > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel -- John M. Chambers jmc@bell-labs.com Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc ==> 4051.audit <== Tue Sep 2 22:38:06 2003 ripley changed notes Tue Sep 2 22:38:06 2003 ripley foobar Thu Sep 4 18:46:43 2003 thomas moved from incoming to feature&FAQ Thu Sep 4 18:47:09 2003 thomas moved from feature&FAQ to Language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Low-level * PR# 989 * Subject: "[.data.frame" allows un-named 3rd subscript From: "Charles C. Berry" Date: Mon, 18 Jun 2001 13:13:46 -0700 (PDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 989 <== From cberry@tajo.ucsd.edu Mon Jun 18 22:10:28 2001 Received: from mailbox4.ucsd.edu (mailbox4.ucsd.edu [132.239.1.56]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA14900 for ; Mon, 18 Jun 2001 22:10:27 +0200 (MET DST) Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49]) by mailbox4.ucsd.edu (8.11.3/8.11.0) with ESMTP id f5IKAKq28590 for ; Mon, 18 Jun 2001 13:10:20 -0700 (PDT) Received: from tajo.ucsd.edu (tajo.ucsd.edu [132.239.99.2]) by smtp.ucsd.edu (8.9.3/8.9.3) with ESMTP id NAA24075 for ; Mon, 18 Jun 2001 13:10:20 -0700 (PDT) Received: by tajo.ucsd.edu (8.9.3+Sun/SMI-SVR4-UCSD.1) id NAA15110; Mon, 18 Jun 2001 13:13:46 -0700 (PDT) Date: Mon, 18 Jun 2001 13:13:46 -0700 (PDT) Message-Id: <200106182013.NAA15110@tajo.ucsd.edu> From: "Charles C. Berry" To: r-bugs@biostat.ku.dk Subject: "[.data.frame" allows un-named 3rd subscript Since the Extract page has usage as: x[i, j, ... , drop=TRUE] I would expect that 'drop=' would need to be given to the third 'subscript' > diag(4)[ , 4 , 4 ] # Forgot 'drop=' or added extra ',' Error in diag(4)[, 4, 4] : incorrect number of dimensions > > as.data.frame( diag(4) )[ , 4 , 4 ] # should return error, right? [1] 0 0 0 1 Also note: > diag(4)[ , , drop=TRUE ] [,1] [,2] [,3] [,4] [1,] 1 0 0 0 [2,] 0 1 0 0 [3,] 0 0 1 0 [4,] 0 0 0 1 > > as.data.frame( diag(4) )[ , , drop=TRUE ] Error in [.data.frame(as.data.frame(diag(4)), , , drop = 4) : Argument "j" is missing, with no default > --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = major = 1 minor = 2.3 year = 2001 month = 04 day = 26 language = R Search Path: .GlobalEnv, package:nls, package:nlme, package:ctest, Autoloads, package:base Chuck -- Charles C. Berry (858) 534-2098 Dept of Family/Preventive Medicine E mailto:cberry@tajo.ucsd.edu UC San Diego http://hacuna.ucsd.edu/members/ccb.html La Jolla, San Diego 92093-0645 ==> 989.reply.1 <== From pd@blueberry.kubism.ku.dk Mon Jun 18 22:35:29 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id WAA15008; Mon, 18 Jun 2001 22:35:28 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.9.3/8.9.3) id WAA31163; Mon, 18 Jun 2001 22:38:38 +0200 Sender: pd@pubhealth.ku.dk To: cberry@tajo.ucsd.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] "[.data.frame" allows un-named 3rd subscript (PR#989) References: <200106182010.WAA14911@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 18 Jun 2001 22:38:38 +0200 In-Reply-To: cberry@tajo.ucsd.edu's message of "Mon, 18 Jun 2001 22:10:29 +0200 (MET DST)" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cberry@tajo.ucsd.edu writes: > Since the Extract page has usage as: > > x[i, j, ... , drop=TRUE] > > I would expect that 'drop=' would need to be given to the third 'subscript' > > > diag(4)[ , 4 , 4 ] # Forgot 'drop=' or added extra ',' > Error in diag(4)[, 4, 4] : incorrect number of dimensions > > > > as.data.frame( diag(4) )[ , 4 , 4 ] # should return error, right? > [1] 0 0 0 1 > And the bug is? The generic indexing should really be x[...,drop=T]. Methods for specific classes can specialize to a particular number of indices if they want to, which is what is happening here > get ("[.data.frame") function (x, i, j, drop = if (missing(i)) TRUE else length(cols) == 1) one could fairly easily slip in a "..." argument after "j", and then inside the function give an error if "..." is not empty, but what would the point be? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 989.followup.1 <== From cberry@tajo.ucsd.edu Mon Jun 18 23:06:32 2001 Received: from mailbox3.ucsd.edu (mailbox3.ucsd.edu [132.239.1.55]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA15201; Mon, 18 Jun 2001 23:06:31 +0200 (MET DST) Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49]) by mailbox3.ucsd.edu (8.10.1/8.11.0) with ESMTP id f5IL6PR16820; Mon, 18 Jun 2001 14:06:25 -0700 (PDT) Received: from tajo.ucsd.edu (tajo.ucsd.edu [132.239.99.2]) by smtp.ucsd.edu (8.9.3/8.9.3) with ESMTP id OAA06469; Mon, 18 Jun 2001 14:06:24 -0700 (PDT) Received: from localhost by tajo.ucsd.edu (8.9.3+Sun/SMI-SVR4-UCSD.1) id OAA15733; Mon, 18 Jun 2001 14:09:49 -0700 (PDT) Date: Mon, 18 Jun 2001 14:09:49 -0700 (PDT) From: "Charles C. Berry" To: Peter Dalgaard BSA cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] "[.data.frame" allows un-named 3rd subscript (PR#989) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII See below. On 18 Jun 2001, Peter Dalgaard BSA wrote: > cberry@tajo.ucsd.edu writes: > > > Since the Extract page has usage as: > > > > x[i, j, ... , drop=TRUE] > > > > I would expect that 'drop=' would need to be given to the third 'subscript' > > > > > diag(4)[ , 4 , 4 ] # Forgot 'drop=' or added extra ',' > > Error in diag(4)[, 4, 4] : incorrect number of dimensions > > > > > > as.data.frame( diag(4) )[ , 4 , 4 ] # should return error, right? > > [1] 0 0 0 1 > > > > And the bug is? > > The generic indexing should really be x[...,drop=T]. Methods for > specific classes can specialize to a particular number of indices if > they want to, which is what is happening here > > > get ("[.data.frame") > function (x, i, j, drop = if (missing(i)) TRUE else length(cols) == > 1) > > one could fairly easily slip in a "..." argument after "j", and then > inside the function give an error if "..." is not empty, but what > would the point be? > The point would be to catch errors like this for ( i in 1:2 ) foo[i,2] <- my.fun( bar[,i,2] , another.arg ) that might otherwise pass unnoticed when 'bar' is a data.frame. Charles C. Berry (858) 534-2098 Dept of Family/Preventive Medicine E mailto:cberry@tajo.ucsd.edu UC San Diego http://hacuna.ucsd.edu/members/ccb.html La Jolla, San Diego 92093-0645 ==> 989.audit <== Tue Jun 19 09:07:09 2001 ripley moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1068 * Subject: Interrupts (was Re: [Rd] X11 protocol errors ...) From: Luke Tierney Date: Wed, 22 Aug 2001 19:32:51 -0500 --see also followup in PR#1069 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1068 <== From luke@nokomis.stat.umn.edu Thu Aug 23 02:32:58 2001 Received: from nokomis.stat.umn.edu (root@nokomis.stat.umn.edu [134.84.86.39]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id CAA09952 for ; Thu, 23 Aug 2001 02:32:57 +0200 (MET DST) Received: (from luke@localhost) by nokomis.stat.umn.edu (8.11.3/8.10.2/SuSE Linux 8.10.0-0.3) id f7N0Wpq10715; Wed, 22 Aug 2001 19:32:51 -0500 Date: Wed, 22 Aug 2001 19:32:51 -0500 From: Luke Tierney To: maechler@stat.math.ethz.ch Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Interrupts (was Re: [Rd] X11 protocol errors ...) Message-ID: <20010822193251.A10682@nokomis.stat.umn.edu> References: <200108221235.OAA05855@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108221235.OAA05855@pubhealth.ku.dk>; from maechler@stat.math.ethz.ch on Wed, Aug 22, 2001 at 02:35:24PM +0200 Martin wrote: > Just this morning, > I found (again!, we had something close to this before) > the following related bugous behavior : > After interrupting a plot (which would have taken a few minutes and was > "wrong" anyway), starting another plot, interrupting again [with C-c], > and maybe the same once more, > R started just giving a ">" prompt > but did not react any further at all. > (C-c would return the prompt, but no other reaction was possible) > Only killing the R process helped. > > I may try to reproduce more exactly later today. I'm surprised we don't get more of these sorts of things on UNIX. Our current UNIX interrupt handling approach takes an immediate LONGJMP out of the signal handler no matter where the signal occurs (except for two places where signals are suspended). Any place where an invariant is temporarily broken, any place where an assignment is not yet complete, is a potential trouble spot. I've been meaning to raise this issue at some point: I think we will need to eventually spend some time re-examining how we want to handle interrupts. Right now on Windows/Mac interrupts are only processed at special points in the evaluation process, which is a bit restrictive (but perhaps unavoidable due to OS limitations). On UNIX on the other hand we LONGJUMP out of the signal handler except for the very few places where the signal gets masked temporarily (GC and one place in graphics I believe). The UNIX approach is much too loose even now, and it becomes even more untenable if we add any kind of threading support. We will I think have to come up with a cleaner model for very selectively enabling interrupt processing, perhaps with some integration with the external function registration mechanism Duncan added recently (e.g. marking a function as one where LONGJMP's are safe). We will also need some means of controlling interrupt behaviour from R, such as having some sort of without.interrupts and with.interrupts functions to be able to program reliable interaction with interrupts at the R level. (Another sort of thing we might consider is suspending interrupts during on.exit processing.) It's a farily big can of worms, and probably not urgent for now, but we will need to look at it eventually. luke -- Luke Tierney University of Minnesota Phone: 612-625-7843 School of Statistics Fax: 612-624-8868 313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu ==> 1068.audit <== Tue Aug 28 10:16:46 2001 ripley moved from incoming to Low-level Tue Aug 28 10:23:54 2001 ripley changed notes Tue Aug 28 10:23:54 2001 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1069 * Subject: Interrupts (was Re: [Rd] X11 protocol errors ...) From: "John W. Eaton" Date: Wed, 22 Aug 2001 21:56:33 -0500 --part of PR#1068 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1069 <== From jwe@ricotta.che.wisc.edu Thu Aug 23 04:57:11 2001 Received: from ricotta.che.wisc.edu (ricotta.che.wisc.edu [128.104.179.160]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id EAA10175 for ; Thu, 23 Aug 2001 04:57:10 +0200 (MET DST) Received: from ricotta.che.wisc.edu (jwe@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7N2uZqU003270; Wed, 22 Aug 2001 21:56:35 -0500 Received: (from jwe@localhost) by ricotta.che.wisc.edu (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f7N2uXNS003266; Wed, 22 Aug 2001 21:56:33 -0500 From: "John W. Eaton" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.28897.468790.842201@ricotta.che.wisc.edu> Date: Wed, 22 Aug 2001 21:56:33 -0500 To: Luke Tierney Cc: maechler@stat.math.ethz.ch, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Interrupts (was Re: [Rd] X11 protocol errors ...) In-Reply-To: <20010822193251.A10682@nokomis.stat.umn.edu> References: <200108221235.OAA05855@pubhealth.ku.dk> <20010822193251.A10682@nokomis.stat.umn.edu> X-Mailer: VM 6.95 under Emacs 20.7.2 On 22-Aug-2001, Luke Tierney wrote: | We will I think have to come up with a cleaner model for very | selectively enabling interrupt processing, perhaps with some | integration with the external function registration mechanism Duncan | added recently (e.g. marking a function as one where LONGJMP's are | safe). FWIW, Octave doesn't do this correctly either, it just does a longjmp, same as R, which can result in leaking memory, and possibly other bad things. The way Bash handles this is to only set a flag in the handler for SIGINT, then at safe places in the code, there are QUIT; statements. These are macros that expand to some code that may longjump somewhere depending on the interrupt state. This method avoids the problems of jumping out of the signal handler, which may result in memory leaks or inconsistencies in global state. The hard part is inserting the (many!) QUIT statements, though it is probably somewhat easier if this type of choice is made early on in the life of the program instead of late. I only mention Bash because it is a program that is expected to handle a lot of interrupts without leaking memory or crashing, and seems to do so reasonably well. Packages like R and Octave also have to be able to handle interrupts in calls Fortran or C code that may run for a long time, and which cannot be modified (at least not easily) to add the equivalent QUIT calls. I'm not sure what the right solution is for cases like that. jwe -- www.octave.org | Unfortunately we were hoplessly optimistic in 1954 www.che.wisc.edu/~jwe | about the problems of debugging FORTRAN programs. | -- J. Backus ==> 1069.audit <== Tue Aug 28 10:16:46 2001 ripley moved from incoming to Low-level Tue Aug 28 10:23:24 2001 ripley changed notes Tue Aug 28 10:23:24 2001 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1880 * Subject: You requested this report From: Berwin Turlach Date: Tue, 6 Aug 2002 16:57:54 +0800 --The bug is that we get as far as mkCLOSXP before an error is reported ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1880 <== From postmaster@franz.stat.wisc.edu Tue Aug 6 10:58:39 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA21842 for ; Tue, 6 Aug 2002 10:58:38 +0200 (MET DST) Received: from asclepius.uwa.edu.au (really [130.95.128.56]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Tue, 6 Aug 2002 03:57:56 -0500 (CDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id DE5CB2F8B7F for ; Tue, 6 Aug 2002 16:56:24 +0800 (WST) Received: from bossiaea.maths.uwa.edu.au (bossiaea.maths.uwa.edu.au [130.95.16.247]) by asclepius.uwa.edu.au (Postfix) with ESMTP id C3D5C2F8B56 for ; Tue, 6 Aug 2002 16:56:24 +0800 (WST) Received: (from berwin@localhost) by bossiaea.maths.uwa.edu.au (8.9.3/8.9.3) id QAA23639; Tue, 6 Aug 2002 16:57:54 +0800 Date: Tue, 6 Aug 2002 16:57:54 +0800 From: Berwin Turlach Message-Id: <200208060857.QAA23639@bossiaea.maths.uwa.edu.au> To: r-bugs@r-project.org Subject: You requested this report Cc: berwin@bossiaea.maths.uwa.edu.au Hi guys, I am planning to let my students do some simulations regarding the bias of the sample standard deviation. The following function is pretty standard (so I hope :) ): > sim <- function(nrng, replic, true.s, random, ...){ + res <- NULL + for(n in nrng){ + data <- matrix(random(n*replic,...), ncol=replic) + val <- sqrt(apply(data, 2, var)) + res <- rbind(res, + cbind(bias=val-true.s, n=n)) + } + res + } It takes a vector of sample sizes, a number (the number of replications we want to simulate), the true value of the standard deviation and a function that generates the random number (which may depend on additional paramters). So let's try this: > nrng <- c(2,4,8,16,32,64) > replic <- 500 > true.s <- 2 > tmp <- sim(nrng, replic, true.s, rnorm, sd = 2) Yes, seems to work. Now I thought of perhaps creating a list of several scenarios (random numbers) and loop over it. So I tried: > dist <- list(list(rnorm, true.s = 2, sd=2), + list(rexp, true.s = 1) + ) Followed by > res <- sim(nrng, replic, dist[[1]][2], dist[[1]][1], dist[[1]][-c(1,2)]) Error in as.vector(data) : couldn't find function "random" O.k., this doesn't work. So let us try: > res <- sim(nrng, replic, dist[[1]][2], as.function(dist[[1]][1]), dist[[1]][-c(1,2)]) Error in as.function.default(dist[[1]][1]) : invalid body argument for "function" Should NEVER happen; please bug.report() [mkCLOSXP] No idea why you consider this a bug. :) I would have been willing to put it down to my misuse of R. But since you requested a bug report, here it is. Cheers, Berwin BTW: How can I actually do what I want to do? I realise that I am probably on a completely wrong track regarding the passing of the ... parameters. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 5.1 year = 2002 month = 06 day = 17 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base ==> 1880.audit <== Mon Aug 19 22:35:34 2002 thomas changed notes Mon Aug 19 22:35:34 2002 thomas foobar Mon Aug 19 22:35:34 2002 thomas moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2253 * Subject: [R] CTRL-C suspends echo of shell (R versions 1.6.0 and 1.6.1) From: Wolfram Fischer - Z/I/M Date: Mon, 4 Nov 2002 10:18:48 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2253 <== From wolfram@fischer-zim.ch Mon Nov 4 10:19:44 2002 Received: from franz.stat.wisc.edu (mail@www.omegahat.org [128.105.174.32]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA18585 for ; Mon, 4 Nov 2002 10:19:43 +0100 (MET) Received: from ecslin02.ecs.ch ([193.134.251.17]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 188dNq-0001QS-00 for ; Mon, 04 Nov 2002 03:18:58 -0600 Received: from s1x.zimnet.ch (dialin-d-15.ecs.ch [194.69.197.15]) by ecslin02.ecs.ch (8.9.3/8.9.3) with ESMTP id KAA32376 for ; Mon, 4 Nov 2002 10:18:55 +0100 Received: (from wf@localhost) by s1x.zimnet.ch (8.11.6/8.11.6/SuSE Linux 0.5) id gA49Im017451 for r-bugs@r-project.org; Mon, 4 Nov 2002 10:18:48 +0100 Date: Mon, 4 Nov 2002 10:18:48 +0100 From: Wolfram Fischer - Z/I/M To: r-bugs@r-project.org Subject: [R] CTRL-C suspends echo of shell (R versions 1.6.0 and 1.6.1) Message-ID: <20021104101848.A17333@s1x.zimnet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Problem: - Shell does not echo anymore after using CTRL-C (to interrupt calculations) once during a R session. Procedure: - [start session] R - [input] CTRL-C - [end session] q() Some details: - `stty` before: speed 38400 baud; line = 0; lnext = ; - `stty` after: speed 38400 baud; line = 0; lnext = ; min = 1; time = 0; -icrnl -icanon -echo I have seen the problem in versions 1.6.0 and 1.6.1, but not in 1.5.1 which I am running on SuSE Linux 7.3. The shell used is bash-2.05.0(1). Wolfram Fischer ==> 2253.reply.1 <== From p.dalgaard@biostat.ku.dk Mon Nov 4 10:58:57 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id KAA19354; Mon, 4 Nov 2002 10:58:56 +0100 (MET) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.6/8.11.6) id gA49wsH01807; Mon, 4 Nov 2002 10:58:54 +0100 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: wolfram@fischer-zim.ch Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [R] CTRL-C suspends echo of shell (R versions 1.6.0 and 1.6.1) (PR#2253) References: <200211040919.KAA18590@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 04 Nov 2002 10:58:53 +0100 In-Reply-To: <200211040919.KAA18590@pubhealth.ku.dk> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii wolfram@fischer-zim.ch writes: > Problem: > - Shell does not echo anymore > after using CTRL-C (to interrupt calculations) > once during a R session. > > Procedure: > - [start session] R > - [input] CTRL-C > - [end session] q() > > > Some details: > - `stty` before: speed 38400 baud; line = 0; lnext = ; > > - `stty` after: speed 38400 baud; line = 0; lnext = ; min = 1; time = 0; > -icrnl > -icanon -echo > > I have seen the problem in versions 1.6.0 and 1.6.1, but not in 1.5.1 > which I am running on SuSE Linux 7.3. The shell used is bash-2.05.0(1). Seen here too, but I actually thought it took more to provoke it. Blind-enter "stty sane" to revert. (Might this be related to the readline stack issue?) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 2253.audit <== Mon Nov 4 15:22:27 2002 maechler foobar Mon Nov 4 15:22:27 2002 maechler moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4073 * Subject: Problem with S4 slots in C code From: Laurence Kell FM CEFAS Date: Fri, 5 Sep 2003 10:23:38 +0100 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4073 <== From mailnull@stat.math.ethz.ch Fri Sep 5 11:27:11 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h859R8JH015525 for ; Fri, 5 Sep 2003 11:27:10 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h859QD0j026715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Sep 2003 11:26:13 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h859QDS5026714 for R-bugs@biostat.ku.dk; Fri, 5 Sep 2003 11:26:13 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h859Q40i026679 for ; Fri, 5 Sep 2003 11:26:05 +0200 (MEST) Received: from mailhost.bequalm.org ([62.190.17.165] helo=terminal1.cefas.co.uk) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19vCro-0001au-00 for ; Fri, 05 Sep 2003 04:26:56 -0500 Received: from lowexpress2.corp.cefas.co.uk (unverified) by terminal1.cefas.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 5 Sep 2003 10:25:56 +0100 Received: by LOWEXPRESS2.corp.cefas.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 10:24:05 +0100 Message-ID: <8FC44BEDB265D711972400508B6D77960482E4@LOWEXPRESS1.corp.cefas.co.uk> From: Laurence Kell FM CEFAS To: "'r-bugs@r-project.org'" Subject: Problem with S4 slots in C code Date: Fri, 5 Sep 2003 10:23:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3738F.63DE3390" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3738F.63DE3390 Content-Type: text/plain; charset="iso-8859-1" #I want to be able to create a new S4 class and read data into it using C code # Here is a very simple S4 object inheriting from "array", but with 5 specified dimensions #(the validity stuff has been stripped out to make it short as I don't think it is the problem here) setClass("FLQuant", representation("array"), prototype=(array(1, dim=c(1,1,1,1,1), dimnames=list(age="0", year="0", sex="combined", season="all", area="all"))) ) # In R, I can create a new "FLQuant" object: > fl <- new("FLQuant") > fl An object of class "FLQuant" , , sex = combined, season = all, area = all year age 0 0 1 # and: > aa <- array(2, dim=c(1,1,1,1,1), dimnames=list(age="1", year="2000", sex="combined", season="all", area="all")) > aa , , sex = combined, season = all, area = all year age 2000 1 2 # Putting the array aa into fl is done like this (by the way, is this a correct way to do it?): > fl@.Data <- aa > fl An object of class "FLQuant" , , sex = combined, season = all, area = all year age 2000 1 2 # Now, we want to do the same in C, to interface with existing code. # However, the .Data slot is not being replaced with the new object > dyn.load("C:/fl/flr/flr.dll") > test<-function() .Call("Test") > test() An object of class "FLQuant": , , sex = combined, season = all, area = all year age 0 0 1 > #C code to do the same thing extern "C" __declspec(dllexport) SEXP __stdcall Test(void) { SEXP FLQuant, v, d1, d2, d3, d4, d5, dim, dimnames, names; //Create new S4 object PROTECT(FLQuant = NEW_OBJECT(MAKE_CLASS("FLQuant"))); //Create array for slot //Set dimensions of array PROTECT(dim = allocVector(INTSXP, 5)); INTEGER(dim)[0] = 1; INTEGER(dim)[1] = 1; INTEGER(dim)[2] = 1; INTEGER(dim)[3] = 1; INTEGER(dim)[4] = 1; //Allocate memory PROTECT(v = Rf_allocArray(REALSXP, dim)); //Create dimension names PROTECT(dimnames = allocVector(VECSXP, 5)); PROTECT(d1 = allocVector(INTSXP, 1)); INTEGER(d1)[0] = 1; SET_VECTOR_ELT(dimnames, 0, d1); PROTECT(d2 = allocVector(INTSXP, 1)); INTEGER(d2)[0] = 2000; SET_VECTOR_ELT(dimnames, 1, d2); PROTECT(d3 = allocVector(STRSXP, 1)); SET_STRING_ELT(d3, 0, mkChar("combined")); SET_VECTOR_ELT(dimnames, 2, d3); PROTECT(d4 = allocVector(STRSXP, 1)); SET_STRING_ELT(d4, 0, mkChar("all")); SET_VECTOR_ELT(dimnames, 3, d4); PROTECT(d5 = allocVector(STRSXP, 1)); SET_STRING_ELT(d5, 0, mkChar("all")); SET_VECTOR_ELT(dimnames, 4, d5); //Create names for dimensions PROTECT(names = allocVector(STRSXP, 5)); SET_STRING_ELT(names, 0, mkChar("age")); SET_STRING_ELT(names, 1, mkChar("year")); SET_STRING_ELT(names, 2, mkChar("sex")); SET_STRING_ELT(names, 3, mkChar("season")); SET_STRING_ELT(names, 4, mkChar("area")); setAttrib(dimnames, R_NamesSymbol, names); setAttrib(v, R_DimNamesSymbol, dimnames); //Set data REAL(v)[0] = 2; //Set slot SET_SLOT(FLQuant, install(".Data"), v); UNPROTECT(10); return FLQuant; } --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 7.1 year = 2003 month = 06 day = 16 language = R Windows 2000 Professional (build 2195) Service Pack 3.0 Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base <> ------_=_NextPart_000_01C3738F.63DE3390 Content-Type: application/octet-stream; name="Laurence Kell (E-mail).vcf" Content-Disposition: attachment; filename="Laurence Kell (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Kell;Laurence FN:Laurence Kell (E-mail) ORG:CEFAS TEL;WORK;VOICE:+44 (0) 1502 524257 TEL;WORK;FAX:+44 (0) 1502 524511 ADR;WORK:;;Lowestoft Laboratory;Pakefield Road;Lowestoft,;NR33 0HT;UK LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Lowestoft Laboratory=0D=0APakefield Road, Lowestoft, NR33 0HT=0D=0AUK EMAIL;PREF;INTERNET:/o=CEFAS/ou=LOWESTOFT/cn=Recipients/cn=LTK00 REV:20030410T130517Z END:VCARD ------_=_NextPart_000_01C3738F.63DE3390-- ==> 4073.followup.1 <== From duncan@research.bell-labs.com Fri Sep 5 16:29:10 2003 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h85ET9JH020331 for ; Fri, 5 Sep 2003 16:29:09 +0200 (MET DST) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h85ET99Y079751; Fri, 5 Sep 2003 10:29:09 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h85ET22e086883; Fri, 5 Sep 2003 10:29:02 -0400 (EDT) Received: from jessie.research.bell-labs.com (localhost [127.0.0.1]) by jessie.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h85ET1D8007563; Fri, 5 Sep 2003 10:29:01 -0400 (EDT) Received: (from duncan@localhost) by jessie.research.bell-labs.com (8.12.9/8.12.9/Submit) id h85ET1v5007557; Fri, 5 Sep 2003 10:29:01 -0400 (EDT) Date: Fri, 5 Sep 2003 10:29:01 -0400 From: Duncan Temple Lang To: L.T.Kell@cefas.co.uk Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Problem with S4 slots in C code (PR#4073) Message-ID: <20030905102900.C6490@jessie.research.bell-labs.com> Mail-Followup-To: Duncan Temple Lang , L.T.Kell@cefas.co.uk, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk References: <200309050927.h859RDJH015529@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200309050927.h859RDJH015529@pubhealth.ku.dk>; from L.T.Kell@cefas.co.uk on Fri, Sep 05, 2003 at 11:27:14AM +0200 In the case of the .Data slot, you will probably want to use FLQuant = R_do_slot_assign(FLQuant, install(".Data"), v); rather than SET_SLOT(). I am not certain if we have updated this yet (and it is hard for me to check with very limited network access). L.T.Kell@cefas.co.uk wrote: > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_000_01C3738F.63DE3390 > Content-Type: text/plain; > charset="iso-8859-1" > > #I want to be able to create a new S4 class and read data into it using C > code > > # Here is a very simple S4 object inheriting from "array", but with 5 > specified dimensions > #(the validity stuff has been stripped out to make it short as I don't think > it is the problem here) > > setClass("FLQuant", > representation("array"), > prototype=(array(1, dim=c(1,1,1,1,1), dimnames=list(age="0", > year="0", sex="combined", season="all", area="all"))) > ) > > # In R, I can create a new "FLQuant" object: > > fl <- new("FLQuant") > > fl > An object of class "FLQuant" > , , sex = combined, season = all, area = all > > year > age 0 > 0 1 > > # and: > > aa <- array(2, dim=c(1,1,1,1,1), dimnames=list(age="1", year="2000", > sex="combined", season="all", area="all")) > > aa > , , sex = combined, season = all, area = all > > year > age 2000 > 1 2 > > # Putting the array aa into fl is done like this (by the way, is this a > correct way to do it?): > > fl@.Data <- aa > > fl > An object of class "FLQuant" > , , sex = combined, season = all, area = all > > year > age 2000 > 1 2 > > # Now, we want to do the same in C, to interface with existing code. > # However, the .Data slot is not being replaced with the new object > > > > dyn.load("C:/fl/flr/flr.dll") > > test<-function() .Call("Test") > > test() > > An object of class "FLQuant": > > , , sex = combined, season = all, area = all > > year > age 0 > 0 1 > > > > #C code to do the same thing > extern "C" __declspec(dllexport) SEXP __stdcall Test(void) > { > SEXP FLQuant, v, > d1, d2, d3, d4, d5, > dim, dimnames, names; > > //Create new S4 object > PROTECT(FLQuant = NEW_OBJECT(MAKE_CLASS("FLQuant"))); > > //Create array for slot > //Set dimensions of array > PROTECT(dim = allocVector(INTSXP, 5)); > INTEGER(dim)[0] = 1; > INTEGER(dim)[1] = 1; > INTEGER(dim)[2] = 1; > INTEGER(dim)[3] = 1; > INTEGER(dim)[4] = 1; > > //Allocate memory > PROTECT(v = Rf_allocArray(REALSXP, dim)); > > //Create dimension names > PROTECT(dimnames = allocVector(VECSXP, 5)); > > PROTECT(d1 = allocVector(INTSXP, 1)); > INTEGER(d1)[0] = 1; > SET_VECTOR_ELT(dimnames, 0, d1); > > PROTECT(d2 = allocVector(INTSXP, 1)); > INTEGER(d2)[0] = 2000; > SET_VECTOR_ELT(dimnames, 1, d2); > > PROTECT(d3 = allocVector(STRSXP, 1)); > SET_STRING_ELT(d3, 0, mkChar("combined")); > SET_VECTOR_ELT(dimnames, 2, d3); > > PROTECT(d4 = allocVector(STRSXP, 1)); > SET_STRING_ELT(d4, 0, mkChar("all")); > SET_VECTOR_ELT(dimnames, 3, d4); > > PROTECT(d5 = allocVector(STRSXP, 1)); > SET_STRING_ELT(d5, 0, mkChar("all")); > SET_VECTOR_ELT(dimnames, 4, d5); > > //Create names for dimensions > PROTECT(names = allocVector(STRSXP, 5)); > SET_STRING_ELT(names, 0, mkChar("age")); > SET_STRING_ELT(names, 1, mkChar("year")); > SET_STRING_ELT(names, 2, mkChar("sex")); > SET_STRING_ELT(names, 3, mkChar("season")); > SET_STRING_ELT(names, 4, mkChar("area")); > setAttrib(dimnames, R_NamesSymbol, names); > setAttrib(v, R_DimNamesSymbol, dimnames); > > //Set data > REAL(v)[0] = 2; > > //Set slot > SET_SLOT(FLQuant, install(".Data"), v); > > UNPROTECT(10); > > return FLQuant; > } > > > > > > > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 1 > minor = 7.1 > year = 2003 > month = 06 > day = 16 > language = R > > Windows 2000 Professional (build 2195) Service Pack 3.0 > > Search Path: > .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, > package:nls, package:ts, Autoloads, package:base > > <> > > ------_=_NextPart_000_01C3738F.63DE3390 > Content-Type: application/octet-stream; > name="Laurence Kell (E-mail).vcf" > Content-Disposition: attachment; > filename="Laurence Kell (E-mail).vcf" > > BEGIN:VCARD > VERSION:2.1 > N:Kell;Laurence > FN:Laurence Kell (E-mail) > ORG:CEFAS > TEL;WORK;VOICE:+44 (0) 1502 524257 > TEL;WORK;FAX:+44 (0) 1502 524511 > ADR;WORK:;;Lowestoft Laboratory;Pakefield Road;Lowestoft,;NR33 0HT;UK > LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Lowestoft Laboratory=0D=0APakefield Road, Lowestoft, NR33 0HT=0D=0AUK > EMAIL;PREF;INTERNET:/o=CEFAS/ou=LOWESTOFT/cn=Recipients/cn=LTK00 > REV:20030410T130517Z > END:VCARD > > ------_=_NextPart_000_01C3738F.63DE3390-- > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel -- _______________________________________________________________ Duncan Temple Lang duncan@research.bell-labs.com Bell Labs, Lucent Technologies office: (908)582-3217 700 Mountain Avenue, Room 2C-259 fax: (908)582-3340 Murray Hill, NJ 07974-2070 http://cm.bell-labs.com/stat/duncan ==> 4073.audit <== Mon Nov 17 08:57:30 2003 ripley foobar Mon Nov 17 08:57:30 2003 ripley moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4474 * Subject: Memmory Bugs From: "Eric R. Riehl" Date: Wed, 8 Oct 2003 14:30:57 -0400 (EDT) --about use of enum for messages in errors.c ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4474 <== From eriehl@email.unc.edu Wed Oct 8 20:31:40 2003 Received: from smtp.unc.edu (listserv0.isis.unc.edu [152.2.0.38]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h98IVd0P021126 for ; Wed, 8 Oct 2003 20:31:40 +0200 (MET DST) Received: from testbox (testbox.oit.unc.edu [152.2.22.9]) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id h98IUvs4008998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 8 Oct 2003 14:30:58 -0400 (EDT) Date: Wed, 8 Oct 2003 14:30:57 -0400 (EDT) From: "Eric R. Riehl" X-X-Sender: eriehl@testbox To: r-bugs@biostat.ku.dk Subject: Memmory Bugs Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="43518230-584990211-1065637857=:31587" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --43518230-584990211-1065637857=:31587 Content-Type: TEXT/PLAIN; charset=US-ASCII I found (or rather the compiler I was using found) a few bugs in the R-1.7.1 sources. I'm not sure if they're fixed in the 1.8.0 sources or not. I've attached a diff file, where R-1.7.1a is the patches version. Eric Riehl --43518230-584990211-1065637857=:31587 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patches Content-Disposition: attachment; filename=patch U2VuZGVyOiBMU0YgU3lzdGVtIDxsc2ZhZG1pbkBiYW9iYWItbjMwLmlzaXMu dW5jLmVkdT4NClN1YmplY3Q6IEpvYiAxODMyNzogPGRpZmYgLXIgUi0xLjcu MS8gUi0xLjcuMWEvPiBFeGl0ZWQNCg0KSm9iIDxkaWZmIC1yIFItMS43LjEv IFItMS43LjFhLz4gd2FzIHN1Ym1pdHRlZCBmcm9tIGhvc3QgPGJhb2JhYi1u Ni5pc2lzLnVuYy5lZHU+IGJ5IHVzZXIgPGVyaWVobD4uDQpKb2Igd2FzIGV4 ZWN1dGVkIG9uIGhvc3QocykgPGJhb2JhYi1uMzAuaXNpcy51bmMuZWR1Piwg aW4gcXVldWUgPGJhdGNoPiwgYXMgdXNlciA8ZXJpZWhsPi4NCjwvYWZzL2lz aXMudW5jLmVkdS9ob21lL2Uvci9lcmllaGw+IHdhcyB1c2VkIGFzIHRoZSBo b21lIGRpcmVjdG9yeS4NCjwvYWZzL2lzaXMudW5jLmVkdS9wa2cvci0xNzEv LmJ1aWxkL3NyYz4gd2FzIHVzZWQgYXMgdGhlIHdvcmtpbmcgZGlyZWN0b3J5 Lg0KU3RhcnRlZCBhdCBXZWQgT2N0ICA4IDE0OjI0OjM0IDIwMDMNClJlc3Vs dHMgcmVwb3J0ZWQgYXQgV2VkIE9jdCAgOCAxNDoyNDo1OSAyMDAzDQoNCllv dXIgam9iIGxvb2tlZCBsaWtlOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgTFNC QVRDSDogVXNlciBpbnB1dA0KZGlmZiAtciBSLTEuNy4xLyBSLTEuNy4xYS8N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpFeGl0ZWQgd2l0aCBleGl0IGNvZGUgMS4N Cg0KUmVzb3VyY2UgdXNhZ2Ugc3VtbWFyeToNCg0KICAgIENQVSB0aW1lICAg OiAgICAgIDIuMTggc2VjLg0KICAgIE1heCBNZW1vcnkgOiAgICAgICAgIDEg TUINCiAgICBNYXggU3dhcCAgIDogICAgICAgICAzIE1CDQoNCiAgICBNYXgg UHJvY2Vzc2VzICA6ICAgICAgICAgMQ0KDQpUaGUgb3V0cHV0IChpZiBhbnkp IGZvbGxvd3M6DQoNCmRpZmYgLXIgUi0xLjcuMS9zcmMvbGlicmFyeS90Y2x0 ay9zcmMvdGNsdGsuYyBSLTEuNy4xYS9zcmMvbGlicmFyeS90Y2x0ay9zcmMv dGNsdGsuYw0KNjQ0YzY0NA0KPCAJc3RybmNweShidWYsIFRjbF9HZXRTdHJp bmdSZXN1bHQoUlRjbF9pbnRlcnApLCBsZW4pOw0KLS0tDQo+IAlzdHJuY3B5 KChjaGFyICopYnVmLCBUY2xfR2V0U3RyaW5nUmVzdWx0KFJUY2xfaW50ZXJw KSwgbGVuKTsNCmRpZmYgLXIgUi0xLjcuMS9zcmMvbWFpbi9kb3Rjb2RlLmMg Ui0xLjcuMWEvc3JjL21haW4vZG90Y29kZS5jDQoyNTFjMjUxDQo8IAkgICAg YnVmWzI1Nl0gPSAnXDAnOw0KLS0tDQo+IAkgICAgYnVmWzI1NV0gPSAnXDAn Ow0KZGlmZiAtciBSLTEuNy4xL3NyYy9tYWluL2Vycm9ycy5jIFItMS43LjFh L3NyYy9tYWluL2Vycm9ycy5jDQo1OThjNTk4DQo8ICAgICBjb25zdCBSX1dB Uk5JTkcgY29kZTsNCi0tLQ0KPiAgICAgY29uc3QgUl9FUlJPUiBjb2RlOw0K ZGlmZiAtciBSLTEuNy4xL3NyYy9tYWluL2dyYXBoaWNzLmMgUi0xLjcuMWEv c3JjL21haW4vZ3JhcGhpY3MuYw0KNTk1NSw1OTU2YzU5NTUsNTk1Ng0KPCAg ICAgUmZfZHBwdHIoZGQpLT5maW5bMl0gPSBSZl9kcFNhdmVkcHRyKGRkKS0+ ZmluWzJdOw0KPCAgICAgUmZfZHBwdHIoZGQpLT5maW5bM10gPSBSZl9kcFNh dmVkcHRyKGRkKS0+ZmluWzNdOw0KLS0tDQo+ICAgICAvKiAgICBSZl9kcHB0 cihkZCktPmZpblsyXSA9IFJmX2RwU2F2ZWRwdHIoZGQpLT5maW5bMl07ICov DQo+ICAgICAvKiAgICBSZl9kcHB0cihkZCktPmZpblszXSA9IFJmX2RwU2F2 ZWRwdHIoZGQpLT5maW5bM107ICovDQo2MDA5LDYwMTBjNjAwOSw2MDEwDQo8 ICAgICBSZl9kcHB0cihkZCktPnBpblsyXSA9IFJmX2RwU2F2ZWRwdHIoZGQp LT5waW5bMl07DQo8ICAgICBSZl9kcHB0cihkZCktPnBpblszXSA9IFJmX2Rw U2F2ZWRwdHIoZGQpLT5waW5bM107DQotLS0NCj4gICAgIC8qICAgIFJmX2Rw cHRyKGRkKS0+cGluWzJdID0gUmZfZHBTYXZlZHB0cihkZCktPnBpblsyXTsg Ki8NCj4gICAgIC8qICAgIFJmX2RwcHRyKGRkKS0+cGluWzNdID0gUmZfZHBT YXZlZHB0cihkZCktPnBpblszXTsgKi8NCmRpZmYgLXIgUi0xLjcuMS9zcmMv bWFpbi9tYWluLmMgUi0xLjcuMWEvc3JjL21haW4vbWFpbi5jDQoyNzljMjc5 DQo8ICAgICBzdGF0ZS5idWZbMTAyNV0gPSAnXDAnOyAvKiBzdG9wZ2FwIG1l YXN1cmUgaWYgbGluZSA+IDEwMjQgY2hhcnMgKi8NCi0tLQ0KPiAgICAgc3Rh dGUuYnVmWzEwMjRdID0gJ1wwJzsgLyogc3RvcGdhcCBtZWFzdXJlIGlmIGxp bmUgPiAxMDI0IGNoYXJzICovDQpkaWZmIC1yIFItMS43LjEvc3JjL3VuaXgv c3lzLWNvbW1vbi5jIFItMS43LjFhL3NyYy91bml4L3N5cy1jb21tb24uYw0K Njg2YzY4Ng0KPCAJc21bQlVGX1NJWkVdID0gJ1wwJzsNCi0tLQ0KPiAJc21b QlVGX1NJWkUtMV0gPSAnXDAnOw0KT25seSBpbiBSLTEuNy4xYS9zcmMvdW5p eDogc3lzLWNvbW1vbi5jfg0K --43518230-584990211-1065637857=:31587-- ==> 4474.reply.1 <== From p.dalgaard@biostat.ku.dk Wed Oct 8 22:08:06 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h98K860P021575; Wed, 8 Oct 2003 22:08:06 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h98K9vxl031317; Wed, 8 Oct 2003 22:09:57 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h98K9vfb031313; Wed, 8 Oct 2003 22:09:57 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: eriehl@email.unc.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Memmory Bugs (PR#4474) References: <200310081831.h98IVf0P021130@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 08 Oct 2003 22:09:57 +0200 In-Reply-To: <200310081831.h98IVf0P021130@pubhealth.ku.dk> Message-ID: Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii eriehl@email.unc.edu writes: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > Send mail to mime@docserver.cac.washington.edu for more info. > > --43518230-584990211-1065637857=:31587 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > I found (or rather the compiler I was using found) a few bugs in the > R-1.7.1 sources. I'm not sure if they're fixed in the 1.8.0 sources > or not. > > I've attached a diff file, where R-1.7.1a is the patches version. > > Eric Riehl > > --43518230-584990211-1065637857=:31587 > Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch > Content-Transfer-Encoding: BASE64 > Content-ID: > Content-Description: patches > Content-Disposition: attachment; filename=patch > > U2VuZGVyOiBMU0YgU3lzdGVtIDxsc2ZhZG1pbkBiYW9iYWItbjMwLmlzaXMu > dW5jLmVkdT4NClN1YmplY3Q6IEpvYiAxODMyNzogPGRpZmYgLXIgUi0xLjcu > MS8gUi0xLjcuMWEvPiBFeGl0ZWQNCg0KSm9iIDxkaWZmIC1yIFItMS43LjEv Please don't use attached files in r-bugs; they become quite a pain to decipher. Most of the things you report have already been fixed in 1.8.0, except diff -r R-1.7.1/src/main/errors.c R-1.7.1a/src/main/errors.c 598c598 < const R_WARNING code; --- > const R_ERROR code; (This is now in line 750 -- a context diff would have been welcome). The problem there is that we have 749 static struct { 750 const R_WARNING code; 751 const char* const format; 752 } 753 const ErrorDB[] = { 754 { ERROR_NUMARGS, "invalid number of arguments" }, 755 { ERROR_ARGTYPE, "invalid argument type" }, and the ERROR_* values are not in the R_WARNING enum type. Formally, that is a bug, but I suspect that we generate the correct code anyway.... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 4474.audit <== Mon Nov 17 08:55:35 2003 ripley changed notes Mon Nov 17 08:55:35 2003 ripley foobar Mon Nov 17 08:55:35 2003 ripley moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6617 * Subject: Regular expressions & large strings From: Mark White Date: Fri, 27 Feb 2004 11:27:18 +0000 --Works on my (TSL) OS X and Linux machines --Incorrect result confirmed on RH8.0 and segfault on Windows (BDR) --The segfault is under a call to regexec: PCRE is not used. --If perl=TRUE is included, this works, fast. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6617 <== From mjw@celos.net Fri Feb 27 12:18:46 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id D00C51042D for ; Fri, 27 Feb 2004 12:18:45 +0100 (CET) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13845-03 for ; Fri, 27 Feb 2004 12:18:45 +0100 (CET) Received: from smtp-out7.blueyonder.co.uk (smtp-out7.blueyonder.co.uk [195.188.213.10]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 27 Feb 2004 12:18:40 +0100 (CET) Received: from mirkwood.celos.net ([82.43.152.229]) by smtp-out7.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Fri, 27 Feb 2004 11:18:39 +0000 Received: from mark by mirkwood.celos.net with local (Exim 3.32 #1) id 1Awg9G-0000m3-00 for r-bugs@biostat.ku.dk; Fri, 27 Feb 2004 11:27:18 +0000 Date: Fri, 27 Feb 2004 11:27:18 +0000 From: Mark White To: r-bugs@biostat.ku.dk Subject: Regular expressions & large strings Message-ID: <20040227112718.GB2748@celos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 27 Feb 2004 11:18:39.0560 (UTC) FILETIME=[733D8480:01C3FD23] X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-7.5 required=5.0 tests=BAYES_10,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) A possible regex bug when working with large strings. The following code snippet t5 <- paste( c( "# === TEST", rep(' ', 2452294) ), collapse='') str( sub("^.*TEST", "xyz", t5) ) str( sub("^.*TEST", "xyz", substr(t5,0,200)) ) doesn't behave right; on one machine, the second and third lines print different results [the second line, on the long string, doesn't do the substitution], while on another, the second line causes a segfault. Both are running R 1.8.1 with PCRE, under NetBSD (1.6.1 and 1.6 respectively). Possible related (although perhaps not a bug): function(n) { line <- paste(as.character(trunc(runif(n)*100)),collapse=" ") system.time( rep <- gsub("[[:space:]]", "-", line) ) } gives rather long times rising v sharply for big strings (eg 2.2s at n=2e4, 360s at n=2e5 on AMD 1.2GHz). Other languages aren't so slow on this task (eg n=2e5: 0.4s ruby 1.8.1, and 5.2s python 2). Doubtless my extremely-quick-hack benchmarks aren't fair, but the difference still seems rather big. Mark <>< ==> 6617.audit <== Sat Feb 28 01:33:44 2004 thomas changed notes Sat Feb 28 01:33:44 2004 thomas moved from incoming to Low-level Sat Feb 28 11:32:58 2004 ripley changed notes ==> 6617.followup.1 <== From ripley@stats.ox.ac.uk Sat Feb 28 12:31:15 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5D52EEFCF for ; Sat, 28 Feb 2004 12:31:15 +0100 (CET) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20768-01 for ; Sat, 28 Feb 2004 12:31:14 +0100 (CET) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 28 Feb 2004 12:31:14 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i1SBVDrt003051; Sat, 28 Feb 2004 11:31:13 GMT Date: Sat, 28 Feb 2004 11:31:13 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: mjw@celos.net Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Regular expressions & large strings (PR#6617) In-Reply-To: <20040227111915.018731042E@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I was able to confirm the error on RH8.0 Linux and the segfault on Windows. Note that PCRE is not being used, and if you add perl=TRUE to your [g]sub calls you get correct results extremely fast. The segfault is occurring in regexec, that is in the GNU regex code included in R. I am not clear it is worth spending any time on trying to find the problem in that code as - you can use perl=TRUE as an alternative - we will be replacing the GNU regex code in due course to cope with internationalization issues. On Fri, 27 Feb 2004 mjw@celos.net wrote: > A possible regex bug when working with large strings. The > following code snippet > > t5 <- paste( c( "# === TEST", rep(' ', 2452294) ), collapse='') > str( sub("^.*TEST", "xyz", t5) ) > str( sub("^.*TEST", "xyz", substr(t5,0,200)) ) > > doesn't behave right; on one machine, the second and third > lines print different results [the second line, on the long > string, doesn't do the substitution], while on another, the > second line causes a segfault. Both are running R 1.8.1 > with PCRE, under NetBSD (1.6.1 and 1.6 respectively). > > Possible related (although perhaps not a bug): > > function(n) { > line <- paste(as.character(trunc(runif(n)*100)),collapse=" ") > system.time( rep <- gsub("[[:space:]]", "-", line) ) > } > > gives rather long times rising v sharply for big strings (eg > 2.2s at n=2e4, 360s at n=2e5 on AMD 1.2GHz). Other languages > aren't so slow on this task (eg n=2e5: 0.4s ruby 1.8.1, and > 5.2s python 2). Doubtless my extremely-quick-hack benchmarks > aren't fair, but the difference still seems rather big. > > Mark <>< > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6617.followup.2 <== From mjw@celos.net Sat Feb 28 16:05:36 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id B7F90EDF2 for ; Sat, 28 Feb 2004 16:05:35 +0100 (CET) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21505-05 for ; Sat, 28 Feb 2004 16:05:35 +0100 (CET) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 28 Feb 2004 16:05:35 +0100 (CET) Received: from mirkwood.celos.net ([82.43.153.138]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Feb 2004 15:05:34 +0000 Received: from mark by mirkwood.celos.net with local (Exim 3.32 #1) id 1Ax6AU-0000C1-00; Sat, 28 Feb 2004 15:14:18 +0000 Date: Sat, 28 Feb 2004 15:14:18 +0000 From: Mark White To: Prof Brian Ripley Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Regular expressions & large strings (PR#6617) Message-ID: <20040228151418.GA341@celos.net> References: <20040227111915.018731042E@slim.kubism.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 28 Feb 2004 15:05:34.0837 (UTC) FILETIME=[50FDAA50:01C3FE0C] X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Prof Brian Ripley writes: > I was able to confirm the error on RH8.0 Linux and the segfault on > Windows. > > Note that PCRE is not being used, and if you add perl=TRUE to your [g]sub > calls you get correct results extremely fast. Thanks for clarifying that; I hadn't realised. > The segfault is occurring in regexec, that is in the GNU regex code > included in R. I am not clear it is worth spending any time on trying to > find the problem in that code as > > - you can use perl=TRUE as an alternative > - we will be replacing the GNU regex code in due course to cope with > internationalization issues. Sounds fine. Do you think either of the following are worth doing in the meantime? - Add an strsplit() variant with PCRE (perhaps this problem is be related to PR#6601; and the speed might be nice anyway). - Add options(pcre) so the potentially bad code can be avoided without explicitly setting perl=TRUE every time. Mark <>< ==> 6617.followup.3 <== From ripley@stats.ox.ac.uk Sat Feb 28 16:16:16 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id C29FEEDE2 for ; Sat, 28 Feb 2004 16:16:16 +0100 (CET) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21559-04 for ; Sat, 28 Feb 2004 16:16:16 +0100 (CET) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 28 Feb 2004 16:16:15 +0100 (CET) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i1SFGFrt003254; Sat, 28 Feb 2004 15:16:15 GMT Date: Sat, 28 Feb 2004 15:16:15 +0000 (GMT) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: Mark White Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Regular expressions & large strings (PR#6617) In-Reply-To: <20040228151418.GA341@celos.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Sat, 28 Feb 2004, Mark White wrote: > Prof Brian Ripley writes: > > I was able to confirm the error on RH8.0 Linux and the segfault on > > Windows. > > > > Note that PCRE is not being used, and if you add perl=TRUE to your [g]sub > > calls you get correct results extremely fast. > > Thanks for clarifying that; I hadn't realised. > > > The segfault is occurring in regexec, that is in the GNU regex code > > included in R. I am not clear it is worth spending any time on trying to > > find the problem in that code as > > > > - you can use perl=TRUE as an alternative > > - we will be replacing the GNU regex code in due course to cope with > > internationalization issues. > > Sounds fine. Do you think either of the following are worth > doing in the meantime? > > - Add an strsplit() variant with PCRE (perhaps this > problem is be related to PR#6601; and the speed might be > nice anyway). Worth considering, as least. > - Add options(pcre) so the potentially bad code can be > avoided without explicitly setting perl=TRUE every time. No, as unfortunately the definitions are slightly different and there are a lot of usages of the POSIX regexps in the base R code (and elsewhere). I would expect that usages with more than 10000 chars in one string were rare, and indeed were not supported for most of R's life. This is yet another one of those issues where the very limited development resources come into play. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7022 * Subject: Bug in parse(text = ) From: Martin Maechler Date: Fri, 25 Jun 2004 09:19:32 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7022 <== From mail@stat.math.ethz.ch Fri Jun 25 09:19:35 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 12400F6DA for ; Fri, 25 Jun 2004 09:19:35 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23478-06 for ; Fri, 25 Jun 2004 09:19:34 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 25 Jun 2004 09:19:34 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5P7JXkT008923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jun 2004 09:19:33 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i5P7JXRB008921 for R-bugs@biostat.ku.dk; Fri, 25 Jun 2004 09:19:33 +0200 Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5P7JWoW008899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jun 2004 09:19:32 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.11/8.12.8/Submit) id i5P7JWi3030910; Fri, 25 Jun 2004 09:19:32 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16603.53764.370556.629598@gargle.gargle.HOWL> Date: Fri, 25 Jun 2004 09:19:32 +0200 To: R-bugs@stat.math.ethz.ch Cc: Jean Coursol Subject: Bug in parse(text = ) In-Reply-To: <200406241322.PAA09735@jacaranda.math.u-psud.fr> References: <200406241322.PAA09735@jacaranda.math.u-psud.fr> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: Martin Maechler Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of maechler@stat.math.ethz.ch does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Merci beaucoup, Jean, for the bug report -- which I'm no "completeing" to R-bugs >>>>> "Jean" == Jean Coursol >>>>> on Thu, 24 Jun 2004 15:22:37 +0200 (CEST) writes: Jean> I was exploring the polynom library with students: The following is reproducible also with the current version of R 1.9.1 [on RHEL Linux] horner <- function(p) { a <- as.character(rev(unclass(p))) h <- a[1] while (length(a <- a[-1]) > 0) { h <- paste("x*(", h, ")", sep = "") if (a[1] != 0) h <- paste(a[1], " + ", h, sep = "") } h } library(polynom) x <- polynomial() z <- (1+x)^100 zh <- horner(z) nchar(zh) ## [1] 2404 parse(text = zh) # => Segmentation fault ## where Jean wrote '(it ran one time !!!)' ## and it happens the first time for me. ==> 7022.reply.1 <== From p.dalgaard@biostat.ku.dk Fri Jun 25 09:33:21 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id A10DACB5B; Fri, 25 Jun 2004 09:33:21 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i5P7WnYg005000; Fri, 25 Jun 2004 09:32:49 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i5P7WnHB004996; Fri, 25 Jun 2004 09:32:49 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: maechler@stat.math.ethz.ch Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Bug in parse(text = ) (PR#7022) References: <20040625071940.9096610871@slim.kubism.ku.dk> From: Peter Dalgaard Date: 25 Jun 2004 09:32:48 +0200 In-Reply-To: <20040625071940.9096610871@slim.kubism.ku.dk> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) maechler@stat.math.ethz.ch writes: > Merci beaucoup, Jean, > for the bug report -- which I'm no "completeing" to R-bugs But you're still requiring library(polynom) for triggering the bug. If we are to be sure that it is not a bug in that package but a bug in R, you need to include the definition of at least polynomial() with the instructions to reproduce the effect... [snip] > library(polynom) > > x <- polynomial() > z <- (1+x)^100 > zh <- horner(z) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 7022.followup.1 <== From ripley@stats.ox.ac.uk Fri Jun 25 10:09:13 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 4AC2BEAD6; Fri, 25 Jun 2004 10:09:13 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23767-06; Fri, 25 Jun 2004 10:09:12 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP id A2BAC1832; Fri, 25 Jun 2004 10:09:12 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i5P89Brt021334; Fri, 25 Jun 2004 09:09:11 +0100 (BST) Date: Fri, 25 Jun 2004 09:09:11 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: Peter Dalgaard Cc: maechler@stat.math.ethz.ch, , Subject: Re: [Rd] Bug in parse(text = ) (PR#7022) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On 25 Jun 2004, Peter Dalgaard wrote: > maechler@stat.math.ethz.ch writes: > > > Merci beaucoup, Jean, > > for the bug report -- which I'm no "completeing" to R-bugs > > But you're still requiring library(polynom) for triggering the bug. If > we are to be sure that it is not a bug in that package There seems to be in that it is not using the R code from `S Programming' p.95, according to the original report. > but a bug in R, > you need to include the definition of at least polynomial() with the > instructions to reproduce the effect... > > [snip] > > library(polynom) > > > > x <- polynomial() > > z <- (1+x)^100 > > zh <- horner(z) Hmm, horner is not in the package! It is a function internal to as.function.polynomial. as.function(z) segfaults at #0 R_TextBufferGetc (txtb=0xffda00) at /users/ripley/R/cvs/R-devel/src/main/iosupport.c:232 #1 0x080c7623 in text_getc () at ./gram.y:1011 #2 0x080c6eed in xxgetc () at ./gram.y:291 #3 0x080c7bc5 in token () at ./gram.y:1496 #4 0x080c85c5 in Rf_yylex () at ./gram.y:1894 #5 0x080c8bef in Rf_yyparse () at /usr/share/bison/bison.simple:573 #6 0x080c997e in R_Parse1 (status=0xbfffda58) at ./gram.y:941 #7 0x080c9aad in R_Parse (n=-1, status=0xbfffda58) at ./gram.y:1076 #8 0x080c9c1e in R_ParseVector (text=0xffffffff, n=-1, status=0xffffffff) at ./gram.y:1153 #9 0x0813c3d9 in do_parse (call=0x8500c00, op=0xffffffff, args=0x84fb898, env=0x8ed385c) at /users/ripley/R/cvs/R-devel/src/main/source.c:68 so that's definitely a bug in R. It is being asked to parse a very long line and a highly-nested expression. I suspect the latter is the problem. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 7022.reply.2 <== From maechler@stat.math.ethz.ch Fri Jun 25 10:19:21 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5A9A110871; Fri, 25 Jun 2004 10:19:21 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23919-05; Fri, 25 Jun 2004 10:19:20 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP id 083AC1832; Fri, 25 Jun 2004 10:19:20 +0200 (CEST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5P8JKvJ021524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jun 2004 10:19:20 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.11/8.12.8/Submit) id i5P8JK8o001910; Fri, 25 Jun 2004 10:19:20 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <16603.57351.582179.466625@gargle.gargle.HOWL> Date: Fri, 25 Jun 2004 10:19:19 +0200 To: Peter Dalgaard Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Bug in parse(text = ) (PR#7022) In-Reply-To: References: <20040625071940.9096610871@slim.kubism.ku.dk> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: Martin Maechler Received-SPF: none (hypatia: domain of maechler@stat.math.ethz.ch does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-3.3 required=5.0 tests=BASE64_ENC_TEXT,BAYES_10,IN_REP_TO,RCVD_IN_ORBS,REFERENCES, USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Pj4+Pj4gIlBEIiA9PSBQZXRlciBEYWxnYWFyZCA8cC5kYWxnYWFyZEBiaW9zdGF0Lmt1LmRrPg0K Pj4+Pj4gICAgIG9uIDI1IEp1biAyMDA0IDA5OjMyOjQ4ICswMjAwIHdyaXRlczoNCg0KICAgIFBE PiBtYWVjaGxlckBzdGF0Lm1hdGguZXRoei5jaCB3cml0ZXM6DQogICAgPj4gTWVyY2kgYmVhdWNv dXAsIEplYW4sIGZvciB0aGUgYnVnIHJlcG9ydCAtLSB3aGljaCBJJ20gbm8NCiAgICA+PiAiY29t cGxldGVpbmciIHRvIFItYnVncw0KDQogICAgUEQ+IEJ1dCB5b3UncmUgc3RpbGwgcmVxdWlyaW5n IGxpYnJhcnkocG9seW5vbSkgZm9yDQogICAgUEQ+IHRyaWdnZXJpbmcgdGhlIGJ1Zy4gSWYgd2Ug YXJlIHRvIGJlIHN1cmUgdGhhdCBpdCBpcyBub3QNCiAgICBQRD4gYSBidWcgaW4gdGhhdCBwYWNr YWdlIGJ1dCBhIGJ1ZyBpbiBSLCB5b3UgbmVlZCB0bw0KICAgIFBEPiBpbmNsdWRlIHRoZSBkZWZp bml0aW9uIG9mIGF0IGxlYXN0IHBvbHlub21pYWwoKSB3aXRoIHRoZQ0KICAgIFBEPiBpbnN0cnVj dGlvbnMgdG8gcmVwcm9kdWNlIHRoZSBlZmZlY3QuLi4NCg0Kd2VsbCwgdHJ5IHRoaXMgKHdpdGhv dXQgcGFja2FnZSBwb2x5bm9tKToNCg0KPiBwYXJzZSh0ZXh0PSIxICsgeCooMTAwICsgeCooNDk1 MCArIHgqKDE2MTcwMCArIHgqKDM5MjEyMjUgKyB4Kig3NTI4NzUyMCArIHgqKDExOTIwNTI0MDAg KyB4KigxNjAwNzU2MDgwMCArIHgqKDE4NjA4Nzg5NDMwMCArIHgqKDE5MDIyMzE4MDg0MDAgKyB4 KigxNzMxMDMwOTQ1NjQ0MCArIHgqKDE0MTYyOTgwNDY0MzYwMCArIHgqKDEwNTA0MjEwNTExMDY3 MDAgKyB4Kig3MTEwNTQyNDk5Nzk5MjAwICsgeCooNDQxODY5NDI2NzczMjM2MDggKyB4KigyNTMz Mzg0NzEzNDk5ODg2NzIgKyB4KigxMzQ1ODYwNjI5MDQ2ODE0NzIwICsgeCooNjY1MDEzNDg3Mjkz NzIwMTY2NCArIHgqKDMwNjY0NTEwODAyOTg4MjA4MTI4ICsgeCooMS4zMjM0MTU3MjkzOTIxMmUr MjAgKyB4Kig1LjM1OTgzMzcwNDAzODFlKzIwICsgeCooMi4wNDE4NDE0MTEwNjIxM2UrMjEgKyB4 Kig3LjMzMjA2Njg4NTE3NzY1ZSsyMSArIHgqKDIuNDg2NTI3MDMwNjI1NDdlKzIyICsgeCooNy45 Nzc2MDc1NTY1OTAwNGUrMjIgKyB4KigyLjQyNTE5MjY5NzIwMzM3ZSsyMyArIHgqKDYuOTk1NzQ4 MTY1MDA5NzJlKzIzICsgeCooMS45MTczNTMyMDA3ODA0NGUrMjQgKyB4Kig0Ljk5ODgxMzcwMjAz NDczZSsyNCArIHgqKDEuMjQxMDg0NzgxMTk0ODNlKzI1ICsgeCooMi45MzcyMzM5ODIxNjEwOWUr MjUgKyB4Kig2LjYzMjQ2MzgzMDY4NjM0ZSsyNSArIHgqKDEuNDMwMTI1MDEzNDkxNzRlKzI2ICsg eCooMi45NDY5MjQyNzAyMjU0MWUrMjYgKyB4Kig1LjgwNzE3NDI5NzIwODllKzI2ICsgeCooMS4w OTUwNjcxNTMxODc5NmUrMjcgKyB4KigxLjk3NzIwNDU4MjE0NDkzZSsyNyArIHgqKDMuNDIwMDI5 NTQ3NDkzOTRlKzI3ICsgeCooNS42NzAwNDg5ODY2MzQ2OWUrMjcgKyB4Kig5LjAxMzkyNDAzMDAz NDYzZSsyNyArIHgqKDEuMzc0NjIzNDE0NTgwMjhlKzI4ICsgeCooMi4wMTE2NDQwMjEzMzcwMGUr MjggKyB4KigyLjgyNTg4MDg4NzExNjI2ZSsyOCArIHgqKDMuODExNjUzMjg5NTk4NjdlKzI4ICsg eCooNC45Mzc4MjM1Nzk3MDczN2UrMjggKyB4Kig2LjE0NDg0NzEyMTQxMzYyZSsyOCArIHgqKDcu MzQ3MDk5ODE5MDgxNWUrMjggKyB4Kig4LjQ0MTM0ODcyODMwNjRlKzI4ICsgeCooOS4zMjA2NTU4 ODc1MDVlKzI4ICsgeCooOS44OTEzMDgyODg3ODA4ZSsyOCArIHgqKDEuMDA4OTEzNDQ1NDU1NjRl KzI5ICsgeCooOS44OTEzMDgyODg3ODA4ZSsyOCArIHgqKDkuMzIwNjU1ODg3NTA1ZSsyOCArIHgq KDguNDQxMzQ4NzI4MzA2NGUrMjggKyB4Kig3LjM0NzA5OTgxOTA4MTVlKzI4ICsgeCooNi4xNDQ4 NDcxMjE0MTM2MmUrMjggKyB4Kig0LjkzNzgyMzU3OTcwNzM3ZSsyOCArIHgqKDMuODExNjUzMjg5 NTk4NjdlKzI4ICsgeCooMi44MjU4ODA4ODcxMTYyNmUrMjggKyB4KigyLjAxMTY0NDAyMTMzNzAw ZSsyOCArIHgqKDEuMzc0NjIzNDE0NTgwMjhlKzI4ICsgeCooOS4wMTM5MjQwMzAwMzQ2M2UrMjcg KyB4Kig1LjY3MDA0ODk4NjYzNDY5ZSsyNyArIHgqKDMuNDIwMDI5NTQ3NDkzOTRlKzI3ICsgeCoo MS45NzcyMDQ1ODIxNDQ5M2UrMjcgKyB4KigxLjA5NTA2NzE1MzE4Nzk2ZSsyNyArIHgqKDUuODA3 MTc0Mjk3MjA4OWUrMjYgKyB4KigyLjk0NjkyNDI3MDIyNTQxZSsyNiArIHgqKDEuNDMwMTI1MDEz NDkxNzRlKzI2ICsgeCooNi42MzI0NjM4MzA2ODYzNGUrMjUgKyB4KigyLjkzNzIzMzk4MjE2MTA5 ZSsyNSArIHgqKDEuMjQxMDg0NzgxMTk0ODNlKzI1ICsgeCooNC45OTg4MTM3MDIwMzQ3M2UrMjQg KyB4KigxLjkxNzM1MzIwMDc4MDQ0ZSsyNCArIHgqKDYuOTk1NzQ4MTY1MDA5NzJlKzIzICsgeCoo Mi40MjUxOTI2OTcyMDMzN2UrMjMgKyB4Kig3Ljk3NzYwNzU1NjU5MDA0ZSsyMiArIHgqKDIuNDg2 NTI3MDMwNjI1NDdlKzIyICsgeCooNy4zMzIwNjY4ODUxNzc2NWUrMjEgKyB4KigyLjA0MTg0MTQx MTA2MjEzZSsyMSArIHgqKDUuMzU5ODMzNzA0MDM4MWUrMjAgKyB4KigxLjMyMzQxNTcyOTM5MjEy ZSsyMCArIHgqKDMwNjY0NTEwODAyOTg4MjA4MTI4ICsgeCooNjY1MDEzNDg3MjkzNzIwMTY2NCAr IHgqKDEzNDU4NjA2MjkwNDY4MTQ3MjAgKyB4KigyNTMzMzg0NzEzNDk5ODg2NzIgKyB4Kig0NDE4 Njk0MjY3NzMyMzYwOCArIHgqKDcxMTA1NDI0OTk3OTkyMDAgKyB4KigxMDUwNDIxMDUxMTA2NzAw ICsgeCooMTQxNjI5ODA0NjQzNjAwICsgeCooMTczMTAzMDk0NTY0NDAgKyB4KigxOTAyMjMxODA4 NDAwICsgeCooMTg2MDg3ODk0MzAwICsgeCooMTYwMDc1NjA4MDAgKyB4KigxMTkyMDUyNDAwICsg eCooNzUyODc1MjAgKyB4KigzOTIxMjI1ICsgeCooMTYxNzAwICsgeCooNDk1MCArIHgqKDEwMCAr IHgqKDEpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkp KSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpIik= ==> 7022.reply.3 <== From maechler@stat.math.ethz.ch Fri Jun 25 10:42:09 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 59F59108C4 for ; Fri, 25 Jun 2004 10:42:09 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24028-10 for ; Fri, 25 Jun 2004 10:42:08 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 25 Jun 2004 10:42:08 +0200 (CEST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i5P8g8r9026080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jun 2004 10:42:08 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.11/8.12.8/Submit) id i5P8g7wY002055; Fri, 25 Jun 2004 10:42:07 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16603.58719.605636.507715@gargle.gargle.HOWL> Date: Fri, 25 Jun 2004 10:42:07 +0200 To: R-bugs@biostat.ku.dk Subject: Re: [Rd] Bug in parse(text = ) (PR#7022) In-Reply-To: <16603.57351.582179.466625@gargle.gargle.HOWL> References: <20040625071940.9096610871@slim.kubism.ku.dk> <16603.57351.582179.466625@gargle.gargle.HOWL> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: Martin Maechler Received-SPF: none (hypatia: domain of maechler@stat.math.ethz.ch does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >>>>> "MM" == Martin Maechler >>>>> on Fri, 25 Jun 2004 10:19:19 +0200 writes: >>>>> "PD" == Peter Dalgaard >>>>> on 25 Jun 2004 09:32:48 +0200 writes: PD> But you're still requiring library(polynom) for PD> triggering the bug. If we are to be sure that it is not PD> a bug in that package but a bug in R, you need to PD> include the definition of at least polynomial() with the PD> instructions to reproduce the effect... MM> well, try this (without package polynom): >> parse(text="1 + x*(100 + x*(4950 + x*(161700 + x*(3921225 .... and then I had the full length 2404 string which---I had "known in advance" (Murphy's law)--- has been thrown up before it got back to R-devel, actually by my mailer already. Now this should be easier to pass through: tt <- tempfile() download.file("ftp://ftp.stat.math.ethz.ch/U/maechler/R/longpoly.rda", tt) load(tt) zh # look at the long "polygon string" parse(text=zh) ## seg.fault -- Martin ==> 7022.audit <== Sat Jun 26 09:08:14 2004 ripley moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7027 * Subject: Problem with hasArg and the ... argument From: j.j.goeman@lumc.nl Date: Mon, 28 Jun 2004 11:12:27 +0200 (CEST) --Problem is if sys.function() should be changed or its docs. See further --discussion on R-devel. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7027 <== From j.j.goeman@lumc.nl Mon Jun 28 11:12:27 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 02FC5EAC6 for ; Mon, 28 Jun 2004 11:12:27 +0200 (CEST) From: j.j.goeman@lumc.nl To: R-bugs@biostat.ku.dk Subject: Problem with hasArg and the ... argument Message-Id: <20040628091227.02FC5EAC6@slim.kubism.ku.dk> Date: Mon, 28 Jun 2004 11:12:27 +0200 (CEST) X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Jelle Goeman Version: 1.9.0 OS: mingw32, windows 2000 Submission from: (NULL) (145.88.209.33) Hi Everyone, I get very strange results using the function hasArg with the ... function argument. In my own function: > gt <- globaltest(X,Y) > sampling(gt) works fine, but > sampling(globaltest(X,Y)) results in: Error in eval(expr, envir, enclos) : "missing" illegal use of missing I've tracked down the problem. Define the simple function: xory <- function(x, ...) if (hasArg(y)) y else x then x <- 1:10 xx <- xory(x) plot(x, xx) works fine, but plot(x, xory(x)) gives the same error. The problem is that the plot function also has an argument y, which somehow interferes with the hasArg function. Is there an alternative to hasArg that really checks if an argument y was supplied for the xy function itself? Jelle ==> 7027.followup.1 <== From dmurdoch@pair.com Mon Jun 28 13:41:03 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 4B8E4EAD6 for ; Mon, 28 Jun 2004 13:41:03 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13674-02 for ; Mon, 28 Jun 2004 13:41:02 +0200 (CEST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by slam.kubism.ku.dk (Postfix) with SMTP for ; Mon, 28 Jun 2004 13:41:01 +0200 (CEST) Received: (qmail 3860 invoked from network); 28 Jun 2004 11:41:00 -0000 Received: from xi.pair.com (HELO localhost) (209.68.1.25) by relay.pair.com with SMTP; 28 Jun 2004 11:41:00 -0000 X-pair-Authenticated: 209.68.1.25 From: Duncan Murdoch To: j.j.goeman@lumc.nl Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Problem with hasArg and the ... argument (PR#7027) Date: Mon, 28 Jun 2004 07:40:58 -0400 Message-ID: References: <20040628091228.B04B8EAD6@slim.kubism.ku.dk> In-Reply-To: <20040628091228.B04B8EAD6@slim.kubism.ku.dk> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_FORTE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Mon, 28 Jun 2004 11:12:28 +0200 (CEST), j.j.goeman@lumc.nl wrote: >Full_Name: Jelle Goeman >Version: 1.9.0 >OS: mingw32, windows 2000 >Submission from: (NULL) (145.88.209.33) >I've tracked down the problem. Define the simple function: > >xory <- function(x, ...) if (hasArg(y)) y else x > >then > >x <- 1:10 >xx <- xory(x) >plot(x, xx) > >works fine, but > >plot(x, xory(x)) > >gives the same error. The problem is that the plot function also has an argument >y, which somehow interferes with the hasArg function. Is there an alternative to >hasArg that really checks if an argument y was supplied for the xy function >itself? This is still present in 1.9.1 and r-patched (on Windows). It appears to be a bug in or misuse of sys.function: within hasArg, sys.function(0) returns hasArg as expected, but sys.function(1) returns plot. xory() seems to get lost. Duncan Murdoch ==> 7027.reply.1 <== From p.dalgaard@biostat.ku.dk Mon Jun 28 13:52:55 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5DCF8EFBE; Mon, 28 Jun 2004 13:52:55 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i5SBq7Yg030624; Mon, 28 Jun 2004 13:52:09 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i5SBq6Im030620; Mon, 28 Jun 2004 13:52:06 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: j.j.goeman@lumc.nl Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Problem with hasArg and the ... argument (PR#7027) References: <20040628091228.B04B8EAD6@slim.kubism.ku.dk> From: Peter Dalgaard Date: 28 Jun 2004 13:52:05 +0200 In-Reply-To: <20040628091228.B04B8EAD6@slim.kubism.ku.dk> Message-ID: Lines: 76 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) j.j.goeman@lumc.nl writes: > xory <- function(x, ...) if (hasArg(y)) y else x > > then > > x <- 1:10 > xx <- xory(x) > plot(x, xx) > > works fine, but > > plot(x, xory(x)) > > gives the same error. The problem is that the plot function also has > an argument y, which somehow interferes with the hasArg function. Is > there an alternative to hasArg that really checks if an argument y > was supplied for the xy function itself? No, but hasArg has issues: fnames <- names(formals(sys.function(1))) is getting the names of plot() rather than xory(). I almost thought I had caught the Mighty John blundering there, but this actually looks more like sys.function is not behaving as documented and counts frames in the wrong direction. Checking... Yep, the logic in R_sysfunction() is to give the function of frame #n: if (n > 0) n = framedepth(cptr) - n; else n = - n; if (n < 0 ) errorcall(R_GlobalContext->call, "illegal frame number"); while (cptr->nextcontext != NULL) { if (cptr->callflag & CTXT_FUNCTION ) { if (n == 0) return duplicate(cptr->callfun); /***** do we need to DUP? */ else n--; } cptr = cptr->nextcontext; } whereas the documentation has 'sys.function' gives the definition of the function currently being evaluated in the frame 'n' generations back. However, we're using the current convention in quite a few places (sys.function(sys.parent())) and, worse, who know what packages might do. It is tempting just to change the documentation, but it is part of a grouped documentation of sys.whatever, which has which: the frame number if non-negative, the number of generations to go back if negative. (See the Details section.) n: the number of frame generations to go back. and sys.function is documented with argument 'n', which we'd have to change to 'which', but the default is n=0 for "current function" which is unlike 'which' which has 0 meaning .GlobalEnv. Argh... My take is that we need to fix sys.function to behave according to docs, change what we can in the R internals, and face the consequences for package maintainers. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 7027.audit <== Thu Jul 1 09:33:50 2004 ripley changed notes Thu Jul 1 09:33:50 2004 ripley moved from incoming to Low-level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Macintosh * PR# 6903 * Subject: Memory Leak in OS X versions? From: dvanbrunt@well-wired.com Date: Fri, 21 May 2004 15:24:05 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6903 <== From dvanbrunt@well-wired.com Fri May 21 15:24:11 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id D76CA1058D for ; Fri, 21 May 2004 15:24:05 +0200 (CEST) From: dvanbrunt@well-wired.com To: R-bugs@biostat.ku.dk Subject: Memory Leak in OS X versions? Message-Id: <20040521132405.D76CA1058D@slim.kubism.ku.dk> Date: Fri, 21 May 2004 15:24:05 +0200 (CEST) X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_20,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: David L. Van Brunt Version: 1.8-1.9 beta OS: OS X 10.3 Submission from: (NULL) (68.74.58.109) As posted on R-Help (after which another user replicated the problem): --------------- This is the conclusion from a prior thread ([R] " cannot allocate vector of length 1072693248") which ended with no other answer but that there must be a problem in the OS X version of R, or in the compile of the source on OS X. I’ve posted code and data here: http://www.well-wired.com/reflibrary/uploads/1084503247.zip If you setwd() into the directory that is made, then “source()” the “.R” file, it should run fine on Windows but crash on any machine with OS X (Panther) giving: “Error in as.vector(data) : cannot allocate vector of length 1073741824” after a few iterations of the loop. I've repeated this on a Powerbook G4 with 500 MB of RAM, an iMac with 128M of RAM, and a Dual 2GHz G5 with 1.5 Gig of RAM. Have used the Raqua, the Frameworks installation, and a fresh compile of the source using Fink in the X11 implementation. No matter the machine or the version (1.8x through 1.9, OS X or Unix X11), I get the same result. Thanks to Andy Liaw for helping me tune the code this far. I'm stumped. Would love to hear others' experience with this, and if they can reproduce the problem elsewhere. -- David L. Van Brunt, Ph.D. Outlier Consulting & Development mailto: ==> 6903.followup.1 <== From stefano.iacus@unimi.it Fri May 21 19:47:13 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 77B2D1058C for ; Fri, 21 May 2004 19:47:13 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14418-09 for ; Fri, 21 May 2004 19:47:12 +0200 (CEST) Received: from ms001msg.fastwebnet.it (ms001msg.fastwebnet.it [213.140.2.51]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 21 May 2004 19:47:12 +0200 (CEST) Received: from [10.0.1.3] (1.101.207.49) by ms001msg.fastwebnet.it (7.0.028) id 4096D40500787051; Fri, 21 May 2004 19:47:12 +0200 In-Reply-To: <20040521132440.BA60A10590@slim.kubism.ku.dk> References: <20040521132440.BA60A10590@slim.kubism.ku.dk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch From: stefano iacus Subject: Re: [Rd] Memory Leak in OS X versions? (PR#6903) Date: Fri, 21 May 2004 19:47:10 +0200 To: dvanbrunt@well-wired.com X-Mailer: Apple Mail (2.613) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I can confirm the behaviour (btw, 1.9.0 is not beta) in 1.9.0 and in=20 R-patched I'll try to investigate. stefano On May 21, 2004, at 3:24 PM, dvanbrunt@well-wired.com wrote: > Full_Name: David L. Van Brunt > Version: 1.8-1.9 beta > OS: OS X 10.3 > Submission from: (NULL) (68.74.58.109) > > > As posted on R-Help (after which another user replicated the problem): > --------------- > This is the conclusion from a prior thread ([R] " cannot allocate=20 > vector of > length 1072693248") which ended with no other answer but that there=20 > must be > a problem in the OS X version of R, or in the compile of the source on=20= > OS X. > > I=92ve posted code and data here: > http://www.well-wired.com/reflibrary/uploads/1084503247.zip > > If you setwd() into the directory that is made, then =93source()=94 = the=20 > =93.R=94 > file, it should run fine on Windows but crash on any machine with OS X > (Panther) giving: =93Error in as.vector(data) : cannot allocate vector = of > length 1073741824=94 after a few iterations of the loop. > > I've repeated this on a Powerbook G4 with 500 MB of RAM, an iMac with=20= > 128M > of RAM, and a Dual 2GHz G5 with 1.5 Gig of RAM. Have used the Raqua,=20= > the > Frameworks installation, and a fresh compile of the source using Fink=20= > in the > X11 implementation. No matter the machine or the version (1.8x through=20= > 1.9, > OS X or Unix X11), I get the same result. > > Thanks to Andy Liaw for helping me tune the code this far. > > I'm stumped. Would love to hear others' experience with this, and if=20= > they > can reproduce the problem elsewhere. > > > --=20 > David L. Van Brunt, Ph.D. > Outlier Consulting & Development > mailto: > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > ==> 6903.audit <== Sat May 22 22:03:57 2004 ripley moved from incoming to Macintosh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6940 * Subject: Crash in OSX From: murray.pung@studentmail.newcastle.edu.au Date: Sat, 5 Jun 2004 04:36:52 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6940 <== From murray.pung@studentmail.newcastle.edu.au Sat Jun 5 04:36:53 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 889C210878 for ; Sat, 5 Jun 2004 04:36:52 +0200 (CEST) From: murray.pung@studentmail.newcastle.edu.au To: R-bugs@biostat.ku.dk Subject: Crash in OSX Message-Id: <20040605023652.889C210878@slim.kubism.ku.dk> Date: Sat, 5 Jun 2004 04:36:52 +0200 (CEST) X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_10,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Murray Pung Version: 1.9.0 OS: OSX Mac Submission from: (NULL) (134.148.20.33) Date/Time: 2004-06-05 12:32:30 +1000 OS Version: 10.3.4 (Build 7H63) Report Version: 2 Command: R.bin Path: /Library/Frameworks/R.framework/Resources/bin/R.bin Version: 1.9.0 (R 1.9.0) PID: 358 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000005 Thread 0 Crashed: 0 libSystem.B.dylib 0x90006e70 strlen + 0x50 1 R_aqua.so 0x0048699c HistFwd + 0x134 (aquaconsole.c:3451) 2 R_aqua.so 0x004825c8 KeybHandler + 0xd4 (aquaconsole.c:1370) 3 com.apple.HIToolbox 0x927d2330 DispatchEventToHandlers + 0x150 4 com.apple.HIToolbox 0x927d25a4 SendEventToEventTargetInternal + 0x174 5 com.apple.HIToolbox 0x927d6a0c SendEventToEventTargetWithOptions + 0x28 6 com.apple.HIToolbox 0x9280b4c0 _Z19HandleKeyboardEventP14OpaqueEventRefm + 0x160 7 com.apple.HIToolbox 0x927e2fe4 _Z29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 0x1f8 8 com.apple.HIToolbox 0x927d23ec DispatchEventToHandlers + 0x20c 9 com.apple.HIToolbox 0x927d25a4 SendEventToEventTargetInternal + 0x174 10 com.apple.HIToolbox 0x927e4a34 SendEventToEventTarget + 0x28 11 R_aqua.so 0x004876d0 Raqua_ProcessEvents + 0xa4 (aquaconsole.c:3889) 12 R_aqua.so 0x0048204c Raqua_ReadConsole + 0x9c (aquaconsole.c:1228) 13 R.bin 0x00080c78 Rf_ReplIteration + 0x60 (main.c:200) 14 R.bin 0x00080f30 R_ReplConsole + 0x88 (main.c:299) 15 R.bin 0x000818d8 run_Rmainloop + 0x78 (main.c:654) 16 R.bin 0x000ed7bc main + 0x14 (system.c:102) 17 R.bin 0x0000204c _start + 0x17c (crt.c:267) 18 R.bin 0x00001ecc start + 0x30 PPC Thread State: srr0: 0x90006e70 srr1: 0x0200f030 vrsave: 0x00000000 cr: 0x44022244 xer: 0x20000000 lr: 0x0048699c ctr: 0x90006e20 r0: 0x0048699c r1: 0xbffff060 r2: 0x000001f4 r3: 0x00000005 r4: 0x00000001 r5: 0x00000004 r6: 0x0000007d r7: 0x004b6870 r8: 0x004b6870 r9: 0x00000005 r10: 0x004b6870 r11: 0x00494a34 r12: 0x90006e20 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000002 r21: 0x00000000 r22: 0x05607710 r23: 0x0110d8f0 r24: 0xbffff270 r25: 0xffffd96e r26: 0x00000000 r27: 0xbffff180 r28: 0x00000001 r29: 0x004af55c r30: 0x004afd2c r31: 0x00486870 Binary Images Description: 0x1000 - 0x16dfff R.bin /Library/Frameworks/R.framework/Resources/bin/R.bin 0x47f000 - 0x493fff R_aqua.so /Library/Frameworks/R.framework/Resources/modules/R_aqua.so 0x605000 - 0x62ffff libreadline.4.3.dylib /Library/Frameworks/R.framework/Resources/bin/Frameworks/libreadline.4.3.dylib 0x17b9000 - 0x17bcfff methods.so /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/methods/libs/methods.so 0x2008000 - 0x217bfff libR.dylib /Library/Frameworks/R.framework/Resources/bin/libR.dylib 0x5489000 - 0x548afff tools.so /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/tools/libs/tools.so 0x5492000 - 0x54bcfff stats.so /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/stats/libs/stats.so 0x576a000 - 0x57a4fff vfonts.so /Library/Frameworks/R.framework/Resources/modules/vfonts.so 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.4 (299.31) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 10.3.4 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90570000 - 0x905defff com.apple.framework.IOKit 1.3.2 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x90610000 - 0x9069afff com.apple.CoreServices.OSServices 3.0.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x90700000 - 0x90700fff com.apple.CoreServices 10.3 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x90720000 - 0x90787fff com.apple.audio.CoreAudio 2.1.2 /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x907f0000 - 0x907f9fff com.apple.DiskArbitration 2.0.3 /System/Library/PrivateFrameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x90810000 - 0x90810fff com.apple.ApplicationServices 1.0 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x90910000 - 0x90983fff com.apple.DesktopServices 1.2.2 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x90d00000 - 0x90d1bfff com.apple.SystemConfiguration 1.7.1 (???) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x90d40000 - 0x90d40fff com.apple.Carbon 10.3 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x910b0000 - 0x910fffff com.apple.bom 1.2.4 (63) /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x912a0000 - 0x912bdfff com.apple.audio.SoundManager 3.8 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x912e0000 - 0x912f7fff com.apple.LangAnalysis 1.5.4 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x91320000 - 0x913defff ColorSync /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x91460000 - 0x91473fff com.apple.speech.synthesis.framework 3.2 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x914a0000 - 0x91509fff com.apple.htmlrendering 1.1.2 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x91560000 - 0x91619fff com.apple.QD 3.4.64 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x91670000 - 0x916a8fff com.apple.AE 1.3.2 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x916e0000 - 0x91773fff com.apple.print.framework.PrintCore 3.3 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x917e0000 - 0x917f0fff com.apple.speech.recognition.framework 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x91810000 - 0x9182afff com.apple.openscripting 1.2.1 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x91850000 - 0x91860fff com.apple.ImageCapture 2.1.0 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x91890000 - 0x9189cfff com.apple.help 1.0.1 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x918c0000 - 0x918cdfff com.apple.CommonPanels 1.2.1 (1.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x918f0000 - 0x9193efff com.apple.print.framework.Print 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x91990000 - 0x9199bfff com.apple.securityhi 1.2 (90) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x919c0000 - 0x91a33fff com.apple.NavigationServices 3.3.1 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x91ab0000 - 0x91ac4fff libCGATS.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib 0x91ae0000 - 0x91aebfff libCSync.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x91b10000 - 0x91b2afff libPDFRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libPDFRIP.A.dylib 0x91b50000 - 0x91b5ffff libPSRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libPSRIP.A.dylib 0x91b80000 - 0x91b93fff libRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x91bb0000 - 0x91d3cfff com.apple.QuickTime 6.4.0 /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 0x92070000 - 0x92096fff com.apple.FindByContent 1.4 (1.2) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent 0x920c0000 - 0x922a7fff com.apple.security 2.3 (176) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x92430000 - 0x92468fff com.apple.LaunchServices 10.3 (84) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x92740000 - 0x92777fff com.apple.CFNetwork 1.2.1 (7) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x927d0000 - 0x92b54fff com.apple.HIToolbox 1.3.3 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x92d30000 - 0x92d80fff com.apple.HIServices 1.4.1 (0.0.1d1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x935d0000 - 0x938a8fff com.apple.CoreGraphics 1.203.20 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x939a0000 - 0x939b4fff libcups.2.dylib /usr/lib/libcups.2.dylib 0x939d0000 - 0x939d4fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x94060000 - 0x94078fff com.apple.WebServices 1.1.1 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore 0x94120000 - 0x9414bfff libncurses.5.dylib /usr/lib/libncurses.5.dylib 0x945b0000 - 0x945b9fff libz.1.dylib /usr/lib/libz.1.dylib 0x94610000 - 0x9462afff libresolv.9.dylib /usr/lib/libresolv.9.dylib 0x94650000 - 0x946affff com.apple.SearchKit 1.0.2 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x94b20000 - 0x94badfff com.apple.ink.framework 55.8 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x954c0000 - 0x95ac6fff libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x95b20000 - 0x95df0fff libLAPACK.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x95e40000 - 0x95eadfff libvDSP.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x95f00000 - 0x95f20fff libvMisc.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x968d0000 - 0x969b2fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x96a20000 - 0x96ae2fff libcrypto.0.9.7.dylib /usr/lib/libcrypto.0.9.7.dylib 0x96b40000 - 0x96b6efff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib 0x96bf0000 - 0x96c7ffff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x96e80000 - 0x96e90fff com.apple.vecLib 3.0.1 (vecLib 3.0.1) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x97510000 - 0x97518fff libbsm.dylib /usr/lib/libbsm.dylib ==> 6940.audit <== Mon Jun 7 11:30:58 2004 ripley moved from incoming to Macintosh ==> 6940.followup.1 <== From jago@mclink.it Tue Jun 8 16:06:18 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 6FD2410870 for ; Tue, 8 Jun 2004 16:06:17 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00283-07 for ; Tue, 8 Jun 2004 16:06:15 +0200 (CEST) Received: from mail2.mclink.it (mail2.mclink.it [195.110.128.53]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 8 Jun 2004 16:06:15 +0200 (CEST) Received: from [147.162.105.17] ([147.162.105.17]) by mail2.mclink.it (8.12.6p2/8.12.3) with ESMTP id i58E62KD056333; Tue, 8 Jun 2004 16:06:03 +0200 (CEST) (envelope-from jago@mclink.it) In-Reply-To: <20040605023655.74B6910880@slim.kubism.ku.dk> References: <20040605023655.74B6910880@slim.kubism.ku.dk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch From: stefano iacus Subject: Re: [Rd] Crash in OSX (PR#6940) Date: Tue, 8 Jun 2004 16:06:01 +0200 To: murray.pung@studentmail.newcastle.edu.au X-Mailer: Apple Mail (2.618) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Please report a reproducible example. It's surely something related to the history (prev/next key) management but I cannot track it down this way. stefano On Jun 5, 2004, at 4:36 AM, murray.pung@studentmail.newcastle.edu.au wrote: > Full_Name: Murray Pung > Version: 1.9.0 > OS: OSX Mac > Submission from: (NULL) (134.148.20.33) > > > Date/Time: 2004-06-05 12:32:30 +1000 > OS Version: 10.3.4 (Build 7H63) > Report Version: 2 > > Command: R.bin > Path: /Library/Frameworks/R.framework/Resources/bin/R.bin > Version: 1.9.0 (R 1.9.0) > PID: 358 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000005 > > Thread 0 Crashed: > 0 libSystem.B.dylib 0x90006e70 strlen + 0x50 > 1 R_aqua.so 0x0048699c HistFwd + 0x134 > (aquaconsole.c:3451) > 2 R_aqua.so 0x004825c8 KeybHandler + 0xd4 > (aquaconsole.c:1370) > 3 com.apple.HIToolbox 0x927d2330 DispatchEventToHandlers + 0x150 > 4 com.apple.HIToolbox 0x927d25a4 SendEventToEventTargetInternal + > 0x174 > 5 com.apple.HIToolbox 0x927d6a0c SendEventToEventTargetWithOptions > + 0x28 > 6 com.apple.HIToolbox 0x9280b4c0 > _Z19HandleKeyboardEventP14OpaqueEventRefm + > 0x160 > 7 com.apple.HIToolbox 0x927e2fe4 > _Z29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueE > ventRefPv > + 0x1f8 > 8 com.apple.HIToolbox 0x927d23ec DispatchEventToHandlers + 0x20c > 9 com.apple.HIToolbox 0x927d25a4 SendEventToEventTargetInternal + > 0x174 > 10 com.apple.HIToolbox 0x927e4a34 SendEventToEventTarget + 0x28 > 11 R_aqua.so 0x004876d0 Raqua_ProcessEvents + 0xa4 > (aquaconsole.c:3889) > 12 R_aqua.so 0x0048204c Raqua_ReadConsole + 0x9c > (aquaconsole.c:1228) > 13 R.bin 0x00080c78 Rf_ReplIteration + 0x60 > (main.c:200) > 14 R.bin 0x00080f30 R_ReplConsole + 0x88 (main.c:299) > 15 R.bin 0x000818d8 run_Rmainloop + 0x78 (main.c:654) > 16 R.bin 0x000ed7bc main + 0x14 (system.c:102) > 17 R.bin 0x0000204c _start + 0x17c (crt.c:267) > 18 R.bin 0x00001ecc start + 0x30 > > PPC Thread State: > srr0: 0x90006e70 srr1: 0x0200f030 vrsave: 0x00000000 > cr: 0x44022244 xer: 0x20000000 lr: 0x0048699c ctr: 0x90006e20 > r0: 0x0048699c r1: 0xbffff060 r2: 0x000001f4 r3: 0x00000005 > r4: 0x00000001 r5: 0x00000004 r6: 0x0000007d r7: 0x004b6870 > r8: 0x004b6870 r9: 0x00000005 r10: 0x004b6870 r11: 0x00494a34 > r12: 0x90006e20 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 > r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 > r20: 0x00000002 r21: 0x00000000 r22: 0x05607710 r23: 0x0110d8f0 > r24: 0xbffff270 r25: 0xffffd96e r26: 0x00000000 r27: 0xbffff180 > r28: 0x00000001 r29: 0x004af55c r30: 0x004afd2c r31: 0x00486870 > > Binary Images Description: > 0x1000 - 0x16dfff R.bin > /Library/Frameworks/R.framework/Resources/bin/R.bin > 0x47f000 - 0x493fff R_aqua.so > /Library/Frameworks/R.framework/Resources/modules/R_aqua.so > 0x605000 - 0x62ffff libreadline.4.3.dylib > /Library/Frameworks/R.framework/Resources/bin/Frameworks/ > libreadline.4.3.dylib > 0x17b9000 - 0x17bcfff methods.so > /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/ > methods/libs/methods.so > 0x2008000 - 0x217bfff libR.dylib > /Library/Frameworks/R.framework/Resources/bin/libR.dylib > 0x5489000 - 0x548afff tools.so > /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/ > tools/libs/tools.so > 0x5492000 - 0x54bcfff stats.so > /Library/Frameworks/R.framework/Versions/1.9.0/Resources/library/ > stats/libs/stats.so > 0x576a000 - 0x57a4fff vfonts.so > /Library/Frameworks/R.framework/Resources/modules/vfonts.so > 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld > 0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib > 0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3.4 (299.31) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ > CoreFoundation > 0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 10.3.4 > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x90570000 - 0x905defff com.apple.framework.IOKit 1.3.2 (???) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x90610000 - 0x9069afff com.apple.CoreServices.OSServices 3.0.1 > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/OSServices.framework/Versions/A/OSServices > 0x90700000 - 0x90700fff com.apple.CoreServices 10.3 (???) > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > CoreServices > 0x90720000 - 0x90787fff com.apple.audio.CoreAudio 2.1.2 > /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio > 0x907f0000 - 0x907f9fff com.apple.DiskArbitration 2.0.3 > /System/Library/PrivateFrameworks/DiskArbitration.framework/Versions/ > A/DiskArbitration > 0x90810000 - 0x90810fff com.apple.ApplicationServices 1.0 (???) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > ApplicationServices > 0x90910000 - 0x90983fff com.apple.DesktopServices 1.2.2 > /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/ > Versions/A/DesktopServicesPriv > 0x90d00000 - 0x90d1bfff com.apple.SystemConfiguration 1.7.1 (???) > /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/ > SystemConfiguration > 0x90d40000 - 0x90d40fff com.apple.Carbon 10.3 (???) > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon > 0x910b0000 - 0x910fffff com.apple.bom 1.2.4 (63) > /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom > 0x912a0000 - 0x912bdfff com.apple.audio.SoundManager 3.8 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CarbonSound.framework/Versions/A/CarbonSound > 0x912e0000 - 0x912f7fff com.apple.LangAnalysis 1.5.4 > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis > 0x91320000 - 0x913defff ColorSync > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ColorSync.framework/Versions/A/ColorSync > 0x91460000 - 0x91473fff com.apple.speech.synthesis.framework 3.2 > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis > 0x914a0000 - 0x91509fff com.apple.htmlrendering 1.1.2 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HTMLRendering.framework/Versions/A/HTMLRendering > 0x91560000 - 0x91619fff com.apple.QD 3.4.64 (???) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/QD.framework/Versions/A/QD > 0x91670000 - 0x916a8fff com.apple.AE 1.3.2 > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/AE.framework/Versions/A/AE > 0x916e0000 - 0x91773fff com.apple.print.framework.PrintCore 3.3 > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/PrintCore.framework/Versions/A/PrintCore > 0x917e0000 - 0x917f0fff com.apple.speech.recognition.framework 3.3 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > SpeechRecognition.framework/Versions/A/SpeechRecognition > 0x91810000 - 0x9182afff com.apple.openscripting 1.2.1 (???) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > OpenScripting.framework/Versions/A/OpenScripting > 0x91850000 - 0x91860fff com.apple.ImageCapture 2.1.0 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > ImageCapture.framework/Versions/A/ImageCapture > 0x91890000 - 0x9189cfff com.apple.help 1.0.1 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Help.framework/Versions/A/Help > 0x918c0000 - 0x918cdfff com.apple.CommonPanels 1.2.1 (1.0) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > CommonPanels.framework/Versions/A/CommonPanels > 0x918f0000 - 0x9193efff com.apple.print.framework.Print 3.3 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Print.framework/Versions/A/Print > 0x91990000 - 0x9199bfff com.apple.securityhi 1.2 (90) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > SecurityHI.framework/Versions/A/SecurityHI > 0x919c0000 - 0x91a33fff com.apple.NavigationServices 3.3.1 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > NavigationServices.framework/Versions/A/NavigationServices > 0x91ab0000 - 0x91ac4fff libCGATS.A.dylib > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/Resources/ > libCGATS.A.dylib > 0x91ae0000 - 0x91aebfff libCSync.A.dylib > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/Resources/ > libCSync.A.dylib > 0x91b10000 - 0x91b2afff libPDFRIP.A.dylib > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/Resources/ > libPDFRIP.A.dylib > 0x91b50000 - 0x91b5ffff libPSRIP.A.dylib > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/Resources/ > libPSRIP.A.dylib > 0x91b80000 - 0x91b93fff libRIP.A.dylib > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib > 0x91bb0000 - 0x91d3cfff com.apple.QuickTime 6.4.0 > /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime > 0x92070000 - 0x92096fff com.apple.FindByContent 1.4 (1.2) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/FindByContent.framework/Versions/A/FindByContent > 0x920c0000 - 0x922a7fff com.apple.security 2.3 (176) > /System/Library/Frameworks/Security.framework/Versions/A/Security > 0x92430000 - 0x92468fff com.apple.LaunchServices 10.3 (84) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/LaunchServices.framework/Versions/A/LaunchServices > 0x92740000 - 0x92777fff com.apple.CFNetwork 1.2.1 (7) > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/CFNetwork.framework/Versions/A/CFNetwork > 0x927d0000 - 0x92b54fff com.apple.HIToolbox 1.3.3 (???) > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > HIToolbox.framework/Versions/A/HIToolbox > 0x92d30000 - 0x92d80fff com.apple.HIServices 1.4.1 (0.0.1d1) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/HIServices.framework/Versions/A/HIServices > 0x935d0000 - 0x938a8fff com.apple.CoreGraphics 1.203.20 (???) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > 0x939a0000 - 0x939b4fff libcups.2.dylib /usr/lib/libcups.2.dylib > 0x939d0000 - 0x939d4fff libmathCommon.A.dylib > /usr/lib/system/libmathCommon.A.dylib > 0x94060000 - 0x94078fff com.apple.WebServices 1.1.1 (1.1.0) > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore > 0x94120000 - 0x9414bfff libncurses.5.dylib /usr/lib/libncurses.5.dylib > 0x945b0000 - 0x945b9fff libz.1.dylib /usr/lib/libz.1.dylib > 0x94610000 - 0x9462afff libresolv.9.dylib /usr/lib/libresolv.9.dylib > 0x94650000 - 0x946affff com.apple.SearchKit 1.0.2 > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/SearchKit.framework/Versions/A/SearchKit > 0x94b20000 - 0x94badfff com.apple.ink.framework 55.8 > /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ > Ink.framework/Versions/A/Ink > 0x954c0000 - 0x95ac6fff libBLAS.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libBLAS.dylib > 0x95b20000 - 0x95df0fff libLAPACK.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libLAPACK.dylib > 0x95e40000 - 0x95eadfff libvDSP.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvDSP.dylib > 0x95f00000 - 0x95f20fff libvMisc.dylib > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ > vecLib.framework/Versions/A/libvMisc.dylib > 0x968d0000 - 0x969b2fff libicucore.A.dylib /usr/lib/libicucore.A.dylib > 0x96a20000 - 0x96ae2fff libcrypto.0.9.7.dylib > /usr/lib/libcrypto.0.9.7.dylib > 0x96b40000 - 0x96b6efff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib > 0x96bf0000 - 0x96c7ffff ATS > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > Frameworks/ATS.framework/Versions/A/ATS > 0x96e80000 - 0x96e90fff com.apple.vecLib 3.0.1 (vecLib 3.0.1) > /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib > 0x97510000 - 0x97518fff libbsm.dylib /usr/lib/libbsm.dylib > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7030 * Subject: input file and console command size limit From: jerome.mutterer@ibmp-ulp.u-strasbg.fr Date: Tue, 29 Jun 2004 09:00:36 +0200 (CEST) --On R Aqua on MacOS X ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7030 <== From jerome.mutterer@ibmp-ulp.u-strasbg.fr Tue Jun 29 09:00:36 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 34850ECB4 for ; Tue, 29 Jun 2004 09:00:36 +0200 (CEST) From: jerome.mutterer@ibmp-ulp.u-strasbg.fr To: R-bugs@biostat.ku.dk Subject: input file and console command size limit Message-Id: <20040629070036.34850ECB4@slim.kubism.ku.dk> Date: Tue, 29 Jun 2004 09:00:36 +0200 (CEST) X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: j m Version: 1.9.0 OS: Mac OsX 10.3.4 Submission from: (NULL) (130.79.19.4) I noticed a 1024 characters size limit when entering R commands in the R console or when calling R from the command line using something like >R $R_in_opts $r_inputfile $R_out_opts $r_outputfile ==> 7030.audit <== Thu Jul 1 09:34:19 2004 ripley changed notes Thu Jul 1 09:34:19 2004 ripley moved from incoming to Macintosh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7036 * Subject: Installation of R 1.9 on Mac OS X 10.3 From: deejemon@eudoramail.com Date: Wed, 30 Jun 2004 03:26:05 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7036 <== From deejemon@eudoramail.com Wed Jun 30 03:26:05 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 00826108EF for ; Wed, 30 Jun 2004 03:26:05 +0200 (CEST) From: deejemon@eudoramail.com To: R-bugs@biostat.ku.dk Subject: Installation of R 1.9 on Mac OS X 10.3 Message-Id: <20040630012605.00826108EF@slim.kubism.ku.dk> Date: Wed, 30 Jun 2004 03:26:05 +0200 (CEST) X-Spam-Status: No, hits=1.2 required=5.0 tests=BAYES_20,FORGED_EUDORAMAIL_RCVD,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Mac OS X Angel Version: 1.9 OS: 10.3.4 Submission from: (NULL) (128.184.132.11) Having installed both the libxml and the R packages which are included in the R 1.9 distribution, I ended up with a very small application (/Applications/R.app), of only about 170KB. Double-clicking this application showed the icon in the Dock momentarily, but it would disappear and nothing else would happen. I opened up the installer into Pacifist (http://www.charlessoft.com) to see the contents, and indeed, the installer is almost empty - only the 170-or-so KB to be installed. I also noticed that the framework which is mentioned during the installation screen was not listed. I expected something to be installed into /Library/Frameworks, but nothing appeared in the installer contents. That's when I noticed that the installer pkg (R.pkg) is actually about 15MB. I wondered where all that other space was going. If the application is less than 200KB, why should the installer be 15MB? So, I found the R.framework.tgz file in R.pkg/Contents/Resources/. It looks like this framework is not being installed. I manually copied the R.framework.tgz, decompressed it, copied it into /Library/Frameworks (I had to create the Frameworks folder, since it didn't already exist), and suddenly R started running. ==> 7036.audit <== Thu Jul 1 09:32:25 2004 ripley moved from incoming to Macintosh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7047 * Subject: DSTEIN error From: weigand.stephen@charter.net Date: Sat, 3 Jul 2004 05:09:36 +0200 (CEST) --Mac OS X BLAS problem ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7047 <== From weigand.stephen@charter.net Sat Jul 3 05:09:37 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id AE5E11092D for ; Sat, 3 Jul 2004 05:09:36 +0200 (CEST) From: weigand.stephen@charter.net To: R-bugs@biostat.ku.dk Subject: DSTEIN error Message-Id: <20040703030936.AE5E11092D@slim.kubism.ku.dk> Date: Sat, 3 Jul 2004 05:09:36 +0200 (CEST) X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Stephen Weigand Version: 1.9.0 OS: Mac OS X 10.3.4 Submission from: (NULL) (68.115.89.235) When running an iteratively reweighted least squares program R crashes and the following is written to the console.app (when using R GUI) or to stdout (when using R from the command line): Parameter 5 to routine DSTEIN was incorrect Mac OS BLAS parameter error in DSTEIN, parameter #0, (unavailable), is 0 In case it helps, here's the function and function call that causes the crash. n <- 4 p <- 1 f <- 2; k <- 2 lms.bcn.univar <- function(y, B, p, f, k, lambda.0, mu.0, sigma.0){ n <- length(y) D11 <- matrix(1, nrow = p, ncol = n) D1 <- rbind(cbind(D11, matrix(0, nrow = p, ncol = f)), cbind(matrix(0, nrow = f, ncol = n), diag(f))) D22 <- rbind(rep(1:0,n), rep(0:1,n)) x1 <- t(D22)[,1] x2 <- t(D22)[,2] D2 <- rbind(cbind(diag(n), matrix(0, nrow = n, ncol = 2*n)), cbind(matrix(0, nrow = f, ncol = n), D22)) R <- matrix(0, nrow = n, ncol = k * n) Ra <- diag(n + n*k) A11 <- function(lambda, mu, sigma){ diag((1 + 2 * lambda^2 * sigma^2)/(mu^2 * sigma^2), nrow = n) } A22 <- function(lambda, sigma, n) { A <- matrix(0, nrow = n*2, ncol = n*2) block <- c(7 * sigma^2 / 4, lambda * sigma, lambda * sigma, 2 / (sigma^2)) ## code to get the indices of the elements of a block ## diagonal matrix when the matrix is treated as a vector. m <- n*2 s <- integer(0) for (i in seq(1, m-1, by = 2)) s <- c(s, rep(i:(i+1),2)) block.indices <- m * rep(0:(m-1), each = 2) + s A[block.indices] <- block return(A) } A12 <- function(lambda, mu, sigma, n) { A <- matrix(0, nrow = n, ncol = n * 2) block <- c(-1/(2 * mu), (2*lambda)/(mu * sigma)) block.indices <- n * 0:(2*n-1) + rep(1:n, each = 2) A[block.indices] <- block return(A) } I.exp <- function(A11,A12,A22) { rbind(cbind(A11, A12), cbind(t(A12),A22)) } G <- function(D2, Ra, A11, A12, A22){ D2 %*% Ra %*% I.exp(A11,A12,A22) %*% t(Ra) %*% t(D2) } W <- function(G){ G11 <- G[1:n, 1:4] G12 <- G[1:4, 5:6] G22 <- G[5:6, 5:6] } W <- function(G,n,k){ G11 <- G[1:n, 1:n] G12 <- G[1:n, (n+1):(n+k)] G22 <- G[(n+1):(n+k), (n+1):(n+k)] G11 - G12 %*% solve(G22) %*% t(G12) } zbc <- function(y,lambda, mu, sigma) { ((y/mu)^lambda - 1) / (lambda * sigma) } L1 <- function(y,lambda, mu, sigma) { z <- zbc(y,lambda, mu, sigma) return(z/(mu * sigma) + lambda * (z^2 - 1) / mu) } L2 <- function(y,lambda,mu,sigma){ z <- zbc(y,lambda, mu, sigma) L.lambda <- z/lambda * (z - log(y/mu)/sigma) - log(y/mu) * (z^2 - 1) L.sigma <- (z^2 - 1)/sigma L <- c(L.lambda, L.sigma) return(L[c(1, n + 1) + rep(0:(n-1), each = 2)]) } u1 <- function(L1, L2, G, R, D22) { G12 <- G[1:n, (n+1):(n+k)] G22 <- G[(n+1):(n+k), (n+1):(n+k)] return(L1 + (R - G12 %*% solve(G22) %*% D22) %*% L2) } u2 <- function(L2, A12, A22, R, D11, beta.new, beta.old){ L2 - (t(A12) + A22 %*% t(R)) %*% t(D11) %*% (beta.new - beta.old) } loglike <- function(y, l, m, s) { sum( l * log(y/m) - log(s) - 0.5 * zbc(y,l,m,s)^2 ) } loglikeOptim <- function(par,y){ lambda <- par[1] mu <- par[2] sigma <- par[3] -1 * loglike(y, lambda, mu, sigma) } ll.0 <- loglike(y, lambda.0, mu.0, sigma.0) require(MASS) lambda.old <- lambda.0; mu.old <- mu.0; sigma.old <- sigma.0 parameters <- as.data.frame(matrix(NA, ncol = 4, nrow = B)) colnames(parameters) <- c("lambda", "mu", "sigma", "loglike") for(i in 1:B) { ##cat(paste(i, ",")) a11 <- A11(lambda.old, mu.old, sigma.old) a22 <- A22(lambda.old, sigma.old, n) a12 <- A12(lambda.old, mu.old, sigma.old, n) g <- G(D2, Ra, a11, a12, a22); w <- W(g, n ,2) l1 <- L1(y, lambda.old, mu.old, sigma.old) l2 <- L2(y, lambda.old, mu.old, sigma.old) Y.mu <- solve(w) %*% u1(l1, l2, g, R, D22) + t(D11) %*% mu.old mu.new <- coef(lm.gls(Y.mu ~ 1, W = w)) psi.old <- rbind(lambda.old, sigma.old) Y.psi <- solve(a22) %*% u2(l2, a12, a22, R, D11, mu.new, mu.old) + t(D22) %*% psi.old psi.new <- coef(lm.gls(Y.psi ~ -1 + x1 + x2, W = a22)) lambda.new <- psi.new[1]; sigma.new <- psi.new[2] parameters[i, 1] <- lambda.new parameters[i, 2] <- mu.new parameters[i, 3] <- sigma.new parameters[i, 4] <- loglike(y, lambda.new, mu.new, sigma.new) ### update the old with the new lambda.old <- lambda.new; mu.old <- mu.new; sigma.old <- sigma.new; } return(list(lambda.0 = lambda.0, mu.0 = mu.0, sigma.0 = sigma.0, loglike.0 = ll.0, parameters = parameters)) } require(MASS) set.seed(1676) y <- exp(rnorm(20) + 2) y <- round(y,2) ##print(lms.bcn.univar(y, B=15, p=1, f=2, k=2, 0.3, 8, 0.8)) y <- rgamma(100,3,2) print(lms.bcn.univar(y, B=5, p=1, f=2, k=2, 0.3, mu.0 = median(y), sigma.0 = sd(y)/median(y))) ==> 7047.followup.1 <== From ripley@stats.ox.ac.uk Sat Jul 3 07:40:59 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 07CA71092B for ; Sat, 3 Jul 2004 07:40:58 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26623-08 for ; Sat, 3 Jul 2004 07:40:58 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 3 Jul 2004 07:40:57 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i635eurt028860; Sat, 3 Jul 2004 06:40:56 +0100 (BST) Date: Sat, 3 Jul 2004 06:40:56 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: weigand.stephen@charter.net Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] DSTEIN error (PR#7047) In-Reply-To: <20040703030938.EFBC010930@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) What does `R crashes' mean? Please see the R posting guide. I think the error message indicates a bug in MacOS X. What made you think this was a bug in R? (It depends of course what `crashes' meant - if the R application aborted it would be, but not if it just gave an error message (hardly a crash) nor if the MacOS runtime aborted.) The code runs to completion on Windows and Linux with a variety of BLASes, including that supplied with R (which MacOS X is unable to use as it is Fortran). On Sat, 3 Jul 2004 weigand.stephen@charter.net wrote: > Full_Name: Stephen Weigand > Version: 1.9.0 > OS: Mac OS X 10.3.4 > Submission from: (NULL) (68.115.89.235) > > > When running an iteratively reweighted least squares program R crashes and the > following is > written to the console.app (when using R GUI) or to stdout (when using R from > the command > line): > > Parameter 5 to routine DSTEIN was incorrect > Mac OS BLAS parameter error in DSTEIN, parameter #0, (unavailable), is 0 .... -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 7047.followup.2 <== From weigand.stephen@charter.net Wed Jul 7 05:48:01 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id AB6F0108C7 for ; Wed, 7 Jul 2004 05:48:01 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19401-05 for ; Wed, 7 Jul 2004 05:48:00 +0200 (CEST) Received: from mxsf20.cluster1.charter.net (mxsf20.cluster1.charter.net [209.225.28.220]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 7 Jul 2004 05:48:00 +0200 (CEST) Received: from mxip11.cluster1.charter.net (mxip11a.cluster1.charter.net [209.225.28.141]) by mxsf20.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i673onoD028058 for ; Tue, 6 Jul 2004 23:50:50 -0400 Received: from c68.115.89.235.roc.mn.charter.com (HELO [192.168.1.103]) (68.115.89.235) by mxip11.cluster1.charter.net with ESMTP; 06 Jul 2004 23:47:58 -0400 X-Ironport-AV: i="3.81R,152,1083556800"; d="scan'208"; a="91134646:sNHT15916874" Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CC70F59-CFC8-11D8-B8A3-000393B2B0E2@charter.net> Content-Transfer-Encoding: 7bit From: "Stephen D. Weigand" Subject: Re: [Rd] DSTEIN error (PR#7047) Date: Tue, 6 Jul 2004 22:47:53 -0500 To: R-bugs@biostat.ku.dk X-Mailer: Apple Mail (2.618) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) By "R crashes" I mean R GUI quits completely and R from the command line returns the user to the Unix shell. On Jul 3, 2004, at 12:40 AM, Prof Brian Ripley wrote: > What does `R crashes' mean? Please see the R posting guide. > > I think the error message indicates a bug in MacOS X. What made you > think > this was a bug in R? (It depends of course what `crashes' meant - if > the > R application aborted it would be, but not if it just gave an error > message (hardly a crash) nor if the MacOS runtime aborted.) > > The code runs to completion on Windows and Linux with a variety of > BLASes, > including that supplied with R (which MacOS X is unable to use as it is > Fortran). > > On Sat, 3 Jul 2004 weigand.stephen@charter.net wrote: > >> Full_Name: Stephen Weigand >> Version: 1.9.0 >> OS: Mac OS X 10.3.4 >> Submission from: (NULL) (68.115.89.235) >> >> >> When running an iteratively reweighted least squares program R >> crashes and the >> following is >> written to the console.app (when using R GUI) or to stdout (when >> using R from >> the command >> line): >> >> Parameter 5 to routine DSTEIN was incorrect >> Mac OS BLAS parameter error in DSTEIN, parameter #0, (unavailable), >> is 0 > > .... ==> 7047.audit <== Fri Jul 9 18:48:41 2004 maechler changed notes Fri Jul 9 18:48:41 2004 maechler moved from incoming to Macintosh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Misc * PR# 1126 * Subject: R-bug report www page whishlist From: jens.lund@nordea.com Date: Wed, 10 Oct 2001 18:24:29 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1126 <== From jens.lund@nordea.com Wed Oct 10 18:24:29 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA01798 for ; Wed, 10 Oct 2001 18:24:29 +0200 (MET DST) Date: Wed, 10 Oct 2001 18:24:29 +0200 (MET DST) From: jens.lund@nordea.com Message-Id: <200110101624.SAA01798@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: R-bug report www page whishlist Full_Name: Jens Lund Version: -- OS: -- Submission from: (NULL) (194.239.194.210) On http://r-bugs.biostat.ku.dk/cgi-bin/R pressing "new bug report" returns a new form. It would, IMHO, be natural to place the "submit bug report" button on this form *below* the input area for the actual bug report :-) Cheers, Jens ==> 1126.audit <== Wed Oct 10 19:08:54 2001 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1158 * Subject: bug.report()sends empty message From: Paul Gilbert Date: Mon, 05 Nov 2001 10:05:27 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1158 <== From pgilbert@bank-banque-canada.ca Mon Nov 5 16:07:41 2001 Received: from mail1.bank-banque-canada.ca (mail1.bank-banque-canada.ca [140.80.193.130]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA03956 for ; Mon, 5 Nov 2001 16:07:39 +0100 (MET) Received: from fwx-t1 ([140.80.193.132]) by mail1.bank-banque-canada.ca (8.9.3/8.9.3) with SMTP id KAA05318; Mon, 5 Nov 2001 10:01:04 -0500 (EST) Message-ID: <3BE6AAB6.E0962CD5@bank-banque-canada.ca> Date: Mon, 05 Nov 2001 10:05:27 -0500 From: Paul Gilbert X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: R-bugs CC: brahm@alum.mit.edu Subject: bug.report()sends empty message Content-Type: multipart/mixed; boundary="------------FAC78F7B6BFECAD9BD873458" This is a multi-part message in MIME format. --------------FAC78F7B6BFECAD9BD873458 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Mon, 22 Oct 2001, David Brahm wrote: > I swear, bug.report() ate my message! Apologies to all, esp. Peter who > will once again have to clean up after my mess... With some editors on Unix bug.report() does this. The problem is that some editors (like Nedit) fork a separate process and return. The Unix version of bug.report sends an empty message in this case. The fix is to make the Unix version the same as the Windows version, with an optional argument "wait". Attached are four small files bug.report.R, bug.report.Rd, Sys.mail.R, and Sys.mail.Rd, which attempt to fix the problem and the documentation. They also separate out the mail mechanism as a utility that can be used elsewhere. Unfortunately, I have only been able to test these on a limited number of platforms. Paul Gilbert --------------FAC78F7B6BFECAD9BD873458 Content-Type: text/plain; charset=us-ascii; name="bug.report.R" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bug.report.R" bug.report <- function(subject = "", ccaddress = Sys.getenv("USER"), method = getOption("mailer"), address = "gilp", #"r-bugs@r-project.org", file = "R.bug.report", wait=TRUE) { methods <- c("mailx", "gnudoit", "none", "ess") method <- if(is.null(method)) "none" else methods[pmatch(method, methods)] body <- paste("\\n<>\\n\\n\\n\\n", "--please do not edit the information below--\\n\\n", "Version:\\n ", paste(names(R.version),R.version, sep=" = ",collapse="\\n "), "\\n\\n", "Search Path:\\n ", paste(search(), collapse=", "), "\\n", sep="", collapse="") if(method == "gnudoit") { cmd <- paste("gnudoit -q '", "(mail nil \"", address, "\")", "(insert \"", body, "\")", "(search-backward \"Subject:\")", "(end-of-line)'", sep="") system(cmd) if (wait) { cat("Hit Return to continue in R. ") answer <- readline() } } else if(method=="none"){ disclaimer <- paste("# Your mailer is set to \"none\" (default on Windows),\n", "# hence we cannot send the bug report directly from R.\n", "# Please copy the bug report (after finishing it) to\n", "# your favorite email program and send it to\n#\n", "# ", address, "\n#\n", "######################################################\n", "\n\n", sep = "") cat(disclaimer, file=file) body <- gsub("\\\\n", "\n", body) cat(body, file=file, append=TRUE) system(paste(getOption("editor"), file)) cat("The unsent bug report can be found in file", file, "\n") if (wait) { cat("Hit Return to continue in R. ") answer <- readline() } } else if(method == "mailx"){ if(missing(subject)) stop("Subject missing") body <- gsub("\\\\n", "\n", body) cat(body, file=file, append=FALSE) system(paste(getOption("editor"), file)) if (wait) { cat("Submit the bug report? (finish editing and save the file before responding) ") answer <- readline() answer <- grep("y", answer, ignore.case=TRUE) if(length(answer)>0){ body <- scan(file, what="char", sep="\n") cat("Sending email ...\n") status <- Sys.mail(address=address, ccaddress=ccaddress, subject=subject, body=body, method="mailx") if(!status) status <- Sys.mail(address=address, ccaddress=ccaddress, subject=subject, body=body, method="mail") if(!status) status <- Sys.mail(address=address, ccaddress=ccaddress, subject=subject, body=body, method="Mail") if(!status) { cat("Sending email failed!\n") cat("The unsent bug report can be found in file", file, "\n") } } } else cat("The unsent bug report can be found in file", file, "\n") } else if(method=="ess"){ body <- gsub("\\\\n", "\n", body) cat(body) if (wait) { cat("Hit Return to continue in R. ") answer <- readline() } } } --------------FAC78F7B6BFECAD9BD873458 Content-Type: text/plain; charset=us-ascii; name="bug.report.Rd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bug.report.Rd" \name{bug.report} \alias{bug.report} \title{Send a Bug Report} \usage{ bug.report(subject = "", ccaddress = Sys.getenv("USER"), method = getOption("mailer"), address = "r-bugs@r-project.org", file = "R.bug.report", wait = TRUE) } \arguments{ \item{subject}{Subject of the email. Please do not use single quotes (\code{'}) in the subject!} \item{ccaddress}{Optional email address for copies (default is current user). Use \code{ccaddress = NULL} for no copies.} \item{method}{Submission method, one of \code{"mailx"}, \code{"gnuclient"}, \code{"none"}, or \code{"ess"}.} \item{address}{Recipient's email address.} \item{file}{File to use for setting up the email (or storing it when method is \code{"none"} or sending mail fails).} \item{wait}{logical. Should \R wait for the editor to return?} } \description{ Invokes an editor to write a bug report and optionally mail it to the r-bugs list at \email{r-bugs@r-project.org}. Some standard information on the current version and configuration of \R are included automatically. } \details{ Currently direct submission of bug reports works only on Unix systems. If the submission method is \code{"mailx"}, then the default editor is used to write the bug report. Which editor is used can be controlled using \code{\link{options}}, type \code{getOption("editor")} to see what editor is currently defined. Please use the help pages of the respective editor for details of usage. After saving the bug report (in the temporary file opened) and exiting the editor the report is mailed using a Unix command line mail utility such as \code{mailx}. A copy of the mail is sent to the current user. If method is \code{"gnuclient"}, then an emacs mail buffer is opened and used for sending the email. If method is \code{"none"} or \code{NULL} (which is the default on Windows systems), then only an editor is opened to help writing the bug report. The report can then be copied to your favorite email program and be sent to the r-bugs list. If method is \code{"ess"} the body of the mail is simply sent to stdout. If wait is \code{"TRUE"} then \R issues a prompt after the editor is started and waits for input. If \R is sending the mail (e.g. with method code{"mailx"}) then wait should be \code{"TRUE"}. In this case the edited file must be saved before responding to the question. } \value{Nothing useful.} \section{When is there a bug?}{ If \R executes an illegal instruction, or dies with an operating system error message that indicates a problem in the program (as opposed to something like ``disk full''), then it is certainly a bug. Taking forever to complete a command can be a bug, but you must make certain that it was really \R's fault. Some commands simply take a long time. If the input was such that you KNOW it should have been processed quickly, report a bug. If you don't know whether the command should take a long time, find out by looking in the manual or by asking for assistance. If a command you are familiar with causes an \R error message in a case where its usual definition ought to be reasonable, it is probably a bug. If a command does the wrong thing, that is a bug. But be sure you know for certain what it ought to have done. If you aren't familiar with the command, or don't know for certain how the command is supposed to work, then it might actually be working right. Rather than jumping to conclusions, show the problem to someone who knows for certain. Finally, a command's intended definition may not be best for statistical analysis. This is a very important sort of problem, but it is also a matter of judgment. Also, it is easy to come to such a conclusion out of ignorance of some of the existing features. It is probably best not to complain about such a problem until you have checked the documentation in the usual ways, feel confident that you understand it, and know for certain that what you want is not available. If you are not sure what the command is supposed to do after a careful reading of the manual this indicates a bug in the manual. The manual's job is to make everything clear. It is just as important to report documentation bugs as program bugs. If the online argument list of a function disagrees with the manual, one of them must be wrong, so report the bug. } \section{How to report a bug}{ When you decide that there is a bug, it is important to report it and to report it in a way which is useful. What is most useful is an exact description of what commands you type, from when you start \R until the problem happens. Always include the version of \R, machine, and operating system that you are using; type `version' in \R to print this. The most important principle in reporting a bug is to report FACTS, not hypotheses or categorizations. It is always easier to report the facts, but people seem to prefer to strain to posit explanations and report them instead. If the explanations are based on guesses about how \R is implemented, they will be useless; we will have to try to figure out what the facts must have been to lead to such speculations. Sometimes this is impossible. But in any case, it is unnecessary work for us. For example, suppose that on a data set which you know to be quite large the command \code{data.frame(x, y, z, monday, tuesday)} never returns. Do not report that \code{data.frame()} fails for large data sets. Perhaps it fails when a variable name is a day of the week. If this is so then when we got your report we would try out the \code{data.frame()} command on a large data set, probably with no day of the week variable name, and not see any problem. There is no way in the world that we could guess that we should try a day of the week variable name. Or perhaps the command fails because the last command you used was a \code{[} method that had a bug causing \R's internal data structures to be corrupted and making the \code{data.frame()} command fail from then on. This is why we need to know what other commands you have typed (or read from your startup file). It is very useful to try and find simple examples that produce apparently the same bug, and somewhat useful to find simple examples that might be expected to produce the bug but actually do not. If you want to debug the problem and find exactly what caused it, that is wonderful. You should still report the facts as well as any explanations or solutions. Invoking \R with the \code{--vanilla} option may help in isolating a bug. This ensures that the site profile and saved data files are not read. On some systems a bug report can be generated using the \code{bug.report()} function. This automatically includes the version information and sends the bug to the correct address. Alternatively the bug report can be emailed to \email{r-bugs@r-project.org} or submitted to the Web page at \url{http://bugs.r-project.org}. } \seealso{R FAQ, \code{link{Sys.mail}} } \author{This help page is adapted from the Emacs manual} \keyword{utilities} \keyword{error} --------------FAC78F7B6BFECAD9BD873458 Content-Type: text/plain; charset=us-ascii; name="Sys.mail.R" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Sys.mail.R" Sys.mail <- function(address = Sys.info()$user, ccaddress = NULL, bccaddress = NULL, subject = NULL, body= "no body", method = getOption("mailer")) { if(!(is.character(address) && nchar(address)>0)) stop("A character string address must be specified.") # The arguments to mail, mailx, and Mail are all the same, but a different # mailer will require that this first part be re-organized under the # specific method. file <- tempfile() on.exit(unlink(file)) cat(body, file=file, append=FALSE, sep="\n") cmdargs <- paste(address, "<", file, "2>/dev/null") if(is.character(ccaddress) && nchar(ccaddress)>0) cmdargs <- paste(" -c '", ccaddress, "' ", cmdargs) if(is.character(bccaddress) && nchar(bccaddress)>0) cmdargs <- paste(" -b '", bccaddress, "' ", cmdargs) if(is.character(subject) && nchar(subject)>0) cmdargs <- paste(" -s '", subject, "' ", cmdargs) status <- 1 if(method == "mailx") status <- system(paste("mailx", cmdargs)) else if(method == "mail") status <- system(paste("mail", cmdargs)) else if(method == "Mail") status <- system(paste("Mail", cmdargs)) else { warning(paste("mail method ", method, " not supported.\n")) return(F) } if(status > 0) { warning(paste("sending email with ", method, " failed.\n")) return(F) } T } --------------FAC78F7B6BFECAD9BD873458 Content-Type: text/plain; charset=us-ascii; name="Sys.mail.Rd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Sys.mail.Rd" \name{Sys.mail} \alias{Sys.mail} \title{Send Mail} \usage{ Sys.mail(address= Sys.info()$user, ccaddress = NULL, bccaddress = NULL, subject = NULL, body= "no body", method = getOption("mailer")) } \arguments{ \item{address}{Recipient's email address. The default is the user name as indicated by \code{Sys.info()$user}, which will correspond to your own email address on many systems.} \item{ccaddress}{Optional email address for copies. Use \code{ccaddress = NULL} for no copies.} \item{bccaddress}{Optional email address for blind copies. Use \code{bccaddress = NULL} for no copies.} \item{subject}{Subject of the email. Please do not use single quotes in the subject!} \item{method}{Submission method, one of \code{"mailx"}, \code{"mail"}, or \code{"Mail"}.} \item{body}{A vector of character, one line per element to place in the body of the email.} } \description{ Use a system mail tool to send a message. Multiple recipients can be specified in any of the addresses by enclosing them in double (\code{"}) quotes. Please do not use single (\code{'}) quotes. The body is a vector of character. Each element of body is written as a line of the message body. } \details{ Currently works only on Unix systems using "mailx", "mail" or "Mail". The mail tool needs to be found on your Unix search path. } \value{TRUE or FALSE indicating success or failure as returned by the operating system. (This does not indicate that the message was received at the address.)} \examples{ \dontrun{Sys.mail(address="friends", subject="R", body="R is great")} } \seealso{\code{link{options}} } \author{Paul Gilbert} \keyword{utilities} --------------FAC78F7B6BFECAD9BD873458-- ==> 1158.audit <== Sat Nov 17 11:59:57 2001 ripley foobar Sat Nov 17 11:59:57 2001 ripley moved from incoming to Misc ==> 1158.followup.1 <== From postmaster@franz.stat.wisc.edu Mon Dec 10 19:37:36 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA01758 for ; Mon, 10 Dec 2001 19:37:35 +0100 (MET) Received: from mailmro2.fmr.com (really [192.223.198.254]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Mon, 10 Dec 2001 12:37:28 -0600 (CST) Received: from virmro110nts.fmr.com (virmro110nts.fmr.com [172.26.5.98]) by mailmro2.fmr.com (Switch-2.2.0/Switch-2.2.0) with SMTP id fBAIaqX07055 for ; Mon, 10 Dec 2001 13:36:52 -0500 (EST) Received: from arbprod.fmr.com (arbproda.fmr.com [155.1.103.75]) by msgbos102nts.fmr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.89) id W0GPQMRB; Mon, 10 Dec 2001 13:36:51 -0500 Received: (from a215020@localhost) by arbprod.fmr.com (8.11.1/8.11.1) id fBAIapl09851; Mon, 10 Dec 2001 13:36:51 -0500 (EST) Date: Mon, 10 Dec 2001 13:36:51 -0500 (EST) From: David Brahm Message-Id: <200112101836.fBAIapl09851@arbprod.fmr.com> Reply-to: brahm@alum.mit.edu To: r-bugs@r-project.org Cc: a215020@arbprod.fmr.com Subject: Re: bug.report() sends empty message (PR#1158) On Oct 22, I sent an empty bug report (#1138) because bug.report() "ate my message". Paul Gilbert opened a new bug report (#1158) for this problem. I'm now convinced it's because I had an apostrophe in the subject line ("round() doesn't"). The bug.report documentation specifically warns against this, but the bug.report() function could also check for it! I suggest adding this line to the bug.report code: if (regexpr("'", subject) > 0) stop("Please, no apostrophe in the subject.") -- David Brahm (brahm@alum.mit.edu) R> getOption("mailer") [1] "mailx" Version: platform = sparc-sun-solaris2.6 arch = sparc os = solaris2.6 system = sparc, solaris2.6 status = major = 1 minor = 3.1 year = 2001 month = 08 day = 31 language = R Search Path: .GlobalEnv, package:misc, package:io, package:arrays, package:ls1, package:g.data, package:db, package:ts, package:ctest, Autoloads, package:base ==> 1158.followup.2 <== From pgilbert@bank-banque-canada.ca Mon Dec 10 20:09:31 2001 Received: from mail1.bank-banque-canada.ca (mail1.bank-banque-canada.ca [140.80.193.130]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA01969 for ; Mon, 10 Dec 2001 20:09:29 +0100 (MET) Received: from fwx-int (fwx-int.bank-banque-canada.ca [140.80.193.129]) by mail1.bank-banque-canada.ca (8.9.3/8.9.3) with SMTP id OAA00487; Mon, 10 Dec 2001 14:04:01 -0500 (EST) Received: from mfa99599.boc by mailhost.bank-banque-canada.ca (8.8.8+Sun/SMI-SVR4) id NAA05366; Mon, 10 Dec 2001 13:53:57 -0500 (EST) Received: from mfa01506.boc (mfa01506 [140.80.3.112]) by mfa99599.boc (8.9.1b+Sun/8.9.1) with ESMTP id NAA29819; Mon, 10 Dec 2001 13:53:56 -0500 (EST) Received: from bank-banque-canada.ca (localhost [127.0.0.1]) by mfa01506.boc (8.9.3+Sun/8.9.3) with ESMTP id NAA09467; Mon, 10 Dec 2001 13:53:53 -0500 (EST) Sender: pgilbert@bank-banque-canada.ca Message-ID: <3C1504C0.1ADC7F0D@bank-banque-canada.ca> Date: Mon, 10 Dec 2001 13:53:52 -0500 From: Paul Gilbert X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: brahm@alum.mit.edu CC: R-bugs@biostat.ku.dk Subject: Re: [Rd] Re: bug.report() sends empty message (PR#1158) References: <200112101837.TAA01768@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit brahm@alum.mit.edu wrote: > On Oct 22, I sent an empty bug report (#1138) because bug.report() >"ate my >message". Paul Gilbert opened a new bug report (#1158) for this >problem. > I'm now convinced it's because I had an apostrophe in the subject >line Your problem may have been due to the apostrophe, but it reminded me of another outstanding problem which I had neglected to report previously: wait=TRUE as in the windows version seems to be necessary with some Unix editors too (e.g. Nedit). Paul Gilbert ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1503 * Subject: R-GNOME From: Patrick Gonin Date: Thu, 2 May 2002 09:29:07 +0200 --1) is not a bug, as jpeg etc work. capabilities() has been changed for 1.5.1 --2) system() needs a new version for GNOME. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1503 <== From gonin@genethon.fr Thu May 2 09:30:07 2002 Received: from diogene.genethon.fr (root@diogene.genethon.fr [193.50.68.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id JAA00984 for ; Thu, 2 May 2002 09:30:06 +0200 (MET DST) Received: (from root@localhost) by diogene.genethon.fr (8.11.5/8.11.5) id g427TSs22721 for r-bugs@biostat.ku.dk; Thu, 2 May 2002 09:29:28 +0200 (MET DST) Received: from [192.168.100.154] (nat0-154.genethon.fr [192.168.100.154]) by diogene.genethon.fr (8.11.5/8.11.5) with ESMTP id g427TOA22697 for ; Thu, 2 May 2002 09:29:24 +0200 (MET DST) Mime-Version: 1.0 X-Sender: gonin@diogene.genethon.fr Message-Id: Date: Thu, 2 May 2002 09:29:07 +0200 To: R-bugs@biostat.ku.dk From: Patrick Gonin Subject: R-GNOME Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id JAA00984 Hi R colleagues, I don't know whether this is a bug, but something weird happen with R-GNOME. Version 1.5.0. I compiled the stuff under i-686 Linux RH 7.2 using ./configure --with-gnome. R can be started with or without the Gnome interface: fine. However, when I start with Gnome interface, jpeg and a few other things are unavailable (checked using capabilities()), whereas everything is available (except Gnome) when I start R without Gnome. Also, some calls seem available with Gnome: system("..") returns nothing. Maybe this is related to the experimental nature of the Gnome interface. Hope that helps. Cheers, -- ---------------------------- Patrick Gonin, DVM, PhD Head of in vivo Evaluation Dept Généthon 1 bis, rue de l'Internationale- BP 60 91002 EVRY CEDEX FRANCE Tel: 33-1-69-47-10-21 Fax: 33-1-60-77-86-98 gonin@genethon.fr ---------------------------- ==> 1503.followup.1 <== From ripley@stats.ox.ac.uk Thu May 2 11:22:18 2002 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id LAA02921 for ; Thu, 2 May 2002 11:22:18 +0200 (MET DST) From: ripley@stats.ox.ac.uk Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.9.0/8.9.0) with ESMTP id KAA23483; Thu, 2 May 2002 10:21:37 +0100 (BST) Date: Thu, 2 May 2002 10:21:37 +0100 (BST) X-X-Sender: To: cc: Subject: Re: [Rd] R-GNOME (PR#1503) In-Reply-To: <200205020730.JAA00989@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by pubhealth.ku.dk id LAA02921 On Thu, 2 May 2002 gonin@genethon.fr wrote: > Hi R colleagues, > > I don't know whether this is a bug, but something weird happen with R-GNOME. > Version 1.5.0. > I compiled the stuff under i-686 Linux RH 7.2 using ./configure --with-gnome. > R can be started with or without the Gnome interface: fine. > However, when I start with Gnome interface, jpeg and a few other > things are unavailable (checked using capabilities()), whereas > everything is available (except Gnome) when I start R without Gnome. Have you actually tried them? capabilities() can be wrong, as it only reports what it is sure about. For me under RH7.2 jpeg(), png() and X11() do all work under R --gui=gnome. (Well, actually gnome has problems with its dialogs as it makes assumptions about the X11 system in use and I am not using XFree86.) I will try to work out a more definitive algorithm for capabilities, but its main use is to test if checks should be run, so it needs to be conservative. And as you note, Gnome is experimental and has a separate maintainer .... > Also, some calls seem available with Gnome: system("..") returns nothing. > Maybe this is related to the experimental nature of the Gnome interface. > Hope that helps. > Cheers, > -- > ---------------------------- > Patrick Gonin, DVM, PhD > Head of in vivo Evaluation Dept > Généthon > 1 bis, rue de l'Internationale- BP 60 > 91002 EVRY CEDEX > FRANCE > Tel: 33-1-69-47-10-21 > Fax: 33-1-60-77-86-98 > gonin@genethon.fr > ---------------------------- > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 ==> 1503.followup.2 <== From plummer@iarc.fr Thu May 2 12:32:14 2002 Received: from smtp01.iarc.fr (IDENT:root@smtp01-193.iarc.fr [193.51.164.211]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA04003 for ; Thu, 2 May 2002 12:32:04 +0200 (MET DST) Received: from xena.iarc.fr ([10.10.150.201]) by smtp01.iarc.fr (8.9.3/8.9.3) with ESMTP id MAA17293; Thu, 2 May 2002 12:30:44 +0200 Message-ID: X-Mailer: XFMail 1.4.7 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200205020922.LAA02927@pubhealth.ku.dk> Date: Thu, 02 May 2002 12:32:10 +0200 (CEST) Organization: International Agency for Research on Cancer Sender: martyn@xena.iarc.fr From: Martyn Plummer To: ripley@stats.ox.ac.uk Subject: Re: [Rd] R-GNOME (PR#1503) Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch On 02-May-2002 ripley@stats.ox.ac.uk wrote: > On Thu, 2 May 2002 gonin@genethon.fr wrote: > >> Hi R colleagues, >> >> I don't know whether this is a bug, but something weird happen with R-GNOME. >> Version 1.5.0. >> I compiled the stuff under i-686 Linux RH 7.2 using ./configure >> --with-gnome. >> R can be started with or without the Gnome interface: fine. >> However, when I start with Gnome interface, jpeg and a few other >> things are unavailable (checked using capabilities()), whereas >> everything is available (except Gnome) when I start R without Gnome. > > Have you actually tried them? capabilities() can be wrong, as it only > reports what it is sure about. For me under RH7.2 jpeg(), png() and X11() > do all work under R --gui=gnome. (Well, actually gnome has problems with > its dialogs as it makes assumptions about the X11 system in use and I am > not using XFree86.) > > I will try to work out a more definitive algorithm for capabilities, but > its main use is to test if checks should be run, so it needs to be > conservative. And as you note, Gnome is experimental and has a separate > maintainer .... jpeg() is available under the GNOME interface and works correctly. >> Also, some calls seem available with Gnome: system("..") returns nothing. >> Maybe this is related to the experimental nature of the Gnome interface. >> Hope that helps. The GNOME port currently uses the same version of do_system as the unix command line port of R. This sends the output of the system call to the standard output. So, for example, if you R-GNOME from a terminal, the output will appear in the terminal and not the R GNOME console. GNOME needs its own version of do_system. I will fix this for R 1.5.1. Martyn ==> 1503.audit <== Tue May 7 09:09:09 2002 ripley changed notes Tue May 7 09:09:09 2002 ripley foobar Tue May 7 09:09:09 2002 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2644 * Subject: R CMD SHLIB uses foo.c instead of foo.cc if both are present From: faheem@email.unc.edu Date: Sun, 16 Mar 2003 19:47:55 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2644 <== From faheem@email.unc.edu Sun Mar 16 19:47:56 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2GIltn9022825 for ; Sun, 16 Mar 2003 19:47:56 +0100 (MET) Date: Sun, 16 Mar 2003 19:47:55 +0100 (MET) Message-Id: <200303161847.h2GIltn9022825@pubhealth.ku.dk> From: faheem@email.unc.edu To: R-bugs@biostat.ku.dk Subject: R CMD SHLIB uses foo.c instead of foo.cc if both are present Full_Name: Faheem Mitha Version: 1.6.2 OS: Debian GNU/Linux Submission from: (NULL) (209.42.199.193) Suppose you are making a shared library using R CMD SHLIB foo.cc If there is a file called foo.c in the same directory, then it will be used instead. faheem ~/scratch/r-base>R CMD SHLIB foo.cc gcc-3.0 -I/usr/lib/R/include -D__NO_MATH_INLINES -mieee-fp -fPIC -g -O2 -c foo.c -o foo.o g++-3.0 -shared -o foo.so foo.o -L/usr/lib/R/bin -lR This has been rather annoying for me, because I sometimes write C and C++ versions of the same program side by side and so the files have the same name except for the extensions. It should be possible to fix it, though I don't understand the relevant scripts enough to suggest a patch. Note this bug has also been reported by me as Debian bug #184969. You can access this report via the web at http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=184969 Faheem. ==> 2644.followup.1 <== From duncan@research.bell-labs.com Sun Mar 16 20:10:11 2003 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2GJAAn9022924 for ; Sun, 16 Mar 2003 20:10:11 +0100 (MET) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h2GJAAN5042506; Sun, 16 Mar 2003 14:10:10 -0500 (EST) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h2GJA3jt001825; Sun, 16 Mar 2003 14:10:03 -0500 (EST) Received: from jessie.research.bell-labs.com (localhost [127.0.0.1]) by jessie.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h2GJA31G027315; Sun, 16 Mar 2003 14:10:03 -0500 (EST) Received: (from duncan@localhost) by jessie.research.bell-labs.com (8.12.8/8.12.8/Submit) id h2GJA287027314; Sun, 16 Mar 2003 14:10:02 -0500 (EST) Date: Sun, 16 Mar 2003 14:10:02 -0500 From: Duncan Temple Lang To: faheem@email.unc.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] R CMD SHLIB uses foo.c instead of foo.cc if both are present (PR#2644) Message-ID: <20030316141002.A26681@jessie.research.bell-labs.com> Mail-Followup-To: Duncan Temple Lang , faheem@email.unc.edu, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk References: <200303161847.h2GIlvn9022829@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303161847.h2GIlvn9022829@pubhealth.ku.dk>; from faheem@email.unc.edu on Sun, Mar 16, 2003 at 07:47:57PM +0100 The "fix" is relatively simple. One can change the order of the suffixes listed in $R_HOME/etc/Makeconf (i.e. the Makeconf.in version) to alter the precedence. If one changes the line .SUFFIXES: .c .cc .cpp .C .d .f .lo .o to place the '.c' after the '.cc', your example will work as you want it. While the behavior is not desirable since you specified foo.cc on the command line for R CMD SHLIB, I don't think it is a good idea to be using files named x.c and x.cc in the same directory. I would think that this will lead to confusions with other tools and I can't think of a context in which it is necessary. D. faheem@email.unc.edu wrote: > Full_Name: Faheem Mitha > Version: 1.6.2 > OS: Debian GNU/Linux > Submission from: (NULL) (209.42.199.193) > > > Suppose you are making a shared library using > > R CMD SHLIB foo.cc > > If there is a file called foo.c in the same directory, then it will be used > instead. > > faheem ~/scratch/r-base>R CMD SHLIB foo.cc > gcc-3.0 -I/usr/lib/R/include -D__NO_MATH_INLINES -mieee-fp -fPIC -g -O2 > -c foo.c -o foo.o > g++-3.0 -shared -o foo.so foo.o -L/usr/lib/R/bin -lR > > This has been rather annoying for me, because I sometimes write C and C++ > versions of the same program side by side and so the files have the same > name except for the extensions. It should be possible to fix it, though I > don't understand the relevant scripts enough to suggest a patch. > > Note this bug has also been reported by me as Debian bug #184969. You can access > > this report via the web at > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=184969 > > Faheem. > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel -- _______________________________________________________________ Duncan Temple Lang duncan@research.bell-labs.com Bell Labs, Lucent Technologies office: (908)582-3217 700 Mountain Avenue, Room 2C-259 fax: (908)582-3340 Murray Hill, NJ 07974-2070 http://cm.bell-labs.com/stat/duncan ==> 2644.audit <== Mon Mar 24 12:48:18 2003 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2645 * Subject: Re: [Rd] R CMD SHLIB uses foo.c instead of foo.cc if both are present From: Faheem Mitha Date: Sun, 16 Mar 2003 15:44:14 -0500 (EST) --part of 2644 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2645 <== From faheem@email.unc.edu Sun Mar 16 21:44:26 2003 Received: from smtp.intrex.net (smtp.intrex.net [209.42.192.250]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2GKiPn9023335 for ; Sun, 16 Mar 2003 21:44:25 +0100 (MET) Received: from Chrestomanci [209.42.199.243] by smtp.intrex.net with ESMTP (SMTPD32-7.13) id A2204A58027A; Sun, 16 Mar 2003 15:44:16 -0500 Received: from faheem (helo=localhost) by Chrestomanci with local-esmtp (Exim 3.36 #1 (Debian)) id 18uezO-0002RM-00; Sun, 16 Mar 2003 15:44:14 -0500 Date: Sun, 16 Mar 2003 15:44:14 -0500 (EST) From: Faheem Mitha X-X-Sender: faheem@Chrestomanci To: Duncan Temple Lang cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] R CMD SHLIB uses foo.c instead of foo.cc if both are present (PR#2644) In-Reply-To: <20030316141002.A26681@jessie.research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Faheem Mitha X-Declude-Sender: faheem@email.unc.edu [209.42.199.243] On Sun, 16 Mar 2003, Duncan Temple Lang wrote: > The "fix" is relatively simple. One can change the order of the > suffixes listed in $R_HOME/etc/Makeconf (i.e. the Makeconf.in version) > to alter the precedence. If one changes the line > > .SUFFIXES: .c .cc .cpp .C .d .f .lo .o > > to place the '.c' after the '.cc', your example will work as you want it. Just to clarify. Is this something that you (ie. R developers) are planning to change, or are you just recommending that I change it? If so, it will break on every upgrade. Wonder if I can put this in Makevars as a local override, though... Hmm. Perhaps using makefiles would be easier, really. > While the behavior is not desirable since you specified foo.cc on the > command line for R CMD SHLIB, I don't think it is a good idea to be > using files named x.c and x.cc in the same directory. I would think > that this will lead to confusions with other tools and I can't think > of a context in which it is necessary. Mmm. Certainly not *necessary*. I still think it is a bug, though. Faheem. ==> 2645.audit <== Mon Mar 24 12:49:14 2003 ripley moved from incoming to Misc Mon Mar 24 12:51:57 2003 ripley changed notes Mon Mar 24 12:51:57 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2648 * Subject: Re: [Rd] R CMD SHLIB uses foo.c instead of foo.cc if both are present From: Kurt Hornik Date: Mon, 17 Mar 2003 21:32:55 +0100 --part of 2644 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2648 <== From hornik@ci.tuwien.ac.at Mon Mar 17 22:35:24 2003 Received: from mr.tuwien.ac.at (mr.tuwien.ac.at [128.130.2.10]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2HLZOn9006311 for ; Mon, 17 Mar 2003 22:35:24 +0100 (MET) Received: from mithrandir.hornik.net (mail@b206-178.dialin.tuwien.ac.at [128.131.206.178]) by mr.tuwien.ac.at (8.12.8/8.12.8) with ESMTP id h2HLZBpa023910; Mon, 17 Mar 2003 22:35:14 +0100 (MET) Received: from hornik by mithrandir.hornik.net with local (Exim 3.36 #1 (Debian)) id 18v1Hz-0002QF-00; Mon, 17 Mar 2003 21:32:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15990.12535.257371.548411@mithrandir.hornik.net> Date: Mon, 17 Mar 2003 21:32:55 +0100 To: faheem@email.unc.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] R CMD SHLIB uses foo.c instead of foo.cc if both are present (PR#2645) In-Reply-To: <200303162044.h2GKiRn9023340@pubhealth.ku.dk> References: <200303162044.h2GKiRn9023340@pubhealth.ku.dk> X-Mailer: VM 7.11 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik X-Virus-Scanned: by amavisd-milter (http://amavis.org/) >>>>> faheem writes: > On Sun, 16 Mar 2003, Duncan Temple Lang wrote: >> The "fix" is relatively simple. One can change the order of the >> suffixes listed in $R_HOME/etc/Makeconf (i.e. the Makeconf.in version) >> to alter the precedence. If one changes the line >> >> .SUFFIXES: .c .cc .cpp .C .d .f .lo .o >> >> to place the '.c' after the '.cc', your example will work as you want it. > Just to clarify. Is this something that you (ie. R developers) are > planning to change, or are you just recommending that I change it? If > so, it will break on every upgrade. Wonder if I can put this in > Makevars as a local override, though... > Hmm. Perhaps using makefiles would be easier, really. It may be possible to work around this from your end using R CMD COMPILE first and then calling R CMD SHLIB only for the linking part. >> While the behavior is not desirable since you specified foo.cc on the >> command line for R CMD SHLIB, I don't think it is a good idea to be >> using files named x.c and x.cc in the same directory. I would think >> that this will lead to confusions with other tools and I can't think >> of a context in which it is necessary. > Mmm. Certainly not *necessary*. I still think it is a bug, though. Actually, if you have foo.c and foo.cc in the same dir and compile these for linking into a shared library they would both compile into foo.o ... -k ==> 2648.audit <== Mon Mar 24 12:49:14 2003 ripley moved from incoming to Misc Mon Mar 24 12:51:45 2003 ripley changed notes Mon Mar 24 12:51:45 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2656 * Subject: recursive default argument reference in debugger From: pburns@pburns.seanet.com Date: Wed, 19 Mar 2003 12:23:40 +0100 (MET) --problem in debugger() ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2656 <== From pburns@pburns.seanet.com Wed Mar 19 12:23:41 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.8/8.12.8) with ESMTP id h2JBNen9026099 for ; Wed, 19 Mar 2003 12:23:41 +0100 (MET) Date: Wed, 19 Mar 2003 12:23:40 +0100 (MET) Message-Id: <200303191123.h2JBNen9026099@pubhealth.ku.dk> From: pburns@pburns.seanet.com To: R-bugs@biostat.ku.dk Subject: recursive default argument reference in debugger Full_Name: Patrick Burns Version: 1.6.1 OS: Linux Submission from: (NULL) (217.35.44.203) # the setup fjj.bd <- function (x, y=x$b[, c("lower", "upper"), drop=FALSE]) { y } jjb0 <- list(b=array(1:3, c(1, 3), list("A", c("", "", "C")))) options(error=dump.frames) # creating the problem > fjj.bd(jjb0) Error in fjj.bd(jjb0) : subscript out of bounds > debugger() Message: Error in fjj.bd(jjb0) : subscript out of bounds Available environments had calls: 1: fjj.bd(jjb0) Enter an environment number, or 0 to exit Selection: 1 Error in get(.obj, envir = dump[[.selection]]) : recursive default argument reference The problem is that "debugger" gets an error when trying to go into the dump. I don't understand what is going on, but it doesn't have to do with the actual names of the objects -- the same thing happens if all the names are changed. This is precisely the same on Linux with 1.6.1 and Windows with 1.6.2. ==> 2656.audit <== Mon Nov 17 08:56:29 2003 ripley changed notes Mon Nov 17 08:56:29 2003 ripley foobar Mon Nov 17 08:56:29 2003 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3646 * Subject: as.POSIXct Bug when used with POSIXlt arg and tz= arg From: Gabor Grothendieck Date: Sun, 3 Aug 2003 20:08:59 -0700 (PDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3646 <== From ggrothendieck@volcanomail.com Mon Aug 4 05:09:15 2003 Received: from omta02.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h7439EJH027254 for ; Mon, 4 Aug 2003 05:09:15 +0200 (MET DST) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta02.mta.everyone.net (Postfix) with ESMTP id 369F919E24; Sun, 3 Aug 2003 20:09:00 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 141494757; Sun, 3 Aug 2003 20:09:00 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Sun, 3 Aug 2003 20:08:59 -0700 (PDT) From: Gabor Grothendieck To: r-bugs@biostat.ku.dk Cc: jerome@hivnet.ubc.ca, p.connolly@hortresearch.co.nz, dmurdoch@pair.com Subject: as.POSIXct Bug when used with POSIXlt arg and tz= arg Reply-To: ggrothendieck@volcanomail.com X-Originating-Ip: [207.35.143.177] Message-Id: <20030804030900.141494757@sitemail.everyone.net> Tracking down this bug was joint work with Jermoe Asselin (jerome at hivnet.ubc.ca) and Patrick Connolly (p.connolly at hortresearch.co.nz). We collectively were able to determine that this is a problem in both Windows 2000 and in Linux and by testing it in our three time zones that it seems to be daylight savings time related. Conversion of POSIXlt datetimes to POSIXct appears to have problems. Consider the following where lt1 and lt2 are both POSIXlt dates that correspond to the same date even though they were created using different statements. Even though lt1 and lt2 represent the same date, as.POSIXct(lt1,tz="") and as.POSIXct(lt2,tz="") differ by one hour. One clue is that the isdst flag is set in lt1 but not in lt2. However, both lt1 and lt2 are GMT dates and either the isdst flag should not be set or at least subsequent processing should not depend on it. Furthermore, even though lt1 is the one that has isdst set I am not entirely sure whether its that one or the other one that gives the wrong answer. > lt1 <- as.POSIXlt("2003-06-01 04:00:00",tz="GMT") > lt1; as.POSIXct(lt1); as.POSIXct(lt1,tz=""); lt1[["isdst"]] [1] "2003-06-01 04:00:00 GMT" [1] "2003-06-01 Eastern Daylight Time" [1] "2003-06-01 04:00:00 Eastern Daylight Time" [1] 1 > lt2 <- as.POSIXlt(as.POSIXct("2003-06-01"),tz="GMT") > lt2; as.POSIXct(lt2); as.POSIXct(lt2,tz=""); lt2[["isdst"]] [1] "2003-06-01 04:00:00 GMT" [1] "2003-06-01 Eastern Daylight Time" [1] "2003-06-01 05:00:00 Eastern Daylight Time" [1] 0 > > paste(R.version) [1] "i386-pc-mingw32" "i386" "mingw32" "i386, mingw32" [5] "" "1" "7.1" "2003" [9] "06" "16" "R" > Sys.timezone() [1] "Eastern Daylight Time" This is not just a Windows problem. Here is the example repeated on Jerome's Linux machine in the Pacific Daylight Time zone. In this case, lt1 and lt2 differ by 3 hours but as.POSIXct(lt1,tz="") and as.POSIXlt(lt2,tz="") differ by 4 hours! Again, I am not sure which one is wrong but they should be the same. The same comment on isdst applies here. > lt1 <- as.POSIXlt("2003-06-01 04:00:00",tz="GMT") > lt1; as.POSIXct(lt1); as.POSIXct(lt1,tz=""); lt1[["isdst"]] [1] "2003-06-01 04:00:00 GMT" [1] "2003-05-31 21:00:00 PDT" [1] "2003-06-01 04:00:00 PDT" [1] 1 > lt2 <- as.POSIXlt(as.POSIXct("2003-06-01"),tz="GMT") > lt2; as.POSIXct(lt2); as.POSIXct(lt2,tz=""); lt2[["isdst"]] [1] "2003-06-01 07:00:00 GMT" [1] "2003-06-01 PDT" [1] "2003-06-01 08:00:00 PDT" [1] 0 > paste(R.version) [1] "i686-pc-linux-gnu" "i686" "linux-gnu" [4] "i686, linux-gnu" "" "1" [7] "7.1" "2003" "06" [10] "16" "R" > Sys.timezone() [1] "" The problem does appear to be daylight savings time related since when run in NZST (which is standard time) Patrick got this. Note that isdst is not set for either lt1 nor lt2. Also lt1 and lt2 are the same number of hours apart as are as.POSIXct(lt1,tz="") and as.POSIXct(lt2,tz=""). They are in the relation expected so they are either both right or both wrong. > lt1 <- as.POSIXlt("2003-06-01 04:00:00",tz="GMT") > lt1; as.POSIXct(lt1); as.POSIXct(lt1,tz=""); lt1[["isdst"]] [1] "2003-06-01 04:00:00 GMT" [1] "2003-06-01 16:00:00 NZST" [1] "2003-06-01 04:00:00 NZST" [1] 0 > lt2 <- as.POSIXlt(as.POSIXct("2003-06-01"),tz="GMT") > lt2; as.POSIXct(lt2); as.POSIXct(lt2,tz=""); lt2[["isdst"]] [1] "2003-05-31 12:00:00 GMT" [1] "2003-06-01 NZST" [1] "2003-05-31 12:00:00 NZST" [1] 0 > paste(R.version) [1] "i686-pc-linux-gnu" "i686" "linux-gnu" [4] "i686, linux-gnu" "" "1" [7] "7.1" "2003" "06" [10] "16" "R" > Sys.timezone() [1] "" _____________________________________________________________ Get your own FREE e-mail account at http://www.volcanomail.com ==> 3646.audit <== Mon Aug 4 17:01:49 2003 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4364 * Subject: Re: [Rd] another dump/source problem? From: Ross Ihaka Date: Wed, 01 Oct 2003 07:45:41 +1200 --dump somehow needs to recognize that expressions in lists --probably need to be enclosed in quote(). -- --S does exactly the same though ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4364 <== From mailnull@stat.math.ethz.ch Tue Sep 30 21:46:14 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8UJkD0P022494 for ; Tue, 30 Sep 2003 21:46:13 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h8UJj5rJ014947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Sep 2003 21:45:07 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.10/8.12.10/Submit) id h8UJj4M7014946 for R-bugs@biostat.ku.dk; Tue, 30 Sep 2003 21:45:04 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h8UJierI014863 for ; Tue, 30 Sep 2003 21:44:40 +0200 (MEST) Received: from bm-4a.paradise.net.nz ([202.0.58.23] helo=linda-4.paradise.net.nz) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 1A4QRL-0000iy-00 for ; Tue, 30 Sep 2003 14:45:43 -0500 Received: from smtp-2.paradise.net.nz (smtp-2a.paradise.net.nz [202.0.32.195]) by linda-4.paradise.net.nz (Paradise.net.nz) with ESMTP id <0HM100BJ8LK3E4@linda-4.paradise.net.nz> for R-bugs@R-project.org; Wed, 01 Oct 2003 07:45:41 +1200 (NZST) Received: from stat.auckland.ac.nz (202-0-45-207.adsl.paradise.net.nz [202.0.45.207]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 5406C9E237; Wed, 01 Oct 2003 07:45:37 +1200 (NZST) Date: Wed, 01 Oct 2003 07:45:41 +1200 From: Ross Ihaka Subject: Re: [Rd] another dump/source problem? In-reply-to: To: Peter Kleiweg Cc: r-devel@stat.math.ethz.ch, R-bugs@R-project.org Message-id: <3F79DD65.3050502@stat.auckland.ac.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807 References: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Peter Kleiweg wrote: > Is this a bug? Yes. If you look inside the saved file it contains ..., call = dist(x = USArrests), ... When this is reread, an attempt is made to evaluate the call. Some kind of quoting is needed. > I do this: > > library(mva) > data(USArrests) > d <- dist(USArrests) > dump("d", "tst") > q() > > I restart R and do this: > > source("tst") > > And I get: > > Error in as.matrix(x) : Object "USArrests" not found -- Ross Ihaka Email: ihaka@stat.auckland.ac.nz Department of Statistics Phone: (64-9) 373-7599 x 85054 University of Auckland Fax: (64-9) 373-7018 Private Bag 92019, Auckland New Zealand ==> 4364.audit <== Sun Nov 9 15:17:38 2003 ripley changed notes Sun Nov 9 15:17:39 2003 ripley foobar Sun Nov 9 15:17:39 2003 ripley moved from incoming to Misc Mon Nov 10 05:20:36 2003 ripley changed notes Mon Nov 10 05:20:36 2003 ripley foobar Thu May 6 13:03:43 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6799 * Subject: Re: [R] Unexpected behaviour of identical From: Peter Dalgaard Date: 20 Apr 2004 13:38:49 +0200 --This case is fixed for 1.9.1. --Whether identical should be so fussy is under consideration. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6799 <== From mail@stat.math.ethz.ch Tue Apr 20 13:42:14 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 8391B104A9 for ; Tue, 20 Apr 2004 13:42:14 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02993-05 for ; Tue, 20 Apr 2004 13:42:14 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 20 Apr 2004 13:42:13 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i3KBgD22010936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Apr 2004 13:42:13 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i3KBgDZO010934 for R-bugs@biostat.ku.dk; Tue, 20 Apr 2004 13:42:13 +0200 Received: from slim.kubism.ku.dk (slim.kubism.ku.dk [192.38.18.21]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i3KBgCD5010917 for ; Tue, 20 Apr 2004 13:42:12 +0200 Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id BF75F1046F; Tue, 20 Apr 2004 13:42:11 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i3KBcoYg007944; Tue, 20 Apr 2004 13:38:50 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i3KBcnQ2007940; Tue, 20 Apr 2004 13:38:49 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: "Swinton, Jonathan" , r-bugs@stat.math.ethz.ch Subject: Re: [R] Unexpected behaviour of identical References: From: Peter Dalgaard Date: 20 Apr 2004 13:38:49 +0200 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) "Swinton, Jonathan" writes: > # works as expected > > ac <- c('A','B'); > > identical(ac,ac[1:2]) > [1] TRUE > > #but > > af <- factor(ac) > > identical(af,af[1:2]) > [1] FALSE > > Any opinions? Did a cross-check with Splus and it doesn't do that , so I think it qualifies as a bug. Shouldn't be too hard to fix (might lose a little efficiencty though). -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6799.followup.1 <== From ripley@stats.ox.ac.uk Tue Apr 20 13:51:48 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 4604F1046B; Tue, 20 Apr 2004 13:51:48 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03070-09; Tue, 20 Apr 2004 13:51:47 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP id B808D1DF4; Tue, 20 Apr 2004 13:51:47 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i3KBpkrt020104; Tue, 20 Apr 2004 12:51:46 +0100 (BST) Date: Tue, 20 Apr 2004 12:51:46 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: p.dalgaard@biostat.ku.dk Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Re: [R] Unexpected behaviour of identical (PR#6799) In-Reply-To: <20040420114244.86AF4104BA@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Tue, 20 Apr 2004 p.dalgaard@biostat.ku.dk wrote: > "Swinton, Jonathan" writes: > > > # works as expected > > > ac <- c('A','B'); > > > identical(ac,ac[1:2]) > > [1] TRUE > > > > #but > > > af <- factor(ac) > > > identical(af,af[1:2]) > > [1] FALSE > > > > Any opinions? > > Did a cross-check with Splus and it doesn't do that , so I think it > qualifies as a bug. Shouldn't be too hard to fix (might lose a little > efficiencty though). No, it comes from > get("[.factor") function (x, i, drop = FALSE) { y <- NextMethod("[") class(y) <- oldClass(x) attr(y, "contrasts") <- attr(x, "contrasts") attr(y, "levels") <- attr(x, "levels") if (drop) factor(y) else y } > attributes(af[1:2, drop=TRUE]) $levels [1] "A" "B" $class [1] "factor" > attributes(af[1:2, drop=FALSE]) $class [1] "factor" $levels [1] "A" "B" and one needs to swap the orders. I am about to commit the change. -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6799.reply.1 <== From p.dalgaard@biostat.ku.dk Tue Apr 20 15:32:12 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 737861050C; Tue, 20 Apr 2004 15:32:12 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i3KDSoYg008234; Tue, 20 Apr 2004 15:28:50 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i3KDSkFQ008230; Tue, 20 Apr 2004 15:28:46 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: Prof Brian Ripley Cc: p.dalgaard@biostat.ku.dk, r-devel@stat.math.ethz.ch, Subject: Re: [Rd] Re: [R] Unexpected behaviour of identical (PR#6799) References: From: Peter Dalgaard Date: 20 Apr 2004 15:28:46 +0200 In-Reply-To: Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Prof Brian Ripley writes: > > No, it comes from > > > get("[.factor") > function (x, i, drop = FALSE) > { > y <- NextMethod("[") > class(y) <- oldClass(x) > attr(y, "contrasts") <- attr(x, "contrasts") > attr(y, "levels") <- attr(x, "levels") > if (drop) > factor(y) > else y > } > > > attributes(af[1:2, drop=TRUE]) > $levels > [1] "A" "B" > > $class > [1] "factor" > > > attributes(af[1:2, drop=FALSE]) > $class > [1] "factor" > > $levels > [1] "A" "B" > > and one needs to swap the orders. I am about to commit the change. I got to about the same spot and started thinking about methods for putting attributes back in the same order that they were found, as in A <- attributes(x) attributes(y) <- A[names(A) %in% c("class","contrasts","levels")] Just swapping the order is probably fine, though. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6799.audit <== Tue Apr 20 19:09:02 2004 ripley changed notes Tue Apr 20 19:09:02 2004 ripley moved from incoming to Misc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Models * PR# 1861 * Subject: update() can not find objects From: yzhou@arcturusag.com Date: Thu, 1 Aug 2002 19:01:59 +0200 (MET DST) --The problem is actually deeper than this. -- --Sometime update() wants to evaluate arguments in the environment where the model --was defined, as here. -- --Sometimes it wants to use the current environment, eg this snippet from MASS --ph.fun <- function(data, i) { -- d <- data -- d$calls <- d$fitted + d$res[i] -- coef(update(fit, data=d)) --} ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1861 <== From yzhou@arcturusag.com Thu Aug 1 19:02:00 2002 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA28213 for ; Thu, 1 Aug 2002 19:01:59 +0200 (MET DST) Date: Thu, 1 Aug 2002 19:01:59 +0200 (MET DST) From: yzhou@arcturusag.com Message-Id: <200208011701.TAA28213@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: update() can not find objects Full_Name: Yi-Xiong Zhou Version: 1.5.1 OS: win2000pro Submission from: (NULL) (64.169.249.42) Update() can not find objects when it is used in a function, which is in turn being called by another function. Here is a R script to show the problem: ######## begin of the test script ########## fun1 <- function() { x <- matrix(rnorm(500), 20,25) y <- rnorm(20) oo <- lm(y~x) print("step 1") update(oo) print("first update success.") fun2(oo) } fun2 <- function(gg) { update(gg) print("second update success.") } fun1() ########### end of the test script ############# Here is the result of running this script: [1] "step 1" [1] "first update success." Error in eval(expr, envir, enclos) : Object "y" not found Ideally, update should first search the objects in its environment first, then its parent's, and grand parent's environments ... Right now, it only searchs its own environment and the global environment, skipping its parents'. ==> 1861.reply.1 <== From p.dalgaard@biostat.ku.dk Thu Aug 1 19:26:45 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA28287; Thu, 1 Aug 2002 19:26:44 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.6/8.11.6) id g71HQaE08765; Thu, 1 Aug 2002 19:26:36 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: yzhou@arcturusag.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: update() can not find objects (PR#1861) References: <200208011702.TAA28218@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 01 Aug 2002 19:26:34 +0200 In-Reply-To: <200208011702.TAA28218@pubhealth.ku.dk> Message-ID: Lines: 67 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii yzhou@arcturusag.com writes: > Full_Name: Yi-Xiong Zhou > Version: 1.5.1 > OS: win2000pro > Submission from: (NULL) (64.169.249.42) > > > Update() can not find objects when it is used in a function, which is in turn > being called by another function. Here is a R script to show the problem: > > ######## begin of the test script ########## > fun1 <- function() { > x <- matrix(rnorm(500), 20,25) > y <- rnorm(20) > oo <- lm(y~x) > print("step 1") > update(oo) > print("first update success.") > fun2(oo) > } > > fun2 <- function(gg) { > update(gg) > print("second update success.") > } > > fun1() > ########### end of the test script ############# > > Here is the result of running this script: > > [1] "step 1" > [1] "first update success." > Error in eval(expr, envir, enclos) : Object "y" not found > > Ideally, update should first search the objects in its environment first, then > its parent's, and grand parent's environments ... Right now, it only searchs its > own environment and the global environment, skipping its parents'. No, that's not what you should expect in a language with lexical scoping. However, there might still be a bug, since update with a non-missing formula argument would extract the formula environment from the formula stored in the lm object, but that doesn't happen if it is missing. Modifying fun2 to function(gg) { update(gg,formula(gg)) print("second update success.") } or even function(gg) { update(gg,y~x) print("second update success.") } does allow your example to run, which is somewhat unexpected... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1861.followup.1 <== From yzhou@arcturusag.com Thu Aug 1 19:58:40 2002 Received: from genome.arcturusag.com (mail.arcturusag.com [64.169.249.254]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA28377; Thu, 1 Aug 2002 19:58:39 +0200 (MET DST) Received: by GENOME with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Aug 2002 10:53:32 -0700 Message-ID: From: Yi-Xiong Zhou To: "'Peter Dalgaard BSA'" Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: RE: update() can not find objects (PR#1861) Date: Thu, 1 Aug 2002 10:53:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Thanks Peter. This does work for formula. However, it failed to a function call. Here is another test script: ################# begin test ############### fun1 <- function() { x <- matrix(rnorm(500), 20,25) oo <- fun3(x) print("step 1") update(oo) print("first update success.") fun2(oo) } fun2 <- function(gg) { update(gg) print("second update success.") } fun3 <- function(aa) { oo <- list(x=aa, call=match.call()) oo } fun1() ############### end test ############ The error message is [1] "step 1" [1] "first update success." Error in fun3(aa = x) : Object "x" not found Yi-Xiong -----Original Message----- From: Peter Dalgaard BSA [mailto:p.dalgaard@biostat.ku.dk] Sent: Thursday, August 01, 2002 10:27 AM To: Yi-Xiong Zhou Cc: r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk Subject: Re: update() can not find objects (PR#1861) yzhou@arcturusag.com writes: > Full_Name: Yi-Xiong Zhou > Version: 1.5.1 > OS: win2000pro > Submission from: (NULL) (64.169.249.42) > > > Update() can not find objects when it is used in a function, which is in turn > being called by another function. Here is a R script to show the problem: > > ######## begin of the test script ########## > fun1 <- function() { > x <- matrix(rnorm(500), 20,25) > y <- rnorm(20) > oo <- lm(y~x) > print("step 1") > update(oo) > print("first update success.") > fun2(oo) > } > > fun2 <- function(gg) { > update(gg) > print("second update success.") > } > > fun1() > ########### end of the test script ############# > > Here is the result of running this script: > > [1] "step 1" > [1] "first update success." > Error in eval(expr, envir, enclos) : Object "y" not found > > Ideally, update should first search the objects in its environment first, then > its parent's, and grand parent's environments ... Right now, it only searchs its > own environment and the global environment, skipping its parents'. No, that's not what you should expect in a language with lexical scoping. However, there might still be a bug, since update with a non-missing formula argument would extract the formula environment from the formula stored in the lm object, but that doesn't happen if it is missing. Modifying fun2 to function(gg) { update(gg,formula(gg)) print("second update success.") } or even function(gg) { update(gg,y~x) print("second update success.") } does allow your example to run, which is somewhat unexpected... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1861.followup.2 <== From tlumley@u.washington.edu Thu Aug 1 21:37:37 2002 Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA28674 for ; Thu, 1 Aug 2002 21:37:36 +0200 (MET DST) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g71Jasej008354 for ; Thu, 1 Aug 2002 12:36:54 -0700 Received: FROM homer26.u.washington.edu BY mailscan-out3.cac.washington.edu ; Thu Aug 01 12:36:52 2002 -0700 Received: from localhost (tlumley@localhost) by homer26.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g71Jap8T071380; Thu, 1 Aug 2002 12:36:51 -0700 Date: Thu, 1 Aug 2002 12:36:51 -0700 (PDT) From: Thomas Lumley To: yzhou@arcturusag.com cc: r-devel@stat.math.ethz.ch, Subject: Re: update() can not find objects (PR#1861) In-Reply-To: <200208011702.TAA28218@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Aug 2002 yzhou@arcturusag.com wrote: > Ideally, update should first search the objects in its environment first, then > its parent's, and grand parent's environments ... Right now, it only searchs its > own environment and the global environment, skipping its parents'. > No, ideally it should search the objects in the environment where the model was defined. There's no guarantee that this is a grandparent, and grandparents shouldn't be searched otherwise. It might be tricky to get this to work. What isn't clear to me is whether the current environment should be searched before the environment where the model was defined or afterwards. -thomas ==> 1861.followup.3 <== From tlumley@u.washington.edu Thu Aug 1 23:14:46 2002 Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA28971 for ; Thu, 1 Aug 2002 23:14:45 +0200 (MET DST) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g71LE4ej008711 for ; Thu, 1 Aug 2002 14:14:04 -0700 Received: FROM homer26.u.washington.edu BY mailscan-out2.cac.washington.edu ; Thu Aug 01 14:14:00 2002 -0700 Received: from localhost (tlumley@localhost) by homer26.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g71LDx4S055014; Thu, 1 Aug 2002 14:14:00 -0700 Date: Thu, 1 Aug 2002 14:13:59 -0700 (PDT) From: Thomas Lumley To: Yi-Xiong Zhou cc: "'Peter Dalgaard BSA'" , , Subject: RE: update() can not find objects (PR#1861) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Aug 2002, Yi-Xiong Zhou wrote: > Thanks Peter. This does work for formula. However, it failed to a function > call. Here is another test script: > > ################# begin test ############### > fun1 <- function() { > x <- matrix(rnorm(500), 20,25) > oo <- fun3(x) > print("step 1") > update(oo) > print("first update success.") > fun2(oo) > } > > fun2 <- function(gg) { > update(gg) > print("second update success.") > } > > fun3 <- function(aa) { > oo <- list(x=aa, call=match.call()) > oo > } > > fun1() > ############### end test ############ > > The error message is > > [1] "step 1" > [1] "first update success." > Error in fun3(aa = x) : Object "x" not found Yes, but this isn't supposed to work, and can't. In the first place update() is supposed to work on models, not on arbitrary objects. In the second place, the object you are returning contains no information about where it was created, so it's not possible for update to work out the correct environment. In this case the correct environment happens to be parent.frame(2), but there's no reason why this should be true in general. When the object is a model with a formula it does carry information about where it was defined, so update() can look there. Your first example should have worked, and the fact that it didn't is a bug (though arguably just a wishlist bug). This new example shouldn't work. -thomas ==> 1861.followup.4 <== From yzhou@arcturusag.com Thu Aug 1 23:25:31 2002 Received: from genome.arcturusag.com (mail.arcturusag.com [64.169.249.254]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA29028; Thu, 1 Aug 2002 23:25:29 +0200 (MET DST) Received: by GENOME with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Aug 2002 14:20:22 -0700 Message-ID: From: Yi-Xiong Zhou To: "'Thomas Lumley'" Cc: "'Peter Dalgaard BSA'" , r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: RE: update() can not find objects (PR#1861) Date: Thu, 1 Aug 2002 14:20:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Could an object carry the information about where it was created? Could that be on the wish list? Yi-Xiong -----Original Message----- From: Thomas Lumley [mailto:tlumley@u.washington.edu] Sent: Thursday, August 01, 2002 2:14 PM To: Yi-Xiong Zhou Cc: 'Peter Dalgaard BSA'; r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk Subject: RE: update() can not find objects (PR#1861) On Thu, 1 Aug 2002, Yi-Xiong Zhou wrote: > Thanks Peter. This does work for formula. However, it failed to a function > call. Here is another test script: > > ################# begin test ############### > fun1 <- function() { > x <- matrix(rnorm(500), 20,25) > oo <- fun3(x) > print("step 1") > update(oo) > print("first update success.") > fun2(oo) > } > > fun2 <- function(gg) { > update(gg) > print("second update success.") > } > > fun3 <- function(aa) { > oo <- list(x=aa, call=match.call()) > oo > } > > fun1() > ############### end test ############ > > The error message is > > [1] "step 1" > [1] "first update success." > Error in fun3(aa = x) : Object "x" not found Yes, but this isn't supposed to work, and can't. In the first place update() is supposed to work on models, not on arbitrary objects. In the second place, the object you are returning contains no information about where it was created, so it's not possible for update to work out the correct environment. In this case the correct environment happens to be parent.frame(2), but there's no reason why this should be true in general. When the object is a model with a formula it does carry information about where it was defined, so update() can look there. Your first example should have worked, and the fact that it didn't is a bug (though arguably just a wishlist bug). This new example shouldn't work. -thomas ==> 1861.audit <== Thu Aug 1 23:00:21 2002 thomas moved from incoming to Models Fri Aug 2 00:01:23 2002 thomas changed notes Fri Aug 2 00:01:23 2002 thomas foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3671 * Subject: model.frame() call from inside a function From: Jerome Asselin Date: Wed, 6 Aug 2003 15:41:16 -0700 --is this a bug? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3671 <== From jerome@hivnet.ubc.ca Thu Aug 7 00:41:49 2003 Received: from hivnet.ubc.ca (mailhost.hivnet.ubc.ca [142.103.173.1]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h76MflJH002128 for ; Thu, 7 Aug 2003 00:41:48 +0200 (MET DST) Received: from there (jeromePC [142.103.177.13]) by hivnet.ubc.ca (8.9.0/8.9.0) with SMTP id PAA06728 for ; Wed, 6 Aug 2003 15:47:50 -0700 (PDT) Message-Id: <200308062247.PAA06728@hivnet.ubc.ca> Content-Type: text/plain; charset="iso-8859-1" From: Jerome Asselin Organization: BC Centre for Excellence in HIV/AIDS To: r-bugs@biostat.ku.dk Subject: model.frame() call from inside a function Date: Wed, 6 Aug 2003 15:41:16 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit R version: 1.7.1 OS: Red Hat Linux 7.2 Hi all, The formula object in model.frame() is not retrieved properly when model.frame() is called from within a function and the "subset" argument is supplied. foo <- function(formula,data,subset=NULL) { cat("\n*****Does formula[-3] == ~y ?**** TRUE *****\n") print(formula[-3] == ~y) cat("\n*****Result of model.frame() using formula[-3]**** FAIL *****\n") print(try(model.frame(formula[-3],data=data,subset=subset))) cat("\n*****Result of model.frame() using ~y**** WORKS *****\n") print(try(model.frame(~y,data=data,subset=subset))) } dat <- data.frame(y=c(5,25)) foo(y~1,dat) Curiously, if the "subset" argument is removed from the call to model.frame(), then the execution is successful in both cases. In ?model.frame, one can read: Variables in the formula, `subset' and in `...' are looked for first in `data' and then in the environment of `formula': see the help for `formula()' for further details. However, replacing the line subset <- eval(substitute(subset), data, env) by subset <- eval(substitute(subset), data, environment()) in model.frame.default() fixes this problem. I don't know if this correction would create more problems in other cases. Perhaps there is a better fix. Sincerely, Jerome Asselin -- Jerome Asselin (Jérôme), Statistical Analyst British Columbia Centre for Excellence in HIV/AIDS St. Paul's Hospital, 608 - 1081 Burrard Street Vancouver, British Columbia, CANADA V6Z 1Y6 Email: jerome@hivnet.ubc.ca Phone: 604 806-9112 Fax: 604 806-9044 ==> 3671.reply.1 <== From p.dalgaard@biostat.ku.dk Thu Aug 7 10:07:18 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h7787HJH005729; Thu, 7 Aug 2003 10:07:17 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h778DP8e021423; Thu, 7 Aug 2003 10:13:25 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h778DO42021419; Thu, 7 Aug 2003 10:13:24 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: jerome@hivnet.ubc.ca Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] model.frame() call from inside a function (PR#3671) References: <200308062241.h76MfoJH002132@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 07 Aug 2003 10:13:24 +0200 In-Reply-To: <200308062241.h76MfoJH002132@pubhealth.ku.dk> Message-ID: Lines: 103 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii jerome@hivnet.ubc.ca writes: > R version: 1.7.1 > OS: Red Hat Linux 7.2 > > Hi all, > > The formula object in model.frame() is not retrieved properly when > model.frame() is called from within a function and the "subset" argument > is supplied. > > foo <- function(formula,data,subset=NULL) > { > cat("\n*****Does formula[-3] == ~y ?**** TRUE *****\n") > print(formula[-3] == ~y) > > cat("\n*****Result of model.frame() using formula[-3]**** FAIL *****\n") > print(try(model.frame(formula[-3],data=data,subset=subset))) > > cat("\n*****Result of model.frame() using ~y**** WORKS *****\n") > print(try(model.frame(~y,data=data,subset=subset))) > } > dat <- data.frame(y=c(5,25)) > foo(y~1,dat) > > Curiously, if the "subset" argument is removed from the call to > model.frame(), then the execution is successful in both cases. > > In ?model.frame, one can read: > Variables in the formula, `subset' and in `...' are looked for > first in `data' and then in the environment of `formula': see the > help for `formula()' for further details. > > However, replacing the line > subset <- eval(substitute(subset), data, env) > by > subset <- eval(substitute(subset), data, environment()) > in model.frame.default() fixes this problem. I don't know if this > correction would create more problems in other cases. Perhaps there is a > better fix. There is really nothing to fix, at least if you go by the rule that it is only a bug if it behaves contrary to documentation: There is no "subset" in the environment of "formula", nor in the "data". If you put one there, the error goes away > subset<-NULL > foo(y~1,dat,subset=1) *****Does formula[-3] == ~y ?**** TRUE ***** [1] TRUE *****Result of model.frame() using formula[-3]**** FAIL ***** y 1 5 2 25 *****Result of model.frame() using ~y**** WORKS ***** y 1 5 However, notice that it is not the same subset. There's a whole area of similar nastiness grouped under the heading of "nonstandard evaluation rules". The basic issue is that you will often assume that the variables used for subsetting comes from the same place as those in the model, e.g. in lm(fat~age,subset=sex=="male"). The problem is that it gets really awkward when a function wants to compute the subset variable and combine it with a formula passed as an argument. And it only gets worse when arguments can be both scalar and vector, e.g. plot(fat~age, col=as.numeric(sex)) function(mycolor="green") plot(fat~age, col=mycolor) We have discussed changing this on several occasions, e.g. by requiring that arguments that need to be evaluated in the formula environment or the data frame should be either model formulas themselves or quoted expressions. However, that would break S-PLUS compatibility and also a large body of existing analysis code. [[ I did discover yesterday (or maybe I was just reminded...) that we even have nonstandard nonstandard evaluation rules in some places (nls() seems to evaluate its model formula in the global environment even if it is given explicitly within a function: f <- function() { g <- function(a,x) exp(-a*x) nls(y~g(a,x),start=list(a=.1)) } x <- 1:10 y <- exp(-.12*x)+rnorm(10,sd=.001) f() Error in eval(expr, envir, enclos) : couldn't find function "g" Argh...]] -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 3671.followup.1 <== From jerome@hivnet.ubc.ca Thu Aug 7 20:17:24 2003 Received: from hivnet.ubc.ca (hivnet.ubc.ca [142.103.173.1]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h77IHMJH013294; Thu, 7 Aug 2003 20:17:22 +0200 (MET DST) Received: from there (jeromePC [142.103.177.13]) by hivnet.ubc.ca (8.9.0/8.9.0) with SMTP id LAA00390; Thu, 7 Aug 2003 11:23:24 -0700 (PDT) Message-Id: <200308071823.LAA00390@hivnet.ubc.ca> Content-Type: text/plain; charset="iso-8859-1" From: Jerome Asselin Organization: BC Centre for Excellence in HIV/AIDS To: Peter Dalgaard BSA Subject: Re: [Rd] model.frame() call from inside a function (PR#3671) Date: Thu, 7 Aug 2003 11:16:48 -0700 X-Mailer: KMail [version 1.3.2] Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk References: <200308062241.h76MfoJH002132@pubhealth.ku.dk> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Thanks for your reply and discussion on the issue. See below for another suggestion of a fix. I have spent some time trying to find a fix which would still work as documented: > Variables in the formula, `subset' and in `...' are looked for > first in `data' and then in the environment of `formula': see the > help for `formula()' for further details. The problem is that the expression environment(formula) in model.frame.default() gives the value: (1) for the call model.frame(formula[-3],data=data,subset=subset) ; (2) (or something alike) for the call model.frame(~y,data=data,subset=subset) . In case (1), eval(subset, data, env) in model.frame.default() gives the subset() function which leads to an error. In the case (2), it gives the correct value for subset (i.e., NULL in the example of my original message). I wonder why the environment is not the same for both cases. Don't you? Perhaps this is where the real problem is, but my current understanding of environment() is too limited to make such a claim. I suggest here another fix which I hope respects the documentation. In model.frame.default(), add the line formula <- formula(deparse(formula)) just before the line env <- environment(formula) This change will affect the value of environment(formula). If you make the correction and run the code below, then it should work successfully. The question is whether this change still respects the documentation. Personally, I think this is safe, because the expression eval(subset, data, env) is still evaluated in the environment of `formula', despite the fact that this environment has changed. Sincerely, Jerome Asselin foo <- function(formula,data,subset=NULL) { cat("\n*****Does formula[-3] == ~y ?**** TRUE *****\n") print(formula[-3] == ~y) cat("\n*****Result of model.frame() using formula[-3]**** FAIL *****\n") print(try(model.frame(formula[-3],data=data,subset=subset))) cat("\n*****Result of model.frame() using ~y**** WORKS *****\n") print(try(model.frame(~y,data=data,subset=subset))) } dat <- data.frame(y=c(5,25)) foo(y~1,dat) foo(y~1,dat,subset=1) ####Results after making the correction### > foo(y~1,dat) *****Does formula[-3] == ~y ?**** TRUE ***** [1] TRUE *****Result of model.frame() using formula[-3]**** FAIL ***** y 1 5 2 25 *****Result of model.frame() using ~y**** WORKS ***** y 1 5 2 25 > foo(y~1,dat,subset=1) *****Does formula[-3] == ~y ?**** TRUE ***** [1] TRUE *****Result of model.frame() using formula[-3]**** FAIL ***** y 1 5 *****Result of model.frame() using ~y**** WORKS ***** y 1 5 ==> 3671.audit <== Wed Aug 27 18:38:07 2003 ripley changed notes Wed Aug 27 18:38:07 2003 ripley foobar Tue Sep 2 08:07:17 2003 ripley foobar Tue Sep 2 08:07:17 2003 ripley moved from incoming to Models ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Startup none Directory: System-specific * PR# 848 * Subject: X11 device doesn't handle destroy events correcly From: Thomas Vogels Date: 13 Feb 2001 17:40:46 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 848 <== From postmaster@franz.stat.wisc.edu Tue Feb 13 23:40:36 2001 Received: from franz.stat.wisc.edu (franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id XAA10552 for ; Tue, 13 Feb 2001 23:40:36 +0100 (MET) Received: from infiniti.ece.cmu.edu (really [128.2.133.84]) by franz.stat.wisc.edu via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Tue, 13 Feb 2001 16:40:47 -0600 (CST) Received: (from tov@localhost) by infiniti.ece.cmu.edu (AIX4.3/UCB 8.8.8/8.8.8) id RAA70658; Tue, 13 Feb 2001 17:40:46 -0500 X-Authentication-Warning: infiniti.ece.cmu.edu: tov set sender to tov@ece.cmu.edu using -f Sender: tov@infiniti.ece.cmu.edu To: r-bugs@r-project.org Cc: Thomas Vogels Subject: X11 device doesn't handle destroy events correcly Reply-To: Thomas Vogels X-URI: http://www.ece.cmu.edu/~tov From: Thomas Vogels Date: 13 Feb 2001 17:40:46 -0500 Message-ID: Lines: 258 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, there are two problems in devX11.c. The one is an undocumented nuisance and the other isn't a bug until you try to embed an X11 device in another window (think tktoplevel() in tcltk package...). Let's take a look at locator() first: Assuming you call locator() with a current X11 device, this call is handled in X11_Locator (src/unix/X11/devX11.c). When you have one window open and call locator, you have three options to quit the locator: click Button 1 (to locate), click Button 2 (to abort), or destroy the window. The later results in the error message: "Error in locator(1) : No graphics device is active". That's OK, sort of. This gets problematic when you open two windows: > x11() # assume that's device 2 > x11() # assume that's device 3 > plot(1) > locator(1) # with device 3 == dev.cur()! When you now destroy device 3 (where locator expects the click), you have *no alternative but to close _all_ windows* to abort the locator. The locator continues to wait for mouse clicks in device 3 where of course no further clicks can come from. That's the nuisance part. The second problem is that the device may try to plot() into a non-existant window. Assume that the window was destroyed by some other part of the program. The device (at some point in the future) will receive a DestroyNotify event that handleEvent ignores. Blissfully! *No KillDevice is called* when the window is destroyed by something other than the WM_DELETE_WINDOW mechanism! This happens when you embed the X11 device into another window/application. For starters, the device no longer receives WM_DELETE_WINDOW client messages. But it does receive a DestroyNotify event when the parent (the container window) is destroyed. HandleEvent should, well _handle_ this _event_. The patch below is a _suggestion_ how to solve both problems. It is against the current r-devel, 1.3, as of 2/13. I believe this behavior exists in version 1.2 as well and can be solved there the same way. The patch is just meant as a convenient and concise way to describe my suggestion. I'd greatly appreciate feedback or other ideas! Implementation: -- the variable inclose is now in the device specific structure (why was it global?) After the window is mapped, inclose is TRUE until the window is destroyed explicitly or a DestroyNotify event has been received. -- the deviceSpecific pointer is set to NULL after the memory has been freed. This (side?) effect is used in X11_Locator to detect the closing of the current device which _must_ lead to an error. -- the if statement to handle events of type DestroyEvent is added to handleEvent -- when the user closes the device (dev.off()), the window is destroyed in X11_Close -- when the user pushes the close button in the window frame, the window is destroyed in handleEvent and X11_Close is initiated (the WM_DELETE_WINDOW mechanism already in place.) -- when the window is destroyed for another reason (e.g. the parent being destroyed), it is not destroyed again but X11_Close is still initiated. Regards, -tom -------------------------------------------------- *** devX11.c_orig Tue Feb 13 15:32:24 2001 --- devX11.c Tue Feb 13 17:24:04 2001 *************** *** 116,121 **** --- 116,122 ---- FILE *fp; /* file for a bitmap device */ int quality; /* JPEG quality */ + Rboolean inclose; /* TRUE if window is being closed */ } x11Desc; *************** *** 145,151 **** static Atom _XA_WM_PROTOCOLS, protocol; static Rboolean displayOpen = FALSE; - static Rboolean inclose = FALSE; static int numX11Devices = 0; /********************************************************/ --- 146,151 ---- *************** *** 619,632 **** xd->windowHeight = event.xconfigure.height; xd->resize = 1; } else if ((event.type == ClientMessage) && ! (event.xclient.message_type == _XA_WM_PROTOCOLS)) ! if (!inclose && event.xclient.data.l[0] == protocol) { ! XFindContext(display, event.xclient.window, devPtrContext, &temp); dd = (DevDesc *) temp; ! KillDevice(dd); } } static void R_ProcessEvents(void *data) --- 619,652 ---- xd->windowHeight = event.xconfigure.height; xd->resize = 1; } + else if (event.type == DestroyNotify) { + /* The window is being destroyed, kill the device, too. */ + XFindContext(display, event.xdestroywindow.window, + devPtrContext, &temp); + dd = (DevDesc *) temp; + xd = (x11Desc *) dd->deviceSpecific; + if (!xd->inclose) { + xd->inclose = TRUE; + KillDevice(dd); + } + } else if ((event.type == ClientMessage) && ! (event.xclient.message_type == _XA_WM_PROTOCOLS)) { ! if (event.xclient.data.l[0] == protocol) { ! XFindContext(display, event.xclient.window, devPtrContext, &temp); dd = (DevDesc *) temp; ! xd = (x11Desc *) dd->deviceSpecific; ! if (!xd->inclose) { ! /* Dispatch destroy only once */ ! xd->inclose = TRUE; ! XDestroyWindow(display, xd->window); ! XSync (display, 0); ! KillDevice(dd); ! } } + } + } static void R_ProcessEvents(void *data) *************** *** 1208,1213 **** --- 1228,1234 ---- ExposureMask | ButtonPressMask | StructureNotifyMask); XMapWindow(display, xd->window); XSync(display, 0); + xd->inclose = FALSE; /* Gobble expose events */ *************** *** 1464,1476 **** x11Desc *xd = (x11Desc *) dd->deviceSpecific; if (xd->type == WINDOW) { ! /* process pending events */ ! /* set block on destroy events */ ! inclose = TRUE; R_ProcessEvents((void*) NULL); XFreeCursor(display, xd->gcursor); - XDestroyWindow(display, xd->window); XSync(display, 0); } else { if (xd->npages && xd->type != XIMAGE) { --- 1485,1506 ---- x11Desc *xd = (x11Desc *) dd->deviceSpecific; if (xd->type == WINDOW) { ! /* There are three reasons to be here: */ ! /* 1) The user clicked on a button in the window frame */ ! /* and we received a DELETE_WINDOW from the wm, */ ! /* 2) Somebody destroyed our window directly, or if */ ! /* embedded, the parent is being destroyed, and so */ ! /* we got a DestroyNotify event, too, */ ! /* 3) The user used dev.off() to get rid of us. Bye. */ ! ! if (!xd->inclose) { ! xd->inclose = TRUE; ! XDestroyWindow(display, xd->window); ! } ! /* process pending events (esp. reap events for this window) */ R_ProcessEvents((void*) NULL); XFreeCursor(display, xd->gcursor); XSync(display, 0); } else { if (xd->npages && xd->type != XIMAGE) { *************** *** 1517,1523 **** } free(xd); ! inclose = FALSE; } /********************************************************/ --- 1547,1553 ---- } free(xd); ! dd->deviceSpecific = NULL; } /********************************************************/ *************** *** 1858,1866 **** else done = 2; } ! } ! else handleEvent(event); } /* if it was a Button1 succeed, otherwise fail */ return (done == 1); --- 1888,1901 ---- else done = 2; } ! } else { handleEvent(event); + if (!dd->deviceSpecific) { + /* Allow new active window to redraw */ + R_ProcessEvents((void*)NULL); + error ("Device closed while waiting for input.\n"); + } + } } /* if it was a Button1 succeed, otherwise fail */ return (done == 1); -------------------------------------------------- --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = Under development (unstable) major = 1 minor = 3.0 year = 2001 month = 02 day = 12 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base -- mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204 ==> 848.followup.1 <== From pd@biostat.ku.dk Wed Feb 14 01:10:35 2001 Received: from biostat.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id BAA10968; Wed, 14 Feb 2001 01:10:34 +0100 (MET) Received: (from pd@localhost) by biostat.ku.dk (8.9.3/8.9.3) id BAA02066; Wed, 14 Feb 2001 01:11:56 +0100 Sender: pd@blueberry.kubism.ku.dk To: tov@ece.cmu.edu Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] X11 device doesn't handle destroy events correcly (PR#848) References: <200102132240.XAA10562@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 14 Feb 2001 01:11:56 +0100 In-Reply-To: tov@ece.cmu.edu's message of "Tue, 13 Feb 2001 23:40:37 +0100 (MET)" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit tov@ece.cmu.edu writes: > Blissfully! *No KillDevice is called* when the window is destroyed by > something other than the WM_DELETE_WINDOW mechanism! This happens > when you embed the X11 device into another window/application. For > starters, the device no longer receives WM_DELETE_WINDOW client > messages. But it does receive a DestroyNotify event when the parent > (the container window) is destroyed. HandleEvent should, well > _handle_ this _event_. Heh. Quite probably, this is also the source of the FVWM trouble reported earlier although that triggered an infinite loop which should probably be guarded against by other means as well. Thanks for filing this (good to have as bug report so that we don't forget - it's the sort of thing that often has to wait until someone has a clear enough mind and sufficient stamina to try and get it right.) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 848.audit <== Sat Feb 17 11:44:41 2001 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1020 * Subject: .Call and Mandrake 8.0 From: lcottret@yahoo.fr Date: Wed, 11 Jul 2001 15:34:23 +0200 (MET DST) --problem with symbol names only on Mandrake 8.0, not 7.2 --needs reply to follow-up ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1020 <== From lcottret@yahoo.fr Wed Jul 11 15:34:24 2001 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id PAA16374 for ; Wed, 11 Jul 2001 15:34:23 +0200 (MET DST) Date: Wed, 11 Jul 2001 15:34:23 +0200 (MET DST) From: lcottret@yahoo.fr Message-Id: <200107111334.PAA16374@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: .Call and Mandrake 8.0 Full_Name: Ludovic Cottret Version: R 1.3.0 OS: Linux Submission from: (NULL) (157.136.20.138) I have a R function which call a C function by the instruction ".Call". The first time I call the R function in a R session, it perfectly runs. But the next times, R returns this error message : Error in .Call("", bankpath, accn, indexpath, key, beg, end) : .Call function name not in load table The function name has disappeared !! This function well runs on Mandrake 7.2 but not in Mandrake 8.0. Why ?!? Thanks for your answers... PS : Excuse my poor english... ==> 1020.followup.1 <== From duncan@jessie.research.bell-labs.com Wed Jul 11 16:15:16 2001 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by pubhealth.ku.dk (8.9.3/8.9.1) with SMTP id QAA16686 for ; Wed, 11 Jul 2001 16:15:15 +0200 (MET DST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Wed Jul 11 10:10:04 EDT 2001 Received: from jessie.research.bell-labs.com ([135.104.13.5]) by scummy; Wed Jul 11 10:13:33 EDT 2001 Received: (from duncan@localhost) by jessie.research.bell-labs.com (8.9.1/8.9.1) id KAA02731; Wed, 11 Jul 2001 10:13:07 -0400 (EDT) Date: Wed, 11 Jul 2001 10:13:07 -0400 From: Duncan Temple Lang To: lcottret@yahoo.fr Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] .Call and Mandrake 8.0 (PR#1020) Message-ID: <20010711101307.E24919@jessie.research.bell-labs.com> Mail-Followup-To: lcottret@yahoo.fr, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk References: <200107111334.PAA16384@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200107111334.PAA16384@pubhealth.ku.dk>; from lcottret@yahoo.fr on Wed, Jul 11, 2001 at 03:34:25PM +0200 Hi Ludovic. There are at least two possible explanations for this behaviour. 1) There is a bug in the recently changed code in R to find routines in C and Fortran libraries. 2) The routine that you are .Call()'ing is doing something that has confused the R internals and makes the next R commands not work, and potentially this is not reproducible. If this is not proprietary or confidential code, you can send the C code and instructions as to how to call it from R (that is, provide simple values for the bankpath, accn, indexpath, key, beg and end arguments), then I can see if the computations are potentially writing over other values in memory. Also, you can try a invoking a very simple .Call() routine many times to see if that displays the same failure. For example, put the following C code in a file named simpleCall.c #include "Rinternals.h" SEXP simpleCall() { static int count = 0; SEXP ans; PROTECT(ans = allocVector(INTSXP, 1)); INTEGER(ans)[0] = count++; UNPROTECT(1); return(ans); } Then, compile this with R CMD SHLIB simpleCall.c and call it from R in the following way > dyn.load("simpleCall.so") > for(i in 1:10) { print(.Call("simpleCall")) } If this works, it won't determine whether it is 1) or 2) (or any other possible reason), but if it doesn't work, we will have a lot more information. Thanks, Duncan lcottret@yahoo.fr wrote: > Full_Name: Ludovic Cottret > Version: R 1.3.0 > OS: Linux > Submission from: (NULL) (157.136.20.138) > > > I have a R function which call a C function by the instruction ".Call". > The first time I call the R function in a R session, it perfectly runs. But the > next > times, R returns this error message : > > Error in .Call("", bankpath, accn, indexpath, key, beg, end) : > .Call function name not in load table > > The function name has disappeared !! > This function well runs on Mandrake 7.2 but not in Mandrake 8.0. Why ?!? > > Thanks for your answers... > PS : Excuse my poor english... > > > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ -- _______________________________________________________________ Duncan Temple Lang duncan@research.bell-labs.com Bell Labs, Lucent Technologies office: (908)582-3217 700 Mountain Avenue, Room 2C-259 fax: (908)582-3340 Murray Hill, NJ 07974-2070 http://cm.bell-labs.com/stat/duncan ==> 1020.audit <== Fri Aug 3 11:33:04 2001 ripley changed notes Fri Aug 3 11:33:04 2001 ripley foobar Fri Aug 3 11:33:04 2001 ripley moved from incoming to System-specific Tue Aug 7 08:37:20 2001 ripley changed notes Tue Aug 7 08:37:20 2001 ripley foobar ==> 1020.followup.2 <== From mikalzet@libero.it Fri Dec 7 12:44:05 2001 Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA07110 for ; Fri, 7 Dec 2001 12:44:04 +0100 (MET) From: mikalzet@libero.it Received: from localhost.localdomain (151.25.109.136) by smtp3.libero.it (6.0.032) id 3BD43E2500FA2042 for r-bugs@biostat.ku.dk; Fri, 7 Dec 2001 12:43:26 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 477AB1D9C for ; Fri, 7 Dec 2001 12:43:25 +0100 (CET) Date: Fri, 7 Dec 2001 12:43:25 +0100 (CET) X-X-Sender: To: Subject: bug PR#1020 Message-ID: Return-Receipt-To: mikalzet@libero.it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Found it on the site. I tried duncan's suggestion. #include "Rinternals.h" SEXP simpleCall() { static int count = 0; SEXP ans; PROTECT(ans = allocVector(INTSXP, 1)); INTEGER(ans)[0] = count++; UNPROTECT(1); return(ans); } If I had read this before I could have checked on mandrake 8.0 Here is my output on mandrake 8.1: > dyn.load("simpleCall.so") > for(i in 1:10) { print(.Call("simpleCall")) } [1] 0 [1] 1 [1] 2 [1] 3 [1] 4 [1] 5 [1] 6 [1] 7 [1] 8 [1] 9 for(i in 1:10) { print(.Call("simpleCall")) } [1] 10 [1] 11 [1] 12 [1] 13 [1] 14 [1] 15 [1] 16 [1] 17 [1] 18 [1] 19 > for(i in 1:10) { print(.Call("simpleCall")) } [1] 20 [1] 21 [1] 22 [1] 23 [1] 24 [1] 25 [1] 26 [1] 27 [1] 28 [1] 29 Seems ok ? -- Michele Alzetta ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1097 * Subject: R 1.3.1 fails 'make check' on arm in the Bessel example From: Dirk Eddelbuettel Date: Thu, 20 Sep 2001 23:54:19 -0500 --This platform turned out to have badly broken FPU behaviour. Given up, at --least for now . ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1097 <== From postmaster@franz.stat.wisc.edu Fri Sep 21 06:54:31 2001 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id GAA13162 for ; Fri, 21 Sep 2001 06:54:30 +0200 (MET DST) Received: from sonny.eddelbuettel.com (really [64.195.36.229]) by franz.stat.wisc.edu via smail with esmtp (ident mail using rfc1413) id (Debian Smail3.2.0.111) for ; Thu, 20 Sep 2001 23:54:27 -0500 (CDT) Received: from edd by sonny.eddelbuettel.com with local (Exim 3.32 #1 (Debian)) id 15kIKS-0005EK-00 for ; Thu, 20 Sep 2001 23:54:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15274.51195.688109.743960@sonny.eddelbuettel.com> Date: Thu, 20 Sep 2001 23:54:19 -0500 To: r-bugs@r-project.org Subject: R 1.3.1 fails 'make check' on arm in the Bessel example X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid From: Dirk Eddelbuettel Debian tries to build its packages on a variety of platforms. The arm platform compiled 0.90.1 (the last Debian release before the Debian package required an Atlas library, something we no longer require) failed in 'make check'. The log snippet follows; I traced this to the example(Bessel) code. > matplot(nu, t(outer(xx,nu, besselI)), type = 'l', ylim = c(-50,200), + main = expression(paste("Bessel ",I[nu](x)," for fixed ", x, + ", as ",f(nu))), + xlab = expression(nu)) Error in title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) : Metric information not yet available for this device In addition: Warning messages: 1: Nonfinite axis limits [GScale(nan,nan,1, .); log=0] 2: relative range of values = 9.0072e+15 * EPS, is small (axis 1). 3: Nonfinite axis limits [GScale(-inf,inf,2, .); log=0] 4: relative range of values = 9.0072e+15 * EPS, is small (axis 2). Execution halted Casual inspection suggests that GScale(nan,nan,1, .) is probably incorrect. Now, src/nmath/bessel* provide the Bessel functions but does this reflect a potential libc bug in IEEE handling? I have also asked on the debian-arm mailing list, but no result so far. I have some access to an arm box and could compile small test cases if that helped. Dirk --please do not edit the information below-- Version: platform = i386-pc-linux-gnu arch = i386 os = linux-gnu system = i386, linux-gnu status = major = 1 minor = 3.1 year = 2001 month = 08 day = 31 language = R Search Path: .GlobalEnv, package:ctest, Autoloads, package:base -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey ==> 1097.audit <== Fri Sep 21 07:46:37 2001 ripley moved from incoming to System-specific Fri Jun 14 18:10:49 2002 pd changed notes Fri Jun 14 18:10:49 2002 pd foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1261 * Subject: R_140 AND RHL_72 AND Packages From: Patrick Gonin Date: Wed, 15 Jan 2003 13:25:17 +0100 --Seems to relate to RH7.2 rpms ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1261 <== From gonin@genethon.fr Tue Jan 15 13:25:52 2002 Received: from sansgene.genethon.fr (root@sansgene.genethon.fr [193.50.68.15]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id NAA28694 for ; Tue, 15 Jan 2002 13:25:51 +0100 (MET) Received: from [192.168.100.154] (nat0-154.genethon.fr [192.168.100.154]) by sansgene.genethon.fr (8.11.5/8.11.5) with ESMTP id g0FCPKT28309 for ; Tue, 15 Jan 2002 13:25:20 +0100 (MET) Mime-Version: 1.0 X-Sender: gonin@sansgene.genethon.fr Message-Id: Date: Wed, 15 Jan 2003 13:25:17 +0100 To: r-bugs@biostat.ku.dk From: Patrick Gonin Subject: R_140 AND RHL_72 AND Packages Content-Type: text/plain; charset="us-ascii" ; format="flowed" Dear colleagues, >I use R under RH Linux 7.2 on a i686 PIII 733 machine. I have a problem to install packages since R 1.4.0 has been installed. >I have determined that whenever I install whichever package, the >installation (CMD INSTALL command) fail at finding R files, and at >finding all html,and other help files. >However, it ends up with DONE INSTALL, and when you type >library(XXX) under R, there is no error. But it is like loading an >empty nutshell: no R function available, no help page available >(apart from the 00Index.html file).The only functional call is >always library(help=search) which displays all functions and >datasets of the package (the INDEX file, in fact). When looking at >the directories of the package, you find that only one file remains, >all other have disappeared (while they were there after tar). I have also tried R CMD check which runs correctly and finds all files. >The next test I did was desinstalling R 1.4.0, and reinstalling R >1.3.1, which led to no correction whatsoever (while before >installing R 1.4.0, there were no problem at all with R 1.3.1). >Back with R 1.4.0, I am baffled, since it is like if the first >installation of R 1.4.0 had changed something to my Linux box. >Last important element: some while ago, when I installed 15 packages >under RH 7.2 with R 1.3.1, everything worked OK. Moreover, for >upgrading to RH 7.2, I realised a new installation from scratch >after backup of all important data. >Maybe I should also say that I install and desinstall R-base and >R-recommended using rpm files with gno-rpm. Couldn't it be a general problem with the new binaries of R 1.4.0 and RH 7.2? Any hint welcome, of course, because I have spend many many hours to try to fix that. Best regards, -- ---------------------------- Patrick Gonin, DVM, PhD Head of in vivo Evaluation Dept GENETHON III 1 bis, rue de l'Internationale BP 60 91002 EVRY CEDEX FRANCE Tel: 33-1-69-47-10-21 Fax: 33-1-60-77-86-98 gonin@genethon.fr ---------------------------- ==> 1261.audit <== Fri Jan 18 09:14:36 2002 ripley changed notes Fri Jan 18 09:14:36 2002 ripley foobar Fri Jan 18 09:14:36 2002 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1272 * Subject: eigen segfault with GCC 3 on Solaris From: Paul Gilbert Date: Thu, 17 Jan 2002 15:14:33 -0500 --Seems to be a problem with g77 in gcc 3.0.2 on Solaris only. --Probably a compiler bug ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1272 <== From pgilbert@bank-banque-canada.ca Thu Jan 17 21:26:12 2002 Received: from mail1.bank-banque-canada.ca (mail1.bank-banque-canada.ca [140.80.193.130]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA03042 for ; Thu, 17 Jan 2002 21:26:11 +0100 (MET) Received: from fwx-int (fwx-int.bank-banque-canada.ca [140.80.193.129]) by mail1.bank-banque-canada.ca (8.9.3/8.9.3) with SMTP id PAA12351 for ; Thu, 17 Jan 2002 15:14:51 -0500 (EST) Received: from mfa99599.boc by mailhost.bank-banque-canada.ca (8.8.8+Sun/SMI-SVR4) id PAA12589; Thu, 17 Jan 2002 15:14:36 -0500 (EST) Received: from mfa01506.boc (mfa01506 [140.80.3.112]) by mfa99599.boc (8.9.1b+Sun/8.9.1) with ESMTP id PAA22347 for ; Thu, 17 Jan 2002 15:14:35 -0500 (EST) Received: from bank-banque-canada.ca (localhost [127.0.0.1]) by mfa01506.boc (8.9.3+Sun/8.9.3) with ESMTP id PAA21692 for ; Thu, 17 Jan 2002 15:14:33 -0500 (EST) Sender: pgilbert@bank-banque-canada.ca Message-ID: <3C4730A9.2F4818FA@bank-banque-canada.ca> Date: Thu, 17 Jan 2002 15:14:33 -0500 From: Paul Gilbert X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: R-bugs Subject: eigen segfault with GCC 3 on Solaris Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A message this morning reminded me of a previous problem I had which should be noted in R bugs, but is really a problem with gcc 3 I believe. It may be only a problem on Solaris, but AFAIK has not been checked on other platforms. I resolved it by going back to a gcc 2.9x.x (which a few people suggested). Below is the relevant part of my original post, an example which provokes the segfault, and some gdb information from Peter Dalgaard. PG>I have now tested R 1.3.1 compiled with GCC 3.0.2 on Solaris and the example I PG>previously posted (repeated below) still gives a segmentation fault, as it does PG>with GCC 3.0.1 but not with 2.95.2. The eigen calculation sometimes needs to be PG> repeated several times before the segmentation fault occurs. La.eigen does not PG> cause a problem. (The problem occurred with R-devel too, but I have not tested PG> that with GCC 3.0.2.) PD>I don't know if it helps, but I see it too... 3.0.1 on Solaris 2.7. PD> PD>gdb says that it is happening at l.2144 of eigen.f: PD> PD>2142 C PD>2143 DO 760 J = M, EN PD>2144 RA = RA + H(I,J) * H(J,NA) PD>2145 SA = SA + H(I,J) * H(J,EN) PD>2146 760 CONTINUE PD>2147 C PD> PD>J prints as 7289784 for me, which looks a bit weird since M and EN are PD>17 and 18 respectively. However, optimizers sometimes cause this sort PD>of thing. ----- example ----- zz <- t(matrix(c( 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.082008166, -0.066322053, -0.115616348, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.038919428, 0.009703382, 0.115944209, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.007823026, -0.068859673, 0.025264756, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.067027108, 0.087934957, -0.316974768, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.024890008, 0.052195412, -0.015138322, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.028192857, -0.004832597, 0.207879665, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.078706928, -0.012801413, 0.425960682, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.102169750, 0.163238356, -0.150373125, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.002685166, 0.014355904, 0.197912183, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0.042937314, 0.115719388, 0.679370293, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0.032306141, 0.263227910, 0.009171148, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0.008238734, -0.031480706, 0.051976566, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0.015219148, 0.221345314, 0.020146770, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0.039741608, 0.092955553, -0.262550823, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0.012624418, 0.047810873, 0.201673308, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, -0.114163303, 0.417786916, 0.253110874, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0.049894329, -0.155696562, -0.049735728, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0.006112607, 0.074242237, 0.034046467 ), 18,18)) eigen(zz)$values eigen(zz)$values eigen(zz)$values eigen(zz)$values eigen(zz)$values eigen(zz)$values eigen(zz)$values eigen(zz)$values Segmentation Fault - core dumped ==> 1272.audit <== Fri Jan 18 09:10:34 2002 ripley changed notes Fri Jan 18 09:10:34 2002 ripley foobar Fri Jan 18 09:10:34 2002 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1275 * Subject: compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a) From: Walter Tautz Date: Tue, 22 Jan 2002 10:05:20 -0500 (EST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1275 <== From wtautz@math.uwaterloo.ca Tue Jan 22 16:05:53 2002 Received: from mfcf.math.uwaterloo.ca (wtautz@mfcf.math.uwaterloo.ca [129.97.216.156]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA20264 for ; Tue, 22 Jan 2002 16:05:52 +0100 (MET) Received: from localhost (wtautz@localhost) by mfcf.math.uwaterloo.ca (8.9.3/8.9.3) with SMTP id KAA12752; Tue, 22 Jan 2002 10:05:20 -0500 (EST) X-Authentication-Warning: mfcf.math: wtautz owned process doing -bs Date: Tue, 22 Jan 2002 10:05:20 -0500 (EST) From: Walter Tautz Reply-To: Walter Tautz To: r-bugs@biostat.ku.dk cc: Walter Tautz Subject: compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have included the full configure/make output: (the particular error regarding bessel_i.c is at the END of the report). -walter tautz cd build/R-1.4.0 \ && unset noclobber \ && CPPFLAGS=" " \ LDFLAGS="" \ ./configure --prefix=/software/r-1 \ --datadir=/software/r-1/data \ --libdir=/software/r-1/lib \ --includedir=/software/r-1/include \ --with-x \ \ \ | tee configure.XHIER.log 2>&1 \ && touch XHIER_CONFIGURED creating cache ./config.cache checking for a BSD compatible install... tools/install-sh -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking host system type... mips-sgi-irix6.5 loading site script ./config.site loading build specific script ./config.site checking for pwd... /sbin/pwd checking whether builddir is srcdir... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking whether gcc needs -traditional... no checking whether gcc accepts -M for generating dependencies... yes checking whether gcc supports -c -o FILE.lo... yes checking for mawk... no checking for gawk... no checking for nawk... nawk checking whether ln -s works... yes checking for ranlib... : checking for bison... bison -y checking for ar... ar checking whether echo can suppress newlines... yes configure: warning: redefining INSTALL to be /scratch/usr/source/r-1/build/R-1.4.0/tools/install-sh -c checking for javac... no checking for less... /.software/local/.admin/bins/bin/less checking for perl... /.software/local/.admin/bins/bin/perl checking whether perl version is at least 5.004... yes checking for dvips... no checking for tex... configure: warning: you cannot build DVI versions of the R manuals configure: warning: you cannot build PDF versions of the R manuals no checking for latex... no checking for makeindex... no checking for pdftex... no checking for pdflatex... no checking for makeinfo... /.software/local/.admin/bins/bin/makeinfo checking for unzip... no checking for zip... no checking for Cygwin environment... no checking for mingw32 environment... no checking build system type... mips-sgi-irix6.5 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependant libraries... pass_all checking for object suffix... o checking for executable suffix... no checking command to parse /usr/bin/nm -B output... ok checking for dlfcn.h... yes checking for ranlib... (cached) : checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... none checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld -64) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking dynamic linker characteristics... irix6.5 ld.so checking if libtool supports shared libraries... yes checking whether -lc should be explicitly linked in... yes creating libtool checking whether makeinfo version is at least 4... yes checking for main in -lm... yes defining F77 to be g77 checking whether the Fortran 77 compiler (g77 ) works... yes checking whether the Fortran 77 compiler (g77 ) is a cross-compiler... no checking whether we are using GNU Fortran 77... yes checking whether g77 accepts -g... yes checking for Fortran 77 libraries... -lg2c -lm -L/.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/mabi=64 -L/.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3 -L/usr/bin -L/.software/arch/gcc-2.95.3/dis tribution/lib/mabi=64 -L/.software/arch/gcc-2.95.3/distribution/lib -lm -L/usr/lib64/mips3 -L/usr/lib64 checking whether g77 appends underscores... yes checking whether g77 and gcc agree on int and double... yes checking whether g77 and gcc agree on double complex... yes checking whether g77 supports -c -o FILE.lo... yes checking for c++... g++ checking whether the C++ compiler (g++ ) works... yes checking whether the C++ compiler (g++ ) is a cross-compiler... no checking whether we are using GNU C++... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking whether g++ accepts -M for generating dependencies... yes checking whether g++ supports -c -o FILE.lo... yes checking for sin in -lm... yes checking for sin in -lmoto... no checking for main in -lncurses... no checking for main in -ltermcap... yes checking for dlopen in -ldl... no checking for ATL_xerbla in -latlas... no checking for zherk in -lblas... no checking for dgemm_ in -lblas... yes checking for rl_callback_read_char in -lreadline... no checking for working alloca.h... yes checking for alloca... yes checking for ANSI C header files... yes checking for pid_t... yes checking for vfork.h... no checking for working vfork... no checking for vprintf... yes checking for access... yes checking for acosh... yes checking for asinh... yes checking for atanh... yes checking for bcopy... yes checking for bzero... yes checking for finite... yes checking for ftruncate... yes checking for getcwd... yes checking for getgrgid... yes checking for getpwuid... yes checking for getuid... yes checking for hypot... yes checking for isascii... yes checking for isnan... yes checking for matherr... no checking for memcpy... yes checking for memmove... yes checking for mempcpy... no checking for mkfifo... yes checking for popen... yes checking for putenv... yes checking for rint... yes checking for setenv... no checking for snprintf... yes checking for strcoll... yes checking for stat... yes checking for strptime... yes checking for system... yes checking for times... yes checking for unsetenv... no checking for vsnprintf... yes checking for strdup... yes checking for library containing connect... none required checking for library containing gethostbyname... none required checking for library containing xdr_string... none required checking for __setfpucw... no checking for working calloc... yes checking for working finite... yes checking for working log... yes checking for working strptime... no checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for sys/wait.h that is POSIX.1 compatible... yes checking for arpa/inet.h... yes checking for dl.h... no checking for dlfcn.h... (cached) yes checking for elf.h... yes checking for errno.h... yes checking for fcntl.h... yes checking for floatingpoint.h... no checking for fpu_control.h... no checking for grp.h... yes checking for ieee754.h... no checking for ieeefp.h... yes checking for locale.h... yes checking for netdb.h... yes checking for netinet/in.h... yes checking for pwd.h... yes checking for readline/history.h... yes checking for readline/readline.h... yes checking for rpc/xdr.h... yes checking for string.h... yes checking for strings.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/stat.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/utsname.h... yes checking for unistd.h... yes checking whether setjmp.h is POSIX.1 compatible... yes checking for GNU C library with version >= 2... no checking whether math.h defines isfinite... no checking whether math.h defines isnan... no checking return type of signal handlers... void checking for pid_t... (cached) yes checking for size_t... yes checking for blkcnt_t... yes checking for sys/socket.h... (cached) yes checking for type of socket length... size_t * checking whether byte ordering is bigendian... yes checking for working const... yes checking size of int... 4 checking size of long... 8 checking size of long long... 8 checking size of long double... 8 checking whether C compiler needs -OPT:IEEE_NaN_inf=ON... no checking for xmkmf... /usr/bin/X11/xmkmf checking for X... libraries , headers checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for tclConfig.sh... no checking for tkConfig.sh... no checking for tcl.h... no checking for finite... (cached) yes checking for isnan... (cached) yes checking whether you have IEEE 754 floating-point arithmetic... yes checking for BSD networking... yes checking for jpeglib.h... yes checking if jpeglib version >= 6b... no checking for main in -lz... yes checking for png.h... yes checking if libpng version >= 1.0.5... no checking for XDR support... yes checking for gzopen in -lz... yes checking for zlib.h... yes checking if zlib version >= 1.1.3... no checking whether leap seconds are treated according to POSIX... yes checking for setitimer... yes checking for lpr... lpr checking for paperconf... false updating cache ./config.cache creating ./config.status creating Makeconf creating Makefile creating afm/Makefile creating doc/Makefile creating doc/html/Makefile creating doc/html/search/Makefile creating doc/manual/Makefile creating etc/Makefile creating etc/Makeconf creating etc/Renviron creating m4/Makefile creating share/Makefile creating src/Makefile creating src/appl/Makefile creating src/include/Makefile creating src/include/R_ext/Makefile creating src/library/Makefile creating src/library/base/DESCRIPTION creating src/library/base/Makefile creating src/library/profile/Makefile creating src/library/ctest/DESCRIPTION creating src/library/ctest/Makefile creating src/library/ctest/src/Makefile creating src/library/eda/DESCRIPTION creating src/library/eda/Makefile creating src/library/eda/src/Makefile creating src/library/lqs/DESCRIPTION creating src/library/lqs/Makefile creating src/library/lqs/src/Makefile creating src/library/methods/DESCRIPTION creating src/library/methods/Makefile creating src/library/methods/src/Makefile creating src/library/modreg/DESCRIPTION creating src/library/modreg/Makefile creating src/library/modreg/src/Makefile creating src/library/mva/DESCRIPTION creating src/library/mva/Makefile creating src/library/mva/src/Makefile creating src/library/nls/DESCRIPTION creating src/library/nls/Makefile creating src/library/nls/src/Makefile creating src/library/stepfun/DESCRIPTION creating src/library/stepfun/Makefile creating src/library/splines/DESCRIPTION creating src/library/splines/Makefile creating src/library/splines/src/Makefile creating src/library/tcltk/DESCRIPTION creating src/library/tcltk/Makefile creating src/library/tcltk/src/Makefile creating src/library/tools/DESCRIPTION creating src/library/tools/Makefile creating src/library/ts/DESCRIPTION creating src/library/ts/Makefile creating src/library/ts/src/Makefile creating src/main/Makefile creating src/modules/Makefile creating src/modules/X11/Makefile creating src/modules/gnome/Makefile creating src/modules/internet/Makefile creating src/modules/lapack/Makefile creating src/modules/vfonts/Makefile creating src/nmath/Makefile creating src/nmath/standalone/Makefile creating src/scripts/Makefile creating src/scripts/COMPILE creating src/scripts/INSTALL creating src/scripts/REMOVE creating src/scripts/R.sh creating src/scripts/Rdconv creating src/scripts/Rdindex creating src/scripts/Rprof creating src/scripts/SHLIB creating src/scripts/Sd2Rd creating src/scripts/build creating src/scripts/check creating src/unix/Makefile creating tests/Makefile creating tests/Embedding/Makefile creating tests/Examples/Makefile creating tools/Makefile creating src/include/config.h configure: warning: you cannot build DVI versions of the R manuals configure: warning: you cannot build PDF versions of the R manuals R is now configured for mips-sgi-irix6.5 Source directory: . Installation directory: /software/r-1 C compiler: gcc -g -O2 C++ compiler: g++ -g -O2 FORTRAN compiler: g77 -g -O2 X11 support: yes Gnome support: no Tcl/Tk support: no R profiling support: yes R as a shared library: no cd build/R-1.4.0 \ && make all \ && touch XHIER_BUILT creating src/scripts/R.fe mkdir ../../bin mkdir ../../include mkdir ../../../include/R_ext making approx.d from approx.c making bakslv.d from bakslv.c making bandwidths.d from bandwidths.c making binning.d from binning.c making chull.d from chull.c making cpoly.d from cpoly.c making cumsum.d from cumsum.c making fft.d from fft.c making fmin.d from fmin.c making integrate.d from integrate.c making lbfgsb.d from lbfgsb.c making loglin.d from loglin.c making lowess.d from lowess.c making machar.d from machar.c making maxcol.d from maxcol.c making massdist.d from massdist.c making pretty.d from pretty.c making rowsum.d from rowsum.c making splines.d from splines.c making stem.d from stem.c making strsignif.d from strsignif.c making tabulate.d from tabulate.c making uncmin.d from uncmin.c making zeroin.d from zeroin.c gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c approx.c -o approx.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c bakslv.c -o bakslv.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c bandwidths.c -o bandwidths.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c binning.c -o binning.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c chull.c -o chull.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c cpoly.c -o cpoly.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c cumsum.c -o cumsum.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c fft.c -o fft.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c fmin.c -o fmin.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c integrate.c -o integrate.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c lbfgsb.c -o lbfgsb.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c loglin.c -o loglin.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c lowess.c -o lowess.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c machar.c -o machar.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c maxcol.c -o maxcol.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c massdist.c -o massdist.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c pretty.c -o pretty.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c rowsum.c -o rowsum.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c splines.c -o splines.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c stem.c -o stem.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c strsignif.c -o strsignif.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c tabulate.c -o tabulate.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c uncmin.c -o uncmin.o gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -g -O2 -c zeroin.c -o zeroin.o g77 -g -O2 -c ch2inv.f -o ch2inv.o g77 -g -O2 -c chol.f -o chol.o g77 -g -O2 -c dpbfa.f -o dpbfa.o g77 -g -O2 -c dpbsl.f -o dpbsl.o g77 -g -O2 -c dpoco.f -o dpoco.o g77 -g -O2 -c dpodi.f -o dpodi.o g77 -g -O2 -c dpofa.f -o dpofa.o g77 -g -O2 -c dposl.f -o dposl.o g77 -g -O2 -c dqrdc.f -o dqrdc.o g77 -g -O2 -c dqrdc2.f -o dqrdc2.o g77 -g -O2 -c dqrls.f -o dqrls.o g77 -g -O2 -c dqrsl.f -o dqrsl.o g77 -g -O2 -c dqrutl.f -o dqrutl.o g77 -g -O2 -c dsvdc.f -o dsvdc.o g77 -g -O2 -c dtrco.f -o dtrco.o g77 -g -O2 -c dtrsl.f -o dtrsl.o g77 -g -O2 -c eigen.f -o eigen.o g77 -g -O2 -c lminfl.f -o lminfl.o ar cr libappl.a approx.o bakslv.o bandwidths.o binning.o chull.o cpoly.o cumsum.o fft.o fmin.o integrate.o lbfgsb.o loglin.o lowess.o machar.o maxcol.o massdist.o pretty.o rowsum.o splines.o stem.o strsignif.o tabulate.o uncmin.o zeroin.o ch2in v.o chol.o dpbfa.o dpbsl.o dpoco.o dpodi.o dpofa.o dposl.o dqrdc.o dqrdc2.o dqrls.o dqrsl.o dqrutl.o dsvdc.o dtrco.o dtrsl.o eigen.o lminfl.o : libappl.a making mlutils.d from mlutils.c making d1mach.d from d1mach.c making i1mach.d from i1mach.c making fmax2.d from fmax2.c making fmin2.d from fmin2.c making fprec.d from fprec.c making fround.d from fround.c making ftrunc.d from ftrunc.c making sign.d from sign.c making fsign.d from fsign.c making imax2.d from imax2.c making imin2.d from imin2.c making chebyshev.d from chebyshev.c making log1p.d from log1p.c making lgammacor.d from lgammacor.c making gammalims.d from gammalims.c making stirlerr.d from stirlerr.c making bd0.d from bd0.c making gamma.d from gamma.c making lgamma.d from lgamma.c making gamma_cody.d from gamma_cody.c making beta.d from beta.c making lbeta.d from lbeta.c making polygamma.d from polygamma.c making bessel_i.d from bessel_i.c making bessel_j.d from bessel_j.c making bessel_k.d from bessel_k.c making bessel_y.d from bessel_y.c making choose.d from choose.c making snorm.d from snorm.c making sexp.d from sexp.c making dgamma.d from dgamma.c making pgamma.d from pgamma.c making qgamma.d from qgamma.c making rgamma.d from rgamma.c making dbeta.d from dbeta.c making pbeta.d from pbeta.c making qbeta.d from qbeta.c making rbeta.d from rbeta.c making dunif.d from dunif.c making punif.d from punif.c making qunif.d from qunif.c making runif.d from runif.c making dnorm.d from dnorm.c making pnorm.d from pnorm.c making qnorm.d from qnorm.c making rnorm.d from rnorm.c making dlnorm.d from dlnorm.c ==> 1275.reply.1 <== From p.dalgaard@biostat.ku.dk Tue Jan 22 16:29:23 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA20580; Tue, 22 Jan 2002 16:29:22 +0100 (MET) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id g0MFRjp00671; Tue, 22 Jan 2002 16:27:45 +0100 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: wtautz@math.uwaterloo.ca Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a) (PR#1275) References: <200201221505.QAA20274@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 22 Jan 2002 16:27:45 +0100 In-Reply-To: <200201221505.QAA20274@pubhealth.ku.dk> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii wtautz@math.uwaterloo.ca writes: > I have included the full configure/make output: > (the particular error regarding bessel_i.c is at > the END of the report). ... > bessel_i.c: In function `I_bessel': > bessel_i.c:468: internal error--unrecognizable insn: > (insn 1418 1417 673 (set:DF (reg/v:DF 101) > (if_then_else:DF (ne (reg:DI 416) > (const_int 0 [0x0])) > (reg/v:DF 101) > (reg:DF 415))) -1 (insn_list 1417 (nil)) > (expr_list:REG_DEAD (reg:DI 416) > (nil))) > *** Error code 1 (bu21) > *** Error code 1 (bu21) > *** Error code 1 (bu21) > *** Error code 1 (bu21) > *** Error code 1 (bu21) That looks like a problem in the gcc compiler suite. You might try upgrading the compiler. Sometimes changing compiler flags (you would only need to do it for the offending module) does the trick. Another possibility is that gcc is generating code that the system assembler doesn't understand (this is happening with gcc 3 on Solaris). If so, then you might install GNU binutils. If none of this helps, I'm afraid that you need to take it up with the GCC authors since it is not an R problem. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1275.followup.1 <== From wtautz@math.uwaterloo.ca Tue Jan 22 16:48:52 2002 Received: from mfcf.math.uwaterloo.ca (wtautz@mfcf.math.uwaterloo.ca [129.97.216.156]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id QAA20899; Tue, 22 Jan 2002 16:48:49 +0100 (MET) Received: from localhost (wtautz@localhost) by mfcf.math.uwaterloo.ca (8.9.3/8.9.3) with SMTP id KAA14370; Tue, 22 Jan 2002 10:48:18 -0500 (EST) X-Authentication-Warning: mfcf.math: wtautz owned process doing -bs Date: Tue, 22 Jan 2002 10:48:18 -0500 (EST) From: Walter Tautz Reply-To: Walter Tautz To: Peter Dalgaard BSA cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk, Walter Tautz Subject: Re: [Rd] compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a) (PR#1275) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 22 Jan 2002, Peter Dalgaard BSA wrote: > wtautz@math.uwaterloo.ca writes: > > > I have included the full configure/make output: > > (the particular error regarding bessel_i.c is at > > the END of the report). > ... > > bessel_i.c: In function `I_bessel': > > bessel_i.c:468: internal error--unrecognizable insn: > > (insn 1418 1417 673 (set:DF (reg/v:DF 101) > > (if_then_else:DF (ne (reg:DI 416) > > (const_int 0 [0x0])) > > (reg/v:DF 101) > > (reg:DF 415))) -1 (insn_list 1417 (nil)) > > (expr_list:REG_DEAD (reg:DI 416) > > (nil))) > > *** Error code 1 (bu21) > > *** Error code 1 (bu21) > > *** Error code 1 (bu21) > > *** Error code 1 (bu21) > > *** Error code 1 (bu21) > > That looks like a problem in the gcc compiler suite. You might try > upgrading the compiler. Sometimes changing compiler flags (you would > only need to do it for the offending module) does the trick. > > Another possibility is that gcc is generating code that the system > assembler doesn't understand (this is happening with gcc 3 on > Solaris). If so, then you might install GNU binutils. > I neglected to mention that gcc -v gives: gcc version 2.95.3 20010315 (release) Here is a more verbose output if that helps: Reading specs from /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/specs gcc version 2.95.3 20010315 (release) /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/cpp0 -lang-c -v -I. -I../../src/include -I../../src/include -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dunix -Dmips -Dsgi -Dhost_mips -DMIPSEB -D_MIPSEB -DSYSTYPE_SVR4 -D_LONGLONG -D_SVR4 _SOURCE -D_MODERN_C -D__DSO__ -D__unix__ -D__mips__ -D__sgi__ -D__host_mips__ -D__MIPSEB__ -D_MIPSEB -D__SYSTYPE_SVR4__ -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix -D__mips -D__sgi -D__host_mips -D__MIPSEB -D__SYSTYPE_SVR4 -Asystem(unix) -As ystem(svr4) -Acpu(mips) -Amachine(sgi) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -g -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=long unsigned int -D__PTRDIFF_TYPE__=long int -D__LONG_MAX__=9223372036854775807L -D__EXTENSIONS__ -D_SGI_SOURCE -D_MIPS _FPSET=32 -D_MIPS_ISA=_MIPS_ISA_MIPS3 -D_ABI64=3 -D_MIPS_SIM=_ABI64 -D_MIPS_SZINT=32 -D_MIPS_SZLONG=64 -D_MIPS_SZPTR=64 -D_COMPILER_VERSION=601 -U__mips -D__mips=3 -D__mips64 -DHAVE_CONFIG_H bessel_i.c /var/tmp/ccyhjiCa.i GNU CPP version 2.95.3 20010315 (release) [AL 1.1, MM 40] SGI running IRIX 6.x #include "..." search starts here: #include <...> search starts here: . ../../src/include /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/../../../../mips-sgi-irix6.5/include /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/include /usr/include End of search list. The following default directories have been omitted from the search path: /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/../../../../include/g++-3 /usr/local/include End of omitted list. /.software/arch/gcc-2.95.3/distribution/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/cc1 /var/tmp/ccyhjiCa.i -quiet -dumpbase bessel_i.c -mabi=64 -g -O2 -version -o /var/tmp/ccKOSzid.s GNU C version 2.95.3 20010315 (release) (mips-sgi-irix6.5) compiled by GNU C version 2.95.3 20010315 (release). bessel_i.c: In function `I_bessel': bessel_i.c:468: internal error--unrecognizable insn: (insn 1418 1417 673 (set:DF (reg/v:DF 101) (if_then_else:DF (ne (reg:DI 416) (const_int 0 [0x0])) (reg/v:DF 101) (reg:DF 415))) -1 (insn_list 1417 (nil)) (expr_list:REG_DEAD (reg:DI 416) (nil))) ==> 1275.audit <== Thu Jan 24 15:40:40 2002 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1289 * Subject: R 1.4.0 build fails on AIX From: lio@hpss1.ccs.ornl.gov Date: Wed, 30 Jan 2002 14:10:30 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1289 <== From lio@hpss1.ccs.ornl.gov Wed Jan 30 14:10:31 2002 Received: from blueberry.kubism.ku.dk (blueberry [130.225.108.193]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA19022 for ; Wed, 30 Jan 2002 14:10:30 +0100 (MET) Date: Wed, 30 Jan 2002 14:10:30 +0100 (MET) From: lio@hpss1.ccs.ornl.gov Message-Id: <200201301310.OAA19022@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: R 1.4.0 build fails on AIX Full_Name: Daniel L. Million Version: 1.4.0 OS: AIX 5.1 and 4.3.3 Submission from: (NULL) (160.91.192.125) Is there any guidance available on building R on AIX? Specifically, which C compiler to use? We have AIX XL Fortran version 7.1.1. We also have AIX Visual Age C version 5.0.2. We also have gcc available. I have tried building with "cc" (the default AIX compiler) and "gcc". During the "make", C compilation in src/library/methods/src completes, and then I see this: mkdir ../../../../library/methods/libs dumping R code in package `methods' make: 1254-059 The signal code from the last command is 11. Apparently the make is running R.bin, which coredumps with a segmentation violation. Do I need to be using a thread-safe compiler (e.g., "cc_r") for this build? Any clues at all as to how to get around this? Thanks. Dan Million ==> 1289.followup.1 <== From tlumley@u.washington.edu Wed Jan 30 17:46:32 2002 Received: from jason04.u.washington.edu (jason04.u.washington.edu [140.142.8.53]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id RAA23476 for ; Wed, 30 Jan 2002 17:46:31 +0100 (MET) Received: from homer40.u.washington.edu (homer40.u.washington.edu [140.142.16.6]) by jason04.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0UGjs9Y020226; Wed, 30 Jan 2002 08:45:54 -0800 Received: from localhost (tlumley@localhost) by homer40.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0UGjru1095332; Wed, 30 Jan 2002 08:45:53 -0800 Date: Wed, 30 Jan 2002 08:45:53 -0800 (PST) From: Thomas Lumley To: lio@hpss1.ccs.ornl.gov cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289) In-Reply-To: <200201301310.OAA19034@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jan 2002 lio@hpss1.ccs.ornl.gov wrote: > Full_Name: Daniel L. Million > Version: 1.4.0 > OS: AIX 5.1 and 4.3.3 > Submission from: (NULL) (160.91.192.125) > > > Is there any guidance available on building R on AIX? Specifically, which C > compiler to use? We have AIX XL Fortran version 7.1.1. We also have AIX > Visual Age C version 5.0.2. We also have gcc available. > > I have tried building with "cc" (the default AIX compiler) and "gcc". During > the "make", C compilation in src/library/methods/src completes, and then I > see this: > > mkdir ../../../../library/methods/libs > dumping R code in package `methods' > make: 1254-059 The signal code from the last command is 11. > > Apparently the make is running R.bin, which coredumps with a segmentation > violation. > > Do I need to be using a thread-safe compiler (e.g., "cc_r") for this build? > Any clues at all as to how to get around this? I have successfully built most recent versions of R including 1.4.0 with gcc/g77 and with "C for AIX version 5"/"XL Fortran for AIX" on AIX 4.3. I haven't been able to mix the GNU and IBM compilers, but I haven't tried recently. Last week I compiled R-patched successfully using gcc/g77. I didn't have to do anything special, but AIX has often been source of configuration bugs. You could try not building the methods package: edit Makeconf in the top R/ directory and remove methods from R_PKGS. Also, I think that it's possible to have the methods package build in the usual source form rather than as a saved image. I don't know how, but John Chambers or Duncan Temple Lang may be able to help. These wouldn't actually fix the problem, but would enable you to compile everything else. I'll try again with the AIX compilers and the new R 1.4.1. It's possible that there have been some changes since I last tried, since I usually do this shortly before a release. -thomas ==> 1289.followup.2 <== From lio@hpss1.ccs.ornl.gov Wed Jan 30 20:49:57 2002 Received: from hpss1.ccs.ornl.gov (hpss1.ccs.ornl.gov [160.91.192.125]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id UAA24914 for ; Wed, 30 Jan 2002 20:49:56 +0100 (MET) Received: from localhost (lio@localhost) by hpss1.ccs.ornl.gov (AIX4.3/8.9.3/8.9.1) with ESMTP id OAA18340; Wed, 30 Jan 2002 14:49:04 -0500 Date: Wed, 30 Jan 2002 14:49:04 -0500 (EST) From: Dan Million To: Thomas Lumley cc: , , Dan Million Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jan 2002, Thomas Lumley wrote: > On Wed, 30 Jan 2002 lio@hpss1.ccs.ornl.gov wrote: > > > Full_Name: Daniel L. Million > > Version: 1.4.0 > > OS: AIX 5.1 and 4.3.3 > > Submission from: (NULL) (160.91.192.125) > > > > > > Is there any guidance available on building R on AIX? Specifically, which C > > compiler to use? We have AIX XL Fortran version 7.1.1. We also have AIX > > Visual Age C version 5.0.2. We also have gcc available. > > > > I have tried building with "cc" (the default AIX compiler) and "gcc". During > > the "make", C compilation in src/library/methods/src completes, and then I > > see this: > > > > mkdir ../../../../library/methods/libs > > dumping R code in package `methods' > > make: 1254-059 The signal code from the last command is 11. > > > > Apparently the make is running R.bin, which coredumps with a segmentation > > violation. > > > > Do I need to be using a thread-safe compiler (e.g., "cc_r") for this build? > > Any clues at all as to how to get around this? > > > I have successfully built most recent versions of R including 1.4.0 with > gcc/g77 and with "C for AIX version 5"/"XL Fortran for AIX" on AIX 4.3. I > haven't been able to mix the GNU and IBM compilers, but I haven't tried > recently. Last week I compiled R-patched successfully using gcc/g77. I > didn't have to do anything special, but AIX has often been source of > configuration bugs. > > You could try not building the methods package: edit Makeconf in the top > R/ directory and remove methods from R_PKGS. > > Also, I think that it's possible to have the methods package build in the > usual source form rather than as a saved image. I don't know how, but John > Chambers or Duncan Temple Lang may be able to help. > > These wouldn't actually fix the problem, but would enable you to compile > everything else. > > I'll try again with the AIX compilers and the new R 1.4.1. It's possible > that there have been some changes since I last tried, since I usually do > this shortly before a release. > > -thomas Thanks for the reply. I tried building without the modules package, and got past that point. Now the build fails trying to link tcltk.so. Seems the tclConfig.sh on my host refers to a file that does not exist (/opt/freeware/src/packages/BUILD/tcltk-8.3.3/tcl8.3.3/unix/lib.exp). I'll freely admit to being clueless about most of this. I don't know anything about R; I'm just a sysadmin trying to build/install it for a user who needs it. Dan ==> 1289.followup.3 <== From tlumley@u.washington.edu Wed Jan 30 21:18:08 2002 Received: from jason03.u.washington.edu (jason03.u.washington.edu [140.142.8.11]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id VAA25053 for ; Wed, 30 Jan 2002 21:18:07 +0100 (MET) Received: from homer04.u.washington.edu (homer04.u.washington.edu [140.142.15.38]) by jason03.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0UKHUPE052646; Wed, 30 Jan 2002 12:17:30 -0800 Received: from localhost (tlumley@localhost) by homer04.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0UKHTUO036174; Wed, 30 Jan 2002 12:17:29 -0800 Date: Wed, 30 Jan 2002 12:17:29 -0800 (PST) From: Thomas Lumley To: Dan Million cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jan 2002, Dan Million wrote: > Thanks for the reply. I tried building without the modules package, and > got past that point. Now the build fails trying to link tcltk.so. Seems > the tclConfig.sh on my host refers to a file that does not exist > (/opt/freeware/src/packages/BUILD/tcltk-8.3.3/tcl8.3.3/unix/lib.exp). > > I'll freely admit to being clueless about most of this. I don't know > anything about R; I'm just a sysadmin trying to build/install it for a > user who needs it. Our autodetection of tcl/tk is less reliable than most stuff, partly because the tclConfig.sh and similar files are sometimes inaccurate. If your users don't need tcl/tk (which is a fairly low-level set of facilities for writing GUIs) you can again remove tcltk from the R_PKGS line of Makeconf, or reconfigure ./configure --without-tcltk If your users do need this package then you (or they) need to track down where tcl and tk lurk and provide this information to R. Probably the easiest way would be to install a new version of Tcl and Tk, which should produce an honest set of configuration files. -thomas ==> 1289.followup.4 <== From lio@hpss1.ccs.ornl.gov Thu Jan 31 19:36:53 2002 Received: from hpss1.ccs.ornl.gov (hpss1.ccs.ornl.gov [160.91.192.125]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id TAA08024 for ; Thu, 31 Jan 2002 19:36:52 +0100 (MET) Received: from localhost (lio@localhost) by hpss1.ccs.ornl.gov (AIX4.3/8.9.3/8.9.1) with ESMTP id NAA24034; Thu, 31 Jan 2002 13:36:00 -0500 Date: Thu, 31 Jan 2002 13:36:00 -0500 (EST) From: Dan Million To: Thomas Lumley cc: , , Dan Million Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jan 2002, Thomas Lumley wrote: > On Wed, 30 Jan 2002, Dan Million wrote: > > > Thanks for the reply. I tried building without the modules package, and > > got past that point. Now the build fails trying to link tcltk.so. Seems > > the tclConfig.sh on my host refers to a file that does not exist > > (/opt/freeware/src/packages/BUILD/tcltk-8.3.3/tcl8.3.3/unix/lib.exp). > > Our autodetection of tcl/tk is less reliable than most stuff, partly > because the tclConfig.sh and similar files are sometimes inaccurate. If > your users don't need tcl/tk (which is a fairly low-level set of > facilities for writing GUIs) you can again remove tcltk from the R_PKGS > line of Makeconf, or reconfigure > ./configure --without-tcltk > > If your users do need this package then you (or they) need to track down > where tcl and tk lurk and provide this information to R. Probably the > easiest way would be to install a new version of Tcl and Tk, which should > produce an honest set of configuration files. I installed and built the Tcl/Tk source RPM, and now the file that R wants is there. By skipping the "modules" packages, the build gets all the way to the end. "make check" fails rather quickly: running code in `base-Ex.R' .../bin/sh: 51598 Illegal instruction(coredump) make: 1254-004 The error code from the last command is 1. When I try to run R, I get the opening info and then a "> " prompt. I can type simple commands like help(), but whenever I type q() to quit, I get a coredump. This is consistent with what I saw earlier when the build was trying to load "modules". The stack trace in the coredump contains this: Segmentation fault in spin_lock_global_ppc_mp at 0xd0106644 ($t1) 0xd0106644 (spin_lock_global_ppc_mp+0x24) 7ce5192d stwcx. r7,r5,r3 (dbx) where spin_lock_global_ppc_mp() at 0xd0106644 _rec_mutex_lock(??) at 0xd0170d48 __ct__Q2_3std7_LockitFi(??, ??) at 0xd0bb3a18 __dt__Q2_3std6_WinitFv(??, ??) at 0xd0bdad18 __srterm__7__Fv() at 0xd0bcbe04 exit(??) at 0xd0177c40 Rstd_CleanUp(0x3, 0x0, 0x1), line 529 in "sys-std.c" It almost looks like R is working OK until it calls "exit", and then it blows up. Dan ==> 1289.audit <== Fri Feb 1 21:55:34 2002 ripley moved from incoming to System-specific ==> 1289.followup.5 <== From harald@cepba.upc.es Mon May 5 17:53:44 2003 Received: from dukas.upc.es (dukas.upc.es [147.83.2.62]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h45Frh2b016029 for ; Mon, 5 May 2003 17:53:43 +0200 (MET DST) Received: from amen.cepba.upc.es (amen.cepba.upc.es [147.83.42.19]) by dukas.upc.es (8.12.1/8.12.1) with ESMTP id h45Frg9J012974 for ; Mon, 5 May 2003 17:53:42 +0200 (MET DST) Received: from cepba.upc.es (amen.cepba.upc.es [147.83.42.19]) by amen.cepba.upc.es (SGI-8.9.3/8.9.3) with ESMTP id RAA51323 for ; Mon, 5 May 2003 17:54:40 +0200 (CEST) Sender: harald@cepba.upc.es Message-ID: <3EB68940.F8718856@cepba.upc.es> Date: Mon, 05 May 2003 17:54:40 +0200 From: Harald Servat Gelabert X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX64 6.5 IP28) X-Accept-Language: en MIME-Version: 1.0 To: r-bugs@biostat.ku.dk Subject: (PR#1289) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all, I've found a bug report for R when installing it on an AIX5.1 system. There's a followup (number 4) that comments a segmentation fault on R when quitting "q()". I'm using a newer version of R but on the same operating system and I obtain the same error. There was a way to solve this problem? Best regards and thanks, -- ________________________________________________________________________ Harald Servat Gelabert (harald@cepba.upc.es) o//o Centre Europeu de Paral.lelisme de Barcelona CEPBA o//o WWW...: http://www.cepba.upc.es Tel: +34-93-401 74 23 o//o e-mail: suport@cepba.upc.es Fax: +34-93-401 25 77 o//o CEPBA c/Jordi Girona, 1-3, Mòdul D6. E-08034 Barcelona, Catalunya ________________________________________________________________________ The optimist thinks that this is the best of all possible worlds, and the pessimist knows it. -- J. Robert Oppenheimer, "Bulletin of Atomic Scientists" We scientists, whose tragic destiny it has been to make the methods of annihilation ever more gruesome and more effective, must consider it our solemn and transcendent duty to do all in our power in preventing these weapons from being used for the brutal purpose for which they were invented. -- Albert Einstein, "Bulletin of Atomic Scientists" ==> 1289.reply.1 <== From p.dalgaard@biostat.ku.dk Mon May 5 18:24:11 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h45GOB2b016170; Mon, 5 May 2003 18:24:11 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h45GSY8e007928; Mon, 5 May 2003 18:28:34 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h45GSXs7007924; Mon, 5 May 2003 18:28:33 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: harald@cepba.upc.es Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] (PR#1289) References: <200305051553.h45Fro2b016035@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 05 May 2003 18:28:33 +0200 In-Reply-To: <200305051553.h45Fro2b016035@pubhealth.ku.dk> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii harald@cepba.upc.es writes: > Dear all, > > I've found a bug report for R when installing it on an AIX5.1 system. > There's a followup (number 4) that comments a segmentation fault on R > when quitting "q()". > > I'm using a newer version of R but on the same operating system and > I obtain the same error. > > There was a way to solve this problem? Well, some exact version numbers and bug report ditto might help someone help you. Remember: *You* have a problem. People may actually go out of their way to help you, but if they have to do detective work just to guess your setup or figure out which PR# you're referring to, then they might not bother. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1289.followup.6 <== From harald@cepba.upc.es Mon May 5 18:39:17 2003 Received: from dukas.upc.es (dukas.upc.es [147.83.2.62]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h45GdG2b016236; Mon, 5 May 2003 18:39:17 +0200 (MET DST) Received: from amen.cepba.upc.es (amen.cepba.upc.es [147.83.42.19]) by dukas.upc.es (8.12.1/8.12.1) with ESMTP id h45Gd99J019653; Mon, 5 May 2003 18:39:09 +0200 (MET DST) Received: from cepba.upc.es (amen.cepba.upc.es [147.83.42.19]) by amen.cepba.upc.es (SGI-8.9.3/8.9.3) with ESMTP id SAA52701; Mon, 5 May 2003 18:40:07 +0200 (CEST) Sender: harald@cepba.upc.es Message-ID: <3EB693E6.CF360C1E@cepba.upc.es> Date: Mon, 05 May 2003 18:40:07 +0200 From: Harald Servat Gelabert X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX64 6.5 IP28) X-Accept-Language: en MIME-Version: 1.0 To: Peter Dalgaard BSA CC: R-bugs@biostat.ku.dk Subject: Re: [Rd] (PR#1289) References: <200305051553.h45Fro2b016035@pubhealth.ku.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ups, sorry, I forgot it. I thought that referencing the request could be enough. I'm trying to compile R 1.6.0, 1.6.1 and 1.6.2, and they all fail on the same manner. With R 1.7.0 we have some problems for compiling it. I use GNU C version 3.1 and the G77 in the same package. As I mentioned we have an AIX5.1 operating system running on a cluster of Power3 cpus. When I launch R on the machine and quit from it, it makes a segmentation fault and core dumps. Now I remember, when I tried to compile with XLC/XLF there were several warning on a SETJMP or similar but this compiler didn't fail on that point. (XLC failed when was unable to locate the symbol __fixsfsi) Best regards and thanks, Peter Dalgaard BSA wrote: > > harald@cepba.upc.es writes: > > > Dear all, > > > > I've found a bug report for R when installing it on an AIX5.1 system. > > There's a followup (number 4) that comments a segmentation fault on R > > when quitting "q()". > > > > I'm using a newer version of R but on the same operating system and > > I obtain the same error. > > > > There was a way to solve this problem? > > Well, some exact version numbers and bug report ditto might help > someone help you. > > Remember: *You* have a problem. People may actually go out of their > way to help you, but if they have to do detective work just to guess > your setup or figure out which PR# you're referring to, then they > might not bother. > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -- ________________________________________________________________________ Harald Servat Gelabert (harald@cepba.upc.es) o//o Centre Europeu de Paral.lelisme de Barcelona CEPBA o//o WWW...: http://www.cepba.upc.es Tel: +34-93-401 74 23 o//o e-mail: suport@cepba.upc.es Fax: +34-93-401 25 77 o//o CEPBA c/Jordi Girona, 1-3, Mòdul D6. E-08034 Barcelona, Catalunya ________________________________________________________________________ The optimist thinks that this is the best of all possible worlds, and the pessimist knows it. -- J. Robert Oppenheimer, "Bulletin of Atomic Scientists" We scientists, whose tragic destiny it has been to make the methods of annihilation ever more gruesome and more effective, must consider it our solemn and transcendent duty to do all in our power in preventing these weapons from being used for the brutal purpose for which they were invented. -- Albert Einstein, "Bulletin of Atomic Scientists" ==> 1289.followup.7 <== From hornik@ci.tuwien.ac.at Tue May 6 16:58:04 2003 Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h46Ew32b027362 for ; Tue, 6 May 2003 16:58:03 +0200 (MET DST) Received: from mithrandir.hornik.net (mail@wu057056.wu-wien.ac.at [137.208.57.56]) by isis.wu-wien.ac.at (8.12.8/8.12.6) with ESMTP id h46Ew0Tn044656; Tue, 6 May 2003 16:58:00 +0200 (envelope-from hornik@ci.tuwien.ac.at) Received: from hornik by mithrandir.hornik.net with local (Exim 3.36 #1 (Debian)) id 19Clsx-0000Rf-00; Mon, 05 May 2003 21:44:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16054.48923.85323.827671@mithrandir.hornik.net> Date: Mon, 5 May 2003 21:44:27 +0200 To: harald@cepba.upc.es Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] (PR#1289) In-Reply-To: <200305051639.h45GdM2b016240@pubhealth.ku.dk> References: <200305051639.h45GdM2b016240@pubhealth.ku.dk> X-Mailer: VM 7.14 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik X-WU-uvscan-status: clean v4.2.40/v4261 charon fd6b3731df670a75451c59f40c1e76a4 >>>>> harald writes: > Ups, sorry, I forgot it. I thought that referencing the request > could be enough. > I'm trying to compile R 1.6.0, 1.6.1 and 1.6.2, and they all fail > on the same manner. With R 1.7.0 we have some problems for compiling > it. > I use GNU C version 3.1 and the G77 in the same package. > As I mentioned we have an AIX5.1 operating system running on a > cluster of Power3 cpus. > When I launch R on the machine and quit from it, it makes a > segmentation fault and core dumps. It might be helpful if you could debug this ... Btw, I think the usual recommendation is using GCC 3.0 or 3.2, but not 3.1. -k ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1316 * Subject: shared libraries on AIX From: lio@hpss1.ccs.ornl.gov Date: Mon, 18 Feb 2002 18:53:41 +0100 (MET) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1316 <== From lio@hpss1.ccs.ornl.gov Mon Feb 18 18:53:43 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id SAA04410 for ; Mon, 18 Feb 2002 18:53:41 +0100 (MET) Date: Mon, 18 Feb 2002 18:53:41 +0100 (MET) From: lio@hpss1.ccs.ornl.gov Message-Id: <200202181753.SAA04410@pubhealth.ku.dk> To: R-bugs@biostat.ku.dk Subject: shared libraries on AIX Full_Name: Daniel L. Million Version: 1.4.1 OS: AIX 4.3.3/5.1 Submission from: (NULL) (160.91.192.125) R almost works if I build on AIX without the R shared library (except for crashing on exit and a few other anomalies). I can't get it to do much at all if I build with --enable-R-shlib. For example, it won't load the X11 driver. I ran R in a debugger and traced it down to the point where R_load_X11_shlib successfully loads the R_X11.so library and calls R_init_X11. This calls R_setX11Routines in src/unix/X11.c. On entry to this function, ptr_X11DeviceDriver = 0x2002eb20 and dev = 0x2014ba08. After the statement ptr_X11DeviceDriver = dev; is executed, ptr_X11DeviceDriver remains unchanged at 0x2002eb20 !! So when I type "X11()" at the R prompt, all I ever get is the stub message, "the x11 device has not been loaded". I don't know enough about how shared libraries interact to understand why this pointer is apparently write-protected. I'm hoping someone here can give me a clue. Dan ==> 1316.audit <== Tue Feb 19 10:13:59 2002 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1461 * Subject: make check fails d-p-q-r-tests.R - OpenBSD 3.0 From: Jason Turner Date: Mon, 15 Apr 2002 10:13:36 +0000 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1461 <== From postmaster@franz.stat.wisc.edu Mon Apr 15 12:12:38 2002 Received: from franz.stat.wisc.edu (root@franz.stat.wisc.edu [128.105.174.95]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA07647 for ; Mon, 15 Apr 2002 12:12:37 +0200 (MET DST) Received: from pcp-2.ihug.co.nz (really [203.109.252.66]) by franz.stat.wisc.edu via smail with esmtp id (Debian Smail3.2.0.114) for ; Mon, 15 Apr 2002 05:11:51 -0500 (CDT) Received: from 203-173-247-235.nzwide.ihug.co.nz (camille.indigoindustrial.co.nz) [203.173.247.235] by pcp-2.ihug.co.nz with esmtp (Exim 3.22 #1 (Debian)) id 16x3Sc-0000Ba-00; Mon, 15 Apr 2002 22:11:46 +1200 Received: (from jasont@localhost) by camille.indigoindustrial.co.nz (8.9.3/8.9.3) id WAA07569 for r-bugs@r-project.org; Mon, 15 Apr 2002 22:13:36 +1200 Date: Mon, 15 Apr 2002 10:13:36 +0000 From: Jason Turner To: r-bugs@r-project.org Subject: make check fails d-p-q-r-tests.R - OpenBSD 3.0 Message-ID: <20020415101336.A7551@camille.indigoindustrial.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-mailer: mutt 1.2.5i X-Priority: Booga booga X-FOTD: Persimmon Found one that stumped me. I did a search on R-bugs for the string "d-p-q-r-tests", and found zero entries in all categories (I don't think I secretly gave it a regex). Did the usual configure, make, make check on OpenBSD 3.0, and encountered this message on d-p-q-r-tests.Rout: 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' ...251,253c251 < [1] "`is.NA' value mismatches: 800 in current, 0 in target" < Warning message: < NaNs produced in: exp(pab <- dbeta(p, a, b, log = TRUE)) --- > [1] TRUE 315,317c313 < [1] "`is.NA' value mismatches: 4 in current, 2 in target" < Warning message: < NaNs produced in: exp(z) --- > [1] TRUE OK If you're not too busy, I'd love to provide you with whatever you need to look at this more closely than my untrained eyes can. config.cache? d-p-q-r-tests.Rout? Anything else? > version _ platform i386-unknown-openbsd3.0 arch i386 os openbsd3.0 system i386, openbsd3.0 status major 1 minor 4.1 year 2002 month 01 day 30 language R Cheers Jason -- Indigo Industrial Controls Ltd. 64-21-343-545 jasont@indigoindustrial.co.nz ==> 1461.reply.1 <== From maechler@stat.math.ethz.ch Mon Apr 15 12:46:41 2002 Received: from stat.math.ethz.ch (daemon@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA07975 for ; Mon, 15 Apr 2002 12:46:38 +0200 (MET DST) Received: (from daemon@localhost) by stat.math.ethz.ch (8.9.1/8.9.1) id MAA17444; Mon, 15 Apr 2002 12:45:47 +0200 (MET DST) Received: from lynne(129.132.58.30), claiming to be "lynne.ethz.ch" via SMTP by hypatia, id smtpdAAAa004GV; Mon Apr 15 12:45:43 2002 Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id g3FAjYB22782; Mon, 15 Apr 2002 12:45:34 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15546.44877.955999.520989@gargle.gargle.HOWL> Date: Mon, 15 Apr 2002 12:45:33 +0200 To: jasont@indigoindustrial.co.nz Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] make check fails d-p-q-r-tests.R - OpenBSD 3.0 (PR#1461) In-Reply-To: <200204151012.MAA07652@pubhealth.ku.dk> References: <200204151012.MAA07652@pubhealth.ku.dk> X-Mailer: VM 6.97 under Emacs 21.1.1 Reply-To: Martin Maechler >>>>> "Jason" == Jason Turner writes: Jason> Found one that stumped me. I did a search on R-bugs for the Jason> string "d-p-q-r-tests", and found zero entries in all categories Jason> (I don't think I secretly gave it a regex). Jason> Did the usual configure, make, make check on OpenBSD 3.0, and Jason> encountered this message on d-p-q-r-tests.Rout: Jason> running code in `d-p-q-r-tests.R' ... OK Jason> comparing `d-p-q-r-tests.Rout' to `./d-p-q-r-tests.Rout.save' ...251,253c251 Jason> < [1] "`is.NA' value mismatches: 800 in current, 0 in target" Jason> < Warning message: Jason> < NaNs produced in: exp(pab <- dbeta(p, a, b, log = TRUE)) Jason> --- >> [1] TRUE Jason> 315,317c313 Jason> < [1] "`is.NA' value mismatches: 4 in current, 2 in target" Jason> < Warning message: Jason> < NaNs produced in: exp(z) Jason> --- >> [1] TRUE Jason> OK Jason> If you're not too busy, I'd love to provide you with whatever you Jason> need to look at this more closely than my untrained eyes can. Jason> config.cache? d-p-q-r-tests.Rout? Anything else? Actually, we'd be very grateful if you could run these with R-devel aka "R pre1.5.0" instead. You can get a snapshot using rsync (or the tar file), see http://stat.ethz.ch/CRAN/sources.html If you see the same problem (or also with 1.4.1) look at the tests/d-p-q files probably start R and try things like z <- c(-Inf,Inf,NA,NaN, rt(1000, df=2)) z.ok <- z > -37.5 | !is.finite(z) for(df in 1:10) if(!is.logical(all.equal(pt(z, df), 1 - pt(-z,df), tol= 1e-15))) cat("ERROR -- df = ", df, "\n") c(pz <- pnorm(z), 1 - pnorm(z, lower=FALSE)) c(pz, pnorm(-z, lower=FALSE)) c(log(pz[z.ok]), pnorm(z[z.ok], log=TRUE)) because these are around line 315 of tests/d-p-q-r-tests.Rout.save and the second problem happened around there. [A more desperate option would be to offer a login into your computer to someone from the R core team ...] Thanks for helping us to have R running correctly on OpenBSD 3.0, Martin ==> 1461.audit <== Thu Apr 18 15:35:18 2002 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 1606 * Subject: hitting ^C breaks readline history From: Cyril Humbert Date: Tue, 28 May 2002 12:07:07 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 1606 <== From humbertc@univ-mlv.fr Tue May 28 12:07:07 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id MAA25460 for ; Tue, 28 May 2002 12:07:07 +0200 (MET DST) Date: Tue, 28 May 2002 12:07:07 +0200 (MET DST) Message-Id: <200205281007.MAA25460@pubhealth.ku.dk> From: Cyril Humbert To: R-bugs@biostat.ku.dk Subject: hitting ^C breaks readline history Full_Name: Cyril Humbert Version: 1.5.0 OS: linux Submission from: (NULL) (193.50.159.2) Hitting ^C breaks readline history (when R is stared in an xterm). xterm -e R ^C -> arrow key and history stop working. For example, up-arrow gives "^[[A". ldd ./R.bin [../..] libreadline.so.4.1 => /usr/lib/libreadline.so.4.1 (0x40020000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x4004c000) [../..] libncurses version is 5.2. Note. I've got the same problem with libreadline.so.4.2. ==> 1606.reply.1 <== From p.dalgaard@biostat.ku.dk Tue May 28 14:32:35 2002 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA27572; Tue, 28 May 2002 14:32:34 +0200 (MET DST) Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.11.2/8.11.2) id g4SCWVh01560; Tue, 28 May 2002 14:32:31 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f Sender: pd@pubhealth.ku.dk To: humbertc@univ-mlv.fr Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: hitting ^C breaks readline history (PR#1606) References: <200205281007.MAA25465@pubhealth.ku.dk> From: Peter Dalgaard BSA Date: 28 May 2002 14:32:31 +0200 In-Reply-To: <200205281007.MAA25465@pubhealth.ku.dk> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii humbertc@univ-mlv.fr writes: > Hitting ^C breaks readline history (when R is stared in an xterm). > > xterm -e R > ^C -> arrow key and history stop working. > For example, up-arrow gives "^[[A". Yes, I've noticed as well. However, press Enter and things return to normal. If you give us a clue as to what causes the problem, we might fix it... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 1606.followup.1 <== From cyril@univ-mlv.fr Tue May 28 14:49:35 2002 Received: from univ-mlv.fr (goodboys.univ-mlv.fr [193.50.159.2]) by pubhealth.ku.dk (8.9.3/8.9.1) with ESMTP id OAA27857; Tue, 28 May 2002 14:49:34 +0200 (MET DST) Received: from cyril by univ-mlv.fr with local (Exim 3.20 #1) id 17CgPD-0006St-00; Tue, 28 May 2002 14:48:51 +0200 Date: Tue, 28 May 2002 14:48:50 +0200 From: Cyril Humbert To: Peter Dalgaard BSA Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: hitting ^C breaks readline history (PR#1606) Message-ID: <20020528144850.A24847@borneo.univ-mlv.fr> References: <200205281007.MAA25465@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from p.dalgaard@biostat.ku.dk on Tue, May 28, 2002 at 02:32:31PM +0200 Sender: Cyril Humbert Peter Dalgaard BSA wrote: > humbertc@univ-mlv.fr writes: > > > Hitting ^C breaks readline history (when R is stared in an xterm). > > > > xterm -e R > > ^C -> arrow key and history stop working. > > For example, up-arrow gives "^[[A". > > Yes, I've noticed as well. However, press Enter and things return to > normal. Thanks, that's much better than my previous solution (quit and restart R). > > If you give us a clue as to what causes the problem, we might fix it... Probably something wrong with readline and/or ncurses but currently I don't know exactly what... -- Cyril Humbert ==> 1606.audit <== Mon Jun 3 20:57:41 2002 thomas moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2730 * Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test From: Dirk Eddelbuettel Date: Fri, 4 Apr 2003 06:27:15 -0600 --something obscure in debian: pbuilder is not part of R ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2730 <== From edd@debian.org Fri Apr 4 14:27:17 2003 Received: from sonny.eddelbuettel.com (mail@12-250-182-80.client.attbi.com [12.250.182.80]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h34CRFpD008486 for ; Fri, 4 Apr 2003 14:27:16 +0200 (MET DST) Received: from edd by sonny.eddelbuettel.com with local (Exim 3.35 #1 (Debian)) id 191QHr-000773-00; Fri, 04 Apr 2003 06:27:15 -0600 Date: Fri, 4 Apr 2003 06:27:15 -0600 From: Dirk Eddelbuettel To: r-bugs@biostat.ku.dk Cc: Daniel Schepler , 187537-forwarded@bugs.debian.org Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test Message-ID: <20030404122715.GB27144@sonny.eddelbuettel.com> References: <87n0j6rbjw.fsf@frobnitz.ddts.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87n0j6rbjw.fsf@frobnitz.ddts.net> User-Agent: Mutt/1.3.28i Thanks for the bug report. I will pass it on to R Core. On Thu, Apr 03, 2003 at 11:01:23PM -0800, Daniel Schepler wrote: > Package: r-base > Version: 1.6.2.cvs.20030403-1 > Severity: serious > > Whenever I try to build r-base using pbuilder, it gets stuck at the > following point: > > ... > collecting examples for package 'tcltk' ... > make[6]: Entering directory `/tmp/buildd/r-base-1.6.2.cvs.20030403/src/library' > >>> Building/Updating help pages for package 'tcltk' > Formats: text example > make[6]: Leaving directory `/tmp/buildd/r-base-1.6.2.cvs.20030403/src/library' > running code in 'tcltk-Ex.R' ... > > Part of the output of ps aufwwx reads: > #1234 1727 0.0 0.1 2132 1000 pts/4 S 22:02 0:00 \_ /bin/sh -c ../../bin/R --vanilla < tcltk-Ex.R > tcltk-Ex.Rout 2>&1 || (mv tcltk-Ex.Rout tcltk-Ex.Rout.fail && exit 1) > #1234 1728 0.1 2.6 24524 17004 pts/4 S 22:02 0:03 \_ /tmp/buildd/r-base-1.6.2.cvs.20030403/bin/R.bin --vanilla > #1234 1731 0.0 0.0 0 0 pts/4 Z 22:02 0:00 \_ [R.bin] > > strace -p 1728 doesn't show anything useful, but top shows no CPU > being consumed by the process (which is strange). Hm, I have not seen that. But Doug Bates mentioned something about building remotely, and having had a problem. I have never seen this, and am building both locally and remotely. > In case this makes any difference, I am redirecting the stdout and > stderr of pbuilder into a pipe, while leaving stdin unchanged. Don't know, it may. But that does not propagate to what happens inside pbuilder, i.e. in the processes started by it, does it? Most of the other build systems work, see http://buildd.debian.org/build.php?pkg=r-base The most recent hppa error looks spurious and related to Build-Depends. Just to confirm, you are building on m68k, correct? Dirk -- Wishful thinking can dominate much of the work of a profession for a decade, but not indefinitely. -- Robert Shiller, on Efficient Markets models, 2002 ==> 2730.audit <== Wed Apr 9 13:01:29 2003 ripley moved from incoming to System-specific Wed Apr 9 13:03:16 2003 ripley changed notes Wed Apr 9 13:03:16 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2733 * Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test From: Daniel Schepler Date: 05 Apr 2003 14:06:09 -0800 --part of 2730 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2733 <== From daniel@frobnitz.ddts.net Sun Apr 6 00:06:19 2003 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h35M6IpD015848 for ; Sun, 6 Apr 2003 00:06:19 +0200 (MET DST) Received: from user-119bq03.biz.mindspring.com ([66.149.232.3] helo=frobnitz.ddts.net) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 191vne-0007aZ-00; Sat, 05 Apr 2003 17:06:10 -0500 Received: from daniel by frobnitz.ddts.net with local (Exim 3.36 #1 (Debian)) id 191vnd-0000WI-00; Sat, 05 Apr 2003 14:06:09 -0800 To: Dirk Eddelbuettel Cc: r-bugs@biostat.ku.dk, 187537@bugs.debian.org Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test References: <87n0j6rbjw.fsf@frobnitz.ddts.net> <20030404122715.GB27144@sonny.eddelbuettel.com> Content-Type: text/plain; charset=US-ASCII From: Daniel Schepler Date: 05 Apr 2003 14:06:09 -0800 In-Reply-To: <20030404122715.GB27144@sonny.eddelbuettel.com> Message-ID: <87of3kioq6.fsf@frobnitz.ddts.net> Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) MIME-Version: 1.0 Sender: Daniel Schepler Dirk Eddelbuettel writes: > Thanks for the bug report. I will pass it on to R Core. > > > In case this makes any difference, I am redirecting the stdout and > > stderr of pbuilder into a pipe, while leaving stdin unchanged. > > Don't know, it may. But that does not propagate to what happens inside > pbuilder, i.e. in the processes started by it, does it? > > Most of the other build systems work, see > http://buildd.debian.org/build.php?pkg=r-base > The most recent hppa error looks spurious and related to Build-Depends. I just reproduced the hang on a standard pbuilder setup: after installing pbuilder and editing MIRRORSITE in /etc/pbuilderrc to your liking and setting DISTRIBUTION to sid, you should just be able to run pbuilder create, then "pbuilder build r-base_*.dsc 2>&1|tee build-log". This reproduced the bug for me. (I'm not sure whether pbuilder is actually required, but I didn't feel like installing the Build-Depends for r-base in the root filesystem.) > Just to confirm, you are building on m68k, correct? No, i386. -- Daniel Schepler "Please don't disillusion me. I schepler@math.berkeley.edu haven't had breakfast yet." -- Orson Scott Card ==> 2733.audit <== Wed Apr 9 13:01:29 2003 ripley moved from incoming to System-specific Wed Apr 9 13:02:35 2003 ripley changed notes Wed Apr 9 13:02:35 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2736 * Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test From: Dirk Eddelbuettel Date: Sun, 6 Apr 2003 21:20:29 -0500 --part of 2730 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2736 <== From edd@debian.org Mon Apr 7 04:20:30 2003 Received: from sonny.eddelbuettel.com (mail@12-250-182-80.client.attbi.com [12.250.182.80]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h372KTpD019834 for ; Mon, 7 Apr 2003 04:20:29 +0200 (MET DST) Received: from edd by sonny.eddelbuettel.com with local (Exim 3.35 #1 (Debian)) id 192MFK-0004Yc-00; Sun, 06 Apr 2003 21:20:30 -0500 Date: Sun, 6 Apr 2003 21:20:29 -0500 From: Dirk Eddelbuettel To: Daniel Schepler Cc: Dirk Eddelbuettel , r-bugs@biostat.ku.dk, 187537@bugs.debian.org Subject: Re: Bug#187537: r-base: FTBFS: hangs in tcltk test Message-ID: <20030407022029.GA17494@sonny.eddelbuettel.com> References: <87n0j6rbjw.fsf@frobnitz.ddts.net> <20030404122715.GB27144@sonny.eddelbuettel.com> <87of3kioq6.fsf@frobnitz.ddts.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87of3kioq6.fsf@frobnitz.ddts.net> User-Agent: Mutt/1.3.28i severity 187537 wishlist tags 187537 + upstream thanks I am downgrading because it a) does not affect normal build, b) does not affect autobuilders, and c) is not related to Debian changes to the build process as far as I can see. a) and b) take care of the downgraded severity, c) is for the upstream tag. Let me know if you disagree, strongly or mildly. Dirk -- Wishful thinking can dominate much of the work of a profession for a decade, but not indefinitely. -- Robert Shiller, on Efficient Markets models, 2002 ==> 2736.followup.1 <== From edd@debian.org Mon Apr 7 04:31:13 2003 Received: from sonny.eddelbuettel.com (mail@12-250-182-80.client.attbi.com [12.250.182.80]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h372VCpD019863 for ; Mon, 7 Apr 2003 04:31:13 +0200 (MET DST) Received: from edd by sonny.eddelbuettel.com with local (Exim 3.35 #1 (Debian)) id 192MPd-0004b7-00; Sun, 06 Apr 2003 21:31:09 -0500 Date: Sun, 6 Apr 2003 21:31:09 -0500 From: Dirk Eddelbuettel To: edd@debian.org Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Re: Bug#187537: r-base: FTBFS: hangs in tcltk test (PR#2736) Message-ID: <20030407023109.GA17645@sonny.eddelbuettel.com> References: <200304070220.h372KVpD019838@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304070220.h372KVpD019838@pubhealth.ku.dk> User-Agent: Mutt/1.3.28i Damn. That was meant for control@bugs.debian.org. Sorry for the line noise. Dirk On Mon, Apr 07, 2003 at 04:20:31AM +0200, edd@debian.org wrote: > severity 187537 wishlist > tags 187537 + upstream > thanks > > I am downgrading because it a) does not affect normal build, b) does not > affect autobuilders, and c) is not related to Debian changes to the build > process as far as I can see. a) and b) take care of the downgraded > severity, c) is for the upstream tag. > > Let me know if you disagree, strongly or mildly. > > Dirk > > -- > Wishful thinking can dominate much of the work of a profession for a decade, > but not indefinitely. -- Robert Shiller, on Efficient Markets models, 2002 > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > -- Wishful thinking can dominate much of the work of a profession for a decade, but not indefinitely. -- Robert Shiller, on Efficient Markets models, 2002 ==> 2736.audit <== Wed Apr 9 12:59:59 2003 ripley changed notes Wed Apr 9 12:59:59 2003 ripley foobar Wed Apr 9 13:01:29 2003 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2822 * Subject: "LAPACK routine DGESDD gave error code -12" with Debian From: Ramon Diaz Date: Tue, 22 Apr 2003 20:06:21 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2822 <== From rdiaz@cnio.es Tue Apr 22 20:07:35 2003 Received: from super-lopez.cnio.es (super-lopez.cnio.es [193.147.150.135]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3MI7ZpD014607 for ; Tue, 22 Apr 2003 20:07:35 +0200 (MET DST) Received: from filemon.cnio.es ([10.5.1.10]) by super-lopez.cnio.es with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Apr 2003 20:07:30 +0200 Received: from afrodita ([10.2.1.72]) by filemon.cnio.es with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Apr 2003 20:07:30 +0200 From: Ramon Diaz To: r-bugs@biostat.ku.dk Subject: "LAPACK routine DGESDD gave error code -12" with Debian Date: Tue, 22 Apr 2003 20:06:21 +0200 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200304222006.21884.rdiaz@cnio.es> X-OriginalArrivalTime: 22 Apr 2003 18:07:30.0071 (UTC) FILETIME=[0A183270:01C308FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id h3MI7ZpD014607 Dear All, Under Debian GNU/Linux La.svd (with method = "dgesdd") sometimes gives the error "Error in La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") : LAPACK routine DGESDD gave error code -12" It seems not to depend on the data per se, but on the relationship between numbers of rows and columns. For example, if the number of columns is 100, La.svd will fail when the number of rows is 56, but not if it is 55 or 57. It will not fail if we use "dgesvd". If the number of columns is 51, La.svd fails when the number of rows is between 29 and 50 if we use "dgesdd". This happens if I use the latest deb packages (and thus ATLAS, etc). It does not happen if I build R in this same machine with "--without-blas" (where make check reports no errors). In case it matters, the bug does not show up in a different machine with Windwos 2000 and the Rblas.dll linked against ATLAS provided in http://cran.r-project.org/bin/windows/contrib/ATLAS/P4). I understand this is probably related to the issues mentioned in R-admin about LAPACK 3.0 and some of the issues recently discussed in this list by M. Burger, D. Bates and D. Eddelbuettel. Are there any workarounds (besides not using ATLAS at all?). Ramón ******************************** An example of failure: > ## ncol = 100 > nrow <- 56 > ncol <- 100 > data <- matrix(1:(nrow * ncol), ncol = ncol) > ## you get the errors if you use any other data > ## such as data <- matrix(rnorm(nrow * ncol), ncol = ncol) > svd(data) ## error > La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") ## error > La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesvd") ## OK > ##ncol = 51; it fails with nrow in [29, 50] ************************* > ## version that crashes > version _ platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major 1 minor 7.0 year 2003 month 04 day 16 language R ***************************** > ## version "--without-blas" that does not crash > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 1 minor 7.0 year 2003 month 04 day 16 language R ----- Ramón Díaz-Uriarte Bioinformatics Unit Centro Nacional de Investigaciones Oncológicas (CNIO) (Spanish National Cancer Center) Melchor Fernández Almagro, 3 28029 Madrid (Spain) Fax: +-34-91-224-6972 Phone: +-34-91-224-6900 http://bioinfo.cnio.es/~rdiaz ==> 2822.followup.1 <== From edd@debian.org Wed Apr 23 02:32:53 2003 Received: from sonny.eddelbuettel.com (mail@12-250-182-80.client.attbi.com [12.250.182.80]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3N0WqpD016059 for ; Wed, 23 Apr 2003 02:32:52 +0200 (MET DST) Received: from edd by sonny.eddelbuettel.com with local (Exim 3.35 #1 (Debian)) id 1988Bq-00078P-00; Tue, 22 Apr 2003 19:32:46 -0500 Date: Tue, 22 Apr 2003 19:32:46 -0500 From: Dirk Eddelbuettel To: rdiaz@cnio.es Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk, kurt.hornik@r-project.org, camm@enhanced.com Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) Message-ID: <20030423003246.GA27400@sonny.eddelbuettel.com> References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200304221807.h3MI7apD014611@pubhealth.ku.dk> User-Agent: Mutt/1.3.28i On Tue, Apr 22, 2003 at 08:07:36PM +0200, rdiaz@cnio.es wrote: > Dear All, > > Under Debian GNU/Linux La.svd (with method = "dgesdd") sometimes gives the > error > > "Error in La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") : > LAPACK routine DGESDD gave error code -12" > > It seems not to depend on the data per se, but on the relationship between > numbers of rows and columns. > > For example, if the number of columns is 100, La.svd will fail when the number > of rows is 56, but not if it is 55 or 57. It will not fail if we use > "dgesvd". If the number of columns is 51, La.svd fails when the number of > rows is between 29 and 50 if we use "dgesdd". > > This happens if I use the latest deb packages (and thus ATLAS, etc). It does > not happen if I build R in this same machine with "--without-blas" (where > make check reports no errors). In case it matters, the bug does not show up > in a different machine with Windwos 2000 and the Rblas.dll linked against > ATLAS provided in http://cran.r-project.org/bin/windows/contrib/ATLAS/P4). > > I understand this is probably related to the issues mentioned in R-admin about > LAPACK 3.0 and some of the issues recently discussed in this list by M. > Burger, D. Bates and D. Eddelbuettel. Are there any workarounds (besides not > using ATLAS at all?). We should probably talk to Camm, the Atlas maintainer. Note how on recent upgrades he inserted the note (cf /var/lib/dpkg/info/atlas2-3dnow.templates on my Athlon system) via debconf: Template: atlas2-3dnow/3dnow_warning Type: note Description: 3dnow arithmetic is not IEEE compliant Please note that 3dnow arithmetic does not furnish several results required by the IEEE standard, and may therefore cause errors in code which needs to trap NaN and Inf results, for example. The atlas2-3dnow binaries make heavy use of the 3dnow extensions. Please see the accompanying file /usr/share/doc/atlas2-3dnow/3DNow.txt for details. I know Camm is on a sabbatical but will CC him nonetheless. Dirk > Ramón > > ******************************** > An example of failure: > > ## ncol = 100 > > nrow <- 56 > > ncol <- 100 > > data <- matrix(1:(nrow * ncol), ncol = ncol) > > ## you get the errors if you use any other data > > ## such as data <- matrix(rnorm(nrow * ncol), ncol = ncol) > > svd(data) ## error > > La.svd(data, nu = 0, > nv = min(nrow, ncol), method = "dgesdd") ## error > > La.svd(data, nu = 0, > nv = min(nrow, ncol), method = "dgesvd") ## OK > > > ##ncol = 51; it fails with nrow in [29, 50] > ************************* > > > ## version that crashes > > version > _ > platform i386-pc-linux-gnu > arch i386 > os linux-gnu > system i386, linux-gnu > status > major 1 > minor 7.0 > year 2003 > month 04 > day 16 > language R > ***************************** > > ## version "--without-blas" that does not crash > > version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 1 > minor 7.0 > year 2003 > month 04 > day 16 > language R > > > ----- > Ramón Díaz-Uriarte > Bioinformatics Unit > Centro Nacional de Investigaciones Oncológicas (CNIO) > (Spanish National Cancer Center) > Melchor Fernández Almagro, 3 > 28029 Madrid (Spain) > Fax: +-34-91-224-6972 > Phone: +-34-91-224-6900 > > http://bioinfo.cnio.es/~rdiaz > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > -- Don't drink and derive. Alcohol and algebra don't mix. ==> 2822.followup.2 <== From camm@enhanced.com Thu Apr 24 02:01:03 2003 Received: from intech19.enhanced.com (h-66-134-96-17.PHLAPAFG.covad.net [66.134.96.17]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3O012pD028248 for ; Thu, 24 Apr 2003 02:01:03 +0200 (MET DST) Received: from camm by intech19.enhanced.com with local (Exim 3.35 #1 (Debian)) id 198U9f-0001wP-00; Wed, 23 Apr 2003 19:59:59 -0400 To: Dirk Eddelbuettel Cc: rdiaz@cnio.es, r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk, kurt.hornik@r-project.org Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> <20030423003246.GA27400@sonny.eddelbuettel.com> From: Camm Maguire Date: 23 Apr 2003 19:59:59 -0400 In-Reply-To: <20030423003246.GA27400@sonny.eddelbuettel.com> Message-ID: <54el3swyrk.fsf@intech19.enhanced.com> Lines: 171 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pubhealth.ku.dk id h3O012pD028248 Greetings! 1) This should have nothing to do with atlas, as atlas does not tune this routine, meaning you are using the stock routine from lapack. nm --dynamic /usr/lib/liblapack_atlas.so.2.3 |grep dge 00003810 T ATL_dgetrf 00003590 T ATL_dgetrfC 00003870 T ATL_dgetrfR 00003ae0 T ATL_dgetrs 000047f0 T atl_f77wrap_dgesv__ 000048b0 T atl_f77wrap_dgetnb__ 000048e0 T atl_f77wrap_dgetrf__ 00004970 T atl_f77wrap_dgetrs__ U cblas_dgemm 00007c68 T clapack_dgesv 00007da0 T clapack_dgetrf 00007e90 T clapack_dgetrs 00009430 T dgesv_ 00009500 T dgetrf_ 000095b0 T dgetrs_ intech19:/fix/t2/camm/gcl-2.5.2$ You can check this by verifying that the difficulty persists if you set the LD_LIBRARY_PATH environment variable to /usr/lib 2) Given the error code, and the scaling behavior with matrix size, I'd say the lwork parameter (size of the work array) passed to dgesdd is not always large enough, i.e. is not scaling properly with n,m. Please see 'man dgesdd' for interpretations of the error code. It is the responsibility of the calling routine to allocate and pass the work array to dgesdd. With most lapack routines, one can make a 'workspace query' call first by setting lwork to -1, or some such. check the man page for details. This of course would have to be done with each change in n,m. Alternatively, you could take the minimum workspace requirements from the manpage. lapack is the relevant lib, so I don't know what --without-blas is supposed to do. And working under windows, while nice, doesn't exactly inspire confidence :-). I am in general away from email until 6/1, so correspondence will be spotty. Take care, Dirk Eddelbuettel writes: > On Tue, Apr 22, 2003 at 08:07:36PM +0200, rdiaz@cnio.es wrote: > > Dear All, > > > > Under Debian GNU/Linux La.svd (with method = "dgesdd") sometimes gives the > > error > > > > "Error in La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") : > > LAPACK routine DGESDD gave error code -12" > > > > It seems not to depend on the data per se, but on the relationship between > > numbers of rows and columns. > > > > For example, if the number of columns is 100, La.svd will fail when the number > > of rows is 56, but not if it is 55 or 57. It will not fail if we use > > "dgesvd". If the number of columns is 51, La.svd fails when the number of > > rows is between 29 and 50 if we use "dgesdd". > > > > This happens if I use the latest deb packages (and thus ATLAS, etc). It does > > not happen if I build R in this same machine with "--without-blas" (where > > make check reports no errors). In case it matters, the bug does not show up > > in a different machine with Windwos 2000 and the Rblas.dll linked against > > ATLAS provided in http://cran.r-project.org/bin/windows/contrib/ATLAS/P4). > > > > I understand this is probably related to the issues mentioned in R-admin about > > LAPACK 3.0 and some of the issues recently discussed in this list by M. > > Burger, D. Bates and D. Eddelbuettel. Are there any workarounds (besides not > > using ATLAS at all?). > > We should probably talk to Camm, the Atlas maintainer. Note how on recent > upgrades he inserted the note (cf /var/lib/dpkg/info/atlas2-3dnow.templates > on my Athlon system) via debconf: > > Template: atlas2-3dnow/3dnow_warning > Type: note > Description: 3dnow arithmetic is not IEEE compliant > Please note that 3dnow arithmetic does not furnish several results > required by the IEEE standard, and may therefore cause errors in code > which needs to trap NaN and Inf results, for example. The > atlas2-3dnow binaries make heavy use of the 3dnow extensions. > Please see the accompanying file /usr/share/doc/atlas2-3dnow/3DNow.txt > for details. > > I know Camm is on a sabbatical but will CC him nonetheless. > > Dirk > > > Ramón > > > > ******************************** > > An example of failure: > > > ## ncol = 100 > > > nrow <- 56 > > > ncol <- 100 > > > data <- matrix(1:(nrow * ncol), ncol = ncol) > > > ## you get the errors if you use any other data > > > ## such as data <- matrix(rnorm(nrow * ncol), ncol = ncol) > > > svd(data) ## error > > > La.svd(data, nu = 0, > > nv = min(nrow, ncol), method = "dgesdd") ## error > > > La.svd(data, nu = 0, > > nv = min(nrow, ncol), method = "dgesvd") ## OK > > > > > ##ncol = 51; it fails with nrow in [29, 50] > > ************************* > > > > > ## version that crashes > > > version > > _ > > platform i386-pc-linux-gnu > > arch i386 > > os linux-gnu > > system i386, linux-gnu > > status > > major 1 > > minor 7.0 > > year 2003 > > month 04 > > day 16 > > language R > > ***************************** > > > ## version "--without-blas" that does not crash > > > version > > _ > > platform i686-pc-linux-gnu > > arch i686 > > os linux-gnu > > system i686, linux-gnu > > status > > major 1 > > minor 7.0 > > year 2003 > > month 04 > > day 16 > > language R > > > > > > ----- > > Ramón Díaz-Uriarte > > Bioinformatics Unit > > Centro Nacional de Investigaciones Oncológicas (CNIO) > > (Spanish National Cancer Center) > > Melchor Fernández Almagro, 3 > > 28029 Madrid (Spain) > > Fax: +-34-91-224-6972 > > Phone: +-34-91-224-6900 > > > > http://bioinfo.cnio.es/~rdiaz > > > > ______________________________________________ > > R-devel@stat.math.ethz.ch mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > > -- > Don't drink and derive. Alcohol and algebra don't mix. > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ==> 2822.reply.1 <== From p.dalgaard@biostat.ku.dk Thu Apr 24 13:25:26 2003 Received: from blueberry.kubism.ku.dk (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3OBPQpD004849; Thu, 24 Apr 2003 13:25:26 +0200 (MET DST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id h3OBSN8e026637; Thu, 24 Apr 2003 13:28:23 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id h3OBSMe4026633; Thu, 24 Apr 2003 13:28:22 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: Camm Maguire Cc: Dirk Eddelbuettel , r-devel@stat.math.ethz.ch, kurt.hornik@r-project.org, R-bugs@biostat.ku.dk, rdiaz@cnio.es Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> <20030423003246.GA27400@sonny.eddelbuettel.com> <54el3swyrk.fsf@intech19.enhanced.com> From: Peter Dalgaard BSA Date: 24 Apr 2003 13:28:21 +0200 In-Reply-To: <54el3swyrk.fsf@intech19.enhanced.com> Message-ID: Lines: 58 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Camm Maguire writes: > 2) Given the error code, and the scaling behavior with matrix size, > I'd say the lwork parameter (size of the work array) passed to > dgesdd is not always large enough, i.e. is not scaling properly > with n,m. Please see 'man dgesdd' for interpretations of the error > code. It is the responsibility of the calling routine to allocate > and pass the work array to dgesdd. With most lapack routines, one > can make a 'workspace query' call first by setting lwork to -1, or > some such. check the man page for details. This of course would > have to be done with each change in n,m. Alternatively, you could > take the minimum workspace requirements from the manpage. Right, but that's actually what we do, use the workspace query. It's all very weird, because the -12 value indicates that the lwork parameter is wrong, but it is computed from an exactly identical call, except lwork=-l: lwork = -1; F77_CALL(dgesdd)(CHAR(STRING_ELT(jobu, 0)), &n, &p, xvals, &n, REAL(s), REAL(u), &ldu, REAL(v), &ldvt, &tmp, &lwork, iwork, &info); lwork = (int) tmp; work = (double *) R_alloc(lwork, sizeof(double)); F77_CALL(dgesdd)(CHAR(STRING_ELT(jobu, 0)), &n, &p, xvals, &n, REAL(s), REAL(u), &ldu, REAL(v), &ldvt, work, &lwork, iwork, &info); Also, this must be happening in the early parts of DGESDD which seem to be all integer storage size calculations and so shouldn't need the BLAS. Nevertheless people are seeing different behaviour when linking against different BLAS libraries. There are a lot of calls similar to this one, though: WRKBL = M + M*ILAENV( 1, 'DGELQF', ' ', M, N, -1, -1 ) so whether or not the BLAS is being used is hard to tell precisely. > lapack is the relevant lib, so I don't know what --without-blas is > supposed to do. And working under windows, while nice, doesn't > exactly inspire confidence :-). --without-blas means to use generic blas routines in the R sources rather than any (tuned) system set. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 2822.reply.2 <== From bates@bates4.stat.wisc.edu Thu Apr 24 19:03:24 2003 Received: from bates4.stat.wisc.edu (mail@bates4.stat.wisc.edu [128.105.174.134]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3OH3OpD008663; Thu, 24 Apr 2003 19:03:24 +0200 (MET DST) Received: from bates by bates4.stat.wisc.edu with local (Exim 3.36 #1 (Debian)) id 198k81-0004LK-00; Thu, 24 Apr 2003 12:03:21 -0500 To: Peter Dalgaard BSA Cc: Camm Maguire , Dirk Eddelbuettel , r-devel@stat.math.ethz.ch, kurt.hornik@r-project.org, R-bugs@biostat.ku.dk, rdiaz@cnio.es Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> <20030423003246.GA27400@sonny.eddelbuettel.com> <54el3swyrk.fsf@intech19.enhanced.com> From: Douglas Bates Date: 24 Apr 2003 12:03:21 -0500 In-Reply-To: Message-ID: <6r7k9j25gm.fsf@bates4.stat.wisc.edu> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Douglas Bates Peter Dalgaard BSA writes: > Camm Maguire writes: > > > 2) Given the error code, and the scaling behavior with matrix size, > > I'd say the lwork parameter (size of the work array) passed to > > dgesdd is not always large enough, i.e. is not scaling properly > > with n,m. Please see 'man dgesdd' for interpretations of the error > > code. It is the responsibility of the calling routine to allocate > > and pass the work array to dgesdd. With most lapack routines, one > > can make a 'workspace query' call first by setting lwork to -1, or > > some such. check the man page for details. This of course would > > have to be done with each change in n,m. Alternatively, you could > > take the minimum workspace requirements from the manpage. > > Right, but that's actually what we do, use the workspace query. It's > all very weird, because the -12 value indicates that the lwork > parameter is wrong, but it is computed from an exactly identical call, > except lwork=-l: > > lwork = -1; > > F77_CALL(dgesdd)(CHAR(STRING_ELT(jobu, 0)), > &n, &p, xvals, &n, REAL(s), > REAL(u), &ldu, > REAL(v), &ldvt, > &tmp, &lwork, iwork, &info); > lwork = (int) tmp; It looks like a problem in ilaenv, the Lapack routine that returns the tuning parameters, like the optimal temporary storage size, for various Lapack routines. The value returned in tmp will depend upon the results of several calls to ilaenv. These results can vary between different implementations of the blas (or atlas). ==> 2822.followup.3 <== From camm@enhanced.com Fri Apr 25 15:28:50 2003 Received: from intech19.enhanced.com (h-66-134-96-17.PHLAPAFG.covad.net [66.134.96.17]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3PDSnpD017958; Fri, 25 Apr 2003 15:28:50 +0200 (MET DST) Received: from camm by intech19.enhanced.com with local (Exim 3.35 #1 (Debian)) id 1993Fi-0007EL-00; Fri, 25 Apr 2003 09:28:34 -0400 To: Douglas Bates Cc: Peter Dalgaard BSA , Dirk Eddelbuettel , r-devel@stat.math.ethz.ch, kurt.hornik@r-project.org, R-bugs@biostat.ku.dk, rdiaz@cnio.es Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> <20030423003246.GA27400@sonny.eddelbuettel.com> <54el3swyrk.fsf@intech19.enhanced.com> <6r7k9j25gm.fsf@bates4.stat.wisc.edu> From: Camm Maguire Date: 25 Apr 2003 09:28:33 -0400 In-Reply-To: <6r7k9j25gm.fsf@bates4.stat.wisc.edu> Message-ID: <541xzqd7um.fsf@intech19.enhanced.com> Lines: 77 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Greetings! Douglas Bates writes: > Peter Dalgaard BSA writes: > > > Camm Maguire writes: > > > > > 2) Given the error code, and the scaling behavior with matrix size, > > > I'd say the lwork parameter (size of the work array) passed to > > > dgesdd is not always large enough, i.e. is not scaling properly > > > with n,m. Please see 'man dgesdd' for interpretations of the error > > > code. It is the responsibility of the calling routine to allocate > > > and pass the work array to dgesdd. With most lapack routines, one > > > can make a 'workspace query' call first by setting lwork to -1, or > > > some such. check the man page for details. This of course would > > > have to be done with each change in n,m. Alternatively, you could > > > take the minimum workspace requirements from the manpage. > > > > Right, but that's actually what we do, use the workspace query. It's > > all very weird, because the -12 value indicates that the lwork > > parameter is wrong, but it is computed from an exactly identical call, > > except lwork=-l: > > > > lwork = -1; > > > > F77_CALL(dgesdd)(CHAR(STRING_ELT(jobu, 0)), > > &n, &p, xvals, &n, REAL(s), > > REAL(u), &ldu, > > REAL(v), &ldvt, > > &tmp, &lwork, iwork, &info); > > lwork = (int) tmp; > > It looks like a problem in ilaenv, the Lapack routine that returns the > tuning parameters, like the optimal temporary storage size, for > various Lapack routines. The value returned in tmp will depend upon > the results of several calls to ilaenv. These results can vary between > different implementations of the blas (or atlas). > Just a note that you should check the returned info value on the workspace call to make sure tmp has been filled in. (the man page says this is done only if the other parameters are valid.) Does this problem vary with blas, and if so, how? You can run under whatever blas you want, including reference, via the LD_LIBRARY_PATH variable. Asuming you've installed all the i386 atlas versions and the blas package: LD_LIBRARY_PATH used blas: /usr/lib reference /usr/lib/atlas base vanilla i386 atlas /usr/lib/{sse,sse2,3dnow}/atlas atlas with ISA extensions ilaenv might possibly be an issue, but only realistically if the problem blas is coming from the 3dnow atlas. When I put together the lapack package, I read in the lapack notes how many of the ilaenv constants can be hardwired, saving a certain amount of time on the first call. I chose not to do this only because of the existence of the 3dnow, non-ieee compliant blas option at runtime, as one of the parameters pertains directly to ieee. So ilaenv is calculating its parameters n first call at runtime on Debian. I'm dubious as to the relevance of this, though, as this should only kick in for single precision if at all, and should not affect integer values in any case. Take care, > > > -- Camm Maguire camm@enhanced.com ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah ==> 2822.audit <== Thu May 29 09:51:58 2003 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2823 * Subject: Re: [Rd] From: Kurt Hornik Date: Tue, 22 Apr 2003 20:15:19 +0200 --part of 2822 ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2823 <== From hornik@ci.tuwien.ac.at Tue Apr 22 20:18:02 2003 Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.3.42]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3MIHxpD014666 for ; Tue, 22 Apr 2003 20:18:01 +0200 (MET DST) Received: from mithrandir.hornik.net (mail@wu057056.wu-wien.ac.at [137.208.57.56]) by isis.wu-wien.ac.at (8.12.8/8.12.6) with ESMTP id h3MIHvTn111298; Tue, 22 Apr 2003 20:17:57 +0200 (envelope-from hornik@ci.tuwien.ac.at) Received: from hornik by mithrandir.hornik.net with local (Exim 3.36 #1 (Debian)) id 1982Ij-0003cy-00; Tue, 22 Apr 2003 20:15:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <16037.34487.349521.950443@mithrandir.hornik.net> Date: Tue, 22 Apr 2003 20:15:19 +0200 To: rdiaz@cnio.es Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] "LAPACK routine DGESDD gave error code -12" with Debian (PR#2822) In-Reply-To: <200304221807.h3MI7apD014611@pubhealth.ku.dk> References: <200304221807.h3MI7apD014611@pubhealth.ku.dk> X-Mailer: VM 7.14 under Emacs 21.2.1 Reply-To: Kurt.Hornik@wu-wien.ac.at From: Kurt Hornik X-WU-uvscan-status: clean v4.2.40/v4258 popstar 939ae93a58c73b38bab120ead250ab8f >>>>> rdiaz writes: > Dear All, > Under Debian GNU/Linux La.svd (with method = "dgesdd") sometimes gives the > error > "Error in La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") : > LAPACK routine DGESDD gave error code -12" > It seems not to depend on the data per se, but on the relationship between > numbers of rows and columns. > For example, if the number of columns is 100, La.svd will fail when > the number of rows is 56, but not if it is 55 or 57. It will not fail > if we use "dgesvd". If the number of columns is 51, La.svd fails when > the number of rows is between 29 and 50 if we use "dgesdd". > This happens if I use the latest deb packages (and thus ATLAS, > etc). It does not happen if I build R in this same machine with > "--without-blas" (where make check reports no errors). In case it > matters, the bug does not show up in a different machine with Windwos > 2000 and the Rblas.dll linked against ATLAS provided in > http://cran.r-project.org/bin/windows/contrib/ATLAS/P4). > I understand this is probably related to the issues mentioned in > R-admin about LAPACK 3.0 and some of the issues recently discussed in > this list by M. Burger, D. Bates and D. Eddelbuettel. Are there any > workarounds (besides not using ATLAS at all?). > Ramón > ******************************** > An example of failure: >> ## ncol = 100 >> nrow <- 56 >> ncol <- 100 >> data <- matrix(1:(nrow * ncol), ncol = ncol) >> ## you get the errors if you use any other data >> ## such as data <- matrix(rnorm(nrow * ncol), ncol = ncol) >> svd(data) ## error >> La.svd(data, nu = 0, > nv = min(nrow, ncol), method = "dgesdd") ## error >> La.svd(data, nu = 0, > nv = min(nrow, ncol), method = "dgesvd") ## OK >> ##ncol = 51; it fails with nrow in [29, 50] > ************************* Confirmed on Debian GNU/Linux testing with atlas2-base-dev for both the current 1.7.0 debs and 1.8.0 built from scratch using --with-lapack: hornik@mithrandir:~/tmp$ ldd /usr/local/lib/R/modules/lapack.so libR.so => not found liblapack.so.2 => /usr/lib/atlas/liblapack.so.2 (0x40013000) -k ==> 2823.audit <== Fri Apr 25 20:07:18 2003 ripley changed notes Fri Apr 25 20:07:18 2003 ripley foobar Thu May 29 09:51:58 2003 ripley moved from incoming to System-specific ==> 2823.followup.1 <== From ckm@loafer.org Sun Nov 9 04:20:43 2003 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (localhost [127.0.0.1]) by slim.kubism.ku.dk (Postfix) with ESMTP id 67DC1F542 for ; Sun, 9 Nov 2003 04:20:43 +0100 (CET) Received: from a.mx.loafer.org (66-117-129-150.dsl.lmi.net [66.117.129.150]) by slim.kubism.ku.dk (Postfix) with SMTP id 42ACDF531 for ; Sun, 9 Nov 2003 04:20:42 +0100 (CET) Received: (qmail 13546 invoked from network); 9 Nov 2003 03:20:37 -0000 Received: from pez.loafer.org (192.168.1.102) by 0 with SMTP; 9 Nov 2003 03:20:37 -0000 Received: (qmail 2981 invoked by uid 1131); 9 Nov 2003 03:20:33 -0000 Date: 9 Nov 2003 03:20:33 -0000 Message-ID: <20031109032033.2980.qmail@pez.loafer.org> From: ckm@loafer.org To: r-bugs@biostat.ku.dk Subject: PR#2823 X-Virus-Scanned: by AMaViS snapshot-20020531 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2836 * Subject: R-1.7.0: build feedback: OpenBSD 3.2 From: "Nelson H. F. Beebe" Date: Thu, 24 Apr 2003 11:40:35 -0600 (MDT) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2836 <== From mailnull@stat.math.ethz.ch Thu Apr 24 19:40:47 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3OHekpD008818 for ; Thu, 24 Apr 2003 19:40:47 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3OHehbj018287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Apr 2003 19:40:44 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3OHeh4J018286 for R-bugs@biostat.ku.dk; Thu, 24 Apr 2003 19:40:43 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3OHecbi018265 for ; Thu, 24 Apr 2003 19:40:39 +0200 (MEST) Received: from sunshine.math.utah.edu ([128.110.198.2] ident=[P4jB9svowineRZeiXlmiwyPtw2TxQ1Uq]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 198ki7-0005DQ-00 for ; Thu, 24 Apr 2003 12:40:39 -0500 Received: from suncore.math.utah.edu (IDENT:vaj/hT8eYShMPb6CVAVnm2m9Sgdtj+7D@suncore.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id LAA24541; Thu, 24 Apr 2003 11:40:35 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3p2/8.9.3) id LAA22994; Thu, 24 Apr 2003 11:40:35 -0600 (MDT) Date: Thu, 24 Apr 2003 11:40:35 -0600 (MDT) From: "Nelson H. F. Beebe" To: r-bugs@r-project.org Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: R-1.7.0: build feedback: OpenBSD 3.2 Message-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) R-1.7.0 failed to build on OpenBSD 3.2: Machinetype: Intel Pentium III (600 MHz); OpenBSD 3.2 GENERIC#25 i386 Remote gcc version: gcc (GCC) 3.2.2 Remote g++ version: g++ (GCC) 3.2.2 Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib gcc -shared -Wl,-rpath,/usr/local/lib -o lapack.so Lapack.lo rgeev.lo rsyev.lo -L../../../bin -lRlapack -L/usr/lib/debug -L/usr/local/lib/gcc-lib/i386-unknown-openbsd3.2/3.2.2 -L/usr/local/lib/gcc-lib/i386-unknown-openbsd3.2/3.2.2/../../.. -lfrtbegin -lg2c -lm -lbz2 -lz -lreadline -lncurses -lm ld: -lRlapack: no match collect2: ld returned 1 exit status make[4]: *** [lapack.so] Error 1 make[4]: Leaving directory `/local/build/R-1.7.0/src/modules/lapack' The curious thing is that the library IS present, and should have been found via the -L path settings: % ls -l bin/libRlapack.so -rwxrwxr-x 1 beebe users 2453767 Apr 24 09:46 bin/libRlapack.so ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ==> 2836.audit <== Fri Apr 25 20:06:48 2003 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2837 * Subject: R-1.7.0 build feedback: NetBSD 1.6 From: "Nelson H. F. Beebe" Date: Thu, 24 Apr 2003 11:45:20 -0600 (MDT) --PR#3979 is followup ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2837 <== From mailnull@stat.math.ethz.ch Thu Apr 24 19:45:34 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3OHjYpD008850 for ; Thu, 24 Apr 2003 19:45:34 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3OHjUbj018990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Apr 2003 19:45:30 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h3OHjTo7018987 for R-bugs@biostat.ku.dk; Thu, 24 Apr 2003 19:45:29 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h3OHjNbi018964 for ; Thu, 24 Apr 2003 19:45:23 +0200 (MEST) Received: from sunshine.math.utah.edu ([128.110.198.2] ident=[gMxx9Uii3mR8kpPyHHCLWTMKyfh3qSrQ]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 198kmh-0005Eo-00 for ; Thu, 24 Apr 2003 12:45:23 -0500 Received: from suncore.math.utah.edu (IDENT:3SnKeLwLN3a70A+VbJ7UZpgXOotTyxom@suncore.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id LAA24834; Thu, 24 Apr 2003 11:45:20 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3p2/8.9.3) id LAA23043; Thu, 24 Apr 2003 11:45:20 -0600 (MDT) Date: Thu, 24 Apr 2003 11:45:20 -0600 (MDT) From: "Nelson H. F. Beebe" To: r-bugs@r-project.org Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: R-1.7.0 build feedback: NetBSD 1.6 Message-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) R-1.7.0 built on NetBSD 1.6, but the validation test suite failed: Machinetype: Intel Pentium III (600 MHz); NetBSD 1.6 (GENERIC) Remote gcc version: gcc (GCC) 3.2.2 Remote g++ version: g++ (GCC) 3.2.2 Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib make[5]: Entering directory `/local/build/R-1.7.0/src/library' >>> Building/Updating help pages for package 'base' Formats: text example make[5]: Leaving directory `/local/build/R-1.7.0/src/library' running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 make[4]: Leaving directory `/local/build/R-1.7.0/tests/Examples' make[3]: *** [test-Examples-Base] Error 2 make[3]: Leaving directory `/local/build/R-1.7.0/tests/Examples' make[2]: *** [test-Examples] Error 2 make[2]: Leaving directory `/local/build/R-1.7.0/tests' I forced the tests to run with "make -i check", getting output like this: running code in 'base-Ex.R' ...make[4]: [base-Ex.Rout] Error 1 (ignored) OK collecting examples for package 'ctest' ... make[5]: Entering directory `/local/build/R-1.7.0/src/library' >>> Building/Updating help pages for package 'ctest' Formats: text example make[5]: Leaving directory `/local/build/R-1.7.0/src/library' running code in 'ctest-Ex.R' ...make[4]: [ctest-Ex.Rout] Error 1 (ignored) OK ... mv: cannot stat `eval-etc.Rout': No such file or directory comparing 'eval-etc.Rout' to './eval-etc.Rout.save' ...2a3,158 > > #### eval / parse / deparse / substitute etc > > > > ##- From: Peter Dalgaard BSA > > ##- Subject: Re: source() / eval() bug ??? (PR#96) > > ##- Date: 20 Jan 1999 14:56:24 +0100 > > e1 <- parse(text='c(F=(f <- .3), "Tail area" = 2 * if(f < 1) 30 else 90)')[[1]] > > e1 > c(F = (f <- 0.3), "Tail area" = 2 * if (f < 1) 30 else 90) ... This is followed by 9900+ lines of differences. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ==> 2837.followup.1 <== From mailnull@stat.math.ethz.ch Sat May 3 16:10:04 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h43EA22b001234 for ; Sat, 3 May 2003 16:10:03 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h43E9xVn011233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 May 2003 16:09:59 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h43E9wbO011232 for R-bugs@biostat.ku.dk; Sat, 3 May 2003 16:09:58 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h43E9VVm011198 for ; Sat, 3 May 2003 16:09:32 +0200 (MEST) Received: from sunshine.math.utah.edu ([128.110.198.2] ident=[Kpx5BwJHYia4N37oBuUTfF8HhFza1/sF]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19Bxhj-0002R6-00 for ; Sat, 03 May 2003 09:09:31 -0500 Received: from suncore.math.utah.edu (IDENT:yFZdZiQeoEEvzYCyNJPCA467qCeS9Lcs@suncore.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id IAA23131; Sat, 3 May 2003 08:09:29 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3p2/8.9.3) id IAA13683; Sat, 3 May 2003 08:09:28 -0600 (MDT) Date: Sat, 3 May 2003 08:09:28 -0600 (MDT) From: "Nelson H. F. Beebe" To: Kurt.Hornik@wu-wien.ac.at Cc: beebe@math.utah.edu, r-bugs@r-project.org X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: [Rd] R-1.7.0 build feedback: NetBSD 1.6 (PR#2837) In-Reply-To: Your message of Fri, 2 May 2003 21:43:26 +0200 Message-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) This is a followup to my report of a SIGSEGV in R-1.7.0 built on NetBSD 1.6. Kurt Hornik responded: >> ... >> After some discussions on r-core, two suggestions. >> >> * It might be helpful to know if zlib has found in the OS or compiled >> from the sources within R: if the first you could try configure >> --without-zlib as it is possible the OS has a modified version. >> >> * You have >> >> R : Copyright 2003, The R Development Core Team >> Version 1.7.0 Under development (unstable) (2003-04-11) >> ^^^^^^^^^^^^^^^^^^^^^^ ^^^ >> >> and might just have hit a bad day of the r-devel daily snapshot. >> ... I don't think that the latter is the problem. This version built, validated, and installed on several other platforms. Since my initial bug report for this system, I upgraded the gcc release from 3.2.2 to the latest 3.2.3, so the compilation environment is now a bit different. I tried your suggestion of the --without-zlib configure option, and that produced a working R, which I've installed. There was one *.fail file in the tests directory: reg-tests-1.Rout.fail. It is 2280 lines long, and contains a fair number of "Error xxx" reports. In view of the gcc upgrade, I'm going to go back now and do a fresh build, and see if the zlib problem recurs. Here is a copy of reg-tests-1.Rout.fail: R : Copyright 2003, The R Development Core Team Version 1.7.0 Under development (unstable) (2003-04-11) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type `license()' or `licence()' for distribution details. R is a collaborative project with many contributors. Type `contributors()' for more information. Type `demo()' for some demos, `help()' for on-line help, or `help.start()' for a HTML browser interface to help. Type `q()' to quit R. > ## regression test for PR#376 > aggregate(ts(1:20), nfreq=1/3) Time Series: Start = 1 End = 16 Frequency = 0.333333333333333 [1] 6 15 24 33 42 51 > ## Comments: moved from aggregate.Rd > > > ## aperm > # check the names > x <- array(1:24, c(4, 6)) > nms <- list(happy=letters[1:4], sad=LETTERS[1:6]) > > dimnames(x) <- nms > tmp <- aperm(x, c(2, 1)) > stopifnot(all.equal(dimnames(tmp), nms[c(2, 1)])) > > dimnames(x) <- c(nms[1], list(NULL)) > tmp <- aperm(x, c(2, 1)) > stopifnot(all.equal(dimnames(tmp), c(list(NULL), nms[1]))) > > names(nms) <- c("happy", "sad") > dimnames(x) <- nms > tmp <- aperm(x, c(2, 1)) > stopifnot(all.equal(names(dimnames(tmp)), names(nms[c(2, 1)]))) > > dimnames(x) <- c(nms[1], list(NULL)) > tmp <- aperm(x, c(2, 1)) > stopifnot(all.equal(names(dimnames(tmp)), c("", names(nms)[1]))) > > # check resize > stopifnot(dim(aperm(x, c(2, 1), FALSE)) == dim(x)) > stopifnot(is.null(dimnames(aperm(x, c(2, 1), FALSE)))) > > # check the types > x <- array(1:24, c(4, 6)) > stopifnot(all.equal(aperm(x, c(2, 1)), t(x))) > stopifnot(is.integer(aperm(x, c(2, 1)))) > > x <- x + 0.0 > stopifnot(all.equal(aperm(x, c(2, 1)), t(x))) > stopifnot(is.double(aperm(x, c(2, 1)))) > > x <- x + 0.0i > stopifnot(all.equal(aperm(x, c(2, 1)), t(x))) > > x[] <- LETTERS[1:24] > stopifnot(all.equal(aperm(x, c(2, 1)), t(x))) > > x <- array(list("fred"), c(4, 6)) > x[[3, 4]] <- 1:10 > stopifnot(all.equal(aperm(x, c(2, 1)), t(x))) > ## end of moved from aperm.Rd > > > ## append > stopifnot(append(1:5, 0:1, after=3) == append(1:3, c(0:1, 4:5))) > ## end of moved from append.Rd > > > ## as.POSIXlt > z <- Sys.time() > stopifnot(range(z) == z, + min(z) == z, + max(z) == z, + mean(z) == z) > ## end of moved from as.POSIXlt.Rd > > > ## autoload > stopifnot(ls("Autoloads") == ls(envir = .AutoloadEnv)) > ## end of moved from autoload.Rd > > > ## backsolve > r <- rbind(c(1,2,3), + c(0,1,1), + c(0,0,2)) > ( y <- backsolve(r, x <- c(8,4,2)) ) # -1 3 1 [1] -1 3 1 > r %*% y # == x = (8,4,2) [,1] [1,] 8 [2,] 4 [3,] 2 > ( y2 <- backsolve(r, x, transpose = TRUE)) # 8 -12 -5 [1] 8 -12 -5 > stopifnot(all.equal(drop(t(r) %*% y2), x)) > stopifnot(all.equal(y, backsolve(t(r), x, upper = FALSE, transpose = TRUE))) > stopifnot(all.equal(y2, backsolve(t(r), x, upper = FALSE, transpose = FALSE))) > ## end of moved from backsolve.Rd > > > ## basename > dirname(character(0)) character(0) > ## end of moved from basename.Rd > > > ## Bessel > ## Check the Scaling : > nus <- c(0:5,10,20) > x <- seq(0,40,len=801)[-1] > for(nu in nus) + stopifnot(abs(1- besselK(x,nu)*exp( x) / besselK(x,nu,expo=TRUE)) < 2e-15) > for(nu in nus) + stopifnot(abs(1- besselI(x,nu)*exp(-x) / besselI(x,nu,expo=TRUE)) < 1e-15) > ## end of moved from Bessel.Rd > > > ## c > ll <- list(A = 1, c="C") > stopifnot(identical(c(ll, d=1:3), c(ll, as.list(c(d=1:3))))) > ## moved from c.Rd > > > ## Cauchy > stopifnot(all.equal(dcauchy(-1:4), 1 / (pi*(1 + (-1:4)^2)))) > ## end of moved from Cauchy.Rd > > > ## chol > ( m <- matrix(c(5,1,1,3),2,2) ) [,1] [,2] [1,] 5 1 [2,] 1 3 > ( cm <- chol(m) ) [,1] [,2] [1,] 2.236068 0.4472136 [2,] 0.000000 1.6733201 > stopifnot(abs(m - t(cm) %*% cm) < 100* .Machine$double.eps) > ( Lcm <- La.chol(m) ) [,1] [,2] [1,] 2.236068 0.4472136 [2,] 0.000000 1.6733201 > stopifnot(abs(m - crossprod(Lcm)) < 100* .Machine$double.eps) > > ## check with pivoting > ( m <- matrix(c(5,1,1,3),2,2) ) [,1] [,2] [1,] 5 1 [2,] 1 3 > ( cm <- chol(m, TRUE) ) [,1] [,2] [1,] 2.236068 0.4472136 [2,] 0.000000 1.6733201 attr(,"pivot") [1] 1 2 attr(,"rank") [1] 2 > stopifnot(abs(m - t(cm) %*% cm) < 100* .Machine$double.eps) > > x <- matrix(c(1:5, (1:5)^2), 5, 2) > m <- crossprod(x) > Q <- chol(m) > stopifnot(all.equal(t(Q) %*% Q, m)) > > Q <- chol(m, pivot = TRUE) > pivot <- attr(Q, "pivot") > oo <- order(pivot) > stopifnot(all.equal(t(Q[, oo]) %*% Q[, oo], m)) > stopifnot(all.equal(t(Q) %*% Q, m[pivot, pivot])) > > # now for something positive semi-definite > x <- cbind(x, x[, 1]+3*x[, 2]) > m <- crossprod(x) > qr(m)$rank # is 2, as it should be [1] 2 > > (Q <- chol(m, pivot = TRUE)) # NB wrong rank here ... see Warning section. [,1] [,2] [,3] [1,] 101.0742 7.222415 3.128394e+01 [2,] 0.0000 1.684259 -5.614195e-01 [3,] 0.0000 0.000000 1.010646e-07 attr(,"pivot") [1] 3 1 2 attr(,"rank") [1] 3 > pivot <- attr(Q, "pivot") > oo <- order(pivot) > stopifnot(all.equal(t(Q[, oo]) %*% Q[, oo], m)) > stopifnot(all.equal(t(Q) %*% Q, m[pivot, pivot])) > ## end of moved from chol.Rd > > > ## chol2inv > cma <- chol(ma <- cbind(1, 1:3, c(1,3,7))) > stopifnot(all.equal(diag(3), ma %*% chol2inv(cma))) > stopifnot(all.equal(diag(3), ma %*% La.chol2inv(cma))) > ## end of moved from chol2inv.Rd > > > ## col2rgb > pp <- palette(); names(pp) <- pp # add & use names : > stopifnot(col2rgb(1:8) == print(col2rgb(pp))) black red green3 blue cyan magenta yellow gray red 0 255 0 0 0 255 255 190 green 0 0 205 0 255 0 255 190 blue 0 0 0 255 255 255 0 190 > stopifnot(col2rgb("#08a0ff") == c(8, 160, 255)) > grC <- col2rgb(paste("gray",0:100,sep="")) > stopifnot(grC["red",] == grC["green",], + grC["red",] == grC["blue",], + grC["red", 1:4] == c(0,3,5,8)) > ## end of moved from col2rgb.Rd > > > ## complex > z <- 0i ^ (-3:3) > stopifnot(Re(z) == 0 ^ (-3:3)) > set.seed(123) > z <- complex(real = rnorm(100), imag = rnorm(100)) > stopifnot(Mod ( 1 - sin(z) / ( (exp(1i*z)-exp(-1i*z))/(2*1i) )) + < 20 * .Machine$double.eps) > ## end of moved from complex.Rd > > > ## Constants > stopifnot( + nchar(letters) == 1, + month.abb == substr(month.name, 1, 3) + ) > > eps <- .Machine$double.eps > stopifnot(all.equal(pi, 4*atan(1), tol= 2*eps)) > > # John Machin (1705) computed 100 decimals of pi : > stopifnot(all.equal(pi/4, 4*atan(1/5) - atan(1/239), 4*eps)) > ## end of moved from Constants.Rd > > > ## cor > stopifnot( is.na(var(1)), + !is.nan(var(1))) > > zz <- c(-1.30167, -0.4957, -1.46749, 0.46927) > r <- cor(zz,zz); r - 1 [1] 0 > stopifnot(r <= 1) # fails in R <= 1.3.x, for versions of Linux and Solaris > ## end of moved from cor.Rd > > > ## DateTimeClasses > (dls <- .leap.seconds[-1] - .leap.seconds[-22]) Time differences of 184, 365, 365, 365, 366, 365, 365, 365, 547, 730, 731, 365, 549, 731, 365, 547, 365, 365, 549, 547, 549 days > table(dls) dls 184 365 366 547 549 730 731 1 10 1 3 3 1 2 > ## end of moved from DateTimeClasses.Rd > > > ## deriv > trig.exp <- expression(sin(cos(x + y^2))) > D.sc <- D(trig.exp, "x") > dxy <- deriv(trig.exp, c("x", "y")) > y <- 1 > stopifnot(eval(D.sc) == + attr(eval(dxy),"gradient")[,"x"]) > ff <- y ~ sin(cos(x) * y) > stopifnot(all.equal(deriv(ff, c("x","y"), func = TRUE ), + deriv(ff, c("x","y"), func = function(x,y){ } ))) > ## end of moved from deriv.Rd > > > ## diff > x <- cumsum(cumsum(1:10)) > stopifnot(diff(x, lag = 2) == x[(1+2):10] - x[1:(10 - 2)], + diff(x, lag = 2) == (3:10)^2, + diff(diff(x)) == diff(x, differences = 2)) > ## end of moved from diff.Rd > > > ## duplicated > x <- c(9:20, 1:5, 3:7, 0:8) > ## extract unique elements > (xu <- x[!duplicated(x)]) [1] 9 10 11 12 13 14 15 16 17 18 19 20 1 2 3 4 5 6 7 0 8 > stopifnot(xu == unique(x), # but unique(x) is more efficient + 0:20 == sort(x[!duplicated(x)])) > > data(iris) > stopifnot(duplicated(iris)[143] == TRUE) > ## end of moved from duplicated.Rd > > > ## eigen > Meps <- .Machine$double.eps > set.seed(321, kind = "default") # force a particular seed > m <- matrix(round(rnorm(25),3), 5,5) > sm <- m + t(m) #- symmetric matrix > em <- eigen(sm); V <- em$vect > print(lam <- em$values) # ordered DEcreasingly [1] 5.1738946 3.1585064 0.6849974 -1.6299494 -2.5074489 > > stopifnot( + abs(sm %*% V - V %*% diag(lam)) < 60*Meps, + abs(sm - V %*% diag(lam) %*% t(V)) < 60*Meps) > > ##------- Symmetric = FALSE: -- different to above : --- > > em <- eigen(sm, symmetric = FALSE); V2 <- em$vect > print(lam2 <- em$values) # ordered decreasingly in ABSolute value ! [1] 5.1738946 3.1585064 -2.5074489 -1.6299494 0.6849974 > print(i <- rev(order(lam2))) [1] 1 2 5 4 3 > stopifnot(abs(lam - lam2[i]) < 60 * Meps) > > zapsmall(Diag <- t(V2) %*% V2) [,1] [,2] [,3] [,4] [,5] [1,] 1 0 0 0 0 [2,] 0 1 0 0 0 [3,] 0 0 1 0 0 [4,] 0 0 0 1 0 [5,] 0 0 0 0 1 > stopifnot( abs(1- diag(Diag)) < 60*Meps) > > stopifnot(abs(sm %*% V2 - V2 %*% diag(lam2)) < 60*Meps, + abs(sm - V2 %*% diag(lam2) %*% t(V2)) < 60*Meps) > > ## Re-ordered as with symmetric: > sV <- V2[,i] > slam <- lam2[i] > stopifnot(abs(sm %*% sV - sV %*% diag(slam)) < 60*Meps) > stopifnot(abs(sm - sV %*% diag(slam) %*% t(sV)) < 60*Meps) > ## sV *is* now equal to V -- up to sign (+-) and rounding errors > stopifnot(abs(c(1 - abs(sV / V))) < 1000*Meps) > ## end of moved from eigen.Rd > > > ## euro > data(euro) > stopifnot(euro == signif(euro,6), euro.cross == outer(1/euro, euro)) > ## end of moved from euro.Rd > > > ## Exponential > r <- rexp(100) > stopifnot(abs(1 - dexp(1, r) / (r*exp(-r))) < 1e-14) > ## end of moved from Exponential.Rd > > > ## family > gf <- Gamma() > stopifnot(1:10 == gf$linkfun(gf$linkinv(1:10))) > ## end of moved from family.Rd > > > ## fft > set.seed(123) > eps <- 1e-11 > for(N in 1:130) { + x <- rnorm(N) + if(N %% 5 == 0) { + m5 <- matrix(x,ncol=5) + stopifnot(apply(m5,2,fft) == mvfft(m5)) + } + dd <- Mod(1 - (f2 <- fft(fft(x), inverse=TRUE)/(x*length(x)))) + stopifnot(dd < eps) + } > ## end of moved from fft.Rd > > > ## findint > N <- 100 > X <- sort(round(rt(N, df=2), 2)) > tt <- c(-100, seq(-2,2, len=201), +100) > it <- findInterval(tt, X) > > ## See that this is N * Fn(.) : > tt <- c(tt,X) > eps <- 100 * .Machine$double.eps > require(stepfun) Loading required package: stepfun [1] TRUE > stopifnot(it[c(1,203)] == c(0, 100), + all.equal(N * ecdf(X)(tt), + findInterval(tt, X), tol = eps), + findInterval(tt,X) == apply( outer(tt, X, ">="), 1, sum) + ) > ## end of moved from findint.Rd > > > ## format > (dd <- sapply(1:10, function(i)paste((9:0)[1:i],collapse=""))) [1] "9" "98" "987" "9876" "98765" [6] "987654" "9876543" "98765432" "987654321" "9876543210" > np <- nchar(pd <- prettyNum(dd, big.mark="'")) > stopifnot(sapply(0:2, function(m) + all(grep("'", substr(pd, 1, np - 4*m)) == (4+3*m):10))) > ## end of moved from format.Rd > > > ## Geometric > pp <- sort(c((1:9)/10, 1 - .2^(2:8))) > print(qg <- qgeom(pp, prob = .2)) [1] 0 0 1 2 3 4 5 7 10 14 21 28 36 43 50 57 > ## test that qgeom is an inverse of pgeom > print(qg1 <- qgeom(pgeom(qg, prob=.2), prob =.2)) [1] 0 0 1 2 3 4 5 7 10 14 21 28 36 43 50 57 ==> 2837.followup.2 <== From ripley@stats.ox.ac.uk Sat May 3 18:07:46 2003 Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.20.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h43G7j2b001509 for ; Sat, 3 May 2003 18:07:45 +0200 (MET DST) Received: from gannet.stats (gannet.stats [163.1.20.127]) by toucan.stats.ox.ac.uk (8.12.9/8.12.9) with ESMTP id h43G7iUK026908; Sat, 3 May 2003 17:07:44 +0100 (BST) Date: Sat, 3 May 2003 17:07:44 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: beebe@math.utah.edu cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] R-1.7.0 build feedback: NetBSD 1.6 (PR#2837) In-Reply-To: <200305031410.h43EAB2b001238@pubhealth.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 3 May 2003 beebe@math.utah.edu wrote: > This is a followup to my report of a SIGSEGV in R-1.7.0 built > on NetBSD 1.6. > > Kurt Hornik responded: > > >> ... > >> After some discussions on r-core, two suggestions. > >> > >> * It might be helpful to know if zlib has found in the OS or compiled > >> from the sources within R: if the first you could try configure > >> --without-zlib as it is possible the OS has a modified version. > >> > >> * You have > >> > >> R : Copyright 2003, The R Development Core Team > >> Version 1.7.0 Under development (unstable) (2003-04-11) > >> ^^^^^^^^^^^^^^^^^^^^^^ ^^^ > >> > >> and might just have hit a bad day of the r-devel daily snapshot. > >> ... > > I don't think that the latter is the problem. This version built, > validated, and installed on several other platforms. > > Since my initial bug report for this system, I upgraded the gcc > release from 3.2.2 to the latest 3.2.3, so the compilation environment > is now a bit different. > > I tried your suggestion of the --without-zlib configure option, and > that produced a working R, which I've installed. There was one *.fail > file in the tests directory: reg-tests-1.Rout.fail. It is 2280 lines > long, and contains a fair number of "Error xxx" reports. About 12 are expected. The error will be in the last command line, so only the last few lines of the file are relevant: to wit > ## pweibull(large, log=T): > stopifnot(pweibull(seq(1,50,len=1001), 2,3, log = TRUE) < 0) Error: pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) < 0 is not TRUE for which you would need to investigate the output of pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) and I guess that this is an accuracy problem in the runtime (libc). -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 2837.followup.3 <== From mailnull@stat.math.ethz.ch Sun May 4 16:05:08 2003 Received: from hypatia.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h44E572b004715 for ; Sun, 4 May 2003 16:05:08 +0200 (MET DST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h44E54Vn021972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 May 2003 16:05:04 +0200 (MEST) Received: (from mailnull@localhost) by hypatia.math.ethz.ch (8.12.9/8.12.6/Submit) id h44E54OH021967 for R-bugs@biostat.ku.dk; Sun, 4 May 2003 16:05:04 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by hypatia.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h44E4qVm021809 for ; Sun, 4 May 2003 16:04:52 +0200 (MEST) Received: from sunshine.math.utah.edu ([128.110.198.2] ident=[I6d9LC0zKIVZGy1Fx7n2/rXULuWgbU18]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19CK6m-00043O-00 for ; Sun, 04 May 2003 09:04:52 -0500 Received: from suncore.math.utah.edu (IDENT:bHftZpkqdwdSaDBF4o7e+TqImxj8h41k@suncore.math.utah.edu [128.110.198.5]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id IAA16217; Sun, 4 May 2003 08:04:49 -0600 (MDT) Received: (from beebe@localhost) by suncore.math.utah.edu (8.9.3p2/8.9.3) id IAA04834; Sun, 4 May 2003 08:04:48 -0600 (MDT) Date: Sun, 4 May 2003 08:04:48 -0600 (MDT) From: "Nelson H. F. Beebe" To: r-bugs@r-project.org Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: [Rd] R-1.7.0 build feedback: NetBSD 1.6 (PR#2837): final report Message-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) I've now done two rebuilds of R-1.7.0 on NetBSD 1.6, one with the --without-zlib configure option, and one without. Both builds use the recently-installed gcc-3.2.3 compiler. As before, the one built normally gets a segment violation, whereas the one built with the --without-zlib option works. The odd thing is that neither uses shared libraries for zlib: % ldd /usr/local/lib/R/bin/R.bin /usr/local/lib/R/bin/R.bin: -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lg2c.0 => /usr/local/lib/libg2c.so.0 -lc.12 => /usr/lib/libc.so.12 -lgcc_s.1 => /usr/local/lib/libgcc_s.so.1 The other build shows the same library list. The NetBSD 1.6 system ships with these libraries: /usr/lib/libz.a /usr/lib/libz.so.0 /usr/lib/libz_p.a /usr/lib/libz.so /usr/lib/libz.so.0.2 /usr/lib/libz_pic.a but the pkg_info commands on NetBSD and OpenBSD produce no output. There seems to be no simple way to confirm the zlib version on these systems. Running strings and nm on libz.a produces no useful identification. However, /usr/include/zlib.h reports "version 1.1.4, March 11th, 2002", which is the same as the one that I installed in /usr/local/, and is the latest stable release (I'm on the zlib beta testers list). That number is confirmed by this simple test program: % cat show-zlib-version.c #include #include #include int main() { (void)printf("zlibVersion() reports [%s]\n", zlibVersion()); return (EXIT_SUCCESS); } % cc show-zlib-version.c -lz && ./a.out zlibVersion() reports [1.1.4] The bad one only segment faults after installation. If I run it in the build tree as bin/R, it works, and passes all but the base-Ex test. Brian Ripley responds to the reg-tests-1.Rout.fail file found in the working build: >> ... >> The error will be in the last command line, so >> only the last few lines of the file are relevant: to wit >> >> > ## pweibull(large, log=T): >> > stopifnot(pweibull(seq(1,50,len=1001), 2,3, log = TRUE) < 0) >> Error: pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) < 0 is not TRUE >> >> for which you would need to investigate the output of >> >> pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) >> >> and I guess that this is an accuracy problem in the runtime (libc). >> ... Here is what I get in that output: % R R : Copyright 2003, The R Development Core Team Version 1.7.0 Under development (unstable) (2003-04-11) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type `license()' or `licence()' for distribution details. R is a collaborative project with many contributors. Type `contributors()' for more information. Type `demo()' for some demos, `help()' for on-line help, or `help.start()' for a HTML browser interface to help. Type `q()' to quit R. > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) [1] -2.252266e+00 -2.162061e+00 -2.076474e+00 -1.995124e+00 -1.917675e+00 [6] -1.843830e+00 -1.773331e+00 -1.705943e+00 -1.641459e+00 -1.579693e+00 [11] -1.520477e+00 -1.463659e+00 -1.409102e+00 -1.356679e+00 -1.306276e+00 [16] -1.257788e+00 -1.211118e+00 -1.166177e+00 -1.122883e+00 -1.081160e+00 [21] -1.040937e+00 -1.002149e+00 -9.647332e-01 -9.286334e-01 -8.937957e-01 [26] -8.601698e-01 -8.277083e-01 -7.963667e-01 -7.661032e-01 -7.368779e-01 [31] -7.086534e-01 -6.813940e-01 -6.550661e-01 -6.296376e-01 -6.050778e-01 [36] -5.813577e-01 -5.584494e-01 -5.363265e-01 -5.149634e-01 -4.943358e-01 [41] -4.744204e-01 -4.551946e-01 -4.366369e-01 -4.187266e-01 -4.014437e-01 [46] -3.847688e-01 -3.686833e-01 -3.531692e-01 -3.382092e-01 -3.237864e-01 [51] -3.098845e-01 -2.964877e-01 -2.835807e-01 -2.711486e-01 -2.591770e-01 [56] -2.476519e-01 -2.365597e-01 -2.258870e-01 -2.156210e-01 -2.057491e-01 [61] -1.962592e-01 -1.871392e-01 -1.783776e-01 -1.699631e-01 -1.618847e-01 [66] -1.541315e-01 -1.466932e-01 -1.395596e-01 -1.327205e-01 -1.261664e-01 [71] -1.198878e-01 -1.138753e-01 -1.081199e-01 -1.026130e-01 -9.734578e-02 [76] -9.231000e-02 -8.749747e-02 -8.290025e-02 -7.851057e-02 -7.432090e-02 [81] -7.032386e-02 -6.651231e-02 -6.287926e-02 -5.941794e-02 -5.612173e-02 [86] -5.298423e-02 -4.999919e-02 -4.716054e-02 -4.446239e-02 -4.189903e-02 [91] -3.946490e-02 -3.715463e-02 -3.496298e-02 -3.288491e-02 -3.091551e-02 [96] -2.905005e-02 -2.728393e-02 -2.561271e-02 -2.403212e-02 -2.253801e-02 [101] -2.112637e-02 -1.979336e-02 -1.853526e-02 -1.734848e-02 -1.622957e-02 [106] -1.517522e-02 -1.418223e-02 -1.324752e-02 -1.236817e-02 -1.154132e-02 [111] -1.076427e-02 -1.003442e-02 -9.349278e-03 -8.706452e-03 -8.103661e-03 [116] -7.538723e-03 -7.009554e-03 -6.514161e-03 -6.050648e-03 -5.617201e-03 [121] -5.212098e-03 -4.833694e-03 -4.480428e-03 -4.150814e-03 -3.843441e-03 [126] -3.556967e-03 -3.290122e-03 -3.041701e-03 -2.810561e-03 -2.595622e-03 [131] -2.395859e-03 -2.210307e-03 -2.038050e-03 -1.878228e-03 -1.730026e-03 [136] -1.592676e-03 -1.465456e-03 -1.347685e-03 -1.238723e-03 -1.137968e-03 [141] -1.044855e-03 -9.588518e-04 -8.794615e-04 -8.062168e-04 -7.386800e-04 [146] -6.764415e-04 -6.191181e-04 -5.663515e-04 -5.178069e-04 -4.731716e-04 [151] -4.321541e-04 -3.944823e-04 -3.599030e-04 -3.281801e-04 -2.990941e-04 [156] -2.724409e-04 -2.480308e-04 -2.256875e-04 -2.052476e-04 -1.865595e-04 [161] -1.694827e-04 -1.538870e-04 -1.396520e-04 -1.266662e-04 -1.148267e-04 [166] -1.040384e-04 -9.421341e-05 -8.527081e-05 -7.713589e-05 -6.973986e-05 [171] -6.301937e-05 -5.691614e-05 -5.137658e-05 -4.635146e-05 -4.179554e-05 [176] -3.766734e-05 -3.392878e-05 -3.054498e-05 -2.748400e-05 -2.471657e-05 [181] -2.221595e-05 -1.995767e-05 -1.791939e-05 -1.608070e-05 -1.442298e-05 [186] -1.292925e-05 -1.158404e-05 -1.037325e-05 -9.284062e-06 -8.304808e-06 [191] -7.424880e-06 -6.634643e-06 -5.925350e-06 -5.289063e-06 -4.718585e-06 [196] -4.207393e-06 -3.749581e-06 -3.339801e-06 -2.973218e-06 -2.645460e-06 [201] -2.352578e-06 -2.091005e-06 -1.857524e-06 -1.649233e-06 -1.463518e-06 [206] -1.298022e-06 -1.150627e-06 -1.019425e-06 -9.027020e-07 -7.989171e-07 [211] -7.066874e-07 -6.247715e-07 -5.520563e-07 -4.875440e-07 -4.303409e-07 [216] -3.796467e-07 -3.347456e-07 -2.949976e-07 -2.598306e-07 -2.287339e-07 [221] -2.012514e-07 -1.769765e-07 -1.555466e-07 -1.366387e-07 -1.199652e-07 [226] -1.052701e-07 -9.232584e-08 -8.093002e-08 -7.090295e-08 -6.208508e-08 [231] -5.433485e-08 -4.752674e-08 -4.154950e-08 -3.630461e-08 -3.170488e-08 [236] -2.767316e-08 -2.414125e-08 -2.104887e-08 -1.834283e-08 -1.597615e-08 [241] -1.390740e-08 -1.210008e-08 -1.052202e-08 -9.144876e-09 -7.943739e-09 [246] -6.896685e-09 -5.984448e-09 -5.190104e-09 -4.498796e-09 -3.897489e-09 [251] -3.374750e-09 -2.920564e-09 -2.526156e-09 -2.183845e-09 -1.886912e-09 [256] -1.629483e-09 -1.406425e-09 -1.213253e-09 -1.046054e-09 -9.014167e-10 [261] -7.763638e-10 -6.683025e-10 -5.749754e-10 -4.944174e-10 -4.249193e-10 [266] -3.649955e-10 -3.133551e-10 -2.688775e-10 -2.305899e-10 -1.976489e-10 [271] -1.693233e-10 -1.449798e-10 -1.240699e-10 -1.061191e-10 -9.071710e-11 [276] -7.750911e-11 -6.618894e-11 -5.649181e-11 -4.818967e-11 -4.108569e-11 [281] -3.501033e-11 -2.981737e-11 -2.538114e-11 -2.159339e-11 -1.836120e-11 [286] -1.560441e-11 -1.325440e-11 -1.125233e-11 -9.547585e-12 -8.096857e-12 [291] -6.862844e-12 -5.813794e-12 -4.922507e-12 -4.165557e-12 -3.523182e-12 [296] -2.978284e-12 -2.516320e-12 -2.124856e-12 -1.793343e-12 -1.512790e-12 [301] -1.275424e-12 -1.074696e-12 -9.050538e-13 -7.618350e-13 -6.409318e-13 [306] -5.389023e-13 -4.528600e-13 -3.803624e-13 -3.193001e-13 -2.678968e-13 [311] -2.247091e-13 -1.882938e-13 -1.577627e-13 -1.321165e-13 -1.105782e-13 [316] -9.248158e-14 -7.727152e-14 -6.461498e-14 -5.395684e-14 -4.496403e-14 [321] -3.752554e-14 -3.130829e-14 -2.609024e-14 -2.176037e-14 -1.809664e-14 [326] -1.498801e-14 -1.254552e-14 -1.043610e-14 -8.659740e-15 -7.216450e-15 [331] -5.995204e-15 -4.884981e-15 -4.107825e-15 -3.330669e-15 -2.775558e-15 [336] -2.331468e-15 -1.887379e-15 -1.554312e-15 -1.332268e-15 -1.110223e-15 [341] -8.881784e-16 -7.771561e-16 -5.551115e-16 -5.551115e-16 -4.440892e-16 [346] -3.330669e-16 -3.330669e-16 -2.220446e-16 -2.220446e-16 -1.110223e-16 [351] -1.110223e-16 -1.110223e-16 -1.110223e-16 -1.110223e-16 -1.110223e-16 [356] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 ...all lines are zero from here on... [996] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [1001] 0.000000e+00 When I compare it with output from FreeBSD 5.0 on the same platform, I get 4 columns instead of 5, and the numbers are nonzero right up to the last: > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) [1] -2.252266e+00 -2.162061e+00 -2.076474e+00 -1.995124e+00 [5] -1.917675e+00 -1.843830e+00 -1.773331e+00 -1.705943e+00 ... [993] -1.765317e-119 -1.028280e-119 -5.986435e-120 -3.483321e-120 [997] -2.025755e-120 -1.177467e-120 -6.840359e-121 -3.971708e-121 [1001] -2.304857e-121 On OpenBSD 3.2 on the same platform (all of these systems run on top of VMware on top of GNU/Linux 7.2 or 8.0 on Pentium III 600MHz dual CPU servers), I get 5-column output, and trailing zeros: > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) [1] -2.252266e+00 -2.162061e+00 -2.076474e+00 -1.995124e+00 -1.917675e+00 [6] -1.843830e+00 -1.773331e+00 -1.705943e+00 -1.641459e+00 -1.579693e+00 [11] -1.520477e+00 -1.463659e+00 -1.409102e+00 -1.356679e+00 -1.306276e+00 [16] -1.257788e+00 -1.211118e+00 -1.166177e+00 -1.122883e+00 -1.081160e+00 [21] -1.040937e+00 -1.002149e+00 -9.647332e-01 -9.286334e-01 -8.937957e-01 ... [351] -1.110223e-16 -1.110223e-16 -1.110223e-16 -1.110223e-16 -1.110223e-16 [356] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 ... [996] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [1001] 0.000000e+00 On Solaris 9 x86 on the same platform, I get 4-column output: > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) [1] -2.252266e+00 -2.162061e+00 -2.076474e+00 -1.995124e+00 [5] -1.917675e+00 -1.843830e+00 -1.773331e+00 -1.705943e+00 [9] -1.641459e+00 -1.579693e+00 -1.520477e+00 -1.463659e+00 [13] -1.409102e+00 -1.356679e+00 -1.306276e+00 -1.257788e+00 [17] -1.211118e+00 -1.166177e+00 -1.122883e+00 -1.081160e+00 ... [353] -8.543005e-17 -7.001648e-17 -5.735327e-17 -4.695528e-17 [357] -3.842190e-17 -3.142256e-17 -2.568459e-17 -2.098321e-17 [361] -1.713324e-17 -1.398220e-17 -1.140459e-17 -9.297196e-18 ... [993] -1.765317e-119 -1.028280e-119 -5.986435e-120 -3.483321e-120 [997] -2.025755e-120 -1.177467e-120 -6.840359e-121 -3.971708e-121 [1001] -2.304857e-121 On the underlying GNU/Linux systems, I get 4-column output: > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) [1] -2.252266e+00 -2.162061e+00 -2.076474e+00 -1.995124e+00 [5] -1.917675e+00 -1.843830e+00 -1.773331e+00 -1.705943e+00 [9] -1.641459e+00 -1.579693e+00 -1.520477e+00 -1.463659e+00 [13] -1.409102e+00 -1.356679e+00 -1.306276e+00 -1.257788e+00 [17] -1.211118e+00 -1.166177e+00 -1.122883e+00 -1.081160e+00 ... [353] -8.543005e-17 -7.001648e-17 -5.735327e-17 -4.695528e-17 [357] -3.842190e-17 -3.142256e-17 -2.568459e-17 -2.098321e-17 [361] -1.713324e-17 -1.398220e-17 -1.140459e-17 -9.297196e-18 ... [997] -2.025755e-120 -1.177467e-120 -6.840359e-121 -3.971708e-121 [1001] -2.304857e-121 I'd like to get to the bottom of these differences. My numerical calculator project, extended hoc http://www.math.utah.edu/hoc has an extensive battery of validation tests, which have turned up bugs in the math library on a half-dozen systems, including a couple in glibc. However, although the tests show some differences between the four guest O/Ses, the chi-square and incomplete gamma function tests pass. The tests reveal that OpenBSD has these anomalies: exp(-Inf) -> NaN, exp(Inf) -> Inf, but exp(-MAXNORMAL) -> 0 and exp(MAXNORMAL) -> +Inf, as expected. Examination of the R-1.7.0/src/nmath/pweibull.c file shows that pweibull() calls pow(), log(), log1p(), and R_D_exp(), and the latter is defined in ./src/nmath/dpq.h as #define R_D_exp(x) (log_p ? (x) : exp(x)) /* exp(x) */ I therefore tried some experiments with hoc, using log1p() as the most likely candidate for errors, since it is quite new, and much less used than exp() and log(). And voilà, log1p() is at least part of the problem: FreeBSD, Solaris 9 x86, GNU/Linux, Solaris SPARC: hoc64> for (k = 0; k <= 100; ++k) println k, log1p(2^-k) 0 0.69314718055994529 1 0.40546510810816438 ... 50 8.8817841970012484e-16 51 4.4408920985006252e-16 52 2.2204460492503128e-16 53 1.1102230246251565e-16 ... 99 1.5777218104420236e-30 100 7.8886090522101181e-31 NetBSD, OpenBSD: hoc64> for (k = 0; k <= 100; ++k) println k, log1p(2^-k) 0 0.69314718055994529 1 0.40546510810816438 ... 50 8.8817841970012484e-16 51 4.4408920985006252e-16 52 2.2204460492503128e-16 53 0 54 0 ... 99 0 100 0 OpenBSD 3.3 was announced earlier this week, so if my colleague who installs these systems can find the time, we may be able to test it as well. log1p will now get some additional tests in the hoc validation suite. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ==> 2837.audit <== Fri Apr 25 20:06:48 2003 ripley moved from incoming to System-specific Mon Aug 25 19:23:40 2003 ripley changed notes Mon Aug 25 19:23:40 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2887 * Subject: tools/ldAIX4 Assumes AIX nm From: rgrubbfink@cox.net Date: Wed, 30 Apr 2003 22:24:34 +0200 (MET DST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2887 <== From rgrubbfink@cox.net Wed Apr 30 22:24:34 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3UKOY2b010902 for ; Wed, 30 Apr 2003 22:24:34 +0200 (MET DST) Date: Wed, 30 Apr 2003 22:24:34 +0200 (MET DST) Message-Id: <200304302024.h3UKOY2b010902@pubhealth.ku.dk> From: rgrubbfink@cox.net To: R-bugs@biostat.ku.dk Subject: tools/ldAIX4 Assumes AIX nm Full_Name: Richard L. Grubb Version: 1.6.2 OS: AIX 4.3.3 Submission from: (NULL) (130.76.96.17) The ldAIX4 script in the tools directory calls the nm program, assuming it is the nm supplied with AIX. However, I have GNU nm in $HOME/bin, and it was being executed instead of /usr/bin/nm or /bin/nm. The script failed silently, and caused downstream problems because etc/R.exp was empty. I ran into this same bug under R 1.7.0, but have not verified my fix yet (I backed up to version 1.6.2 to see if I could build it). My fix was to replace the line "nm=nm" in the script ldAIX4 with "nm=/bin/nm" See also my bug report on nm not being able to read src/main/dounzip.o ==> 2887.audit <== Fri May 2 22:28:30 2003 maechler moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 2888 * Subject: AIX 4.3.3 nm will not read all of dounzip.o From: rgrubbfink@cox.net Date: Wed, 30 Apr 2003 22:33:24 +0200 (MET DST) --Looks like an AIX bug, not an R one. --Other people have succeeded on AIX 5.1. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 2888 <== From rgrubbfink@cox.net Wed Apr 30 22:33:24 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h3UKXO2b010936 for ; Wed, 30 Apr 2003 22:33:24 +0200 (MET DST) Date: Wed, 30 Apr 2003 22:33:24 +0200 (MET DST) Message-Id: <200304302033.h3UKXO2b010936@pubhealth.ku.dk> From: rgrubbfink@cox.net To: R-bugs@biostat.ku.dk Subject: AIX 4.3.3 nm will not read all of dounzip.o Full_Name: Richard L. Grubb Version: 1.6.2 OS: AIX 4.3.3 Submission from: (NULL) (130.76.96.17) The tools/ldAIX4 script fails when it tries to execute nm -p -g -h dounzip.o. The output is: __mull U - __divss U - __divus U - __quoss U - __quous U - .mkdir U - .strlen U - .strcpy U - .strcat U - ...[SNIP]... .inflateInit2_ U - .crc32 U - .inflate U - .inflateEnd U - .do_int_unzip T 1084 758 .R_newunz T 2904 426 nm: dounzip.o: 0654-206 Cannot process the symbol table Whereas Gnu nm -p -g dounzip.o (can't use -h in GNU nm) gives: U __mulh U __mull U __divss U __divus U __quoss U __quous U .mkdir U .strlen U .strcpy U .strcat ...[SNIP]... U .crc32 U .inflate U .inflateEnd 000000000000043c T .do_int_unzip 0000000000000b58 T .R_newunz U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb U .bb U .eb 0000000000002a40 T unz_copyright 0000000000002a94 D do_int_unzip 0000000000002b00 D R_newunz I deleted dounzip.o from the list of object files to be processed by ldAIX4, and the rest of R has compiled ok so far. ==> 2888.audit <== Fri May 2 22:28:30 2003 maechler moved from incoming to System-specific Thu May 8 23:38:22 2003 ripley changed notes Thu May 8 23:38:22 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4295 * Subject: Bugs compiling R-1.7.1 with Intel compilers icc and ifc From: Date: Thu, 25 Sep 2003 11:26:09 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4295 <== From CanisMaior@web.de Thu Sep 25 11:26:15 2003 Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8P9QE0P023073 for ; Thu, 25 Sep 2003 11:26:14 +0200 (MET DST) Received: from web.de (fmomail03.dlan.cinetic.de [172.20.1.236]) by mailgate5.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h8P9Q9Q03287 for r-bugs@biostat.ku.dk; Thu, 25 Sep 2003 11:26:09 +0200 Date: Thu, 25 Sep 2003 11:26:09 +0200 Message-Id: <200309250926.h8P9Q9Q03287@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: To: r-bugs@biostat.ku.dk Subject: Bugs compiling R-1.7.1 with Intel compilers icc and ifc Precedence: fm-user Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bugs compiling R-1.7.1 with Intel compilers icc and ifc, on x86-computer (Pentium IV) and linux operating system Hello, as there aren't many reports about that issue, I'll give a little report here. (Hope I don't bother anyone) The best thing about using icc and ifc are the warnings, because it is said that the Intel compilers are stricter and give more precise warnings than gcc. Warnings are good for making better code. used software : * Intel c/c++ Compiler for 32-bit applications, Version 7.1 Build 20030307Z * Intel Fortran Compiler for 32-bit applications, Version 7.1 Build 20030307Z (both with licence FOR NON-COMMERCIAL USE ONLY) * autoconf (GNU Autoconf) 2.57 * GNU Make version 3.79.1 First: It is possible to compile R-1.7.1 with intel compilers ;-) But: There are several bugs. As the Intel compilers are quite reliable, the bugs may be in the R-code :-( *) some commands crashes R, see later. *) the configure script seems to have a bug, even if you make your own configure script with autoconf. Perhaps it's only a typo, perhaps it's an error of autoconf. So you have to do some things manually: 1) run configure : (you have to adjust the paths) env CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared SHLIB_LDFLAGS=-shared ./configure CC=icc CFLAGS=-O2 CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc CXXFLAGS=O2 FFLAGS=-C90 2) delete a wrong path in some Makefiles: -L/usr/local/lib" The quotation mark is the wrong thing. Delete it! You can search all the files containing this erratum recursively by R-1.7.1> grep local/lib\" * R-1.7.1> grep local/lib\" */* R-1.7.1> grep local/lib\" */*/* and so on. On my computer, the incorrect files are: R-1.7.1/Makeconf R-1.7.1/etc/Makeconf R-1.7.1/bin/R R-1.7.1/src/library/ctest/src/Makefile R-1.7.1/src/library/modreg/src/Makefile R-1.7.1/src/library/mva/src/Makefile R-1.7.1/src/library/ts/src/Makefile Note: R-1.7.1/bin/R does not exist at the beginning, so edit all the other files and start with make ---> it will create an bin/R and stops with an error Then do a make clean edit the file bin/R = erase the wrong quotation mark and start the compilation again with You also can start the compilation, quickly change to bin/ and edit the R-script file. make or better: Do a make &> this_is_a_logfile.log & which writes the compiler warnings to a file. Now it should succeed. Note: make check fails. That's a first hint that there are some problems. Don't install that R! You can run R locally by starting bin/R How does it work? *) Many, many things work fine and fast! But some commands make errors or even crashes R, e.g. demo(lm.glm) crashes R, demo(nlm) makes only an error and stops with the statement "nlm(function(x) fdd(x[1], x[2]), c(-1.2, 1), hessian = TRUE)" (compared with an R-1.7.1, build with gcc 3.3.1 on the same machine, no special configure options) I'll give only an extract of the compiler warnings. There are many more warnings, of course. Feel free to contact me, Volkmar Klatt volkmar.klatt AT stud.uni-bayreuth.de or CanisMaior AT web.de -------------------- * Most warnings are harmless and derives from the gcc compiling flag '-mieee-fp', that icc and ifc dont't understand. This flag is hard coded in the configure.ac file, and it seems that one cannot avoid it easily. That's bad, the configure script should be totally independent from any compiler, I think. * Many warnings refer to Fortran code that is obsolescent in Fortran 95 and/or in Fortran 90. Some code (like "ASSIGN") is even deleted in Fortran 95 * More serious things: (even dangerous?): ########################################## Comment 12 at (1592:blas.f) : This statement is obsolescent in Fortran 90 and deleted in Fortran 95 ASSIGN 210 TO IGO ^ Comment 12 at (1603:blas.f) : This statement is obsolescent in Fortran 90 and deleted in Fortran 95 ------------------ connections.c(841): warning #191: type qualifier is meaningless on cast type return gzwrite(fp, (const voidp)ptr, size*nitems)/size; ^ connections.c(1027): warning #191: type qualifier is meaningless on cast type BZ2_bzWrite(&bzerror, bfp, (const voidp)ptr, size*nitems); ------------------ dotcode.c(251): warning #175: subscript out of range buf[256] = '\0'; ^ ------------------ errors.c(602): warning #188: enumerated type mixed with another type { ERROR_NUMARGS, "invalid number of arguments" }, ^ errors.c(603): warning #188: enumerated type mixed with another type { ERROR_ARGTYPE, "invalid argument type" }, ^ errors.c(605): warning #188: enumerated type mixed with another type { ERROR_TSVEC_MISMATCH, "time-series/vector length mismatch" }, ^ errors.c(606): warning #188: enumerated type mixed with another type { ERROR_INCOMPAT_ARGS, "incompatible arguments" }, ^ errors.c(608): warning #188: enumerated type mixed with another type { ERROR_UNIMPLEMENTED, "unimplemented feature in %s" }, ^ errors.c(609): warning #188: enumerated type mixed with another type { ERROR_UNKNOWN, "unknown error (report this!)" } ^ ------------- graphics.c(5955): warning #175: subscript out of range Rf_dpptr(dd)->fin[2] = Rf_dpSavedptr(dd)->fin[2]; ^ graphics.c(5955): warning #175: subscript out of range Rf_dpptr(dd)->fin[2] = Rf_dpSavedptr(dd)->fin[2]; ^ graphics.c(5956): warning #175: subscript out of range Rf_dpptr(dd)->fin[3] = Rf_dpSavedptr(dd)->fin[3]; ^ graphics.c(5956): warning #175: subscript out of range Rf_dpptr(dd)->fin[3] = Rf_dpSavedptr(dd)->fin[3]; ^ graphics.c(6009): warning #175: subscript out of range Rf_dpptr(dd)->pin[2] = Rf_dpSavedptr(dd)->pin[2]; ^ graphics.c(6009): warning #175: subscript out of range Rf_dpptr(dd)->pin[2] = Rf_dpSavedptr(dd)->pin[2]; ^ graphics.c(6010): warning #175: subscript out of range Rf_dpptr(dd)->pin[3] = Rf_dpSavedptr(dd)->pin[3]; ^ graphics.c(6010): warning #175: subscript out of range Rf_dpptr(dd)->pin[3] = Rf_dpSavedptr(dd)->pin[3]; ^ ---------------- main.c(279): warning #175: subscript out of range state.buf[1025] = '\0'; /* stopgap measure if line > 1024 chars */ ^ ---------------- regex.c(5278): warning #589: transfer of control bypasses initialization of: variable "same_str_p" (declared at line 4163) goto restore_best_regs; ^ ----------------- distance.c(123): warning #187: use of "=" where "==" may have been intended /* use Inf = lim x -> oo */ (dev = 1.))) { ^ ------------------ sfm-read.c(555): warning #266: function declared implicitly bswap_flt64 (&data[i]); ^ sfm-read.c(659): warning #266: function declared implicitly bswap_flt64 (&hdr.bias); ^ sfm-read.c(920): warning #266: function declared implicitly bswap_flt64 (&mv[j]); ^ sfm-read.c(1174): warning #266: function declared implicitly bswap_flt64 (&cooked_label[i]->v.f); ^ sfm-read.c(1440): warning #266: function declared implicitly bswap_flt64 (temp); ^ sfm-read.c(1451): warning #266: function declared implicitly bswap_flt64 (temp); ^ sfm-read.c(1540): warning #266: function declared implicitly bswap_flt64 (&src); ^ ------------------- (in foreign:) stataread.c(102): warning #266: function declared implicitly reverse_double(i); ^ ----------------- ______________________________________________________________________________ Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) - bei der Stiftung Warentest - ein Doppelsieg! http://f.web.de/?mc=021184 ==> 4295.followup.1 <== From saikat@stat.wisc.edu Fri Sep 26 15:45:38 2003 Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8QDja0P012495 for ; Fri, 26 Sep 2003 15:45:37 +0200 (MET DST) Received: from stat.wisc.edu (bioxt38.dfci.harvard.edu [155.52.45.88]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id h8QDjNR17400 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Fri, 26 Sep 2003 08:45:30 -0500 Date: Fri, 26 Sep 2003 09:46:15 -0400 Subject: Re: [Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk To: CanisMaior@web.de From: Saikat DebRoy In-Reply-To: <200309250926.h8P9QG0P023078@pubhealth.ku.dk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) On Thursday, Sep 25, 2003, at 05:26 US/Eastern, CanisMaior@web.de wrote: > Bugs compiling R-1.7.1 with Intel compilers icc and ifc, > on x86-computer (Pentium IV) and linux operating system > Many of those bugs can be fixed by using appropriate configure options. Some of the warnings are serious, but they quite a few of them or fixed yesterday. > Hello, > as there aren't many reports about that issue, I'll give a little > report here. (Hope I don't bother anyone) > > The best thing about using icc and ifc are the warnings, because > it is said that the Intel compilers are stricter and give more > precise warnings than gcc. > Warnings are good for making better code. > used software : > * Intel c/c++ Compiler for 32-bit applications, Version 7.1 Build > 20030307Z > * Intel Fortran Compiler for 32-bit applications, Version 7.1 Build > 20030307Z > (both with licence FOR NON-COMMERCIAL USE ONLY) > * autoconf (GNU Autoconf) 2.57 I used all of the above on an Intel Pentium IV running Debian Linux testing distribution. In addition I had GNU make version 3.80 > * GNU Make version 3.79.1 > > First: > It is possible to compile R-1.7.1 with intel compilers ;-) > > But: > There are several bugs. As the Intel compilers are quite reliable, > the bugs may be in the R-code :-( > > *) some commands crashes R, see later. This can be fixed with appropriate options to the compiler. See below. > *) the configure script seems to have a bug, even if you make your own > configure script with autoconf. > Perhaps it's only a typo, perhaps it's an error of autoconf. > So you have to do some things manually: > This indeed is a bug in the configure script. I have a fix that works for the intel and the GNU compilers. I have no idea if it breaks anything for other compilers or platforms. > 1) > run configure : (you have to adjust the paths) > env CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared > SHLIB_LDFLAGS=-shared ./configure CC=icc CFLAGS=-O2 > CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc > CXXFLAGS=O2 FFLAGS=-C90 > A better set of configure options is ./configure CC=icc CFLAGS='-O2 -mp' CPPFLAGS=-I/opt/intel/compiler70/ia32/include F77=ifc CXX=icc CXXFLAGS='-O2 -mp' FFLAGS='-C90 -w90 -w95 -mp' CPICFLAGS=-shared CXXPICFLAGS=-shared FPICFLAGS=-shared SHLIB_LDFLAGS=-shared SHLIB_CXXLDFLAGS=-shared The -mp option forces stricter IEEE-754 floating point arithmetic conformance. Any operation involving an NA or NaN crashes R without this option. The icc and ifc also have a less strict -mp1 option which does not work for R. The -w90 and -w95 suppresses warnings about Fortran syntax made obsolete by Fortran 90 or 95. > 2) delete a wrong path in some Makefiles: > -L/usr/local/lib" > The quotation mark is the wrong thing. Delete it! > The problem is in the AC_F77_LIBRARY_LDFLAGS macro. It guesses the linker flags by passing a verbose option (-v for ifc) to the compiler. For ifc this produces a multiline output, one line continued to the next by a \ character. It also contains some " characters. These together produces the wrong results. We can fix this by removing all \ and " from the variable ac_f77_v_output in that macro. I am not sure if this breaks anything in other compilers. > make > or better: Do a > > make &> this_is_a_logfile.log & > > which writes the compiler warnings to a file. > Now it should succeed. > After you do everything I described, the make should succeed. It will still show some warnings. I think most of the warnings for R itself is harmless. > Note: > make check > fails. That's a first hint that there are some problems. Now make check should work. > Don't install that R! I would still be cautious about installing an R compiled with icc/ifc as your default but I think it is useful for the warnings it produces. Thanks, Saikat ==> 4295.followup.2 <== From saikat@stat.wisc.edu Sat Sep 27 01:19:17 2003 Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8QNJG0P016029 for ; Sat, 27 Sep 2003 01:19:17 +0200 (MET DST) Received: from stat.wisc.edu (bioxt38.dfci.harvard.edu [155.52.45.88]) (authenticated (0 bits)) by sabe.cs.wisc.edu (8.11.3/8.11.3) with ESMTP id h8QNJ8R19478 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Fri, 26 Sep 2003 18:19:15 -0500 Date: Fri, 26 Sep 2003 19:20:01 -0400 Subject: Re: [Rd] Bugs compiling R-1.7.1 with Intel compilers icc and ifc (PR#4295) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch To: Kurt.Hornik@wu-wien.ac.at From: Saikat DebRoy In-Reply-To: <16244.34147.349298.186981@mithrandir.hornik.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) On Friday, Sep 26, 2003, at 14:28 US/Eastern, Kurt Hornik wrote: > > Yep, the problem is the "-mGLOB_options_string=......" one gets, and > AC_F77_LIBRARY_LDFLAGS() cannot handle this. I tend to avoid > overloading stuff from Autoconf (and am not a fan of unconditionally > removing double quotes either), and we have a macro for postprocessing > the AC_F77_LIBRARY_LDFLAGS results anyways. I've added > > -[a-zA-Z]/*\" | -[a-zA-Z]*\\) # ifc > ;; > Kurt, That did not work. If you look in the configure file, it came out without the [ and ] characters. I think you need to use [[ and ]] in the aclocal.m4 file. Saikat ==> 4295.audit <== Wed Oct 15 02:18:03 2003 thomas foobar Wed Oct 15 02:18:03 2003 thomas moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4459 * Subject: Redhat 7.2 gcc optimisation From: Paul Murrell Date: Wed, 08 Oct 2003 15:28:11 +1300 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4459 <== From mailnull@stat.math.ethz.ch Wed Oct 8 04:28:29 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h982ST0P009524 for ; Wed, 8 Oct 2003 04:28:29 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h982RJq6012290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Oct 2003 04:27:19 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.10/8.12.10/Submit) id h982RHRe012287 for R-bugs@biostat.ku.dk; Wed, 8 Oct 2003 04:27:18 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.10/8.12.10) with ESMTP id h982R7q5012267 for ; Wed, 8 Oct 2003 04:27:08 +0200 (MEST) Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 1A743i-0000PB-00 for ; Tue, 07 Oct 2003 21:28:15 -0500 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h982SBEE002445 for ; Wed, 8 Oct 2003 15:28:11 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9085E33F17 for ; Wed, 8 Oct 2003 15:27:30 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21620-04 for ; Wed, 8 Oct 2003 15:27:30 +1300 (NZDT) Received: from stat10.stat.auckland.ac.nz (stat10.stat.auckland.ac.nz [130.216.50.10]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6476733EFF for ; Wed, 8 Oct 2003 15:27:30 +1300 (NZDT) Received: from stat.auckland.ac.nz (murrell.stat.auckland.ac.nz [130.216.50.118]) by stat10.stat.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id h982SB616576; Wed, 8 Oct 2003 15:28:11 +1300 Message-ID: <3F83763B.3070102@stat.auckland.ac.nz> Date: Wed, 08 Oct 2003 15:28:11 +1300 From: Paul Murrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: r-bugs@r-project.org Subject: Redhat 7.2 gcc optimisation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hypatia X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Level: Hi The the gcc on Redhat 7.2 with default C compiler configuration setting CFLAGS="-g -O2" produces some worrying differences in output compared to CFLAGS="-g -Wall -pedantic" The following differences were seen in graphical output from running examples: besselI DIFFERENCE in example 4 DIFFERENCE in example 5 (1e+00 becomes 1e-00 in axis label) -- co.intervals DIFFERENCE in example 8 (third y-value in lowess curve different)!!! -- dnbinom DIFFERENCE in example 2 (contour line labels at different locations) -- pbirthday DIFFERENCE in example 1 (1e+00 becomes 1e-00 in axis label) -- persp DIFFERENCE in example 3 (order of drawing surface facets different) ####### Reproduction details Differences were detected in graphics output using the graphicsQC package (see http://www.stat.auckland.ac.nz/~paul/index.html) and ... model.graphics(package="base", device="postscript", format="pbm", model.loc="model", verbose=TRUE) ... to produce output for CFLAGS="-g -O2" and ... test.graphics(package="base", device="postscript", format="pbm", model.loc="model", test.loc="test", verbose=TRUE) ... to produce output for CFLAGS="-g -Wall -pedantic" Paul --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = beta major = 1 minor = 8.0 year = 2003 month = 10 day = 07 language = R Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, package:lattice, package:grid, package:graphicsQC, Autoloads, package:base -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 paul@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ ==> 4459.audit <== Mon Nov 17 08:31:51 2003 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6488 * Subject: R fails to build on AFS From: Atro.Tossavainen+rproject@helsinki.fi Date: Wed, 28 Jan 2004 14:40:27 +0100 (CET) --insufficent information: what was the error message? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6488 <== From Atro.Tossavainen+rproject@helsinki.fi Wed Jan 28 14:40:28 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id D7BB21044D for ; Wed, 28 Jan 2004 14:40:27 +0100 (CET) From: Atro.Tossavainen+rproject@helsinki.fi To: R-bugs@biostat.ku.dk Subject: R fails to build on AFS Message-Id: <20040128134027.D7BB21044D@slim.kubism.ku.dk> Date: Wed, 28 Jan 2004 14:40:27 +0100 (CET) X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_20,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Atro Tossavainen Version: 1.8.1 OS: Linux x86, PPC, Solaris 7 SPARC, IRIX 6.5, Tru64 4.0F, HP-UX 10.20 Submission from: (NULL) (128.214.205.5) The @ character in path names causes the R build process to barf. It is used on the AFS file system for OS-specific magic: /afs/../../../../@sys/../.. links to a different directory on each system type (the magic "@sys" is expanded by AFS at file access time to the system value, such as alpha_dux40, hp_ux102, i386_linux24, etc). ==> 6488.audit <== Thu Jan 29 12:47:34 2004 ripley changed notes Thu Jan 29 12:47:34 2004 ripley moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7062 * Subject: fedora core 2 + bitmap() + ghostscript From: Piers Dunstan Date: Wed, 07 Jul 2004 10:01:42 +1000 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7062 <== From Piers.Dunstan@csiro.au Wed Jul 7 02:01:46 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id D4E8E108C7 for ; Wed, 7 Jul 2004 02:01:45 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18716-01 for ; Wed, 7 Jul 2004 02:01:43 +0200 (CEST) Received: from act-mx1.csiro.au (act-mx1.csiro.au [152.83.2.12]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 7 Jul 2004 02:01:43 +0200 (CEST) Received: from act-mx1.csiro.au (localhost.localdomain [127.0.0.1]) by localhost.act.csiro.au (Postfix) with ESMTP id 74D1954016 for ; Wed, 7 Jul 2004 10:01:40 +1000 (EST) Received: from exgw1-mel.nexus.csiro.au (exgw1-mel.nexus.csiro.au [138.194.3.56]) by act-mx1.csiro.au (Postfix) with SMTP id 5EB2F54014 for ; Wed, 7 Jul 2004 10:01:40 +1000 (EST) Received: from EXVIC3-MEL.vic.csiro.au ([138.194.3.54]) by exgw1-mel.nexus.csiro.au with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jul 2004 10:01:38 +1000 Received: from EXTAS2-HBA.tas.csiro.au ([140.79.3.44]) by EXVIC3-MEL.vic.csiro.au with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jul 2004 10:01:38 +1000 Received: EXTAS2-HBA.tas.csiro.au 140.79.3.44 from 140.79.17.40 140.79.17.40 via HTTP with MS-WebStorage 6.0.6249 Received: from sisyphus by EXTAS2-HBA.tas.csiro.au; 07 Jul 2004 10:01:42 +1000 Subject: fedora core 2 + bitmap() + ghostscript From: Piers Dunstan Reply-To: Piers.Dunstan@csiro.au To: r-bugs@biostat.ku.dk Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1089158502.3233.14.camel@sisyphus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 07 Jul 2004 10:01:42 +1000 X-OriginalArrivalTime: 07 Jul 2004 00:01:38.0249 (UTC) FILETIME=[932A9B90:01C463B5] X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,SIGNATURE_LONG_SPARSE, USER_AGENT_XIMIAN version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi all, A bug popped up recently when I upgraded to fedora core 2 (from core 1). Whenever I used the bitmap() function, ghostscript complained that it couldn't handle png or tiff devices. This was NOT a bug with R. It was with the version of ghostscript shipped with core 2. Going to rawhide and getting ghostscript 7.07-29 (core 2 comes with 7.07-25) solved this problem. Unfortunately, I have no output to demonstrate this problem as I FINALLY managed to fix it, and there's no way I going back :) Thanks Piers -- /*****************************/ Dr Piers Dunstan Marine Research CSIRO Hobart, Tasmania Ph: 613 6232 5382 Email: Piers.Dunstan@csiro.au /************************************/ ==> 7062.followup.1 <== From MSchwartz@MedAnalytics.com Wed Jul 7 03:05:47 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id B6B50108C7 for ; Wed, 7 Jul 2004 03:05:47 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18844-07 for ; Wed, 7 Jul 2004 03:05:46 +0200 (CEST) Received: from mail6.atl.registeredsite.com (mail6.atl.registeredsite.com [64.224.219.80]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 7 Jul 2004 03:05:45 +0200 (CEST) Received: from imta01a2.registeredsite.com (imta01a2.registeredsite.com [64.225.255.10]) by mail6.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6715ihH007932; Wed, 7 Jul 2004 01:05:44 GMT Received: from [192.168.1.2] ([69.76.28.186]) by imta01a2.registeredsite.com with ESMTP id <20040707010544.XCOK4075.imta01a2.registeredsite.com@[192.168.1.2]>; Tue, 6 Jul 2004 21:05:44 -0400 Subject: Re: [Rd] fedora core 2 + bitmap() + ghostscript (PR#7062) From: Marc Schwartz Reply-To: MSchwartz@MedAnalytics.com To: Piers.Dunstan@csiro.au Cc: R-Devel , R-bugs@biostat.ku.dk In-Reply-To: <20040707000147.BCE4B108D0@slim.kubism.ku.dk> References: <20040707000147.BCE4B108D0@slim.kubism.ku.dk> Content-Type: text/plain Organization: MedAnalytics, Inc. Message-Id: <1089162343.16727.90.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 06 Jul 2004 20:05:43 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Tue, 2004-07-06 at 19:01, Piers.Dunstan@csiro.au wrote: > Hi all, > A bug popped up recently when I upgraded to fedora core 2 (from core > 1). Whenever I used the bitmap() function, ghostscript complained that > it couldn't handle png or tiff devices. This was NOT a bug with R. It > was with the version of ghostscript shipped with core 2. Going to > rawhide and getting ghostscript 7.07-29 (core 2 comes with 7.07-25) > solved this problem. > > Unfortunately, I have no output to demonstrate this problem as I FINALLY > managed to fix it, and there's no way I going back :) > > Thanks Piers Here is some example output, which is a problem with the default version of GS in FC2: > bitmap("test.png") > DEBUG: no psname was provided. DEBUG: no psname was provided. DEBUG: no psname was provided. plot(1:10) > dev.off() null device 1 However, despite the msgs, the PNG file _is_ created with the plot. I have noted the above problems when opening postscript files using gv, where the above DEBUG msg appears in a pop up window. You have to clear the pop up to get the file to display. This has been a problem since moving to FC2. Note that I installed the updated '-29' rpms from fedora development and re-ran the sequence of statements _during the same R session_ and the second sequence below is the result, with the DEBUG msgs gone: > bitmap("test.png") > plot(1:10) > dev.off() null device 1 This should not have been reported however to R-bugs, since as you note above, it is not a bug in R. An FYI "heads up" msg to r-devel and/or r-help would have been entirely reasonable though. Marc Schwartz ==> 7062.audit <== Fri Jul 9 18:49:12 2004 maechler moved from incoming to System-specific ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: TooMuchAtOnce * PR# 7008 * Subject: dates From: gilescrane@doh.state.nj.us Date: Tue, 22 Jun 2004 22:18:41 +0200 (CEST) --Nothing to reproduce here ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7008 <== From gilescrane@doh.state.nj.us Tue Jun 22 22:18:42 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 71467D622 for ; Tue, 22 Jun 2004 22:18:41 +0200 (CEST) From: gilescrane@doh.state.nj.us To: R-bugs@biostat.ku.dk Subject: dates Message-Id: <20040622201841.71467D622@slim.kubism.ku.dk> Date: Tue, 22 Jun 2004 22:18:41 +0200 (CEST) X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Giles L Crane Version: 1.9.0 OS: Windows 98 Submission from: (NULL) (199.20.71.17) In package foreign, the read.epiinfo() does not read dates properly. (1) In reading a dataset, read.epiinfo made many dates NA. (2) Instead of reading dates to a POSIXct format, why not read to a mm/dd/yyyy format such as "06/22/2004"? As you may know, EPI6 calculates and displays dates quite directly. (3) The package date does not seem to have a convenient way of extracting dates from POSIXct format. Appreciate any comments, GLC ==> 7008.audit <== Wed Jun 23 10:51:47 2004 ripley changed notes Wed Jun 23 10:51:47 2004 ripley moved from incoming to TooMuchAtOnce ==> 7008.followup.1 <== From ripley@stats.ox.ac.uk Wed Jun 23 14:09:12 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 20177F590 for ; Wed, 23 Jun 2004 14:09:12 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11380-10 for ; Wed, 23 Jun 2004 14:09:11 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 23 Jun 2004 14:09:11 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i5NC9Art019284; Wed, 23 Jun 2004 13:09:10 +0100 (BST) Date: Wed, 23 Jun 2004 13:09:09 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: gilescrane@doh.state.nj.us Cc: r-devel@stat.math.ethz.ch, Subject: Re: [Rd] dates (PR#7008) In-Reply-To: <20040622201846.CE08DEABD@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) R-bugs is for bugs, and one bug per report. That means it cannot cope with three-part reports, two parts of which seem to be questions/wishes. On Tue, 22 Jun 2004 gilescrane@doh.state.nj.us wrote: > Full_Name: Giles L Crane > Version: 1.9.0 > OS: Windows 98 > Submission from: (NULL) (199.20.71.17) > > > In package foreign, the read.epiinfo() does not > read dates properly. > (1) In reading a dataset, > read.epiinfo made many dates NA. Can you give a reproducible example, please. Please start a new topic with a comprehensive subject line, as this one has been closed. > (2) Instead of reading dates to a POSIXct format, > why not read to a mm/dd/yyyy format such as > "06/22/2004"? > As you may know, EPI6 calculates and displays > dates quite directly. R does not use that date format (which is not an international standard). Indeed, how does anyone know that is a date (and if "01/01/1989", that it is in the illogical mm/dd/yyyy format only used in a few countries). > (3) The package date does not seem to have > a convenient way of extracting dates > from POSIXct format. Well, the date package was written about a decade before POSIXct. Why would anyone still be using it for new data? (Such a person could easily write one for his/her own use.) > Appreciate any comments, -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: Windows * PR# 3234 * Subject: scan() crash in Windows 98 From: "Simon Fear" Date: Wed, 11 Jun 2003 12:09:38 +0100 --Currently unreproducible ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3234 <== From mailnull@stat.math.ethz.ch Wed Jun 11 13:10:03 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h5BBA32b018125 for ; Wed, 11 Jun 2003 13:10:03 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5BBA09P019788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jun 2003 13:10:01 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h5BBA0Uc019785 for R-bugs@biostat.ku.dk; Wed, 11 Jun 2003 13:10:00 +0200 (MEST) Received: from franz.stat.wisc.edu (www.omegahat.org [128.105.174.32]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h5BB9r9O019759 for ; Wed, 11 Jun 2003 13:09:54 +0200 (MEST) Received: from anchor-post-39.mail.demon.net ([194.217.242.80]) by franz.stat.wisc.edu with esmtp (Exim 3.35 #1 (Debian)) id 19Q3UM-00016C-00 for ; Wed, 11 Jun 2003 06:09:58 -0500 Received: from anchor-sbs-1.mail.demon.net ([194.159.243.143] helo=mail-1.sbs.demon.net) by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2) id 19Q3UG-0003GP-0U for r-bugs@r-project.org; Wed, 11 Jun 2003 12:09:52 +0100 Received: from sbs1287.customer.demon.com (synequanon01.synequanon.synequanon.com) [194.159.221.242] by mail-1.sbs.demon.net with esmtp id 19Q3UF-000C5d-01; Wed, 11 Jun 2003 12:09:51 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 content-class: urn:content-classes:message Subject: scan() crash in Windows 98 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Importance: normal Priority: normal Date: Wed, 11 Jun 2003 12:09:38 +0100 Message-ID: <6C8A8033ABC1E3468048ABC4F13CE572AC0CE4@synequanon01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: scan() crash in Windows 98 Thread-Index: AcMwCfLfvP8BPZvqEdeZ4gAFXWubmQ== From: "Simon Fear" To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by stat.math.ethz.ch id h5BB9r9O019759 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### scan() (and so also of course read.table, read.csv etc) crashes right out of R (GUI) if it encounters non-ASCII characters (my particular example was a superscript 2 which is OK in MS applications (even in Notepad this is OK: BMI* (kg/m²)). For example read.csv("d:\\table03.csv",colClasses="character") generates "This program has performed an illegal operation and will be shut down ..." and the details says RGUI caused an invalid page fault in module R.DLL at 0167:004f3b67. Registers: EAX=0098007a CS=0167 EIP=004f3b67 EFLGS=00010246 EBX=01d97e92 SS=016f ESP=0096e140 EBP=0096e158 ECX=ffffffb2 DS=016f ESI=0000000a FS=3baf EDX=01fbd5b2 ES=016f EDI=00000000 GS=0000 Bytes at CS:EIP: 66 8b 04 48 25 57 01 00 00 25 ff ff 00 00 eb 9f Stack dump: 000c0000 00000001 00966000 00000013 0000000b 00000000 0096e188 0048dd2f 01d97e88 00000000 01fbd5cc 01fbd5cc 000c0000 00000004 0000000d 00000001 which certainly meeans nothing at all to me! Simon Fear --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 7.0 year = 2003 month = 04 day = 16 language = R Windows 98 SE 4.10 (build 2222) A Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base Simon Fear Senior Statistician Syne qua non Ltd Tel: +44 (0) 1379 644449 Fax: +44 (0) 1379 644445 email: Simon.Fear@synequanon.com web: http://www.synequanon.com Number of attachments included with this message: 0 This message (and any associated files) is confidential and contains information which may be legally privileged. It is intended for the stated addressee(s) only. Access to this email by anyone else is unauthorised. If you are not the intended addressee, any action taken (or not taken) in reliance on it, or any disclosure or copying of the contents of it is unauthorised and unlawful. If you are not the addressee, please inform the sender immediately and delete the email from your system. This message and any associated attachments have been checked for viruses using an internationally recognised virus detection process. However, Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of Syne qua non. ==> 3234.followup.1 <== From ligges@amadeus.statistik.uni-dortmund.de Thu Jun 12 08:32:32 2003 Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h5C6WV2b024865 for ; Thu, 12 Jun 2003 08:32:32 +0200 (MET DST) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 52CE44AAC3E; Thu, 12 Jun 2003 08:32:32 +0200 (MET DST) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id h5C6WWv10079; Thu, 12 Jun 2003 08:32:32 +0200 (MET DST) Message-ID: <3EE81E92.4010705@statistik.uni-dortmund.de> Date: Thu, 12 Jun 2003 08:32:50 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: Simon.Fear@synequanon.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] scan() crash in Windows 98 (PR#3234) References: <200306111110.h5BBA42b018129@pubhealth.ku.dk> In-Reply-To: <200306111110.h5BBA42b018129@pubhealth.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Simon.Fear@synequanon.com wrote: > # Your mailer is set to "none" (default on Windows), > # hence we cannot send the bug report directly from R. > # Please copy the bug report (after finishing it) to > # your favorite email program and send it to > # > # r-bugs@r-project.org > # > ###################################################### > > > > scan() (and so also of course read.table, read.csv etc) crashes right > out of > R (GUI) > if it encounters non-ASCII characters (my particular example was a > superscript 2 > which is OK in MS applications (even in Notepad this is OK: BMI* > (kg/m?)). ... and also OK in R (patched) for non-DOS-based Microsoft Operating Systems, like WinNT 4.0, hence difficult to debug (unless Duncan has still a Win9x machine running?). Uwe Ligges > For example > > read.csv("d:\\table03.csv",colClasses="character") > > generates > > "This program has performed an illegal operation and will be shut down > ..." > > and the details says > > RGUI caused an invalid page fault in > module R.DLL at 0167:004f3b67. > Registers: > EAX=0098007a CS=0167 EIP=004f3b67 EFLGS=00010246 > EBX=01d97e92 SS=016f ESP=0096e140 EBP=0096e158 > ECX=ffffffb2 DS=016f ESI=0000000a FS=3baf > EDX=01fbd5b2 ES=016f EDI=00000000 GS=0000 > Bytes at CS:EIP: > 66 8b 04 48 25 57 01 00 00 25 ff ff 00 00 eb 9f > Stack dump: > 000c0000 00000001 00966000 00000013 0000000b 00000000 0096e188 0048dd2f > 01d97e88 00000000 01fbd5cc 01fbd5cc 000c0000 00000004 0000000d 00000001 > > which certainly meeans nothing at all to me! > > Simon Fear > > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 1 > minor = 7.0 > year = 2003 > month = 04 > day = 16 > language = R > > Windows 98 SE 4.10 (build 2222) A > > Search Path: > .GlobalEnv, package:methods, package:ctest, package:mva, > package:modreg, > package:nls, package:ts, Autoloads, package:base > > > Simon Fear > Senior Statistician > Syne qua non Ltd > Tel: +44 (0) 1379 644449 > Fax: +44 (0) 1379 644445 > email: Simon.Fear@synequanon.com > web: http://www.synequanon.com > > Number of attachments included with this message: 0 > > This message (and any associated files) is confidential and > contains information which may be legally privileged. It is > intended for the stated addressee(s) only. Access to this > email by anyone else is unauthorised. If you are not the > intended addressee, any action taken (or not taken) in > reliance on it, or any disclosure or copying of the contents of > it is unauthorised and unlawful. If you are not the addressee, > please inform the sender immediately and delete the email > from your system. > > This message and any associated attachments have been > checked for viruses using an internationally recognised virus > detection process. However, Internet communications cannot > be guaranteed to be secure or error-free as information could > be intercepted, corrupted, lost, destroyed, arrive late or > incomplete. Therefore, we do not accept responsibility for any > errors or omissions that are present in this message, or any > attachment, that have arisen as a result of e-mail transmission. > If verification is required, please request a hard-copy version. > Any views or opinions presented are solely those of the author > and do not necessarily represent those of Syne qua non. > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel ==> 3234.audit <== Thu Jun 12 09:51:18 2003 ripley changed notes Thu Jun 12 09:51:18 2003 ripley foobar Thu Jun 12 09:51:18 2003 ripley moved from incoming to Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3644 * Subject: Windows 2000 Bug in GMT +/- n Timezones From: Gabor Grothendieck Date: Sun, 3 Aug 2003 20:06:49 -0700 (PDT) --As it says, a Windows 2000 bug ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3644 <== From ggrothendieck@volcanomail.com Mon Aug 4 05:07:07 2003 Received: from omta02.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h74376JH027221 for ; Mon, 4 Aug 2003 05:07:06 +0200 (MET DST) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta02.mta.everyone.net (Postfix) with ESMTP id A12591AAA5; Sun, 3 Aug 2003 20:06:49 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 4970045C1; Sun, 3 Aug 2003 20:06:49 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Sun, 3 Aug 2003 20:06:49 -0700 (PDT) From: Gabor Grothendieck To: r-bugs@biostat.ku.dk Cc: jerome@hivnet.ubc.ca, p.connolly@hortresearch.co.nz, dmurdoch@pair.com Subject: Windows 2000 Bug in GMT +/- n Timezones Reply-To: ggrothendieck@volcanomail.com X-Originating-Ip: [207.35.143.177] Message-Id: <20030804030649.4970045C1@sitemail.everyone.net> Tracking down this bug was joint work with Jermoe Asselin (jerome at hivnet.ubc.ca) and Patrick Connolly (p.connolly at hortresearch.co.nz). We collectively were able to determine that this is a problem in Windows 2000 but not in Linux. Timezones of the form GMT-5, GMT+3, etc. do not work properly in Windows 2000 for nearby dates in daylight savings time although they do work for nearby dates not in daylight savings time and in far away dates. (Apparently nearby dates are processed by the OS and far away ones by R.) This appears to be a Windows specific problem as these timezones do give correct results in Linux. Run the code below on Windows 2000 and it will display a table like the one later on. The rows are timezones and the columns are dates. The entries in the table are the hours between GMT and the date/timezone for that cell. For example, for the 1995-06-29 column, the row labelled GMT+1 gives the the time difference between 1995-06-29 GMT and 1995-06-29 GMT+1. It shows that the two times are equal but they should be one hour different. In fact, examining this same column we see that all the cells that correspond to GMT+n and GMT-n for each n are wrong by one hour. # start of code my.outer <- function(x,y,f) { # same as outer but can accept functions with scalar args # (whereas outer only takes functions that can take vector args) ff <- function(z) f(z[[1]],z[[2]]) outer( x, y, function(x,y)apply(data.frame(x,y),1,ff) ) } my.tz <- c("XYZ", "EST", "EDT", "PST", "PDT", "NZT", "NZST", "NZDT", "ET", "PT", "", "GMT-5", "GMT-4", "GMT-3", "GMT-2", "GMT-1", "GMT", "GMT+1", "GMT+2", "GMT+3", "GMT+4", "GMT+5") names(my.tz) <- my.tz "my.dates" <- c("1895-06-29", "1995-01-29", "1995-06-29", "2095-06-29") names(my.dates) <- my.dates f <- function(d,z) as.POSIXct(d,tz=z) - as.POSIXct(d,tz="GMT") tab <- t( my.outer( my.dates, my.tz, f ) ) paste(R.version); Sys.timezone(); tab # end of code to copy On a Eastern Daylight Time Windows 2000 machine it produces this: [1] "i386-pc-mingw32" "i386" "mingw32" "i386, mingw32" [5] "" "1" "7.1" "2003" [9] "06" "16" "R" [1] "Eastern Daylight Time" 1895-06-29 1995-01-29 1995-06-29 2095-06-29 XYZ 0 0 -1 0 EST 0 0 -1 0 EDT 0 0 -1 0 PST 0 0 -1 0 PDT 0 0 -1 0 NZT 0 0 -1 0 NZST -1 0 -1 -1 NZDT -1 0 -1 -1 ET -1 0 -1 -1 PT -1 0 -1 -1 4 5 4 4 GMT-5 -5 -5 -6 -5 GMT-4 -4 -4 -5 -4 GMT-3 -3 -3 -4 -3 GMT-2 -2 -2 -3 -2 GMT-1 -1 -1 -2 -1 GMT 0 0 0 0 GMT+1 1 1 0 1 GMT+2 2 2 1 2 GMT+3 3 3 2 3 GMT+4 4 4 3 4 GMT+5 5 5 4 5 Also most of the timezones don't work and either give the same result as XYZ (which is a clearly invalid timezone) or else deviate from the XYZ row by one hour. Although not shown "Eastern Daylight Time", "Eastern Standard Time", "Eastern Time" and "Eastern XYZ Time" all give the same result as for row ET above. _____________________________________________________________ Get your own FREE e-mail account at http://www.volcanomail.com ==> 3644.audit <== Mon Aug 4 16:53:48 2003 ripley moved from incoming to Windows Tue Sep 2 22:43:31 2003 ripley changed notes Tue Sep 2 22:43:31 2003 ripley foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 3841 * Subject: end-of-loop-timeout problem and submit-bug-report output (resending) Subject: ess-mode 5.1.24; end of loop timeout Subject: Re: where should i increase ess-loop-timeout From: Scot W McNary From: Rich Heiberger Date: Tue, 19 Aug 2003 16:25:18 -0400 (EDT) Date: Mon, 28 Jul 2003 14:30:03 -0400 (EDT) --Misdirected from ess-bugs? ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 3841 <== From mailnull@stat.math.ethz.ch Wed Aug 20 12:27:22 2003 Received: from stat.math.ethz.ch (root@hypatia.ethz.ch [129.132.58.23]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h7KARLJH021009 for ; Wed, 20 Aug 2003 12:27:21 +0200 (MET DST) Received: from stat.math.ethz.ch (localhost [127.0.0.1]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h7KAQZGl024988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Aug 2003 12:26:35 +0200 (MEST) Received: (from mailnull@localhost) by stat.math.ethz.ch (8.12.9/8.12.6/Submit) id h7KAQYu3024987 for R-bugs@biostat.ku.dk; Wed, 20 Aug 2003 12:26:34 +0200 (MEST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by stat.math.ethz.ch (8.12.9/8.12.6) with ESMTP id h7KAQQGk024958 for ; Wed, 20 Aug 2003 12:26:26 +0200 (MEST) Received: (from maechler@localhost) by lynne.ethz.ch (8.11.6/8.11.2) id h7KAR9a18892; Wed, 20 Aug 2003 12:27:09 +0200 Resent-From: Martin Maechler Resent-Message-ID: <16195.19709.56452.662154@gargle.gargle.HOWL> Resent-Date: Wed, 20 Aug 2003 12:27:09 +0200 Resent-To: R-bugs@stat.math.ethz.ch Message-ID: <20030819162422.K10461@fellspt.charm.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-BeenThere: ess-help@stat.math.ethz.ch X-Mailman-Version: 2.1.2 Precedence: list List-Id: ESS (Emacs Speaks Statistics) Discussion and Help List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: ess-help-bounces@stat.math.ethz.ch From: Scot W McNary To: ess-help@stat.math.ethz.ch Subject: end-of-loop-timeout problem and submit-bug-report output (resending) Date: Tue, 19 Aug 2003 16:25:18 -0400 (EDT) X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) (Hi, I tried sending this to ess-bugs, but got it bounced back: "user unknown". Hope this isn't too off-topic for ess-help. Scot) I'm using Xemacs 21.4, ess 5.1.24, on Windows 98 SE, with John Fox's configuration files: (http://socserv.mcmaster.ca/jfox/Books/Companion/ESS/index.html) and am getting the end-of-loop-timeout warning message I've seen reported to ESS-help several times over the last few months. In response to the last posting about it, Rich Heiberger suggested to another poster running M-x submit-bug-report and sending it to ess-bugs. I thought I might do the same. C-g does give back control of the cursor as advised by Rich, but I have never had trouble running R or ESS after getting the error message. Since it doesn't seem to affect my working with Xemacs at all, I've been treating it like a flashing "12:00" on my VCR and I'm too lazy to change it. However, having now seen a few others speak up with the problem, I thought I'd try and see if it could be fixed. However, please note that I'm perfectly happy living with it if that's the easiest thing to do! Here are the first few lines of init.el that show my choices among the options for John Fox's configuration. Below that is the submit-bug-report output. Let me know if I need to provide more information. Thanks, Scot McNary *** begin Fox's configuration options in init.el*** ;;;------------------------------------------------------------* ;;; sample init.el file for ess + Xemacs under MS Windows * ;;; John Fox * ;;; 27 November 2002 Version 0.5.2 * ;;;------------------------------------------------------------* ;; This file goes in the .xemacs subdirectory of your HOME directory ;; In Windows 9x, set the HOME environment variable, e.g., set HOME=c:\ ;; In Windows NT, 2000, or XP, use location pointed to by HOMEDRIVE, HOMEPATH ;; or set the HOME environment variable ;;;---------------------------------------------------------------------------------------------- ;;; configuration options: ;; change to suit ;; If pc-behaviour-level > 0, backspace key, marked-region replace, etc. are as in Windows. ;; If pc-behaviour-level > 1, in addition Windows editing keys C-x, C-c, C-v are defined. (defconst pc-behaviour-level 0) ; 2 = all Windows editing behaviours turned on ;; If suppress-initial-dialog is t then the initialization message dialog box is not displayed. ;; Recommended default is nil for Windows NT/2000/XP, t for Windows 9x. (defconst suppress-initial-dialog t) ; nil = show dialog ;; If enable-R-menus > 0, then unproblematic R menu items are enabled. ;; If enable-R-menus > 1, then in addition menu items that call GUI functions are enabled. ;; Recommended default is 2 for Windows NT/2000/XP, 1 for Windows 9x. (defconst enable-R-menus 1) ; 2 = all menu items enabled ;; If suppress-R-toolbar is t then the R toolbar is not shown. (defconst suppress-R-toolbar nil) ; nil = show R toolbar ;; If dedicated-R-window is t then buffers other than the R-process buffer ;; cannot be displayed in the lower window (defconst dedicated-R-window t) ; t = dedicated window *** end Fox's configuration options in init.el*** ************************************************* ************************************************* ************************************************* ************* ******************* Now, here is the output from the submit-bug-report function: ************* ******************* ************************************************* ************************************************* ************************************************* ***begin M-x submit-bug-report output*** To: ess-bugs@stat.math.ethz.ch Subject: ess-mode 5.1.24; end of loop timeout --text follows this line-- Emacs : XEmacs 21.4 (patch 11) "Native Windows TTY Support (Windows)" [Lucid] (i586-pc-win32) of Wed Jan 08 2003 on TSUNAMI Package: ess-mode 5.1.24 current state: ============== (setq ess-language "S" ess-dialect "R" ess-ask-for-ess-directory nil ess-ask-about-transfile nil ess-directory nil ess-keep-dump-files "always" ess-source-directory "/tmp/" ) (ess-setq-vars-LOCAL): language=SAS, dialect=SAS, buf=unlikely-name.sas, comint..echoes=nil, comint..sender=comint-simple-send (ess-mode-1): ess-language=SAS, ess-dialect=SAS buf=unlikely-name.sas (ess-mode-1.5): alist=((ess-local-customize-alist quote SAS-customize-alist) (ess-language . SAS) (ess-dialect . SAS) (ess-mode-editing-alist . SAS-editing-alist) (ess-mode-syntax-table . SAS-syntax-table) (inferior-ess-program . inferior-SAS-program-name) (ess-help-sec-regex . ^[A-Z. ---]+:$) (ess-help-sec-keys-alist . ) (ess-object-name-db-file . ess-sas-namedb.el) (inferior-ess-objects-command . objects(%d)) (inferior-ess-help-command . help("%s",pager="cat",window=F) ) (inferior-ess-exit-command . endsas; ) (ess-loop-timeout . 1000000) (inferior-ess-primary-prompt . \([A-Z][][A-Za-z0-9.]*\)*>) (inferior-ess-secondary-prompt . ^) (comint-use-prompt-regexp-instead-of-fields . t) (inferior-ess-start-file) (inferior-ess-start-args . inferior-SAS-args-temp) (ess-local-process-name)) (ess-mode-1.6): editing-alist=((sentence-end . ;[ */]*) (paragraph-start . ^[ ]*$) (paragraph-separate . ^[ ]*$) (paragraph-ignore-fill-prefix . t) (adaptive-fill-mode) (indent-line-function quote sas-indent-line) (require-final-newline . t) (comment-start . \*\|/\*) (comment-start-skip . \*+) (comment-end . ;\|\*/) (comment-column . 40) (parse-sexp-ignore-comments . t) (ess-set-style . ess-default-style) (ess-local-process-name) (tab-stop-list . ess-sas-tab-stop-alist) (ess-mode-syntax-table . SAS-syntax-table) (font-lock-keywords-case-fold-search . t) (font-lock-defaults quote (SAS-mode-font-lock-keywords))) (ess-setq-vars-LOCAL): language=SAS, dialect=SAS, buf=unlikely-name.sas, comint..echoes=nil, comint..sender=comint-simple-send Finished setting up ESS-mode. [ess-site.el]: ess-customize-alist=((ess-local-customize-alist quote SAS-customize-alist) (ess-language . SAS) (ess-dialect . SAS) (ess-mode-editing-alist . SAS-editing-alist) (ess-mode-syntax-table . SAS-syntax-table) (inferior-ess-program . inferior-SAS-program-name) (ess-help-sec-regex . ^[A-Z. ---]+:$) (ess-help-sec-keys-alist . ) (ess-object-name-db-file . ess-sas-namedb.el) (inferior-ess-objects-command . objects(%d)) (inferior-ess-help-command . help("%s",pager="cat",window=F) ) (inferior-ess-exit-command . endsas; ) (ess-loop-timeout . 1000000) (inferior-ess-primary-prompt . \([A-Z][][A-Za-z0-9.]*\)*>) (inferior-ess-secondary-prompt . ^) (comint-use-prompt-regexp-instead-of-fields . t) (inferior-ess-start-file) (inferior-ess-start-args . inferior-SAS-args-temp) (ess-local-process-name)) [ess-site.el _2_]: ess-customize-alist=((ess-local-customize-alist quote SAS-customize-alist) (ess-language . SAS) (ess-dialect . SAS) (ess-mode-editing-alist . SAS-editing-alist) (ess-mode-syntax-table . SAS-syntax-table) (inferior-ess-program . inferior-SAS-program-name) (ess-help-sec-regex . ^[A-Z. ---]+:$) (ess-help-sec-keys-alist . ) (ess-object-name-db-file . ess-sas-namedb.el) (inferior-ess-objects-command . objects(%d)) (inferior-ess-help-command . help("%s",pager="cat",window=F) ) (inferior-ess-exit-command . endsas; ) (ess-loop-timeout . 1000000) (inferior-ess-primary-prompt . \([A-Z][][A-Za-z0-9.]*\)*>) (inferior-ess-secondary-prompt . ^) (comint-use-prompt-regexp-instead-of-fields . t) (inferior-ess-start-file) (inferior-ess-start-args . inferior-SAS-args-temp) (ess-local-process-name)) (R): ess-dialect=nil, buf=*scratch*, start-arg=nil current-prefix-arg=nil (inferior-ess 0): ess-start-args=--ess ess-setq-vars-default 0: ess-language=Initial, -dialect=nil, buf=*ESS*, comint..echoes=nil, comint..sender=comint-simple-send ess-setq-vars-default 1: ess-language=S, -dialect=R, buf=*ESS*, comint..echoes=nil, comint..sender=comint-simple-send (inf-ess 1): lang=S, dialect=R, tmp-dialect=R, buf=*scratch* (inf-ess 1.1): procname=R temp-dialect=R, buf-name=*R* (inferior-ess) Method #3 start=c:\ buf=*R* (ess-setq-vars-LOCAL): language=S, dialect=R, buf=*R*, comint..echoes=nil, comint..sender=comint-simple-send (inf-ess 2.1): ess-language=S, ess-dialect=R buf=*R* (inf-ess 2.2): start args = --ess , inf-ess-start-args=--ess (inf-ess finish [S(R), C:/Program Files/R/rw1071/bin/Rterm(nil,nil)] (ess-multi 0): inf-ess-start-args=--ess , comint-..echoes=nil (i-ess 1): buf=*R*, lang=S, comint..echo=nil, comint..sender=comint-simple-send, (i-ess 2): buf=*R*, lang=S, comint..echo=t, comint..sender=inferior-R-input-sender, (ess-setq-vars-LOCAL): language=S, dialect=R, buf=*R*, comint..echoes=t, comint..sender=inferior-R-input-sender (i-ess 3): curr-buf=*R*, comint..echo=t, comint..sender=inferior-R-input-sender, (ess-multi post inf-ess: start-args=--ess , comint-echoes=t (ess-multi 1): start-args=--ess Making Process...Buf *R*, Proc R, Prog C:/Program Files/R/rw1071/bin/Rterm Start File=nil, Args= --ess . ***end M-x submit-bug-report output*** -- Scot W. McNary email:smcnary@charm.net Message: 3 Date: Mon, 28 Jul 2003 14:30:03 -0400 (EDT) From: Rich Heiberger Subject: Re: where should i increase ess-loop-timeout To: , Alejandro Mu?oz del R?o Message-ID: <200307281830.h6SIU3EX105308@surfer.sbm.temple.edu> The most likely reason for running into an ess-loop-timeout problem is that the cursor is in the wrong place. The fix is to put it in the right place. The workaround is often: 1. enter C-g to get control back. 2. move the cursor to the end of the buffer and enter The long term fix is to figure out why there was a cursor placement problem. For that we need more detail. Detail consists of two parts. a. run M-x ess-submit-bug report b. write an excessively detailed description of what you were doing when the window froze. Send it to ess-bugs@stat.math.ethz.ch Rich ______________________________________________ ESS-help@stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/ess-help ==> 3841.audit <== Wed Aug 20 20:10:29 2003 dmurdoch changed notes Wed Aug 20 20:10:29 2003 dmurdoch foobar Tue Sep 2 08:07:56 2003 ripley foobar Tue Sep 2 08:07:56 2003 ripley moved from incoming to Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4047 * Subject: File in use error From: oakeley@fmi.ch Date: Tue, 2 Sep 2003 11:06:16 +0200 (MET DST) --Windows / R(D)COM / Bioconductor, probably the last. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4047 <== From oakeley@fmi.ch Tue Sep 2 11:06:16 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8296GJH006978 for ; Tue, 2 Sep 2003 11:06:16 +0200 (MET DST) Date: Tue, 2 Sep 2003 11:06:16 +0200 (MET DST) Message-Id: <200309020906.h8296GJH006978@pubhealth.ku.dk> From: oakeley@fmi.ch To: R-bugs@biostat.ku.dk Subject: File in use error Full_Name: Edward J. Oakeley Version: 1.7.1 OS: Windows XP Submission from: (NULL) (212.47.183.3) This bug occurs when using the (D)COM server to connect to the "expresso" command of the Bioconductor Affy package. It may be a bug of R, (D)COM or Affy ut I will report it here anyway as it feels like an R bug. The Affy package when invoked will read a series of large (10Mb) text files from the working directory. These files contain information about a microarray experiment (CEL files). The instructions passed to R are as follows (VB .NET): ----- 'Make (D)COM connection Dim x As New STATCONNECTORSRVLib.StatConnector() 'Initialising R x.Init("R") x.EvaluateNoReturn("library(affy)") sPath = "c:\\temp\\" x.EvaluateNoReturn("setwd(" + Chr(34) + sPath + Chr(34) + ")") 'Reading files... x.EvaluateNoReturn("data <- ReadAffy()") 'Calculating RMA expression values... x.EvaluateNoReturn("eset <- expresso(data, bgcorrect.method=" + Chr(34) + "rma" + Chr(34) + ", normalize.method=" + Chr(34) + "quantiles" + Chr(34) + ", pmcorrect.method=" + Chr(34) + "pmonly" + Chr(34) + ", summary.method=" + Chr(34) + "avgdiff" + Chr(34) + ")") 'Writng output data x.EvaluateNoReturn("write.exprs(eset,file=" + Chr(34) + "output.txt" + Chr(34) + ")") x.Close() ------ The "Close()" command should shutdown R and release all of the ownerships on files as R quits but it does not. The files loaded (CEL files) can now not be deleted or moved until the user logs off. The error generated is "file is in use by another process". The output file "output.txt" does not have any special restriction on its access applied. The bug does not appear when the commands are invoked from the R console. The only exception with the console approach is that the termination command given is "q()". This command generates an error when passed over the (D)COM server. The documentation recommended using the "Close()" function instead. Anyway, just thought you should know... If this is not a bug then if anyone can tell me how to release ownership on these files I would really appreciate it. Thanks Ed ==> 4047.audit <== Tue Sep 2 22:37:48 2003 ripley changed notes Tue Sep 2 22:37:48 2003 ripley foobar Tue Sep 2 22:37:48 2003 ripley moved from incoming to Windows Fri Apr 30 16:32:00 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 4246 * Subject: creates directory that can't be deleted From: xiaobao_wang@yahoo.com Date: Mon, 22 Sep 2003 02:26:31 +0200 (MET DST) --This is a Windows bug. ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 4246 <== From xiaobao_wang@yahoo.com Mon Sep 22 02:26:31 2003 Received: from blueberry (blueberry [192.38.19.4]) by pubhealth.ku.dk (8.12.9/8.12.9) with ESMTP id h8M0QVJH012747 for ; Mon, 22 Sep 2003 02:26:31 +0200 (MET DST) Date: Mon, 22 Sep 2003 02:26:31 +0200 (MET DST) Message-Id: <200309220026.h8M0QVJH012747@pubhealth.ku.dk> From: xiaobao_wang@yahoo.com To: R-bugs@biostat.ku.dk Subject: creates directory that can't be deleted Full_Name: Xiaobao Wang Version: R 1.7.1 OS: Windows XP Submission from: (NULL) (24.45.25.102) accidentally done the following: rpt.dir <- paste("c:/report/testR","bestsub",spe="/") dir.create(rpt.dir) (spe should be sep). Now the directory "c:/report/testR bestsub " cannot be removed. I tried to remove it from Windows Explorer and got the message box: ================================================================= Error Deleting file or folder: Cannot delete file: Cannot read from source file or disk ================================================================= ==> 4246.audit <== Fri Oct 3 08:53:33 2003 maechler moved from incoming to Windows Wed Nov 19 13:20:24 2003 dmurdoch changed notes Wed Nov 19 13:20:24 2003 dmurdoch foobar Wed Nov 19 14:11:06 2003 dmurdoch changed notes Wed Nov 19 14:11:06 2003 dmurdoch foobar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6742 * Subject: save image as postscript side-effect From: martin.noellenburg@stud.uni-karlsruhe.de Date: Mon, 5 Apr 2004 17:51:13 +0200 (CEST) --This is saving from the windows() device menu. --Not reproducible ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6742 <== From martin.noellenburg@stud.uni-karlsruhe.de Mon Apr 5 17:51:13 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3676210439 for ; Mon, 5 Apr 2004 17:51:13 +0200 (CEST) From: martin.noellenburg@stud.uni-karlsruhe.de To: R-bugs@biostat.ku.dk Subject: save image as postscript side-effect Message-Id: <20040405155113.3676210439@slim.kubism.ku.dk> Date: Mon, 5 Apr 2004 17:51:13 +0200 (CEST) X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Martin Nöllenburg Version: 1.8.1 OS: Win XP Submission from: (NULL) (141.52.232.84) When I try to save any image produced by the plot command by choosing "file -> save as -> postscript..." in the menu, the settings for the decimal point are changed from '.' to ',' somehow. In the postscript output all '.' are replaced by ',' as well, so the file cannot be opened. Furthermore when I type e.g. "3.4" afterwards at the prompt, the next line is just "3": > 3.4 [1] 3 ==> 6742.followup.1 <== From ligges@amadeus.statistik.uni-dortmund.de Mon Apr 5 18:11:12 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 86049EDE2 for ; Mon, 5 Apr 2004 18:11:12 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17395-05 for ; Mon, 5 Apr 2004 18:11:11 +0200 (CEST) Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 5 Apr 2004 18:10:56 +0200 (CEST) Received: from amadeus.statistik.uni-dortmund.de (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id DF4BE1B0AB; Mon, 5 Apr 2004 18:10:55 +0200 (MET DST) Received: from statistik.uni-dortmund.de ([129.217.207.201]) by amadeus.statistik.uni-dortmund.de (8.11.6+Sun/8.11.6) with ESMTP id i35GAt510571; Mon, 5 Apr 2004 18:10:55 +0200 (MET DST) Message-ID: <40718519.2060702@statistik.uni-dortmund.de> Date: Mon, 05 Apr 2004 18:11:05 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: martin.noellenburg@stud.uni-karlsruhe.de Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] save image as postscript side-effect (PR#6742) References: <20040405155142.D52E01043B@slim.kubism.ku.dk> In-Reply-To: <20040405155142.D52E01043B@slim.kubism.ku.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) martin.noellenburg@stud.uni-karlsruhe.de wrote: > Full_Name: Martin Nöllenburg > Version: 1.8.1 > OS: Win XP > Submission from: (NULL) (141.52.232.84) > > > When I try to save any image produced by the plot command by choosing "file -> > save as -> postscript..." in the menu, the settings for the decimal point are > changed from '.' to ',' somehow. > In the postscript output all '.' are replaced by ',' as well, so the file cannot > be opened. Furthermore when I type e.g. "3.4" afterwards at the prompt, the next > line is just "3": > > >>3.4 > > [1] 3 Please, can you specify a reproducible example? It works for me (at least on WinNT 4.0). Uwe Ligges ==> 6742.reply.1 <== From p.dalgaard@biostat.ku.dk Mon Apr 5 19:25:26 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 1637CEDF1; Mon, 5 Apr 2004 19:25:26 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i35HN7Yg007590; Mon, 5 Apr 2004 19:23:07 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i35HN7Uk007586; Mon, 5 Apr 2004 19:23:07 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: ligges@statistik.uni-dortmund.de Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] save image as postscript side-effect (PR#6742) References: <20040405161147.6787A10439@slim.kubism.ku.dk> From: Peter Dalgaard Date: 05 Apr 2004 19:23:07 +0200 In-Reply-To: <20040405161147.6787A10439@slim.kubism.ku.dk> Message-ID: Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) ligges@statistik.uni-dortmund.de writes: > martin.noellenburg@stud.uni-karlsruhe.de wrote: > > > Full_Name: Martin Nöllenburg > > Version: 1.8.1 > > OS: Win XP > > Submission from: (NULL) (141.52.232.84) > > > > > > When I try to save any image produced by the plot command by choosing "file -> > > save as -> postscript..." in the menu, the settings for the decimal point are > > changed from '.' to ',' somehow. > > In the postscript output all '.' are replaced by ',' as well, so the file cannot > > be opened. Furthermore when I type e.g. "3.4" afterwards at the prompt, the next > > line is just "3": > > > > > >>3.4 > > > > [1] 3 > > Please, can you specify a reproducible example? > It works for me (at least on WinNT 4.0). (He probably can't since this kind of problem tends to depend on the individual system.) I've seen this a long time ago and I'm fairly sure the reason is a Windows DLL bug rather than an R one. You might want to check the archives. -p -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ==> 6742.audit <== Tue Apr 6 17:43:23 2004 maechler moved from incoming to Windows Sun Apr 18 13:31:58 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6955 * Subject: strange apparently data-dependent crash with large data From: Tony Plate Date: Mon, 07 Jun 2004 10:57:26 -0600 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6955 <== From mail@stat.math.ethz.ch Mon Jun 7 18:59:26 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0B0DD108F0 for ; Mon, 7 Jun 2004 18:59:26 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27047-06 for ; Mon, 7 Jun 2004 18:59:25 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 7 Jun 2004 18:59:25 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i57GxO4E003691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jun 2004 18:59:24 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i57GxOUF003689 for R-bugs@biostat.ku.dk; Mon, 7 Jun 2004 18:59:24 +0200 Received: from nambe.blackmesacapital.com ([12.96.201.67]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i57GxCdI002934 for ; Mon, 7 Jun 2004 18:59:13 +0200 Received: from ACONCAGUA.blackmesacapital.com ([192.168.118.73]) by nambe.blackmesacapital.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Jun 2004 10:57:41 -0600 Message-Id: <6.1.0.6.2.20040607093617.0418fbb0@mailhost.blackmesacapital.com> X-Sender: tplate@mailhost.blackmesacapital.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 07 Jun 2004 10:57:26 -0600 To: R-bugs@R-project.org From: Tony Plate Subject: strange apparently data-dependent crash with large data Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jun 2004 16:57:41.0202 (UTC) FILETIME=[8B868320:01C44CB0] Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of tplate@blackmesacapital.com does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I'm consistently seeing R crash with a particular large data set. What's strange is that although the crash seems related to running out of memory, I'm unable to construct a pseudo-random data set of the same size that also causes the crash. Further adding to the strangeness is that the crash only happens if the dataset goes through a save()/load() cycle -- without that, the command in question just gives an out-of-memory error, but does not crash. To make this clear, three different versions of the same data consistently produce very different behavior: (1) original data read with read.table: memory error; fail to allocate 164062 Kb (2) original data through save()/load() cycle: memory error; fail to allocate 82031 Kb, followed by crash (3) psuedo-random data of same size and similar characteristics: works without problem This is with R-1.9.0 under Windows 2000. I'm not loading any optional packages. I get the same crash behavior with R-1.9.0 patched, and R-2.0.0 alpha, but I didn't test success with the psuedo-random data under those programs. (In case it matters, I got R-1.9.0 patched and R-2.0.0 alpha as pre-compiled Windows binaries from http://cran.us.r-project.org/ at 9:30am MDT on Jun 7, 2004.) Unfortunately, I don't have sufficient knowledge of how to debug memory problems in R to make further progress than I've made here, but maybe the following will provide some clues for someone else. All the following transcripts are from Rgui.exe, with new runs at each comment beginning with "###" ### Read in the data and get a out-of-memory error (but no crash) > # ClassifyTrain.txt is from http://mill.ucsd.edu/data/ClassifyTrain.zip > X <- read.table("ClassifyTrain.txt", skip=2) > X1 <- as.matrix(X) > hist(log(X1[,-(1:2)]+1)) Error: cannot allocate vector of size 164062 Kb In addition: Warning message: Reached total allocation of 1024Mb: see help(memory.size) > ### Read in the data and save it as a .RData file for faster runs (I initially did this for speed, ### but this seems to be essential to causing the crash) > # ClassifyTrain.txt is from http://mill.ucsd.edu/data/ClassifyTrain.zip > X <- read.table("ClassifyTrain.txt", skip=2) > X1 <- as.matrix(X) > c(class(X1), storage.mode(X1), dim(X1)) [1] "matrix" "double" "30000" "702" > save(list="X1", file="X1.RData") ### Produce the crash > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 1 minor 9.0 year 2004 month 04 day 12 language R > > load("X1.RData") > c(class(X1), storage.mode(X1), dim(X1)) [1] "matrix" "double" "30000" "702" > # all of the following 3 command consistently cause a crash > hist(log(X1[,-(1:2)]+1)) > hist(log(X1[,-(1:2)]+1), breaks=seq(0,13,0.5)) > hist(log(X1[,-(1:2)]+1), breaks=seq(0,13,0.5), plot=F) Error: cannot allocate vector of size 82031 Kb In addition: Warning message: Reached total allocation of 1024Mb: see help(memory.size) [message that comes in a Windows dialog box after a wait of many seconds:] R Console: Rgui.exe - Application Error The exception unknown software exception (0xc00000fd) occured in the application at location 0x6b5b0a53 #### The following is a failed attempt to reproduce the crash with psuedo-random #### data, i.e., R functions correctly (even when X1 is in memory) > > # Look at some characteristics of the original data in > # order to produce a matrix of similar psuedo-random numbers. > load("X1.RData") > dim(X1) [1] 30000 702 > class(X1) [1] "matrix" > storage.mode(X1) [1] "double" > table(is.na(X1)) FALSE 21060000 > table(X1==0) FALSE TRUE 2284455 18775545 > exp(diff(log(table(X1==0)))) TRUE 8.218829 > table(X1>=0) TRUE 21060000 > range(X1) [1] 0 326022 > memory.limit() [1] 1073741824 > memory.limit()/2^20 [1] 1024 > object.size(X1)/2^20 [1] 161.0267 > > set.seed(1) > X <- matrix(rexp(30000 * 702, 5e-5) * rbinom(30000 * 702, 1, 1/8), ncol=702) > range(X) [1] 3.615044e-04 3.249415e+05 > > # Both of thse commands seem to work without problems > hist(log(X[,-(1:2)]+1)) > hist(log(X[,-(1:2)]+1), breaks=seq(0,13,0.5)) ==> 6955.followup.1 <== From ripley@stats.ox.ac.uk Mon Jun 7 19:40:20 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 67949108EF for ; Mon, 7 Jun 2004 19:40:20 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27211-02 for ; Mon, 7 Jun 2004 19:40:19 +0200 (CEST) Received: from toucan.stats.ox.ac.uk (toucan.stats.ox.ac.uk [163.1.210.20]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 7 Jun 2004 19:40:18 +0200 (CEST) Received: from gannet.stats (gannet.stats [163.1.211.17]) by toucan.stats.ox.ac.uk (8.12.10/8.12.10) with ESMTP id i57HeIrt001854; Mon, 7 Jun 2004 18:40:18 +0100 (BST) Date: Mon, 7 Jun 2004 18:40:17 +0100 (BST) From: Prof Brian Ripley X-X-Sender: ripley@gannet.stats To: tplate@blackmesacapital.com Cc: r-devel@stat.math.ethz.ch, Subject: (PR#6955) Re: [Rd] strange apparently data-dependent crash with large data In-Reply-To: <20040607165927.D6BD8108F1@slim.kubism.ku.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) It is not very surprising that the R process might crash once the maximum memory limit is reached. View anything done in a session after that as suspect. (The Unix equivalent is often to crash without even telling you that you are out of memory.) On Mon, 7 Jun 2004 tplate@blackmesacapital.com wrote: > I'm consistently seeing R crash with a particular large data set. What's > strange is that although the crash seems related to running out of memory, > I'm unable to construct a pseudo-random data set of the same size that also > causes the crash. Further adding to the strangeness is that the crash only > happens if the dataset goes through a save()/load() cycle -- without that, > the command in question just gives an out-of-memory error, but does not crash. > > To make this clear, three different versions of the same data consistently > produce very different behavior: > > (1) original data read with read.table: memory error; fail to allocate > 164062 Kb > (2) original data through save()/load() cycle: memory error; fail to > allocate 82031 Kb, followed by crash > (3) psuedo-random data of same size and similar characteristics: works > without problem > > This is with R-1.9.0 under Windows 2000. I'm not loading any optional > packages. I get the same crash behavior with R-1.9.0 patched, and R-2.0.0 > alpha, but I didn't test success with the psuedo-random data under those > programs. (In case it matters, I got R-1.9.0 patched and R-2.0.0 alpha as > pre-compiled Windows binaries from http://cran.us.r-project.org/ at 9:30am > MDT on Jun 7, 2004.) Unfortunately, I don't have sufficient knowledge of > how to debug memory problems in R to make further progress than I've made > here, but maybe the following will provide some clues for someone else. > > All the following transcripts are from Rgui.exe, with new runs at each > comment beginning with "###" > > ### Read in the data and get a out-of-memory error (but no crash) > > # ClassifyTrain.txt is from http://mill.ucsd.edu/data/ClassifyTrain.zip > > X <- read.table("ClassifyTrain.txt", skip=2) > > X1 <- as.matrix(X) > > hist(log(X1[,-(1:2)]+1)) > Error: cannot allocate vector of size 164062 Kb > In addition: Warning message: > Reached total allocation of 1024Mb: see help(memory.size) > > > > ### Read in the data and save it as a .RData file for faster runs (I > initially did this for speed, > ### but this seems to be essential to causing the crash) > > # ClassifyTrain.txt is from http://mill.ucsd.edu/data/ClassifyTrain.zip > > X <- read.table("ClassifyTrain.txt", skip=2) > > X1 <- as.matrix(X) > > c(class(X1), storage.mode(X1), dim(X1)) > [1] "matrix" "double" "30000" "702" > > save(list="X1", file="X1.RData") > > ### Produce the crash > > version > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 1 > minor 9.0 > year 2004 > month 04 > day 12 > language R > > > > load("X1.RData") > > c(class(X1), storage.mode(X1), dim(X1)) > [1] "matrix" "double" "30000" "702" > > # all of the following 3 command consistently cause a crash > > hist(log(X1[,-(1:2)]+1)) > > hist(log(X1[,-(1:2)]+1), breaks=seq(0,13,0.5)) > > hist(log(X1[,-(1:2)]+1), breaks=seq(0,13,0.5), plot=F) > Error: cannot allocate vector of size 82031 Kb > In addition: Warning message: > Reached total allocation of 1024Mb: see help(memory.size) > > [message that comes in a Windows dialog box after a wait of many seconds:] > > R Console: Rgui.exe - Application Error > The exception unknown software exception (0xc00000fd) occured in the > application at location 0x6b5b0a53 > > #### The following is a failed attempt to reproduce the crash with > psuedo-random > #### data, i.e., R functions correctly (even when X1 is in memory) > > > > # Look at some characteristics of the original data in > > # order to produce a matrix of similar psuedo-random numbers. > > load("X1.RData") > > dim(X1) > [1] 30000 702 > > class(X1) > [1] "matrix" > > storage.mode(X1) > [1] "double" > > table(is.na(X1)) > > FALSE > 21060000 > > table(X1==0) > > FALSE TRUE > 2284455 18775545 > > exp(diff(log(table(X1==0)))) > TRUE > 8.218829 > > table(X1>=0) > > TRUE > 21060000 > > range(X1) > [1] 0 326022 > > memory.limit() > [1] 1073741824 > > memory.limit()/2^20 > [1] 1024 > > object.size(X1)/2^20 > [1] 161.0267 > > > > set.seed(1) > > X <- matrix(rexp(30000 * 702, 5e-5) * rbinom(30000 * 702, 1, 1/8), ncol=702) > > range(X) > [1] 3.615044e-04 3.249415e+05 > > > > # Both of thse commands seem to work without problems > > hist(log(X[,-(1:2)]+1)) > > hist(log(X[,-(1:2)]+1), breaks=seq(0,13,0.5)) > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, ripley@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ==> 6955.audit <== Tue Jun 8 19:08:19 2004 ripley moved from incoming to Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Directory: incoming * PR# 5834 * Subject: bug-gdk error From: 9busova@st.fmph.uniba.sk Date: Tue, 16 Dec 2003 08:13:17 +0100 (CET) --Problem with gnome GUI ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 5834 <== From 9busova@st.fmph.uniba.sk Tue Dec 16 08:13:18 2003 Return-Path: <9busova@st.fmph.uniba.sk> X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id DD248EC61 for ; Tue, 16 Dec 2003 08:13:17 +0100 (CET) From: 9busova@st.fmph.uniba.sk To: R-bugs@biostat.ku.dk Subject: bug-gdk error Message-Id: <20031216071317.DD248EC61@slim.kubism.ku.dk> Date: Tue, 16 Dec 2003 08:13:17 +0100 (CET) Full_Name: Lenka Busova Version: 1.8.0 OS: Linux Submission from: (NULL) (217.67.17.234) Greetings, I have some problems running R with parameters --gui=gnome. When I mark text in console, and want to copy it, R crashes with the following note: Gdk-ERROR **: file gdkselection.c: line 331 (gdk_string_to_compound_text): assertion failed: (property.encoding == gdk_atom_intern ("COMPOUND_TEXT", FALSE) && property.format == 8) aborting... Aborted I've been using versions R-1.6.1 and R-1.8.0 The problem is the same no matter if I run R under kde 3.1.4 or gnome 2.4, or if I mark with a mouse or keyboard I've compiled it with gcc-3.2.3-r3 gdk 1.2 kernel 2.4.23_pre8-gss I use Gentoo linux distribution Thanks for any advice Lenka ==> 5834.audit <== Thu Jan 8 15:39:26 2004 ripley changed notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 6804 * Subject: Re: [R] Error message during debug From: Duncan Murdoch Date: Tue, 20 Apr 2004 14:15:05 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 6804 <== From mail@stat.math.ethz.ch Tue Apr 20 20:15:15 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 40CA410472 for ; Tue, 20 Apr 2004 20:15:15 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06358-10 for ; Tue, 20 Apr 2004 20:15:14 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 20 Apr 2004 20:15:14 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i3KIFD8T029858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Apr 2004 20:15:13 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i3KIFDeJ029856 for R-bugs@biostat.ku.dk; Tue, 20 Apr 2004 20:15:13 +0200 Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with SMTP id i3KIF7ui029837 for ; Tue, 20 Apr 2004 20:15:07 +0200 Received: (qmail 6594 invoked from network); 20 Apr 2004 18:15:04 -0000 Received: from xi.pair.com (HELO localhost) (209.68.1.25) by relay.pair.com with SMTP; 20 Apr 2004 18:15:04 -0000 X-pair-Authenticated: 209.68.1.25 From: Duncan Murdoch To: ggrothendieck@myway.com Cc: r-bugs@r-project.org Subject: Re: [R] Error message during debug Date: Tue, 20 Apr 2004 14:15:05 -0400 Message-ID: References: <20040420174843.B110012D51@mprdmxin.myway.com> In-Reply-To: <20040420174843.B110012D51@mprdmxin.myway.com> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_FORTE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Tue, 20 Apr 2004 13:48:43 -0400 (EDT), "Gabor Grothendieck" wrote : > >In R 1.9.0 on Windows XP Pro I get an error if I try to >debug the identity function f shown: > > > f <- function(x)x > > debug(f) > > f(1) > debugging in: f(1) > Error in f(1) : Unimplemented feature in eval > > R.version.string > [1] "R version 1.9.0, 2004-04-12" > >Without debuggging its ok. Confirmed. It's not new in 1.9.0, it appears in 1.8.1 as well. It seems that a function body consisting of a single token triggers it. I get a crash from this variation: f <- function(x) 4 Maybe the system is trying to tell us that functions this simple don't need debugging? ;-) I'm sending this message to r-bugs to get it into the bug list (but I won't have time to look at it until at least the weekend, if someone else wants to fix it). Duncan Murdoch ==> 6804.reply.1 <== From p.dalgaard@biostat.ku.dk Tue Apr 20 21:02:46 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 698591043B; Tue, 20 Apr 2004 21:02:46 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i3KIxNYg011534; Tue, 20 Apr 2004 20:59:23 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i3KIxMZa011530; Tue, 20 Apr 2004 20:59:22 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: dmurdoch@pair.com Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Re: [R] Error message during debug (PR#6804) References: <20040420181543.A86F110478@slim.kubism.ku.dk> From: Peter Dalgaard Date: 20 Apr 2004 20:59:22 +0200 In-Reply-To: <20040420181543.A86F110478@slim.kubism.ku.dk> Message-ID: Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) dmurdoch@pair.com writes: > On Tue, 20 Apr 2004 13:48:43 -0400 (EDT), "Gabor Grothendieck" > wrote : > > > > >In R 1.9.0 on Windows XP Pro I get an error if I try to > >debug the identity function f shown: > > > > > f <- function(x)x > > > debug(f) > > > f(1) > > debugging in: f(1) > > Error in f(1) : Unimplemented feature in eval > > > R.version.string > > [1] "R version 1.9.0, 2004-04-12" > > > >Without debuggging its ok. > > Confirmed. It's not new in 1.9.0, it appears in 1.8.1 as well. It > seems that a function body consisting of a single token triggers it. > I get a crash from this variation: > > f <- function(x) 4 > > Maybe the system is trying to tell us that functions this simple don't > need debugging? ;-) > > I'm sending this message to r-bugs to get it into the bug list (but I > won't have time to look at it until at least the weekend, if someone > else wants to fix it). Actually, ?debug says: Currently you can only debug functions that have bodies enclosed in braces. This is a bug and will be fixed soon. (and has probably said so for a very long time....) I hadn't seen the segfault from debugging a constant before, but I recently discovered that you *can* (sort of) debug a single-expression function by setting options(error=recover). -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7039 * Subject: segfault in apply with "==" and double From: chabrier@toulouse.inra.fr Date: Thu, 1 Jul 2004 12:26:26 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7039 <== From chabrier@toulouse.inra.fr Thu Jul 1 12:26:27 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id CAE361092C for ; Thu, 1 Jul 2004 12:26:26 +0200 (CEST) From: chabrier@toulouse.inra.fr To: R-bugs@biostat.ku.dk Subject: segfault in apply with "==" and double Message-Id: <20040701102626.CAE361092C@slim.kubism.ku.dk> Date: Thu, 1 Jul 2004 12:26:26 +0200 (CEST) X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_20,NO_REAL_NAME,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Patrick Chabrier Version: 1.9.1 OS: Linux version 2.4.18 (gcc version 2.95.4 20011002 (Debian prerelease)) Submission from: (NULL) (193.54.96.5) R : Copyright 2004, The R Foundation for Statistical Computing Version 1.9.1 (2004-06-21), ISBN 3-900051-00-3 R is free ..... ..... > apply(matrix(rnorm(1000*3000),nrow=3000), 2,"==",rnorm(400)) Segmentation fault I'm conscious that this is not the best way to use the "==" operator. I just hope it can help, Cordially, Patrick CHABRIER ------------------------------------------------------------------------\ Institut National de la Recherche Agronomique \_0/ Station de Biométrie & d'Intelligence Artificielle (/ Chemin de Borde-Rouge Tel : (0)5-61-28-54-36 _o BP 27 - 31326 Castanet-Tolosan Cedex Fax : (0)5-61-28-53-35 _/ |_ FRANCE \ ------------------------------- e-mail : chabrier@toulouse.inra.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7052 * Subject: Rd2txt bug From: "Dorer, David" Date: Mon, 5 Jul 2004 11:39:18 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7052 <== From mail@stat.math.ethz.ch Mon Jul 5 17:39:25 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 6951A108D7 for ; Mon, 5 Jul 2004 17:39:25 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08762-07 for ; Mon, 5 Jul 2004 17:39:24 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 5 Jul 2004 17:39:24 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i65FdN8W010047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jul 2004 17:39:23 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i65FdNP7010045 for R-bugs@biostat.ku.dk; Mon, 5 Jul 2004 17:39:23 +0200 Received: from PHSXCHICI3.partners.org (phsxchici3.mgh.harvard.edu [132.183.130.38]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i65FdJ74010013 for ; Mon, 5 Jul 2004 17:39:20 +0200 Received: by phsxchici3.mgh.harvard.edu with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Jul 2004 11:40:02 -0400 Message-ID: <098FF7AF9BBDD511B09500508BE393C507C84341@phsexch23.mgh.harvard.edu> From: "Dorer, David" To: "'r-bugs@r-project.org'" Subject: Rd2txt bug Date: Mon, 5 Jul 2004 11:39:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C462A6.1368C806" Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of ddorer@partners.org does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C462A6.1368C806 Content-Type: text/plain; charset="iso-8859-1" <> ------_=_NextPart_000_01C462A6.1368C806 Content-Type: text/plain; name="bug.txt" Content-Disposition: attachment; filename="bug.txt" I was trying to get text man pages (so I can read them in emacs). When I tried to convert the base.Rd file the machine ran for a long time then produced the following: /home/dorer/Rtar/R-1.8.1/bin/R CMD Rd2txt /home/dorer/Rtar/R-1.8.1/library/base/man/base.Rd too many pairs of braces in this file at /home/dorer/Rtar/R-1.8.1/share/perl/R/Rdconv.pm line 238, line 46892. Report bugs to . David Dorer MGH Biostatistics DDORER@PARTNERS.ORG ------_=_NextPart_000_01C462A6.1368C806-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7055 * Subject: Wrong object type produced - LANGSXP should be LISTSXP From: bauerda@ieee.org Date: Tue, 6 Jul 2004 20:25:04 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7055 <== From bauerda@ieee.org Tue Jul 6 20:25:04 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5F5FC108D7 for ; Tue, 6 Jul 2004 20:25:04 +0200 (CEST) From: bauerda@ieee.org To: R-bugs@biostat.ku.dk Subject: Wrong object type produced - LANGSXP should be LISTSXP Message-Id: <20040706182504.5F5FC108D7@slim.kubism.ku.dk> Date: Tue, 6 Jul 2004 20:25:04 +0200 (CEST) X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_20,NO_REAL_NAME,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, UPPERCASE_25_50 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: David Bauer Version: 1.9 OS: Linux Submission from: (NULL) (160.91.245.8) In the file gram.y, the xxsubscript function generates a LANGSXP with another LANGSXP as its CDR. I believe that this is a mistake and that the second LANGSXP should be a LISTSXP. The inputs a1, a3 are parameters to the subscript function (a2), and as such they should be in a dotted-pair list. David Bauer --- gram.y.orig 2003-11-15 05:40:35.000000000 -0500 +++ gram.y 2004-07-06 13:45:10.000000000 -0400 @@ -731,11 +731,11 @@ static SEXP xxsubscript(SEXP a1, SEXP a2, SEXP a3) { SEXP ans; if (GenerateCode) - PROTECT(ans = LCONS(a2, LCONS(a1, CDR(a3)))); + PROTECT(ans = LCONS(a2, CONS(a1, CDR(a3)))); else PROTECT(ans = R_NilValue); UNPROTECT_PTR(a3); UNPROTECT_PTR(a1); return ans; ==> 7055.reply.1 <== From p.dalgaard@biostat.ku.dk Wed Jul 7 00:56:13 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry.kubism.ku.dk (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 9E5ECFC09; Wed, 7 Jul 2004 00:56:13 +0200 (CEST) Received: from blueberry.kubism.ku.dk (localhost.localdomain [127.0.0.1]) by blueberry.kubism.ku.dk (8.12.8/8.12.8) with ESMTP id i66MsqYg021631; Wed, 7 Jul 2004 00:54:52 +0200 Received: (from pd@localhost) by blueberry.kubism.ku.dk (8.12.8/8.12.8/Submit) id i66MsphB021627; Wed, 7 Jul 2004 00:54:51 +0200 X-Authentication-Warning: blueberry.kubism.ku.dk: pd set sender to p.dalgaard@biostat.ku.dk using -f To: bauerda@ieee.org Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk Subject: Re: [Rd] Wrong object type produced - LANGSXP should be LISTSXP (PR#7055) References: <20040706182507.2731B108D8@slim.kubism.ku.dk> From: Peter Dalgaard Date: 07 Jul 2004 00:54:51 +0200 In-Reply-To: <20040706182507.2731B108D8@slim.kubism.ku.dk> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) bauerda@ieee.org writes: > Full_Name: David Bauer > Version: 1.9 > OS: Linux > Submission from: (NULL) (160.91.245.8) > > > In the file gram.y, the xxsubscript function generates a LANGSXP with another > LANGSXP as its CDR. I believe that this is a mistake and that the second > LANGSXP should be a LISTSXP. The inputs a1, a3 are parameters to the subscript > function (a2), and as such they should be in a dotted-pair list. Hmmm. Probably true in principle (as far as I can see, corresponding logic for funcalls does make the argument list an ordinary pairlist, not a language object). However, is it not a victimless crime? I can't think of a way to make it matter at the R level. It's the sort of thing that you tend not to want to fix if it isn't broken... Notice that z <- quote(x[2]) mode(z[-1]) returns call, but the same is true of any function call (and that's kind of weird, but a consequence of a general rule that [-indexing returns an object of the same mode as the original). [snip...] > - PROTECT(ans = LCONS(a2, LCONS(a1, CDR(a3)))); > + PROTECT(ans = LCONS(a2, CONS(a1, CDR(a3)))); -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7068 * Subject: Bug in Make or configure: spaces in path From: williams.elliot@bls.gov Date: Thu, 8 Jul 2004 01:50:10 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7068 <== From williams.elliot@bls.gov Thu Jul 8 01:50:10 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3ECC8108C1 for ; Thu, 8 Jul 2004 01:50:10 +0200 (CEST) From: williams.elliot@bls.gov To: R-bugs@biostat.ku.dk Subject: Bug in Make or configure: spaces in path Message-Id: <20040707235010.3ECC8108C1@slim.kubism.ku.dk> Date: Thu, 8 Jul 2004 01:50:10 +0200 (CEST) X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Elliot Williams Version: 1.9.1 OS: Linux Submission from: (NULL) (146.142.53.18) Hi, The usual configure/make procedure hangs when there is a space in the pathname. For instance, I had R in "/home/elliot/R Software/R-1.9.1/" and make complained that it couldn't find "Software/R-1.9.1/". Changing the directory to R_Software resolved the problem. This is a small problem, but it might bite new linux users who like to use spaces in directory names and don't know that it can cause troubles. Note that this is similar to a bug about commas in filepaths, number 5536. I do not, however, expect the earth. :-) Elliot. ==> 7068.reply.1 <== From maechler@stat.math.ethz.ch Thu Jul 8 11:36:37 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3725DEAC6 for ; Thu, 8 Jul 2004 11:36:37 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30523-02 for ; Thu, 8 Jul 2004 11:36:36 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Thu, 8 Jul 2004 11:36:36 +0200 (CEST) Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i689aZgr021374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2004 11:36:35 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.11/8.12.8/Submit) id i689aZOg001484; Thu, 8 Jul 2004 11:36:35 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16621.5539.556870.30632@gargle.gargle.HOWL> Date: Thu, 8 Jul 2004 11:36:35 +0200 To: williams.elliot@bls.gov Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Bug in Make or configure: spaces in path (PR#7068) In-Reply-To: <20040707235016.09165108C5@slim.kubism.ku.dk> References: <20040707235016.09165108C5@slim.kubism.ku.dk> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: Martin Maechler Received-SPF: none (hypatia: domain of maechler@stat.math.ethz.ch does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_ORBS,REFERENCES,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) >>>>> "williams" == williams elliot >>>>> on Thu, 8 Jul 2004 01:50:16 +0200 (CEST) writes: williams> Full_Name: Elliot Williams Version: 1.9.1 OS: williams> Linux Submission from: (NULL) (146.142.53.18) williams> Hi, williams> The usual configure/make procedure hangs when williams> there is a space in the pathname. williams> For instance, I had R in "/home/elliot/R williams> Software/R-1.9.1/" and make complained that it williams> couldn't find "Software/R-1.9.1/". Changing the williams> directory to R_Software resolved the problem. williams> This is a small problem, but it might bite new williams> linux users who like to use spaces in directory williams> names and don't know that it can cause troubles. Hmm, I think these new users should rather learn that it probably *will* cause much too much trouble and stop using spaces in file names.... {well, I can hear some people scream, but that's my humble opinion}. williams> Note that this is similar to a bug about commas in williams> filepaths, number 5536. I do not, however, expect williams> the earth. :-) I'm waiting for others to comment, but I wouldn't consider this a bug. Just don't use "crazy" directory names ("," or non-ASCII accents..) since this will bite you eventually anyway (i.e. not only with R), e.g. using an accented char, or Umlaut and moving your directory tree to a locale where these characters are not valid or at least not displayed usually. Martin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7072 * Subject: Reproducible Rterm crash. From: "Richard M. Heiberger" Date: Fri, 9 Jul 2004 15:27:56 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7072 <== From mail@stat.math.ethz.ch Fri Jul 9 21:28:43 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id AD9D7FBF9 for ; Fri, 9 Jul 2004 21:28:43 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08554-02 for ; Fri, 9 Jul 2004 21:28:42 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Fri, 9 Jul 2004 21:28:42 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i69JSfoR009759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jul 2004 21:28:41 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i69JSfii009757 for R-bugs@biostat.ku.dk; Fri, 9 Jul 2004 21:28:41 +0200 Received: from po-smtp1.temple.edu (po-smtp1.temple.edu [155.247.166.195]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i69JRweb009697 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 9 Jul 2004 21:28:40 +0200 Received: from po-d.temple.edu (po-d.temple.edu [155.247.166.222]) by po-smtp1.temple.edu (MOS 3.4.8-GR) with ESMTP id BTE58182; Fri, 9 Jul 2004 15:27:56 -0400 (EDT) Received: from 155.247.229.6 by po-d.temple.edu (MOS 3.4.8-GR) with HTTPS/1.1; Fri, 9 Jul 2004 15:27:56 -0400 Date: Fri, 9 Jul 2004 15:27:56 -0400 From: "Richard M. Heiberger" Subject: Reproducible Rterm crash. To: r-bugs@r-project.org X-Mailer: Webmail Mirapoint Direct 3.4.8-GR MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=po-smtp1.temple.edu Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of rmh@temple.edu does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_01,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org Reproducible Rterm crash. I drew a complicated graph, then resized the graphics window. R reported > Insufficient memory for resize. Killing device and then killed the device. It also killed itself. Windows saved c:\cygwin\tmp\WER3A8D.tmp.dir00\appcompat.txt I copied it to ~/tmp/appcompat.txt I can send it, if you ask for it. Windows gave all sorts of information in an "Error Report Contents" popup and then wouldn't let me copy it. Error Signature AppName: rterm.exe AppVer: 1.91.30621.0 ModName:ntdll.dll ModVer: 5.1.2600.1217 Offset: 00025a58 I copied the appended file bivnorm.s into the *R* buffer (running Rterm under ESS 5.2.1) and hit ENTER. The graphs eventually showed up. They were empty shells. When I resize the graph device, it crashed. I repeated the exercise on Windows NT4 and the resize worked correctly. The graph itself was still empty. This example works correctly on S-Plus and generates a series of wireplots of a rotated bivariate normal density. ##---------------------bivnorm.s---------------------------------------- ## Bivariate Normal density in 3-D space with various viewpoints. ## Based on the function example.draping2 in the trellis library. example.bivariate.normal <- function(rho=0, layout.in=c(3,3), lwd.in=.1, col.regions.in=trellis.par.get("regions")$col) { old.par <- par(lwd=lwd.in) on.exit(par(old.par)) x <- seq(-2, 2, length=33) y <- x fxy <- 1/(2*pi*sqrt(1-rho^2)) * exp(-.5/(1-rho^2) * outer(x^2, y^2, "+") - 2*rho*outer(x,y,"*")) angle <- c(22.5, 67.5, 112.5, 337.5, 157.5, 292.5, 247.5, 202.5) Angle <- rep(angle, rep(length(fxy), 8)) Viewing.Angle <- ordered(Angle, angle) wireframe(rep(fxy, 8) ~ rep(x[row(fxy)], 8) * rep(y[col(fxy)], 8) | Viewing.Angle, panel = function(x, y, subscripts, z, angle, ...) { w <- unique(angle[subscripts]) panel.wireframe(x, y, subscripts, z, screen = list(z = w, x = -60, y = 0), ...) }, angle = Angle, ## this is how to pass down external element strip = function(...) strip.default(..., strip.names = T, style = "1"), skip = c(F, F, F, F, T, F, F, F, F), drape = T, layout = layout.in, distance = 0.3, main = paste("Bivariate Normal, rho=", rho), xlab = list("x", cex = 0.4), ylab = list("y", cex = 0.4), zlab = list("f(x,y)", cex = 0.4), col.regions=col.regions.in) } ## example.bivariate.normal() # boring, with rho=0 example.bivariate.normal(.7) # all views on one page ### export.eps is not recommended for this example. ### The minimum lwd parameter is too thick on the graphsheet ## ### We recommend using a the postscript driver directly. ## black and white ## trellis.device(postscript, file=hh("conc/figure/bivnorm.eps"), color=F) ## strip.background0() ## example.bivariate.normal(.7, # all views on one page ## col.regions.in=rep(82:106, rep(4,25))) ## dev.off() ## ## color ## trellis.device(postscript, file=hh("conc/figure/bivnorm-color.eps"), color=T) ## strip.background0() ## example.bivariate.normal(.7) # all views on one page ## dev.off() example.bivariate.normal(.7, layout=c(1,1)) # each view on its own page ## One per page, cycle through pages with Ctrl-PageUp and Ctrl-PageDown ## ## This is the plot from which the figure in the book is taken. ## We use just the Viewing.Angle=112.5 panel. ## ### We recommend using a the postscript driver directly. ## black and white ## trellis.device(postscript, onefile=F, print.it=F, color=F) ## strip.background0() ## example.bivariate.normal(.7, layout=c(1,1), # One panel per page ## col.regions.in=rep(82:106, rep(4,25))) ## dev.off() ## ## manually rename ps.out.003.ps to hh("conc/figure/bivnorm1125.eps") ## ## color ## trellis.device(postscript, onefile=F, print.it=F, color=T) ## strip.background0() ## example.bivariate.normal(.7, layout=c(1,1)) # One panel per page ## dev.off() ## ## manually rename ps.out.003.ps to hh("conc/figure/bivnorm1125-color.eps") ## for (rho in seq(-.9,.9,.1)) # one page for each rho ## print(example.bivariate.normal(rho)) ##---------------------bivnorm.s---------------------------------------- # ###################################################### --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 9.1 year = 2004 month = 06 day = 21 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, package:methods, package:stats, package:utils, file:c:/HOME/rmh/hh/splus.library/HH/.RData, package:multcomp, package:mvtnorm, package:abind, package:graphics, package:lattice, package:grid, Autoloads, package:base ==> 7072.followup.1 <== From dmurdoch@pair.com Fri Jul 9 21:57:29 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 9ACA3FBF9 for ; Fri, 9 Jul 2004 21:57:29 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08705-03 for ; Fri, 9 Jul 2004 21:57:28 +0200 (CEST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by slam.kubism.ku.dk (Postfix) with SMTP for ; Fri, 9 Jul 2004 21:57:27 +0200 (CEST) Received: (qmail 35205 invoked from network); 9 Jul 2004 19:57:26 -0000 Received: from xi.pair.com (HELO localhost) (209.68.1.25) by relay.pair.com with SMTP; 9 Jul 2004 19:57:26 -0000 X-pair-Authenticated: 209.68.1.25 From: Duncan Murdoch To: rmh@temple.edu Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] Reproducible Rterm crash. (PR#7072) Date: Fri, 09 Jul 2004 15:57:31 -0400 Message-ID: References: <20040709192845.EC9C0FC09@slim.kubism.ku.dk> In-Reply-To: <20040709192845.EC9C0FC09@slim.kubism.ku.dk> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_ORBS,REFERENCES,USER_AGENT_FORTE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Fri, 9 Jul 2004 21:28:45 +0200 (CEST), rmh@temple.edu wrote : >Reproducible Rterm crash. > >I drew a complicated graph, then resized the graphics window. > >R reported >> Insufficient memory for resize. Killing device >and then killed the device. It also killed itself. I just tried your code (after loading lattice so it would run), and didn't crash. I think you just ran out of memory. We try to recover gracefully from situations like that, but it's hard, and especially hard to track down when we can't reproduce it. All I can suggest (and I know it's not much of a suggestion) is that you recompile R with debug information, then run it under gdb and see if you can figure out where we've missed some checks. It's possible that Emacs has something to do with this, but hard to know. You might find that running Rterm outside of Emacs works fine just because more memory is available. Duncan Murdoch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7075 * Subject: read.table, read.fwf, and na.strings From: "Richard M. Heiberger" Date: Sat, 10 Jul 2004 17:21:01 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7075 <== From mail@stat.math.ethz.ch Sat Jul 10 23:21:08 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 5CE8AE963 for ; Sat, 10 Jul 2004 23:21:08 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13481-07 for ; Sat, 10 Jul 2004 23:21:07 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Sat, 10 Jul 2004 23:21:06 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6ALL6Mw020943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Jul 2004 23:21:06 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6ALL6AI020941 for R-bugs@biostat.ku.dk; Sat, 10 Jul 2004 23:21:06 +0200 Received: from po-smtp2.temple.edu (po-smtp2.temple.edu [155.247.166.196]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6ALL2pJ020923 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 10 Jul 2004 23:21:04 +0200 Received: from po-d.temple.edu (po-d.temple.edu [155.247.166.222]) by po-smtp2.temple.edu (MOS 3.4.8-GR) with ESMTP id BSE19854; Sat, 10 Jul 2004 17:21:01 -0400 (EDT) Received: from 155.247.229.6 by po-d.temple.edu (MOS 3.4.8-GR) with HTTPS/1.1; Sat, 10 Jul 2004 17:21:01 -0400 Date: Sat, 10 Jul 2004 17:21:01 -0400 From: "Richard M. Heiberger" Subject: read.table, read.fwf, and na.strings To: r-bugs@r-project.org X-Mailer: Webmail Mirapoint Direct 3.4.8-GR MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=po-smtp2.temple.edu Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of rmh@temple.edu does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### Is this intended behavior for the read.fwf(na.strings="-999")? I anticipated that the na.strings would be padded with blanks. Therefore I anticipated getting the result tmp2 from the simpler na.strings in the tmp1 assignment? My anticipation is based on the documentation that says "Blank fields are also considered to be missing values." > na.strings: a vector of strings which are to be interpreted as 'NA' > values. Blank fields are also considered to be missing > values. temp.dat ---------------- 123456-999 01234 56-9990123412345 ---------------- read.fwf.test.r ------------------------------------------------ tmp1 <- read.fwf("temp.dat", na.strings="-999", col.names=LETTERS[1:4], widths=c(2,4,5,5)) tmp1 tmp2 <- read.fwf("temp.dat", na.strings=c("-999","-999 "), col.names=LETTERS[1:4], widths=c(2,4,5,5)) tmp2 ------------------------------------------------ > tmp1 A B C D 1 12 3456 -999 1234 2 56 NA 1234 12345 > tmp2 A B C D 1 12 3456 NA 1234 2 56 NA 1234 12345 --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 9.1 year = 2004 month = 06 day = 21 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/HH/.RData, package:methods, package:stats, package:utils, package:multcomp, package:mvtnorm, package:abind, package:graphics, package:lattice, package:grid, Autoloads, package:base ==> 7075.followup.1 <== From ligges@statistik.uni-dortmund.de Mon Jul 12 16:35:00 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0247DEAC4 for ; Mon, 12 Jul 2004 16:35:00 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22908-01 for ; Mon, 12 Jul 2004 16:34:59 +0200 (CEST) Received: from nx5.hrz.uni-dortmund.de (nx5.HRZ.Uni-Dortmund.DE [129.217.131.21]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Mon, 12 Jul 2004 16:34:58 +0200 (CEST) Received: from amadeus (Amadeus.Statistik.Uni-Dortmund.DE [129.217.206.1]) by nx5.hrz.uni-dortmund.de (Postfix) with ESMTP id 20ABD4AA5B5; Mon, 12 Jul 2004 16:34:58 +0200 (MET DST) Received: from [129.217.207.201] (unknown [129.217.207.201]) by amadeus (Postfix) with ESMTP id EE9197CE6; Mon, 12 Jul 2004 16:34:57 +0200 (CEST) Message-ID: <40F2A1B1.6040605@statistik.uni-dortmund.de> Date: Mon, 12 Jul 2004 16:35:29 +0200 From: Uwe Ligges Organization: Fachbereich Statistik, Universitaet Dortmund User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en, de-de, de MIME-Version: 1.0 To: rmh@temple.edu Cc: R-bugs@biostat.ku.dk Subject: Re: [Rd] read.table, read.fwf, and na.strings (PR#7075) References: <20040710212110.29A8AEAC3@slim.kubism.ku.dk> In-Reply-To: <20040710212110.29A8AEAC3@slim.kubism.ku.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) rmh@temple.edu wrote: > # Your mailer is set to "none" (default on Windows), > # hence we cannot send the bug report directly from R. > # Please copy the bug report (after finishing it) to > # your favorite email program and send it to > # > # r-bugs@r-project.org > # > ###################################################### > > > Is this intended behavior for the read.fwf(na.strings="-999")? > I anticipated that the na.strings would be padded with blanks. > Therefore I anticipated getting the result tmp2 from the simpler > na.strings in the tmp1 assignment? My anticipation is based on the > documentation that says > "Blank fields are also considered to be missing values." > > >>na.strings: a vector of strings which are to be interpreted as 'NA' >> values. Blank fields are also considered to be missing >> values. > > > > temp.dat A blank field in the first column of the first row is: 3456-999 01234 56-9990123412345 The field "-999 " cannot assumed to be blank in any sence from my point of view. Anyway, improving NA handling in read.fwf() is certainly something for the wishlist (particularly padding blanks for na.string(s)). Is anybody out there going to contribute (given anybody else thinks it is useful)? Uwe Ligges > ---------------- > 123456-999 01234 > 56-9990123412345 > ---------------- > > read.fwf.test.r > ------------------------------------------------ > tmp1 <- read.fwf("temp.dat", > na.strings="-999", > col.names=LETTERS[1:4], > widths=c(2,4,5,5)) > tmp1 > tmp2 <- read.fwf("temp.dat", > na.strings=c("-999","-999 "), > col.names=LETTERS[1:4], > widths=c(2,4,5,5)) > tmp2 > ------------------------------------------------ > > > >>tmp1 > > A B C D > 1 12 3456 -999 1234 > 2 56 NA 1234 12345 > >>tmp2 > > A B C D > 1 12 3456 NA 1234 > 2 56 NA 1234 12345 > > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 1 > minor = 9.1 > year = 2004 > month = 06 > day = 21 > language = R > > Windows XP Home Edition (build 2600) Service Pack 1.0 > > Search Path: > .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/HH/.RData, package:methods, package:stats, > package:utils, package:multcomp, package:mvtnorm, package:abind, package:graphics, > package:lattice, package:grid, Autoloads, package:base > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7082 * Subject: names in `getAnywhere' object don't match docs From: rpeng@jhsph.edu Date: Mon, 12 Jul 2004 23:36:05 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7082 <== From rpeng@jhsph.edu Mon Jul 12 23:36:06 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from blueberry (blueberry.kubism.ku.dk [192.38.19.4]) by slim.kubism.ku.dk (Postfix) with ESMTP id D94D5DE89 for ; Mon, 12 Jul 2004 23:36:05 +0200 (CEST) From: rpeng@jhsph.edu To: R-bugs@biostat.ku.dk Subject: names in `getAnywhere' object don't match docs Message-Id: <20040712213605.D94D5DE89@slim.kubism.ku.dk> Date: Mon, 12 Jul 2004 23:36:05 +0200 (CEST) X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,NO_REAL_NAME,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Full_Name: Roger D. Peng Version: 1.9.1 OS: Linux (Fedora Core 1) Submission from: (NULL) (162.129.44.120) The docs for getAnywhere say: Value: An object of class '"getAnywhere"'. This is a list with components name: the name searched for. funs: a list of objects found where: a character vector explaining where the object(s) were found visible: logical: is the object visible dups: logical: is the object identical to one earlier in the list. But the object returned by getAnywhere() has names > g <- getAnywhere("print") > names(g) [1] "name" "objs" "where" "visible" "dups" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7083 * Subject: Re: [Rd] read.table, read.fwf, and na.strings From: "Richard M. Heiberger" Date: Tue, 13 Jul 2004 00:06:24 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7083 <== From rmh@temple.edu Tue Jul 13 06:07:50 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id EE1C2EAC0 for ; Tue, 13 Jul 2004 06:07:49 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26011-08 for ; Tue, 13 Jul 2004 06:07:49 +0200 (CEST) Received: from po-smtp2.temple.edu (po-smtp2.temple.edu [155.247.166.196]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 13 Jul 2004 06:07:48 +0200 (CEST) Received: from po-d.temple.edu (po-d.temple.edu [155.247.166.222]) by po-smtp2.temple.edu (MOS 3.4.8-GR) with ESMTP id BSH10643; Tue, 13 Jul 2004 00:06:24 -0400 (EDT) Received: from 155.247.229.5 by po-d.temple.edu (MOS 3.4.8-GR) with HTTPS/1.1; Tue, 13 Jul 2004 00:06:24 -0400 Date: Tue, 13 Jul 2004 00:06:24 -0400 From: "Richard M. Heiberger" Subject: Re: [Rd] read.table, read.fwf, and na.strings (PR#7075) To: Uwe Ligges Cc: R-bugs@biostat.ku.dk X-Mailer: Webmail Mirapoint Direct 3.4.8-GR MIME-Version: 1.0 Message-Id: <8eefb5f3.5f112d0c.81a1c00@po-d.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=po-smtp2.temple.edu X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I am pleased to report that R already has the answer to my request in the strip.white=TRUE, argument. With this argument tmp3 <- read.fwf("temp.dat", na.strings="-999", strip.white=TRUE, col.names=LETTERS[1:4], widths=c(2,4,5,5)) tmp3 behaves exactly like I want it to behave. Please add it explicitly to the documentation for read.fwf and all will be well. Currently it is there only by indirect reference to read.table. Rich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7084 * Subject: text(x, y, labels) - recycling problems and RFC From: Martin Maechler Date: Tue, 13 Jul 2004 18:21:57 +0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7084 <== From mail@stat.math.ethz.ch Tue Jul 13 18:22:01 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id ECDD5108B5 for ; Tue, 13 Jul 2004 18:22:00 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29408-07 for ; Tue, 13 Jul 2004 18:22:00 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Tue, 13 Jul 2004 18:21:59 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6DGLxj6013187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2004 18:21:59 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6DGLxN8013185 for R-bugs@biostat.ku.dk; Tue, 13 Jul 2004 18:21:59 +0200 Received: from lynne.ethz.ch (lynne [129.132.58.30]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6DGLwZ1013167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2004 18:21:58 +0200 Received: (from maechler@localhost) by lynne.ethz.ch (8.12.11/8.12.8/Submit) id i6DGLvLr025440; Tue, 13 Jul 2004 18:21:57 +0200 From: Martin Maechler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16628.3109.702856.715318@gargle.gargle.HOWL> Date: Tue, 13 Jul 2004 18:21:57 +0200 To: R-bugs@stat.math.ethz.ch Subject: text(x, y, labels) - recycling problems and RFC X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: Martin Maechler Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of maechler@stat.math.ethz.ch does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,USER_AGENT_VM version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Not a bug necessarily, in text(), but at least an inconsistency, and a need for more documentation: Contrary to e.g., plot(), text(x,y,labels) *does* recycle it's arguments to some extent -- and probably has always in S. However it doesn't do all I think it should, i.e., plot(1:7); text(1:2, 1+ 1:3, LETTERS[1:4]) does recycle 'x' to c(1:2, 1) {length 3} to match 'y' but doesn't recycle to length 4 in order to match 'labels'. While one can well accept this, I believe it should give a warning since it silently 'drops' the "d". However, I'm proposing to consider S(-plus) compatibility here. In S-PLUS 6.1, the result of the above is identical to plot(1:7); text(rep(1:2,length=4), rep(1+ 1:3, length=4), LETTERS[1:4]) i.e. (x,y) is recycled to length 4, the length of 'labels'. Further note that in plot(1:7); text(1:2, 1+ 1:3, LETTERS[1:2], col=2:6) the 'labels' *are* recycled to length 3, matching (x,y) -- but not to length 5 of 'col' which is fine -- just not the other way around. I'd propose that R should recycle all three (x,y,labels) [but not more] to common length. BTW, "grid" graphics do recycle as well, at least grid.text(labels, x, y) does --- and as I see it does also recycle at least the 'rotation'. Martin Maechler ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7085 * Subject: $21446 From: "Leopoldo Rosado" Date: Tue, 13 Jul 2004 15:05:48 -0500 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7085 <== From l.rosado_xk@4b.es Tue Jul 13 22:00:33 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id D4CC1108B9 for ; Tue, 13 Jul 2004 22:00:33 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30442-02 for ; Tue, 13 Jul 2004 22:00:32 +0200 (CEST) Received: from wonderfulcatv.com.tw (unknown [219.241.179.115]) by slam.kubism.ku.dk (Postfix) with SMTP for ; Tue, 13 Jul 2004 22:00:30 +0200 (CEST) Received: from 162.197.208.77 by smtp.4b.es; Tue, 13 Jul 2004 20:05:50 +0000 Message-ID: From: "Leopoldo Rosado" To: r-bugs@biostat.ku.dk Subject: $21446 Date: Tue, 13 Jul 2004 15:05:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=1.7 required=5.0 tests=BAD_CREDIT,RCVD_IN_ORBS,SUBJ_DOLLARS version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.web-lender.com/p3/li.php?weo=71 Best Regards, Leopoldo ---- system information ---- writing like allow publication lies invoking users Policy object formatting container create fallback to collation elements States) Preferences colors application Unlike public session-like an ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7086 * Subject: umask problem From: Karel =?iso-8859-1?Q?Kulhav=FD?= Date: Wed, 14 Jul 2004 06:19:07 +0000 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7086 <== From mail@stat.math.ethz.ch Wed Jul 14 08:19:13 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 3B977108AF for ; Wed, 14 Jul 2004 08:19:13 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32747-08 for ; Wed, 14 Jul 2004 08:19:12 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 14 Jul 2004 08:19:12 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6E6JB0k018097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2004 08:19:11 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6E6JBCN018095 for R-bugs@biostat.ku.dk; Wed, 14 Jul 2004 08:19:11 +0200 Received: from beton.cybernet.src (cimice4.lam.cz [212.71.168.94]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6E6J8d1018068 for ; Wed, 14 Jul 2004 08:19:09 +0200 Received: from clock by beton.cybernet.src with local (Exim 4.30) id 1Bkd6h-00009u-Vv for r-bugs@r-project.org; Wed, 14 Jul 2004 06:19:07 +0000 Date: Wed, 14 Jul 2004 06:19:07 +0000 From: Karel =?iso-8859-1?Q?Kulhav=FD?= To: r-bugs@r-project.org Subject: umask problem Message-ID: <20040714061907.GA599@beton.cybernet.src> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Orientation: Gay Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of clock@twibright.com does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_10,RCVD_IN_ORBS,USER_AGENT_MUTT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hello R-1.9.0 when the user that compiles R has umask 027 and root has umask 022, then R is installed incorrectly: clock@beton:~$ R /usr/bin/R: line 156: /usr/lib/R/bin/R.bin: Permission denied /usr/bin/R: line 156: exec: /usr/lib/R/bin/R.bin: cannot execute: Success clock@beton:~$ ls -la /usr/lib/R/bin/R.bin -rwxr-x--- 1 root root 2032542 Jul 13 20:04 /usr/lib/R/bin/R.bin ^^^ Cl< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7087 * Subject: S.pecial S.tock S.ituation - FCON From: "Santos Boone" Date: Wed, 14 Jul 2004 16:16:36 +0200 (CEST) -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7087 <== From iqcmqibdlxce@yahoo.com Wed Jul 14 16:16:36 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 62E9F108BC for ; Wed, 14 Jul 2004 16:16:36 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03134-10 for ; Wed, 14 Jul 2004 16:16:27 +0200 (CEST) Received: from adsl-67-127-61-71.dsl.pltn13.pacbell.net (adsl-67-127-61-71.dsl.pltn13.pacbell.net [67.127.61.71]) by slam.kubism.ku.dk (Postfix) with SMTP for ; Wed, 14 Jul 2004 16:16:24 +0200 (CEST) X-Message-Info: FHO/kmezl/28/f/YP+1/122568345118212 Received: from guard.iqcmqibdlxce@yahoo.com ([176.192.225.120]) by dcp3-hxo52.iqcmqibdlxce@yahoo.com with Microsoft SMTPSVC(5.0.1879.4334); Wed, 14 Jul 2004 12:14:07 -0300 Received: from sophie.iqcmqibdlxce@yahoo.com ([155.190.88.51]) by arbitrary.iqcmqibdlxce@yahoo.com with MailEnable ESMTP; Wed, 14 Jul 2004 17:08:07 +0200 From: "Santos Boone" To: "R-bugs" Subject: S.pecial S.tock S.ituation - FCON MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk Message-Id: <20040714141636.62E9F108BC@slim.kubism.ku.dk> Date: Wed, 14 Jul 2004 16:16:36 +0200 (CEST) X-Spam-Status: No, hits=3.0 required=5.0 tests=EXCUSE_3,FORGED_YAHOO_RCVD,RCVD_IN_ORBS version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) **FCON****FCON****FCON****FCON****FCON***FCON** H.O.T New Issue - F.inancialContent, Inc. - T.ICKER: FCON H.UGE N.EWS: MediaNews Group Signs Network-Wide Licensing Agreement with FinancialContent Dont sleep on this s.tock - get in today! FCON will e.xplode on 14th of July and next week when even better news are e.xpected FCON j.ust r.eleased V.ery H.O.T news. Please read below, we expect that many newsle.tters will cover FCON in next 5 days and we believe the s.toc.k is headed to 2.50 If you take a look at the chart of FCON for the last 1 year you will find this is one of the most stable OTCBB stocks. --------------------------- Current P.rice : 1.45 Near-ter.m target: 2.70 Long-ter.m target: 3.50 --------------------------- +++ Our L.ast P.ick: XLPI ( we recemmended at 70 cents and now its $1.60) +++ How many times have you seen new issues e.xplode but you couldn't get your han.ds on t.hem? We are alert.ing you to a spec.ial com.pany with a uniq.ue bu.siness model that is set to expl.ode in next 1 mon.th -- this is y.our chan.ce to get in at the very begi.nning! This is also a chan.ce to get in ea.rly, where usu.ally only inst.itutional i.nvestors get in, at the beginning. The average investor rarely gets the opport.unity to get new issue shares at the begin.ning because brokers give them all to he.dge fun.ds and clients that do thou.sands of dolla.rs of commissi.on busin.ess with them, thereby leaving the small indi.vidual out in the COLD! This is exc.iting bu.siness in an exci.ting place and time. Don't be the one to look back and say, I had the chance to inve.st, but passed…. _________________________________________________________________________________________________________________ Ch.eck out there amaz.ing n.ews here: MediaNews Group Signs Network-Wide Licensing Agreement with FinancialContent SOUTH SAN FRANCISCO, Calif., Jul 13, 2004 /PRNewswire-FirstCall via COMTEX/ -- FinancialContent, Inc. (FCON) , a leading provider of financial data and business applications to online media and fin.ancial serv.ices compa.nies worl.dwide, today anno.unced that the Comp.any has entered into a major licensing agree.ment with MediaNe.ws Group to deliver custo.mized online fina.ncial channels across its network of media properties. MediaN.ews Group, Inc. is the nation's 7th-largest new.spaper company, with headqu.arters in Denver, Colorado. MediaNews Group and its affi.liated comp.anies publish 50 daily newspapers and 115 non-daily public.ations in 12 states, with daily and Sunday circulation of appro.ximately 2.1 million and 2.4 million respectively. In addition, MediaNews Group owns a CBS affili.ate in Anchorage, Alaska and four radio stations in Texas. MediaNews will implement the first deployments on the websi.tes for the Connecticut Post, the Denver Post, the Los Angeles Daily News and the Salt Lake Tribune. Forty other daily online editions will add custom financial channels over the next several weeks. "MediaNews represents the finest example to date of an enterprise customer lev.eraging all the features and capab.ilities of our Studio 3.5 content manage.ment platform," said Wing Yu, CEO of Fin.ancialContent. -------------------- D.i.s.c.l.a.i.m.e.r -------------------- Inform.ation within this email contains "f.orward look.ing state.ments" within the meaning of Sect.ion 27A of the Sec.urities Ac.t of 1933 and Sect.ion 21B of the Securit.ies Exc.hange Ac.t of 1934. Any stat.ements that express or involve discu.ssions with resp.ect to pre.dictions, goa.ls, expec.tations, be.liefs, pl.ans, proje.ctions, object.ives, assu.mptions or fut.ure eve.nts or perform.ance are not stat.ements of histo.rical fact and may be "forw.ard loo.king stat.ements." For.ward looking state.ments are based on expect.ations, estim.ates and project.ions at the time the statem.ents are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those prese.ntly anticipated. Forward look.ing statements in this action may be identified through the use of words su.ch as: "pro.jects", "for.esee", "expects", "est.imates," "be.lieves," "underst.ands" "wil.l," "part of: "anticip.ates," or that by stat.ements indi.cating certain actions "may," "cou.ld," or "might" occur. All information provided within this em.ail pertai.ning to inv.esting, st.ocks, securi.ties must be under.stood as informa.tion provided and not investm.ent advice. Eme.rging Equity Al.ert advi.ses all re.aders and subscrib.ers to seek advice from a registered profe.ssional secu.rities represent.ative before dec.iding to trade in sto.cks featured within this ema.il. None of the mate.rial within this rep.ort shall be constr.ued as any kind of invest.ment advi.ce. Please have in mind that the interpr.etation of the witer of this newsl.etter about the news published by the company does not represent the com.pany official sta.tement and in fact may differ from the real meaning of what the news rele.ase meant to say. Please read the news release by your.self and judge by yourself about the detai.ls in it. In compli.ance with Sec.tion 17(b), we discl.ose the hol.ding of FCON s.hares prior to the publi.cation of this report. Be aware of an inher.ent co.nflict of interest res.ulting from such holdi.ngs due to our intent to pro.fit from the liqui.dation of these shares. Sh.ares may be s.old at any time, even after posi.tive state.ments have been made regard.ing the above company. Since we own sh.ares, there is an inher.ent conf.lict of inte.rest in our statem.ents and opin.ions. Readers of this publi.cation are cauti.oned not to place und.ue relia.nce on forw.ard-looki.ng statements, which are based on certain assump.tions and expectati.ons invo.lving various risks and uncert.ainties, that could cause results to differ materi..ally from those set forth in the forw.ard- looking state.ments. Please be advi.sed that noth.ing within this em.ail shall cons.titute a solic.itation or an offer to buy or sell any s.ecurity menti.oned her.ein. This news.letter is neither a regi.stered inves.tment ad.visor nor affil.iated with any brok.er or dealer. All statements made are our express opinion only and should be treated as such. We may own, buy and sell any securi.ties menti.oned at any time. This report includes forw.ard-looki.ng stat.ements within the meaning of The Pri.vate Securi.ties Litig.ation Ref.orm Ac.t of 1995. These state.ments may include terms as "expe.ct", "bel.ieve", "ma.y", "wi.ll", "mo.ve","und.ervalued" and "inte.nd" or simil.ar terms. This news.letter was paid $7500 from th.ird p.arty to se.nd this report. PL.EASE DO YOUR OWN D.UE DI.LIGENCE B.EFORE INVES.TING IN ANY PRO.FILED COMP.ANY. You may lo.se mon.ey from inve.sting in Pen.ny St.ocks. To be removed from further emails send email to --------------------- mercy expeditious continent paz cranny haberdashery pertinent morphine robbins brassiere thaw immense leech severe transferral fantasia ian enigma jot upshot suggestion dorothea shingle disturb beast ballast bent brigantine cabinetry humpty . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7088 * Subject: Re: [R] constrOptim and function with additional parameters? From: Duncan Murdoch Date: Wed, 14 Jul 2004 10:25:07 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7088 <== From mail@stat.math.ethz.ch Wed Jul 14 16:25:12 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 1D0F0F32C for ; Wed, 14 Jul 2004 16:25:12 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03253-06 for ; Wed, 14 Jul 2004 16:25:11 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 14 Jul 2004 16:25:11 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6EEPAsd028601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2004 16:25:10 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6EEPAgB028599 for R-bugs@biostat.ku.dk; Wed, 14 Jul 2004 16:25:10 +0200 Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with SMTP id i6EEP83j028573 for ; Wed, 14 Jul 2004 16:25:09 +0200 Received: (qmail 7854 invoked from network); 14 Jul 2004 14:25:04 -0000 Received: from xi.pair.com (HELO localhost) (209.68.1.25) by relay.pair.com with SMTP; 14 Jul 2004 14:25:04 -0000 X-pair-Authenticated: 209.68.1.25 From: Duncan Murdoch To: "Roger D. Peng" Cc: Marlene Mueller , R-bugs@stat.math.ethz.ch Subject: Re: [R] constrOptim and function with additional parameters? Date: Wed, 14 Jul 2004 10:25:07 -0400 Message-ID: References: <13650.1089809941@www40.gmx.net> <40F53CC9.9070305@jhsph.edu> In-Reply-To: <40F53CC9.9070305@jhsph.edu> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of dmurdoch@pair.com does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_FORTE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) I've moved this from r-help to r-bugs. If you reply, please be careful that replies go to the right place: r-bugs if your comment is specifically about the bug (and it contains the PR# in the subject that will be added when this is cc'd to r-devel), r-devel if general discussion, not both. On Wed, 14 Jul 2004 10:01:45 -0400, "Roger D. Peng" wrote : >Actually, I think this is a bug. Take a look at this part of constrOptim: This is the problem all right, but it's a little tricky to fix. The problem is that "..." is documented as being additional parameters to pass through to optim(). You don't want to pass all of those to f(), only the ones that don't match optim()'s arg list. (And that has to be done carefully, because of partial argument matching.) I don't know of other cases where we edit the "..." list before passing it onwards. Are there any? > > > constrOptim >function (theta, f, grad, ui, ci, mu = 1e-04, control = list(), > method = if (is.null(grad)) "Nelder-Mead" else "BFGS", >outer.iterations = 10 >0, > outer.eps = 1e-05, ...) >{ > if (!is.null(control$fnscale) && control$fnscale < 0) > mu <- -mu > [...] > obj <- f(theta) > ^^^^^^^^^^^^^^^ > r <- R(theta, theta) > for (i in 1:outer.iterations) { > obj.old <- obj > r.old <- r > [...] >} > >So the object function `f' is called on the starting value `theta' but >the `...' is not passed through. > >-roger > >Duncan Murdoch wrote: >> On Wed, 14 Jul 2004 14:59:01 +0200 (MEST), "Marlene Mueller" >> wrote : >> >> >>>How can I use a function with some additional input parameters >>>in constrOptim? For example, something like >>> >>>fr <- function(x,a) { ## Rosenbrock Banana function >>> x1 <- x[1] >>> x2 <- x[2] >>> a * (x2 - x1 * x1)^2 + (1 - x1)^2 >>>} >>> >>>where the optimum is to be found w.r.t. x. Calling >>>optim(c(-1.2,1), fr, NULL, a=100) works as expected, but I fail >>>to provide the a=100 in the constrained case: >>> >>> >>>> constrOptim(c(-1.2,0.9), fr, NULL, ui=rbind(c(-1,0),c(0,-1)), >>> >>>ci=c(-1,-1),a=100) >>>Error in f(theta) : Argument "a" is missing, with no default >>> >>>Is this a bug or is there a different solution that I miss here? >> >> >> I can't spot why your use of constrOptim isn't working, but you should >> be able to workaround it by doing something like this: >> >> applyDefaults <- function(fn, ...) { >> function(x) fn(x, ...) >> } >> >> constrOptim(c(-1.2,0.9), applyDefaults(fr, a=100), NULL, >> ui=rbind(c(-1,0),c(0,-1)),ci=c(-1,-1)) >> >> The applyDefaults function creates a new function which evaluates the >> old one with some of the parameters set to fixed values. >> >> Duncan Murdoch >> >> ______________________________________________ >> R-help@stat.math.ethz.ch mailing list >> https://www.stat.math.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7089 * Subject: Re: [R] constrOptim and function with additional parameters? From: "Roger D. Peng" Date: Wed, 14 Jul 2004 10:38:28 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7089 <== From mail@stat.math.ethz.ch Wed Jul 14 16:38:32 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id C7ED5108B5 for ; Wed, 14 Jul 2004 16:38:32 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03253-10 for ; Wed, 14 Jul 2004 16:38:31 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 14 Jul 2004 16:38:31 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6EEcVMq000651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2004 16:38:31 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6EEcVZW000647 for R-bugs@biostat.ku.dk; Wed, 14 Jul 2004 16:38:31 +0200 Received: from gateway1.jhsph.edu (gateway1.jhsph.edu [162.129.40.71]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6EEcTOv000611 for ; Wed, 14 Jul 2004 16:38:29 +0200 Received: from unknown (HELO XCH-VN01.sph.ad.jhsph.edu) (172.30.34.41) by gateway1.jhsph.edu with ESMTP; 14 Jul 2004 10:38:33 -0400 X-SBRS-GW1: None X-Ironport-AV: i="3.81R,168,1083556800"; d="scan'208"; a="1908304:sNHT34543106" Received: from owa-1.sph.ad.jhsph.edu ([172.30.34.47]) by XCH-VN01.sph.ad.jhsph.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 10:38:28 -0400 Received: from [10.20.80.12] ([10.20.80.12]) by owa-1.sph.ad.jhsph.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Jul 2004 10:38:28 -0400 Message-ID: <40F54564.4000204@jhsph.edu> Date: Wed, 14 Jul 2004 10:38:28 -0400 From: "Roger D. Peng" User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Murdoch Cc: Marlene Mueller , R-bugs@stat.math.ethz.ch Subject: Re: [R] constrOptim and function with additional parameters? References: <13650.1089809941@www40.gmx.net> <40F53CC9.9070305@jhsph.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2004 14:38:28.0524 (UTC) FILETIME=[3A39BEC0:01C469B0] Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of rpeng@jhsph.edu does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Okay, looking at the docs, then it's not a bug, since the "..." argument is not actually documented as "other arguments passed to f or grad". However, that *is* how it's document in `optim', so one can see how this might cause some confusion. Now, it's not clear to me which other arguments need to be passed to `optim' except perhaps `hessian'. Am I missing something? -roger Duncan Murdoch wrote: > I've moved this from r-help to r-bugs. If you reply, please be > careful that replies go to the right place: r-bugs if your comment is > specifically about the bug (and it contains the PR# in the subject > that will be added when this is cc'd to r-devel), r-devel if general > discussion, not both. > > On Wed, 14 Jul 2004 10:01:45 -0400, "Roger D. Peng" > wrote : > > >>Actually, I think this is a bug. Take a look at this part of constrOptim: > > > This is the problem all right, but it's a little tricky to fix. The > problem is that "..." is documented as being additional parameters to > pass through to optim(). You don't want to pass all of those to f(), > only the ones that don't match optim()'s arg list. (And that has to > be done carefully, because of partial argument matching.) > > I don't know of other cases where we edit the "..." list before > passing it onwards. Are there any? > > >>>constrOptim >> >>function (theta, f, grad, ui, ci, mu = 1e-04, control = list(), >> method = if (is.null(grad)) "Nelder-Mead" else "BFGS", >>outer.iterations = 10 >>0, >> outer.eps = 1e-05, ...) >>{ >> if (!is.null(control$fnscale) && control$fnscale < 0) >> mu <- -mu >> [...] >> obj <- f(theta) >> ^^^^^^^^^^^^^^^ >> r <- R(theta, theta) >> for (i in 1:outer.iterations) { >> obj.old <- obj >> r.old <- r >> [...] >>} >> >>So the object function `f' is called on the starting value `theta' but >>the `...' is not passed through. >> >>-roger >> >>Duncan Murdoch wrote: >> >>>On Wed, 14 Jul 2004 14:59:01 +0200 (MEST), "Marlene Mueller" >>> wrote : >>> >>> >>> >>>>How can I use a function with some additional input parameters >>>>in constrOptim? For example, something like >>>> >>>>fr <- function(x,a) { ## Rosenbrock Banana function >>>>x1 <- x[1] >>>>x2 <- x[2] >>>>a * (x2 - x1 * x1)^2 + (1 - x1)^2 >>>>} >>>> >>>>where the optimum is to be found w.r.t. x. Calling >>>>optim(c(-1.2,1), fr, NULL, a=100) works as expected, but I fail >>>>to provide the a=100 in the constrained case: >>>> >>>> >>>> >>>>>constrOptim(c(-1.2,0.9), fr, NULL, ui=rbind(c(-1,0),c(0,-1)), >>>> >>>>ci=c(-1,-1),a=100) >>>>Error in f(theta) : Argument "a" is missing, with no default >>>> >>>>Is this a bug or is there a different solution that I miss here? >>> >>> >>>I can't spot why your use of constrOptim isn't working, but you should >>>be able to workaround it by doing something like this: >>> >>>applyDefaults <- function(fn, ...) { >>> function(x) fn(x, ...) >>>} >>> >>>constrOptim(c(-1.2,0.9), applyDefaults(fr, a=100), NULL, >>>ui=rbind(c(-1,0),c(0,-1)),ci=c(-1,-1)) >>> >>>The applyDefaults function creates a new function which evaluates the >>>old one with some of the parameters set to fixed values. >>> >>>Duncan Murdoch >>> >>>______________________________________________ >>>R-help@stat.math.ethz.ch mailing list >>>https://www.stat.math.ethz.ch/mailman/listinfo/r-help >>>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >>> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7090 * Subject: Online notice From: "WebCamFan" Date: Wed, 14 Jul 2004 17:30:34 -0200 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7090 <== From xmbrgqw@hush.com Wed Jul 14 20:36:00 2004 Return-Path: X-Original-To: r-bugs@biostat.ku.dk Delivered-To: r-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 0F58C108BC; Wed, 14 Jul 2004 20:36:00 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04652-07; Wed, 14 Jul 2004 20:35:39 +0200 (CEST) Received: from 201-1-47-225.dsl.telesp.net.br (unknown [201.1.47.225]) by slam.kubism.ku.dk (Postfix) with SMTP id 812682776; Wed, 14 Jul 2004 20:35:34 +0200 (CEST) X-Message-Info: 31X375PSitjx1NV191vvdIPSmgZY78aWOI7icbXvryL64OSV991 Received: from mail pickup service by 201.1.47.225 with Microsoft SMTPSVC; Wed, 14 Jul 2004 23:24:34 +0400 Content-Class: urn:content-classes:message Reply-To: "WebCamFan" From: "WebCamFan" To: r-bugs@biostat.ku.dk Cc: sr@biostat.ku.dk, pka@biostat.ku.dk, p.dalgaard@biostat.ku.dk Subject: Online notice Date: Wed, 14 Jul 2004 17:30:34 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--98975087543751721155" X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk Message-Id: <20040714183600.0F58C108BC@slim.kubism.ku.dk> X-Spam-Status: No, hits=1.2 required=5.0 tests=BAYES_60,RCVD_IN_ORBS version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) ----98975087543751721155 Content-Type: text/plain; charset="iso-3919-7" Content-Transfer-Encoding: quoted-printable Online notice: On-LINE <<<<<<<<<<<< Brooks has sent you an invitation for a =93Friendly Chat=94, To ACCEPT... = http://www.s2khost.biz/brooke/?RID=3Dsexyme <<<<<<<<<<<< Don't like girls hit ( Ctrl+Alt+F4 ) To REFUSE ----98975087543751721155-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * PR# 7091 * Subject: tracing something in a namespace From: "Richard M. Heiberger" Date: Wed, 14 Jul 2004 15:32:59 -0400 -- no notes -- ~~~~~~~~~~ original reports follow ~~~~~~~~~~ ==> 7091 <== From mail@stat.math.ethz.ch Wed Jul 14 21:33:05 2004 Return-Path: X-Original-To: R-bugs@biostat.ku.dk Delivered-To: R-bugs@biostat.ku.dk Received: from localhost (slam.kubism.ku.dk [192.38.18.22]) by slim.kubism.ku.dk (Postfix) with ESMTP id 8F4AE108C6 for ; Wed, 14 Jul 2004 21:33:05 +0200 (CEST) Received: from slam.kubism.ku.dk ([127.0.0.1]) by localhost (slam [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04956-05 for ; Wed, 14 Jul 2004 21:33:04 +0200 (CEST) Received: from hypatia.math.ethz.ch (hypatia.ethz.ch [129.132.58.23]) by slam.kubism.ku.dk (Postfix) with ESMTP for ; Wed, 14 Jul 2004 21:33:04 +0200 (CEST) Received: from hypatia.math.ethz.ch (localhost [127.0.0.1]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6EJX4X3004802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jul 2004 21:33:04 +0200 Received: (from mail@localhost) by hypatia.math.ethz.ch (8.12.11/8.12.11/Submit) id i6EJX42C004800 for R-bugs@biostat.ku.dk; Wed, 14 Jul 2004 21:33:04 +0200 Received: from po-smtp1.temple.edu (po-smtp1.temple.edu [155.247.166.195]) by hypatia.math.ethz.ch (8.12.11/8.12.11) with ESMTP id i6EJX1hs004781 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 14 Jul 2004 21:33:02 +0200 Received: from po-d.temple.edu (po-d.temple.edu [155.247.166.222]) by po-smtp1.temple.edu (MOS 3.4.8-GR) with ESMTP id BTR58109; Wed, 14 Jul 2004 15:32:59 -0400 (EDT) Received: from 155.247.229.6 by po-d.temple.edu (MOS 3.4.8-GR) with HTTPS/1.1; Wed, 14 Jul 2004 15:32:59 -0400 Date: Wed, 14 Jul 2004 15:32:59 -0400 From: "Richard M. Heiberger" Subject: tracing something in a namespace To: r-bugs@r-project.org X-Mailer: Webmail Mirapoint Direct 3.4.8-GR MIME-Version: 1.0 Message-Id: <9e3bfdcd.5fe9d61e.8781800@po-d.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=po-smtp1.temple.edu Received-SPF: pass (hypatia: localhost is always allowed.) Received-SPF: none (hypatia: domain of rmh@temple.edu does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at pubhealth.ku.dk X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,RCVD_IN_ORBS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### > x <- rnorm(10) > y <- 1:10 > xyplot(y ~ x) > trace(lattice:::print.trellis, exit=recover) [1] "print.trellis" Warning message: Assigning over the binding of symbol "print.trellis" in environment/package "lattice" in: .assignOverBinding(what, newFun, whereF) > xyplot(y ~ x) > untrace(lattice:::print.trellis) Error in untrace(lattice:::print.trellis) : Argument what should be the name of a function > Something isn't right. I see three possibilities. a. tracing something in a namespace is prohibited and I didn't get an error, instead I got a warning. b. tracing in a namespace is acceptable, but the trace didn't work. c. untrace doesn't recognize lattice:::print.trellis as the name of a function, even though trace did. --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 9.1 year = 2004 month = 06 day = 21 language = R Windows XP Home Edition (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, file:c:/HOME/rmh/hh/splus.library/HH/.RData, package:methods, package:stats, package:utils, package:multcomp, package:mvtnorm, package:abind, package:graphics, package:lattice, package:grid, Autoloads, package:base ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~