Re: [Rd] stringsAsFactors
In both cases, that is as it should be. 1. expand.grid() (sic) has its main application in factorial designs, for which you want a set of factors 2. tables are factorial structures by nature. Converting factors to character would lose level order (true for 1. as well, actually) - pd > On 13 Apr 2020, at 13:01 , Karolis Koncevičius > wrote: > > Hello, > > I also want to report 2 missed cases of stringsAsFactors=TRUE in base: > > 1. grid.expand() still uses hard stringsAsFactors=TRUE in its arguments. > 2. as.data.frame.table() also keeps factors after conversion from table. > >>>>>>> Duncan Murdoch >>>>>>>on Sun, 12 Apr 2020 08:57:14 -0400 writes: >> >> > The NEWS for R 4.0.0 says "R now uses a stringsAsFactors = FALSE >> > default, and hence by default no longer converts strings to factors in >> > calls to data.frame() and read.table()." >> >> > This seems to have been implemented by setting options(stringsAsFactors >> > = FALSE) in the main R profile. However, setting >> >> > options(stringsAsFactors = NULL) >> >> > reverts to the same behavior as the old options(stringsAsFactors = >> > TRUE). Is this intentional? >> >> >> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and >> alerting us about it. >> >> This will be changed ASAP. >> >> ... and it will benefit the whole R user community if quite a >> few good R users (as most readers of 'R-devel') would start >> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance! >> >> Martin >> >> ______ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expressions from boxplot() passed to bxp()
It's not new anyway. You see the same behaviour with
boxplot(dat, ylab=quote(X[2]))
and it boils down to the use of do.call("bxp", ...) in the internals.
As a general matter, expression() exists to prevent this sort of confusion,
e.g., in this construction,
> X <- quote(Y+1); bquote(f(.(X)))
f(Y + 1)
is indistinguishable from just entering f(Y+1), so f has no way of detecting
whether or not it is intended to evaluate Y + 1. The same thing is happening
with do.call: call objects are being "spliced into" the generated call, and if
they are not protected with expression, you have the trouble.
I don't know whether it is worth trying to change this. You know the
workaround.
-pd
> On 27 Mar 2020, at 02:55 , Marius Hofert wrote:
>
> Hi,
>
> Is this expected behavior (R-3.6.0)?
>
> dat <- cbind(x = 1:10, y = 10:1)
> ylab <- substitute(X[t], list(t = 2))
> plot(dat, ylab = ylab) # works (correctly displays ylab)
> boxplot(dat, ylab = ylab) # fails
> boxplot(dat, ylab = as.expression(ylab)) # works
>
> Thanks & cheers,
> M
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unstable corner of parameter space for qbeta?
It's a pretty extreme case, try e.g. curve(pbeta(x, shape1, shape2), n=10001),
and (probably -- I can't be bothered to work out the relation between beta
shapes and F df parameters this morning...) outside what is normally
encountered in statistical analyses. Notice though, that you have lower=FALSE
in your Qbeta0, so you should have it in qbeta as well:
> qbeta(t,shape1,shape2, lower=FALSE)
[1] 0.949
Warning message:
In qbeta(t, shape1, shape2, lower = FALSE) :
full precision may not have been achieved in 'qbeta'
which of course is still wrong (I dont't think there is a problem in the other
tail, Qbeta0(t,, lower=TRUE) returns zero.
You can see the effect also with
curve(qbeta(x, shape1, shape2), n=10001, from=.99, to=1)
which kind of suggests one of those regime-switching bugs, where different
methods are used for various parts of the domain, and the cross-over is not
done quite right.
At any rate, qbeta is one of R's very basic workhorses, so we do want it to
work right, so by all means file a report.
-pd
> On 26 Mar 2020, at 02:09 , Ben Bolker wrote:
>
>
> I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
> since there's a clear warning about lack of convergence of the numerical
> algorithm ("full precision may not have been achieved"). I can work
> around this, but I'm curious why it happens and whether there's a better
> workaround -- it doesn't seem to be in a particularly extreme corner of
> parameter space. It happens, e.g., forthese parameters:
>
> phi <- 1.1
> i <- 0.01
> t <- 0.001
> shape1 = i/phi ## 0.009090909
> shape2 = (1-i)/phi ## 0.9
> qbeta(t,shape1,shape2) ## 5.562685e-309
> ## brute-force uniroot() version, see below
> Qbeta0(t,shape1,shape2) ## 0.9262824
>
> The qbeta code is pretty scary to read: the warning "full precision
> may not have been achieved" is triggered here:
>
> https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530
>
> Any thoughts? Should I report this on the bug list?
>
>
> A more general illustration:
> http://www.math.mcmaster.ca/bolker/misc/qbeta.png
>
> ===
> fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
> f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
> }
> ## brute-force beta quantile function
> Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
> fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
> uniroot(fn,interval=c(0,1))$root
> }
> Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
> curve(fun,from=1,to=4)
> curve(fun(x,f=Qbeta),add=TRUE,col=2)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
Do note that 3.6-patched will only be live for a day or two as we branch for
4.0.0 on Friday. Anything committed there is unlikely to make it into an
official release (in principle, the 3.6 branch can be revived but it would take
a very strong incentive to do so.)
If you want an R-3.6.3-for-ppc, I think a vendor patch is the way. AFAIR (it's
been more than a decade since I looked at this stuff) the RPM spec files make
it fairly easy to apply changes to the sources before building.
-pd
> On 25 Mar 2020, at 10:00 , Martin Maechler wrote:
>
>>>>>> Martin Maechler
>>>>>>on Tue, 17 Dec 2019 11:25:31 +0100 writes:
>
>>>>>> Tom Callaway
>>>>>>on Fri, 13 Dec 2019 11:06:25 -0500 writes:
>
>>> An excellent question. It is important to remember two key
>>> facts:
>
>>> 1. With gcc on ppc64, long doubles exist, they can
>>> be used, just not safely as constants (and maybe they
>>> still can be used safely under specific conditions?).
>
>>> 2. I am not an expert in either PowerPC64 or gcc. :)
>
>>> Looking at connections.c, we have (in order):
>>> * handling long double as a valid case in a switch statement checking size
>>> * adding long double as a field in the u union define
>>> * handling long double as a valid case in a switch statement checking size
>>> * handling long double as a valid case in a switch statement checking size
>>> * memcpy from the address of a long double
>
>>> In format.c, we have (in order):
>>> * conditionally creating private_nearbyintl for R_nearbyintl
>>> * defining a static const long double tbl[]
>>> * use exact scaling factor in long double precision
>
>>> For most of these, it seems safe to leave them as is for ppc64. I would
>>> have thought that the gcc compiler might have had issue with:
>
>>> connections.c:
>>> static long double ld1;
>>> for (i = 0, j = 0; i < len; i++, j += size) {
>>> ld1 = (long double) REAL(object)[i];
>
>>> format.c:
>>> static const long double tbl[] =
>
>>> ... but it doesn't. Perhaps the original code at issue:
>
>>> arithmetic.c:
>>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>
>>> only makes gcc unhappy because of the very large value trying to be stored
>>> in the static long double, which would make it span the "folded double" on
>>> that architecture.
>
>>> *
>
>>> It seems that the options are:
>
>>> A) Patch the one place where the compiler determines it is not safe to use
>>> a static long double on ppc64.
>>> B) Treat PPC64 as a platform where it is never safe to use a static long
>>> double
>
>>> FWIW, I did run the test suite after applying my patch and all of the tests
>>> pass on ppc64.
>
>>> Tom
>
>> Thank you, Tom.
>> You were right... and only A) is needed.
>
>> In the mean time I've also been CC'ed in a corresponding debian
>> bug report on the exact same architecture.
>
>> In the end, after explanation and recommendation by Tomas
>> Kalibera, I've committed a slightly better change to R's
>> sources, both in the R-devel (trunk) and the "R-3.6.x patched"
>> branch: Via a macro, it continues to use long double also for
>> the PPC 64 in this case:
>
>> $ svn diff -c77587
>> Index: src/main/arithmetic.c
>> ===
>> --- src/main/arithmetic.c(Revision 77586)
>> +++ src/main/arithmetic.c(Revision 77587)
>> @@ -176,8 +176,14 @@
>> #endif
>> }
>
>> +
>> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
>> +# ifdef __PPC64__
>> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with
>> LDOUBLE
>> +# define q_1_eps (1 / LDBL_EPSILON)
>> +# else
>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>> +# endif
>> #else
>> static double q_1_eps = 1 / DBL_EPSILON;
>> #endif
>
>> - ----- -----
>
> Now, Debian Bug#946836 has been reopened,
> because __PPC64__ does not cover all powerpc architectures
> and in their build farm they found non-PPC64 cases which also
> needed to switch from a static variable to a macro,
>
> the suggestion being to replace __PPC64__ by __powerpc__
>
> which is what I'm going to commit now (for R-3.6.x patched and
> for R-devel !).
> I hope that these macros are +- universally working and not too
> much depending on the exact compiler flavor.
>
> Martin Maechler
> ETH Zurich and R Core team
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] note about mispelled words
However, notice that if it is the guy from the Kruskal-Wallis test (William K., 1919--2005), the "Kruskall" is in fact misspelt. It might be someone else, of course... -pd > On 17 Mar 2020, at 18:24 , Duncan Murdoch wrote: > > I believe it is also acceptable to explain in your submission message that > the misspelled words are all proper names. As far as I know, misspellings > are not enough of a problem to cause an automatic rejection, so a human being > will be making a judgment about the note. > > Duncan Murdoch > > On 17/03/2020 11:41 a.m., Henrik Bengtsson wrote: >> You can single quote them to avoid them being spell checked, e.g. ... >> using methods of 'Kruskall' and 'Brainerd'. This is a common and >> accepted practice. >> This is hinted at in "Writing R Extensions" (e.g. help.start()); >> The mandatory ‘Description’ field should give a comprehensive >> description of what the package does. One can use several (complete) >> sentences, but only one paragraph. It should be intelligible to all >> the intended readership (e.g. for a CRAN package to all CRAN users). >> It is good practice not to start with the package name, ‘This package’ >> or similar. As with the ‘Title’ field, double quotes should be used >> for quotations (including titles of books and articles), and single >> quotes for non-English usage, including names of other packages and >> external software. This field should also be used for explaining the >> package name if necessary. URLs should be enclosed in angle brackets, >> e.g. ‘<https://www.r-project.org>’: see also Specifying URLs. >> /Henrik >> On Tue, Mar 17, 2020 at 8:30 AM Gianmarco Alberti >> wrote: >>> >>> Hello, >>> I am checking a package of mine, and I got only 1 note regarding possibly >>> misspelled words in the DESCRIPTION. >>> >>> The issue I am facing is that those 6 words are not actually misspelled, >>> being either first or last names of individuals (actually, statistician; >>> e.g., Kruskall, Brainerd). >>> >>> Shall I have to do something (removing those; which does not make sense), >>> or upon submitting my new version of the package there is a way to make >>> clear that that note can be ignored? >>> >>> By the way, those names were already there in earlier versions of the >>> package and no note cropped out in those occasions. >>> >>> Thank you >>> Best >>> GmA >>> >>> >>> Dr Gianmarco Alberti (PhD Udine) >>> Lecturer in Spatial Forensics >>> Coordinator of the BA course in Criminology >>> Department of Criminology >>> Faculty for Social Wellbeing >>> Room 332, Humanities B (FEMA) >>> University of Malta, Msida, Malta (Europe) - MSD 2080 >>> tel +356 2340 3718 >>> >>> Academic profiles >>> https://www.researchgate.net/profile/Gianmarco_Alberti4 >>> https://malta.academia.edu/GianmarcoAlberti >>> >>> Google Scholar profile >>> https://scholar.google.com/citations?user=tFrJKQ0J=en >>> >>> Correspondence Analysis website >>> http://cainarchaeology.weebly.com/ >>> >>> R packages on CRAN: >>> CAinterprTools >>> https://cran.r-project.org/web/packages/CAinterprTools/index.html >>> >>> GmAMisc >>> https://cran.r-project.org/package=GmAMisc >>> >>> movecost >>> https://cran.r-project.org/web/packages/movecost/index.html >>> >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] R 4.0.0 scheduled for April 24
Full schedule is available on developer.r-project.org. Notice that Copenhagen Business School, like all Danish educational institutions, is physically locked down for two weeks due to COVID-19. The schedule is automated, but there may be irregularities with the nightly builds, if things act up and I can't get to the machine. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.3 is released
The build system rolled up R-3.6.3.tar.gz (codename "Holding the Windsock") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 2b364f6eaef28e069ab8ed779ee5859d MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60 MD5 (VERSION-INFO.dcf) = d97d382dc5583f9385461d8a4b0ff091 MD5 (R-3/R-3.6.3.tar.gz) = 506c9576ba33e1262ad5b5624db9d96a 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 50381062bad9aeb4b0c8c4695cb6955c5ff70699fcc821a8e1b340229100278c NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS 20f8bfdfc6302bb2cf9b0fc5424c9a10ac0953096b6c32768ffd106a3fdd4589 VERSION-INFO.dcf 89302990d8e8add536e12125ec591d6951022cf8475861b3690bc8bf1cefaa8f R-3/R-3.6.3.tar.gz This is the relevant part of the NEWS file CHANGES IN R 3.6.3: NEW FEATURES: * The included LAPACK has been updated to version 3.9.0 (for the included routines, just bug fixes). BUG FIXES: * Fixed a C level integer overflow in rhyper(); reported by Benjamin Tyner in PR#17694. * Uses of url(gzcon(.)) needing to extend buffer size have failed (with HTTP/2 servers), reported by G'abor Cs'ardi. * predict(loess(..), se=TRUE) now errors out (instead of seg.faulting etc) for large sample sizes, thanks to a report and patch by Benjamin Tyner in PR#17121. * tools:assertCondition(., "error") and hence assertError() no longer return errors twice (invisibly). * update(form, new) in the case of a long new formula sometimes wrongly eliminated the intercept from form, or (more rarely) added a garbage term (or seg.faulted !); the fix happened by simplifying the C-level logic of terms.formula(). Reported by Mathias Amb"uhl in PR#16326. * The error message from stopifnot(.., ) again contains the full "stopifnot(...)" call: Its attempted suppression did not work consistently. * On Windows, download.file(., , "wininet", headers=character()) would fail; reported with patch proposal by Kevin Ushey in PR#17710. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] specials issue, a heads up
For some reason, I can't read this without thinking of the tech support guy going "No, it is http:// ... aitch - tee - tee - pee - colon - AS IN WHERE YOUR HEAD IS - slash - slash ..." -pd > On 24 Feb 2020, at 18:26 , Ben Bolker wrote: > > In the long run, coming up with a way to parse specials in formulas > that is both clean and robust is a good idea - annoying users are a > little bit like CRAN maintainers in this respect. I think I would > probably do this by testing identical(eval(extracted_head), > survival::Surv) - but this has lots of potential annoyances (what if > extracted_head is a symbol that can't be found in any attached > environment? Do we have to start with if > (length(find(deparse(extracted_head))>0) ? > > In the short run, a clear note in the documentation seems entirely sufficient. > > On Mon, Feb 24, 2020 at 12:01 PM Hugh Parsonage > wrote: >> >> I mean if the person filing the bug regards style as more important than >> the truth of how R treats formulas then they’re literally talking in >> another language. >> >> I strongly recommend you do nothing or at most make a note in the >> documentation addressing this. Your time is too valuable. >> >> On Tue, 25 Feb 2020 at 12:56 am, Therneau, Terry M., Ph.D. via R-devel < >> r-devel@r-project.org> wrote: >> >>> I recently had a long argument wrt the survival package, namely that the >>> following code >>> didn't do what they expected, and so they reported it as a bug >>> >>> survival::coxph( survival::Surv(time, status) ~ age + sex + >>> survival::strata(inst), >>> data=lung) >>> >>> a. The Google R style guide recommends that one put :: everywhere >>> b. This breaks the recognition of cluster as a "special" in the terms >>> function. >>> >>> I've been stubborn and said that their misunderstanding of how formulas >>> work is not my >>> problem. But I'm sure that the issue will come up again, and multiple >>> other packages >>> will break. >>> >>> A big problem is that the code runs, it just gives the wrong answer. >>> >>> Suggestions? >>> >>> Terry T. >>> >>> >>>[[alternative HTML version deleted]] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >>[[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] specials issue, a heads up
Notice that the stats package contains the same issue: For some reason it
defines an offset() function (for no particular reason, afaics) which just
returns its argument. So
> x <- rnorm(10)
> y <- z <- 1:10
> lm(x~y+offset(z))
Call:
lm(formula = x ~ y + offset(z))
Coefficients:
(Intercept)y
0.8253 -1.0840
> lm(x~y+stats::offset(z))
Call:
lm(formula = x ~ y + stats::offset(z))
Coefficients:
(Intercept) y stats::offset(z)
0.82531 -0.08397NA
So I'm inclined to say that formulas are formulas and functions using formulas
interpret functions and operators at their own convenience. You also deserve
what you get from
> lm(x~base::`+`(y,z))
Call:
lm(formula = x ~ base::`+`(y, z))
Coefficients:
(Intercept) base::`+`(y, z)
0.82531 -0.04198
-pd
> On 24 Feb 2020, at 19:21 , Duncan Murdoch wrote:
>
> On 24/02/2020 8:55 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:
>> I recently had a long argument wrt the survival package, namely that the
>> following code
>> didn't do what they expected, and so they reported it as a bug
>>survival::coxph( survival::Surv(time, status) ~ age + sex +
>> survival::strata(inst),
>> data=lung)
>> a. The Google R style guide recommends that one put :: everywhere
>> b. This breaks the recognition of cluster as a "special" in the terms
>> function.
>> I've been stubborn and said that their misunderstanding of how formulas work
>> is not my
>> problem. But I'm sure that the issue will come up again, and multiple
>> other packages
>> will break.
>> A big problem is that the code runs, it just gives the wrong answer.
>> Suggestions?
>
> I don't know how widely used survival::strata is versus the special strata
> (or cluster, or other specials). If you were just introducing this now, I'd
> try to make sure that only one of those worked: don't have any functions
> matching the names of specials, or have functions that generate an error if
> you call them. I did that in the much less widely used "tables" package,
> e.g. Heading() has special interpretation, and the Heading function is
> defined as
>
> Heading <- function(name = NULL, override = TRUE,
>character.only = FALSE,
> nearData = TRUE)
>stop("This is a pseudo-function, not meant to be called.")
>
> However, survival has far more users than tables does, so changing the name
> of your special functions or the corresponding regular functions could be a
> huge headache.
>
> Perhaps there's a way to set a flag before evaluating the function in the
> formula, and generate a warning if survival::strata is called when it looks
> like the special function is intended.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.3 scheduled for February 29
Full schedule is available on developer.r-project.org. (The date is chosen to celebrate the 5th anniversary of R 1.0.0. Some irregularity may occur on the release day, since this happens to be a Saturday and the release manager is speaking at the CelebRation2020 event...) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mrds function integratepdf cannot be found
Yes, looks like a missing export (and a missing example on the help page, which would have exposed the error...). mrds:::integratepdf() should do the appropriate "burglary" -pd > On 28 Jan 2020, at 12:09 , Patrick Giraudoux > wrote: > > Hi, > > Trying to use the function integratepdf of the mrds package, I get this > message: > > |Error in integratepdf(fox.ds$ddf$ds$aux$ddfobj, select = rep(TRUE, > nrow(fox.ds$ddf$ds$aux$ddfobj$xmat)), : could not find function > "integratepdf" | > > Has anyone already had this issue ? Maybe the function is not exported > in the namespace? > > Best, > > Patrick > > >> library(mrds) > This is mrds 2.2.0 > Built: R 3.6.1; ; 2019-09-28 03:24:13 UTC; windows > > > [[alternative HTML version deleted]] > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Need help to resolve NOTEs in auto check
(a) Spelling issues: False positive are checked manually by CRAN, so just tell them on submission. For software items, Uwe at some point recommended "Single quotes around software names such as 'pkg', functions should be written with parentheses as in foo()." (b) The procedure for submitting is to run 'R CMD build' on the (unpackaged) source directory, then submit the resulting .tar.gz file. If you don't do that, the build time stamp will be absent. Similarly 'R CMD check' should be run on the output from 'R CMD build'. Like this (oups, that dir is out of sync on this computer): Peters-iMac:ISWR-2nd-ed pd$ R CMD build ISwR * checking for file ‘ISwR/DESCRIPTION’ ... OK * preparing ‘ISwR’: * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a ‘data/datalist’ file should be added * re-saving .R files as .rda NB: *.R converted to .rda: other files may need to be removed * re-saving tabular files * creating default NAMESPACE file * building ‘ISwR_2.0-5.tar.gz’ Peters-iMac:ISWR-2nd-ed pd$ R CMD check --as-cran ISwR_2.0-5.tar.gz * using log directory ‘/Users/pd/BIOSTAT/books/ISWR-2nd-ed/ISwR.Rcheck’ * using R version 3.6.0 (2019-04-26) * using platform: x86_64-apple-darwin15.6.0 (64-bit) * using session charset: UTF-8 * using option ‘--as-cran’ * checking for file ‘ISwR/DESCRIPTION’ ... OK * this is package ‘ISwR’ version ‘2.0-5’ * checking CRAN incoming feasibility ... WARNING Maintainer: ‘Peter Dalgaard ’ Insufficient package version (submitted: 2.0.5, existing: 2.0.8) Days since last update: 2 The Date field is over a month old. * checking package namespace information ... OK *.. (c) Examples _will_ be run as part of the check procedure. If that produces stray files in the check directory, you will tget the message that you see. In interactive usage, example(...) will similarly create files in the current directory, which is verboten, so write to a temporary directory instead. (See help(tempfile) for specifics). > On 22 Jan 2020, at 11:29 , Ian Walker wrote: > > Hello, > > I'm trying to repackage an R function so I can update the licence. I'm stuck > with the automatic checks. The problem appears to be the following three > NOTEs in the checking output: > > * checking CRAN incoming feasibility ... NOTE > Maintainer: ‘Ian Walker < > i.wal...@bath.ac.uk >> ’ > > Possibly mis-spelled words in DESCRIPTION: > DEMs (7:503) > STL (7:47) > stereolithography (7:52) > stl (7:24) > > The build time stamp is missing. > > It's not clear what is wrong here - is it the spellings (which are fine) or > the time stamp? If the latter, how do I resolve this? > > * checking DESCRIPTION meta-information ... NOTE > Checking should be performed on sources prepared by ‘R CMD build’. > > I can't make any sense of this issue! > > * checking for non-standard things in the check directory ... NOTE > Found the following files/directories: > ‘lovelyfunction.stl’ ‘volcano.stl’ > > These two .stl files are simply mentioned in the documentation's example code > - they're files that would be created if somebody ran the example code; > they're not in the R package I've created. > > Thanks for any help, > > Ian > -- > Dr Ian Walker FHEA | Department of Psychology, University of Bath > i.wal...@bath.ac.uk (academic) | m...@drianwalker.com (other matters) > > Website: drianwalker.com | Twitter: twitter.com/ianwalker > > My books: > Research Methods and Statistics - a new, clear introduction > http://tinyurl.com/res-stats > Research with People - the essential research textbook: http://amzn.to/sRbYxy > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] [R] choose(n, k) as n approaches k
More importantly, the gamma function is not nice for negative integer
arguments, so gchoose() blows up for integer k and n=-1,-2,...
> gchoose(-2,4)
[1] NaN
Warning messages:
1: In gamma(n + 1) : NaNs produced
2: In gamma(n + 1 - k) : NaNs produced
> choose(-2,4)
[1] 5
and so does the formula with beta().
Of course, choose(-r, k) is exactly what you need for the traditional
formulation of the negative binomial distribution as the number of successes to
get r failures.
-pd
> On 15 Jan 2020, at 01:25 , peter dalgaard wrote:
>
> That crossed my mind too, but presumably someone designed choose() to handle
> the near-integer cases specially. Otherwise, we already have beta() -- you
> just need to remember what the connection is ;-).
>
> I would expect that it has to do with the binomial and negative binomial
> distributions, but I can't offhand picture a calculation that leads to
> integer k, n plus/minus a tiny numerical error of the sort that one may
> encounter with, say, seq().
>
> -pd
>
> ;-) choose(a,b) = 1/(beta(a-b+1,b+1)*(a+1)) or thereabouts
>
>> On 14 Jan 2020, at 19:36 , John Mount wrote:
>>
>>
>> At the risk of throwing oil on a fire. If we are talking about fractional
>> values of choose() doesn't it make sense to look to the gamma function for
>> the correct analytic continuation? In particular k<0 may not imply the
>> function should evaluate to zero until we get k<=-1.
>>
>> Example:
>>
>> ``` r
>> choose(5, 4)
>> #> [1] 5
>>
>> gchoose <- function(n, k) {
>> gamma(n+1)/(gamma(n+1-k) * gamma(k+1))
>> }
>>
>> gchoose(5, 4)
>> #> [1] 5
>> gchoose(5, 0)
>> #> [1] 1
>> gchoose(5, -0.5)
>> #> [1] 0.2351727
>> ```
>>
>>> On Jan 14, 2020, at 10:20 AM, peter dalgaard wrote:
>>>
>>> OK, I see what you mean. But in those cases, we don't get the catastrophic
>>> failures from the
>>>
>>> if (k < 0) return 0.;
>>> if (k == 0) return 1.;
>>> /* else: k >= 1 */
>>>
>>> part, because at that point k is sure to be integer, possibly after
>>> rounding.
>>>
>>> It is when n-k is approximately but not exactly zero and we should return
>>> 1, that we either return 0 (negative case) or n (positive case; because the
>>> n(n-1)(n-2)... product has at least one factor). In the other cases, we get
>>> 1 or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to
>>> produce an integer, due to the
>>>
>>> return R_IS_INT(n) ? R_forceint(r) : r;
>>>
>>> part.
>>>
>>> -pd
>>>
>>>
>>>
>>>> On 14 Jan 2020, at 17:02 , Duncan Murdoch wrote:
>>>>
>>>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch
>>>>>> wrote:
>>>>>>
>>>>>> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>>>>>>> Yep, that looks wrong (probably want to continue discussion over on
>>>>>>> R-devel)
>>>>>>> I think the culprit is here (in src/nmath/choose.c)
>>>>>>>if (k < k_small_max) {
>>>>>>> int j;
>>>>>>> if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>>>>>>> if (k < 0) return 0.;
>>>>>>> if (k == 0) return 1.;
>>>>>>> /* else: k >= 1 */
>>>>>>> if n is a near-integer, then k can become non-integer and negative. In
>>>>>>> your case,
>>>>>>> n == 4 - 1e-7
>>>>>>> k == 4
>>>>>>> n - k == -1e-7 < 4
>>>>>>> n >= 0
>>>>>>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>>>>>>> so k gets set to
>>>>>>> n - k == -1e-7
>>>>>>> which is less than 0, so we return 0. However, as you point out, 1
>>>>>>> would be more reasonable and in accordance with the limit as n -> 4,
>>>>>>> e.g.
>>>>>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>>>>>> [1] -9.289025e-11
>>>>>>> I guess that the fix could be as simple as replacing n by R_forceint(n)
>>>>>>> in the k = n - k step.
>>>>>>
>>>&g
Re: [Rd] [R] choose(n, k) as n approaches k
Fix committed to R-devel w/regression test. I settled for just doing
k = R_forceint(n - k)
inside
if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
so that k stays integer.
In principle, you also could prefix this code
r = n;
for(j = 2; j <= k; j++)
r *= (n-j+1)/j;
return R_IS_INT(n) ? R_forceint(r) : r;
/* might have got rounding errors */
with
if(R_IS_INT(n)) n = R_forceint(n);
but as I said, I believe that is really a no-op because of the rounding at the
end.
-pd
> On 14 Jan 2020, at 19:20 , peter dalgaard wrote:
>
> OK, I see what you mean. But in those cases, we don't get the catastrophic
> failures from the
>
>if (k < 0) return 0.;
>if (k == 0) return 1.;
>/* else: k >= 1 */
>
> part, because at that point k is sure to be integer, possibly after rounding.
>
> It is when n-k is approximately but not exactly zero and we should return 1,
> that we either return 0 (negative case) or n (positive case; because the
> n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1
> or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce
> an integer, due to the
>
>return R_IS_INT(n) ? R_forceint(r) : r;
>
> part.
>
> -pd
>
>
>
>> On 14 Jan 2020, at 17:02 , Duncan Murdoch wrote:
>>
>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch wrote:
>>>>
>>>> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>>>>> Yep, that looks wrong (probably want to continue discussion over on
>>>>> R-devel)
>>>>> I think the culprit is here (in src/nmath/choose.c)
>>>>> if (k < k_small_max) {
>>>>>int j;
>>>>>if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>>>>>if (k < 0) return 0.;
>>>>>if (k == 0) return 1.;
>>>>>/* else: k >= 1 */
>>>>> if n is a near-integer, then k can become non-integer and negative. In
>>>>> your case,
>>>>> n == 4 - 1e-7
>>>>> k == 4
>>>>> n - k == -1e-7 < 4
>>>>> n >= 0
>>>>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>>>>> so k gets set to
>>>>> n - k == -1e-7
>>>>> which is less than 0, so we return 0. However, as you point out, 1 would
>>>>> be more reasonable and in accordance with the limit as n -> 4, e.g.
>>>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>>>> [1] -9.289025e-11
>>>>> I guess that the fix could be as simple as replacing n by R_forceint(n)
>>>>> in the k = n - k step.
>>>>
>>>> I think that would break symmetry: you want choose(n, k) to equal
>>>> choose(n, n-k) when n is very close to an integer. So I'd suggest the
>>>> replacement whenever R_IS_INT(n) is true.
>>>>
>>> But choose() very deliberately ensures that k is integer, so choose(n, n-k)
>>> is ill-defined for non-integer n.
>>
>> That's only true if there's a big difference. I'd be worried about cases
>> where n and k are close to integers (within 1e-7). In those cases, k is
>> silently rounded to integer. As I read your suggestion, n would only be
>> rounded to integer if k > n-k. I think both n and k should be rounded to
>> integer in this near-integer situation, regardless of the value of k.
>>
>> I believe that lchoose(n, k) already does this.
>>
>> Duncan Murdoch
>>
>>>double r, k0 = k;
>>>k = R_forceint(k);
>>> ...
>>>if (fabs(k - k0) > 1e-7)
>>>MATHLIB_WARNING2(_("'k' (%.2f) must be integer, rounded to %.0f"),
>>> k0, k);
>>>
>>>> Duncan Murdoch
>>>>
>>>>> -pd
>>>>>> On 14 Jan 2020, at 00:33 , Wright, Erik Scott wrote:
>>>>>>
>>>>>> This struck me as incorrect:
>>>>>>
>>>>>>> choose(3.99, 4)
>>>>>> [1] 0.979
>>>>>>> choose(3.999, 4)
>>>>>> [1] 0
>>>>>>> choose(4, 4)
>>>>>> [1] 1
>>>>>>> choose(4.001, 4)
>>>>>> [1] 4
>>>>>>> choose(4.01, 4)
>>>>>> [1] 1.02
>>&g
Re: [Rd] [R] choose(n, k) as n approaches k
Um, n(n-1)(n-2)...(n-k+1)/factorial(k), of course, but I think the argument
still holds.
Also, note that there are overflow conditions involved with computing
n(n-1)(n-2)...(n-k+1)/factorial(k)
as written, so it is computed in a loop with alternating multiply and divide
steps. This introduces FP errors even if it is known that the result should be
integer. I.e., we cannot remove the final "R_IS_INT(n) ? R_forceint(r) : r" if
we want choose(n, k) to return an integer if n and k are integers.
-pd
> On 14 Jan 2020, at 19:20 , peter dalgaard wrote:
>
> OK, I see what you mean. But in those cases, we don't get the catastrophic
> failures from the
>
>if (k < 0) return 0.;
>if (k == 0) return 1.;
>/* else: k >= 1 */
>
> part, because at that point k is sure to be integer, possibly after rounding.
>
> It is when n-k is approximately but not exactly zero and we should return 1,
> that we either return 0 (negative case) or n (positive case; because the
> n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1
> or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce
> an integer, due to the
>
>return R_IS_INT(n) ? R_forceint(r) : r;
>
> part.
>
> -pd
>
>
>
>> On 14 Jan 2020, at 17:02 , Duncan Murdoch wrote:
>>
>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch wrote:
>>>>
>>>> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>>>>> Yep, that looks wrong (probably want to continue discussion over on
>>>>> R-devel)
>>>>> I think the culprit is here (in src/nmath/choose.c)
>>>>> if (k < k_small_max) {
>>>>>int j;
>>>>>if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>>>>>if (k < 0) return 0.;
>>>>>if (k == 0) return 1.;
>>>>>/* else: k >= 1 */
>>>>> if n is a near-integer, then k can become non-integer and negative. In
>>>>> your case,
>>>>> n == 4 - 1e-7
>>>>> k == 4
>>>>> n - k == -1e-7 < 4
>>>>> n >= 0
>>>>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>>>>> so k gets set to
>>>>> n - k == -1e-7
>>>>> which is less than 0, so we return 0. However, as you point out, 1 would
>>>>> be more reasonable and in accordance with the limit as n -> 4, e.g.
>>>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>>>> [1] -9.289025e-11
>>>>> I guess that the fix could be as simple as replacing n by R_forceint(n)
>>>>> in the k = n - k step.
>>>>
>>>> I think that would break symmetry: you want choose(n, k) to equal
>>>> choose(n, n-k) when n is very close to an integer. So I'd suggest the
>>>> replacement whenever R_IS_INT(n) is true.
>>>>
>>> But choose() very deliberately ensures that k is integer, so choose(n, n-k)
>>> is ill-defined for non-integer n.
>>
>> That's only true if there's a big difference. I'd be worried about cases
>> where n and k are close to integers (within 1e-7). In those cases, k is
>> silently rounded to integer. As I read your suggestion, n would only be
>> rounded to integer if k > n-k. I think both n and k should be rounded to
>> integer in this near-integer situation, regardless of the value of k.
>>
>> I believe that lchoose(n, k) already does this.
>>
>> Duncan Murdoch
>>
>>>double r, k0 = k;
>>>k = R_forceint(k);
>>> ...
>>>if (fabs(k - k0) > 1e-7)
>>>MATHLIB_WARNING2(_("'k' (%.2f) must be integer, rounded to %.0f"),
>>> k0, k);
>>>
>>>> Duncan Murdoch
>>>>
>>>>> -pd
>>>>>> On 14 Jan 2020, at 00:33 , Wright, Erik Scott wrote:
>>>>>>
>>>>>> This struck me as incorrect:
>>>>>>
>>>>>>> choose(3.99, 4)
>>>>>> [1] 0.979
>>>>>>> choose(3.999, 4)
>>>>>> [1] 0
>>>>>>> choose(4, 4)
>>>>>> [1] 1
>>>>>>> choose(4.001, 4)
>>>>>> [1] 4
>>>>>>> choose(4.01, 4)
>>>>>> [1] 1.02
>>>>>>
>>>>>> Should base::choose(n,
Re: [Rd] [R] choose(n, k) as n approaches k
That crossed my mind too, but presumably someone designed choose() to handle
the near-integer cases specially. Otherwise, we already have beta() -- you just
need to remember what the connection is ;-).
I would expect that it has to do with the binomial and negative binomial
distributions, but I can't offhand picture a calculation that leads to integer
k, n plus/minus a tiny numerical error of the sort that one may encounter with,
say, seq().
-pd
;-) choose(a,b) = 1/(beta(a-b+1,b+1)*(a+1)) or thereabouts
> On 14 Jan 2020, at 19:36 , John Mount wrote:
>
>
> At the risk of throwing oil on a fire. If we are talking about fractional
> values of choose() doesn't it make sense to look to the gamma function for
> the correct analytic continuation? In particular k<0 may not imply the
> function should evaluate to zero until we get k<=-1.
>
> Example:
>
> ``` r
> choose(5, 4)
> #> [1] 5
>
> gchoose <- function(n, k) {
> gamma(n+1)/(gamma(n+1-k) * gamma(k+1))
> }
>
> gchoose(5, 4)
> #> [1] 5
> gchoose(5, 0)
> #> [1] 1
> gchoose(5, -0.5)
> #> [1] 0.2351727
> ```
>
>> On Jan 14, 2020, at 10:20 AM, peter dalgaard wrote:
>>
>> OK, I see what you mean. But in those cases, we don't get the catastrophic
>> failures from the
>>
>>if (k < 0) return 0.;
>>if (k == 0) return 1.;
>>/* else: k >= 1 */
>>
>> part, because at that point k is sure to be integer, possibly after
>> rounding.
>>
>> It is when n-k is approximately but not exactly zero and we should return 1,
>> that we either return 0 (negative case) or n (positive case; because the
>> n(n-1)(n-2)... product has at least one factor). In the other cases, we get
>> 1 or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to
>> produce an integer, due to the
>>
>>return R_IS_INT(n) ? R_forceint(r) : r;
>>
>> part.
>>
>> -pd
>>
>>
>>
>>> On 14 Jan 2020, at 17:02 , Duncan Murdoch wrote:
>>>
>>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch
>>>>> wrote:
>>>>>
>>>>> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>>>>>> Yep, that looks wrong (probably want to continue discussion over on
>>>>>> R-devel)
>>>>>> I think the culprit is here (in src/nmath/choose.c)
>>>>>> if (k < k_small_max) {
>>>>>>int j;
>>>>>>if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>>>>>>if (k < 0) return 0.;
>>>>>>if (k == 0) return 1.;
>>>>>>/* else: k >= 1 */
>>>>>> if n is a near-integer, then k can become non-integer and negative. In
>>>>>> your case,
>>>>>> n == 4 - 1e-7
>>>>>> k == 4
>>>>>> n - k == -1e-7 < 4
>>>>>> n >= 0
>>>>>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>>>>>> so k gets set to
>>>>>> n - k == -1e-7
>>>>>> which is less than 0, so we return 0. However, as you point out, 1 would
>>>>>> be more reasonable and in accordance with the limit as n -> 4, e.g.
>>>>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>>>>> [1] -9.289025e-11
>>>>>> I guess that the fix could be as simple as replacing n by R_forceint(n)
>>>>>> in the k = n - k step.
>>>>>
>>>>> I think that would break symmetry: you want choose(n, k) to equal
>>>>> choose(n, n-k) when n is very close to an integer. So I'd suggest the
>>>>> replacement whenever R_IS_INT(n) is true.
>>>>>
>>>> But choose() very deliberately ensures that k is integer, so choose(n,
>>>> n-k) is ill-defined for non-integer n.
>>>
>>> That's only true if there's a big difference. I'd be worried about cases
>>> where n and k are close to integers (within 1e-7). In those cases, k is
>>> silently rounded to integer. As I read your suggestion, n would only be
>>> rounded to integer if k > n-k. I think both n and k should be rounded to
>>> integer in this near-integer situation, regardless of the value of k.
>>>
>>> I believe that lchoose(n, k) already does this.
>>
Re: [Rd] [R] choose(n, k) as n approaches k
OK, I see what you mean. But in those cases, we don't get the catastrophic
failures from the
if (k < 0) return 0.;
if (k == 0) return 1.;
/* else: k >= 1 */
part, because at that point k is sure to be integer, possibly after rounding.
It is when n-k is approximately but not exactly zero and we should return 1,
that we either return 0 (negative case) or n (positive case; because the
n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1
or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce an
integer, due to the
return R_IS_INT(n) ? R_forceint(r) : r;
part.
-pd
> On 14 Jan 2020, at 17:02 , Duncan Murdoch wrote:
>
> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch wrote:
>>>
>>> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>>>> Yep, that looks wrong (probably want to continue discussion over on
>>>> R-devel)
>>>> I think the culprit is here (in src/nmath/choose.c)
>>>> if (k < k_small_max) {
>>>> int j;
>>>> if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>>>> if (k < 0) return 0.;
>>>> if (k == 0) return 1.;
>>>> /* else: k >= 1 */
>>>> if n is a near-integer, then k can become non-integer and negative. In
>>>> your case,
>>>> n == 4 - 1e-7
>>>> k == 4
>>>> n - k == -1e-7 < 4
>>>> n >= 0
>>>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>>>> so k gets set to
>>>> n - k == -1e-7
>>>> which is less than 0, so we return 0. However, as you point out, 1 would
>>>> be more reasonable and in accordance with the limit as n -> 4, e.g.
>>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>>> [1] -9.289025e-11
>>>> I guess that the fix could be as simple as replacing n by R_forceint(n) in
>>>> the k = n - k step.
>>>
>>> I think that would break symmetry: you want choose(n, k) to equal
>>> choose(n, n-k) when n is very close to an integer. So I'd suggest the
>>> replacement whenever R_IS_INT(n) is true.
>>>
>> But choose() very deliberately ensures that k is integer, so choose(n, n-k)
>> is ill-defined for non-integer n.
>
> That's only true if there's a big difference. I'd be worried about cases
> where n and k are close to integers (within 1e-7). In those cases, k is
> silently rounded to integer. As I read your suggestion, n would only be
> rounded to integer if k > n-k. I think both n and k should be rounded to
> integer in this near-integer situation, regardless of the value of k.
>
> I believe that lchoose(n, k) already does this.
>
> Duncan Murdoch
>
>> double r, k0 = k;
>> k = R_forceint(k);
>> ...
>> if (fabs(k - k0) > 1e-7)
>> MATHLIB_WARNING2(_("'k' (%.2f) must be integer, rounded to %.0f"),
>> k0, k);
>>
>>> Duncan Murdoch
>>>
>>>> -pd
>>>>> On 14 Jan 2020, at 00:33 , Wright, Erik Scott wrote:
>>>>>
>>>>> This struck me as incorrect:
>>>>>
>>>>>> choose(3.99, 4)
>>>>> [1] 0.979
>>>>>> choose(3.999, 4)
>>>>> [1] 0
>>>>>> choose(4, 4)
>>>>> [1] 1
>>>>>> choose(4.001, 4)
>>>>> [1] 4
>>>>>> choose(4.000001, 4)
>>>>> [1] 1.02
>>>>>
>>>>> Should base::choose(n, k) check whether n is within machine precision of
>>>>> k and return 1?
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>> ***
>>>>> sessionInfo()
>>>>> R version 3.6.0 beta (2019-04-15 r76395)
>>>>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>>>>> Running under: macOS High Sierra 10.13.6
>>>>>
>>>>> [[alternative HTML version deleted]]
>>>>>
>>>>> __
>>>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>>> PLEASE do read the posting guide
>>>>> http://www.R-project.org/posting-guide.html
>>>>> and provide commented, minimal, self-contained, reproducible code.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] choose(n, k) as n approaches k
> On 14 Jan 2020, at 16:21 , Duncan Murdoch wrote:
>
> On 14/01/2020 10:07 a.m., peter dalgaard wrote:
>> Yep, that looks wrong (probably want to continue discussion over on R-devel)
>> I think the culprit is here (in src/nmath/choose.c)
>> if (k < k_small_max) {
>> int j;
>> if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
>> if (k < 0) return 0.;
>> if (k == 0) return 1.;
>> /* else: k >= 1 */
>> if n is a near-integer, then k can become non-integer and negative. In your
>> case,
>> n == 4 - 1e-7
>> k == 4
>> n - k == -1e-7 < 4
>> n >= 0
>> R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
>> so k gets set to
>> n - k == -1e-7
>> which is less than 0, so we return 0. However, as you point out, 1 would be
>> more reasonable and in accordance with the limit as n -> 4, e.g.
>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>> [1] -9.289025e-11
>> I guess that the fix could be as simple as replacing n by R_forceint(n) in
>> the k = n - k step.
>
> I think that would break symmetry: you want choose(n, k) to equal choose(n,
> n-k) when n is very close to an integer. So I'd suggest the replacement
> whenever R_IS_INT(n) is true.
>
But choose() very deliberately ensures that k is integer, so choose(n, n-k) is
ill-defined for non-integer n.
double r, k0 = k;
k = R_forceint(k);
...
if (fabs(k - k0) > 1e-7)
MATHLIB_WARNING2(_("'k' (%.2f) must be integer, rounded to %.0f"), k0,
k);
> Duncan Murdoch
>
>> -pd
>>> On 14 Jan 2020, at 00:33 , Wright, Erik Scott wrote:
>>>
>>> This struck me as incorrect:
>>>
>>>> choose(3.99, 4)
>>> [1] 0.979
>>>> choose(3.999, 4)
>>> [1] 0
>>>> choose(4, 4)
>>> [1] 1
>>>> choose(4.001, 4)
>>> [1] 4
>>>> choose(4.01, 4)
>>> [1] 1.02
>>>
>>> Should base::choose(n, k) check whether n is within machine precision of k
>>> and return 1?
>>>
>>> Thanks,
>>> Erik
>>>
>>> ***
>>> sessionInfo()
>>> R version 3.6.0 beta (2019-04-15 r76395)
>>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>>> Running under: macOS High Sierra 10.13.6
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] choose(n, k) as n approaches k
Yep, that looks wrong (probably want to continue discussion over on R-devel)
I think the culprit is here (in src/nmath/choose.c)
if (k < k_small_max) {
int j;
if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
if (k < 0) return 0.;
if (k == 0) return 1.;
/* else: k >= 1 */
if n is a near-integer, then k can become non-integer and negative. In your
case,
n == 4 - 1e-7
k == 4
n - k == -1e-7 < 4
n >= 0
R_IS_INT(n) = TRUE (relative diff < 1e-7 is allowed)
so k gets set to
n - k == -1e-7
which is less than 0, so we return 0. However, as you point out, 1 would be
more reasonable and in accordance with the limit as n -> 4, e.g.
> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
[1] -9.289025e-11
I guess that the fix could be as simple as replacing n by R_forceint(n) in the
k = n - k step.
-pd
> On 14 Jan 2020, at 00:33 , Wright, Erik Scott wrote:
>
> This struck me as incorrect:
>
>> choose(3.99, 4)
> [1] 0.979
>> choose(3.999, 4)
> [1] 0
>> choose(4, 4)
> [1] 1
>> choose(4.001, 4)
> [1] 4
>> choose(4.01, 4)
> [1] 1.02
>
> Should base::choose(n, k) check whether n is within machine precision of k
> and return 1?
>
> Thanks,
> Erik
>
> ***
> sessionInfo()
> R version 3.6.0 beta (2019-04-15 r76395)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS High Sierra 10.13.6
>
> [[alternative HTML version deleted]]
>
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mean
I think median() behaves as designed: As long as the argument can be ordered,
the "middle observation" makes sense, except when the middle falls between two
categories, and you can't define and average of the two candidates for a median.
The "sick man" would seem to be var(). Notice that it is also inconsistent with
cov():
> cov(c("1","2","3","4"),c("1","2","3","4") )
Error in cov(c("1", "2", "3", "4"), c("1", "2", "3", "4")) :
is.numeric(x) || is.logical(x) is not TRUE
> var(c("1","2","3","4"),c("1","2","3","4") )
[1] 1.67
-pd
> On 9 Jan 2020, at 14:49 , Marc Schwartz via R-devel
> wrote:
>
> Jean-Luc,
>
> Please keep the communications on the list, for the benefit of others, now
> and in the future, via the list archive. I am adding r-devel back here.
>
> I can't speak to the rationale in some of these cases. As I noted, it may be
> (is likely) due to differing authors over time, and there may have been
> relevant use cases at the time that the code was written, resulting in the
> various checks. Presumably, the additional checks were not incorporated into
> the other functions to enforce a level of consistency.
>
> We will need to wait for someone from R Core to comment.
>
> Regards,
>
> Marc
>
>> On Jan 9, 2020, at 8:34 AM, Lipatz Jean-Luc wrote:
>>
>> Ok, inconstencies.
>>
>> The last test you wrote is a bit strange. I agree that it is useful to warn
>> about a computation that have no sense in the case of factors. But why
>> testing data;frames? If you go that way using random structures, you can
>> also try :
>>
>>> median(list(1,2),list(3,4),list(4,5))
>> Error in if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x)))
>> return(x[FALSE][NA]) :
>> l'argument n'est pas interprétable comme une valeur logique
>> De plus : Warning message:
>> In if (na.rm) x <- x[!is.na(x)] else if (any(is.na(x))) return(x[FALSE][NA])
>> :
>> la condition a une longueur > 1 et seul le premier élément est utilisé
>>
>> giving a message which, despite of his length, doesn't really explain the
>> reason of the error.
>>
>> Why not a test on arguments like?
>> if (!is.numeric(x))
>> stop("need numeric data")
>>
>>
>> -Message d'origine-
>> De : Marc Schwartz
>> Envoyé : jeudi 9 janvier 2020 14:19
>> À : Lipatz Jean-Luc
>> Cc : R-Devel
>> Objet : Re: [Rd] mean
>>
>>
>>> On Jan 9, 2020, at 7:40 AM, Lipatz Jean-Luc
>>> wrote:
>>>
>>> Hello,
>>>
>>> Is there a reason for the following behaviour?
>>>> mean(c("1","2","3"))
>>> [1] NA
>>> Warning message:
>>> In mean.default(c("1", "2", "3")) :
>>> l'argument n'est ni numérique, ni logique : renvoi de NA
>>>
>>> But:
>>>> var(c("1","2","3"))
>>> [1] 1
>>>
>>> And also:
>>>> median(c("1","2","3"))
>>> [1] "2"
>>>
>>> But:
>>>> quantile(c("1","2","3"),p=.5)
>>> Error in (1 - h) * qs[i] :
>>> argument non numérique pour un opérateur binaire
>>>
>>> It sounds like a lack of symetry.
>>> Best regards.
>>>
>>>
>>> Jean-Luc LIPATZ
>>> Insee - Direction générale
>>> Responsable de la coordination sur le développement de R et la mise en
>>> oeuvre d'alternatives à SAS
>>
>>
>> Hi,
>>
>> It would appear, whether by design or just inconsistent implementations,
>> perhaps by different authors over time, that the checks for whether or not
>> the input vector is numeric differ across the functions.
>>
>> A further inconsistency is for median(), where:
>>
>>> median(c("1", "2", "3", "4"))
>> [1] NA
>> Warning message:
>> In mean.default(sort(x, partial = half + 0L:1L)[half + 0L:1L]) :
>> argument is not numeric or logical: returning NA
>>
>> as a result of there being 4 elements, rather than 3, and the internal
>> checks in the code, where in the case of the input vector having an even
>> number of elements, mean() is used:
>>
>> if (n%%2L == 1L)
>> sort(x, partial = half)[half]
>> else mean(sort(x, partial = half + 0L:1L)[half + 0L:1L])
>>
>>
>> Similarly:
>>
>>> median(factor(c("1", "2", "3")))
>> Error in median.default(factor(c("1", "2", "3"))) : need numeric data
>>
>> because the input vector is a factor, rather than character, and the initial
>> check has:
>>
>> if (is.factor(x) || is.data.frame(x))
>> stop("need numeric data")
>>
>>
>> Regards,
>>
>> Marc Schwartz
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.6.2 is released
It is possible that this means that it is the intention to port the changes
from R-devel to 3.6.2 patched once 3.6.2 is out. In that case, you can be
pretty sure that the changes are NOT in 3.6.2 (and actually not in 3.6.2
patched either -- yet).
If so, you have provided a nice illustration of why I keep telling people not
to do that...
-pd
> On 12 Dec 2019, at 18:05 , Avraham Adler wrote:
>
> Thank you.
>
> I apologize for not providing the link. [1] Under the news for R-revel there
> is a single entry for R 3.6.2-patched.
>
> The file I downloaded was [2] with a date of 2019-12-12 01:50.
>
> Is it safe to say that 3.6.2 has the LAPACK upgrades and fixes?
>
> Apologies in advance if iOS links the URL below. I cannot access gmail
> desktop from behind my corporate firewall.
>
> Thank you again,
>
> Avi
>
> [1]
> https://cran.r-project.org/doc/manuals/r-devel/NEWS.html
> [2]
> https://stat.ethz.ch/R/daily/R-patched.tar.gz
>
> On Thu, Dec 12, 2019 at 11:10 AM Peter Dalgaard wrote:
> It is not obvious what it is that you are calling "R-patched", nor where
> there could be an entry for "3.6.2 patched".
>
> The prerelease/patched versions are snapshots of R-3-6-branch made at 00:20
> so the current one will have been made before the release version run started
> at 09:00 this morning, and hence the nightly tarball will be of the release
> candidate. However it will not be called R-patched:
>
> lrwxr-xr-x 1 pd staff29 Dec 12 00:20 R-latest.tar.gz ->
> R-rc_2019-12-06_r77555.tar.gz
>
> The current version in SVN differs only by the VERSION file. Its NEWS.Rd
> starts
>
> Peters-MacBook-Air:R pd$ more VERSION
> 3.6.2 Patched
> Peters-MacBook-Air:R pd$ more doc/NEWS.Rd
> % -*- coding: utf-8 -*-
> \newcommand{\Rlogo}{\if{html}{\figure{../../html/Rlogo.svg}{options:
> class="toplogo" alt="[R logo]"}}\if{latex}{\figure{Rlogo.pdf}{options:
> width=0.5in}}}
>
> \name{NEWS}
> \title{R News}
> \encoding{UTF-8}
>
> \section{\Rlogo CHANGES IN R 3.6.2}{
>
> \subsection{NEW FEATURES}{
> \itemize{
>
>
> and any changes for 3.6.2 patched should go above the entries for 3.6.2.
>
> - pd
>
>
> > On 12 Dec 2019, at 16:34 , Avraham Adler wrote:
> >
> > Hi.
> >
> > Under R-news there is an entry for 3.6.2 patched regarding LAPACK. However,
> > when uncompresding the current R-patched, it creates R-Rc directories. Is
> > this a naming oversight or is the patched version actually the unadjusted
> > release candidate?
> >
> > Thank you,
> >
> > Avi
> >
> > On Thu, Dec 12, 2019 at 4:58 AM Peter Dalgaard via R-devel
> > wrote:
> > The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy
> > Night") this morning.
> >
> > The list below details the changes in this release.
> >
> > You can get the source code from
> >
> > http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz
> >
> > or wait for it to be mirrored at a CRAN site nearer to you.
> >
> > Binaries for various platforms will appear in due course.
> >
> >
> > For the R Core Team,
> >
> > Peter Dalgaard
> >
> > These are the checksums (md5 and SHA-256) for the freshly created files, in
> > case you wish
> > to check that they are uncorrupted:
> >
> > MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
> > MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
> > MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
> > MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052
> > MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
> > MD5 (NEWS) = 45437b38c75e0248b527c00e6d42ee6a
> > MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
> > MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
> > MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9
> > MD5 (R-latest.tar.gz) = 90d23d138cee26d275da14b58296e521
> > MD5 (README) = f468f281c919665e276a1b691decbbe6
> > MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
> > MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
> > MD5 (VERSION-INFO.dcf) = 9c33701e25092aefc1d16beb5858f20f
> > MD5 (R-3/R-3.6.2.tar.gz) = 90d23d138cee26d275da14b58296e521
> >
> >
> > 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS
> > e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
> > 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3
> > COPYING.LIB
> > 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ
> > f87461be6cbaecc4dce4
Re: [Rd] R 3.6.2 is released
It is not obvious what it is that you are calling "R-patched", nor where there
could be an entry for "3.6.2 patched".
The prerelease/patched versions are snapshots of R-3-6-branch made at 00:20 so
the current one will have been made before the release version run started at
09:00 this morning, and hence the nightly tarball will be of the release
candidate. However it will not be called R-patched:
lrwxr-xr-x 1 pd staff29 Dec 12 00:20 R-latest.tar.gz ->
R-rc_2019-12-06_r77555.tar.gz
The current version in SVN differs only by the VERSION file. Its NEWS.Rd starts
Peters-MacBook-Air:R pd$ more VERSION
3.6.2 Patched
Peters-MacBook-Air:R pd$ more doc/NEWS.Rd
% -*- coding: utf-8 -*-
\newcommand{\Rlogo}{\if{html}{\figure{../../html/Rlogo.svg}{options:
class="toplogo" alt="[R logo]"}}\if{latex}{\figure{Rlogo.pdf}{options:
width=0.5in}}}
\name{NEWS}
\title{R News}
\encoding{UTF-8}
\section{\Rlogo CHANGES IN R 3.6.2}{
\subsection{NEW FEATURES}{
\itemize{
and any changes for 3.6.2 patched should go above the entries for 3.6.2.
- pd
> On 12 Dec 2019, at 16:34 , Avraham Adler wrote:
>
> Hi.
>
> Under R-news there is an entry for 3.6.2 patched regarding LAPACK. However,
> when uncompresding the current R-patched, it creates R-Rc directories. Is
> this a naming oversight or is the patched version actually the unadjusted
> release candidate?
>
> Thank you,
>
> Avi
>
> On Thu, Dec 12, 2019 at 4:58 AM Peter Dalgaard via R-devel
> wrote:
> The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy Night")
> this morning.
>
> The list below details the changes in this release.
>
> You can get the source code from
>
> http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz
>
> or wait for it to be mirrored at a CRAN site nearer to you.
>
> Binaries for various platforms will appear in due course.
>
>
> For the R Core Team,
>
> Peter Dalgaard
>
> These are the checksums (md5 and SHA-256) for the freshly created files, in
> case you wish
> to check that they are uncorrupted:
>
> MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
> MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
> MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
> MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052
> MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
> MD5 (NEWS) = 45437b38c75e0248b527c00e6d42ee6a
> MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
> MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
> MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9
> MD5 (R-latest.tar.gz) = 90d23d138cee26d275da14b58296e521
> MD5 (README) = f468f281c919665e276a1b691decbbe6
> MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
> MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
> MD5 (VERSION-INFO.dcf) = 9c33701e25092aefc1d16beb5858f20f
> MD5 (R-3/R-3.6.2.tar.gz) = 90d23d138cee26d275da14b58296e521
>
>
> 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS
> e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
> 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
> 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ
> f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
> 0ceb6fbab3e0e29bc374683fd5c2ccd0c9c62ce8eca2a394a4603775b3ef129c NEWS
> 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
> 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1
> ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2
> bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954
> R-latest.tar.gz
> 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
> 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES
> 2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS
> 40cc7cea5f0e67cf8f2f7b25a534ae6bc53f38eae2ab2c2649a952ed37f0654a
> VERSION-INFO.dcf
> bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954
> R-3/R-3.6.2.tar.gz
>
> This is the relevant part of the NEWS file
>
> CHANGES IN R 3.6.2:
>
> NEW FEATURES:
>
> * runmed(x, *) gains a new option na.action determining _how_ to
> handle NaN or NA in x.
>
> * dotchart() gains new options ann, xaxt, frame.plot and log.
>
> INSTALLATION on a UNIX-ALIKE:
>
> * Detection of the C stack direction has been moved from run-time
> to configure: this is safer with LTO builds and allows the
> detection to be overridden - see file config.site.
>
> * Source-code changes enable installation on platforms using gcc
> -fno-common (the expected default for gcc 10.x).
[Rd] R 3.6.2 is released
The build system rolled up R-3.6.2.tar.gz (codename "Dark and Stormy Night") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 45437b38c75e0248b527c00e6d42ee6a MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 90d23d138cee26d275da14b58296e521 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60 MD5 (VERSION-INFO.dcf) = 9c33701e25092aefc1d16beb5858f20f MD5 (R-3/R-3.6.2.tar.gz) = 90d23d138cee26d275da14b58296e521 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 0ceb6fbab3e0e29bc374683fd5c2ccd0c9c62ce8eca2a394a4603775b3ef129c NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS 40cc7cea5f0e67cf8f2f7b25a534ae6bc53f38eae2ab2c2649a952ed37f0654a VERSION-INFO.dcf bd65a45cddfb88f37370fbcee4ac8dd3f1aebeebe47c2f968fd9770ba2bbc954 R-3/R-3.6.2.tar.gz This is the relevant part of the NEWS file CHANGES IN R 3.6.2: NEW FEATURES: * runmed(x, *) gains a new option na.action determining _how_ to handle NaN or NA in x. * dotchart() gains new options ann, xaxt, frame.plot and log. INSTALLATION on a UNIX-ALIKE: * Detection of the C stack direction has been moved from run-time to configure: this is safer with LTO builds and allows the detection to be overridden - see file config.site. * Source-code changes enable installation on platforms using gcc -fno-common (the expected default for gcc 10.x). C-LEVEL FACILITIES: * installTrChar (which is nowadays is wrapped by installChar) is defined in Rinternals.h. (Neither are part of the API.) PACKAGE INSTALLATION: * Header Rconfig.h contains the value of FC_LEN_T deduced at installation which is used by the prototypes in headers R_ext/BLAS.h and R_ext/Lapack.h but to avoid extensive breakage this is only exposed when USE_FC_LEN_T is defined. If a package's C/C++ calls to BLAS/LAPACK allow for the 'hidden' arguments used by most Fortran compilers to pass the lengths of Fortran character arguments, define USE_FC_LEN_T and include Rconfig.h (possibly _via_ R.h) before including R_ext/BLAS.h or R_ext/Lapack.h. * A package with Fortran source code and perhaps C (but not C++) sources can request for its shared object/DLL to be linked by the Fortran compiler by including a line USE_FC_TO_LINK= in src/Makevars[.win] and using $(SHLIB_OPENMP_FFLAGS) as part of PKG_LIBS. The known reason for doing so is a package which uses Fortran (only) OpenMP on a platform where the Fortran OpenMP runtime is incompatible with the C one (e.g. gfortran 9.x with clang). UTILITIES: * R CMD check has a new option to mitigate checks leaving files/directories in /tmp. See the 'R Internals' manual - this is part of --as-cran. Windows: * The default standard for C++ in package installation is C++11 (as it has been on other platforms where available since R 3.6.0: the default toolchain on Windows was defaulting to C++98). DEPRECATED AND DEFUNCT: * Support for specifying C++98 in package installation is deprecated. * Support in R CMD config for F77, FCPIFCPLAGS, CPP, CXXCPP and CXX98 and similar is deprecated. (CPP is found from the system make and may well not be set.) Use $CC -E and $CXX -E instead of CPP and CXXCPP.
Re: [Rd] What should dnorm(0, 0, -Inf) return?
I have committed a fix for r-devel (dnorm only).
-pd
> On 9 Dec 2019, at 08:49 , Martin Maechler wrote:
>
>>>>>> peter dalgaard
>>>>>>on Sun, 8 Dec 2019 12:11:50 +0100 writes:
>
>> Yes, that looks like a bug and an easily fixable one too.
>
> agreed.
>
>> However, I spy another issue: Why do we check the
>> !R_FINITE(x) && mu == x before checking for sd < 0 ? The
>> difference is whether we
>
>> return ML_NAN; or ML_ERR_return_NAN;
>
>> but surely negative sd should always be an error?
>
>> I'd be inclined to do
>
>> if (sigma < 0) ML_ERR_return_NAN;
>> if(!R_FINITE(sigma)) return R_D__0;
>> if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
>> if (sigma == 0)
>> return (x == mu) ? ML_POSINF : R_D__0;
>> x = (x - mu) / sigma;
>
>
>> (Ping Martin...)
>
> I think you are spot on, Peter.
> All of this code has a longish history, with incremental border
> case improvements.
> Let's hope (somewhat unrealistically) this is the last one for
> dnorm().
>
> NB: dlnorm() and some of the gamma/chisq/.. may need a
>similar adjustment
>
> Lastly, regression tests for this
> (either in tests/d-p-q-r-tests.{R,Rout.save}
> or easier in reg-tests-1d.R) should be added too.
>
>> -pd
>
>>> On 7 Dec 2019, at 23:40 , Wang Jiefei wrote:
>>>
>>> Good question, I cannot speak for R's developers but I would like to
>>> provide some information on the problem. Here are the first few lines of
>>> the dnorm function located at src\nmath\dnorm.c:
>>>
>>> ```
>>> double dnorm4(double x, double mu, double sigma, int give_log)
>>> {
>>> #ifdef IEEE_754
>>> if (ISNAN(x) || ISNAN(mu) || ISNAN(sigma))
>>> return x + mu + sigma;
>>> #endif
>>> if(!R_FINITE(sigma)) return R_D__0;
>>> if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
>>> if (sigma <= 0) {
>>> if (sigma < 0) ML_ERR_return_NAN;
>>> /* sigma == 0 */
>>> return (x == mu) ? ML_POSINF : R_D__0;
>>> }
>>>
>>> }
>>> ```
>>>
>>> You can clearly see where the problem is. I think either the document or
>>> the code needs a modification.
>>>
>>> Best,
>>> Jiefei
>>>
>>> On Sat, Dec 7, 2019 at 5:05 PM Weigand, Stephen D. via R-devel <
>>> r-devel@r-project.org> wrote:
>>>
>>>> Hi,
>>>> Apropos of a recent Inf question, I've previously wondered if dnorm "does
>>>> the right thing" with
>>>>
>>>> dnorm(0, 0, -Inf)
>>>>
>>>> which gives zero. Should that be zero or NaN (or NA)?
>>>>
>>>> The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0
>>>> is TRUE, then... is this a bug?
>>>>
>>>> Thank you,
>>>> Stephen
>>>> Rochester, MN USA
>>>>
>>>> __
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> --
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk Priv: pda...@gmail.com
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] What should dnorm(0, 0, -Inf) return?
Yes, that looks like a bug and an easily fixable one too.
However, I spy another issue: Why do we check the !R_FINITE(x) && mu == x
before checking for sd < 0 ? The difference is whether we
return ML_NAN;
or
ML_ERR_return_NAN;
but surely negative sd should always be an error?
I'd be inclined to do
if (sigma < 0) ML_ERR_return_NAN;
if(!R_FINITE(sigma)) return R_D__0;
if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
if (sigma == 0)
return (x == mu) ? ML_POSINF : R_D__0;
x = (x - mu) / sigma;
(Ping Martin...)
-pd
> On 7 Dec 2019, at 23:40 , Wang Jiefei wrote:
>
> Good question, I cannot speak for R's developers but I would like to
> provide some information on the problem. Here are the first few lines of
> the dnorm function located at src\nmath\dnorm.c:
>
> ```
> double dnorm4(double x, double mu, double sigma, int give_log)
> {
> #ifdef IEEE_754
>if (ISNAN(x) || ISNAN(mu) || ISNAN(sigma))
> return x + mu + sigma;
> #endif
>if(!R_FINITE(sigma)) return R_D__0;
>if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
>if (sigma <= 0) {
>if (sigma < 0) ML_ERR_return_NAN;
>/* sigma == 0 */
>return (x == mu) ? ML_POSINF : R_D__0;
>}
>
> }
> ```
>
> You can clearly see where the problem is. I think either the document or
> the code needs a modification.
>
> Best,
> Jiefei
>
> On Sat, Dec 7, 2019 at 5:05 PM Weigand, Stephen D. via R-devel <
> r-devel@r-project.org> wrote:
>
>> Hi,
>> Apropos of a recent Inf question, I've previously wondered if dnorm "does
>> the right thing" with
>>
>> dnorm(0, 0, -Inf)
>>
>> which gives zero. Should that be zero or NaN (or NA)?
>>
>> The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0
>> is TRUE, then... is this a bug?
>>
>> Thank you,
>> Stephen
>> Rochester, MN USA
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] CRAN submission with "possibly unsafe calls" or alternative approach?
I think you may want to rethink the mechanism.
Locked bindings are generally there to allow the compiler to make assumptions
about the type, etc., of objects (or rather: not make assumptions because it
will know what the type is). Unlocking invalidates this and may trigger
recompilation or introduce errors. (There are people who know the details much
better than I do).
I seem to recall that people have come up with ways to set up an environment
which can contain mutable objects of this sort.
-pd
> On 6 Dec 2019, at 10:05 , Rainer M Krug wrote:
>
> Hi
>
> In my package `dmdScheme` I define three variables. Depending on a state in
> the package (a selected metadata schemes) these are set as followed from
> within the package:
>
> ```
> unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
> assign("dmdScheme_example", scheme_example, "package:dmdScheme")
> lockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
>
>
> scheme_raw <- as_dmdScheme_raw(scheme_example)
> unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
> assign("dmdScheme_raw", scheme_raw, "package:dmdScheme")
> lockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
>
>
> scheme <- as_dmdScheme(scheme_raw, keepData = FALSE, checkVersion = FALSE)
> unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
> assign("dmdScheme", scheme, "package:dmdScheme")
> lockBinding("dmdScheme", as.environment("package:dmdScheme”))
> ```
>
> ( See
> https://github.com/Exp-Micro-Ecol-Hub/dmdScheme/blob/b97e7b5ef116476e065aeec1da1050eecbd6adf7/R/scheme_use.R#L37-L49
> )
>
> My reasoning is that I want to lock these variables, as they are essential to
> the functioning of the package.
>
> But I get, probably not surprising, the following NOTE:
>
>
> ```
> * checking R code for possible problems ... NOTE
> Found the following possibly unsafe calls:
> File ‘dmdScheme/R/scheme_use.R’:
> unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
> unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
> unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
> ```
>
> For the submission to CRAN, Can I disregard this note and explain it during
> the submission?
>
> My second question concerns the values itself. I set the variables to NULL in
> the /data folder in the package, but even after they are set as above, the
> valuee in `dmdScheme::dmdScheme` is still NULL:
>
> ```
>> names(dmdScheme)
> [1] "Experiment" "Genus""Treatments" "Measurement"
> [5] "DataExtraction" "DataFileMetaData"
>> names(dmdScheme::dmdScheme)
> NULL
>>
> ```
>
> Is there a way, that I can change the value of dmdScheme::… variables during
> runtime?
>
> Thanks,
>
> Rainer
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Orcid ID: 0000-0002-7490-0066
>
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
>
> Office: +41 (0)44 635 47 64
> Cell: +41 (0)78 630 66 57
> email: rainer.k...@uzh.ch
> rai...@krugs.de
> Skype: RMkrug
>
> PGP: 0x0F52F982
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Fix non-ASCII characters in R packages
Dunno if it helps, but the NOTE is about "checking data", which, as far as I can decipher the code, means that it is looking at datasets in the data/ directory. So I suspect that looking at *.R files is not going to be the right thing to do. -pd > On 2 Dec 2019, at 14:57 , Rafael Pereira wrote: > > Hi all, > > I am trying to update my R package on CRAN but I am being requested to fix > this NOTE: > > checking data for non-ASCII characters ... NOTE Note: found 58 marked > Latin-1 strings > > I have used to code below to identify my scripts that have strings using > non-ASCII characters. The problem is that in most cases these non-ASCII > characters are used in the documentation of functions, so I cannot simply > convert their encoding using iconv() for example > > # Find scripts using non-ASCII characters > f <- list.files(pattern = "*.R", recursive = T) > r <- lapply(f, tools::showNonASCIIfile) > > I've tried (1) reopening and (2) resaving those scripts with UTF-8 > encoding, (3) setting UTF-8 as the default encoding of the project, but > nothing seems to fix this issue. Any suggestions? > > obs. I've posted this question on SO > https://stackoverflow.com/questions/59139923/fix-non-ascii-characters-in-r-packages > > best, > > Rafael Pereira > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] switch to reference counting in R-devel
> On 24 Nov 2019, at 15:30 , Tierney, Luke wrote: > > Baring any unforeseen issues Freudian slip, if ever I saw one.... -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can't build R 3.6.1 or 3.5.3 on Ubuntu 18.04 LTS
Pure guessing, but a frequent way to get the "have libs, still won't build" syndrome on Linux variants is not having installed the corresponding -dev or -devel package. -pd > On 21 Nov 2019, at 19:07 , Saren Tasciyan wrote: > > Hi, > > I am trying to build a more recent version (3.6.1 or 3.5.3) of R on Ubuntu > 18.04 LTS. I have installed build-deps with: > > sudo apt-get build-dep r-base > > and I ran ./configure > > During "make", I get the following error: > > platform.o: In function `do_eSoftVersion': > /home/user/Desktop/R-3.6.1/src/main/platform.c:3129: undefined reference to > `u_getVersion_58' > /home/user/Desktop/R-3.6.1/src/main/platform.c:3130: undefined reference to > `u_versionToString_58' > util.o: In function `resetICUcollator': > /home/user/Desktop/R-3.6.1/src/main/util.c:2025: undefined reference to > `ucol_close_58' > util.o: In function `do_ICUset': > /home/user/Desktop/R-3.6.1/src/main/util.c:2103: undefined reference to > `ucol_close_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2136: undefined reference to > `ucol_setStrength_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2111: undefined reference to > `uloc_setDefault_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2115: undefined reference to > `ucol_open_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2112: undefined reference to > `uloc_setDefault_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2138: undefined reference to > `ucol_setAttribute_58' > util.o: In function `do_ICUget': > /home/user/Desktop/R-3.6.1/src/main/util.c:2161: undefined reference to > `ucol_getLocaleByType_58' > util.o: In function `Rf_Scollate': > /home/user/Desktop/R-3.6.1/src/main/util.c:2219: undefined reference to > `uiter_setUTF8_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2220: undefined reference to > `uiter_setUTF8_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:: undefined reference to > `ucol_strcollIter_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2200: undefined reference to > `uloc_setDefault_58' > /home/user/Desktop/R-3.6.1/src/main/util.c:2203: undefined reference to > `ucol_open_58' > collect2: error: ld returned 1 exit status > Makefile:145: recipe for target 'R.bin' failed > make[3]: *** [R.bin] Error 1 > make[3]: Leaving directory '/home/user/Desktop/R-3.6.1/src/main' > Makefile:137: recipe for target 'R' failed > make[2]: *** [R] Error 2 > make[2]: Leaving directory '/home/user/Desktop/R-3.6.1/src/main' > Makefile:28: recipe for target 'R' failed > make[1]: *** [R] Error 1 > make[1]: Leaving directory '/home/user/Desktop/R-3.6.1/src' > Makefile:60: recipe for target 'R' failed > make: *** [R] Error 1 > > I found some suggestiong related to libicu* libraries, but I have those libs > insalled. > > Any ideas, where this is failing? > > Best, > > SarenT > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.2 scheduled for December 12
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] calls with comment attribute
I think this is spot on. I remember all sorts of silliness when deparsing
expressions while trying to retain comments - comments moving from beginning to
end of loops or vice versa, that sort of thing. It was pretty much impossible
to stick comments into the parse tree and have them come back out in a sensible
position. After the keep.source changes, we didn't use comment() attributes
anymore but print/deparse still acts on them. A peek at gram.y from an early R
version should reveal the mechanism used then.
GB: presumably the comment character was considered part of the comment and
stored with it, which is why it isn't added for printing.
-pd
> On 13 Nov 2019, at 04:15 , William Dunlap via R-devel
> wrote:
>
> I suspect that the parser used it to store comments, including the initial
> "#", before R started using the srcref attribute. (S also stored comments
> in the parse tree.)
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Tue, Nov 12, 2019 at 4:16 PM Duncan Murdoch
> wrote:
>
>> On 12/11/2019 5:01 p.m., William Dunlap via R-devel wrote:
>>> In general R doesn't print the "comment" attribute of an object
>>>> structure(1:3, comment=c("a comment", "another comment"))
>>>[1] 1 2 3
>>> but if the object is a call it prints it in an unusual format
>>>> structure(quote(func(arg)), comment=c("a comment", "another
>> comment"))
>>>a comment
>>>another comment
>>>func(arg)
>>>
>>> What is the rationale for the special treatment of calls?
>>
>> It was there in revision 2 of src/main/deparse.c in 1997. (For those
>> unfamiliar with R history: the current revision of R is 77405. That
>> particular file has been revised 248 times since rev 2.)
>>
>> I suspect either nobody has noticed it before, or nobody had the nerve
>> to touch it.
>>
>> Duncan Murdoch
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] head.matrix can return 1000s of columns -- limit to n or add new argument?
Hmm, the problem I see here is that these implied classes are all inherently
one-off. We also have
> inherits(matrix(1,1,1),"numeric")
[1] FALSE
> is.numeric(matrix(1,1,1))
[1] TRUE
> inherits(1L,"numeric")
[1] FALSE
> is.numeric(1L)
[1] TRUE
and if we start fixing one, we might need to fix all.
For method dispatch, we do have inheritance, e.g.
> foo.numeric <- function(x) x + 1
> foo <- function(x) UseMethod("foo")
> foo(1)
[1] 2
> foo(1L)
[1] 2
> foo(matrix(1,1,1))
[,1]
[1,]2
> foo.integer <- function(x) x + 2
> foo(1)
[1] 2
> foo(1L)
[1] 3
> foo(matrix(1,1,1))
[,1]
[1,]2
> foo(matrix(1L,1,1))
[,1]
[1,]3
but these are not all automatic: "integer" implies "numeric", but "matrix" does
not imply "numeric", much less "integer".
Also, we seem to have a rule that inherits(x, c) iff c %in% class(x), which
would break -- unless we change class(x) to return the whole set of inherited
classes, which I sense that we'd rather not do
-pd
> On 30 Oct 2019, at 12:29 , Martin Maechler wrote:
>
> Note however the following historical quirk :
>
>> sapply(setNames(,1:5), function(K) inherits(array(pi, dim=1:K), "array"))
>1 2 3 4 5
> TRUE FALSE TRUE TRUE TRUE
>
> (Is this something we should consider changing for R 4.0.0 -- to
> have it TRUE also for 2d-arrays aka matrix objects ??)
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] set.seed() in a package
We commit a similar sin in the help pages, e.g. example(set.seed) ; runif(2) example(set.seed) ; runif(2) gives you the same random uniforms both times. (Of course it isn't that much of an issue, since you would rarely be running examples before any serious simulations.) You can fairly easily work around that by saving and restoring .Random.seed. I wonder if that isn't also true of the cases using set.seed() for other reasons? -pd > On 30 Oct 2019, at 13:46 , Duncan Murdoch wrote: > > On 30/10/2019 3:28 a.m., Marvin Wright wrote: >> Hi all, >> I recently found several calls of set.seed() in a CRAN package. These calls >> are in a plot function, which could lead to unexpected behaviour. See >> https://github.com/sammo3182/interplot/issues/33 >> <https://github.com/sammo3182/interplot/issues/33> for a description of the >> problem. >> I checked the CRAN repository policies and could not find anything about >> this. I would have expected a policy against setting fixed seeds somewhere >> in a package. Am I missing something? > > set.seed() writes .Random.seed in the user's global environment, which > violates this policy: > > - Packages should not modify the global environment (user’s workspace). > > However, every call to a random number generator creates or modifies > .Random.seed as well, and most of those are expected and shouldn't be > flagged. And interplot() is documented to do random simulations, so it would > be expected to change the seed: the issue is that given the same inputs it > always changes it to the same thing. I think that would be quite hard for a > test to detect. > > Should it be a policy with no test? Maybe, because I agree with you that > interplot()'s set.seed(324) is bad practice. > > Duncan Murdoch > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange "no-echo" in place of "slave"
The first of Suharno's examples can be viewed that way, because R under ESS is not a "slave" in the technical sense, just a situation where you do not want keyboard input to be echoed. "Non-echoing" might have been better language though. The 2nd example really is of the master/slave variety, and to my knowledge nothing to do with echoing, so looks like a search-and-replace oversight. Presumably, "worker thread" (or thereabouts) would be a better replacement. -pd > On 6 Oct 2019, at 14:00 , Gabriel Becker wrote: > > As far as I know, not being involved with the effort at all, they are > removing the term 'slave' and replacing it with 'no-echo' which is intended > to be fully synonmyous with the meaning of the old 'slave' term. > > ~G > > On Sun, Oct 6, 2019 at 10:56 PM suharto_anggono--- via R-devel < > r-devel@r-project.org> wrote: > >> SVN revision replaces "slave" with "no-echo" in R devel. >> >> >> In each of the following, "no-echo" is rather strange to me. >> >> - src/gnuwin32/README.Rterm >> 3) As a no-echo process for ESS mode in NTEmacs with flag --ess. >> >> - src/library/grDevices/src/qdCocoa.m >> /* the no-echo thread work until this is NO */ >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Building fails with 'mypackage/DESCRIPTION' does not exist
Is it really called "mypackage"? Otherwise I'd first check that it is spelled the same way in all cases... Another possibility is that the embedded spaces in the pathname is doing you in. -pd > On 30 Sep 2019, at 16:31 , Steve Gutreuter wrote: > > I have a package which will no longer build after minor changes. The > problem occurs under both Windows 10 and Linux Mint. For example, from a > Windows terminal I do: > > C:\Users\xyz\OneDrive - ORG\Computing\Devel> R CMD build screenr > > and I get: > > * checking for file 'mypackage/DESCRIPTION' ... OK > * preparing 'mypackage': > * checking DESCRIPTION meta-information ... OK > * installing the package to process help pages > * saving partial Rd database > Error in .read_description(ldpath) : > file 'mypackage/DESCRIPTION' does not exist > Execution halted > > So the first and third lines of output contradict the error message, and of > course mypackage/DESCRIPTION does exist. I suspect the problem has nothing > to do with the DESCRIPTION file, but have not found way to identify the > actual problem in searches on StackOverflow and elsewhere. My .R files in > mypackage/R contain Roxygen comments, and curiously devtools::document() > adds nothing to mypackage/man. > > Any suggestions about how to debug or solve this problem? > > Thanks! > Steve > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] script translation - good practice?
Yes. Check out https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses and also note that CC-BY is not recommended as a software license (by CC themselves). As there is one-way compatibility, it should be possible to clarify the situation by putting your derivative work under the GPL. Although not legally required, it would probably be good manners to inform the original authors. -pd > On 18 Sep 2019, at 14:20 , Raphael Bonnet > wrote: > > Thank you Peter for your response, > > It looks ok for the license. The journal's content appears to be under this > license: > https://creativecommons.org/licenses/by/3.0/ > > Raphael > > Le 18/09/2019 à 14:11, peter dalgaard a écrit : >> Not a lawyer, but... >> >> I would expect that it depends on what license it was published under >> originally. If it doesn't explicitly allow the creation of derivative works, >> then I would be wary. >> >> -pd >> >>> On 18 Sep 2019, at 13:59 , Raphael Bonnet >>> wrote: >>> >>> Hi everyone, >>> >>> I just rewrote a bit of Matlab code into R and that I would like to make it >>> available for the community. >>> Unfortunately this bit of code has been published by authors that I've >>> never contacted. >>> >>> I was wondering if I could submit a package to CRAN by keeping the same >>> license as the journal in which the code was published and citing the paper >>> and the authors. >>> Can I associate myself as [cre, trl] in the description file? >>> >>> Thanks, >>> Raphael >>> >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] script translation - good practice?
Not a lawyer, but... I would expect that it depends on what license it was published under originally. If it doesn't explicitly allow the creation of derivative works, then I would be wary. -pd > On 18 Sep 2019, at 13:59 , Raphael Bonnet > wrote: > > Hi everyone, > > I just rewrote a bit of Matlab code into R and that I would like to make it > available for the community. > Unfortunately this bit of code has been published by authors that I've never > contacted. > > I was wondering if I could submit a package to CRAN by keeping the same > license as the journal in which the code was published and citing the paper > and the authors. > Can I associate myself as [cre, trl] in the description file? > > Thanks, > Raphael > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] ?Syntax wrong about `?`'s precedence ?
...and 14955, which seems to have the explanation (but was marked as
closed/fixed??). The parser does list '?' as lower precedence than '=', but
'='-assignments are not normal 'expr's which can appear as arguments to '?'.
(Presumably because of named arguments: f(a=b) differs from f(a<-b).)
Other tokens which have lower precedence than assignments are flow-control
items, IF ELSE WHILE FOR REPEAT, but I don't see any way to confuse them in the
same way as '?'.
It might be possible to resolve the situation by specifying '?' syntax
explicitly as
expr_or_assign '?' expr_or_assign, but, well, "There be Tygers here"...
-pd
> On 30 Aug 2019, at 18:32 , Kevin Ushey wrote:
>
> See also: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16710
>
> On Fri, Aug 30, 2019 at 9:02 AM William Dunlap via R-devel
> wrote:
>>
>> Precedence is a property of the parser and has nothing to do with the
>> semantics assigned to various symbols. Using just core R functions you can
>> see the precedence of '?' is between those of '=' and '<-'.
>>
>>> # '=' has lower precedence than '?'
>>> str(as.list(parse(text="a ? b = c")[[1]]))
>> List of 3
>> $ : symbol =
>> $ : language `?`(a, b)
>> $ : symbol c
>>> str(as.list(parse(text="a = b ? c")[[1]]))
>> List of 3
>> $ : symbol =
>> $ : symbol a
>> $ : language `?`(b, c)
>>> # '<-' has higher precedence than '?'
>>> str(as.list(parse(text="a ? b <- c")[[1]]))
>> List of 3
>> $ : symbol ?
>> $ : symbol a
>> $ : language b <- c
>>> str(as.list(parse(text="a <- b ? c")[[1]]))
>> List of 3
>> $ : symbol ?
>> $ : language a <- b
>> $ : symbol c
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>>
>> On Fri, Aug 30, 2019 at 4:41 AM Stephen Ellison
>> wrote:
>>
>>>> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Ant F
>>>> Sent: 29 August 2019 12:06
>>>> To: r-devel@r-project.org
>>>> Subject: [Rd] ?Syntax wrong about `?`'s precedence ?
>>>> ...
>>>> See the following example :
>>>>
>>>>`?` <- `+`
>>>
>>> I'm curious; What did you expect to happen if you replace the function '?'
>>> with the operator '+' ?
>>> ? is surely now being evaluated as a user-defined function and not as an
>>> operator.
>>> Would you expect the results of doing that to be the same as evaluation
>>> without replacement?
>>>
>>> S Ellison
>>>
>>>
>>>
>>>
>>> ***
>>> This email and any attachments are confidential. Any u...{{dropped:10}}
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Misspelled words in DESCRIPTION
I'd write "PK/PD" though. Or did the world change while I was looking the other way? -pd > On 20 Aug 2019, at 00:42 , John Harrold wrote: > > Yeah that's it. Thanks Uwe and Ben. > > On Mon, Aug 19, 2019 at 3:21 PM Ben Bolker wrote: > >> >> I suspect the NOTE said something about "*possibly* misspelled words" >> (emphasis added). This should be OK; just put the explanation below in >> your notes to CRAN about the submission, clarifying that this is indeed >> a false positive. >> >> cheers >>Ben Bolker >> >> On 2019-08-19 6:13 p.m., John Harrold wrote: >>> Hello, >>> >>> I am attempting to submit my first package to CRAN. I believe I've >>> successfully gotten rid of all the notes, but there is one that I'm >> unable >>> to eliminate. In the DESCRIPTION file in both the Title and Description >>> fields I use the term PKPD. This stands for Pharmacokinetics and >>> Pharmacodynamics. It seems that none of these are recognized as words >> that >>> are spelled correctly. They are kind of important in the context of the >>> package and there are no other better or more accurate descriptors that I >>> can use. >>> >>> Is there a way to get around this? >>> >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > > -- > John > :wq > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Appetite for eliminating dependency on Perl
Dunno about runtime. We used to have much more - all the Rdconv stuff used to be based on pattern matching by Perl scripts, but they were converted to R scripts and later to use proper parsers. For building, if you ever need to regenerate a configure script or write your own for a package, notice that aclocal & friends are Perl scripts. -pd > On 9 Aug 2019, at 00:37 , Ken Williams wrote: > > Preamble: I am in no way opposed to Perl in general - I love Perl and > probably always will. > > R currently has Perl as both a build-time and run-time dependency. This > adds about 200 Mb, give or take, to the required environment size (as > measured in CentOS - looks like it might be a bit smaller in Ubuntu?). > > Not such a huge deal, really, but the actual benefit R gets from the > dependency is quite small. From my poking around in the R sources (using > `git grep -P '\bperl\b(?! ?= ?(?:TRUE|FALSE))' ` as a filter), it looks > like it's only used in the following nooks & crannies: > > * tools/help2man.pl > * tools/install-info.pl > * configure: INSTALL_INFO="perl \$(top_srcdir)/tools/install-info.pl" > * m4/R.m4: INSTALL_INFO="perl \$(top_srcdir)/tools/install-info.pl" > > Ultimately that's only two scripts. `help2man.pl` seems like it's part of > the build process, but not used at runtime. `install-info.pl` seems like > maybe it's runnable at runtime, but requires user initiation to run, at > which point the user is expected to have perl installed. Either one of > them could probably be ported to another language pretty easily, maybe even > R. > > Anything else I missed? > > If someone were to volunteer the porting work, would there be any appetite > for eliminating the dependency? > > -Ken > > [[alternative HTML version deleted]] > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Potential bug in update.formula when updating offsets
Terry, Martin Would this happen to be related to the "indexing term objects" issue that has been bothering you? -pd > On 5 Aug 2019, at 21:44 , Paul Buerkner wrote: > > Hi all, > > update.formula does not seem to correctly update (i.e. remove in my case) > offset terms. > > Here is an example: > > update(~x + offset(z), ~ . - offset(z)) >> ~x + offset(z) > > Also: > update(~x, ~ . - offset(z)) >> ~x + offset(z) > > In both cases, I would expect the result >> ~x > > as - should remove from the formula as happens for instance > in: > > update(~x + z, ~ . - z) >> ~x > > I don't know if this behavior is intentional but I would say it is at least > unfortunate. > > Paul > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN down ?
The latter pd@cran:~$ uptime 19:37:51 up 0 min, 2 users, load average: 4.80, 1.30, 0.44 > On 5 Jul 2019, at 19:37 , peter dalgaard wrote: > > Hum, I could reach the machine once: > > $ ssh cran.r-project.org > > The programs included with the Debian GNU/Linux system are free software; > > > but now it hangs on connecting. So either it is being DOS'ed or someone saw > the problem and restarted it. > > -pd > > >> On 5 Jul 2019, at 18:45 , Dirk Eddelbuettel wrote: >> >> >> There seems to be another outage of the Vienna CRAN server [1] though from >> what I can from afar not related to DNS outage [2]. >> >> Could anyone confirm and possibly alert the local team in Vienna? >> >> Dirk >> >> [1] https://twitter.com/d_olivaw/status/1147161883797086214 >> [2] The DNS resolves on a few sites but eg simple pings stall >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> >> ______ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > > > > > > > > > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN down ?
Hum, I could reach the machine once: $ ssh cran.r-project.org The programs included with the Debian GNU/Linux system are free software; but now it hangs on connecting. So either it is being DOS'ed or someone saw the problem and restarted it. -pd > On 5 Jul 2019, at 18:45 , Dirk Eddelbuettel wrote: > > > There seems to be another outage of the Vienna CRAN server [1] though from > what I can from afar not related to DNS outage [2]. > > Could anyone confirm and possibly alert the local team in Vienna? > > Dirk > > [1] https://twitter.com/d_olivaw/status/1147161883797086214 > [2] The DNS resolves on a few sites but eg simple pings stall > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.1 is released
The build system rolled up R-3.6.1.tar.gz (codename "Action of the Toes") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 0b9e5d3077558ec2d91d39e03bfb2ad5 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = f5003472d58a3d3765a1c537fdae71d5 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 08158353102084599797db8c9ccf8e2a MD5 (VERSION-INFO.dcf) = ff3f371396553df4e1936c10a56d973d MD5 (R-3/R-3.6.1.tar.gz) = f5003472d58a3d3765a1c537fdae71d5 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL dd2ff3bc1e94c9751aed4182da7ed381bb546535bdf61f33b033474067c85c7c NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 5baa9ebd3e71acecdcc3da31d9042fb174d55a42829f8315f2457080978b1389 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2d2e85e85574c4430951f6b070c08cd5aff1602abfd1bb162bed6d89c436b11f THANKS 20cf23c12614c5d9e8f9b3983005a35c8bac4c7340db4d7911afe05ca0688e07 VERSION-INFO.dcf 5baa9ebd3e71acecdcc3da31d9042fb174d55a42829f8315f2457080978b1389 R-3/R-3.6.1.tar.gz This is the relevant part of the NEWS file CHANGES IN R 3.6.1: INSTALLATION on a UNIX-ALIKE: * The default detection of the shell variable libNN is overridden for derivatives of Debian Linux, some of which have started to have a /usr/lib64 directory. (E.g. Ubuntu 19.04.) As before, it can be specified in config.site. UTILITIES: * R CMD config knows the values of AR and RANLIB, often set for LTO builds. DEPRECATED AND DEFUNCT: * The use of a character vector with .Fortran() is formally deprecated and gives a non-portability warning. (It has long been strongly discouraged in 'Writing R Extensions'.) BUG FIXES: * On Windows, GUI package installation via menuInstallPkgs() works again, thanks to Len Weil's and Duncan Murdoch's PR#17556. * R CMD check on data() fixing PR#17558 thanks to Duncan Murdoch. * quasi(*, variance = list(..)) now works more efficiently, and should work in all cases fixing PR#17560. Further, quasi(var = mu(1-mu)) and quasi(var = "mu ^ 3") now work, and quasi(variance = "log(mu)") now gives a correct error message. * Creation of lazy loading database during package installation is again robust to Rprofile changing the current working directory (PR#17559). * boxplot(y ~ f, horizontal=TRUE) now produces correct x- and y-labels. * rbind.data.frame() allows to keep levels from factor columns (PR#17562) via new option factor.exclude. Additionally, it works in one more case with matrix-columns which had been reported on 2017-01-16 by Krzysztof Banas. * Correct messaging in C++ pragma checks in tools code for R CMD check, fixing PR#17566 thanks to Xavier Robin. * print()ing and auto-printing no longer differs for functions with a user defined print.function, thanks to Bill Dunlap's report. * On Windows, writeClipboard(.., format = ) now does correctly pass format to the underlying C code, thanks to a bug report (with patch) by Jenny Bryan. * as.data.frame() treats 1D arrays the same as vectors, PR#17570. * Improvements in smoothEnds(x, *) working with NAs (towards runmed() working in that case, in the next version of R). * vcov(glm(), dispersion = *) works correctly again, fixing PR#17571 thanks to Pavel Krivitsky. * R CMD INSTALL of binary packages on Windows now works also with per-directory locking. * R CMD INSTALL and install.packages() on Windows are
Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error
> On 28 Jun 2019, at 16:03 , Martin Maechler wrote:
>
>>>>>> Henrik Bengtsson
>>>>>>on Thu, 27 Jun 2019 16:00:39 -0700 writes:
>
>> Using:
>>
>> untrace(methods::conformMethod)
>> at <- c(12,4,3,2)
>> str(body(methods::conformMethod)[[at]])
>> ## language omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>> cc <- 0L
>> trace(methods::conformMethod, tracer = quote({
>> cc <<- cc + 1L
>> print(cc)
>> if (cc == 31) { ## manually identified
>>untrace(methods::conformMethod)
>>trace(methods::conformMethod, at = list(at), tracer = quote({
>> str(list(signature = signature, mnames = mnames, fnames = fnames))
>> print(ls())
>> try(str(list(omittedSig = omittedSig, signature = signature)))
>>}))
>> }
>> }))
>> loadNamespace("oligo")
>>
>> gives:
>>
>> Untracing function "conformMethod" in package "methods"
>> Tracing function "conformMethod" in package "methods"
>> Tracing conformMethod(signature, mnames, fnames, f, fdef, definition)
>> step 12,4,3,2
>> List of 3
>> $ signature: Named chr [1:4] "TilingFeatureSet" "ANY" "ANY" "array"
>> ..- attr(*, "names")= chr [1:4] "object" "subset" "target" "value"
>> ..- attr(*, "package")= chr [1:4] "oligoClasses" "methods" "methods"
>> "methods"
>> $ mnames : chr [1:2] "object" "value"
>> $ fnames : chr [1:4] "object" "subset" "target" "value"
>> [1] "f" "fdef" "fnames" "fsig" "imf"
>> [6] "method" "mnames" "omitted""omittedSig" "sig0"
>> [11] "sigNames" "signature"
>> List of 2
>> $ omittedSig: logi [1:4] FALSE TRUE TRUE FALSE
>> $ signature : Named chr [1:4] "TilingFeatureSet" "ANY" "ANY" "array"
>> ..- attr(*, "names")= chr [1:4] "object" "subset" "target" "value"
>> ..- attr(*, "package")= chr [1:4] "oligoClasses" "methods" "methods"
>> "methods"
>> Error in omittedSig && (signature[omittedSig] != "missing") :
>> 'length(x) = 4 > 1' in coercion to 'logical(1)'
>> Error: unable to load R code in package 'oligo'
>>
>
> Thank you, Henrik, nice piece of using trace() .. and the above
> is useful for solving the issue -- I can work with that.
>
> I'm already pretty sure the wrong code starts with
>
>omittedSig <- sigNames %in% fnames[omitted] #
>
> -
>
I think the intention must have been that the two "ANY" signatures should
change to "missing". However, with the current logic that will not happen,
because
> c(F,T,T,F) && c(T,T)
[1] FALSE
Henrik's non-fix would have resulted in
> c(F,T,T,F) & c(T,T)
[1] FALSE TRUE TRUE FALSE
which is actually right, but only coincidentally due to recycling of c(T,T).
Had it been c(F,T) then it would have been expanded to c(F,T,F,T) which would
be the opposite of what was wanted.
Barring NA issues, I still think
omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
should do the trick.
-pd
>
> *Still* I cannot understand why in my case (and probably Peter,
> as he also said he can't reproduce),
> the conformMethod() function is not even called when I run
> loadNamespace("oligo").
>
> As conformMethod() is *only* called from setMethod(), I've
> started trace()ing setMethod() and indeed, it is *only* called one,
> and not with oligo methods/generics,...
>
> Henrik, do you per chance not install packages in the usual way,
> i.e., do you install them without saving all the pre-computed
> classes and methods tables etc,
> and that would be *why* these setMethod() etc are only called at
> this point in time ?
>
> Martin
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error
Henrik,
If a minimal reprex is hard to construct, could you perhaps instrument your
version of R to include a browser() call at the start of the
else if(!all(signature[omittedSig] == "missing")) {
branch, run the code that triggers the issue for you (and must hit that branch)
and tell us what the "signature" and "omittedSig" objects look like at that
point?
Bonus points for figuring out why it is needed to use numerical indexing in
omittedSig <- seq_along(omittedSig)[omittedSig]
signature[omittedSig] <- "missing" # logical index will extend
signature!
(I'm sure there is a valid reason, I just don't get it...)
-pd
> On 25 Jun 2019, at 09:44 , peter dalgaard wrote:
>
> Argh! Yes you are right, the "fix" doesn't. And I fell into the same "hey
> it's a vector so && has to be wrong"-trap. So this has to be reverted to
> something that has at least failed unconspicuously for a decade Will do.
> Thanks to Martin for remaining suspicious!
>
> [This code was originally from 2009, by John Chambers. It is not too likely
> that he'll remember what the intention actually was... The logic does escape
> me: An omitted signature is only an omitted signature if the signature of the
> omitted signature is not "missing"? In that case, I think
>
> omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
>
> might work (omittedSig[omittedSig] == TRUE, so we don't need to &. That is,
> unless there are NA issues.), but I am not at all sure that is what is wanted!
> ]
>
> -pd
>
>> On 25 Jun 2019, at 07:16 , Henrik Bengtsson
>> wrote:
>>
>> **Maybe this bug needs to be understood further before applying the
>> patch because patch is most likely also wrong**
>>
>> Because, from just looking at the expressions, I think neither the R
>> 3.6.0 version:
>>
>> omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>>
>> nor the patched version (I proposed):
>>
>> omittedSig <- omittedSig & (signature[omittedSig] != "missing")
>>
>> can be correct. For a starter, 'omittedSig' is a logical vector. We
>> see that 'omittedSig' is used to subset 'signature'. In other words,
>> the length of 'signature[omittedSig]' and hence the length of
>> '(signature[omittedSig] != "missing")' will equal sum(omittedSig),
>> i.e. the length will be in {0,1,...,length(omittedSig)}.
>>
>> The R 3.6.0 version with '&&' is not correct because '&&' requires
>> length(omittedSig) == 1L and sum(omittedSig) == 1L, which is unlikely
>> to be the original intention.
>>
>> The patched version with '&' is most likely not correct either because
>> 'LHS & RHS' assume length(LHS) == length(RHS), unless it relies on the
>> auto-expansion of either vector. So, for the '&' version to be
>> correct, it basically requires that length(omittedSig) = length(LHS) =
>> length(RHS) = sum(omittedSig), which also sounds unlikely to be the
>> original intention.
>>
>> Disclaimer: Please note that I have not at all studied the rest of the
>> function, so the above is just based on that single line plus
>> debugging that 'omittedSig' is a logical vector.
>>
>> Martin, I don't have the time to dive into this further. Though I did
>> try to see if it happened when one of oligo's dependencies were
>> loaded, but that was not the case. It kicks in when oligo is loaded.
>> FYI, I can also replicate your non-replicatation on another R 3.6.0
>> version. I'll see if I can narrow down what's different, e.g.
>> comparing sessionInfo():s, etc. However, I want to reply with
>> findings above asap due to the R 3.6.1 release and you might roll back
>> the patch (since it might introduce other bugs as Peter mentioned).
>>
>> /Henrik
>>
>>
>> On Mon, Jun 24, 2019 at 3:05 AM Martin Maechler
>> wrote:
>>>
>>>>>>>> Henrik Bengtsson via R-core
>>>>>>>> on Sun, 23 Jun 2019 11:29:58 -0700 writes:
>>>
>>>> Thank you.
>>>> To correct myself, I can indeed reproduce this with R --vanilla too.
>>>> A reproducible example is:
>>>
>>>> $ R --vanilla
>>>> R version 3.6.0 Patched (2019-05-31 r76629) -- "Planting of a Tree"
>>>> ...
>>>>> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
>>>>> loadNamespace("oligo")
>>>> Error in omittedSig && (signatur
Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error
Ah, not quite: The logic is that if something has omittedSig and "missing" is
not the signature, those signatures get _set_ to missing. There's just a bit of
tap-dancing around to find exactly which they are so that there can be a
message about changing them.
-pd
> On 25 Jun 2019, at 09:44 , peter dalgaard wrote:
>
> Argh! Yes you are right, the "fix" doesn't. And I fell into the same "hey
> it's a vector so && has to be wrong"-trap. So this has to be reverted to
> something that has at least failed unconspicuously for a decade Will do.
> Thanks to Martin for remaining suspicious!
>
> [This code was originally from 2009, by John Chambers. It is not too likely
> that he'll remember what the intention actually was... The logic does escape
> me: An omitted signature is only an omitted signature if the signature of the
> omitted signature is not "missing"? In that case, I think
>
> omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
>
> might work (omittedSig[omittedSig] == TRUE, so we don't need to &. That is,
> unless there are NA issues.), but I am not at all sure that is what is wanted!
> ]
>
> -pd
>
>> On 25 Jun 2019, at 07:16 , Henrik Bengtsson
>> wrote:
>>
>> **Maybe this bug needs to be understood further before applying the
>> patch because patch is most likely also wrong**
>>
>> Because, from just looking at the expressions, I think neither the R
>> 3.6.0 version:
>>
>> omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>>
>> nor the patched version (I proposed):
>>
>> omittedSig <- omittedSig & (signature[omittedSig] != "missing")
>>
>> can be correct. For a starter, 'omittedSig' is a logical vector. We
>> see that 'omittedSig' is used to subset 'signature'. In other words,
>> the length of 'signature[omittedSig]' and hence the length of
>> '(signature[omittedSig] != "missing")' will equal sum(omittedSig),
>> i.e. the length will be in {0,1,...,length(omittedSig)}.
>>
>> The R 3.6.0 version with '&&' is not correct because '&&' requires
>> length(omittedSig) == 1L and sum(omittedSig) == 1L, which is unlikely
>> to be the original intention.
>>
>> The patched version with '&' is most likely not correct either because
>> 'LHS & RHS' assume length(LHS) == length(RHS), unless it relies on the
>> auto-expansion of either vector. So, for the '&' version to be
>> correct, it basically requires that length(omittedSig) = length(LHS) =
>> length(RHS) = sum(omittedSig), which also sounds unlikely to be the
>> original intention.
>>
>> Disclaimer: Please note that I have not at all studied the rest of the
>> function, so the above is just based on that single line plus
>> debugging that 'omittedSig' is a logical vector.
>>
>> Martin, I don't have the time to dive into this further. Though I did
>> try to see if it happened when one of oligo's dependencies were
>> loaded, but that was not the case. It kicks in when oligo is loaded.
>> FYI, I can also replicate your non-replicatation on another R 3.6.0
>> version. I'll see if I can narrow down what's different, e.g.
>> comparing sessionInfo():s, etc. However, I want to reply with
>> findings above asap due to the R 3.6.1 release and you might roll back
>> the patch (since it might introduce other bugs as Peter mentioned).
>>
>> /Henrik
>>
>>
>> On Mon, Jun 24, 2019 at 3:05 AM Martin Maechler
>> wrote:
>>>
>>>>>>>> Henrik Bengtsson via R-core
>>>>>>>> on Sun, 23 Jun 2019 11:29:58 -0700 writes:
>>>
>>>> Thank you.
>>>> To correct myself, I can indeed reproduce this with R --vanilla too.
>>>> A reproducible example is:
>>>
>>>> $ R --vanilla
>>>> R version 3.6.0 Patched (2019-05-31 r76629) -- "Planting of a Tree"
>>>> ...
>>>>> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
>>>>> loadNamespace("oligo")
>>>> Error in omittedSig && (signature[omittedSig] != "missing") :
>>>> 'length(x) = 4 > 1' in coercion to 'logical(1)'
>>>> Error: unable to load R code in package ‘oligo’
>>>
>>>> /Henrik
>>>
>>> Thank you Henrik, for the report, etc, but
>>> hmm... after loading the oligo package, almost 40 (non
>>> base+Recommended) packages have been loaded as well, which
Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error
Argh! Yes you are right, the "fix" doesn't. And I fell into the same "hey it's
a vector so && has to be wrong"-trap. So this has to be reverted to something
that has at least failed unconspicuously for a decade Will do. Thanks to
Martin for remaining suspicious!
[This code was originally from 2009, by John Chambers. It is not too likely
that he'll remember what the intention actually was... The logic does escape
me: An omitted signature is only an omitted signature if the signature of the
omitted signature is not "missing"? In that case, I think
omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
might work (omittedSig[omittedSig] == TRUE, so we don't need to &. That is,
unless there are NA issues.), but I am not at all sure that is what is wanted!
]
-pd
> On 25 Jun 2019, at 07:16 , Henrik Bengtsson
> wrote:
>
> **Maybe this bug needs to be understood further before applying the
> patch because patch is most likely also wrong**
>
> Because, from just looking at the expressions, I think neither the R
> 3.6.0 version:
>
> omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>
> nor the patched version (I proposed):
>
> omittedSig <- omittedSig & (signature[omittedSig] != "missing")
>
> can be correct. For a starter, 'omittedSig' is a logical vector. We
> see that 'omittedSig' is used to subset 'signature'. In other words,
> the length of 'signature[omittedSig]' and hence the length of
> '(signature[omittedSig] != "missing")' will equal sum(omittedSig),
> i.e. the length will be in {0,1,...,length(omittedSig)}.
>
> The R 3.6.0 version with '&&' is not correct because '&&' requires
> length(omittedSig) == 1L and sum(omittedSig) == 1L, which is unlikely
> to be the original intention.
>
> The patched version with '&' is most likely not correct either because
> 'LHS & RHS' assume length(LHS) == length(RHS), unless it relies on the
> auto-expansion of either vector. So, for the '&' version to be
> correct, it basically requires that length(omittedSig) = length(LHS) =
> length(RHS) = sum(omittedSig), which also sounds unlikely to be the
> original intention.
>
> Disclaimer: Please note that I have not at all studied the rest of the
> function, so the above is just based on that single line plus
> debugging that 'omittedSig' is a logical vector.
>
> Martin, I don't have the time to dive into this further. Though I did
> try to see if it happened when one of oligo's dependencies were
> loaded, but that was not the case. It kicks in when oligo is loaded.
> FYI, I can also replicate your non-replicatation on another R 3.6.0
> version. I'll see if I can narrow down what's different, e.g.
> comparing sessionInfo():s, etc. However, I want to reply with
> findings above asap due to the R 3.6.1 release and you might roll back
> the patch (since it might introduce other bugs as Peter mentioned).
>
> /Henrik
>
>
> On Mon, Jun 24, 2019 at 3:05 AM Martin Maechler
> wrote:
>>
>>>>>>> Henrik Bengtsson via R-core
>>>>>>>on Sun, 23 Jun 2019 11:29:58 -0700 writes:
>>
>>> Thank you.
>>> To correct myself, I can indeed reproduce this with R --vanilla too.
>>> A reproducible example is:
>>
>>> $ R --vanilla
>>> R version 3.6.0 Patched (2019-05-31 r76629) -- "Planting of a Tree"
>>> ...
>>>> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
>>>> loadNamespace("oligo")
>>> Error in omittedSig && (signature[omittedSig] != "missing") :
>>> 'length(x) = 4 > 1' in coercion to 'logical(1)'
>>> Error: unable to load R code in package ‘oligo’
>>
>>> /Henrik
>>
>> Thank you Henrik, for the report, etc, but
>> hmm... after loading the oligo package, almost 40 (non
>> base+Recommended) packages have been loaded as well, which hence
>> need to have been installed before, too ..
>> which is not quite a "vanilla repr.ex." in my view
>>
>> Worse, I cannot reproduce :
>>
>>> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
>>> Sys.getenv("_R_CHECK_LENGTH_1_LOGIC2_")
>>[1] "true"
>>> debugonce(conformMethod)
>>> loadNamespace("oligo")
>>
>>Warning messages:
>>1: multiple methods tables found for ‘rowSums’
>>2: multiple methods tables found for ‘colSums’
>>3: multiple methods tables found for ‘rowMeans’
>>4: multiple methods tables found for ‘colM
Re: [Rd] Calculation of e^{z^2/2} for a normal deviate z
You may want to look into using the log option to qnorm
e.g., in round figures:
> log(1e-300)
[1] -690.7755
> qnorm(-691, log=TRUE)
[1] -37.05315
> exp(37^2/2)
[1] 1.881797e+297
> exp(-37^2/2)
[1] 5.314068e-298
Notice that floating point representation cuts out at 1e+/-308 or so. If you
want to go outside that range, you may need explicit manipulation of the log
values. qnorm() itself seems quite happy with much smaller values:
> qnorm(-5000, log=TRUE)
[1] -99.94475
-pd
> On 21 Jun 2019, at 17:11 , jing hua zhao wrote:
>
> Dear Rui,
>
> Thanks for your quick reply -- this allows me to see the bottom of this. I
> was hoping we could have a handle of those p in genmoics such as 1e-300 or
> smaller.
>
> Best wishes,
>
>
> Jing Hua
>
>
> From: Rui Barradas
> Sent: 21 June 2019 15:03
> To: jing hua zhao; r-devel@r-project.org
> Subject: Re: [Rd] Calculation of e^{z^2/2} for a normal deviate z
>
> Hello,
>
> Well, try it:
>
> p <- .Machine$double.eps^seq(0.5, 1, by = 0.05)
> z <- qnorm(p/2)
>
> pnorm(z)
> # [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12
> # [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16
> #[11] 1.110223e-16
> p/2
> # [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12
> # [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16
> #[11] 1.110223e-16
>
> exp(z*z/2)
> # [1] 9.184907e+06 5.301421e+07 3.073154e+08 1.787931e+09 1.043417e+10
> # [6] 6.105491e+10 3.580873e+11 2.104460e+12 1.239008e+13 7.306423e+13
> #[11] 4.314798e+14
>
>
> p is the smallest possible such that 1 + p != 1 and I couldn't find
> anything to worry about.
>
>
> R version 3.6.0 (2019-04-26)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 19.04
>
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
>
> locale:
> [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
> [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
> [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods
> [7] base
>
> other attached packages:
>
> [many packages loaded]
>
>
> Hope this helps,
>
> Rui Barradas
>
> �s 15:24 de 21/06/19, jing hua zhao escreveu:
>> Dear R-developers,
>>
>> I am keen to calculate exp(z*z/2) with z=qnorm(p/2) and p is very small. I
>> wonder if anyone has experience with this?
>>
>> Thanks very much in advance,
>>
>>
>> Jing Hua
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.6.1 scheduled for July 5
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Increasing number of observations worsen the regression model
Yes, it is important that it only happens with certan BLAS, so probably not really an R issue. However, there has been some concern over the C/Fortran interfaces lately, so if you could narrow it down to a specific BLAS routine, it could prove useful for the developers. One fairly easy thing to do would be to find the breakdown point. I speculate that it could be at 16384 (=2^14) and that some sort of endianness or integer width declaration is the cause. (It would in turn suggest that MKL is using 16-bit integers somehow, which doesn't really seem credible, but you never know.) I'm moving this to the r-devel list. It certainly is not for r-help. -pd > On 27 May 2019, at 10:47 , Ivan Krylov wrote: > > On Sat, 25 May 2019 14:38:07 +0200 > Raffa wrote: > >> I have tried to ask for example in CrossValidated >> <https://stats.stackexchange.com/questions/410050/increasing-number-of-observations-worsen-the-regression-model> >> >> but the code works for them. Any help? > > In the comments you note that the problem went away after you replaced > Intel MKL with OpenBLAS. This is important. > > The code that fits linear models in R is somewhat complex[*]; if > you want to get to the bottom of the problem, you may have to take > parts of it and feed them differently-sized linear regression problems > until you narrow it down to a specific set of calls to BLAS or LAPACK > functions which Intel MKL provides. > > One option would be to ask at Intel MKL forums[**]. > > -- > Best regards, > Ivan > > [*] > https://madrury.github.io/jekyll/update/statistics/2016/07/20/lm-in-R.html > > [**] https://software.intel.com/en-us/forums/intel-math-kernel-library/ > > __ > r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R problems with lapack with gfortran
The point is that LAPACK uses characters as control arguments in multiple places and we don't write the LAPACK Fortran routines. It has long been known that general character strings was a portability issue but many (not just R people) have thought that length-one character were safe to pass as char* pointers. So "avoid" is not really an option if we want to use LAPACK functionality at all. Workarounds/solutions include: - disable certain optimizations -- works for now, but doesn't remove the root cause so seems generally fragile - "onion-skin" all LAPACK routines to call via a Fortran routine that converts integer arguments to the required character -- possible, but it adds overhead and there are hundreds of routines (and it would be kind of ugly!). - modify LAPACK itself similarly -- requires naming change of routines as per the license, and there are still hundreds of routines; avoids overhead, but creates maintenance nightmare to keep up with changes in LAPACK - change all prototypes and calls to follow gfortran calling conventions -- still a lot of work since each char* arguments need to be supplemented by a length going at the end of the arglist. If gfortran was the only compiler around, I'd say this would be the least painful route, but still no fun since it requires changes to a lot of user code (in packages too). It is not clear if this approach works with other Fortrans. - figure out Fortran2003 specification for C/Fortran interoperability -- this _sounds_ like the right solution, but I don't think many understand how to use it and what is implied (in particular, will it require making changes to LAPACK itself?) - move towards the LAPACKE C interface -- but that also adds onionskin overhead and ultimately calls Fortran in essentially the same way as R does, so doesn't really solve anything at all (unless we can shift responsibility for sorting things out onto the LAPACK team, but I kind of expect that they do not want it.) - twist the arms of the gfortran team to do something that keeps old code working. Compiler engineers understandably hate that sort of thing, but I seem to recall some precedent (pointer alignment, back in the dark ages?). -pd > On 4 May 2019, at 16:49 , Berend Hasselman wrote: > > Hi, Thomas, Tomas, > > Doesn't this issue demonstrate the warning and advice given in the last > paragraph of section 6.6 > of the "Writing R Extensions" manual: > > > Passing character strings from C to Fortran or vice versa is not portable > (and to Fortran 90 or later is even less so). We have found that it helps to > ensure that a C string to be passed is followed by several nuls (and not just > the one needed as a C terminator). But for maximal portability character > strings in Fortran should be avoided. > > > Avoid. > > Berend > >> On 3 May 2019, at 19:25, Thomas König wrote: >> >> Hi Tomas, >> >> thanks a lot for your analysis. I have created >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 >> for this, and put you in CC (if your e-mail address >> for GCC bugzilla is still current). >> >> Regards >> >> Thomas >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R optim(method="L-BFGS-B"): unexpected behavior when working with parent environments
Yes, I think you are right. I was at first confused by the fact that after the
optim() call,
> environment(fn)$xx
[1] 10
> environment(fn)$ret
[1] 100.02
so not 9.999, but this could come from x being assigned the final value without
calling fn.
-pd
> On 3 May 2019, at 11:58 , Duncan Murdoch wrote:
>
> Your results below make it look like a bug in optim(): it is not duplicating
> a value when it should, so changes to x affect xx as well.
>
> Duncan Murdoch
>
> On 03/05/2019 4:41 a.m., Serguei Sokol wrote:
>> On 03/05/2019 10:31, Serguei Sokol wrote:
>>> On 02/05/2019 21:35, Florian Gerber wrote:
>>>> Dear all,
>>>>
>>>> when using optim() for a function that uses the parent environment, I
>>>> see the following unexpected behavior:
>>>>
>>>> makeFn <- function(){
>>>> xx <- ret <- NA
>>>> fn <- function(x){
>>>> if(!is.na(xx) && x==xx){
>>>> cat("x=", xx, ", ret=", ret, " (memory)", fill=TRUE, sep="")
>>>> return(ret)
>>>> }
>>>> xx <<- x; ret <<- sum(x^2)
>>>> cat("x=", xx, ", ret=", ret, " (calculate)", fill=TRUE, sep="")
>>>> ret
>>>> }
>>>> fn
>>>> }
>>>> fn <- makeFn()
>>>> optim(par=10, fn=fn, method="L-BFGS-B")
>>>> # x=10, ret=100 (calculate)
>>>> # x=10.001, ret=100.02 (calculate)
>>>> # x=9.999, ret=100.02 (memory)
>>>> # $par
>>>> # [1] 10
>>>> #
>>>> # $value
>>>> # [1] 100
>>>> # (...)
>>>>
>>>> I would expect that optim() does more than 3 function evaluations and
>>>> that the optimization converges to 0.
>>>>
>>>> Same problem with optim(par=10, fn=fn, method="BFGS").
>>>>
>>>> Any ideas?
>>> I don't have an answer but may be an insight. For some mysterious
>>> reason xx is getting changed when in should not. Consider:
>>>> fn=local({n=0; xx=ret=NA; function(x) {n <<- n+1; cat(n, "in
>>> x,xx,ret=", x, xx, ret, "\n"); if (!is.na(xx) && x==xx) ret else {xx
>>> <<- x; ret <<- x**2; cat("out x,xx,ret=", x, xx, ret, "\n"); ret}}})
>>>> optim(par=10, fn=fn, method="L-BFGS-B")
>>> 1 in x,xx,ret= 10 NA NA
>>> out x,xx,ret= 10 10 100
>>> 2 in x,xx,ret= 10.001 10 100
>>> out x,xx,ret= 10.001 10.001 100.02
>>> 3 in x,xx,ret= 9.999 9.999 100.02
>>> $par
>>> [1] 10
>>>
>>> $value
>>> [1] 100
>>>
>>> $counts
>>> function gradient
>>>11
>>>
>>> $convergence
>>> [1] 0
>>>
>>> $message
>>> [1] "CONVERGENCE: NORM OF PROJECTED GRADIENT <= PGTOL"
>>>
>>> At the third call, xx has value 9.999 while it should have kept the
>>> value 10.001.
>>>
>> A little follow-up: if you untie the link between xx and x by replacing
>> the expression "xx <<- x" by "xx <<- x+0" it works as expected:
>> > fn=local({n=0; xx=ret=NA; function(x) {n <<- n+1; cat(n, "in
>> x,xx,ret=", x, xx, ret, "\n"); if (!is.na(xx) && x==xx) ret else {xx <<-
>> x+0; ret <<- x**2; cat("out x,xx,ret=", x, xx, ret, "\n"); ret}}})
>> > optim(par=10, fn=fn, method="L-BFGS-B")
>> 1 in x,xx,ret= 10 NA NA
>> out x,xx,ret= 10 10 100
>> 2 in x,xx,ret= 10.001 10 100
>> out x,xx,ret= 10.001 10.001 100.02
>> 3 in x,xx,ret= 9.999 10.001 100.02
>> out x,xx,ret= 9.999 9.999 99.98
>> 4 in x,xx,ret= 9 9.999 99.98
>> out x,xx,ret= 9 9 81
>> 5 in x,xx,ret= 9.001 9 81
>> out x,xx,ret= 9.001 9.001 81.018
>> 6 in x,xx,ret= 8.999 9.001 81.018
>> out x,xx,ret= 8.999 8.999 80.982
>> 7 in x,xx,ret= 1.776357e-11 8.999 80.982
>> out x,xx,ret= 1.776357e-11 1.776357e-11 3.155444e-22
>> 8 in x,xx,ret= 0.001 1.776357e-11 3.155444e-22
>> out x,xx,ret= 0.001 0.001 1e-06
>> 9 in x,xx,ret= -0.001 0.001 1e-06
>> out x,xx,ret= -0.001 -0.001 1e-06
>> 10 in x,xx,ret= -1.334475e-23 -0.001 1e-06
>> out x,xx,ret= -1.334475e-23 -1.334475e-23 1.780823e-46
>> 11 in x,xx,ret= 0.001 -1.334475e-23 1.780823e-46
>> out x,xx,ret= 0.001 0.001 1e-06
>> 12 in x,xx,ret= -0.001 0.001 1e-06
>> out x,xx,ret= -0.001 -0.001 1e-06
>> $par
>> [1] -1.334475e-23
>> $value
>> [1] 1.780823e-46
>> $counts
>> function gradient
>> 44
>> $convergence
>> [1] 0
>> $message
>> [1] "CONVERGENCE: NORM OF PROJECTED GRADIENT <= PGTOL"
>> Serguei.
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
OK, this is now in R-devel, but only superficially tested (b/c this is a Mac).
Please check it out.
-pd
> On 30 Apr 2019, at 23:09 , Paul Murrell wrote:
>
> Hi Peter
>
> Yes, that looks roughly right to me. I would be in favour of your option
> (b), partly because it is probably easiest and partly because that retains
> the basic graphics device startup logic pattern that is replicated across
> all(?) graphics devices.
>
> Paul
>
> On 28/04/19 11:39 AM, peter dalgaard wrote:
>> I had a look at the current code, and AFAICT it has essentially the same
>> structure as it did back then. I think it may have finally dawned upon me
>> what the issue really is:
>> The logic is that in Rf_addX11Device, we have
>> if (!X11DeviceDriver(dev, display, width, height,
>> ps, gamma, colormodel, maxcubesize,
>> bgcolor, canvascolor, sfonts, res,
>> xpos, ypos, title, useCairo, antialias,
>> family)) {
>> free(dev);
>> errorcall(call, _("unable to start device %s"), devname);
>> }
>> dd = GEcreateDevDesc(dev);
>> GEaddDevice2(dd, devname);
>> i.e., we start the device driver, and if it fails, we throw away the "dev"
>> structure and call it a day. If it succeeds, we proceed to create a device
>> descriptor structure and add it to the list of open devices.
>> This approach means that X11DeviceDriver() cannot do anything that
>> potentially accesses the dd structure because it isn't there yet, and the
>> things it cannot do apparently includes calling R_ProcessX11Events(). [To be
>> completely sure that this is actually still true, I'd need to have a closer
>> look at what handleEvent() does.]
>> So to fix things, it would seem that you could (a) add the device before
>> attempting to start the driver, preparing to back it out if the driver fails
>> to start, or (b) add a call to R_ProcessX11Events() _after_ the
>> GEaddDevice2(dd, devname). Option (b) is probably the easiest.
>> Paul: Does this analysis look roughly right?
>> -pd
>>> On 26 Apr 2019, at 01:23 , frede...@ofb.net wrote:
>>>
>>> Thanks Professor Dalgard.
>>>
>>> If you have a different way to fix the bug then I'd be happy to test
>>> it.
>>>
>>> Or whatever. I understand that maybe some data was being referenced
>>> before it had been initialized. I could also support moving the
>>> R_ProcessEvents call in another place, but it seems one would also
>>> like to generate some kind of warning message, at the location of the
>>> bad reference, rather than segfaulting. Was it not possible to
>>> identify this location? I'm guessing that Valgrind is a bit more
>>> mature now than it was in 2001...?
>>>
>>> Frederick
>>>
>>> On Wed, Apr 24, 2019 at 03:12:55PM +0200, peter dalgaard wrote:
>>>> OK, so I did the archaeology anyway
>>>>
>>>>
>>>> This was the story, R-core November 29, 2001. Part of thread "X11 still
>>>> segfaults".
>>>>
>>>> >>
>>>> .
>>>> Gah. I've been too tired today. Why did that take me so long?
>>>>
>>>> The culprit seems to be
>>>>
>>>> R_ProcessEvents((void*) NULL)
>>>>
>>>> in newX11DeviceDriver
>>>>
>>>> This gets called *before* this stuff at the end of Rf_addX11Device
>>>>
>>>>dd = GEcreateDevDesc(dev);
>>>>addDevice((DevDesc*) dd);
>>>>initDisplayList((DevDesc*) dd);
>>>>
>>>> and it is that "dd" that gets called by Rf_playDisplayList. Removing
>>>> the offending line stops the segfaulting, seemingly with no ill
>>>> effects.
>>>>
>>>> I'm not really sure what the use of that line ever was; it might be
>>>> necessary to make the call somewhere later, but it appears to have
>>>> been possible to race past it before receiving any events all the
>>>> time.
>>>>
>>>> I also changed a couple of spots missing dd->newDevStruct=1
>>>>
>>>> Will commit in a moment.
>>>> <<
>>>>
>>>> And the following day, in "graphics saga part III", we had
>>>>
>>>> ->>
>>>> ...
>>>>
>>>> I can't ma
Re: [R-pkg-devel] Whack-a-mole base::assign(".ptime", proc.time(), pos = "CheckExEnv")
That line is a generic part of the timing (it records current time so that at
the end you can do what amounts to "Time used:" proc.time() - .ptime).
It is not likely to contain the actual error -- notice that the message just
gives you a best guess of the error location and that may fail. You probably
need to have a look at the actual radsafer-Ex.R file and its output to find the
true culprit.
If you have catastrophic failures, yes, you see them only one at a time.
-pd
> On 30 Apr 2019, at 03:16 , Mark Hogue wrote:
>
> (The subject title is in reference to the arcade game where fake mole heads
> pop up and the contestant is challenged to smash them down as more and more
> keep popping up.)
>
> I made some changes to a package and when I run the R CMD check, I get one
> error with this lead-in notification:
>
> Running examples in 'radsafer-Ex.R' failed
> The error most likely occurred in:
> *base::assign(".ptime", proc.time(), pos = "CheckExEnv")*
>
> When I do something with the affected function, I get a similar error on
> another function.
>
> Could it have something to do with my having added argument checks on these
> functions? Could someone advise where to go to understand this error
> better? And is it normal to get only one error at a time like this?
>
> Thanks,
>
> Mark
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
I had a look at the current code, and AFAICT it has essentially the same
structure as it did back then. I think it may have finally dawned upon me what
the issue really is:
The logic is that in Rf_addX11Device, we have
if (!X11DeviceDriver(dev, display, width, height,
ps, gamma, colormodel, maxcubesize,
bgcolor, canvascolor, sfonts, res,
xpos, ypos, title, useCairo, antialias, family)) {
free(dev);
errorcall(call, _("unable to start device %s"), devname);
}
dd = GEcreateDevDesc(dev);
GEaddDevice2(dd, devname);
i.e., we start the device driver, and if it fails, we throw away the "dev"
structure and call it a day. If it succeeds, we proceed to create a device
descriptor structure and add it to the list of open devices.
This approach means that X11DeviceDriver() cannot do anything that potentially
accesses the dd structure because it isn't there yet, and the things it cannot
do apparently includes calling R_ProcessX11Events(). [To be completely sure
that this is actually still true, I'd need to have a closer look at what
handleEvent() does.]
So to fix things, it would seem that you could (a) add the device before
attempting to start the driver, preparing to back it out if the driver fails to
start, or (b) add a call to R_ProcessX11Events() _after_ the GEaddDevice2(dd,
devname). Option (b) is probably the easiest.
Paul: Does this analysis look roughly right?
-pd
> On 26 Apr 2019, at 01:23 , frede...@ofb.net wrote:
>
> Thanks Professor Dalgard.
>
> If you have a different way to fix the bug then I'd be happy to test
> it.
>
> Or whatever. I understand that maybe some data was being referenced
> before it had been initialized. I could also support moving the
> R_ProcessEvents call in another place, but it seems one would also
> like to generate some kind of warning message, at the location of the
> bad reference, rather than segfaulting. Was it not possible to
> identify this location? I'm guessing that Valgrind is a bit more
> mature now than it was in 2001...?
>
> Frederick
>
> On Wed, Apr 24, 2019 at 03:12:55PM +0200, peter dalgaard wrote:
>> OK, so I did the archaeology anyway
>>
>>
>> This was the story, R-core November 29, 2001. Part of thread "X11 still
>> segfaults".
>>
>> >>
>> .
>> Gah. I've been too tired today. Why did that take me so long?
>>
>> The culprit seems to be
>>
>> R_ProcessEvents((void*) NULL)
>>
>> in newX11DeviceDriver
>>
>> This gets called *before* this stuff at the end of Rf_addX11Device
>>
>> dd = GEcreateDevDesc(dev);
>> addDevice((DevDesc*) dd);
>> initDisplayList((DevDesc*) dd);
>>
>> and it is that "dd" that gets called by Rf_playDisplayList. Removing
>> the offending line stops the segfaulting, seemingly with no ill
>> effects.
>>
>> I'm not really sure what the use of that line ever was; it might be
>> necessary to make the call somewhere later, but it appears to have
>> been possible to race past it before receiving any events all the
>> time.
>>
>> I also changed a couple of spots missing dd->newDevStruct=1
>>
>> Will commit in a moment.
>> <<
>>
>> And the following day, in "graphics saga part III", we had
>>
>> ->>
>> ...
>>
>> I can't make it happen in 1.3.1 but...
>>
>> It is probably not unrelated to the R_ProcessEvents line that
>> I took out, but that was definitely wrong. However, one might reenable
>> it if one could change this bit of code
>>
>> if (!(ptr_X11DeviceDriver)((DevDesc*)(dev), display, width, height, ps,
>> gamma,
>>colormodel, maxcubesize, canvascolor)) {
>> free(dev);
>> errorcall(gcall, "unable to start device %s", devname);
>> }
>> gsetVar(install(".Device"), mkString(devname), R_NilValue);
>> dd = GEcreateDevDesc(dev);
>> addDevice((DevDesc*) dd);
>> initDisplayList((DevDesc*) dd);
>>
>>
>> and put the if-clause last. A cursory clance through the three
>> functions that are being called didn't reveal anything that would rely
>> on having opened the device driver first.
>>
>> Paul?
>>
>> (I might try it locally, but I'm not sure I should commit anything.)
>>
>> <<---
>>
>> It seems that the suggestion was never followed up on?
>>
>
[Rd] R 3.6.0 is released
The build system rolled up R-3.6.0.tar.gz (codename "Planting of a Tree") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 28a3942a7129877e9af1d5ea16202052 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 6d227865440cc1ece3d97bdf4a8ee41e MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 65601eac6d353f7efb5b48c29097c2fb MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 08158353102084599797db8c9ccf8e2a MD5 (VERSION-INFO.dcf) = 97d5e3df5e5ac56750695e4b49145fae MD5 (R-3/R-3.6.0.tar.gz) = 65601eac6d353f7efb5b48c29097c2fb 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 38219d9c6221ccfbf075ef03711b420a1aa8731f890c8f2337148b602a217c2d FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 184dfa18e3069782d1092b289a6fe6ef85feb951cd4d1566b225c746d29a5420 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 36fcac3e452666158e62459c6fc810adc247c7109ed71c5b6c3ad5fc2bf57509 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2d2e85e85574c4430951f6b070c08cd5aff1602abfd1bb162bed6d89c436b11f THANKS 05bd1202b132c8e91a8887d923fcc525cfb3bf81c67847d15876b88bf0c68a71 VERSION-INFO.dcf 36fcac3e452666158e62459c6fc810adc247c7109ed71c5b6c3ad5fc2bf57509 R-3/R-3.6.0.tar.gz This is the relevant part of the NEWS file CHANGES IN R 3.6.0: SIGNIFICANT USER-VISIBLE CHANGES: * Serialization format version 3 becomes the default for serialization and saving of the workspace (save(), serialize(), saveRDS(), compiler::cmpfile()). Serialized data in format 3 cannot be read by versions of R prior to version 3.5.0. Serialization format version 2 is still supported and can be selected by version = 2 in the save/serialization functions. The default can be changed back for the whole R session by setting environment variables R_DEFAULT_SAVE_VERSION and R_DEFAULT_SERIALIZE_VERSION to 2. For maximal back-compatibility, files vignette.rds and partial.rdb generated by R CMD build are in serialization format version 2, and resave by default produces files in serialization format version 2 (unless the original is already in format version 3). * The default method for generating from a discrete uniform distribution (used in sample(), for instance) has been changed. This addresses the fact, pointed out by Ottoboni and Stark, that the previous method made sample() noticeably non-uniform on large populations. See PR#17494 for a discussion. The previous method can be requested using RNGkind() or RNGversion() if necessary for reproduction of old results. Thanks to Duncan Murdoch for contributing the patch and Gabe Becker for further assistance. The output of RNGkind() has been changed to also return the 'kind' used by sample(). NEW FEATURES: * Sys.setFileTime() has been vectorized so arguments path and time of length greater than one are now supported. * axis() gets new option gap.axis = NA for specifying a multiplication factor for the minimal "gap" (distance) between axis labels drawn. Its default is 1 for labels _parallel_ to the axis, and 0.25 for perpendicular ones. Perpendicular labels no longer overlap, fixing bug PR#17384. * The default method of plot() gains new arguments xgap.axis = NA and ygap.axis = NA to be passed to the x- and y- axis(.., gap.axis=*) calls. * removeSource() now works not only for functions but also for some language objects. * as.call(), rep.int(), rep_len() and nchar() dispatch internally. * is(object, class2) looks for class2 in the calling namespace after looking in the namespace of class(object). * extendrange(.., f) with a length-2 f no
Re: [Rd] Bug in "stats4" package - "confint" method
Yep, I know. Well, maybe I didn't, but there are also issues with propagation
of fixedness in constrained optimization.
Revising mle() had neen on my todo list for way too long. The bbmle package
handles this better, I believe.
-pd
> On 24 Apr 2019, at 16:51 , Stefano de Pretis wrote:
>
> Dear R developers,
>
> I noticed a bug in the stats4 package, specifically in the confint method
> applied to “mle” objects.
> In particular, when some “fixed” parameters define the log likelihood, these
> parameters are stored within the mle object but they are not used by the
> “confint" method, which retrieves their value from the global environment
> (whenever they still exist).
>
> Sample code:
>
>> ## Avoid printing to unwarranted accuracy
>> od <- options(digits = 5)
>> x <- 0:10
>> y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
>>
>> ## Easy one-dimensional MLE:
>> nLL <- function(lambda, y) -sum(stats::dpois(y, lambda, log = TRUE))
>> fit0 <- mle(nLL, start = list(lambda = 5), fixed=list(y=y), nobs = NROW(y))
>> confint(fit0)
> Profiling...
> 2.5 % 97.5 %
> 9.6524 13.6716
>> rm(y)
>> confint(fit0)
> Profiling...
> Error in eval(expr, p) : object 'y' not found
>
> In this sample code, I’m showing that after the removal of y from the global
> environment the method ‘confint’ is not able anymore to act on the object
> ‘fit0’.
>
> This retrieval from the global environment is actually dangerous because it’s
> silent and in case the user changes the value of ‘y’ for another purpose the
> method ‘confint’ will return a wrong evaluation of the confidence interval
> without throwing any warning.
>
> I suggest to use the fixed values that are already contained within the mle
> object:
>
>> fit0@fullcoef[grep('y', names(fit0@fullcoef))]
> y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11
> 26 17 13 12 20 5 9 8 5 4 8
>
> Additionally, the method ‘coef’ returns both the coefficient and the fixed
> parameters - while should return only the parameters - , while the ‘fullcoef’
> method is not implemented - while present in the documentation of 'mle-class’.
>
> Best,
> Stefano
>
> Center for Genomic Science of IIT@SEMM
>
> Stefano de Pretis, PhD
> Postdoctoral fellow
> stefano.depre...@iit.it <mailto:stefano.depre...@iit.it>
> Via Adamello 16, 20139 Milan, Italy
> <http://maps.google.it/maps?q=Via+Adamello+16,+20139+Milan=utf-8=firefox-a=UTF8==Via+Adamello,+16,+20139+Milano,+Lombardia=it=16>
> t: +39 02 94375046
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
OK, so I did the archaeology anyway
This was the story, R-core November 29, 2001. Part of thread "X11 still
segfaults".
>>
.
Gah. I've been too tired today. Why did that take me so long?
The culprit seems to be
R_ProcessEvents((void*) NULL)
in newX11DeviceDriver
This gets called *before* this stuff at the end of Rf_addX11Device
dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);
and it is that "dd" that gets called by Rf_playDisplayList. Removing
the offending line stops the segfaulting, seemingly with no ill
effects.
I'm not really sure what the use of that line ever was; it might be
necessary to make the call somewhere later, but it appears to have
been possible to race past it before receiving any events all the
time.
I also changed a couple of spots missing dd->newDevStruct=1
Will commit in a moment.
<<
And the following day, in "graphics saga part III", we had
->>
...
I can't make it happen in 1.3.1 but...
It is probably not unrelated to the R_ProcessEvents line that
I took out, but that was definitely wrong. However, one might reenable
it if one could change this bit of code
if (!(ptr_X11DeviceDriver)((DevDesc*)(dev), display, width, height, ps,
gamma,
colormodel, maxcubesize, canvascolor)) {
free(dev);
errorcall(gcall, "unable to start device %s", devname);
}
gsetVar(install(".Device"), mkString(devname), R_NilValue);
dd = GEcreateDevDesc(dev);
addDevice((DevDesc*) dd);
initDisplayList((DevDesc*) dd);
and put the if-clause last. A cursory clance through the three
functions that are being called didn't reveal anything that would rely
on having opened the device driver first.
Paul?
(I might try it locally, but I'm not sure I should commit anything.)
<<---
It seems that the suggestion was never followed up on?
-pd
> On 24 Apr 2019, at 11:42 , peter dalgaard wrote:
>
> I don't recall exactly what I did 18 years ago eiher and I likely don't have
> the time to dig into the archives and reconstruct.
>
> I can imagine that the issue had to do with the protocol around creating and
> mapping windows. Presumably the segfault comes from looking for events on a
> window that hasn't been created yet, or has already been destroyed, leading
> to a NULL reference somewhere. I have a vague recollection that the issue was
> window manager dependent (in 2001 probably not twm, more likely xvwm on
> RedHat if it was affecting me).
>
> A proper fix should go via proper understanding of the X11 protocol -
> uncommenting a line is as bad as commenting it in the 1st place So more
> like "wait for window to exist THEN process events" -- but the 1st part may
> be WM specific, etc.
>
> I recall docs being quite obtuse, and the X11 "mechanism not policy" credo
> doesn't help as WMs are not obliged to (say) send notifications, so you can
> end up stalling, waiting for events that never happen.
>
> It is entirely possible that there is stuff in here that I didn't understand
> properly at the time, and still don't!
>
> - pd
>
>> On 24 Apr 2019, at 02:30 , Paul Murrell wrote:
>>
>> Hi
>>
>> Sorry, I can't offer an explanation for the commented-out line.
>> However, regarding your final question of avoiding the R-core bottleneck,
>> you do have the option of creating a third-party graphics device package.
>> See, for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does
>> that provide you with a way forward ?
>>
>> Paul
>>
>> On 20/04/2019 5:27 p.m., frede...@ofb.net wrote:
>>> Dear R Devel,
>>>
>>> I know that someone put this line in src/modules/X11/devX11.c:2824 for
>>> a reason, because commenting it out causes R to miss an important
>>> ConfigureNotify event in my window manager. The result is that plots
>>> are initially drawn off the window borders, unreadable.
>>>
>>> R_ProcessX11Events((void*) NULL);
>>>
>>> Unfortunately for me, this line is commented in the standard release
>>> of R, it has "#if BUG ... #endif" around it.
>>>
>>> I guess it is also unfortunate for anyone who uses the same window
>>> manager as I do, namely i3, which I think is pretty popular among Unix
>>> power users these days; not to mention other full-screen window
>>> managers which probably exhibit the same bug in R.
>>>
>>> Maybe everyone on the Core team uses twm as their window manager? Or
>>> RStudio on Windows? Which
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
I don't recall exactly what I did 18 years ago eiher and I likely don't have the time to dig into the archives and reconstruct. I can imagine that the issue had to do with the protocol around creating and mapping windows. Presumably the segfault comes from looking for events on a window that hasn't been created yet, or has already been destroyed, leading to a NULL reference somewhere. I have a vague recollection that the issue was window manager dependent (in 2001 probably not twm, more likely xvwm on RedHat if it was affecting me). A proper fix should go via proper understanding of the X11 protocol - uncommenting a line is as bad as commenting it in the 1st place So more like "wait for window to exist THEN process events" -- but the 1st part may be WM specific, etc. I recall docs being quite obtuse, and the X11 "mechanism not policy" credo doesn't help as WMs are not obliged to (say) send notifications, so you can end up stalling, waiting for events that never happen. It is entirely possible that there is stuff in here that I didn't understand properly at the time, and still don't! - pd > On 24 Apr 2019, at 02:30 , Paul Murrell wrote: > > Hi > > Sorry, I can't offer an explanation for the commented-out line. > However, regarding your final question of avoiding the R-core bottleneck, you > do have the option of creating a third-party graphics device package. See, > for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does that > provide you with a way forward ? > > Paul > > On 20/04/2019 5:27 p.m., frede...@ofb.net wrote: >> Dear R Devel, >> >> I know that someone put this line in src/modules/X11/devX11.c:2824 for >> a reason, because commenting it out causes R to miss an important >> ConfigureNotify event in my window manager. The result is that plots >> are initially drawn off the window borders, unreadable. >> >>R_ProcessX11Events((void*) NULL); >> >> Unfortunately for me, this line is commented in the standard release >> of R, it has "#if BUG ... #endif" around it. >> >> I guess it is also unfortunate for anyone who uses the same window >> manager as I do, namely i3, which I think is pretty popular among Unix >> power users these days; not to mention other full-screen window >> managers which probably exhibit the same bug in R. >> >> Maybe everyone on the Core team uses twm as their window manager? Or >> RStudio on Windows? Which would be sad because then we're not >> representing an important user demographic, namely those who prefer >> software which is modern and powerful, yet simple to understand and >> modify; fully configurable and interoperable and so on. >> >> I first reported this bug 3 years ago. In doing research for my bug >> report, I found that the line was commented out by Peter Dalgaard in >> 2001 with the explanation "X11 segfault fix - I hope". >> >> I don't know what the way forward is. Obviously the Core Team has >> reason to say, "look, this isn't very important, it's been broken >> since 2001, maybe fixing it will cause the undocumented segfault bug >> to reappear, clearly no one here uses your window manager". Do I have >> to submit a correctness proof for the proposed change? What do I do? >> >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702 >> >> As mentioned in my bug report, I checked using gdb that >> ConfigureNotify is indeed being received by the call to >> R_ProcessX11Events() when it is uncommented. I haven't experienced any >> segfaults. >> >> It's good that Peter left evidence that "R_ProcessX11Events" was being >> called 18 years ago from X11DeviceDriver(). If he had deleted the >> line, rather than commenting it, then discovering the reason for the >> window rendering bug would have been much harder for me. >> >> However, the downside is that now it is not just a matter of inserting >> the line where it belongs; I also feel a bit like I have to explain >> why it was initially removed. But although I've given it some thought, >> I still have no idea. >> >> Somewhat tangentially, I am wondering if there is some way that we >> could make the development of R's graphics code proceed at a faster >> rate, for example by pulling it out into a separate module, so that >> people could offer alternative implementations via CRAN etc., rather >> than having R Core be the bottleneck. Would this make sense? Has it >> already been done? >> >> Thank you, >> >> Frederick >> >> ______ >> R-devel@r-proj
Re: [R-pkg-devel] dtrti2 error on CRAN checks
Kurt Hornik submitted a bug report to the gfortran maintainers yesterday, and yes, it seems to have a lot to do with this. He and Brian Ripley have been able to pinpoint it to certain gfortran revisions (specifically gfortran-9 at least r268992, or gfortran-8 at least r269349), but we're lacking a simple test case. -pd > On 18 Apr 2019, at 07:53 , Benjamin Christoffersen wrote: > > Thanks for the quick reply. First a correction. I meant Ubuntu 18.04.2 > of course, sorry. > >> In short, you need to look more closely. > Is there a way to tell which BLAS and LAPACK is used on the Debian > machines on CRAN? I checked the "CRAN Package Check Flavors" page but > there is no information there regarding BLAS or LAPACK. > > I have tried to test the package with Atlas, OpenBlas, and the > reference implementation with gcc 7.3.0 and 8.2.0. It all worked > without any errors. > > It seems that gcc has changed since January from version 8.2.0 and > 7.3.0 to 8.3.0 on the tests on CRAN. Further, it is now Debian version > 8.3.0-2 instead of Debian 8.2.0-7 and Debian 7.3.0-29. I do not know > whether this can matter. > > Sincerely yours, > Benjamin Christoffersen > > > > > > > > Den ons. 17. apr. 2019 kl. 11.38 skrev Dirk Eddelbuettel : >> >> >> On 17 April 2019 at 11:06, Benjamin Christoffersen wrote: >> | Since the start of April, I have gotten some errors on the Debian >> | machines on the check on CRAN for my package dynamichazard. The places >> | where I get the errors seems to come down to LAPACK's dtrtri routine. >> | I have tried to reproduce the error on Debian 18.04.2 with clang 8.0.0 >> | but I cannot reproduce them. >> | >> | The errors came suddenly and the tests passed before. I see similar >> | issues (I think) in the following package: >> | - RcppHMM >> | - BNPmix >> | - themetagenomics >> | - tidytext >> | - stm >> | >> | Any ideas what the error may be? Here is the relevant code parts for >> | one of the failed tests: >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/for_tests.cpp#L216 >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/arma_BLAS_LAPACK.cpp#L26 >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L67 >> >> There are four or more different sources of LAPACK and BLAS on Debian as we >> (since the late 1990s !!) utilize the nature of the _interface_ allowing >> different packages to fill in. >> >> So there could be >> i) the R internal source with a partial library -- Fedora/CentOS use this >> but the Debian distro builds do not >> ii) "reference BLAS", external, unoptimized >> iii) OpenBLAS, the successor to Goto, parallel via multithreading >> iv) Atlas, "tuned" but not mulitthreading >> and more as eg Intel MKL via a quick script (see my blog). >> >> As a historical aside, and way-back-when, ii) earned us year's long growling >> from the direction of Oxfordshire because some early/old versions of LAPACK >> had bugs. But it cuts both ways: the external versions tend to be complete >> whereas what R ships with internally contains a subset -- and at least one >> (early) user of RcppArmadillo was bitten when R built from sources using >> defaults would not have the complex operations he needed. To R Core's credit >> these missing functions got filled in over the years. >> >> In short, you need to look more closely. On the Ubuntu 18.10 machine that I >> type this on, sessionInfo()'s second paragraph has >> >> Matrix products: default >> BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 >> LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.3.so >> >> which IIRC is also the default (via some Debian/Ubuntu internal 'ordering' of >> the available alternatives). >> >> Hth, Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Bug in the "reformulate" function in stats package
I think that, also in R core, it is well recognized that it is unfortunate
design that some formula manipulation tools rely on going via textual
representation of the entire formula.
I'd be strongly tempted to replace the current reformulate() with something
like this
> x <- c("a variable","another variable", "anormalone")
> lhs <- Reduce(function(x,y) bquote(.(x)+.(y)), lapply(x, as.name))
> as.formula(bquote(~.(lhs)))
~`a variable` + `another variable` + anormalone
However, there is a fair amount of conservatism because of the existing code
base.
In particular, one needs to watch out for nasty corner cases: E.g.,
reformulate(c("x","y","x:y")) contains an interaction term, not a regression
variable `x:y`. It is not too clear that this is desirable, but it is quite
likely that someone's code actually uses it as a feature. Of course,
auto-quoting anything that isn't a plain variable name breaks the feature. And
there's no progammatic way to tell whether "P/E" is intended as a variable name
(price/earnings ratio) or as equal to "P + P:E", so if we want both
possibilities there needs to be a way to choose between them. Which puts us
back at square one.
-pd
> On 18 Apr 2019, at 22:21 , Saren Tasciyan wrote:
>
> So here is it as txt file. It is funny that a R file is restricted in R-devel
> mailing list.
>
> Anyhow, in this case R-core have a few choices here:
>
> * ignore my solution
> * show that it is actually bad or worse
> * consider adding it
>
> Considering, that it is a minor change from previous version and doesn't
> bother the existing usage, I saw the necessity to submit it here. But newer
> solution in the 3.6.0 may solve other problems too. I can't argue against
> that. This solves my part of the problem, without affecting existing usage of
> the function.
>
> If R-core is hard to convince, because this is just who they are, then I
> should consider moving to other platforms. But so far, it seems to me that
> they are doing a great job. I don't mind also someone rejecting this tiny fix
> I have found, which works for me now. I can only thank for their time spent
> considering it.
>
> Actually, I had in mind a more complex but cleaner solution with recursive
> functions to implement any kind of reformulation (not only with "+"). But I
> simple lack the big picture on R expressions, I need to read more. Maybe I
> will come back with that in the future.
>
> Cheers to all,
>
> Saren
>
> On 18.04.19 17:51, Ben Bolker wrote:
>> I appreciate your enthusiasm and persistence for this issue, but I
>> suspect you may have trouble convincing R-core to adopt your changes --
>> they are "better", "easier", "more intuitive" for you ... but how sure
>> are you they are completely backward compatible, have no performance
>> issues, will not break in unusual cases ... ?
> --
> Saren Tasciyan
> /PhD Student / Sixt Group/
> Institute of Science and Technology Austria
> Am Campus 1
> 3400 Klosterneuburg, Austria
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parsing code with newlines
”\r" is CR not LF. On systems that use CRLF as newline, the combination should be "\n" at the C (or R) level. However, I suppose there is no particular reason not to treat CR as whitespace, as does happen with FF and HT. -pd > On 11 Apr 2019, at 01:59 , Mikhail Titov wrote: > > The barely modified test code I had in my previous post, does not parse > what would seem a legit sample string "\r\n ls()". However, it does > parse alright "\n ls()". Nowhere in the docs the intolerance to line > feeds is mentioned. It is reproducible from R console as well. > > ,[ R console session ] > | > parse(text="\r\n ls()") > | Error in parse(text = "\r\n ls()") : :1:1: unexpected input > | 1: > | ^ > | > > ` > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ActiveTCL has non open-source license
Yes, it is annoying but may or may not be an issue for end users. Tcl and Tk are themselves OpenSource and GPL compatible but their license is less stringent than GPL, which allows ActiveState to close up their version (which AFAIK only adds the convenience of a binary install). If you are bothered by it, compile from sources. This is what Simon Urbanek does for the CRAN Mac binaries. Regarding legal issues, I believe this only bites if you both compile R against ActiveTcl _and_ try to redistribute the binary. > On 8 Apr 2019, at 04:39 , Vassil Kakaradov wrote: > > https://cran.r-project.org/doc/manuals/R-admin.html#Installing-R-under-macOS > https://www.activestate.com/activetcl/downloads links to ActiveTCL which > has non open-source license: > http://docs.activestate.com/activetcl/8.5/get/license/ > "ActiveState Confidential Information includes the Software, including all > source and object code, and all associated documentation, but not > Accessible Code." > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] attempt to re-insert old removed package
For most packages[*], I assume that you can just take on the role as maintainer, bump the version number and resubmit. If you don't actually maintain it, then of course it might fall of CRAN again after a while. -pd [*] Actually, I expect that CRAN policy implies "all" here; I just can't be bothered to check... > On 5 Apr 2019, at 10:24 , Ramón Fallon wrote: > > Hi, > > I've been searching for some procedures to try an get an old package back > into CRAN. > > It's package that has the re exclamation mark on cran github and is not > available via install.packages() for modern version of R. > > However some small changes to the source were enough to get it installed > via R CMD INSTALL, so I thought I might how difficult it would be to get it > back into the CRAN repo, but I have been able to find procedures for that > process. > > Any body who has managed this already? Helpful links appreciated, many > thanks. > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] prettyNum digits=0 not compatible with scientific notation
> On 22 Mar 2019, at 18:07 , Martin Maechler wrote:
>
> gives (on Linux R 3.5.3, Fedora 28)
>
> d=10 d=7 d=2 d=1 d=0
> [1,] "123456" "123456" "123456" "1e+05" "%#4.0-1e"
> [2,] "12345.6""12345.6""12346" "12346" "%#4.0-1e"
> [3,] "1234.56""1234.56""1235" "1235" "1235"
> [4,] "123.456""123.456""123""123" "123"
> [5,] "12.3456""12.3456""12" "12""12"
> [6,] "1.23456""1.23456""1.2""1" "1"
> [7,] "0.123456" "0.123456" "0.12" "0.1" "0"
> [8,] "0.0123456" "0.0123456" "0.012" "0.01" "0"
> [9,] "0.00123456" "0.00123456" "0.0012" "0.001" "0"
>
> but probably looks better on Mac
Yes (3.5.1 though)
> nn <- 123456*10^(0:-8); dd <- c(10, 7, 2:0); names(dd) <- paste0("d=",dd)
> sapply(dd, function(dig) sapply(nn, format, digits=dig))
d=10 d=7 d=2 d=1 d=0
[1,] "123456" "123456" "123456" "1e+05" "1.e+05"
[2,] "12345.6""12345.6""12346" "12346" "1.e+04"
[3,] "1234.56""1234.56""1235" "1235" "1235"
[4,] "123.456""123.456""123""123" "123"
[5,] "12.3456""12.3456""12" "12""12"
[6,] "1.23456""1.23456""1.2""1" "1"
[7,] "0.123456" "0.123456" "0.12" "0.1" "0"
[8,] "0.0123456" "0.0123456" "0.012" "0.01" "0"
[9,] "0.00123456" "0.00123456" "0.0012" "0.001" "0"
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prettyNum digits=0 not compatible with scientific notation
FWIW, it doesn't seem to be happening on Mac OS:
> format(2^30, digits=0)
[1] "1.e+09"
> prettyNum(12345.6, digits=0)
[1] "1.e+04"
A glibc misfeature?
-pd
> On 22 Mar 2019, at 10:10 , Martin Maechler wrote:
>
> Thank you, Robert for raising this here !
>
>>>>>> Robert McGehee
>>>>>>on Thu, 21 Mar 2019 20:56:19 + writes:
>
>> R developers,
>> Seems I get a bad result ("%#4.0-1e" in particular) when trying to use
>> prettyNum digits=0 with scientific notation. I tried on both my Linux box
>> and on an online R evaluator and saw the same problem, so it's not limited
>> to my box at least. I see the problem in both R 3.5.3 and R 3.3.2.
>
>> options(scipen= -100)
>
> The above is extreme: You're basically setting an option to
> always see non-integer numbers in "scientific" format ..
> But read below about what 'digits' means in this case.
>
>> prettyNum(1, digits=0)
>> [1] "%#4.0-1e"
>> prettyNum(2, digits=0)
>> [1] "%#4.0-1e"
>> prettyNum(1, digits=0, scientific=FALSE) # Works
>> [1] "1"
>> prettyNum(1:2, digits=0) # Works
>> [1] "1" "2"
>> prettyNum(c(1.1, 2.1), digits=0)
>> [1] "%#4.0-1e" "%#4.0-1e"
>> prettyNum(c(1.1, 2.1), digits=1) # Works
>> [1] "1e+00" "2e+00"
>
> I'm the scape goat / culprit /.. : I have worked on tweaking the
> formatting of (non integer) numbers in R for a long time, on the
> way introducing prettyNum(), also already long ago...
> but then it's actually not prettyNum() but rather format() here :
>
> Have you read its help page - *with* care?
>
> If you do, you'd notice that 'digits' is not among the formal arguments
> of prettyNum() *and* that prettyNum() passes all its `...` to format().
> And if you read ?format [which then you should to understand 'digits' !]
> you see
>
>> digits: how many significant digits are to be used for numeric and
>> complex ‘x’. The default, NULL, uses ‘getOption("digits")’.
>> This is a suggestion: enough decimal places will be used so that
>> the smallest (in magnitude) number has this many significant
>> digits, and also to satisfy ‘nsmall’.
>
>>[.]
>
> So, for the real numbers you use in your example, digits are
> *significant* digits as in 'options(digits= *)' or
> 'print(.., digits= *)'
>
> -- Excursion about 'integer' and format()ing
> -- and you now may also understand why prettyNum(1:2, digits=0) works
> as you expect: integer formatting behaves differently
> but I acknowledge that the ?format help page does not say so
> explicitly yet: it 'real and complex' numbers for the
> 'scientific' argument, and 'numeric and complex' numbers for
> the 'format' argument.
> If you replac numeric by reald, what this entails (by logic)
> that 'integer' numbers are *not* affected by 'digits' nor 'scientific'.
>
> But there's yet more subtlety: 'integer' here means class/type "integer"
> and not just an integer number, i.e., the difference of 1L and 1 :
>
>> str(1)
> num 1
>> str(1L)
> int 1
>> str(1:3)
> int [1:3] 1 2 3
>> str(1:3 + 0)
> num [1:3] 1 2 3
>>
> -- end of Excursion{'integer' ..} ---
>
> Back to real numbers : 'digits' are used as *significant* digits
> (and are only a suggestion: format() and prettyNum() ensure
> a common width for their resulting strings so printing will be
> nicely aligned), see e.g.
>
>> format(3.14, scientific=FALSE)
> [1] "3.14"
>> format(3.14*c(1, 1e-7), scientific=FALSE)
> [1] "3.14000" "0.00314"
>>
>
> So back to your examples : What would you mean with
> ``0 significant digits'' ?
> It really does not make sense to show *no* significant digits ..
>
> Intuitively, without spending enough time, I'd say that the bug
> in format.default() -- which is called by prettyNum() in
> this case -- is that it does *not* treat
> 'digits = 0' as 'digits = 1' in this case.
>
> NB: digits = 0 has been valid inoptions(digits = 0) etc,
> "forever" I think, possibly inherited from S, but I don't
> really know and I wonder if we should not make it invalid eventually
> requiring at least 1.
> So we could make it raise a *warning* (and set it to '1') for now.
> What do others think?
>
> Anyone with S(-PLUS) or Terr or .. who can report if digits=0
> is allowed there and what it does in a simple situation like
&
Re: [R-pkg-devel] obscure syntax error
It could use a little whitespace, but I (and the Rstudio script editor) can't
spot anything wrong, like mismatching braces or parens, and all
else-at-beginning-of-line is inside the function.
Could it be an incomplete last line?
-pd
> On 22 Mar 2019, at 11:18 , Jim Lemon wrote:
>
> Hi,
> I have been attempting to check a new version of the prettyR package,
> and have struck a difficult problem. The check fails at the
> installation, and when I track the error, it is "Unexpected end of
> input" in the xtab function. I have tried a number of things as I
> thought that it was a non-printing character (I have had that happen
> before). I can paste the entire function into an R session and there
> is no error. Has anyone struck an error like this before?
>
> xtab<-function(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE,
> html=FALSE,bgcol="lightgray") {
>
> if(missing(formula))
> stop("Usage:
> xtab(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE\n")
> ft<-as.character(attr(terms(formula),"variables")[-1])
> nft<-length(ft)
> if(nft>2) {
> xt<-list()
> by.factor<-as.factor(data[[ft[nft]]])
> factor.levels<-levels(by.factor)
> factor.labels<-attr(data[,ft[nft]],"value.labels")
> if(!is.null(names(factor.labels))) factor.labels<-names(factor.levels)
> if(is.null(factor.labels)) factor.labels<-factor.levels
> nlevels<-length(factor.levels)
> for(i in 1:nlevels) {
> currentdata<-subset(data,by.factor==factor.levels[i])
> for(j in 1:dim(currentdata)[2])
>attr(currentdata[,j],"value.labels")<-attr(data[,j],"value.labels")
> currentcount<-length(currentdata[[nft]])
> totalcount<-length(data[[nft]])
> cat("\nCount for",ft[nft],"=",factor.labels[i],"is",currentcount,
>"(",round(100*currentcount/totalcount,1),"%)\n\n")
> rightside<-ifelse(nft>3,paste(ft[2:(nft-1)],sep="",collapse="+"),ft[2])
> next.formula<-as.formula(paste(ft[1],rightside,sep="-",collapse=""))
> xt[[i]]<-xtab(next.formula,data=currentdata,varnames=varnames,chisq=chisq,
>phi=phi,html=html,bgcol=bgcol)
> }
> }
> else {
> if(missing(data)) xt<-calculate.xtab(get(ft[1]),get(ft[2]),varnames=varnames)
> else xt<-calculate.xtab(data[,ft[1]],data[,ft[2]],varnames=varnames)
> }
> attr(xt,"class")<-"xtab"
> return(xt)
> }
> Thanks for any pointers.
>
> Jim
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] R 3.6.0 scheduled for April 26
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possibly broken system2 env-option
On Windows, ‘env’ is only supported for commands such as ‘R’ and
‘make’ which accept environment variables on their command line.
So I suppose that would be tricky.
The basic issue is that on Unix-alikes, system2 constructs a command like
FOO=bar cmd args
and passes that to sh via system(). On windoes, system() does not call sh, so
system2() does (effectively)
cmd FOO=bar args
and hopes that cmd knows what to do with the env setting.
-pd
> On 19 Mar 2019, at 11:09 , Gábor Csárdi wrote:
>
> On Tue, Mar 19, 2019 at 9:59 AM peter dalgaard wrote:
> [...]
>> What you need is something like (NB: single quotes!)
>>> system2("sh", env = c("VAR='Hello World'"), args = c("-c 'echo $VAR'"))
>> Hello World
>
> Just out of curiosity, do you think it is possible to make this
> portable, assuming sh is available? On Windows it gives
>
>> system2("sh", env = c("VAR='Hello World'"), args = c("-c 'echo $VAR'"))
> /rtools34/bin/sh: VAR=Hello World: No such file or directory
> Warning message:
> running command '"sh" VAR='Hello World' -c 'echo $VAR'' had status 127
>
> G.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possibly broken system2 env-option
You are using it wrong. It wants strings of the form "name=value", not a
character vector with names as labels. So this is closer to the mark:
> system2("echo", env = c("VAR='Hello World'"), args = c("$VAR"))
>
However, as you see it doesn't work as intended. The problem is that the
$-substitution refers to the environment of the shell executing the command.
I.e. this does not work from a terminal command line either:
pd$ VAR="foo" echo $VAR
pd$
Or even
pd$ VAR="bar"
pd$ VAR="foo" echo $VAR
bar
What you need is something like (NB: single quotes!)
pd$ VAR="foo" sh -c 'echo $VAR'
foo
So:
> system2("sh", env = c("VAR='Hello World'"), args = c("-c 'echo $VAR'"))
Hello World
-pd
> On 18 Mar 2019, at 17:28 , Henning Bredel wrote:
>
> Hey all,
>
> what is wrong with this command:
>
> system2("echo", env = c(VAR = "Hello World"), args = c("$VAR"))
>
> I am a bit confused, as help("system2") writes about the env option:
>
>> character vector of name=value strings to set environment variables.
>
> Is this option buggy, or am I using it just wrong?
>
> Thanks for your help
>
> Henning
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.data.frame.table() does not recognize default.stringsAsFactors()
My point was that, in a table, the row and columns usually have a well-defined order. If you convert the table to data frame form, typically in order to fit a Poisson GLM, you do want to preserve that order, and not have the levels converted to a locale-dependent alphabetical order in your analyses. Or at least, if you do want conversion to character, you should say so very explicitly. That is the way it currently works: You can override, just not via the global option. Notice also that it is very easy to do as.character(factor) if you need it, whereas it is rather more painful to convert a character vector to a factor with level names determined by the dimension names of the appropriate extent of the original table. -pd > On 15 Mar 2019, at 13:13 , Therneau, Terry M., Ph.D. via R-devel > wrote: > > I have to disagree with both Peter and Martin on this. > > The underneath issue is that the automatic conversion of characters to > factors by the > data.frame functions was the single most egregious design blunder in the > Statistical > Models in S book, and we are still living with it. The stringsAsFactors > option was a > compromise to let users opt out of that mistake (one I had to fight hard > for).In that > light I read Peter's defense as "but in this case we really DO know better > than the user, > and won't let them opt out", and Martin's as "they shouldn't have been able > to opt out in > the first place, so weaken it at every opportunity". > > I generally agree that global options should be minimal. But if one exists, > let's be > consistent and listen to it. > > (Footnote: In the Mayo Biostat group, stringsAsFactors=FALSE is the > recommended global > option for all users. It's a pure cost/productivity thing. We work on > thousands of data > sets in a year, and the errors and misunderstandings that silent conversions > generate far > outweigh any benefits. ) > > Terry T. > > > On 3/15/19 6:00 AM, r-devel-requ...@r-project.org wrote: >>> I have no recollection of the original rationale for as.data.frame.table, >>> but I actually think it is fine as it is: >>> The classifying_factors_ of a crosstable should be factors unless very >>> specifically directed otherwise and that should not depend on the setting >>> of an option that controls the conversion of character data. >> >>> For as.data.frame.matrix, in contrast, it is the_content_ of the matrix >>> that is being converted, and it seems much more reasonable to follow the >>> same path as for other character data. >> >>> -pd >> >> I very strongly agree that as.data.frame.table() should not be >> changed to follow a global option. >> >> To the contrary: I've repeatedly mentioned that in my view it >> has been a design mistake to allow data.frame() and as.data.frame() be >> influenced >> by a global option >> [and we should've tried harder to keep things purely functional >>(R remaining as closely as possible a "functional language"), >> e.g. by providing wrapper functions the same way we have such >> wrappers for versions of read.table() with different defaults >> for some of the arguments >> ] > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.data.frame.table() does not recognize default.stringsAsFactors()
I have no recollection of the original rationale for as.data.frame.table, but I
actually think it is fine as it is:
The classifying _factors_ of a crosstable should be factors unless very
specifically directed otherwise and that should not depend on the setting of an
option that controls the conversion of character data.
For as.data.frame.matrix, in contrast, it is the _content_ of the matrix that
is being converted, and it seems much more reasonable to follow the same path
as for other character data.
-pd
> On 12 Mar 2019, at 21:39 , Mychaleckyj, Josyf C (jcm6t)
> wrote:
>
> Reporting a possible inconsistency or bug in handling stringsAsFactors in
> as.data.frame.table()
>
> Here is a simple test
>
>> options()$stringsAsFactors
> [1] TRUE
>> x<-c("a","b","c","a","b")
>> d<-as.data.frame(table(x))
>> d
> x Freq
> 1 a2
> 2 b2
> 3 c1
>> class(d$x)
> [1] "factor"
>> d2<-as.data.frame(table(x),stringsAsFactors=F)
>> class(d2$x)
> [1] “character"
>> options(stringsAsFactors=F)
>> options()$stringsAsFactors
> [1] FALSE
>> d3<-as.data.frame(table(x))
>> d3
> x Freq
> 1 a2
> 2 b2
> 3 c1
>> class(d3$x)
> [1] “factor"
>> d4<-as.data.frame(table(x),stringsAsFactors=F)
>> class(d4$x)
> [1] “character"
>
>
> # Display the code showing the different stringsAsFactors handling in table
> and matrix:
>
>> as.data.frame.table
> function (x, row.names = NULL, ..., responseName = "Freq", stringsAsFactors =
> TRUE,
>sep = "", base = list(LETTERS))
> {
>ex <- quote(data.frame(do.call("expand.grid", c(dimnames(provideDimnames(x,
>sep = sep, base = base)), KEEP.OUT.ATTRS = FALSE, stringsAsFactors =
> stringsAsFactors)),
>Freq = c(x), row.names = row.names))
>names(ex)[3L] <- responseName
>eval(ex)
> }
>
>
>
>> as.data.frame.matrix
> function (x, row.names = NULL, optional = FALSE, make.names = TRUE,
>..., stringsAsFactors = default.stringsAsFactors())
> {
>d <- dim(x)
>nrows <- d[[1L]]
>ncols <- d[[2L]]
>ic <- seq_len(ncols)
>dn <- dimnames(x)
>if (is.null(row.names))
>row.names <- dn[[1L]]
>collabs <- dn[[2L]]
>if (any(empty <- !nzchar(collabs)))
>collabs[empty] <- paste0("V", ic)[empty]
>value <- vector("list", ncols)
>if (mode(x) == "character" && stringsAsFactors) {
>for (i in ic) value[[i]] <- as.factor(x[, i])
>}
>else {
>for (i in ic) value[[i]] <- as.vector(x[, i])
>}
>autoRN <- (is.null(row.names) || length(row.names) != nrows)
>if (length(collabs) == ncols)
>names(value) <- collabs
>else if (!optional)
>names(value) <- paste0("V", ic)
>class(value) <- "data.frame"
>if (autoRN)
>attr(value, "row.names") <- .set_row_names(nrows)
>else .rowNamesDF(value, make.names = make.names) <- row.names
>value
> }
>
>
>
>
>> sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: CentOS Linux 7 (Core)
>
> Matrix products: default
> BLAS: /usr/lib64/libblas.so.3.4.2
> LAPACK: /usr/lib64/liblapack.so.3.4.2
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.2 tools_3.5.2
>
> Thanks,
> Joe
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.5.3 is released
The build system rolled up R-3.5.3.tar.gz (codename "Great Truth") this morning. The list below details the changes in this release. This is the wrap-up release for the 3.5.x series, so actually, not much has happened. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.5.3.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 3bba37aa1dd06de3f781200a8081302f MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = ab129f42b1d5ca25122db6b1bda0fcd9 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 591dcf615162127f904e4e461f330ce9 MD5 (R-latest.tar.gz) = 525e902dd331c387f271692a1537aff8 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 08158353102084599797db8c9ccf8e2a MD5 (VERSION-INFO.dcf) = cb61b0eb560efcbbec47128abf3fb761 MD5 (R-3/R-3.5.3.tar.gz) = 525e902dd331c387f271692a1537aff8 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 98df47801c33cc4f4a4de98447cb2bd40e09c0920195f540a981ceed874714f2 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 4c6eb7cd9d8f4c1858a8f853698d2954d42d5d8b71c5c4d20bc6bd970f034bfe NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ca04f78ffe54afa326fe3ed40e7e1411acaed2fa5ead97ddf51c6aa5b7bc NEWS.2 2bfa37b7bd709f003d6b8a172ddfb6d03ddd2d672d6096439523039f7a8e678c R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES 2d2e85e85574c4430951f6b070c08cd5aff1602abfd1bb162bed6d89c436b11f THANKS 1ce83e7a843f95e8b0d5abf6ced7426cc337cc607f9862f99d46a7d05793ac15 VERSION-INFO.dcf 2bfa37b7bd709f003d6b8a172ddfb6d03ddd2d672d6096439523039f7a8e678c R-3/R-3.5.3.tar.gz This is the relevant part of the NEWS file: CHANGES IN R 3.5.3: INSTALLATION on a UNIX-ALIKE: * Detection of flags for C++98/11/14/17 has been improved: in particular if CXX??STD is set, it is tried first with no additional flags. PACKAGE INSTALLATION: * New macro F_VISIBILITY as an alternative to F77_VISIBILITY. This will become the preferred form in R 3.6.0. BUG FIXES: * writeLines(readLines(fnam), fnam) now works as expected, thanks to Peter Meissner's PR#17528. * setClassUnion() no longer warns, but uses message() for now, when encountering "non local" subclasses of class members. * stopifnot(exprs = T) no longer fails. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled
It's not "stealth fixed"! It was never there... (on the release branch)
The timestamp checking code is still present in R-devel. I presume something
needs to be done about the breakage.
- pd
> On 7 Mar 2019, at 14:38 , Bob Rudis wrote:
>
> It's fixed in the RC that's GA on the 11th.
>
> I think perhaps "stealth fixed" may be more appropro since it's not in SVN
> logs, Bugzilla nor noted prominently in any of the various NEWS* files.
>
> Then there's the "why was the core R installation using a third party,
> non-HTTPS site for this to begin with".
>
> And, in other news, there are tests in the R source that rely on a check of
> `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is
> registered. Thankfully there's no current IP address associated with it.
> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might be
> a better choice as well since that won't break the reason for the
> connectivity checks and won't arbitrarily send telemetry pings to third
> parties in the even anyone outside of R Core decides to run the tests (say,
> when patching something in R).
>
> -boB
>
>> On Mar 7, 2019, at 07:54, Rainer M Krug wrote:
>>
>> I can confirm the same when checking on travis with r-devel.
>>
>> And thanks for the tip with
>>
>> env:
>> - _R_CHECK_SYSTEM_CLOCK_=0
>>
>> In .travis.yml
>>
>> Seems to be working now
>>
>> Rainer
>>
>>
>>
>>> On 7 Mar 2019, at 12:48, Ralf Herold wrote:
>>>
>>> Dear All,
>>>
>>> Checking a new package under development produces a warning in a local
>>> R-devel MS Windows environment (output below).
>>>
>>> Building it with R-devel on Travis fails (because warnings are changed to
>>> errors), but is successful when setting environment variable
>>> _R_CHECK_SYSTEM_CLOCK_ to zero.
>>>
>>> No issue occurs when checking and building with R-stable and R-oldrel on
>>> Travis, or with any R version on win-builder.r-project.org.
>>>
>>> The warning concerns using http://worldclockapi.com/, which however seems
>>> out of service ("The web app you have attempted to reach is currently
>>> stopped and does not accept any requests."). This is referenced in the main
>>> function for R CMD check
>>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may
>>> concern more R-devel than R-package-devel. I am posting here to check if
>>> the issue was noticed by other package developers and to check the impact.
>>>
>>> Thanks for any suggestions.
>>> Best regards,
>>> Ralf
>>>
>>>
>>> PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check
>>> E:\mypackage_0.1.2.3.tar.gz --as-cran
>>> * using log directory 'C:/Users/username/ctrdata.Rcheck'
>>> * using R Under development (unstable) (2019-03-05 r76200)
>>> * using platform: x86_64-w64-mingw32 (64-bit)
>>> * using session charset: ISO8859-1
>>> * using option '--as-cran'
>>> [...]
>>> * checking package directory ... OK
>>> * checking for future file timestamps ...Warning in file(con, "r") :
>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status
>>> was '403 Site Disabled'
>>> WARNING
>>> unable to verify current time
>>> * checking 'build' directory … OK
>>> [...]
>>>
>>>
>>>
>>> ## Ralf Herold
>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>> ## https://paediatricdata.eu/
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>>
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] R 3.5.3 scheduled for March 11
Full schedule available on developer.r-project.org (pending auto-update from SVN) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return/print standard error in t.test()
It's not a problem per se to put additional information into class htest objects (hey, it's S3 after all...) and there is a precedent in chisq.test which returns $observed and $expected. Getting such information printed by print.htest is more tricky, although it might be possible to (ab)use the $estimate slot. The further question is whether one would really want to do that (change the output and/or modify the current return values), at the risk of affecting a rather large bundle of existing scripts, books, lecture notes, etc. I don't think that I would want to do that for the case of the s.e.d., although I'll admit that there is another thing that has always been a bit of an eyesore to me: We give a confidence interval but not the corresponding point estimate (i.e. the _difference_ of the means). It might be better to simply start over and write a new function. In the process one might address other things that people have been asking for, like calculations based on the sample mean and SDs (which would useful for dealing with published summaries and textbook examples). Oh, and a formula interface for the one-sample test. -pd > On 21 Feb 2019, at 22:51 , Fox, John wrote: > > Dear Thomas, > > it is, unfortunately, not that simple. t.test() returns an object of class > "htest" and not all such objects have standard errors. I'm not entirely sure > what the point is since it's easy to compute the standard error of the > difference from the information in the object (adapting an example from > ?t.test): > >> (res <- t.test(1:10, y = c(7:20))) > > Welch Two Sample t-test > > data: 1:10 and c(7:20) > t = -5.4349, df = 21.982, p-value = 1.855e-05 > alternative hypothesis: true difference in means is not equal to 0 > 95 percent confidence interval: > -11.052802 -4.947198 > sample estimates: > mean of x mean of y > 5.5 13.5 > >> as.vector(abs(diff(res$estimate)/res$statistic)) # SE > [1] 1.47196 >> class(res) > [1] "htest" > > and if you really want to print the SE as a matter of course, you could > always write your own wrapper for t.test() that returns an object of class, > say, "t.test" for which you can provide a print() method. Much of the > advantage of working in a statistical computing environment like R (or Stata, > for that matter) is that you can make things work the way you like. > > Best, > John > > - > John Fox, Professor Emeritus > McMaster University > Hamilton, Ontario, Canada > Web: http::/socserv.mcmaster.ca/jfox > >> On Feb 21, 2019, at 3:57 PM, Thomas J. Leeper wrote: >> >> A recent thread on Twitter [1] by a Stata user highlighted that t.test() >> does not return or print the standard error of the mean difference, despite >> it being calculated by the function. >> >> I know this isn’t the kind of change that’s likely to be made but could we >> at least return the SE even if the print() method isn’t updated? Or, >> better, update the print() method to display this as well? >> >> Best, >> Thomas >> >> [1] >> https://twitter.com/amandayagan/status/1098314654470819840?s=21 >> -- >> >> Thomas J. Leeper >> http://www.thomasleeper.com >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug Report: read.table with UTF-8 encoded file imports infinity symbol as Integer 8
Fortune nomination... > On 8 Feb 2019, at 13:07 , Tomas Kalibera wrote: > > This is caused by Windows "best fit" default behavior in conversion of > unicode characters to characters in the current native encoding: at some > point in the past, 8 has been chosen as a good fit for infinity in Windows. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug Report: read.table with UTF-8 encoded file imports infinity symbol as Integer 8
This doesn't seem to be happening on MacOS, neither in Terminal nor RStudio, (R
3.5.1, R-devel, R-patched). So probably Windows specific.
-pd
> On 7 Feb 2019, at 11:17 , David Byrne wrote:
>
> Bug
> Using read.table(file, encoding="UTF-8") to import a UTF-8 encoded
> file containing the infinity symbol (' ∞ ') results in the infinity
> symbol imported as the number 8. Other Unicode characters seem
> unaffected, example, Zhe: ж
>
> Expected Behavior:
> The imported data.frame should represent the infinity symbol as the
> expected 'Inf' so that normal mathematical operations can be processed
>
> Stack Overflow Post:
> I created a question on Stack Overflow where one other member was able
> to reproduce the same issues I was having. This question can be found
> at:
> https://stackoverflow.com/questions/54522196/r-read-table-with-utf-8-encoded-file-reads-infinity-symbol-as-8-int
>
> Method to Reproduce - 1:
> A simple method to reproduce this issues is to use R-Studio: In the
> console, type the following:
>> read.table(text=" ∞", encoding="UTF-8")
>
> The result should be a data.frame with a single value of '8'
>
> Repeating the same with ж Results in correct expected behavior
>
> Method to Reproduce - 2:
> Create a .csv file containing the infinity and Zhe characters (I have
> attached the file for convenience, hopefully it is no rejected by your
> email service). Launch an interactive session using
>
>> r --vanilla
>
> Enter the following statement taking care to replace the
> with the appropriate one:
>
>> read.table("/unicode_chars.csv", sep=",", encoding="UTF-8")
>
>
> This should result in a two element data.frame; the first being the
> incorrect value of 8 with an additional and the second the
> correct value of Zhe.
>
> Note the additional prefixed to the front of the '8'. This
> appears to be a hidden character for the purposes of letting editors
> know the encoding. The following link has some explanation however, it
> states this is caused by excel. The file I created was done so using
> notepad and not Excel.
>
> https://medium.freecodecamp.org/a-quick-tale-about-feff-the-invisible-character-cd25cd4630e7
>
> System Details:
> OS:
>> Windows 10.0.17134 Build 17134
>
>
> R Version:
>> platform x86_64-w64-mingw32
>> arch x86_64
>> os mingw32
>> system x86_64, mingw32
>> status
>> major 3
>> minor 4.1
>> year 2017
>> month 06
>> day30
>> svn rev72865
>> language R
>> version.string R version 3.4.1 (2017-06-30)
>> nickname Single Candle
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R
The difference is obviously in the "con" men. The definition of role="con" in
the MARC code list is
Conservator [con]
A person or organization responsible for documenting, preserving, or treating
printed or manuscript material, works of art, artifacts, or other media
UF Preservationist
Is this as intended?
-pd
> On 6 Feb 2019, at 13:26 , Ivan Krylov wrote:
>
> Hi!
>
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
>
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
>
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
>
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
>
> The actual field from DESCRIPTION now looks like this:
>
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
>
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
>
> What should I do to avoid the NOTE?
>
> --
> Best regards,
> Ivan
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Inefficiency in df$col
Does either of you have a patch against current R-devel? I tried the obvious, but the build dies with building package 'tools' all.R is unchanged ../../../../library/tools/libs/x86_64/tools.so is unchanged installing 'sysdata.rda' Error in get(method, envir = home) : object '$.data.frame' not found Error: unable to load R code in package 'tools' Execution halted ...and I can't really be arsed to dig into tools to see exactly where it is hardcoding the existence of $.data.frame. -pd > On 4 Feb 2019, at 15:32 , Duncan Murdoch wrote: > > On 04/02/2019 9:20 a.m., Radford Neal wrote: >>>> I think you might want to just delete the definition of $.data.frame, >>>> reverting to the situation before R-3.1.0. >>> >>> I imagine the cause is that the list version is done in C code rather >>> than R code (i.e. there's no R function `$.list`). So an alternative >>> solution would be to also implement `$.data.frame` in the underlying C >>> code. This won't be quite as fast (it needs that test for NULL), but >>> should be close in the full match case. >> I maybe wasn't completely clear. The $ operator for data frames was >> previously done in C - since it was done by the same primitive as for >> lists. In R-3.1.0, this was changed - producing a massive slowdown - >> for the purpose of giving a warning on partial matches even if the >> user had not set the warnPartialMatchDollar option to TRUE. In >> R-3.1.1, this was changed to not warn unless warnPartialMatchDollar was >> TRUE which was the PREVIOUS behaviour. In other words, this change >> reverted the change made in R-3.1.0. But instead of simply deleting >> the definition of $.data.frame, R-3.1.1 added extra code to it, the >> only effect of which is to slightly change the wording of the warning >> message from what is produced for any other list, while still retaining >> the massive slowdown. >> There is no need for you to write $.data.frame in C. You just need >> to delete the version written in R. > > Sorry, I did misunderstand. Thanks for the clarification. > > But if the "You" in your last sentence meant me, it needs to be "They": I am > not a member of R Core and can't make any changes to the sources. > > Duncan Murdoch > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] RData files with identical objects in package
There is (of course) a difference between what is the default for a (missing)
field in DESCRIPTION and what shells like RStudio put into the field by
default...
I don't think there is a discrepancy between what is in the official
documentation and what R and R CMD * actually does.
-pd
> On 14 Jan 2019, at 07:10 , Troels Ring wrote:
>
> Thank you so much! Perhaps it could be mentioned in the official
> documentation on writing R extensions - even if - if I can read English -
> the
> default is to avoid "lazyData" loading - and "laxyData" loading is in some
> opposition to loading using data() - whereas - if we use RStudio, and make
> an R documentation file for data, we have it ending with:
> \examples{
> data(ddd)
> ## maybe str(ddd) ; plot(ddd) ...
> }
> \keyword{datasets}
>
> At the same time as "lazyData" is used default in DESCRIPTION ?
>
> 1.1.6 Data in packages
> The data subdirectory is for data files, either to be made available via
> lazy-loading or for loading using data(). (The choice is made by the
> 'LazyData' field in the DESCRIPTION file: the default is not to do so.) It
> should not be used for other data files needed by the package, and the
> convention has grown up to use directory inst/extdata for such files.
>
> All best wishes
> Troels
>
>
> -Oprindelig meddelelse-
> Fra: peter dalgaard
> Sendt: 13. januar 2019 22:00
> Til: Troels Ring
> Cc: Michael Dewey ; package-develop
>
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>
> I think it is illegal if you use the lazyload database, because that is
> indexed by name and contains every object that would be created by data().
> This creates an obvious issue if two objects share a name.
>
> Once you use the lazyload database, loading the package creates an
> environment which is initially full of promises, one for each object.
> Evaluating one of these makes the actual object appear in the environment.
>
> Using data() causes the corresponding promise(s) to be created in the global
> environment. IIRC, there is a registry that says which objects are created
> by which arguments to data(), but as they are still taken from the lazydata
> database, the last one created with a given name still wins.
>
> -ps
>
>> On 13 Jan 2019, at 14:13 , Troels Ring wrote:
>>
>> Thanks a lot - I'm sure you are right that I could just use different
>> names but I cannot understand why it could cause problem to have two
>> different well formated .RData files in the /data directory both with
>> an "x" - is that really illegal? I cannot see it stated in the
>> official munual - but it is long (wrting r extensions) -BW Troels
>>
>> -Oprindelig meddelelse-
>> Fra: Michael Dewey
>> Sendt: 13. januar 2019 12:56
>> Til: Troels Ring ; package-develop
>>
>> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>>
>> Dear Troels
>>
>> Perhaps I misunderstand what you are trying to do but would it be
>> possible to put each x and y into a list or a dataframe with different
>> names and then modify your usgae to pull them from there? Then there
>> would be no danger of users getting the wrong x and y
>>
>> Michael
>>
>> On 13/01/2019 08:38, Troels Ring wrote:
>>> Dear friends - I have a package under creation making heavy
>>> calculations on chemical/clinical data and I plan to include as
>>> "examples" the use of some literature data used in my papers. To
>>> illustrate what then occurs, I made two RData files consisting only
>>> of x and y with different values for x and y like
>>>
>>> X <- 100
>>>
>>> Y <- 1000
>>>
>>> save(x,y,file="first.RData")
>>>
>>> and then a new x and y in "second" with x <- 45 and y <- 32
>>>
>>> When I put these in a "data" directory of a new package without
>>> further ado in RStudio
>>>
>>> Ctrl-shift-L
>>>
>>> Ctrl-shift-B
>>>
>>>
>>>
>>> .there is a warning
>>>
>>> * installing *source* package 'try' ...
>>>
>>> ** R
>>>
>>> ** data
>>>
>>> *** moving datasets to lazyload DB
>>>
>>> warning: objects 'x', 'y' are created by more than one data call
>>>
>>> ** byte-compile and prepare package for lazy loading
>>>
>>> ** help
>>>
>>> converting help for package 'try'
>
Re: [Rd] history of objects() and ls()
As far as I remember, this comes from S-PLUS, introduced around v.3 (white book?) or maybe v.4, and due to a desire to cut some Unix ties as MS-DOS was taking over the world. However, it was long ago, in a different world, and besides, S-PLUS is dead (mostly). - Peter > On 4 Jan 2019, at 00:45 , Ben Bolker wrote: > > > I found out today (maybe I had known sometime before??) that objects() > is a synonym for ls(). I'm curious about the history, which seems to go > at least back to the beginning of R. It's been thus since SVN revision > 2 (Sep 1997) ... > > svn cat https://svn.r-project.org/R/trunk/src/library/base/R/attach@2 | > grep objects > > I had a quick look at the Becker & Chambers brown book (1984) and > Becker and Wilks blue book (1988) on Google books and could find ls but > not objects() ... ? > > Anyone happen to know? > > cheers > Ben Bolker > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Package update submission to CRAN fails on pretest
Hmm, no ERRORs in the CRAN checks at this moment? Re. utf-8, on Mac OS, the CRAN checks have a note about 90 strings marked as utf8. I see 57 of them in > life$Country[Encoding(life$Country)!="unknown"] [1] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." [3] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." [5] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." ... and 32 more in "mortality". You go find the remaining 1... This seems to be an issue with the quote symbol: > u <- life$Country[Encoding(life$Country)!="unknown"][1] > Encoding(u) [1] "UTF-8" > Encoding(u) <- "bytes" > u [1] "Korea, Dem. People\\xe2\\x80\\x99s Rep." I have no clue why this is not an issue on only some platforms. -pd > On 7 Dec 2018, at 08:54 , Wolfgang Lenhard > wrote: > > Dear list, > I am getting problems when trying to submit an update of the package > cNORM to CRAN. I am developing the package with RStudio and devtools and > I am using Travis for automatic testing. The package is tested locally > on Win10 and Mac OS X and on Travis with Ubuntu and Mac both for > development and release versions of R. All local tests and tests on > Travis work flawlessly - no errors, warning or notes. When submitting to > CRAN, a note and an error show up on some of the Linux OS (Fedora & > Solaris) and Mac OS X, while others display an 'OK' (Win, Debian). The > results: https://cran.r-project.org/web/checks/check_results_cNORM.html > > - error: This seems to be related to the vignette with the following > message: >> * checking examples ... ERROR >> Running examples in ‘cNORM-Ex.R’ failed > I can however not identify the location of the error > > - Note: Check: data for non-ASCII characters > > The strange thing is: I checked all data files multiple times. They > mainly consist of data.frames with numerics and all colnames are ASCII. > I am not able to replicate the issue. The same is true for the error, > which does not show up on Travis and as well locally. And finally, the > results state, that the version of the package is 1.0.1, which had been > the first submission to CRAN a month ago. The current version of the > package is 1.1.1. Could this be the reason for the problem? > > Do you have an idea how to progress with the testing or how to locate > the errors? Any help is welcome. > > Best regards, > Wolfgang Lenhard > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] R 3.5.2 scheduled for December 20
Full schedule available on developer.r-project.org -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Effieciency drop in do.call?
A classical way of encountering this is
x <- rnorm(1000)
do.call("plot", list(x))
A way out is
do.call("plot", list(quote(x)))
-pd
> On 19 Nov 2018, at 22:32 , peter dalgaard wrote:
>
> If it was just about args evaluation, then the slowness would be in the
> list() call, no?
> An accidental deparse of a large structure could well be the culprit.
>
> -pd
>
>
>> On 19 Nov 2018, at 18:53 , Gabor Grothendieck
>> wrote:
>>
>> The do.call version evaluates all arguments while the normal version
>> may not depending on the function. There could also be a difference
>> if the function uses non-standard evaluation since in that case the
>> two could be passing different different argument values.
>>
>> For an example of the second case,
>>
>> f <- function(x) deparse(substitute(x))
>>
>> f(pi)
>> ## [1] "pi"
>>
>> do.call("f", list(pi))
>> ## [1] "3.14159265358979"
>>
>> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner
>> wrote:
>>>
>>> Hi all,
>>>
>>> today, I stumbled upon a puzzling (to me) problem apparently related to
>>> do.call() that resulted
>>> in an efficiency drop of multiple orders of magnitudes compared to just
>>> calling the function directly (multiple minutes as compared to one second).
>>>
>>> That is
>>>
>>> fun(a = a, b = b, c = c, ...)
>>>
>>> took one second, while
>>>
>>> args <- list(a = a, b = b, c = c, ...)
>>> do.call(fun, args)
>>>
>>> took multiple minutes.
>>>
>>> In my package (brms), I use do.call in various places but only in one it
>>> resulted in this
>>> efficiency drop.
>>>
>>> Before I try to make a reproducible example, I wanted to ask if there are
>>> any known issues
>>> with do.call that may explain this?
>>>
>>> Paul
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>> --
>> Statistics & Software Consulting
>> GKX Group, GKX Associates Inc.
>> tel: 1-877-GKX-GROUP
>> email: ggrothendieck at gmail.com
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Effieciency drop in do.call?
If it was just about args evaluation, then the slowness would be in the list()
call, no?
An accidental deparse of a large structure could well be the culprit.
-pd
> On 19 Nov 2018, at 18:53 , Gabor Grothendieck wrote:
>
> The do.call version evaluates all arguments while the normal version
> may not depending on the function. There could also be a difference
> if the function uses non-standard evaluation since in that case the
> two could be passing different different argument values.
>
> For an example of the second case,
>
> f <- function(x) deparse(substitute(x))
>
> f(pi)
> ## [1] "pi"
>
> do.call("f", list(pi))
> ## [1] "3.14159265358979"
>
> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner
> wrote:
>>
>> Hi all,
>>
>> today, I stumbled upon a puzzling (to me) problem apparently related to
>> do.call() that resulted
>> in an efficiency drop of multiple orders of magnitudes compared to just
>> calling the function directly (multiple minutes as compared to one second).
>>
>> That is
>>
>> fun(a = a, b = b, c = c, ...)
>>
>> took one second, while
>>
>> args <- list(a = a, b = b, c = c, ...)
>> do.call(fun, args)
>>
>> took multiple minutes.
>>
>> In my package (brms), I use do.call in various places but only in one it
>> resulted in this
>> efficiency drop.
>>
>> Before I try to make a reproducible example, I wanted to ask if there are
>> any known issues
>> with do.call that may explain this?
>>
>> Paul
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Unexpected symbol when checking package examples
Not just a capitalization issue (mertools vs. merTools)? Barring that, maybe locale trouble? Can you also do things like LC_ALL=C R < merTools-Ex.R ? Also, check for lines starting with "else" (I think you shouldn't be able to run it line-by-line if that was the issue, though). -pd > On 11 Nov 2018, at 21:39 , Jared Knowles wrote: > > Hi! > > I have a bit of a weird issue when I'm trying to check my package merTools > (source repo available here: https://github.com/jknowles/merTools > > On Windows and Linux builds for R-release and R-devel, when R CMD CHECK > checks examples, it returns the following error below: > > Warning: parse error in file 'merTools-Ex.R': > 1: unexpected symbol > 117: cleanEx() > 118: nameEx > > > Upon inspecting the example file generated by R CMD CHECK (mertools-Ex.R) - > it contains only valid R code. I can run it line by line or source the > whole file in R without any errors. But, during the check process, this > error occurs. > > The functions cleanEx() and nameEx() appear to be created as part of the > checking process. > > I have not changed the examples in the code since the last time I ran R CMD > CHECK so I am quite confident that the example code for all functions is > valid R code. > > Any ideas on what might be the source of this problem? > > Thanks! > Jared > > > > Jared Knowles > President, Civilytics Consulting LLC > www.jaredknowles.com > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] error unserializing ascii format (v2 or v3)
I see this on MacOS as well, so likely not platform dependent. A little more diddling to try to narrow it down: > unserialize(serialize(as.raw(1), NULL, version=2, ascii=TRUE)) [1] 30 > unserialize(serialize(list(as.raw(1)), NULL, version=2, ascii=TRUE)) [[1]] [1] 30 > unserialize(serialize(list(raw=as.raw(1)), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(raw = as.raw(1)), NULL, version = 2, : 'installTrChar' must be called on a CHARSXP, but got 'pairlist' > unserialize(serialize(list(r=as.raw(1)), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(r = as.raw(1)), NULL, version = 2, : 'installTrChar' must be called on a CHARSXP, but got 'pairlist' > unserialize(serialize(list(r=1), NULL, version=2, ascii=TRUE)) $r [1] 1 > unserialize(serialize(list(as.raw(c(1,2))), NULL, version=2, ascii=TRUE)) [[1]] [1] 30 31 So it looks like there is an issue with reading a named list containing a raw vector. Unnamed lists work and so does non-raw vectors. The length of the vector doesn't seem to matter and neither does the actual name. You can vary the error message by varying the entries in the vector, but the gist of it is that something gets misinterpreted and the rest of the data stop making sense. I also tried going explicitly through a text connection, and that seems exactly equivalent. -pd > On 7 Nov 2018, at 23:35 , Michael Sannella via R-devel > wrote: > > I ran into an interesting error unserializing a file created with > ascii=TRUE: > > R 3.5.1 (Windows or Linux): >> unserialize(serialize(list(raw=as.raw(c(39,41))), NULL, version=2, > ascii=TRUE)) >Error in unserialize(serialize(list(raw = as.raw(c(39, 41))), NULL, > version = 2, : > ReadItem: unknown type 29, perhaps written by later version of R > > The same error happens when the serialization is done with version=2 > or version=3. It does not happen if the serialization is done with > ascii=FALSE. > > Note that 0x29 == 41. It looks like unserialize is reading the wrong > line. > > I tried this in earlier versions of R on Windows, and the same error > happens in every version from R-2.15.3 (the earliest I have) on up. > > ~~ Michael Sannella > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Surprise with plot.lm()
Here's a silly little stunt: > Y <- rexp(10) ; x <- 1:10 > plot(lm(I(Y^.3)~x)) Hit to see next plot: Hit to see next plot: Error: $ operator is invalid for atomic vectors The root cause is that the "AsIs" class lingers on the intercept passed to abline() via qqline(), so abline sees that it has been passed an object and uses coef() and coef.default() looks for object$coefficients, and... poof! The immediate workaround is just to drop the I(), but as I() is frequently needed on the right hand side of formulas, this looks like a rather easy mistake to make, so it might be worth fixing, but how? -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
> On 7 Oct 2018, at 16:04 , Rui Barradas wrote:
>
> Hello,
>
> I don't see why you say that the documentation seems to be wrong:
>
>
> class(args(`+`))
> #[1] "function"
>
>
> args() on a primitive does return a closure. At least in this case it does.
But in this case it doesn't:
> is.primitive(get("["))
[1] TRUE
> class(args(get("[")))
[1] "NULL"
Or, for that matter:
> is.primitive(`[`)
[1] TRUE
> class(args(`[`))
[1] "NULL"
-pd
>
>
> Rui Barradas
>
> Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
>> There is more "fun" afoot here, but I don't recall what the point may be:
>>> args(get("+"))
>> function (e1, e2)
>> NULL
>>> args(get("["))
>> NULL
>>> get("[")
>> .Primitive("[")
>>> get("+")
>> function (e1, e2) .Primitive("+")
>> The other index operators, "[[", "[<-", "[[<-" are similar
>> The docs are pretty clear that args() on a primitive should yield a closure,
>> so at least the documentation seems to be wrong.
>> -pd
>>> On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
>>>
>>> Hi,
>>>
>>> A short code example showing the warning might the only thing needed here:
>>>
>>> ```
>>>> formals(args(`[`))
>>> NULL
>>>
>>> *Warning message:In formals(fun) : argument is not a function*
>>>> is.function(`[`)
>>> [1] TRUE
>>>> is.primitive(`[`)
>>> [1] TRUE
>>> ```
>>>
>>> Now with an other primitive:
>>>
>>> ```
>>>> formals(args(`sum`))
>>> $...
>>>
>>>
>>> $na.rm
>>> [1] FALSE
>>>
>>>> is.function(`sum`)
>>> [1] TRUE
>>>> is.primitive(`sum`)
>>> [1] TRUE
>>>> class(`[`)
>>> [1] "function"
>>> ```
>>>
>>> Is this a feature ?
>>>
>>>
>>> Laurent
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
There is more "fun" afoot here, but I don't recall what the point may be:
> args(get("+"))
function (e1, e2)
NULL
> args(get("["))
NULL
> get("[")
.Primitive("[")
> get("+")
function (e1, e2) .Primitive("+")
The other index operators, "[[", "[<-", "[[<-" are similar
The docs are pretty clear that args() on a primitive should yield a closure, so
at least the documentation seems to be wrong.
-pd
> On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
>
> Hi,
>
> A short code example showing the warning might the only thing needed here:
>
> ```
>> formals(args(`[`))
> NULL
>
> *Warning message:In formals(fun) : argument is not a function*
>> is.function(`[`)
> [1] TRUE
>> is.primitive(`[`)
> [1] TRUE
> ```
>
> Now with an other primitive:
>
> ```
>> formals(args(`sum`))
> $...
>
>
> $na.rm
> [1] FALSE
>
>> is.function(`sum`)
> [1] TRUE
>> is.primitive(`sum`)
> [1] TRUE
>> class(`[`)
> [1] "function"
> ```
>
> Is this a feature ?
>
>
> Laurent
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Relevel confusing with numeric value
In a word, no. It is behaving as documented and adding a warning would just
confuse others who have been using the feature as intended.
This belongs in the same bin as "as.integer(f) vs as.integer(as.character(f))"
and "x[f] vs. x[as.character(f)]"
-pd
> On 2 Oct 2018, at 17:18 , Emil Bode wrote:
>
> Something that bit me:
> The function relevel takes a factor, and a reference level to be promoted to
> the first place.
> If “ref” is a character this level is promoted, if it’s a numeric the
> “ref”-th level is promoted.
> Which turns out to be very confusing if you have factor with numeric values
> (e.g. when reading in a csv with some dirty numeric columns and
> stringsAsFactors TRUE)
> For example:
>
> set.seed(1)
> test <- data.frame(n=sample(c(1:100, letters[1:10]), size=90))
> test$n <- relevel(test$n, 50)
> print(levels(test$n))
>
> gives “62” as the first level.
>
> Could we make something like this an error, or at least issue a warning?
> Also because some other functions automatically coerce, factor(…,
> levels=1:100) and levels(test$n) <- 1:100 works fine.
> So this is maybe the most confusing: relevel(factor(1:10, levels = -10:20),
> 15) gives “4” as the first level
>
> For now I’ve thought of 2 possible implementations, that could be inserted in
> stats::relevel.factor(), just before is.character(ref):
>
> if(is.numeric(ref) && ref %in% lev)
>warning('Provided numeric reference, note that this will promote the ',
> ref, 'th value, not level with value "', ref, '"!')
>
> or
>
> if(is.numeric(ref) && any(!is.na(suppressWarnings(as.numeric(lev)
>warning('Provided numeric reference, note that this will promote the ',
> ref, 'th value, not level with value "', ref, '"!')
>
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.b...@dans.knaw.nl<mailto:emil.b...@dans.knaw.nl>
>
> DANS: Netherlands Institute for Permanent Access to Digital Research Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
> i...@dans.knaw.nl<mailto:i...@dans.kn> |
> dans.knaw.nl
> DANS is an institute of the Dutch Academy KNAW<http://knaw.nl/nl> and funding
> organisation NWO<http://www.nwo.nl/>.
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug, max argument in print.default(), on R-3.5.1-patched
Not in print.default(), but in print.data.frame(), which is now doing its own
max= handling but not passing max to print.default (maechler, r75122 --- was
this really for r-patched?
-pd
> On 22 Sep 2018, at 23:46 , Gábor Csárdi wrote:
>
> The max argument of print.default() does not override
> options(max.print), see below.
> R 3.5.1 and R-devel both seem good.
>
> Gábor
>
>> options(max.print = 1)
>> print(data.frame(a=1:10))
> a
> 1 1
> [ reached 'max' / getOption("max.print") -- omitted 9 rows ]
>> print(data.frame(a=1:10), max = 100)
>a
> 1 1
> [ reached getOption("max.print") -- omitted 9 rows ]
>> options(max.print = 1000)
>> R.version
> _
> platform x86_64-w64-mingw32
> arch x86_64
> os mingw32
> system x86_64, mingw32
> status Patched
> major 3
> minor 5.1
> year 2018
> month 09
> day11
> svn rev75286
> language R
> version.string R version 3.5.1 Patched (2018-09-11 r75286)
> nickname Feather Spray
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A different error in sample()
Yup, that is a bug, at least in the documentation. Probably a clearer example
is
x <- seq(2.001, 2.999, length.out=999)
threes <- sapply(x, function(y) table(sample(y, 1, replace=TRUE))[3])
plot(threes, type="l")
curve(1*(x-2)/x, add=TRUE, col="red")
which is entirely consistent with what you'd expect from floor(runif(1, 0,
y)) + 1, and as far as I can tell from the source, that is what is happening
internally.
(Strict monotonicity is a bit of a red herring, it is jut a matter of having
spaced the y so far apart that the probability of an order reversal becomes
negligible.)
So either we should do what the documentation says we do, or the documentation
should not say that we do what we do not actually do...
The suspect code is this snippet from do_sample:
int n = (int) dn;
.
if (replace || k < 2) {
for (int i = 0; i < k; i++) iy[i] = (int)(R_unif_index(dn) + 1);
} else {
int *x = (int *)R_alloc(n, sizeof(int));
for (int i = 0; i < n; i++) x[i] = i;
for (int i = 0; i < k; i++) {
int j = (int)(R_unif_index(n));
iy[i] = x[j] + 1;
x[j] = x[--n];
}
}
(notice arguments to R_unif_index)
-pd
> On 20 Sep 2018, at 01:53 , lmo via R-devel wrote:
>
> Although it seems to be pretty weird to enter a numeric vector of length one
> that is not an integer as the first argument to sample(), the results do not
> seem to match what is documented in the manual. In addition, the results
> below do not support the use of round rather than truncate in the
> documentation. Consider the code below.
> The first sentence in the details section says: "If x has length 1, is
> numeric (in the sense of is.numeric) and x >= 1, sampling via sample takes
> place from 1:x."
> In the console:> 1:2.001
> [1] 1 2
>> 1:2.9
> [1] 1 2
>
> truncation:
>> trunc(2.9)
> [1] 2
>
> So, this seems to support the quote from in previous emails: "Non-integer
> positive numerical values of n or x will be truncated to the next smallest
> integer, which has to be no larger than .Machine$integer.max."
> However, again in the console:> set.seed(123)
>> table(sample(2.001, 1, replace=TRUE))
>
>123
> 5052 49417
>
> So, neither rounding nor truncation is occurring. Next, define a sequence.
>> x <- seq(2.001, 2.51, length.out=20)
> Now, grab all of the threes from sample()-ing this sequence.
>
>> set.seed(123)
>> threes <- sapply(x, function(y) table(sample(y, 1, replace=TRUE))[3])
>
> Check for NAs (I cheated here and found a nice seed).> any(is.na(threes))
> [1] FALSE
> Now, the (to me) disturbing result.
>
>> is.unsorted(threes)
> [1] FALSE
>
> or equivalently
>
>> all(diff(threes) > 0)
> [1] TRUE
>
> So the number of threes grows monotonically as 2.001 moves to 2.5. As I
> hinted above, the monotonic growth is not assured. My guess is that the
> growth is stochastic and relates to some "probability weighting" based on how
> close the element of x is to 3. Perhaps this has been brought up before, but
> it seems relevant to the current discussion.
> A potential aid to this issue would be something like
> if(length(x) == 1 && !all.equal(x, as.integer(x))) warning("It is a bad idea
> to use vectors of length 1 in the x argument that are not integers.")
> Hope that helps,luke
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] R graphics 'text' package 'adj' parameter order wrong incorrect reversed?
Exactly. And left alignment means that the left end of the text is aligned with the anchor point, etc. So documentation is correct. -pd > On 19 Sep 2018, at 01:33 , Jim Lemon wrote: > > Hi Simon, > I think the conventions of typesetting are to blame. Think of an > invisible box around the text being displayed. > __ > |Left justification | > |-| > meaning that the text _starts_ at the left of the field and is to the > right of the text position specified > __ > |Right justification| > |-| > > meaning that the text _ends_ at the right of the field and is to the > left of the text position. Can't do the top and bottom justification > this way, but I think you get the idea. > > Jim > > On Wed, Sep 19, 2018 at 9:13 AM Simon Dedman wrote: >> >> Original stack overflow post here: >> https://stackoverflow.com/questions/52194719/r-graphic-text-package-adj-parameter-order-wrong-incorrect-reversed >> >> Hopefully this is now the appropriate place to post this as the above post >> got a single comment of agreement. >> >> Content: >> >> I believe R core package graphics text function's adj parameter is >> incorrectly described in the manual >> <https://stat.ethz.ch/R-manual/R-devel/library/graphics/html/text.html> and >> would be grateful if someone could confirm this before I submit a bug report >> <https://www.r-project.org/bugs.html>. >> >> adj text: >> >> adj allows adjustment of the text with respect to (x, y). Values of 0, 0.5, >> and 1 specify left/bottom, middle and right/top alignment, respectively. >> >> Since text controls these labels and not the points which have already been >> plotted, I can't see how "with respect to x,y" can mean anything other than >> "in this direction relative to their points". >> >> However the order is reversed: 0,0 (supposedly left & bottom) is top & >> right; 1,1 (supposedly right & top) is left and bottom. >> >> Reproducible example: >> >> tens = 1:10 >> plot(tens, tens, xlab = "adj 0,0 left/bottom") >> text(tens, tens, labels = letters[tens], adj = c(0,0)) >> plot(tens, tens, xlab = "adj 0.5,0.5 middle") >> text(tens, tens, labels = letters[tens], adj = c(0.5,0.5)) >> plot(tens, tens, xlab = "adj 1,1 right/top") >> text(tens, tens, labels = letters[tens], adj = c(1,1)) >> >> Thanks. >> >>[[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] diag(-1) produces weird result
Yes, both are rooted in age-old design infelicities (in which, basically, interactive expedience has taken precedence over consistency and generality). Unfortunately, they are quite difficult to rectify, because there are bound to be countless uses of, say, diag(5) as a 5x5 identity matrix which would break if it suddenly meant the 1x1 matrix(5) instead. We'd need a very carefully orchestrated warn-deprecate-defunct-newBehaviour sequence, with a time scale of years, most likely. It is, in principle, doable (I think), but we don't really have the mechanisms to follow through on it. Almost all developers have main job responsibilities, and it is very easy to get sidetracked at the wrong moment, so most changes get done on a now-or-never basis. I have toyed with the idea of setting up for version-dependent code where code sections could be coded up front and then activated when the relevant version is reached. Then I got swamped again... -pd > On 17 Sep 2018, at 20:08 , Barry Rowlingson > wrote: > > On Mon, Sep 17, 2018 at 5:22 PM, Gábor Csárdi > wrote: > >> I would say it is a mis-feature. If the 'x' argument of diag() is a >> vector of length 1, then it creates an identity matrix of that size, >> instead of creating a 1x1 matrix with the given value: >> >> ❯ diag(3) >> [,1] [,2] [,3] >> [1,]100 >> [2,]010 >> [3,]001 >> >> Of course this makes it cumbersome to use diag() in a package, when >> you are not sure if the input vector is longer than 1. This seems to >> be a good workaround: >> >> ❯ diag(-1, nrow = 1) >> [,1] >> [1,] -1 >> >> Or, in general if you have vector v: >> >> ❯ v <- -1 >> ❯ diag(v, nrow = length(v)) >> [,1] >> [1,] -1 >>> >> > > Anyone else getting deja-vu with the `sample` function? > >> sample(5:3) > [1] 3 5 4 > > ok... > >> sample(5:4) > [1] 4 5 > > fine... > >> sample(5:5) > [1] 3 1 5 2 4 > > uh oh. Documented, of course. > > B > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svg ignores cex.axis in R3.5.1 on macOS
gt;> locale: >> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] compiler_3.5.1 >> >> >> ** The axis labels are appropriately expanded with the first >> "plot(1:2, cex.axis=2)". However, when I wrote that to an svg file >> and opened it in other applications (GIMP and Safari), the cex.axis >> request was ignored. This also occurred inside RStudio on my Mac. It >> worked properly using R 3.2.1 under Windows 7. > > >I just confirmed that when I created a file like this under Windows 7 >and brought it back to my Mac, it displayed fine. I have not tried this >with the current version of R under Windows 7 nor an old version of R on >my Mac. Thanks. Spencer >> >> >> Thanks, >> Spencer Graves >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warnings on Windows
I don't think this has anything to do with Fortran. The full warning message is presumably like Warning: S3 methods . . . were declared in NAMESPACE but not found which according to google-fu happens if you are declaring methods from a package that isn't loaded, in this case possibly dplyr. On previous occasions, this has happened due to race conditions so that one package is not completely updated before another is installed, and that could well be the case if you see trouble on just the one platform, so maybe wait and see if the warning goes away. Otherwise, check for missing dependencies. > On 14 Aug 2018, at 17:00 , Wang, Zhu wrote: > > Hi all, > > For the R package bujar, the warnings below were generated on CRAN's Windows > systems. The package uses some Fortran subroutines. I would appreciate any > advice to eliminate the warnings. By the way, similar warnings were generated > to some unrelated R packages as well: > https://www.r-project.org/nosvn/R.check/r-oldrel-windows-ix86+x86_64/imputeTS-00check.html. > > Thanks in advance. > > Zhu Wang > > https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/bujar-00check.html > > > * installing *source* package 'bujar' ... > ** package 'bujar' successfully unpacked and MD5 sums checked > ** R > ** data > ** inst > ** byte-compile and prepare package for lazy loading > Warning: S3 methods '[.fun_list', '[.grouped_df', 'all.equal.tbl_df', > 'anti_join.data.frame', 'anti_join.tbl_df', 'arrange.data.frame', > 'arrange.default', 'arrange.grouped_df', 'arrange.tbl_df', > 'arrange_.data.frame', 'arrange_.tbl_df', 'as.data.frame.grouped_df', > 'as.data.frame.rowwise_df', 'as.data.frame.tbl_cube', 'as.data.frame.tbl_df', > 'as.table.tbl_cube', 'as.tbl.data.frame', 'as.tbl.tbl', 'as.tbl_cube.array', > 'as.tbl_cube.data.frame', 'as.tbl_cube.matrix', 'as.tbl_cube.table', > 'as_data_frame.grouped_df', 'as_data_frame.tbl_cube', 'auto_copy.tbl_cube', > 'auto_copy.tbl_df', 'cbind.grouped_df', 'collapse.data.frame', > 'collect.data.frame', 'common_by.NULL', 'common_by.character', > 'common_by.default', 'common_by.list', 'compute.data.frame', > 'copy_to.DBIConnection', 'copy_to.src_local', 'default_missing.data.frame', > 'default_missing.default', 'dim.tbl_cube', 'distinct.data.frame', > 'distinct.default', 'distinct.grouped_df', 'distinct.tbl_df', > 'distinct_.data.frame', 'distinct_.grouped > _df', 'dist [... truncated] > ** help > *** installing help indices > ** building package indices > ** installing vignettes > ** testing if installed package can be loaded > *** arch - i386 > Warning: S3 methods '[.fun_list', '[.grouped_df', 'all.equal.tbl_df', > 'anti_join.data.frame', 'anti_join.tbl_df', 'arrange.data.frame', > 'arrange.default', 'arrange.grouped_df', 'arrange.tbl_df', > 'arrange_.data.frame', 'arrange_.tbl_df', 'as.data.frame.grouped_df', > 'as.data.frame.rowwise_df', 'as.data.frame.tbl_cube', 'as.data.frame.tbl_df', > 'as.table.tbl_cube', 'as.tbl.data.frame', 'as.tbl.tbl', 'as.tbl_cube.array', > 'as.tbl_cube.data.frame', 'as.tbl_cube.matrix', 'as.tbl_cube.table', > 'as_data_frame.grouped_df', 'as_data_frame.tbl_cube', 'auto_copy.tbl_cube', > 'auto_copy.tbl_df', 'cbind.grouped_df', 'collapse.data.frame', > 'collect.data.frame', 'common_by.NULL', 'common_by.character', > 'common_by.default', 'common_by.list', 'compute.data.frame', > 'copy_to.DBIConnection', 'copy_to.src_local', 'default_missing.data.frame', > 'default_missing.default', 'dim.tbl_cube', 'distinct.data.frame', > 'distinct.default', 'distinct.grouped_df', 'distinct.tbl_df', > 'distinct_.data.frame', 'distinct_.grouped > _df', 'dist [... truncated] > *** arch - x64 > Warning: S3 methods '[.fun_list', '[.grouped_df', 'all.equal.tbl_df', > 'anti_join.data.frame', 'anti_join.tbl_df', 'arrange.data.frame', > 'arrange.default', 'arrange.grouped_df', 'arrange.tbl_df', > 'arrange_.data.frame', 'arrange_.tbl_df', 'as.data.frame.grouped_df', > 'as.data.frame.rowwise_df', 'as.data.frame.tbl_cube', 'as.data.frame.tbl_df', > 'as.table.tbl_cube', 'as.tbl.data.frame', 'as.tbl.tbl', 'as.tbl_cube.array', > 'as.tbl_cube.data.frame', 'as.tbl_cube.matrix', 'as.tbl_cube.table', > 'as_data_frame.grouped_df', 'as_data_frame.tbl_cube', 'auto_copy.tbl_cube', > 'auto_copy.tbl_df', 'cbind.grouped_df', 'collapse.data.frame', > 'collect.data.frame', 'common_by.NULL', 'common_by.character', > 'common_by.default', 'common_by.list', 'compute.data.frame', > 'copy_to.DBIConnection', 'copy_to.src_local', 'default_missing.data.frame', > 'default_missing.default', 'dim.tbl_cube', 'distinct.data.frame', > 'distinct.default', 'distinct.grouped_df', 'distinct.tbl_df', > 'distinct_.data.frame', 'distinct_.grouped > _df', 'dist [... truncated] > * MD5 sums > packaged installation of 'bujar' as bujar_0.2-3.zip > * DONE (bujar) > In R CMD INSTALL > > > **Connecticut Children's Confidentiality Notice** > This e-mail message, including any attachments, is
Re: [R-pkg-devel] Replicate solaris errors
Have you tried asking CRAN for help? I mean, if you don't fix an obvious error, with a well-known cause, like the log thing, they'll get fed up and throw you off. However, fixing and then discovering an issue elsewhere is different, especially if you cannot easily reproduce it at your end. -pd > On 11 Aug 2018, at 20:41 , Thibault Vatter wrote: > > Yes, the non-portable call to log which causes the current build to fail on > solaris has been corrected in a development version. However, the segfault > that we don't understand and were asked to correct was present in the > previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that it > is likely to reappear if we resubmit with only the non-portable log call > corrected. > > This is why, in order to avoid resubmitting with the segfault still there > and having the package removed from CRAN, we would like to be able to > replicate the solaris build. > > On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar wrote: > >> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter >> () escribió: >>> >>> Dear package developers, >>> >>> We've recently received an email letting us know that our package >>> rvinecopulib ( >>> https://cran.r-project.org/web/packages/rvinecopulib/index.html) would >> be >>> removed from CRAN unless the errors from the solaris build were >> corrected. >>> >>> Note that the package compile and the unit tests pass on the other test >>> platforms from CRAN and even a local R devel build with ASAN / UBSAN >>> sanitizers. On solaris, the package compiles but a segfault is produced >> by >>> one unit test for a reason that we still don't understand. >> >> Are you talking about a new development version that is not still on >> CRAN? Because the current CRAN version fails to install. >> >> Iñaki >> >>> >>> To replicate the issue, I tried to mimic CRAN's solaris config ( >>> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a >>> virtual machine following the steps in the gist below (based on >> Jeroen's): >>> >>> https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6 >>> >>> Note that the "--with-readline=no" configure option at the end was added >>> because I got "configure: error: --with-readline=yes (default) and >>> headers/libs are not available" without it. >>> >>> Unfortunately, I then got the "configure: error: a suitable iconv is >>> essential" and could not proceed to build R. >>> >>> I know that I should get GNU iconv as specified in the installation >> manual, >>> hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I >>> verified that iconv is in /opt/csw/lib as expected and I thought that >>> adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would >>> then do the trick, but it does not seem to be the case. >>> >>> Two questions: >>> >>> 1) What did I miss or do wrong? >>> >>> 2) Anyone found a way to replicate solaris CRAN builds to test packages? >> I >>> tried to use https://builder.r-hub.io/, but some of my package's >>> dependencies fail to install because of udunits2 is missing on their >> system >>> if I recall correctly. >>> >>> Thibault >>> >>>[[alternative HTML version deleted]] >>> >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
