=================================================
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 <paradis@isem.univ-montp2.fr>
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 <r-bugs@biostat.ku.dk>; 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 <m16JCqF-000IZvC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <paradis@isem.univ-montp2.fr>
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 <p.dalgaard@biostat.ku.dk>
Date: 26 Dec 2001 15:31:27 +0100
In-Reply-To: <200112261207.NAA13242@pubhealth.ku.dk>
Message-ID: <x2heqet5mo.fsf@blueberry.kubism.ku.dk>
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 <ripley@stats.ox.ac.uk>
X-X-Sender: <ripley@gannet.stats>
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
cc: <paradis@isem.univ-montp2.fr>, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] bug with var(rep(1e30, 3)) (PR#1228)
In-Reply-To: <x2heqet5mo.fsf@blueberry.kubism.ku.dk>
Message-ID: <Pine.LNX.4.31.0112261550130.12728-100000@gannet.stats>
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 <ripley@stats.ox.ac.uk>
Cc: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>,
<paradis@isem.univ-montp2.fr>, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] bug with var(rep(1e30, 3)) (PR#1228)
References: <Pine.LNX.4.31.0112261550130.12728-100000@gannet.stats>
From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
Date: 26 Dec 2001 17:59:59 +0100
In-Reply-To: <Pine.LNX.4.31.0112261550130.12728-100000@gannet.stats>
Message-ID: <x2vgetrk6o.fsf@blueberry.kubism.ku.dk>
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 <ripley@stats.ox.ac.uk> 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: <maechler@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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 <daheiser@gvn.net>
>>>>> 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 <maechler@stat.math.ethz.ch> 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 <R-bugs@biostat.ku.dk>; 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 <p.dalgaard@biostat.ku.dk>
Date: 02 May 2003 00:20:06 +0200
In-Reply-To: <200305012044.h41Ki02b017789@pubhealth.ku.dk>
Message-ID: <x265oujomh.fsf@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <dmurdoch@pair.com>
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: <c783bv43uq0raa1km9a7qqs0ri7pjmo1gu@4ax.com>
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 <welinder@rentec.com>
To: p.dalgaard@biostat.ku.dk
CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk
In-reply-to: <x265oujomh.fsf@biostat.ku.dk> (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> <x265oujomh.fsf@biostat.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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Mon, 22 Sep 2003 14:47:19 +0100 (BST)
From: Tim Massingham <tim.massingham@ebi.ac.uk>
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 <welinder@rentec.com>
>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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Mon, 22 Sep 2003 14:49:04 +0100 (BST)
From: Tim Massingham <tim.massingham@ebi.ac.uk>
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 <liebscher@gsf.de>
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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Fri, 12 Dec 2003 11:21:36 +0100 (MET)
From: Volkmar Liebscher <liebscher@gsf.de>
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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: liebscher@gsf.de
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Bug in pbinom? (PR#5727)
In-Reply-To: <20031212101923.309D2FC01@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0312121038390.13347-100000@gannet.stats>
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: <Nick.Efthymiou@Schwab.com>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: Nick.Efthymiou@schwab.com
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Accuracy: Correct sums in rowSums(), colSums() (PR#6196)
In-Reply-To: <20031230005720.9CEC71044D@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0312300813410.10660-100000@gannet.stats>
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" <daheiser@gvn.net>
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: <daheiser@gvn.net>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Mon, 5 Apr 2004 19:23:36 -0700
From: "David Heiser" <daheiser@gvn.net>
To: <r-bugs@biostat.ku.dk>
Subject: Accuracy Bug 1228
Date: Mon, 5 Apr 2004 19:23:35 -0700
Message-ID: <MDBBIKBEJOFIDACIIADNEEKLCEAA.daheiser@gvn.net>
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: <terra@gnome.org>
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 <R-bugs@biostat.ku.dk>; 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 <john.maindonald@anu.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <m158XFN-000JbdC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <john.maindonald@anu.edu.au>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
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: <Pine.WNT.4.44.0203052125210.1136-100000@tern.stats>
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 <maechler@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
This is a bad bug as reported by Robin Hankin,
it is still in "R-patched" ...
##- From: Robin Hankin <r.hankin@auckland.ac.nz>
##- 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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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 <r.hankin@auckland.ac.nz>
> ##- 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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <ripley@stats.ox.ac.uk>
Cc: R-bugs@stat.math.ethz.ch, R-core@stat.math.ethz.ch
Subject: Re: bad fisher.test() bug (PR#1662)
In-Reply-To: <Pine.GSO.4.44.0206131000030.1025-100000@auk.stats>
References: <15624.23861.930057.723845@gargle.gargle.HOWL>
<Pine.GSO.4.44.0206131000030.1025-100000@auk.stats>
X-Mailer: VM 7.07 under Emacs 20.7.1
Reply-To: Martin Maechler <maechler@stat.math.ethz.ch>
(CC'ed to R-bugs ``for the record'')
>>>>> "BDR" == Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes:
BDR> On Thu, 13 Jun 2002, Martin Maechler wrote:
>> >>>>> "MM" == Martin Maechler
>> <maechler@stat.math.ethz.ch> writes:
>>
>> >>>>> "BDR" == Brian D Ripley <ripley@stats.ox.ac.uk>
>> 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
Sender: ripley@auk.stats
To: maechler@stat.math.ethz.ch
cc: R-bugs@biostat.ku.dk, <r.hankin@auckland.ac.nz>
Subject: Re: fisher.test FEXACT memory bug "should not occur" (PR#1662)
In-Reply-To: <200206130622.IAA16038@pubhealth.ku.dk>
Message-ID: <Pine.GSO.4.44.0206131210510.16576-100000@auk.stats>
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 <r.hankin@auckland.ac.nz>
> ##- 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 <R-bugs@biostat.ku.dk>; 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: <ripley@gannet.stats>
To: Martin Maechler <maechler@stat.math.ethz.ch>
cc: <R-bugs@stat.math.ethz.ch>
Subject: Re: bad fisher.test() bug (PR#1662)
In-Reply-To: <15624.28889.858685.234909@gargle.gargle.HOWL>
Message-ID: <Pine.LNX.4.31.0206131654050.2219-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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: <ripley@gannet.stats>
To: <Jarno.Tuimala@Helsinki.Fi>
cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>
Subject: Re: problem with qq( ) (PR#1729)
In-Reply-To: <200207020837.KAA28253@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0207021005500.25466-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <deepayansarkar@yahoo.com>
Subject: Re: problem with qq( ) (PR#1729)
To: R-bugs@biostat.ku.dk
In-Reply-To: <Pine.LNX.4.31.0207021005500.25466-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <stdlib.h>
~~~~~~~~~~ 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <bates@stat.wisc.edu>
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 <bates@bates5.stat.wisc.edu>
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 <u9801539@leonard.anu.edu.au>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <u9801539@leonard.anu.edu.au>
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 <fharrell@virginia.edu>
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 <r-bugs@biostat.ku.dk>; 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 <fharrell@virginia.edu>
To: r-bugs@biostat.ku.dk
Cc: Thomas Lumley <tlumley@u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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: <mschwartz@medanalytics.com>
From: "Marc Schwartz" <mschwartz@medanalytics.com>
To: <John_Hendrickx@yahoo.com>, <r-devel@stat.math.ethz.ch>
Cc: <R-bugs@biostat.ku.dk>
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 <korner@eco.umnw.ethz.ch>
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 <r-bugs@biostat.ku.dk>; 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 <korner@eco.umnw.ethz.ch>
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" <jrogers@cantatapharm.com>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <jrogers@cantatapharm.com>
To: <r-bugs@r-project.org>
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
<anyname>.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. <rogers@cantatapharm.com>
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 <R-bugs@biostat.ku.dk>; 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: <Pine.LNX.4.44.0302012205160.12055-100000@gannet.stats>
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
> <anyname>.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. <rogers@cantatapharm.com>
> 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 <R-bugs@biostat.ku.dk>; 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" <jrogers@cantatapharm.com>
To: <ripley@stats.ox.ac.uk>
Cc: <R-bugs@biostat.ku.dk>
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 <anyname>.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. <rogers@cantatapharm.com>
> > 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 <rmh@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Sun, 27 Apr 2003 01:56:30 -0400 (EDT)
Date: Sun, 27 Apr 2003 01:56:30 -0400
From: Rich Heiberger <rmh@surfer.sbm.temple.edu>
To: <r-bugs@r-project.org>
Subject: bug and proposed fix in print.trellis 1.7.0
Message-ID: <Pine.SGI.4.32.0304270153310.2626055-400000@surfer.sbm.temple.edu>
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: <Pine.SGI.4.32.0304270156300.2626055@surfer.sbm.temple.edu>
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: <Pine.SGI.4.32.0304270156301.2626055@surfer.sbm.temple.edu>
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: <Pine.SGI.4.32.0304270156302.2626055@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <rmh@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <deepayan@stat.wisc.edu>
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 <rmh@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <rmh@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <deepayan@stat.wisc.edu>
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 <jerome@hivnet.ubc.ca>
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 <r-bugs@biostat.ku.dk>; 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 <jerome@hivnet.ubc.ca>
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 <tlumley@u.washington.edu>
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 <tlumley@u.washington.edu>
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 <r-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
To: Jerome Asselin <jerome@hivnet.ubc.ca>
cc: r-bugs@biostat.ku.dk
Subject: Re: frailty models in survreg() -- survival package
In-Reply-To: <200305062242.PAA26505@hivnet.ubc.ca>
Message-ID: <Pine.A41.4.44.0305061551340.23944-100000@homer14.u.washington.edu>
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 <r-bugs@biostat.ku.dk>; 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 <jerome@hivnet.ubc.ca>
Organization: BC Centre for Excellence in HIV/AIDS
To: Thomas Lumley <tlumley@u.washington.edu>
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: <Pine.A41.4.44.0305061551340.23944-100000@homer14.u.washington.edu>
In-Reply-To: <Pine.A41.4.44.0305061551340.23944-100000@homer14.u.washington.edu>
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 <p.dalgaard@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <p.dalgaard@biostat.ku.dk>
Date: 12 May 2003 18:19:28 +0200
Message-ID: <x21xz49lyn.fsf@biostat.ku.dk>
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 <deepayan@stat.wisc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: johannes.freudenberg@imise.uni-leipzig.de
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] split.AffyBatch (PR#3197)
In-Reply-To: <200306051405.h55E512b010237@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.44.0306051601210.1215-100000@gannet.stats>
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" <johannes.freudenberg@imise.uni-leipzig.de>
--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 <R-bugs@biostat.ku.dk>; 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: <Pine.LNX.4.44.0306051601210.1215-100000@gannet.stats>
From: "Johannes Freudenberg" <johannes.freudenberg@imise.uni-leipzig.de>
MIME-Version: 1.0
subject: Re: [Rd] split.AffyBatch (PR#3197)
To: "Prof Brian Ripley" <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <davidD@qimr.edu.au>
#
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" <gerard.tromp@sanger.med.wayne.edu>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Sun, 3 Aug 2003 22:44:47 -0400 (EDT)
From: "Gerard Tromp" <gerard.tromp@sanger.med.wayne.edu>
To: <r-bugs@biostat.ku.dk>
Subject: R package {genetics} function summary.genotype -- H and PIC return incorrect values.
Date: Sun, 3 Aug 2003 22:45:06 -0400
Message-ID: <JPEFJIPNHLIGNJFDNCJFMEOOCDAA.gerard.tromp@sanger.med.wayne.edu>
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 <davidD@qimr.edu.au>
#
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]" <m.grum@cgiar.org>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <QF2C5NQZ>; Sun, 03 Aug 2003 23:52:49 -0700
Date: Sun, 03 Aug 2003 23:41:39 -0700
From: "Grum, Mikkel [IPGRI-SSA-Nairobi]" <m.grum@cgiar.org>
Subject: hclust() and agnes() method="average" divergence
To: r-bugs@r-project.org
Cc: maechler@stat.math.ethz.ch
Message-id:
<FC788AB9771FD6118E6F0002A5AD7B8F0188F409@icrafnttrain.icraf.cgiar.org>
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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
>>>>> "MikG" == m grum <m.grum@cgiar.org>
>>>>> 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 <maechler@stat.math.ethz.ch> 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 <ligges@statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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
<gregory_r_warnes@groton.pfizer.com>), 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 <davidD@qimr.edu.au>
> #
> 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
>>>>> "kjetil" == kjetil halvorsen <kjetil@entelnet.bo>
>>>>> 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 <maechler@stat.math.ethz.ch> 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 <R-bugs@biostat.ku.dk>; 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 <p.dalgaard@biostat.ku.dk>
Date: 22 Oct 2003 20:01:48 +0200
In-Reply-To: <200310221710.h9MHA40P016151@pubhealth.ku.dk>
Message-ID: <x21xt540dv.fsf@biostat.ku.dk>
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: <jean.coursol@math.u-psud.fr>
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 <R-bugs@biostat.ku.dk>; 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: <dmurdoch@pair.com>
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 <R-bugs@biostat.ku.dk>; 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 <dmurdoch@pair.com>
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: <i4t6sv8du0f8q3dgmhn86u1pojmvea13h7@4ax.com>
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
<albrecht.gebhardt@uni-klu.ac.at> and the Windows binary package
maintainer Uwe Ligges <ligges@statistik.uni-dortmund.de>, 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: Duncan Murdoch <dmurdoch@pair.com>
Cc: jean.coursol@math.u-psud.fr, <R-bugs@biostat.ku.dk>,
<r-devel@stat.math.ethz.ch>
Subject: Re: [Rd] O2 optimization produces wrong code (PR#5315)
In-Reply-To: <i4t6sv8du0f8q3dgmhn86u1pojmvea13h7@4ax.com>
Message-ID: <Pine.LNX.4.44.0311251543390.6601-100000@gannet.stats>
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
> <albrecht.gebhardt@uni-klu.ac.at> and the Windows binary package
> maintainer Uwe Ligges <ligges@statistik.uni-dortmund.de>, 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: <schiessler@agere.com>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: schiessler@agere.com
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] memory leak (PR#5476)
In-Reply-To: <20031203050158.86615EC53@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0312030748170.21703-100000@gannet.stats>
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: <schiessler@agere.com>
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 <R-bugs@biostat.ku.dk>; 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 <YFAJ5XJY>; Wed, 3 Dec 2003 11:11:41 -0500
Message-ID: <3FCE0B37.89A2D4C7@agere.com>
From: "Schiessler, Gary E (Gary)" <schiessler@agere.com>
To: Prof Brian Ripley <ripley@stats.ox.ac.uk>
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 <wolfram@fischer-zim.ch>
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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.R-project.org>; 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 <r-bugs@lists.R-project.org>; 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 <wolfram@fischer-zim.ch>
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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: wolfram@fischer-zim.ch
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: (PR#6005) Re: [Rd] [R] lattice: levelplot: error: min not meaningful
In-Reply-To: <20031222163049.BFEB4104AC@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0312221648390.12528-100000@gannet.stats>
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: <deepayan@stat.wisc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <deepayan@stat.wisc.edu>
To: Prof Brian Ripley <ripley@stats.ox.ac.uk>, 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: <Pine.LNX.4.44.0312221648390.12528-100000@gannet.stats>
In-Reply-To: <Pine.LNX.4.44.0312221648390.12528-100000@gannet.stats>
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 <svetlana.eden@vanderbilt.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@R-project.org>; 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 <R-bugs@R-project.org>; 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 <R-bugs@R-project.org>; Fri, 26 Mar 2004 15:43:59 -0600 (CST)
Date: Fri, 26 Mar 2004 15:45:18 -0600
From: Svetlana Eden <svetlana.eden@vanderbilt.edu>
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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 26 Mar 2004 23:40:07 +0100
In-Reply-To: <20040326214433.3D2A010438@slim.kubism.ku.dk>
Message-ID: <x2zna3jkqg.fsf@biostat.ku.dk>
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: <phddas@yahoo.com>
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 <R-bugs@biostat.ku.dk>; 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: <giles.crane@doh.state.nj.us>
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 <R-bugs@biostat.ku.dk>; 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: <tlumley@u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
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: <Pine.A41.4.58.0405191154250.224978@homer06.u.washington.edu>
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" <Jonathan.Swinton@astrazeneca.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@lists.r-project.org>; Fri, 21 May 2004 15:04:16 +0100 (BST)
Received: by ukapzcmsxhub01.ukap.astrazeneca.net with Internet Mail Service (5.5.2653.19)
id <K9H1T31R>; Fri, 21 May 2004 15:04:15 +0100
Message-ID: <FCA5F290CE7FFD42A6F1515497B0F0A20436222F@ukapphresmsx02.ukapd.astrazeneca.net>
From: "Swinton, Jonathan" <Jonathan.Swinton@astrazeneca.com>
To: "'r-bugs@lists.r-project.org'" <r-bugs@stat.math.ethz.ch>
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" <rmh@temple.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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" <rmh@temple.edu>
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: <giles.crane@doh.state.nj.us>
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 <R-bugs@biostat.ku.dk>; 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: <wb@arb-phys.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: wb@arb-phys.uni-dortmund.de
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>,
Douglas Bates <bates@stat.wisc.edu>
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: <Pine.LNX.4.44.0406231309370.23737-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <azzalini@stat.unipd.it>
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 <- (-35<x)
if(k>2 & 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <bates@stat.wisc.edu>
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 <bates@bates4.stat.wisc.edu>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <T65b7b9f9dbac1e08e217d@groexms01.pfizer.com>;
Wed, 5 Nov 2003 09:55:15 -0500
Received: by groexcn04.pfizer.com with Internet Mail Service (5.5.2654.89)
id <WH5Y8JJJ>; Wed, 5 Nov 2003 09:55:15 -0500
Message-ID: <D7A3CFD7825BD6119B880002A58F06C20680AA18@groexmb02.pfizer.com>
From: "Warnes, Gregory R" <gregory_r_warnes@groton.pfizer.com>
To: "'Douglas Bates'" <bates@stat.wisc.edu>, 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: <pbtud@yahoo.com>
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 <R-bugs@biostat.ku.dk>; 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 <rmh@surfer.sbm.temple.edu>
From: "Francis Hsuan" <francis.hsuan@temple.edu> 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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <rmh@surfer.sbm.temple.edu>
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" <francis.hsuan@temple.edu> Add To Address Book
To: <rmh@temple.edu>
Cc: "Francis Hsuan" <francish@temple.edu>
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: <msa@biostat.mgh.harvard.edu>
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 <R-bugs@biostat.ku.dk>; 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: <ligges@amadeus.statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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: <msa@biostat.mgh.harvard.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <msa@biostat.mgh.harvard.edu>
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 <ligges@statistik.uni-dortmund.de>
> 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: <ligges@amadeus.statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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 <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> <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 <ligges@statistik.uni-dortmund.de>
>>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: <tlumley@u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
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: <Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
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: <msa@biostat.mgh.harvard.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <msa@biostat.mgh.harvard.edu>
To: tlumley@u.washington.edu
Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk
In-reply-to: <Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
(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> <Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
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 <tlumley@u.washington.edu>
> 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: <tlumley@u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
To: Marek Ancukiewicz <msa@biostat.mgh.harvard.edu>
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: <Pine.A41.4.58.0404091120270.61772@homer32.u.washington.edu>
References: <20040409172243.B026310476@slim.kubism.ku.dk>
<Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
<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: <p.dalgaard@biostat.ku.dk>
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 <msa@biostat.mgh.harvard.edu>
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>
<Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
<20040409180817.D6C275E197@biostat.mgh.harvard.edu>
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Date: 09 Apr 2004 20:37:23 +0200
In-Reply-To: <20040409180817.D6C275E197@biostat.mgh.harvard.edu>
Message-ID: <x2vfk9q9p8.fsf@biostat.ku.dk>
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 <msa@biostat.mgh.harvard.edu> 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: <msa@biostat.mgh.harvard.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <msa@biostat.mgh.harvard.edu>
To: tlumley@u.washington.edu
Cc: R-bugs@biostat.ku.dk
In-reply-to: <Pine.A41.4.58.0404091120270.61772@homer32.u.washington.edu>
(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>
<Pine.A41.4.58.0404091032330.61772@homer32.u.washington.edu>
<20040409180817.D6C275E197@biostat.mgh.harvard.edu> <Pine.A41.4.58.0404091120270.61772@homer32.u.washington.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 <tlumley@u.washington.edu>
> 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 <fc@maths.uq.edu.au>
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: <fc@maths.uq.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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 <fc@maths.uq.edu.au>
To: r-bugs@biostat.ku.dk
Cc: fc@ebi.ac.uk
Subject: Bug in FEXACT: gave negative key
Message-ID: <Pine.GSO.4.44.0406171954500.20141-100000@socrates.maths.uq.edu.au>
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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 17 Jun 2004 12:25:36 +0200
In-Reply-To: <20040617100047.B13DB1057B@slim.kubism.ku.dk>
Message-ID: <x2r7sexyzj.fsf@biostat.ku.dk>
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: <cornulier@cebc.cnrs.fr>
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 <R-bugs@biostat.ku.dk>; 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" <pauljohn@ku.edu>
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 <r-bugs@biostat.ku.dk>; 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" <pauljohn@ku.edu>
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" <pauljohn@ukans.edu>
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 <r-bugs@biostat.ku.dk>; 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" <pauljohn@ukans.edu>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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: <BE3FDFA0E846D311B264009027887568021F9571@pcexch.dar.csiro.au>
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 <noetzold@medinf.mu-luebeck.de>
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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <noetzold@medinf.mu-luebeck.de>
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: <htang@hpl.hp.com>
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 <R-bugs@biostat.ku.dk>; 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: <Scot@Wilcoxon.Org>
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 <R-bugs@biostat.ku.dk>; 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: <ligges@amadeus.statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@stat.math.ethz.ch>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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 <Scot@wilcoxon.org>
>>>>> 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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 10 Jan 2004 16:37:38 +0100
In-Reply-To: <20040110151249.285AF10456@slim.kubism.ku.dk>
Message-ID: <x2isjj4xx9.fsf@biostat.ku.dk>
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: <Scot@Wilcoxon.Org>
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 <Scot@Wilcoxon.Org>
To: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk
In-Reply-To: <x2isjj4xx9.fsf@biostat.ku.dk>
References: <20040110151249.285AF10456@slim.kubism.ku.dk>
<x2isjj4xx9.fsf@biostat.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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <m13Zrkl-000IW0C@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <R-bugs@r-project.org>; 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 <R-bugs@r-project.org>; 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 <ripley@stats.ox.ac.uk>
X-Sender: ripley@toucan.stats
To: R-bugs@r-project.org
Subject: identify.default ignores any setting of cex.
Message-ID: <Pine.GSO.4.05.10009151011510.14885-100000@toucan.stats>
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
Organization: Fachbereich Statistik, Universitaet Dortmund
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: r-bugs <R-bugs@biostat.ku.dk>
CC: "Brian D. Ripley" <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
To: <ligges@statistik.uni-dortmund.de>
cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Re: identify.default ignores any setting of cex (PR#660)
In-Reply-To: <200104251524.RAA02124@pubhealth.ku.dk>
Message-ID: <Pine.WNT.4.31.0104251852500.300-100000@tern.stats>
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 <plummer@iarc.fr>
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 <r-bugs@biostat.ku.dk>; 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 <m148NHG-000IYiC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Tue, 19 Dec 2000 14:53:55 +0100
Message-ID: <XFMail.001219145601.plummer@iarc.fr>
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 <plummer@iarc.fr>
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 <r-bugs@biostat.ku.dk>; 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 <m149OzA-000IXMC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <R-bugs@biostat.ku.dk>
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 <H.RINNER@TIROL.GV.AT>
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 <r-bugs@biostat.ku.dk>; 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 <m14JHRE-000IWyC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <T0a0b80c8512ecf1400@xms.tirol.gv.at> for <r-bugs@r-project.org>;
Thu, 18 Jan 2001 14:54:33 +0100
Received: by xms.tirol.gv.at with Internet Mail Service (5.5.2650.21)
id <CLGLQ6B7>; Thu, 18 Jan 2001 14:54:33 +0100
Message-ID: <C4D44AB4CB62D311BA6500041202E8862640F8@xms1.tirol.gv.at>
From: RINNER Heinrich <H.RINNER@TIROL.GV.AT>
To: "'r-bugs@r-project.org'" <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 <H.RINNER@TIROL.GV.AT>
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 <tov@ece.cmu.edu>
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 <r-bugs@biostat.ku.dk>; 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 <m14NTW2-000IWyC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <tov@ece.cmu.edu>
Subject: screen can't go back to (split) screen with log="y" plot
Reply-To: Thomas Vogels <tov@ece.cmu.edu>
X-URI: http://www.ece.cmu.edu/~tov
From: Thomas Vogels <tov@ece.cmu.edu>
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
Date: 30 Jan 2001 00:39:41 -0500
Message-ID: <pxsnm1egyq.fsf@infiniti.ece.cmu.edu>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
Sender: <ripley@auk.stats>
To: <tov@ece.cmu.edu>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] screen can't go back to log="y" plot (PR#831)
In-Reply-To: <200101300539.GAA28465@pubhealth.ku.dk>
Message-ID: <Pine.GSO.4.31.0101300725290.17104-100000@auk.stats>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
Cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] screen can't go back to log="y" plot (PR#831)
References: <Pine.GSO.4.31.0101300725290.17104-100000@auk.stats>
Reply-To: Thomas Vogels <tov@ece.cmu.edu>
X-URI: http://www.ece.cmu.edu/~tov
From: Thomas Vogels <tov@ece.cmu.edu>
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: <px7l3bcik6.fsf@infiniti.ece.cmu.edu>
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 <ripley@stats.ox.ac.uk> 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 <tov@ece.cmu.edu>
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 <r-bugs@biostat.ku.dk>; 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 <tov@ece.cmu.edu>
Subject: screen doesn't handle redrawing properly
Reply-To: Thomas Vogels <tov@ece.cmu.edu>
X-URI: http://www.ece.cmu.edu/~tov
From: Thomas Vogels <tov@ece.cmu.edu>
Date: 01 Feb 2001 14:20:52 -0500
Message-ID: <pxitmub46j.fsf@infiniti.ece.cmu.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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" <paul@stat.auckland.ac.nz>
To: <r-core@r-project.org>
Cc: <R-bugs@biostat.ku.dk>
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 <john.maindonald@anu.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <m151H95-000JH8C@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <john.maindonald@anu.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <m15CCch-000JGhC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <r-bugs@biostat.ku.dk>; 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 <m15CFDy-000JJWC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
>>>>> "Paul" == Paul Murrell <paul@stat.auckland.ac.nz> 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 <R-bugs@biostat.ku.dk>
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 <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.
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 <R-bugs@biostat.ku.dk>; 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 <MAILER-DAEMON@pubhealth.ku.dk>
Message-Id: <200107170228.EAA21901@blueberry.kubism.ku.dk>
To: <R-bugs@biostat.ku.dk>
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 -----
<John>
(expanded from: <John>)
<Maindonald>
(expanded from: <Maindonald>)
----- Transcript of session follows -----
... while talking to mail.kubism.ku.dk.:
>>> RCPT To:<maindonald@mail.kubism.ku.dk>
<<< 550 <maindonald@mail.kubism.ku.dk>... User unknown
550 <Maindonald>... User unknown
>>> RCPT To:<john@mail.kubism.ku.dk>
<<< 550 <john@mail.kubism.ku.dk>... User unknown
550 <John>... 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 <john@mail.kubism.ku.dk>... 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 <maindonald@mail.kubism.ku.dk>... 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: <R-bugs@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>
To: paul@stat.auckland.ac.nz
Subject: Re: legend() with xpd=T; omission of initial plot character (PR#943)
CC: John Maindonald <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.
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 <pd@pubhealth.ku.dk>
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 <r-bugs@biostat.ku.dk>; 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 <m15FBxI-000JJjC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <pd@pubhealth.ku.dk>
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" <paul@stat.auckland.ac.nz>
To: <pd@pubhealth.ku.dk>, <r-devel@stat.math.ethz.ch>
Cc: <R-bugs@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
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 <r-bugs@biostat.ku.dk>; 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 <m15UWoD-000JIvC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <p.dalgaard@biostat.ku.dk>
Date: 08 Aug 2001 19:08:01 +0200
Message-ID: <x2snf2zdhq.fsf@blueberry.kubism.ku.dk>
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 <ihaka@stat.auckland.ac.nz>
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 <kjetilh@umsanet.edu.bo>
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 <r-bugs@biostat.ku.dk>; 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 <m15xCZT-000JIvC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <kjetilh@umsanet.edu.bo>
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 <r-bugs@biostat.ku.dk>; 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 <m16YqdA-000IbFC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <kjetilh@umsanet.edu.bo>
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 <rolf@maths.uwa.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <m161PcE-000JLZC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Wed, 7 Nov 2001 18:07:23 +0800 (WST)
From: Rolf Turner <rolf@maths.uwa.edu.au>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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" <merithew@ccmr.cornell.edu>
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 <r-bugs@biostat.ku.dk>; 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 <m17HmaZ-000IYKC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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" <merithew@ccmr.cornell.edu>
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: <Pine.LNX.4.44.0206110918130.12431-100000@magic.ccmr.cornell.edu>
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
<p.murrell@auckland.ac.nz> 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <p.murrell@auckland.ac.nz>
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
> <p.murrell@auckland.ac.nz> 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)-><something> 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 <r-bugs@biostat.ku.dk>; 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 <m17HwxI-000IXcC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <R-bugs@biostat.ku.dk>; 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 <Timur.Elzhov@jinr.ru>
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 <r-bugs@biostat.ku.dk>; 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 <m17iEH0-000IWqC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Fri, 23 Aug 2002 17:22:17 +0400
Date: Fri, 23 Aug 2002 17:22:15 +0400
From: Timur Elzhov <Timur.Elzhov@jinr.ru>
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 <etv@pcf004.jinr.ru>
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 <R-bugs@biostat.ku.dk>; 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 <jarioksa@sun3.oulu.fi>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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<E
Subject: Wandering usr values in par(no.readonly=TRUW)
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1801894504P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 12 Nov 2002 13:50:44 +0200
From: Jari Oksanen <jarioksa@sun3.oulu.fi>
--==_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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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: <mschwartz@medanalytics.com>, <jarioksa@sun3.oulu.fi>
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 <maechler@stat.math.ethz.ch>
>>>>> "Marc" == Marc Schwartz <mschwartz@medanalytics.com>
>>>>> 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> <more good analysis>
Thank you Marc!
Martin Maechler <maechler@stat.math.ethz.ch> 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 <R-bugs@biostat.ku.dk>; 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: <mschwartz@medanalytics.com>
From: "Marc Schwartz" <mschwartz@medanalytics.com>
To: <maechler@stat.math.ethz.ch>, <r-devel@stat.math.ethz.ch>
Cc: <R-bugs@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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: <mschwartz@medanalytics.com>
From: "Marc Schwartz" <mschwartz@medanalytics.com>
To: <maechler@stat.math.ethz.ch>, <r-devel@stat.math.ethz.ch>
Cc: <R-bugs@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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?= <gb@stat.umu.se>
To: jerome@hivnet.ubc.ca
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] plot() with type="s" and lty=2 (PR#2630)
In-Reply-To: <200303122236.h2CMa0n9021101@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.44.0303130830020.2139-100000@tal.stat.umu.se>
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 <R-bugs@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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: <dgrove@fhcrc.org>
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 <R-bugs@biostat.ku.dk>; 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: <jonathan_lees@unc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>
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: <jonathan_lees@unc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <jonathan_lees@unc.edu>
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 <R-bugs@biostat.ku.dk>
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: <kleiweg@let.rug.nl>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <kleiweg@let.rug.nl>
X-X-Sender: peter@kleigh.nl
To: jonathan_lees@unc.edu
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Re: postscript image problem (PR#6763)
In-Reply-To: <20040428120725.D150B10481@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0404281428020.2826-100000@kleigh.nl>
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 <R-bugs@biostat.ku.dk>
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" <gregory_r_warnes@groton.pfizer.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <T6a7c574ecbac1e08e21c8@groexms01.pfizer.com> for <r-bugs@r-project.org>;
Tue, 29 Jun 2004 10:23:49 -0400
Received: by groexcn04.pfizer.com with Internet Mail Service (5.5.2654.89)
id <M54GYC5Z>; Tue, 29 Jun 2004 10:23:49 -0400
Message-ID: <D7A3CFD7825BD6119B880002A58F06C20C521696@groexmb02.pfizer.com>
From: "Warnes, Gregory R" <gregory_r_warnes@groton.pfizer.com>
To: "'R-Bugs (E-mail)'" <r-bugs@r-project.org>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
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: <Pine.GSO.4.44.0206191008210.21134-100000@auk.stats>
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 <stdio.h> 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 <R-bugs@biostat.ku.dk>; 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 <accot@free.fr>
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 <ripley@stats.ox.ac.uk>
CC: R-bugs@biostat.ku.dk
Subject: Re: Maybe a problem in binary read/write (PR#1688)
References: <Pine.GSO.4.44.0206191008210.21134-100000@auk.stats>
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 <stdio.h> 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)
## <NOTE>
## 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 <ndir.h> 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 <sys/types.h>
+# endif
+# ifdef HAVE_SYS_STAT_H
+# include <sys/stat.h>
+# endif
+# else /* Macintosh */
+# include <types.h>
+# ifndef __MRC__
+# include <stat.h>
+# else
+# include <mpw_stat.h>
+# endif
+# endif /* Macintosh */
+#endif /* HAVE_STAT */
+
+#ifdef HAVE_ERRNO_H
+# include <errno.h>
+#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 <R-bugs@biostat.ku.dk>; 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: <ripley@gannet.stats>
To: Johnny Accot <accot@free.fr>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: Maybe a problem in binary read/write (PR#1688)
In-Reply-To: <3D121989.509@free.fr>
Message-ID: <Pine.LNX.4.31.0206201942270.9210-100000@gannet.stats>
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 <stdio.h> 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 <kleiweg@let.rug.nl>
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 <r-bugs@biostat.ku.dk>; 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 <m16H2xF-000IXfC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <kleiweg@let.rug.nl>
X-X-Sender: <kleiweg@kleigh.nl>
To: <r-bugs@r-project.org>
Subject: configure: sed: Function s%@PDFLATEX@%/usr/local/bin/pdflatex%g
cannot be parsed.
Message-ID: <Pine.LNX.4.33.0112201304160.476-100000@kleigh.nl>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: <ripley@gannet.stats>
To: <gm81640@development.nssmb.com>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268)
In-Reply-To: <200201170528.GAA21628@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0201170827260.2465-100000@gannet.stats>
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 <p.dalgaard@biostat.ku.dk>
Date: 17 Jan 2002 11:45:33 +0100
In-Reply-To: <200201170837.JAA23228@pubhealth.ku.dk>
Message-ID: <x2g055cl2q.fsf@blueberry.kubism.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <geordon.marchak@nssmb.com>
X-X-Sender: <gm81640@lx22z001.nssmb.com>
To: Prof Brian Ripley <ripley@stats.ox.ac.uk>
Cc: <geordon.marchak@nssmb.com>, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Solaris 2.6 Compile (PR#1268)
In-Reply-To: <Pine.LNX.4.31.0201170827260.2465-100000@gannet.stats>
Message-ID: <Pine.LNX.4.33.0201211721260.8617-100000@lx22z001.nssmb.com>
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 <ripley@stats.ox.ac.uk>
> 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: <ripley@gannet.stats>
To: <brendan_mcmahon@prusec.com>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Installation problem : SunOS (PR#1291)
In-Reply-To: <200201311700.SAA07558@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0201311742120.12426-100000@gannet.stats>
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 <kleiweg@let.rug.nl>
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 <r-bugs@biostat.ku.dk>; 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 <m172YpF-000IYIC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <kleiweg@let.rug.nl>
X-X-Sender: <kleiweg@kleigh.nl>
To: <r-bugs@r-project.org>
Subject: configure script fails on comment in tkConfig.sh
Message-ID: <Pine.LNX.4.33.0204301632320.29798-100000@kleigh.nl>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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: <ripley@gannet.stats>
To: <dhouston@bio.ri.ccf.org>
cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>
Subject: Re: make install fails - index.html not found (PR#1658)
In-Reply-To: <200206112014.WAA06199@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0206112136170.23760-100000@gannet.stats>
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 <r-bugs@biostat.ku.dk>; 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 <m17JMr0-000IWsC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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: <Pine.SOL.3.96.1020615185530.24629A-100000@bitter.mit.edu>
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 <R-bugs@biostat.ku.dk>; 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 <hornik@ci.tuwien.ac.at>
>>>>> 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" <gsivrao@hotmail.com>
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 <r-bugs@biostat.ku.dk>; 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 <m17XSRV-000IWqC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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" <gsivrao@hotmail.com>
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: <F9NUyKhy7uQP5F1iVbC00014ae6@hotmail.com>
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 = <unknown>
Serial = <unknown>
Users = <unknown>
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 <thoar@cgd.ucar.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@R-project.org>; 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 <r-bugs@R-project.org>; 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 <r-bugs@R-project.org>; 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 <thoar@cgd.ucar.edu>
X-Sender: <thoar@sunray2>
Reply-To: Tim Hoar <thoar@ucar.edu>
To: <r-bugs@R-project.org>
Subject: building R 1.7.0 under RH7.3
Message-ID: <Pine.GSO.4.30.0304211257440.23064-200000@sunray2>
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: <Pine.GSO.4.30.0304211316160.23064@sunray2>
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 <R-bugs@biostat.ku.dk>; 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" <ok@cs.otago.ac.nz>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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" <ok@cs.otago.ac.nz>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: ok@cs.otago.ac.nz
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] 1.7.1 make check fails (PR#3282)
In-Reply-To: <200306180532.h5I5W5JH010775@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.44.0306180703060.27947-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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, <rdfile>
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, <rdfile>
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 <bug-make@gnu.org>.
]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 <p.dalgaard@biostat.ku.dk>
Date: 16 Jul 2003 00:31:24 +0200
In-Reply-To: <200307151656.h6FGuOJH000875@pubhealth.ku.dk>
Message-ID: <x2ptkb8ls3.fsf@biostat.ku.dk>
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, <rdfile>
> 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: <D3A3AA459175A44CB5326F26DA7A189C0145FA3D@orsmsx405.jf.intel.com>
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" <michael.t.klinglesmith@intel.com>
To: "Peter Dalgaard BSA" <p.dalgaard@biostat.ku.dk>
Cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>
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,
<rdfile>
> 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 <p.dalgaard@biostat.ku.dk>
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: <x2ptkb8ls3.fsf@biostat.ku.dk>
References: <200307151656.h6FGuOJH000875@pubhealth.ku.dk>
<x2ptkb8ls3.fsf@biostat.ku.dk>
X-Mailer: VM 7.16 under Emacs 21.2.1
Reply-To: Kurt.Hornik@wu-wien.ac.at
From: Kurt Hornik <hornik@ci.tuwien.ac.at>
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, <rdfile>
>> 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 <maechler@stat.math.ethz.ch>
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 <p.dalgaard@biostat.ku.dk>, 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>
<x2ptkb8ls3.fsf@biostat.ku.dk>
<16148.58458.680003.755101@mithrandir.hornik.net>
X-Mailer: VM 7.15 under Emacs 21.3.2
Reply-To: Martin Maechler <maechler@stat.math.ethz.ch>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
>>>>> "KH" == Kurt Hornik <hornik@ci.tuwien.ac.at>
>>>>> 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, <rdfile> 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 <Kurt.Hornik@wu-wien.ac.at>
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 <R-bugs@biostat.ku.dk>; 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 <saikat@stat.wisc.edu>
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: <CC5C1771-F027-11D7-8345-0003931A3C9E@stat.wisc.edu>
References: <200309250926.h8P9QG0P023078@pubhealth.ku.dk>
<CC5C1771-F027-11D7-8345-0003931A3C9E@stat.wisc.edu>
X-Mailer: VM 7.17 under Emacs 21.2.1
Reply-To: Kurt.Hornik@wu-wien.ac.at
From: Kurt Hornik <Kurt.Hornik@wu-wien.ac.at>
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 <wolfram@fischer-zim.ch>
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: <mailnull@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.R-project.org>; 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 <r-bugs@lists.R-project.org>; 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 <wolfram@fischer-zim.ch>
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: <a0108661@unet.univie.ac.at>
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 <R-bugs@biostat.ku.dk>; 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: <joachim.geiger@ipp.mpg.de>
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 <R-bugs@biostat.ku.dk>; 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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 20 Apr 2004 12:20:38 +0200
In-Reply-To: <20040420095209.EE86810478@slim.kubism.ku.dk>
Message-ID: <x2pta354sp.fsf@biostat.ku.dk>
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: <mc@austrian-mint.at>
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 <R-bugs@biostat.ku.dk>; 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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 07 May 2004 16:49:58 +0200
In-Reply-To: <20040507144536.CFAF5F0E7@slim.kubism.ku.dk>
Message-ID: <x2oep0mgvd.fsf@biostat.ku.dk>
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: <garvin@cs.rice.edu>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: garvin@cs.rice.edu
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
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: <Pine.LNX.4.44.0405220931240.4289-100000@gannet.stats>
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: <garvin@rice.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <garvin@rice.edu>
X-X-Sender: garvin@hpc3.cs.rice.edu
To: Prof Brian Ripley <ripley@stats.ox.ac.uk>
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: (PR#6896) Re: [Rd] R with shared library support: 'make check'
fails with unresolved symbol (PR#6896)
In-Reply-To: <Pine.LNX.4.44.0405220931240.4289-100000@gannet.stats>
Message-ID: <Pine.LNX.4.44.0405240951060.15213-100000@hpc3.cs.rice.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=-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 <R-bugs@biostat.ku.dk>; 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 <p.dalgaard@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia.math.ethz.ch>; 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 <m12HFNP-000ZSxC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <p.dalgaard@biostat.ku.dk>
Date: 06 Feb 2000 01:18:50 +0100
Message-ID: <x2900zyyhh.fsf@blueberry.kubism.ku.dk>
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 <maechler@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@stat.math.ethz.ch>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch> 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" <gregory_r_warnes@groton.pfizer.com>
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 <r-bugs@biostat.ku.dk>; 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 <m15aSrf-000JIlC@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <T559305f66fac1e08e203f@groexms01.pfizer.com> for <r-bugs@r-project.org>;
Fri, 24 Aug 2001 22:07:41 -0400
Received: by groexcncr05.pfizer.com with Internet Mail Service (5.5.2650.21)
id <R3ZPXZDF>; Fri, 24 Aug 2001 22:07:41 -0400
Message-ID: <5429125E11E4D411AF7300805FE603A8014CED55@groexmbcr02.pfizer.com>
From: "Warnes, Gregory R" <gregory_r_warnes@groton.pfizer.com>
To: "'r-bugs@r-project.org'" <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 <p.dalgaard@biostat.ku.dk>
Date: 25 Aug 2001 15:57:09 +0200
In-Reply-To: <200108250208.EAA03656@pubhealth.ku.dk>
Message-ID: <x23d6gmedm.fsf@blueberry.kubism.ku.dk>
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 <jmc@research.bell-labs.com>
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 <jmc@research.bell-labs.com>
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 <p.dalgaard@biostat.ku.dk>
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> <x23d6gmedm.fsf@blueberry.kubism.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 <p.dalgaard@biostat.ku.dk>
Date: 27 Aug 2001 15:35:17 +0200
In-Reply-To: <200108271245.OAA16874@pubhealth.ku.dk>
Message-ID: <x27kvpwrqi.fsf@blueberry.kubism.ku.dk>
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 <vograno@arbitrade.com>
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 <r-bugs@biostat.ku.dk>; 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 <m169Y6y-000IWoC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Thu, 29 Nov 2001 14:48:41 -0600 (CST)
Received: by mnmail.arbitrade.com with Internet Mail Service (5.5.2653.19)
id <XXDQF55J>; Thu, 29 Nov 2001 14:48:41 -0600
Message-ID: <AFD78192EC49D311BFAE00902798AB8F23D65A@jupiter.sc.arbitrade.com>
From: Vadim Ogranovich <vograno@arbitrade.com>
To: "'r-bugs@r-project.org'" <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 <r-bugs@biostat.ku.dk>; 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 <m16MUb9-000IZ3C@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; Fri, 4 Jan 2002 13:34:35 GMT
Received: from arrow.dur.ac.uk by euclid id <g04DYYG10013@euclid>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: <ripley@gannet.stats>
To: <J.C.Rougier@durham.ac.uk>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Problem with "missing" in "local" (PR#1241)
In-Reply-To: <200201041341.OAA07672@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0201041347390.8133-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <g04EbSG15752@euclid>; 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 <J.C.Rougier@durham.ac.uk>
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 <ripley@stats.ox.ac.uk>
CC: R-bugs@biostat.ku.dk
Subject: Re: [Rd] Problem with "missing" in "local" (PR#1241)
References: <Pine.LNX.4.31.0201041347390.8133-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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, <<whatever>>) # where env is an environment
and
attr( env, <<whatever>>)_ 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Thu, 16 May 2002 16:47:40 +1000 (EST)
Received: by molly.tas.csiro.au with Internet Mail Service (5.5.2655.55)
id <KSPS0LFF>; Thu, 16 May 2002 16:47:30 +1000
Message-ID: <A8877251964B294BAB5BA1FC58B43FED26DC18@molly.tas.csiro.au>
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)
<environment: package:tcltk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <jmc@research.bell-labs.com>
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" <cberry@tajo.ucsd.edu>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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" <cberry@tajo.ucsd.edu>
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 <p.dalgaard@biostat.ku.dk>
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: <x27ky9o75d.fsf@blueberry.kubism.ku.dk>
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" <cberry@tajo.ucsd.edu>
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
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: <x27ky9o75d.fsf@blueberry.kubism.ku.dk>
Message-ID: <Pine.GSO.4.05.10106181348090.12737-100000@tajo.ucsd.edu>
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 <luke@nokomis.stat.umn.edu>
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 <R-bugs@biostat.ku.dk>; 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 <luke@nokomis.stat.umn.edu>
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" <jwe@bevo.che.wisc.edu>
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 <R-bugs@biostat.ku.dk>; 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" <jwe@bevo.che.wisc.edu>
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 <luke@nokomis.stat.umn.edu>
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 <luke@nokomis.stat.umn.edu> 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 <berwin@maths.uwa.edu.au>
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 <r-bugs@biostat.ku.dk>; 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 <m17c0A8-000IX5C@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <berwin@maths.uwa.edu.au>
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 <wolfram@fischer-zim.ch>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <wolfram@fischer-zim.ch>
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 = <undef>;
- `stty` after: speed 38400 baud; line = 0; lnext = <undef>; 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 <p.dalgaard@biostat.ku.dk>
Date: 04 Nov 2002 10:58:53 +0100
In-Reply-To: <200211040919.KAA18590@pubhealth.ku.dk>
Message-ID: <x2y989bqqq.fsf@biostat.ku.dk>
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 = <undef>;
>
> - `stty` after: speed 38400 baud; line = 0; lnext = <undef>; 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 <L.T.Kell@cefas.co.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <T647db2241ac0a8fd1f06c@terminal1.cefas.co.uk> for <r-bugs@r-project.org>;
Fri, 5 Sep 2003 10:25:56 +0100
Received: by LOWEXPRESS2.corp.cefas.co.uk with Internet Mail Service (5.5.2653.19)
id <Q8Q2B4LM>; Fri, 5 Sep 2003 10:24:05 +0100
Message-ID: <8FC44BEDB265D711972400508B6D77960482E4@LOWEXPRESS1.corp.cefas.co.uk>
From: Laurence Kell FM CEFAS <L.T.Kell@cefas.co.uk>
To: "'r-bugs@r-project.org'" <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
<<Laurence Kell (E-mail).vcf>>
------_=_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 <R-bugs@biostat.ku.dk>; 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 <duncan@research.bell-labs.com>
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 <duncan@jessie.research.bell-labs.com>,
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
>
> <<Laurence Kell (E-mail).vcf>>
>
> ------_=_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" <eriehl@email.unc.edu>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Wed, 8 Oct 2003 14:30:58 -0400 (EDT)
Date: Wed, 8 Oct 2003 14:30:57 -0400 (EDT)
From: "Eric R. Riehl" <eriehl@email.unc.edu>
X-X-Sender: eriehl@testbox
To: r-bugs@biostat.ku.dk
Subject: Memmory Bugs
Message-ID: <Pine.LNX.4.44.0310081429010.31587-200000@testbox>
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: <Pine.LNX.4.44.0310081430570.31587@testbox>
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 <p.dalgaard@biostat.ku.dk>
Date: 08 Oct 2003 22:09:57 +0200
In-Reply-To: <200310081831.h98IVf0P021130@pubhealth.ku.dk>
Message-ID: <x2llrvjxt6.fsf@biostat.ku.dk>
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: <Pine.LNX.4.44.0310081430570.31587@testbox>
> 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 <mjw@celos.net>
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: <mjw@celos.net>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <mjw@celos.net>
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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: mjw@celos.net
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Regular expressions & large strings (PR#6617)
In-Reply-To: <20040227111915.018731042E@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0402281126560.17286-100000@gannet.stats>
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: <mjw@celos.net>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <mjw@celos.net>
To: Prof Brian Ripley <ripley@stats.ox.ac.uk>
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> <Pine.LNX.4.44.0402281126560.17286-100000@gannet.stats>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0402281126560.17286-100000@gannet.stats>
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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: Mark White <mjw@celos.net>
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Regular expressions & large strings (PR#6617)
In-Reply-To: <20040228151418.GA341@celos.net>
Message-ID: <Pine.LNX.4.44.0402281510180.17514-100000@gannet.stats>
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 = <long polynom>)
From: Martin Maechler <maechler@stat.math.ethz.ch>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@stat.math.ethz.ch>; 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 <maechler@stat.math.ethz.ch>
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 <coursol@cristal.math.u-psud.fr>
Subject: Bug in parse(text = <long polynom>)
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 <maechler@stat.math.ethz.ch>
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 <coursol@cristal.math.u-psud.fr>
>>>>> on Thu, 24 Jun 2004 15:22:37 +0200 (CEST) writes:
Jean> I was exploring the polynom library with students:
<and found a segmentation fault from parsing a long expression>
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: <p.dalgaard@biostat.ku.dk>
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 = <long polynom>) (PR#7022)
References: <20040625071940.9096610871@slim.kubism.ku.dk>
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Date: 25 Jun 2004 09:32:48 +0200
In-Reply-To: <20040625071940.9096610871@slim.kubism.ku.dk>
Message-ID: <x2smckrt27.fsf@biostat.ku.dk>
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: <ripley@stats.ox.ac.uk>
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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Cc: maechler@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>,
<r-devel@stat.math.ethz.ch>
Subject: Re: [Rd] Bug in parse(text = <long polynom>) (PR#7022)
In-Reply-To: <x2smckrt27.fsf@biostat.ku.dk>
Message-ID: <Pine.LNX.4.44.0406250849040.32191-100000@gannet.stats>
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: <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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 <p.dalgaard@biostat.ku.dk>
Cc: R-bugs@biostat.ku.dk
Subject: Re: [Rd] Bug in parse(text = <long polynom>) (PR#7022)
In-Reply-To: <x2smckrt27.fsf@biostat.ku.dk>
References: <20040625071940.9096610871@slim.kubism.ku.dk>
<x2smckrt27.fsf@biostat.ku.dk>
X-Mailer: VM 7.18 under Emacs 21.3.1
Reply-To: Martin Maechler <maechler@stat.math.ethz.ch>
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: <maechler@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 = <long polynom>) (PR#7022)
In-Reply-To: <16603.57351.582179.466625@gargle.gargle.HOWL>
References: <20040625071940.9096610871@slim.kubism.ku.dk>
<x2smckrt27.fsf@biostat.ku.dk>
<16603.57351.582179.466625@gargle.gargle.HOWL>
X-Mailer: VM 7.18 under Emacs 21.3.1
Reply-To: Martin Maechler <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
>>>>> on Fri, 25 Jun 2004 10:19:19 +0200 writes:
>>>>> "PD" == Peter Dalgaard <p.dalgaard@biostat.ku.dk>
>>>>> 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: <j.j.goeman@lumc.nl>
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 <R-bugs@biostat.ku.dk>; 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: <dmurdoch@pair.com>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <dmurdoch@pair.com>
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: <jlvvd01pppcmojgp0b1cob336deepfg1u1@4ax.com>
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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 28 Jun 2004 13:52:05 +0200
In-Reply-To: <20040628091228.B04B8EAD6@slim.kubism.ku.dk>
Message-ID: <x2d63jdhne.fsf@biostat.ku.dk>
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: <dvanbrunt@well-wired.com>
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 <R-bugs@biostat.ku.dk>; 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: <ocd@well-wired.com>
==> 6903.followup.1 <==
From stefano.iacus@unimi.it Fri May 21 19:47:13 2004
Return-Path: <stefano.iacus@unimi.it>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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: <E28579DF-AB4E-11D8-8DA0-000A95C87F66@unimi.it>
Content-Transfer-Encoding: quoted-printable
Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch
From: stefano iacus <stefano.iacus@unimi.it>
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: <ocd@well-wired.com>
>
> ______________________________________________
> 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: <murray.pung@studentmail.newcastle.edu.au>
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 <R-bugs@biostat.ku.dk>; 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: <jago@mclink.it>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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: <F8E3CCBE-B954-11D8-B1DD-000A95C87F66@mclink.it>
Content-Transfer-Encoding: 7bit
Cc: R-bugs@biostat.ku.dk, r-devel@stat.math.ethz.ch
From: stefano iacus <jago@mclink.it>
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: <jerome.mutterer@ibmp-ulp.u-strasbg.fr>
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 <R-bugs@biostat.ku.dk>; 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: <deejemon@eudoramail.com>
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 <R-bugs@biostat.ku.dk>; 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: <weigand.stephen@charter.net>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
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: <Pine.LNX.4.44.0407030634420.32334-100000@gannet.stats>
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: <weigand.stephen@charter.net>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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: <Pine.LNX.4.44.0407030634420.32334-100000@gannet.stats>
References: <Pine.LNX.4.44.0407030634420.32334-100000@gannet.stats>
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" <weigand.stephen@charter.net>
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 <R-bugs@biostat.ku.dk>; 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 <pgilbert@bank-banque-canada.ca>
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 <r-bugs@biostat.ku.dk>; 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 <pgilbert@bank-banque-canada.ca>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: R-bugs <r-bugs@biostat.ku.dk>
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<<insert bug report here>>\\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 <r-bugs@biostat.ku.dk>; 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 <m16DVIu-000IheC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <a215020@onyx.fmr.com>
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 <R-bugs@biostat.ku.dk>; 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 <pgilbert@bank-banque-canada.ca>
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 <gonin@genethon.fr>
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 <r-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; Thu, 2 May 2002 09:29:24 +0200 (MET DST)
Mime-Version: 1.0
X-Sender: gonin@diogene.genethon.fr
Message-Id: <a05100300b8f698c569f1@[192.168.100.154]>
Date: Thu, 2 May 2002 09:29:07 +0200
To: R-bugs@biostat.ku.dk
From: Patrick Gonin <gonin@genethon.fr>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@gannet.stats>
To: <gonin@genethon.fr>
cc: <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] R-GNOME (PR#1503)
In-Reply-To: <200205020730.JAA00989@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.31.0205021016060.3970-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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: <XFMail.20020502123210.plummer@iarc.fr>
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 <plummer@iarc.fr>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <duncan@research.bell-labs.com>
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 <duncan@jessie.research.bell-labs.com>,
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 <faheem@email.unc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <faheem@email.unc.edu>
X-X-Sender: faheem@Chrestomanci
To: Duncan Temple Lang <duncan@research.bell-labs.com>
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)
In-Reply-To: <20030316141002.A26681@jessie.research.bell-labs.com>
Message-ID: <Pine.LNX.4.44.0303161534570.16046-100000@Chrestomanci>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Faheem Mitha <faheem@email.unc.edu>
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 <hornik@ci.tuwien.ac.at>
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 <R-bugs@biostat.ku.dk>; 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 <hornik@ci.tuwien.ac.at>
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 <R-bugs@biostat.ku.dk>; 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 <ggrothendieck@volcanomail.com>
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 <r-bugs@biostat.ku.dk>; 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 <ggrothendieck@volcanomail.com>
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 <ihaka@stat.auckland.ac.nz>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <R-bugs@R-project.org>; 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 <ihaka@stat.auckland.ac.nz>
Subject: Re: [Rd] another dump/source problem?
In-reply-to: <Pine.LNX.4.44.0309301928430.1170-100000@kleigh.nl>
To: Peter Kleiweg <kleiweg@let.rug.nl>
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: <Pine.LNX.4.44.0309301928430.1170-100000@kleigh.nl>
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 <p.dalgaard@biostat.ku.dk>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia.math.ethz.ch>; 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" <Jonathan.Swinton@astrazeneca.com>,
r-bugs@stat.math.ethz.ch
Subject: Re: [R] Unexpected behaviour of identical
References: <FCA5F290CE7FFD42A6F1515497B0F0A204362194@ukapphresmsx02.ukapd.astrazeneca.net>
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Date: 20 Apr 2004 13:38:49 +0200
In-Reply-To: <FCA5F290CE7FFD42A6F1515497B0F0A204362194@ukapphresmsx02.ukapd.astrazeneca.net>
Message-ID: <x2hdve6fqu.fsf@biostat.ku.dk>
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" <Jonathan.Swinton@astrazeneca.com> 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: <ripley@stats.ox.ac.uk>
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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: p.dalgaard@biostat.ku.dk
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Re: [R] Unexpected behaviour of identical (PR#6799)
In-Reply-To: <20040420114244.86AF4104BA@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0404201249140.11664-100000@gannet.stats>
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" <Jonathan.Swinton@astrazeneca.com> 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: <p.dalgaard@biostat.ku.dk>
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 <ripley@stats.ox.ac.uk>
Cc: p.dalgaard@biostat.ku.dk, r-devel@stat.math.ethz.ch,
<R-bugs@biostat.ku.dk>
Subject: Re: [Rd] Re: [R] Unexpected behaviour of identical (PR#6799)
References: <Pine.LNX.4.44.0404201249140.11664-100000@gannet.stats>
From: Peter Dalgaard <p.dalgaard@biostat.ku.dk>
Date: 20 Apr 2004 15:28:46 +0200
In-Reply-To: <Pine.LNX.4.44.0404201249140.11664-100000@gannet.stats>
Message-ID: <x2y8oq4w35.fsf@biostat.ku.dk>
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 <ripley@stats.ox.ac.uk> 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 <R-bugs@biostat.ku.dk>; 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 <p.dalgaard@biostat.ku.dk>
Date: 01 Aug 2002 19:26:34 +0200
In-Reply-To: <200208011702.TAA28218@pubhealth.ku.dk>
Message-ID: <x2ptx232yd.fsf@biostat.ku.dk>
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 <P7TL2JNV>; Thu, 1 Aug 2002 10:53:32 -0700
Message-ID: <BBAF0DEC119BD41193C100B0D0788DFE1D234B@GENOME>
From: Yi-Xiong Zhou <yzhou@arcturusag.com>
To: "'Peter Dalgaard BSA'" <p.dalgaard@biostat.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
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)
In-Reply-To: <200208011702.TAA28218@pubhealth.ku.dk>
Message-ID: <Pine.A41.4.44.0208011232100.18384-100000@homer26.u.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 1 Aug 2002 yzhou@arcturusag.com wrote:
<snip>
> 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
To: Yi-Xiong Zhou <yzhou@arcturusag.com>
cc: "'Peter Dalgaard BSA'" <p.dalgaard@biostat.ku.dk>,
<r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>
Subject: RE: update() can not find objects (PR#1861)
In-Reply-To: <BBAF0DEC119BD41193C100B0D0788DFE1D234B@GENOME>
Message-ID: <Pine.A41.4.44.0208011405170.18384-100000@homer26.u.washington.edu>
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 <P7TL2JPY>; Thu, 1 Aug 2002 14:20:22 -0700
Message-ID: <BBAF0DEC119BD41193C100B0D0788DFE1D234C@GENOME>
From: Yi-Xiong Zhou <yzhou@arcturusag.com>
To: "'Thomas Lumley'" <tlumley@u.washington.edu>
Cc: "'Peter Dalgaard BSA'" <p.dalgaard@biostat.ku.dk>,
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 <jerome@hivnet.ubc.ca>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <jerome@hivnet.ubc.ca>
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 <p.dalgaard@biostat.ku.dk>
Date: 07 Aug 2003 10:13:24 +0200
In-Reply-To: <200308062241.h76MfoJH002132@pubhealth.ku.dk>
Message-ID: <x2znilx4uz.fsf@biostat.ku.dk>
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 <jerome@hivnet.ubc.ca>
Organization: BC Centre for Excellence in HIV/AIDS
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
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> <x2znilx4uz.fsf@biostat.ku.dk>
In-Reply-To: <x2znilx4uz.fsf@biostat.ku.dk>
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) <environment: R_GlobalEnv> for the call
model.frame(formula[-3],data=data,subset=subset) ;
(2) <environment: 0x883d288> (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 <tov@ece.cmu.edu>
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 <r-bugs@biostat.ku.dk>; 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 <m14So7r-000J2mC@franz.stat.wisc.edu> (Debian Smail3.2.0.102)
for <r-bugs@r-project.org>; 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 <tov@ece.cmu.edu>
Subject: X11 device doesn't handle destroy events correcly
Reply-To: Thomas Vogels <tov@ece.cmu.edu>
X-URI: http://www.ece.cmu.edu/~tov
From: Thomas Vogels <tov@ece.cmu.edu>
Date: 13 Feb 2001 17:40:46 -0500
Message-ID: <px3ddi6wb5.fsf@infiniti.ece.cmu.edu>
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 <p.dalgaard@pubhealth.ku.dk>
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: <x2elx2yvg3.fsf@blueberry.kubism.ku.dk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <duncan@research.bell-labs.com>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Fri, 7 Dec 2001 12:43:25 +0100 (CET)
Date: Fri, 7 Dec 2001 12:43:25 +0100 (CET)
X-X-Sender: <mike@localhost.localdomain>
To: <r-bugs@biostat.ku.dk>
Subject: bug PR#1020
Message-ID: <Pine.LNX.4.33L2.0112071238100.3318-100000@localhost.localdomain>
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 <edd@debian.org>
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 <r-bugs@biostat.ku.dk>; 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 <m15kIKZ-000JJ6C@franz.stat.wisc.edu> (Debian Smail3.2.0.111)
for <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <edd@debian.org>
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 <gonin@genethon.fr>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; Tue, 15 Jan 2002 13:25:20 +0100 (MET)
Mime-Version: 1.0
X-Sender: gonin@sansgene.genethon.fr
Message-Id: <a05100300ba4b0138cb3c@[192.168.100.154]>
Date: Wed, 15 Jan 2003 13:25:17 +0100
To: r-bugs@biostat.ku.dk
From: Patrick Gonin <gonin@genethon.fr>
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 <pgilbert@bank-banque-canada.ca>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <pgilbert@bank-banque-canada.ca>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: R-bugs <R-bugs@biostat.ku.dk>
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 <wtautz@math.uwaterloo.ca>
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 <r-bugs@biostat.ku.dk>; 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 <wtautz@math.uwaterloo.ca>
Reply-To: Walter Tautz <wtautz@math.uwaterloo.ca>
To: r-bugs@biostat.ku.dk
cc: Walter Tautz <wtautz@math.uwaterloo.ca>
Subject: compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a)
Message-ID: <Pine.SOL.3.96.1020122095845.3015H-100000@mfcf.math.uwaterloo.ca>
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 <p.dalgaard@biostat.ku.dk>
Date: 22 Jan 2002 16:27:45 +0100
In-Reply-To: <200201221505.QAA20274@pubhealth.ku.dk>
Message-ID: <x2elki4d8u.fsf@blueberry.kubism.ku.dk>
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 <wtautz@math.uwaterloo.ca>
Reply-To: Walter Tautz <wtautz@math.uwaterloo.ca>
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
cc: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk,
Walter Tautz <wtautz@math.uwaterloo.ca>
Subject: Re: [Rd] compile problem with bessel_i.c on IRIX64 flexor 6.5 10100655 IP35 (uname -a) (PR#1275)
In-Reply-To: <x2elki4d8u.fsf@blueberry.kubism.ku.dk>
Message-ID: <Pine.SOL.3.96.1020122103116.3015L-100000@mfcf.math.uwaterloo.ca>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
To: lio@hpss1.ccs.ornl.gov
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289)
In-Reply-To: <200201301310.OAA19034@pubhealth.ku.dk>
Message-ID: <Pine.A41.4.44.0201300827470.74956-100000@homer40.u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <lio@hpss1.ccs.ornl.gov>
To: Thomas Lumley <tlumley@u.washington.edu>
cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>,
Dan Million <lio@hpss1.ccs.ornl.gov>
Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289)
In-Reply-To: <Pine.A41.4.44.0201300827470.74956-100000@homer40.u.washington.edu>
Message-ID: <Pine.A41.4.31.0201301446540.16064-100000@hpss1.ccs.ornl.gov>
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 <R-bugs@biostat.ku.dk>; 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 <tlumley@u.washington.edu>
To: Dan Million <lio@hpss1.ccs.ornl.gov>
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289)
In-Reply-To: <Pine.A41.4.31.0201301446540.16064-100000@hpss1.ccs.ornl.gov>
Message-ID: <Pine.A41.4.44.0201301155360.117500-100000@homer04.u.washington.edu>
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 <R-bugs@biostat.ku.dk>; 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 <lio@hpss1.ccs.ornl.gov>
To: Thomas Lumley <tlumley@u.washington.edu>
cc: <r-devel@stat.math.ethz.ch>, <R-bugs@biostat.ku.dk>,
Dan Million <lio@hpss1.ccs.ornl.gov>
Subject: Re: [Rd] R 1.4.0 build fails on AIX (PR#1289)
In-Reply-To: <Pine.A41.4.44.0201301155360.117500-100000@homer04.u.washington.edu>
Message-ID: <Pine.A41.4.31.0201311327400.23486-100000@hpss1.ccs.ornl.gov>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <harald@cepba.upc.es>
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 <p.dalgaard@biostat.ku.dk>
Date: 05 May 2003 18:28:33 +0200
In-Reply-To: <200305051553.h45Fro2b016035@pubhealth.ku.dk>
Message-ID: <x2he89bbny.fsf@biostat.ku.dk>
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 <harald@cepba.upc.es>
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 <p.dalgaard@biostat.ku.dk>
CC: R-bugs@biostat.ku.dk
Subject: Re: [Rd] (PR#1289)
References: <200305051553.h45Fro2b016035@pubhealth.ku.dk> <x2he89bbny.fsf@biostat.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 <R-bugs@biostat.ku.dk>; 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 <hornik@ci.tuwien.ac.at>
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 <R-bugs@biostat.ku.dk>; 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 <jasont@indigoindustrial.co.nz>
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 <r-bugs@biostat.ku.dk>; 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 <m16x3Sh-000IamC@franz.stat.wisc.edu> (Debian Smail3.2.0.114)
for <r-bugs@r-project.org>; 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 <jasont@indigoindustrial.co.nz>
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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
>>>>> "Jason" == Jason Turner <jasont@indigoindustrial.co.nz> 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 <humbertc@univ-mlv.fr>
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 <R-bugs@biostat.ku.dk>; 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 <humbertc@univ-mlv.fr>
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 <p.dalgaard@biostat.ku.dk>
Date: 28 May 2002 14:32:31 +0200
In-Reply-To: <200205281007.MAA25465@pubhealth.ku.dk>
Message-ID: <x28z64fo68.fsf@blueberry.kubism.ku.dk>
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 <humbertc@univ-mlv.fr>
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
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> <x28z64fo68.fsf@blueberry.kubism.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: <x28z64fo68.fsf@blueberry.kubism.ku.dk>; from p.dalgaard@biostat.ku.dk on Tue, May 28, 2002 at 02:32:31PM +0200
Sender: Cyril Humbert <cyril@univ-mlv.fr>
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 <edd@debian.org>
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 <r-bugs@biostat.ku.dk>; 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 <edd@debian.org>
To: r-bugs@biostat.ku.dk
Cc: Daniel Schepler <schepler@math.berkeley.edu>,
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] <defunct>
>
> 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 <schepler@math.berkeley.edu>
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 <r-bugs@biostat.ku.dk>; 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 <edd@debian.org>
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 <schepler@math.berkeley.edu>
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 <daniel@frobnitz.ddts.net>
Dirk Eddelbuettel <edd@debian.org> 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 <edd@debian.org>
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 <r-bugs@biostat.ku.dk>; 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 <edd@debian.org>
To: Daniel Schepler <schepler@math.berkeley.edu>
Cc: Dirk Eddelbuettel <edd@debian.org>, 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 <R-bugs@biostat.ku.dk>; 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 <edd@debian.org>
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 <rdiaz@cnio.es>
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 <r-bugs@biostat.ku.dk>; 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 <rdiaz@cnio.es>
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 <R-bugs@biostat.ku.dk>; 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 <edd@debian.org>
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 <R-bugs@biostat.ku.dk>; 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 <edd@debian.org>
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 <camm@enhanced.com>
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 <edd@debian.org> 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 <camm@enhanced.com>
Cc: Dirk Eddelbuettel <edd@debian.org>, 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 <p.dalgaard@biostat.ku.dk>
Date: 24 Apr 2003 13:28:21 +0200
In-Reply-To: <54el3swyrk.fsf@intech19.enhanced.com>
Message-ID: <x2u1co878q.fsf@biostat.ku.dk>
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 <camm@enhanced.com> 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 <p.dalgaard@biostat.ku.dk>
Cc: Camm Maguire <camm@enhanced.com>, Dirk Eddelbuettel <edd@debian.org>,
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> <x2u1co878q.fsf@biostat.ku.dk>
From: Douglas Bates <bates@stat.wisc.edu>
Date: 24 Apr 2003 12:03:21 -0500
In-Reply-To: <x2u1co878q.fsf@biostat.ku.dk>
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 <bates@bates4.stat.wisc.edu>
Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
> Camm Maguire <camm@enhanced.com> 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 <bates@stat.wisc.edu>
Cc: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>,
Dirk Eddelbuettel <edd@debian.org>, 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> <x2u1co878q.fsf@biostat.ku.dk>
<6r7k9j25gm.fsf@bates4.stat.wisc.edu>
From: Camm Maguire <camm@enhanced.com>
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 <bates@stat.wisc.edu> writes:
> Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
>
> > Camm Maguire <camm@enhanced.com> 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 <hornik@ci.tuwien.ac.at>
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 <R-bugs@biostat.ku.dk>; 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 <hornik@ci.tuwien.ac.at>
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: <ckm@loafer.org>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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" <beebe@math.utah.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <beebe@math.utah.edu>
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: <CMM.0.92.0.1051206035.beebe@suncore.math.utah.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)
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" <beebe@math.utah.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <beebe@math.utah.edu>
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: <CMM.0.92.0.1051206320.beebe@suncore.math.utah.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)
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 <p.dalgaard@biostat.ku.dk>
> > ##- 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <beebe@math.utah.edu>
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: <CMM.0.92.0.1051970968.beebe@suncore.math.utah.edu>
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: beebe@math.utah.edu
cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] R-1.7.0 build feedback: NetBSD 1.6 (PR#2837)
In-Reply-To: <200305031410.h43EAB2b001238@pubhealth.ku.dk>
Message-ID: <Pine.LNX.4.44.0305031519400.7222-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <beebe@math.utah.edu>
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: <CMM.0.92.0.1052057088.beebe@suncore.math.utah.edu>
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 <stdio.h>
#include <stdlib.h>
#include <zlib.h>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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: <CanisMaior@web.de>
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 <r-bugs@biostat.ku.dk>; 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: <CanisMaior@web.de>
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 <R-bugs@biostat.ku.dk>; 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 <saikat@stat.wisc.edu>
In-Reply-To: <200309250926.h8P9QG0P023078@pubhealth.ku.dk>
Message-Id: <CC5C1771-F027-11D7-8345-0003931A3C9E@stat.wisc.edu>
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 <R-bugs@biostat.ku.dk>; 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 <saikat@stat.wisc.edu>
In-Reply-To: <16244.34147.349298.186981@mithrandir.hornik.net>
Message-Id: <F3DF72BF-F077-11D7-8345-0003931A3C9E@stat.wisc.edu>
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 <p.murrell@auckland.ac.nz>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>; 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 <r-bugs@r-project.org>;
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 <r-bugs@r-project.org>; 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 <p.murrell@auckland.ac.nz>
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: <Atro.Tossavainen+rproject@helsinki.fi>
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 <R-bugs@biostat.ku.dk>; 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 <Piers.Dunstan@csiro.au>
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: <Piers.Dunstan@csiro.au>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>; 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 <Piers.Dunstan@csiro.au>
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: <MSchwartz@MedAnalytics.com>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <MSchwartz@MedAnalytics.com>
Reply-To: MSchwartz@MedAnalytics.com
To: Piers.Dunstan@csiro.au
Cc: R-Devel <r-devel@stat.math.ethz.ch>, 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: <gilescrane@doh.state.nj.us>
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 <R-bugs@biostat.ku.dk>; 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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: gilescrane@doh.state.nj.us
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: Re: [Rd] dates (PR#7008)
In-Reply-To: <20040622201846.CE08DEABD@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0406231300590.23737-100000@gannet.stats>
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" <Simon.Fear@synequanon.com>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@lists.r-project.org>; 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 <r-bugs@r-project.org>; 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" <Simon.Fear@synequanon.com>
To: <r-bugs@r-project.org>
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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 <ggrothendieck@volcanomail.com>
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 <r-bugs@biostat.ku.dk>; 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 <ggrothendieck@volcanomail.com>
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 <smcnary@charm.net>
From: Rich Heiberger <rmh@surfer.sbm.temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@hypatia>; 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 <maechler@stat.math.ethz.ch>
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
<ess-help.stat.math.ethz.ch>
List-Help: <mailto:ess-help-request@stat.math.ethz.ch?subject=help>
List-Post: <mailto:ess-help@stat.math.ethz.ch>
List-Subscribe: <https://www.stat.math.ethz.ch/mailman/listinfo/ess-help>,
<mailto:ess-help-request@stat.math.ethz.ch?subject=subscribe>
List-Archive: <https://www.stat.math.ethz.ch/pipermail/ess-help>
List-Unsubscribe: <https://www.stat.math.ethz.ch/mailman/listinfo/ess-help>,
<mailto:ess-help-request@stat.math.ethz.ch?subject=unsubscribe>
Errors-To: ess-help-bounces@stat.math.ethz.ch
From: Scot W McNary <smcnary@charm.net>
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 <rmh@surfer.sbm.temple.edu>
Subject: Re: where should i increase ess-loop-timeout
To: <ess-help@stat.math.ethz.ch>, Alejandro Mu?oz del R?o
<munoz@stat.wisc.edu>
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 <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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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: <martin.noellenburg@stud.uni-karlsruhe.de>
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 <R-bugs@biostat.ku.dk>; 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: <ligges@amadeus.statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 05 Apr 2004 19:23:07 +0200
In-Reply-To: <20040405161147.6787A10439@slim.kubism.ku.dk>
Message-ID: <x2y8pagwzo.fsf@biostat.ku.dk>
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 <tplate@blackmesacapital.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@R-project.org>; 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 <tplate@blackmesacapital.com>
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: <ripley@stats.ox.ac.uk>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ripley@stats.ox.ac.uk>
X-X-Sender: ripley@gannet.stats
To: tplate@blackmesacapital.com
Cc: r-devel@stat.math.ethz.ch, <R-bugs@biostat.ku.dk>
Subject: (PR#6955) Re: [Rd] strange apparently data-dependent crash with
large data
In-Reply-To: <20040607165927.D6BD8108F1@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.44.0406071836090.13771-100000@gannet.stats>
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 <R-bugs@biostat.ku.dk>; 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 <dmurdoch@pair.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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 <dmurdoch@pair.com>
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: <rqpa80lp34n5k1qjbggrofkv9qmc1doria@4ax.com>
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"
<ggrothendieck@myway.com> 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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 20 Apr 2004 20:59:22 +0200
In-Reply-To: <20040420181543.A86F110478@slim.kubism.ku.dk>
Message-ID: <x2y8oqfpbp.fsf@biostat.ku.dk>
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"
> <ggrothendieck@myway.com> 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: <chabrier@toulouse.inra.fr>
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 <R-bugs@biostat.ku.dk>; 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" <DDORER@PARTNERS.ORG>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; Mon, 5 Jul 2004 17:39:20 +0200
Received: by phsxchici3.mgh.harvard.edu with Internet Mail Service (5.5.2657.72)
id <N9V2C3AF>; Mon, 5 Jul 2004 11:40:02 -0400
Message-ID: <098FF7AF9BBDD511B09500508BE393C507C84341@phsexch23.mgh.harvard.edu>
From: "Dorer, David" <DDORER@PARTNERS.ORG>
To: "'r-bugs@r-project.org'" <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"
<<bug.txt>>
------_=_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, <rdfile> line 46892.
Report bugs to <r-bugs@r-project.org>.
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: <bauerda@ieee.org>
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 <R-bugs@biostat.ku.dk>; 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: <p.dalgaard@biostat.ku.dk>
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 <p.dalgaard@biostat.ku.dk>
Date: 07 Jul 2004 00:54:51 +0200
In-Reply-To: <20040706182507.2731B108D8@slim.kubism.ku.dk>
Message-ID: <x23c44pwzo.fsf@biostat.ku.dk>
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: <williams.elliot@bls.gov>
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 <R-bugs@biostat.ku.dk>; 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: <maechler@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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 <williams.elliot@bls.gov>
>>>>> 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" <rmh@temple.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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" <rmh@temple.edu>
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: <f7ae50c3.5d56366f.81a7900@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=-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: <dmurdoch@pair.com>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <dmurdoch@pair.com>
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: <grtte0d4vu7cuircllnifd8nlprhha4q83@4ax.com>
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" <rmh@temple.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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" <rmh@temple.edu>
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: <a9c5edca.5de465bb.81ab300@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.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: <ligges@statistik.uni-dortmund.de>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <ligges@statistik.uni-dortmund.de>
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: <rpeng@jhsph.edu>
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 <R-bugs@biostat.ku.dk>; 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" <rmh@temple.edu>
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: <rmh@temple.edu>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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" <rmh@temple.edu>
Subject: Re: [Rd] read.table, read.fwf, and na.strings
(PR#7075)
To: Uwe Ligges <ligges@statistik.uni-dortmund.de>
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 <maechler@stat.math.ethz.ch>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@stat.math.ethz.ch>; 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 <maechler@stat.math.ethz.ch>
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 <maechler@stat.math.ethz.ch>
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" <l.rosado_xk@4b.es>
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: <l.rosado_xk@4b.es>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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: <e2ff01c46914$cb4c6d6d$d4db46d8@wonderfulcatv.com.tw>
From: "Leopoldo Rosado" <l.rosado_xk@4b.es>
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?= <clock@twibright.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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?= <clock@twibright.com>
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" <iqcmqibdlxce@yahoo.com>
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: <iqcmqibdlxce@yahoo.com>
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 <r-bugs@biostat.ku.dk>; 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 <r-bugs@biostat.ku.dk>;
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 <r-bugs@biostat.ku.dk>; 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" <iqcmqibdlxce@yahoo.com>
To: "R-bugs" <r-bugs@biostat.ku.dk>
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 <dmurdoch@pair.com>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@stat.math.ethz.ch>; 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 <dmurdoch@pair.com>
To: "Roger D. Peng" <rpeng@jhsph.edu>
Cc: Marlene Mueller <Marlene.Mueller@gmx.de>,
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: <dufaf01kgr89ok9ejo1fqhsigfaotvhisv@4ax.com>
References: <13650.1089809941@www40.gmx.net> <n8caf0dpfndok0lgh80rrfqnlmt90voa3e@4ax.com> <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" <rpeng@jhsph.edu>
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"
>> <Marlene.Mueller@gmx.de> 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" <rpeng@jhsph.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@stat.math.ethz.ch>; 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" <rpeng@jhsph.edu>
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Duncan Murdoch <dmurdoch@pair.com>
Cc: Marlene Mueller <Marlene.Mueller@gmx.de>,
R-bugs@stat.math.ethz.ch
Subject: Re: [R] constrOptim and function with additional parameters?
References: <13650.1089809941@www40.gmx.net> <n8caf0dpfndok0lgh80rrfqnlmt90voa3e@4ax.com> <40F53CC9.9070305@jhsph.edu> <dufaf01kgr89ok9ejo1fqhsigfaotvhisv@4ax.com>
In-Reply-To: <dufaf01kgr89ok9ejo1fqhsigfaotvhisv@4ax.com>
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" <rpeng@jhsph.edu>
> 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"
>>><Marlene.Mueller@gmx.de> 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" <xmbrgqw@hush.com>
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: <xmbrgqw@hush.com>
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" <xmbrgqw@hush.com>
From: "WebCamFan" <xmbrgqw@hush.com>
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" <rmh@temple.edu>
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: <mail@stat.math.ethz.ch>
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>;
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 <R-bugs@biostat.ku.dk>; 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 <R-bugs@biostat.ku.dk>; 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 <r-bugs@r-project.org>; 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" <rmh@temple.edu>
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~