Re: [Rd] alpha transparency doesn't work for lines when xpd=TRUE
> On Apr 16, 2018, at 10:41 AM, Jiaxuan Chen > wrote: > > Dear R-devel, > > I think I've found a bug - the alpha transparency doesn't work when plotting > lines with xpd = TRUE. > > #works > plot(1:20, col="#1874CD", xpd=T, type="l") > > #works > plot(1:20, col="#1874CD50", xpd=F, type="l") > > #doesn't work > plot(1:20, col="#1874CD50", xpd=T, type="l") It's behaving as expected (last two lines light blue) on a Mac (El Capitan) and R 3.4.3. (I did check to see if T and F were still TRUE and FALSE at the time. It's possible that they were not in your session. Only TRUE and FALSE are reserved words.) > > Thank you. > > Jim > > > [[alternative HTML version deleted]] All the R mailing lists are plain text. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange warning: data() error?
> On Apr 16, 2018, at 2:58 PM, Therneau, Terry M., Ph.D. via R-devel
> wrote:
>
> A user asked me about this and I can't figure it out.
>
> tmt% R
> R Under development (unstable) (2018-04-09 r74565) -- "Unsuffered
> Consequences"
> Copyright (C) 2018 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> > library(survival)
> > data(cgd0)
> Warning message:
> In data(cgd0) : data set ‘cgd0’ not found
>
>
>
> The data set is present and can be manipulated: data() is not required.
> Other data sets in the survival package don't generate this message.
On a Mac the Data Manager panel lists that dataset as "cgd0 (cgd)" and I get
the same warning with any dataset that has a similar appearance of , even the `state.abb` vector that is displayed "state.abb
(state)" (without the quotes.)
> data('state.abb')
Warning message:
In data("state.abb") : data set ‘state.abb’ not found
> str(state.abb)
chr [1:50] "AL" "AK" "AZ" "AR" "CA" "CO" "CT" "DE" "FL" "GA" "HI" "ID" "IL"
"IN" "IA" "KS" "KY" "LA" "ME" "MD" "MA" ...
> data(stack.loss)
Warning message:
In data(stack.loss) : data set ‘stack.loss’ not found
So I guess the message is don't feel picked upon. It seems to be an infelicity
shared by many other datasets even those in the canonical 'datasets' package.
>
> Terry T.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
'Any technology distinguishable from magic is insufficiently advanced.'
-Gehm's Corollary to Clarke's Third Law
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange warning: data() error?
> On Apr 16, 2018, at 3:20 PM, David Winsemius wrote:
>
>>
>> On Apr 16, 2018, at 2:58 PM, Therneau, Terry M., Ph.D. via R-devel
>> wrote:
>>
>> A user asked me about this and I can't figure it out.
>>
>> tmt% R
>> R Under development (unstable) (2018-04-09 r74565) -- "Unsuffered
>> Consequences"
>> Copyright (C) 2018 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>>> library(survival)
>>> data(cgd0)
>> Warning message:
>> In data(cgd0) : data set ‘cgd0’ not found
>>
>>
>>
>> The data set is present and can be manipulated: data() is not required.
>> Other data sets in the survival package don't generate this message.
>
> On a Mac the Data Manager panel lists that dataset as "cgd0 (cgd)" and I get
> the same warning with any dataset that has a similar appearance of paren-name-paren> , even the `state.abb` vector that is displayed "state.abb
> (state)" (without the quotes.)
>
>> data('state.abb')
> Warning message:
> In data("state.abb") : data set ‘state.abb’ not found
>> str(state.abb)
> chr [1:50] "AL" "AK" "AZ" "AR" "CA" "CO" "CT" "DE" "FL" "GA" "HI" "ID" "IL"
> "IN" "IA" "KS" "KY" "LA" "ME" "MD" "MA" ...
>> data(stack.loss)
> Warning message:
> In data(stack.loss) : data set ‘stack.loss’ not found
>
> So I guess the message is don't feel picked upon. It seems to be an
> infelicity shared by many other datasets even those in the canonical
> 'datasets' package.
> survival_Rdata <-
> readRDS("/Library/Frameworks/R.framework/Versions/3.4/Resources/library/survival/data/Rdata.rds")
> survival_Rdata
$bladder
[1] "bladder" "bladder1" "bladder2"
$cancer
[1] "cancer"
$cgd
[1] "cgd" "cgd0"
$colon
[1] "colon"
$flchain
[1] "flchain"
$genfan
[1] "genfan"
$heart
[1] "heart" "jasa" "jasa1"
--- snip
data(bladder2)
# Warning message:
# In data(bladder2) : data set ‘bladder2’ not found
data(mgus1)
# Warning message:
# In data(mgus1) : data set ‘mgus1’ not found
> data(mgus1)
Warning message:
In data(mgus1) : data set ‘mgus1’ not found
> data("survexp.mn")
Warning message:
In data("survexp.mn") : data set ‘survexp.mn’ not found
Hypothesis: datasets in a ..library/data/Rdata.rds file whose listing does
not match the name of the dataset from which it is derived will cause the
behavior in question.
And Terry; After executing `data(package-"survival")` I must mention that the
spelling of "Granulomatous" is not "Granulotomous", and neither is the spelling
of "gammapathy", "gammapothy".
--
David Winsemius
Alameda, CA, USA
'Any technology distinguishable from magic is insufficiently advanced.'
-Gehm's Corollary to Clarke's Third Law
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embeded R application on Windows prints broken character.
> On Apr 26, 2018, at 4:25 PM, Randy Lai wrote: > > The issue was reported to me for https://github.com/randy3k/rtichoke/issues/50 > which is a python program which embeds R and provides a interface to R. > > With R 3.5, for reason which i don't understand, when I typed `"a"` in the > console > STDOUT got `"\x02\xff\xfea\x03\xff\xfe"` with the extra escaped characters. > > I notice that `\x02\xff\xfe` and `\x03\xff\xfe` are encoding related byte > marks. > A clear solution is to filter the escaped characters, but I want to > understand what > changes are causing it happens. It didn’t happen for R 3.4. The maintainer (randy3k, oh that's you) of that python package has apparently fixed it: https://github.com/randy3k/rtichoke/commit/4e29747c47f03381b319665943e290f17fd7914f > Randy > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odd behavior of names
> On Jul 29, 2018, at 6:31 AM, Gabor Grothendieck > wrote: > > The first component name has backticks around it and the second does > not. Though not wrong, it seems inconsistent. > > list(a = 1, b = 2) > ## $`a` > ## [1] 1 > ## > ## $b > ## [1] 2 > > R.version.string > ## [1] "R version 3.5.1 Patched (2018-07-02 r74950)" Agree it would be unexpected. Unable to reproduce on Mac: list(a = 1, b = 2) #-- $a [1] 1 $b [1] 2 R.version.string #[1] "R version 3.5.1 (2018-07-02)" Platform: x86_64-apple-darwin15.6.0 (64-bit) > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] code for sum function
On 2/20/19 2:55 PM, Rampal Etienne wrote: Dear Tomas, Where do I find these files? Do they contain the code for the sum function? Yes. https://svn.r-project.org/R/trunk/ David What do you mean exactly with your point on long doubles? Where can I find documentation on this? Cheers, Rampal On Mon, Feb 18, 2019, 15:38 Tomas Kalibera See do_summary() in summary.c, rsum() for doubles. R uses long double type as accumulator on systems where available. Best, Tomas On 2/14/19 2:08 PM, Rampal Etienne wrote: Hello, I am trying to write FORTRAN code to do the same as some R code I have. I get (small) differences when using the sum function in R. I know there are numerical routines to improve precision, but I have not been able to figure out what algorithm R is using. Does anyone know this? Or where can I find the code for the sum function? Regards, Rampal Etienne __ 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
Re: [Rd] point size in svg
On 6/19/19 8:19 AM, Spencer Graves wrote:
Hello, All:
I'm unable to control the font size in plots to svg. Consider
the following:
svg('cex-svg.svg')
cex. <- 5
plot(1:2, cex.axis=cex.)
text(1:2, 1:2, c('as', 'DF'),
cex=cex.)
dev.off()
When I open this in Gimp 2.10.4, the font size is tiny. I also
tried:
svg('cex-svg.svg', width=15, height=15, pointsize=24)
cex. <- 5
plot(1:2, cex.axis=cex.)
text(1:2, 1:2, c('as', 'DF'),
cex=cex.)
dev.off()
What do I do to control the font size in svg?
I'm unable to reproduce. (I get very large fonts in all three viewing
methods: Rstudio plot panel, ImageViewer and GIMP)
Ubuntu 18.04
R 3.15.2
Gimp 2.10.12
Looking at ?svg makes me think you should be looking at the Cairo Fonts
section of ?X11.
Best;
David.
Thanks,
Spencer Graves
sessionInfo()
R version 3.6.0 (2019-04-26)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.5
Matrix products: default
BLAS:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib
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
[6] methods base
other attached packages:
[1] Ecdat_0.3-2 Ecfun_0.2-1
__
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] dput()
On 2/28/20 11:42 PM, Rui Barradas wrote: Hello, FAQ 7.31 See also this StackOverflow post: https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal That was going to be my initial response, but then I realized that the question might be why the dput representation of the x variable didn't display the detail of the decimal fraction out at the 16th or seventeenth place. So here's some further results to chew on: 1 (rather than 0.99955591) is what would get if `dput` were used to send it to a file: dput(x, file="temp.txt") x <- scan(file="temp.txt") #Read 1 item x==1 #[1] TRUE And if you wanted more precision with the value before it got rectified by output/input you could use the control parameter: dput(x, control="digits17") #0.99956 HTH; David. Hope this helps, Rui Barradas Às 00:08 de 29/02/20, robin hankin escreveu: My interpretation of dput.Rd is that dput() gives an exact ASCII form of the internal representation of an R object. But: rhankin@cuttlefish:~ $ R --version R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) [snip] rhankin@cuttlefish:~ $ R --vanilla --quiet x <- sum(dbinom(0:20,20,0.35)) dput(x) 1 x-1 [1] -4.440892e-16 x==1 [1] FALSE So, dput(x) gives 1, but x is not equal to 1. Can anyone advise? __ 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
Re: [Rd] [R] scalable < > delimiters in plotmath
On Sep 12, 2010, at 11:38 PM, Paul Murrell wrote:
Hi
[shifting to r-devel]
On 13/09/2010 8:43 a.m., David Winsemius wrote:
On Sep 12, 2010, at 4:11 PM, Paul Murrell wrote:
Hi
On 13/09/2010 7:57 a.m., baptiste auguie wrote:
Oh, right I see. I was completely off then. Maybe it's not so
easy to
add<> delimiters after all, I'll have to look at the list of
symbol
pieces to see if these can be constructed too.
The plotmath stuff assumes a font with an Adobe Symbol encoding.
The characters we have to play with are shown at
http://www.stat.auckland.ac.nz/~paul/R/CM/AdobeSym.pdf
.
You can see the components of "growable" delimiters on the bottom
two rows.
Hello Paul;
Both Baptiste and I have looked at the plotmath.c code and it appears
that only a few of those delimiters are supported. We specifically
have tried to use the angle brackets:
> plot(1,1,
xlab=expression(bgroup(symbol(0xe1),atop(x,y),symbol(0xf1
Error in bgroup(symbol(225), atop(x, y), symbol(241)) :
invalid group delimiter
The supported delimiters appear to each be built up from three parts
that are then assembled within a bounding box and as far as I can
determine are limited to "|", "||", "[", "{", "(", ")", "}",and
"}". I
needed to download the full source to find a copy, but I'm fairly
sure
a guRu of your standing needs no help finding the code that handles
the bgroup display inside plotmath.c. I am not at my machine where I
was looking at it, but the code that I just found in expanded form on
the Internet bore your name as a copyright holder.
So I guess my feature request would be:
---add option for using scalable single character delimiters such as
Symbol(0xe1) and Symbol(0xe1).
Meant to type e1 and f1.
Unfortunately, I don't think this is trivial. How are these
supposed to scale? Just get drawn bigger? (which is unlikely to
produce nice results because the lines will get thicker).
My thought was thought was that these were unlikely to be called into
play when they were going to be surrounding multiple lines of text so
would not be expected to scale up as might matrix brackets, but would
rather be used in situations where they represented either means or
physical quantities. In statistical mechanics angle-brackets are the
time averages of quantities like pressure, while in quantum mechanics
physical quantities are the probabilities resulting from wave/matrix
equations involving products of bra's, "<(.)|", and kets, "|(.)>",
representing complex conjugates possibly with a function in between
"< | | >". I would think that including the Symbol(0xf1) and
Symbol(0xe1) simply as "drawn bigger" would be one approach. I would
think another approach could be to increase the height by a greater
ratio than the width, say 1.5 to 1. I don't know what complications
arise in doing so, but would imagine that these would be no worse than
the scaling problems arising with the Greek Sigma.
a) http://en.wikipedia.org/wiki/Bra-ket_notation
b) Table VIII of"Reviews of Modern Physics Style Guide":
http://www.rmp.aps.org/files/rmpgui15.pdf
c) http://www.physics.unlv.edu/~bernard/phy721_99/tex_notes/node8.html
I'm guessing that the reason three-component delimiters were chosen
is
that it was easier to expand the middle section while not expanding
the ends as much but that's just the guess of someone who is perusing
without really being able to fully grasp the intricacies of what is
being done.
That's about right. This is all modelled on TeX's equation
formatting algorithms. The Computer Modern fonts have this kind of
extendable components for very large delimiters, but for angled
brackets it looks like the TeX solution is just to offer various
"big" versions. For example, try the following TeX document ...
\documentclass{article}
\begin{document}
\[ \left\{
\begin{array}{ccc}
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
d & e & f \end{array}
\right\} \]
\[ \left\langle
\begin{array}{ccc}
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
a & b & c \\
d & e & f \end{array}
\right\rangle \]
\end{document}
I see the problem with that construction, although as I said above, I
don't think the angle brackets would be used very much in enclosing 8
line constructs. Is there no way to scale the \langle and \rangle by a
factor of three before prefixing and postfixing a grouped array?
( and plotmath doesn't really support grou
Re: [Rd] Crash report: regexpr("a{2-}", "")
On Sep 21, 2010, at 11:04 PM, Henrik Bengtsson wrote:
Each of the following calls crash ("core dumps") R (R --vanilla) on
various versions and OSes:
regexpr("a{2-}", "")
sub("a{2-}", "")
gsub("a{2-}", "")
EXAMPLES:
sessionInfo()
R version 2.11.1 Patched (2010-09-16 r52949)
Platform: i386-pc-mingw32 (32-bit)
...
regexpr("a{2-}", "")
Assertion failed: iter->max == -1 || iter->max == 1, file
tre-compile.c, line 1825
This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
sessionInfo()
R version 2.12.0 Under development (unstable) (2010-09-14 r52910)
Platform: i386-pc-mingw32/i386 (32-bit)
...
regexpr("a{2-}", "")
Assertion failed: iter->max == -1 || iter->max == 1, file
tre-compile.c, line 1825
This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
sessionInfo()
R version 2.11.0 Patched (2010-05-09 r51960)
x86_64-unknown-linux-gnu
...
regexpr("a{2-}", "")
R: tre-compile.c:1825: tre_ast_to_tnfa: Assertion `iter->max == -1 ||
iter->max == 1' failed.
Aborted
Not a problem in reasonably current Mac with 64bit GUI:
> regexpr("a{2-}", "")
[1] 1
attr(,"match.length")
[1] 0
> sub("a{2-}", "")
Error in is.character(x) : 'x' is missing
> gsub("a{2-}", "")
Error in is.character(x) : 'x' is missing
R version 2.11.1 Patched (2010-08-26 r52822)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
[R.app GUI 1.35 (5612) x86_64-apple-darwin9.8.0]
--
David.
/Henrik
__
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] Crash report: regexpr("a{2-}", "")
On Sep 22, 2010, at 12:12 AM, Henrik Bengtsson wrote:
David's post made me realize that I got the sub()/gsub() lines wrong.
It should be:
regexpr("a{2-}", "")
sub("a{2-}", "", "")
gsub("a{2-}", "", "")
Still no crash on a Mac. Did you mean to include a third argument to
regexpr() as you did for sub and gsub?
--
David.
Either way, the crash is there, at on least Windows and Linux.
/Henrik
On Tue, Sep 21, 2010 at 8:43 PM, David Winsemius > wrote:
On Sep 21, 2010, at 11:04 PM, Henrik Bengtsson wrote:
Each of the following calls crash ("core dumps") R (R --vanilla) on
various versions and OSes:
regexpr("a{2-}", "")
sub("a{2-}", "")
gsub("a{2-}", "")
EXAMPLES:
sessionInfo()
R version 2.11.1 Patched (2010-09-16 r52949)
Platform: i386-pc-mingw32 (32-bit)
...
regexpr("a{2-}", "")
Assertion failed: iter->max == -1 || iter->max == 1, file
tre-compile.c, line 1825
This application has requested the Runtime to terminate it in an
unusual
way.
Please contact the application's support team for more information.
sessionInfo()
R version 2.12.0 Under development (unstable) (2010-09-14 r52910)
Platform: i386-pc-mingw32/i386 (32-bit)
...
regexpr("a{2-}", "")
Assertion failed: iter->max == -1 || iter->max == 1, file
tre-compile.c, line 1825
This application has requested the Runtime to terminate it in an
unusual
way.
Please contact the application's support team for more information.
sessionInfo()
R version 2.11.0 Patched (2010-05-09 r51960)
x86_64-unknown-linux-gnu
...
regexpr("a{2-}", "")
R: tre-compile.c:1825: tre_ast_to_tnfa: Assertion `iter->max == -1
||
iter->max == 1' failed.
Aborted
Not a problem in reasonably current Mac with 64bit GUI:
regexpr("a{2-}", "")
[1] 1
attr(,"match.length")
[1] 0
sub("a{2-}", "")
Error in is.character(x) : 'x' is missing
gsub("a{2-}", "")
Error in is.character(x) : 'x' is missing
R version 2.11.1 Patched (2010-08-26 r52822)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
[R.app GUI 1.35 (5612) x86_64-apple-darwin9.8.0]
--
David.
/Henrik
__
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
Re: [Rd] library verbose option doesn't stop "Loading required package XYZ"
On Oct 20, 2010, at 6:49 PM, Dominick Samperi wrote: Hello, The library verbose option does not stop numerous messages of the form "Loading required package: XYZ". This is inconvenient when a package is loaded repeatedly using Rscript. Is there a way to turn off the "Loading required package" messages? ?invisible > invisible(require(Hmisc)) > invisible(library(rms) ) # no console messages I do not think this suppress the messages when you attempt to load a non-existent package. For that you may need to look at the options() setting for warn and warning.expression One possible work-around is to make packages Suggested instead of Required, but this introduces other issues. Thanks, Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "$<-" fails (invalid subscript type 'language')
On Oct 24, 2010, at 5:35 AM, Vitalie S. wrote: This might be just beyond of my understanding of how assignment works in R, but the documentation does not say anything about: tv <- c(a="dsf", b="sss") tl <- list(232) `$<-`(tl, tv[[1]], "sdfdsfdsfsd") Error: invalid subscript type 'language' Are either of these what you should have done to get what it appears you were aiming for but didn't specify? `$<-`(tl, "sdfdsfdsfsd", tv[[1]]) # yields [[1]] [1] 232 $sdfdsfdsfsd [1] "dsf" > `[<-`(tl, tv[[1]], "sdfdsfdsfsd") [[1]] [1] 232 $dsf [1] "sdfdsfdsfsd" The "$" operator does not evaluate the index whereas the "[" function does. And the documentation is quite clear about that distinction. -- David Winsemius. This happens even before the method is dispatched. I can not handle the "name" argument in my S4 method, because it's not even entered. Thanks, Vitalie. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Indexing request
I just tried ?Constants at the console and was disappointed that the so-named base help page would not come up. > ?Constants No documentation for 'Constants' in specified packages and libraries: you could try '??Constants' Seems like there should have been a match. I was looking for the month abbreviations, failing to hit the right name 4 times and then failing 3 more times on variations of what I remembered to be the name of that page and finally ended up typing: ?letters -- David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R limits documented?
On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote: Is there documentation on R limits? That is, max matrix size, etc.? Diagnostics when limits are exceeded are not always meaningful. For example: x <- rep(0,5*5) Error in rep(0, 5 * 5) : invalid 'times' argument In addition: Warning message: In as.vector(data) : NAs introduced by coercion > x <- rep(0,4*5) > gc() used(Mb) gc trigger(Mb) max used(Mb) Ncells4673306 249.66945861 371.05315868 283.9 Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9 > object.size(x) 1600040 bytes So that is about 2/3 of my installed memory. This seems to be a limitation due to the maximum positive integer being ~ 2*10^9 > 2*10^9 < 5*5 [1] TRUE > 2*10^9 < 4*5 [1] FALSE Here's another example: library(orthopolynom) hermite <- hermite.h.polynomials(1001) hermite[[1001]] # should display 1000-th degree polynomial Error in if (signs[1] == "- ") "-" else "" : missing value where TRUE/FALSE needed Sounds as though the maximum length of an element of type character has been exceeded. Thanks, Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R limits documented?
On Feb 11, 2011, at 8:46 PM, Simon Urbanek wrote:
On Feb 11, 2011, at 8:45 PM, Simon Urbanek wrote:
On Feb 11, 2011, at 7:55 PM, David Winsemius wrote:
On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote:
Is there documentation on R limits?
That is, max matrix size, etc.?
Diagnostics when limits are exceeded are not always
meaningful. For example:
x <- rep(0,5*5)
Error in rep(0, 5 * 5) : invalid 'times' argument
In addition: Warning message:
In as.vector(data) : NAs introduced by coercion
x <- rep(0,4*5)
gc()
used(Mb) gc trigger(Mb) max used(Mb)
Ncells4673306 249.66945861 371.05315868 283.9
Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9
object.size(x)
1600040 bytes
So that is about 2/3 of my installed memory. This seems to be a
limitation due to the maximum positive integer being ~ 2*10^9
2*10^9 < 5*5
[1] TRUE
2*10^9 < 4*5
[1] FALSE
The actual limit is for obvious reasons 2^31-1
as.integer(2^31-1)
[1] 2147483647
as.integer(2^31)
[1] NA
Warning message:
NAs introduced by coercion
(ok, for those that this is not obvious: the integer type ("int" in
C) is 32-bit wide and it is a signed type so the range is
-2^31-1 .. 2^31-1 -- the minus one on each side is the
representation of NA and 0 respectively).
correction: the range should have read -(2^31-1) .. 2^31
I was using the number given in the help page documentation for
"integer". (Part of the question was whether it was "documented".) I
did understand that it was d/t the 4 byte range.
Regarding the second part of the OP's question this is from the
"character" help page:
"as.character truncates components of language objects to 500
characters (was about 70 before 1.3.1)."
And there was a posting from Prof Ripley regarding some other
limitations that had been recently modified:
https://stat.ethz.ch/pipermail/r-devel/2010-November/058989.html
--
David.
Cheers,
Simon
Here's another example:
library(orthopolynom)
hermite <- hermite.h.polynomials(1001)
hermite[[1001]] # should display 1000-th degree polynomial
Error in if (signs[1] == "- ") "-" else "" :
missing value where TRUE/FALSE needed
Sounds as though the maximum length of an element of type
character has been exceeded.
Thanks,
Dominick
David Winsemius, MD
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
On May 5, 2011, at 1:07 PM, Steve Lianoglou wrote: On Wed, May 4, 2011 at 9:24 AM, Barry Rowlingson wrote: On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham wrote: Any hints as to what to search for? For recursive objects, search for recursive objects. Awesome :-) And completely OT but strangely related -- in case you've never stumbled on this gem: google for "recursion" and look for Google's "Did you mean" suggestion ... Man ... sometimes I am so slow! -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation error Mac binary
On Jun 29, 2011, at 5:33 AM, soeren.vo...@uzh.ch wrote: Hello, the compilation of the GUTS package on CRAN for Mac produces the following error messages: http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/GUTS-00install.html I guess it is some namespace collision, but I can not reproduce it on my machine, it compiles fine here. What is the cause and which setup do I need to reproduce the errors? I was going to suggest you take this up with the maintainers... but you _are_ one of the maintainers. Here is the output from an attempt to compile from source, version 0.1.45, with a relatively recent version of R 2.13.0 (but not the most recent and I still use Mac OSX 10.5.8). Perhaps its brevity will be helpful, and the fact that it seems to identify different error than those flagged in the log at CRAN. trying URL 'http://lib.stat.cmu.edu/R/CRAN/src/contrib/GUTS_0.1.45.tar.gz' Content type 'application/x-gzip' length 9842 bytes opened URL == downloaded 9842 bytes Loading required package: lattice Loading required package: sos Loading required package: brew [1] "2011-06-29 09:40:18 EDT" * installing *source* package ‘GUTS’ ... ** libs *** arch - i386 g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/ Library/Frameworks/R.framework/Resources/include/i386 -I/opt/local/ include -I/usr/local/include -I"/Library/Frameworks/R.framework/ Versions/2.13/Resources/library/Rcpp/include" -fPIC -g -O2 -c GUTS.cpp -o GUTS.o In file included from GUTS.cpp:12: GUTS.h:21:28: error: boost/random.hpp: No such file or directory GUTS.h:22:40: error: boost/math/distributions.hpp: No such file or directory GUTS.cpp: In function ‘void to_print(double)’: GUTS.cpp:277: error: ‘cout’ was not declared in this scope GUTS.cpp: In member function ‘void GUTS::showObject()’: GUTS.cpp:281: error: ‘cout’ is not a member of ‘std’ GUTS.cpp:284: error: ‘cout’ was not declared in this scope make: *** [GUTS.o] Error 1 ERROR: compilation failed for package ‘GUTS’ * removing ‘/Library/Frameworks/R.framework/Versions/2.13/Resources/ library/GUTS’ > sessionInfo() R version 2.13.0 beta (2011-04-04 r55296) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] mgcv_1.7-6 sos_1.3-0 brew_1.0-6 lattice_0.19-26 loaded via a namespace (and not attached): [1] grid_2.13.0Matrix_0.999375-50 nlme_3.1-101 tools_2.13.0 -- David. R: version platform i386-apple-darwin9.8.0 arch i386 os darwin9.8.0 system i386, darwin9.8.0 status major 2 minor 13.0 year 2011 month 04 day13 svn rev55427 language R version.string R version 2.13.0 (2011-04-13) I ~ $: gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I ~ $: less /opt/local/include/boost/version.hpp // Boost version.hpp configuration header file --// [...] #define BOOST_VERSION 104601 #define BOOST_LIB_VERSION "1_46_1" [...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [datatable-help] speeding up perception
On Jul 5, 2011, at 7:18 PM, > wrote: On Tue, 5 Jul 2011, Simon Urbanek wrote: On Jul 5, 2011, at 2:08 PM, Matthew Dowle wrote: Simon (and all), I've tried to make assignment as fast as calling `[<-.data.table` directly, for user convenience. Profiling shows (IIUC) that it isn't dispatch, but x being copied. Is there a way to prevent '[<-' from copying x? Good point, and conceptually, no. It's a subassignment after all - see R-lang 3.4.4 - it is equivalent to `*tmp*` <- x x <- `[<-`(`*tmp*`, i, j, value) rm(`*tmp*`) so there is always a copy involved. Now, a conceptual copy doesn't mean real copy in R since R tries to keep the pass-by-value illusion while passing references in cases where it knows that modifications cannot occur and/or they are safe. The default subassign method uses that feature which means it can afford to not duplicate if there is only one reference -- then it's safe to not duplicate as we are replacing that only existing reference. And in the case of a matrix, that will be true at the latest from the second subassignment on. Unfortunately the method dispatch (AFAICS) introduces one more reference in the dispatch chain so there will always be two references so duplication is necessary. Since we have only 0 / 1 / 2+ information on the references, we can't distinguish whether the second reference is due to the dispatch or due to the passed object having more than one reference, so we have to duplicate in any case. That is unfortunate, and I don't see a way around (unless we handle subassignment methods is some special way). I don't believe dispatch is bumping NAMED (and a quick experiment seems to confirm this though I don't guarantee I did that right). The issue is that a replacement function implemented as a closure, which is the only option for a package, will always see NAMED on the object to be modified as 2 (because the value is obtained by forcing the argument promise) and so any R level assignments will duplicate. This also isn't really an issue of imprecise reference counting -- there really are (at least) two legitimate references -- one though the argument and one through the caller's environment. It would be good it we could come up with a way for packages to be able to define replacement functions that do not duplicate in cases where we really don't want them to, but this would require coming up with some sort of protocol, minimally involving an efficient way to detect whether a replacement funciton is being called in a replacement context or directly. Would "$<-" always satisfy that condition. It would be big help to me if it could be designed to avoid duplication the rest of the data.frame. -- There are some replacement functions that use C code to cheat, but these may create problems if called directly, so I won't advertise them. Best, luke Cheers, Simon -- Luke Tierney Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: l...@stat.uiowa.edu Iowa City, IA 52242 WWW: http:// www.stat.uiowa.edu______ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply() returning a list?
On Jul 19, 2011, at 7:34 PM, David A. Johnston wrote: Hi devel list, I searched for past posts about this issue and found none, so my apologies if this has been addressed before. The sapply() function has an argument 'simplify', and the mapply() function has an argument 'SIMPLIFY'. I am surprised that the apply() argument does not have a similar argument. Is there a reason for this? Here's a simple example: x = matrix(1:12, 3, 4) apply(x, 1, sum) [1] 22 26 30 This is what I would like to see: apply(x, 1, sum, simplify = FALSE) [[1]] [1] 22 [[2]] [1] 26 [[3]] [1] 30 Probably no one thought it was that difficult to type the more concise and equally expressive: > as.list(apply(x, 1, sum)) [[1]] [1] 22 [[2]] [1] 26 [[3]] [1] 30 -- David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R checks links broken
On Jul 30, 2011, at 9:46 AM, Dirk Eddelbuettel wrote: I was about to show the Rcpp build check results to a user when I noticed that the relevant URL http://cran.r-project.org/web/checks/check_results_Rcpp.html currently yields a 404 error. It's there now. Spot checking for other package yields the same. Looking at http://cran.r-project.org/web/ Also up. shows that no checks/ diretory can be found. Did an NFS mount go down? Cheers, Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'data.frame' method for base::rep()
On Aug 2, 2011, at 7:55 AM, Liviu Andronic wrote:
Dear R developers
Would you consider adding a 'data.frame' method for the base::rep
function? The need to replicate a df row-wise can easily arise while
programming, and rep() is unable to handle such a case. See below.
x <- iris[1, ]
x[ rep(1,2), ] # "works"
I found a 'rep.data.frame' function in package 'mefa' [2], but I think
it would be nice to have it in base R. In any case, the code used by
the method is very simple.
require(mefa)
Loading required package: mefa
mefa 3.2-1 2011-05-13
mefa:::rep.data.frame
function (x, ...)
as.data.frame(lapply(x, rep, ...))
And here's the example above:
rep(x, 2)
Sepal.Length Sepal.Width Petal.Length Petal.Width Species
1 5.1 3.5 1.4 0.2 setosa
2 5.1 3.5 1.4 0.2 setosa
I do not think the mefa 'rep.data.frame' code is a good example to
replicate ... as it were. It strips classes from any column that does
not have an associated 'rep' method, and the repetoire (we are in some
kind of self-referential loop here) of rep.* methods is pretty meager.
My initial thought was that the expected functionality would be found
with "[" using the template:
dfrm[rep(vec, times/each= vec2) , ]
It appears "[" proves would preserve classes for a much larger range.
methods("[")
> x <- data.frame(a = as.Date('2000-01-01'), b=as.Date('2001-01-01'))
> x$d <- x$a -x$b
> require(mefa)
> rep(x, 2)
a bd
1 2000-01-01 2001-01-01 -366
2 2000-01-01 2001-01-01 -366
> str(rep(x,2))
'data.frame': 2 obs. of 3 variables:
$ a: Date, format: ...
$ b: Date, format: ...
$ d: num -366 -366 # notice that a difftime object has lost its
class
# Whereas using the [rep(. , .) , ] approach does preserve the
difftime class.
> str(x[rep(1,2) , ])
'data.frame': 2 obs. of 3 variables:
$ a: Date, format: ...
$ b: Date, format: ...
$ d:Class 'difftime' atomic [1:2] -366 -366 # leap year
.. ..- attr(*, "units")= chr "days"
Since that works out of the box with fewer potential side-effects, I
am not sure a new method is needed.
--
David.
Please le t me know what you think. Regards
Liviu
[1] http://finzi.psych.upenn.edu/R/library/mefa/html/rep.data.frame.html
[2] http://cran.at.r-project.org/web/packages/mefa/index.html
--
David Winsemius, MD
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'data.frame' method for base::rep()
On Aug 3, 2011, at 2:45 AM, Liviu Andronic wrote:
Hello David
On Tue, Aug 2, 2011 at 4:14 PM, David Winsemius > wrote:
x <- data.frame(a = as.Date('2000-01-01'), b=as.Date('2001-01-01'))
x$d <- x$a -x$b
require(mefa)
rep(x, 2)
a bd
1 2000-01-01 2001-01-01 -366
2 2000-01-01 2001-01-01 -366
str(rep(x,2))
'data.frame': 2 obs. of 3 variables:
$ a: Date, format: ...
$ b: Date, format: ...
$ d: num -366 -366 # notice that a difftime object has lost its
class
Nice catch. Thanks for pointing it out.
# Whereas using the [rep(. , .) , ] approach does preserve the
difftime
class.
str(x[rep(1,2) , ])
'data.frame': 2 obs. of 3 variables:
$ a: Date, format: ...
$ b: Date, format: ...
$ d:Class 'difftime' atomic [1:2] -366 -366 # leap year
.. ..- attr(*, "units")= chr "days"
The above is nice. I wouldn't have thought of it.
Since that works out of the box with fewer potential side-effects,
I am not
sure a new method is needed.
Your solution still seems more like an obscure side-effect of
subsetting than an intuitive feature, in the sense that before trying
it out the average user would probably first turn to base::rep() when
in need to replicate a df, and then (perhaps) to
mefa:::rep.data.frame() (with all the associated confusion and
pitfalls). I would tend to believe that if there is a clean R-ish way
to implement a base::rep.data.frame() it could still be useful.
To me that _is_ the R-ish way. It did not seem at all obscure.
Duplicating column numbers also a way to replicate columns or
rearrange them:
Try:
xtest=data.frame(a=letters[1:10], b=1:10)
xtest[ , c(1,2,2,1)]
--
David.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] repeatable segfault
I can reproduce:
eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
*** caught segfault ***
address 0x102d0e028, cause 'memory not mapped'
Traceback:
1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
## after restart
> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
With OSX 10.5.8
Also happens with 32 bit R
[R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
David Winsemius
On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
Hi. macosx 10.6.8
With R-2.13.1 and also revision 56948 I get the following repeatable
segfault:
wt118:~% R --vanilla --quiet
R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"
$arch
[1] "x86_64"
$os
[1] "darwin9.8.0"
$system
[1] "x86_64, darwin9.8.0"
$status
[1] ""
$major
[1] "2"
$minor
[1] "13.1"
$year
[1] "2011"
$month
[1] "07"
$day
[1] "08"
$`svn rev`
[1] "56322"
$language
[1] "R"
$version.string
[1] "R version 2.13.1 (2011-07-08)"
eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
*** caught segfault ***
address 0x1038000a8, cause 'memory not mapped'
Traceback:
1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
wt118:~%
--
Robin Hankin
Uncertainty Analyst
hankin.ro...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius, MD
Heritage Laboratories
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why my messages are filtered from the list?
On May 28, 2015, at 9:11 PM, Ivan Popivanov wrote: > Hello, > > Over the last two months I have sent two messages (same topic) to the list. > None of them showed on the list. For the first, I got a message that it is > in some queue and waiting for an administrator to look at it. Is the queue > THAT long?! The moderators don't know all the spam rules but we are fairly sure that the Spam filter increases the probability of diverting to the queue especially for Nabble postings , but we suspect also for certain high-risk domains, and using HTML mail. The queue's are fairly short and if your posting doesn't get to the list within 12 hours you can be reasonably sure it was intercepted and will never appear. Some postings from Nabble do not even reach teh moderator queue. If it had a blank Subject or a Subject that was all question marks the moderator might have simply discarded it without even looking at it. I do not see any posting from your address in the Archives for May or April. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why my messages are filtered from the list?
On May 28, 2015, at 10:05 PM, Ivan Popivanov wrote: > Now I am getting confused. I see two postings from me in the archives: > > https://stat.ethz.ch/pipermail/r-devel/2015-May/071205.html > https://stat.ethz.ch/pipermail/r-devel/2015-April/070982.html > > Were these actually published to the list? If so - big apology. > Yes they were, to r-devel. Just not the r-help mailing list Archive I looked in. Sorry for my noise, too. -- David. > Regards, > Ivan > > On Fri, May 29, 2015 at 12:43 AM David Winsemius > wrote: > > On May 28, 2015, at 9:11 PM, Ivan Popivanov wrote: > > > Hello, > > > > Over the last two months I have sent two messages (same topic) to the list. > > None of them showed on the list. For the first, I got a message that it is > > in some queue and waiting for an administrator to look at it. Is the queue > > THAT long?! > > The moderators don't know all the spam rules but we are fairly sure that the > Spam filter increases the probability of diverting to the queue especially > for Nabble postings , but we suspect also for certain high-risk domains, and > using HTML mail. > > The queue's are fairly short and if your posting doesn't get to the list > within 12 hours you can be reasonably sure it was intercepted and will never > appear. Some postings from Nabble do not even reach teh moderator queue. If > it had a blank Subject or a Subject that was all question marks the moderator > might have simply discarded it without even looking at it. I do not see any > posting from your address in the Archives for May or April. > > > [[alternative HTML version deleted]] > > > > ______ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > David Winsemius > Alameda, CA, USA > David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Expected error with help.search in R 3.2.0
Using the Mavericks/Yosemite version of R 3.2.0, I see this:
> utils::help.search("linear models")
Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib, :
'topic' should be a name, length-one character vector or reserved word
Using R 3.1.2 on a SnowLeapard branch does not produce the same result. I do
get the expected large number of hits where those words are in the help pages.
It's an error message from the `help` function, so seems less likely to be
restricted to Macs. I do see that the help() code near the stop() call is the
same in both versions. I do not see where `help.search` calls `help`.
Tracing help is unrevealing. The first call to `help` throws the error and the
call looks exactly like the calls in R 3.1.2
--
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expected error with help.search in R 3.2.0
On Jun 13, 2015, at 10:59 PM, Berend Hasselman wrote:
>
>> On 14-06-2015, at 06:47, David Winsemius wrote:
>>
>> Using the Mavericks/Yosemite version of R 3.2.0, I see this:
>>
>>> utils::help.search("linear models")
>> Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib, :
>> 'topic' should be a name, length-one character vector or reserved word
>>
>> Using R 3.1.2 on a SnowLeapard branch does not produce the same result. I do
>> get the expected large number of hits where those words are in the help
>> pages. It's an error message from the `help` function, so seems less likely
>> to be restricted to Macs. I do see that the help() code near the stop() call
>> is the same in both versions. I do not see where `help.search` calls `help`.
>>
>> Tracing help is unrevealing. The first call to `help` throws the error and
>> the call looks exactly like the calls in R 3.1.2
>>
>
> See this thread on R-SIG-Mac
>
> https://stat.ethz.ch/pipermail/r-sig-mac/2015-April/011420.html
Yes, I see that thread. It reports a problem with the MacGUI package manager.
That was not the problem reported and in fact both help() and the package
manager open correctly. The problem reported was with `help.search()`
>
> This may help.
> Get R 3.2.0-patched or even the release candidate for R 3.2.1
>
There is no R 3.2.0-patched for Mavericks/Yosemite machines. There was a "3.1.3
Patched" for the Snow Leopard platform. I had used the most recent version of R
3.2.0 from the ATT Research site. I then updated to the release candidate as
suggested and R GUI now fails to load with this crash report. Note the error in
naming the location of the R target as to be found in
/Library/Frameworks/R.framework/Versions/3.3/...
I also see that there was a note: x86_64: make FAILED
Starting R from the a Terminal window succeeds and the error with help.search()
does not occur. R 3.2.1 also loads with RStudio with an error reported on
startup that I'm pretty sure has already been reported elsewhere.
Mac GUI launch failure report
Process: R [2518]
Path: /Applications/R.app/Contents/MacOS/R
Identifier:org.R-project.R
Version: ???
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible: R [2518]
User ID: 502
Date/Time: 2015-06-14 07:18:29.359 -0700
OS Version:Mac OS X 10.10.3 (14D136)
Report Version:11
Anonymous UUID:6729BDD8-0426-3F7E-CCFF-434A7BC2CF3E
Sleep/Wake UUID: E4F8B4E6-0F96-4939-A687-D912AD7B215E
Time Awake Since Boot: 14000 seconds
Time Since Wake: 660 seconds
Crashed Thread:0
Exception Type:EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded:
/Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libR.dylib
Referenced from: /Applications/R.app/Contents/MacOS/R
Reason: image not found
Binary Images:
0x7fff66097000 - 0x7fff660cd837 dyld (353.2.1)
<65DCCB06-339C-3E25-9702-600A28291D0E> /usr/lib/dyld
Model: MacBookPro5,3, BootROM MBP53.00AC.B03, 2 processors, Intel Core 2 Duo,
2.8 GHz, 8 GB, SMC 1.48f2
Graphics: NVIDIA GeForce 9600M GT, NVIDIA GeForce 9600M GT, PCIe, 512 MB
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x80AD,
0x484D5434353153364D4D5238432D47372020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x80AD,
0x484D5434353153364D4D5238432D47372020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom
BCM43xx 1.0 (5.106.98.100.24)
Bluetooth: Version 4.3.4f4 15601, 3 services, 19 devices, 1 incoming serial
ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545050B9SA02, 500.11 GB
Serial ATA Device: MATSHITADVD-R UJ-868, 122.5 MB
USB Device: Internal Memory Card Reader
USB Device: Built-in iSight
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Apple Internal Keyboard / Trackpad
USB Device: IR Receiver
Thunderbolt Bus:
> Berend
>
>> --
>> David Winsemius
>> Alameda, CA, USA
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bquote/evalq behavior changed in R-3.2.1
On Jul 15, 2015, at 12:51 PM, William Dunlap wrote:
> I think rapply() was changed to act like lapply() in this respect.
>
When I looked at the source of the difference, it was that typeof() returned
'language' in 3.2.1, while it returned 'list' in the earlier version of R. The
first check in rapply's code in both version was:
if (typeof(object) != "list")
stop("'object' must be a list")
Wrapping list() around the first argument and switching to using eval with an
expression-object rather than a call-object seemed to solve the problem when
this was posed as a question on StackOverflow, but Dayne was not happy with
that solution for other reasons that he is not describing.
--
David.
> In R-3.1.3 we got
> rapply(list(quote(1+myNumber)), evalq, envir=list2env(list(myNumber=17)))
> #[1] 18
> rapply(list(quote(1+myNumber)), eval, envir=list2env(list(myNumber=17)))
> #Error in (function (expr, envir = parent.frame(), enclos = if
> (is.list(envir) || :
> object 'myNumber' not found
> lapply(list(quote(1+myNumber)), evalq, envir=list2env(list(myNumber=17)))
> #Error in eval(substitute(expr), envir, enclos) : object 'X' not found
> lapply(list(quote(1+myNumber)), eval, envir=list2env(list(myNumber=17)))
> #[[1]]
> #[1] 18
> while in R-3.2.0 we get
> rapply(list(quote(1+myNumber)), evalq, envir=list2env(list(myNumber=17)))
> #Error in eval(substitute(expr), envir, enclos) : object 'X' not found
> rapply(list(quote(1+myNumber)), eval, envir=list2env(list(myNumber=17)))
> #[1] 18
> lapply(list(quote(1+myNumber)), evalq, envir=list2env(list(myNumber=17)))
> #Error in eval(substitute(expr), envir, enclos) : object 'X' not found
> lapply(list(quote(1+myNumber)), eval, envir=list2env(list(myNumber=17)))
> #[[1]]
> #[1] 18
>
> Make the FUN argument function(arg)sys.call() to see some details of the
> change.
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Wed, Jul 15, 2015 at 12:35 PM, Dayne Filer wrote:
>
>> In 3.1.2 eval does not store the result of the bquote-generated call in
>> the given environment. Interestingly, in 3.2.1 eval does store the result
>> of the bquote-generated call in the given environment.
>>
>> In other words if I run the given example with eval rather than evalq, on
>> 3.1.2 "x" is never stored in "fenv," but it is when I run the same code on
>> 3.2.1. However, the given example stores "x" in "fenv" on 3.1.2, but throws
>> the error I gave when run on 3.2.1.
>>
>> To give credit, I received the idea for using evalq from SO:
>> http://stackoverflow.com/a/22559385
>>
>> Dayne
>>
>>
>> On Wed, Jul 15, 2015 at 3:29 PM, William Dunlap wrote:
>>
>>> I am curious why you used evalq instead of eval in this code.
>>>
>>> Bill Dunlap
>>> TIBCO Software
>>> wdunlap tibco.com
>>>
>>> On Wed, Jul 15, 2015 at 11:49 AM, Dayne Filer
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I upgraded from 3.1.2 to 3.2.1 and am receiving errors on code that
>>>> worked
>>>> as I intended previously. Briefly, I am using bquote to generate
>>>> expressions to modify data.table objects within a function, so I need
>>>> the
>>>> changes to actually be stored in the given environment. Previously, I
>>>> used
>>>> code like the following:
>>>>
>>>> test <- list(bquote(x <- 10))
>>>> fenv <- environment()
>>>> rapply(test, evalq, envir = fenv)
>>>>
>>>> Although the code in the example above is much simpler, it shows the
>>>> problem. On 3.1.2 the expression is evaluated and x is stored as 10 in
>>>> the
>>>> given environment, fenv. In 3.2.1 the code throws an error:
>>>>
>>>> Error in eval(substitute(expr), envir, enclos) : object 'X' not found
>>>>
>>>> I could not find anything in the release notes that would explain this
>>>> change. Changing evalq to eval works in 3.2.1, but eval does not store x
>>>> in
>>>> the given environment in 3.1.2.
>>>>
>>>> Thanks,
>>>>
>>>> Dayne
>>>>
>>>>[[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
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hidden files problem in R CMD check
On Sep 26, 2015, at 2:06 PM, cstrato wrote: > Dear Dirk, > > Yes, I know, however forget for one moment R. > > If I use tar independent of R it still should not create these hidden files. > > BTW, do you know where these hidden files are stored on the Mac? Your first posting showed which of several different directories they were in. Do you understand that any file whose name starts with a is called a "hidden file"? It is "hidden", i.e not displayed in a Finder window, from people who are using Finder.app unless you change the default settings. It's easy to look up the code that is needed to be pasted into a Terminal session. I never remember it. I just leave Finder set up to display these 'dotfiles' as they are also called. defaults write com.apple.finder AppleShowAllFiles YES killall Finder #The second command restarts Finder.app or you could try to restart the Finder by option (=alt) + rightclicking the Finder icon in the Dock and selecting Relaunch. -- David. > > Best regards, > Christian > > > On 09/26/15 23:01, Dirk Eddelbuettel wrote: >> >> On 26 September 2015 at 22:41, cstrato wrote: >> | Dear Simon, >> | >> | Thank you very much for your help, it did solve my problems!! Great! >> | >> | I have googled COPYFILE_DISABLE and found the following site which does >> | explain the issue with tar on Mac OS X, see: >> | >> http://unix.stackexchange.com/questions/9665/create-tar-archive-of-a-directory-except-for-hidden-files >> | >> | Instead of doing: >> | $tar czf xps_1.29.2.tar.gz xps >> | >> | I did now: >> | $COPYFILE_DISABLE=1 tar czf xps_1.29.2.tar.gz xps >> | >> | Running: >> | $R CMD check xps_1.29.2.tar.gz >> | now leaves only '.BBSoptions' as hidden file. >> >> No, still wrong. As Simon said, we all are supposed to use 'R CMD build xps' >> to create the tarball. "Back in the day ..." straight tar cfz ... worked, it >> more or less stopped _many_ years ago. Cf TheOneManualThatMatters: >> >>1.3.1 Checking packages >>--- >> >>Using 'R CMD check', the R package checker, one can test whether >>_source_ R packages work correctly. It can be run on one or more >>directories, or compressed package 'tar' archives with extension >>'.tar.gz', '.tgz', '.tar.bz2' or '.tar.xz'. >> >> It is strongly recommended that the final checks are run on a 'tar' >>archive prepared by 'R CMD build'. >> >> Ie "It is strongly recommended ... 'tar' archive prepared by 'R CMD build'. >> >> Dirk >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] In plot.ts, las=1 applies to ylab with multiple series and not to axis labels
> On Feb 1, 2016, at 2:55 AM, Martin Maechler > wrote: > >>>>>> Spencer Graves >>>>>>on Sat, 30 Jan 2016 15:34:36 -0600 writes: > >> Hello: >> In plot.ts, las=1 applies to ylab and not axis labels with >> multiple series. The documented behavior is to have las=1 apply to axis >> labels and not ylab. > >> To see this, please try the following: > >> plot.ts(1:4, las=1) > >> plot.ts(matrix(1:8, 4), las=1) > >> On my Mac, the second displays behavior I did not expect. If >> I've done something stupid here, please advise; it won't be the first >> time ;-) > > Nothing stupid; indeed your expectations are correct and there's > a small lapsus in R there, the '...' not being passed to the axis(..) > calls in the matrix case. > I'm hoping you can at the same time look at the unexpected behavior I noted in a simple `plot` call that I observed over the weekend, also on a Mac, but it's hard to believe this is related to the OS.. plot(1:10,1:10, pch=20, lwd=c(1,1,1,3,1) ,type='b') What I'm seeing is the size of the points are accepting the 'lwd' argument when my reading of the docs is that it should be the intervening segments that accept it. And I echo Duncan's thanks. > I'm currently checking the obvious patch and will commit it to > R-devel and R-patched (unless I see problems in our checks). > >> Thanks to all the developers who have made R such a great >> contribution to humanity. > > Thank you for the flowers! > Martin Maechler > > >> Best Wishes, >> Spencer Graves > >> sessionInfo() >> R version 3.2.3 (2015-12-10) >> Platform: x86_64-apple-darwin13.4.0 (64-bit) >> Running under: OS X 10.11.2 (El Capitan) > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.2.4 Mac/Linux different in < on characters
> On Mar 11, 2016, at 6:52 PM, Mick Jordan wrote:
>
> Linux:
> > x<-c("0","1");y<-c("a","-1"); x [1] TRUE TRUE
>
> Mac:
>
> x<-c("0","1");y<-c("a","-1"); x [1] TRUE FALSE
>
On a Mac (and noting the the documentation [somewhere that I cannot find right
now] warns us the the collation sequence for characters is OS dependent):
require(R.oo)
charToInt("-")
#[1] 45
charToInt("1")
#[1] 49
>
> On both systems, LC_COLLATE/LC_CTYPE/LANG are set to en_US.UTF-8
>
> In Java,FWIW, I get the Mac answer if I use String.compareTo and the Linux
> answer if I use Collator.compareTo, but the result is consistent on Mac and
> Linux.
>
> Mick Jordan
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.2.5 Mac OS X package
> On May 2, 2016, at 3:45 PM, Mick Jordan wrote: > > When is the R-3.2.5 binary for Mac OS X likely to show up? Where did you look? I see both Mavericks and SnowLeopard fork binaries with or without r.app GUI at http://r.research.att.com/ I've been using the 3.3.0 RC for a while with only relative minor and mostly expected difficulties relating to packages that have external dependencies. > > Mick Jordan > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it possible to retrieve the last error? (not error *message*)
> On May 4, 2016, at 12:41 PM, Henrik Bengtsson > wrote: > > Hi, > > at the R prompt, is it possible to retrieve the last error (as in > condition object of class "error")? > > I'm not asking for geterrmessage(), which only returns the error > message (as a character string). I'm basically looking for a > .Last.error or .Last.condition, analogously to .Last.value for values, > which can be used when it is "too late" (not possible) to go back an > use try()/tryCatch(). After looking at the code for the exposed `traceback` > I'm wondering if this delivers what you expect: .traceback()[1] > Thanks, > > Henrik > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: pdf.options(embed=TRUE)
> On May 31, 2016, at 4:59 PM, Paul Johnson wrote:
>
> I learned last week that I generated a lot of PDFs and forgot to go
> back and embed the fonts in them.
>
> It would be very pleasant for me if pdf.options included an argument
> to turn on font embedding and have fonts always embedded. Always.
>
> Thanks for your time, as always.
I wondered if it would be fairly simple to use .Rprofile to overwrite `pdf`
with your own version that sets the value of `fonts' to a call to `options` and
then also set the options("pdf_embed")-value to your choice of font(s),
possibly defaulting to the current values of `names(pdfFonts())`.
Looking at the code for `pdf`, however, I see that a call to `check.options`
might require a mere complex set of parameters perhaps involving disabling the
check on the fonts option value.
I ended up wondering if instead the function to modify might not be
`grDevices:::initPSandPDFfonts`
--
David.
>
> --
> Paul E. Johnson http://pj.freefaculty.org
> Director, Center for Research Methods and Data Analysis http://crmda.ku.edu
>
> I only use this account for email list memberships. To write directly,
> address me at pauljohn
> at ku.edu.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "plot.ts" doesn't respect the value of "pch" (+ blocked from Bugzilla signups)
> On Aug 24, 2016, at 5:59 PM, Gregory Werbin
> wrote:
>
> I did a search on Bugzilla for "plot.ts" and didn't find anything on this
> issue. I tried to sign up for Bugzilla to report it, but my e-mail address
> didn't pass your "syntax checking" for a legal e-mail address.
>
> The bug is easily reproducible on my machine as follows:
>
> ## start
>
> # generate some data
> y <- arima.sim(list(), 150)
>
> # this will definitely dispatch to a ".ts" method
> class(y)[1] == 'ts'
>
> # compare and note that `cex = 0.5` has no effect
> plot(y, type = 'b', pch = 16)
> plot(y, type = 'b', pch = 16, cex = 0.5)
>
> # it works if `y` is coerced back to a regular vector
> plot(as.numeric(y), type = 'b', pch = 16, cex = 0.5)
>
> # another way to see the issue
> plot.ts(y, type = 'b', pch = 16, cex = 0.5)
> plot.default(y, type = 'b', pch = 16, cex = 0.5)
>
> ## end
>
> Skimming through source code for `plot.ts`, it seems like the `cex` argument
> is being "eaten" by a `...` somewhere without being properly passed to
> `plot.default`.
'...' does not "eat" parameters, it passes them on.
Looking at the very top of the body we see this in the definition of the
internal `plotts` function:
cex = par("cex"), lty = par("lty"), lwd = par("lwd"),
axes = TRUE, frame.plot = axes, ann = par("ann"), cex.lab =
par("cex.lab"),
col.lab = par("col.lab"), font.lab = par("font.lab"),
cex.axis = par("cex.axis"), col.axis = par("col.axis"),
And at the end of the body we se the call to plotts (including the "dots")
So I would suggest using par-settings.
par(cex=0.5)
plot(y, type = 'b', pch = 16)
(Question seems more appropriate for r-help.)
--
David.
>
> The output of `R.version` is:
> platform x86_64-apple-darwin15.5.0
> arch x86_64
> os darwin15.5.0
> system x86_64, darwin15.5.0
> status
> major 3
> minor 3.1
> year 2016
> month 06
> day21
> svn rev70800
> language R
> version.string R version 3.3.1 (2016-06-21)
> nickname Bug in Your Hair
>
> Greg
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented 'use.names' argument to c()
> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel > wrote: > > 'c' has an undocumented 'use.names' argument. I'm not sure if this is > a documentation or implementation bug. It came up on stackoverflow a couple of years ago: http://stackoverflow.com/questions/24815572/why-does-function-c-accept-an-undocumented-argument/24815653#24815653 At the time it appeared to me to be a documentation lag. > >> c(a = 1) > a > 1 >> c(a = 1, use.names = F) > [1] 1 > > Karl > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wish list: generalized apply
> On Dec 8, 2016, at 12:09 PM, John P. Nolan wrote:
>
> Dear All,
>
> I regularly want to "apply" some function to an array in a way that the
> arguments to the user function depend on the index on which the apply is
> working. A simple example is:
>
> A <- array( runif(160), dim=c(5,4,8) )
> x <- matrix( runif(32), nrow=4, ncol=8 )
> b <- runif(8)
> f1 <- function( A, x, b ) { sum( A %*% x ) + b }
> result <- rep(0.0,8)
> for (i in 1:8) {
> result[i] <- f1( A[,,i], x[,i] , b[i] )
> }
>
> This works, but is slow. I'd like to be able to do something like:
>generalized.apply( A, MARGIN=3, FUN=f1, list(x=x,MARGIN=2),
> list(b=b,MARGIN=1) ), where the lists tell generalized.apply to pass x[,i]
> and b[i] to FUN in addition to A[,,i].
>
> Does such a generalized.apply already exist somewhere? While I can write a C
> function to do a particular case, it would be nice if there was a fast,
> general way to do this.
I would have thought that this would achieve the same result:
result <- sapply( seq_along(b) , function(i) { f1( A[,,i], x[,i] , b[i] )} )
Or:
result <- sapply( seq.int( dim(A)[3] ) , function(i) { f1( A[,,i], x[,i] , b[i]
)} )
(I doubt it will be any faster, but if 'i' is large, parallelism might help.
The inner function appears to be fairly efficient.)
--
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Natural vs National in R signon banner?
his (or much of >> anything). >>>>> They really are amazingly incompetent, considering how much money they >> earn. >>>>> >>>>> Duncan Murdoch >>>>> >>>>> >>>>>> And, yes, this is a low priority issue. All of you have better things >> to >>>>>> do. >>>>>> >>>>>> R is an extremely powerful and comprehensive software system. >>>>>> Thank you all for that. >>>>>> And I would like to clean one gnat from the windshield. >>>>>> >>>>>> I just wax pedantic at times. >>>>>> >>>>>> On Thu, Aug 31, 2017 at 5:13 PM, Duncan Murdoch < >> murdoch.dun...@gmail.com >>>>>> <mailto:murdoch.dun...@gmail.com>> wrote: >>>>>> >>>>>> On 31/08/2017 5:38 PM, Paul McQuesten wrote: >>>>>> >>>>>> The R signon banner includes this statement: >>>>>> Natural language support but running in an English locale >>>>>> >>>>>> Should that not say 'National' instead of 'Natural'? >>>>>> Meaning that LOCALE support is enabled, not that the interface >>>>>> understands >>>>>> human language? >>>>>> >>>>>> >>>>>> No, "natural language" refers to human languages, but it doesn't >>>>>> imply that R understands them. NLS just means that messages may be >>>>>> presented in (or translated to) other human languages in an >>>>>> appropriate context. >>>>>> >>>>>> For example, you can start R on most platforms from the console using >>>>>> >>>>>> LANGUAGE=de R >>>>>> >>>>>> and instead of the start message you saw, you'll see >>>>>> >>>>>> R ist freie Software und kommt OHNE JEGLICHE GARANTIE. >>>>>> Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu >>>>>> verbreiten. >>>>>> Tippen Sie 'license()' or 'licence()' für Details dazu. >>>>>> >>>>>> and so on. >>>>>> >>>>>> Please ignore this and forgive me if this is an inappropriate >>>>>> post. I am a >>>>>> N00B in R. >>>>>> >>>>>> >>>>>> I don't think it is inappropriate. >>>>>> >>>>>> 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 <+45%2038%2015%2035%2001> >> 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 > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what do you think about write.table(... qmethod = "excel")?
> On Sep 20, 2017, at 9:53 AM, Paul Johnson wrote:
>
> On Tue, Sep 19, 2017 at 4:45 PM, Duncan Murdoch
> wrote:
>>
>>
>> That's true, but if that's what they want to do, and they're willing to pay
>> to be able to write files that imitate Excel, then why not do what they ask?
>>
>> On the other hand, if they aren't willing to pay for the work, then you
>> should lecture them on how silly their request is.
>>
>> In any case, base R functions should not include nonsense, so this is not
>> something that should go into R.
>>
>> Duncan Murdoch
>>
>
> I understand. This is a paying client, I'm going where the money goes.
>
> Here's my current working example of a function that writes a CSV
> exactly as Excel does. I've posted this into StackOverflow
> (https://stackoverflow.com/questions/25743018/how-to-conditionally-remove-quotes-in-write-csv).
> It is buried under a thread, maybe will not get much attention and
> bug-checking. Oh, well, I can hope. Processes variables
> column-by-column, I don't know how to do it differently.
>
>
>
> ##' Write CSV files with quotes same as MS Excel 2013 or newer
> ##'
> ##' R's write.csv inserts quotes around all elements in a character
> ##' vector (if quote = TRUE). In contrast, MS Excel CSV export no
> ##' longer inserts quotation marks on all elements in character
> ##' variables, except when the cells include commas or quotation
> ##' marks. This function generates CSV files that are, so far as we
> ##' know, exactly the same "quoted style" as MS Excel CSV export
> ##' files.
> ##'
> ##' This works by manually inserting quotation marks where necessary and
> ##' turning FALSE R's own method to insert quotation marks.
> ##' @param x a data frame
> ##' @param file character string for file name
> ##' @param row.names Default FALSE for row.names
> ##' @importFrom utils write.table
> ##' @return the return from write.table, using revised quotes
> ##' @export
> ##' @author Paul Johnson
> ##' @examples
> ##' set.seed(234)
> ##' x1 <- data.frame(x1 = c("a", "b,c", "b", "The \"Washington, DC\""),
> ##' x2 = rnorm(4), stringsAsFactors = FALSE)
> ##' x1
> ##' fn <- tempfile(pattern = "testcsv", fileext = ".csv")
> ##' writeCSV(x1, file = fn)
> ##' readLines(fn)
> ##' x2 <- read.table(fn, sep = ",", header = TRUE, stringsAsFactors = FALSE)
> ##' all.equal(x1,x2)
> writeCSV <- function(x, file, row.names = FALSE){
>xischar <- colnames(x)[sapply(x, is.character)]
? Should that be:
xIsCharOrFactor <- colnames(x)[sapply(x, function(z) is.character(z) |
is.factor(z) )]
Just asking. No testing done.
__
David.
>for(jj in xischar){
>x[ , jj] <- gsub('"', '""', x[ , jj], fixed = TRUE)
>needsquotes <- grep('[\",]', x[ ,jj])
>x[needsquotes, jj] <- paste0("\"", x[needsquotes, jj], "\"")
>}
>write.table(x, file = file, sep = ",", quote = FALSE,
>row.names = row.names)
> }
>
> Output:
>
>> set.seed(234)
>> x1 <- data.frame(x1 = c("a", "b,c", "b", "The \"Washington, DC\""),
> +x2 = rnorm(4), stringsAsFactors = FALSE)
>> x1
>x1 x2
> 1a 0.6607697
> 2 b,c -2.0529830
> 3b -1.4992061
> 4 The "Washington, DC" 1.4712331
>> fn <- tempfile(pattern = "testcsv", fileext = ".csv")
>> writeCSV(x1, file = fn)
>> readLines(fn)
> [1] "x1,x2"
> [2] "a,0.660769736644892"
> [3] "\"b,c\",-2.052983003941"
> [4] "b,-1.49920605110092"
> [5] "\"The \"\"Washington, DC\"\"\",1.4712331168047"
>> x2 <- read.table(fn, sep = ",", header = TRUE, stringsAsFactors = FALSE)
>> all.equal(x1,x2)
> [1] TRUE
>
> I already see one problem, that I've got no special arrangement for
> column names with commas or quotes. People who want column names with
> those things are even more wrong than the people write a parser that
> can't understand quotes on character variables.
>
> --
> Paul E. Johnson http://pj.freefaculty.org
> Director, Center for Research Methods and Data Analysis http://crmda.ku.edu
>
> To write to me directly, please address me at pauljohn at ku.edu.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
'Any technology distinguishable from magic is insufficiently advanced.'
-Gehm's Corollary to Clarke's Third Law
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Array changing address unexpectedly
> On Nov 12, 2017, at 8:47 AM, lille stor wrote:
>
> Hi,
>
> Given the following R code:
>
> library(pryr)
>
> data <- array(dim = c(5))
>
> for(x in 1:5)
> {
> data[x] <- as.integer(x * 2)
> }
>
> add = address(data) # save address of "data"
>
> for(x in 1:5)
> {
> data[x] <- as.integer(0)
> }
>
> if (add == address(data))
> {
>print("Address did not change")
> }
> else
> {
>print("Address changed")
> }
>
> If one runs this code, message "Address changed" is printed. However, if one
> comments line "data[x] <- as.integer(0)" the address of "data" does not
> change and message "Address did not change" is printed instead. Why? The
> datatype of the array should not change with this line and hence no need for
> R to convert the array to a different type (and have the array's address
> changing in the process).
I'm guessing you didn't take note of the error message:
> else
Error: unexpected 'else' in "else"
It's always good practice to investigate errors. The else function needs to
come immediately after the "{".
Here's a more complete test of what I take to be your question:
library(pryr)
data <- array(dim = c(5))
add = address(data)
for(x in 1:5)
{
data[x] <- as.integer(x * 2)
}
if (add == address(data))
{
print("Address did not change")
} else {
print("Address changed")
}
data <- array(dim = c(5)) # reset
add = address(data)
for(x in 1:5)
{
data[x] <- as.integer(0)
}
if (add == address(data))
{
print("Address did not change")
} else {
print("Address changed")
}
# changes in both situations.
>
> Thank you!
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
'Any technology distinguishable from magic is insufficiently advanced.'
-Gehm's Corollary to Clarke's Third Law
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lm considers removed predictors when finding complete cases
> On Dec 19, 2017, at 11:12 AM, EDUARDO GARCIA PORTUGUES > wrote: > > Dear R-devel list, > > I realized that removing a predictor in lm through the "-"'s operator in > formula() does not affect the complete cases that are considered. A minimal > example is: > > summary(lm(Wind ~ ., data = airquality)) > # 42 observations deleted due to missingness > > summary(lm(Wind ~ . - Ozone, data = airquality)) > # still 42 observations deleted due to missingness, even if only 7 are > # missing for the response and the rest of the predictors > > summary(lm(Wind ~ ., data = subset(airquality, select = -Ozone))) > # 7 observations deleted due to missingness > > I find this behaviour somehow striking and I was wondering whether it is > intended, or whether it would be appropriate to document it in lm's help. The behavior in the second instance seems consistent with a desire to compare models (full versus reduced) based on the same data. You expectation appears to be something else but you have not really explained your rationale for a different expectation other than to call it "striking". If by "striking" you mean hitting your head and saying "Oh course, I should have thought of that" then we would be in agreement. -- David. > > Any insight on this issue is appreciated. > > Best regards, > -- > Eduardo García Portugués > Assistant professor > Department of Statistics > Carlos III University of Madrid > > Office: 7.3.J21 (Leganés) > Phone: (+34) 91624 8836 > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN metadata broken?
On 9/11/20 6:03 AM, Gábor Csárdi wrote: E.g. in https://cran.r-project.org/bin/macosx/contrib/4.0/PACKAGES there is Package: stringi Version: 1.5.3 but there is no such binary at https://cran.r-project.org/bin/macosx/contrib/4.0/ Using my browser I found: https://cran.r-project.org/bin/macosx/contrib/4.0/stringi_1.5.3.tgz FYI, G. __ 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] Allowing S3 methods of rounding functions to take `...`
On 1/28/21 10:56 PM, Abby Spurdle wrote: I've been writing functions for block matrices and more generally, arrays of matrices. Presumably, the default transpose operation would transpose everything. But there are situations where one might want to transpose the top-level matrix (of submatrices) but not the submatrices, themselves. Or vice versa. You could construct a matrix of lists and have the lists hold the sub-matrices. -- David. On a side note, the help file for base::aperm is entitled "Array Transposition". So, this topic is not quite as simple as it may sound. Interestingly, the aperm generic function *does* have dots. On Fri, Jan 29, 2021 at 3:37 PM Gabriel Becker wrote: Out of my naive curiosity, what arguments are you hoping a method for t() will take? I mean honestly an argument could be made that all S3 generics should take I don't think its an overwhelmingly compelling one, but I d see some merit to it given what an s3 generic is at its core. ~G On Thu, Jan 28, 2021 at 5:27 PM Abby Spurdle wrote: That's a great suggestion Davis. While, we're on the topic... Could we have a "dots" argument in base::t, the transpose function? On Fri, Jan 29, 2021 at 4:48 AM Davis Vaughan wrote: I should also say that I would be willing to attempt a patch for this, if others agree that this would be useful. - Davis On Thu, Jan 28, 2021 at 9:14 AM Davis Vaughan wrote: Hi all, I would like to propose adding `...` to the signatures of the following rounding functions: - floor(x) - ceiling(x) - round(x, digits = 0) - And possibly signif(x, digits = 6) The purpose would be to allow S3 methods to add additional arguments as required. A few arguments in favor of this change: `trunc(x, ...)` already takes dots, which sets a precedent for the others to do so as well. It is documented in the same help file as the other rounding functions. Internally at the C level, a check is done to ensure that there is exactly 1 arg for floor() and ceiling(), and either 1 or 2 args for round(). The actual names of those arguments are not checked, however, and I believe this is what allows `round.Date(x, ...)` and `round.POSIXt(x, unit)` to exist, solely because they have 2 arguments. It seems like this is a bit of a hack, since you couldn't create something similar for floor, like `floor.POSIXt(x, unit)` (not saying this should exist, it is just for argument's sake), because the 1 argument check would error on this. I think adding `...` to the signature of the generics would better support what is being done here. Additionally, I have a custom date-like S3 class of my own that I would like to write floor(), ceiling(), and round() methods for, and they would require passing additional arguments. If R core would like to make this change, they could probably tweak `do_trunc()` to be a bit more general, and use it for floor() and ceiling(), since it already allows `...`. A few references: Check for 1 arg in do_math1(), used by floor() and ceiling() https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1270 Check for 2 args in do_Math2(), used by round() https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1655 do_trunc() definition that allows `...` https://github.com/wch/r-source/blob/fe82da3baf849fcd3cc7dbc31c6abc72b57aa083/src/main/arithmetic.c#L1329-L1340 - Davis [[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 __ 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] replicate evaluates its second argument in wrong environment
On 2/15/21 1:10 PM, Hadley Wickham wrote:
This is a nice example of the motivation for tidy evaluation — since
enquo() captures the environment in which the promise should be
evaluated, there's no need for an additional explicit argument.
library(rlang)
replicate2 <- function (n, expr, simplify = "array") {
exnr <- enquo(expr)
It does not appear that the line above would accomplish anything given
the succeeding line. Or am I missing something? Taking it out doesn't
seem to affect results. Whatever magic there is seems to be in the
`eval_tidy` function, whose mechanism or rules seem opaque. Was "exnr"
supposed to be passed to `eval_tidy`?
--
David.
sapply(integer(n), function(i) eval_tidy(expr), simplify = simplify)
}
doRep2 <- function(a, b) sapply(a, replicate2, b)
doRep2(3, 2)
#> [,1]
#> [1,]2
#> [2,]2
#> [3,]2
Hadley
On Sat, Feb 13, 2021 at 7:09 AM Gabor Grothendieck
wrote:
Currently replicate used within sapply within a function can fail
because it gets the environment for its second argument, which is
currently hard coded to be the parent frame, wrong. See this link for
a full example of how it goes wrong and how it could be made to work
if it were possible to pass an envir argument to it.
https://stackoverflow.com/questions/66184446/sapplya-replicate-b-expression-no-longer-works-inside-a-function/66185079#66185079
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at 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] Inconsistency in median()
It would almost trivial to make a wrapper tha first captures attributes, runs
median, and then returns the Re-attribute-ed value.
David.
Sent from my iPhone
> On May 5, 2021, at 8:29 AM, Gustavo Zapata Wainberg
> wrote:
>
> Hi, thanks Dr. Mächler for your prompt response!
>
> I agree with your explanations about this issue. But I was thinking of
> something like adding an argument to median() and mean() that could keep
> the attributes of the variables if set to TRUE.
>
> Thanks again.
>
> Best regards
>
> El mar, 4 may 2021 a las 17:57, Martin Maechler ()
> escribió:
>
>>> Gustavo Zapata Wainberg
>>>on Mon, 3 May 2021 20:48:49 +0200 writes:
>>
>>> Hi!
>>
>>> I'm wrinting this post because there is an inconsistency
>>> when median() is calculated for even or odd vectors. For
>>> odd vectors, attributes (such as labels added with Hmisc)
>>> are kept after running median(), but this is not the case
>>> if the vector is even, in this last case attributes are
>>> lost.
>>
>>> I know that this is due to median() using mean() to obtain
>>> the result when the vector is even, and mean() always
>>> takes attributes off vectors.
>>
>> Yes, and this has been the design of median() for ever :
>>
>> If n := length(x) is odd, the median is "the middle" observation,
>> and should equal to x[j] for j = (n+1)/2
>> and hence e.g., is well defined for an ordered factor.
>>
>> When n is even
>> however, median() must be the mean of "the two middle" observations,
>> which is e.g., not even *defined* for an ordered factor.
>>
>> We *could* talk of the so called lo-median or hi-median
>> (terms probably coined by John W. Tukey) because (IIRC), these
>> are equal to each other and to the median for odd n, but
>> are equal to x[j] and x[j+1] j=n/2 for even n *and* are
>> still "of the same kind" as x[] itself.
>>
>> Interestingly, for the mad() { = the median absolute deviation from the
>> median}
>> we *do* allow to specify logical 'low' and 'high',
>> but that for the "outer" median in MAD's definition, not the
>> inner one.
>>
>> ## From /src/library/stats/R/mad.R :
>>
>> mad <- function(x, center = median(x), constant = 1.4826,
>>na.rm = FALSE, low = FALSE, high = FALSE)
>> {
>>if(na.rm)
>>x <- x[!is.na(x)]
>>n <- length(x)
>>constant *
>>if((low || high) && n%%2 == 0) {
>>if(low && high) stop("'low' and 'high' cannot be both TRUE")
>>n2 <- n %/% 2 + as.integer(high)
>>sort(abs(x - center), partial = n2)[n2]
>>}
>>else median(abs(x - center))
>> }
>>
>>
>>
>>
>>> Don't you think that attributes should be kept in both
>>> cases?
>>
>> well, not all attributes can be kept.
>> Note that for *named* vectors x, x[j] can (and does) keep the name,
>> but there's definitely no sensible name to give to (x[j] + x[j+1])/2
>>
>> I'm willing to collaborate with some, considering
>> to extend median.default() making hi-median and lo-median
>> available to the user.
>> Both of these will always return x[j] for some j and hence keep
>> all (sensible!) attributes (well, if the `[`-method for the
>> corresponding class has been defined correctly; I've encountered
>> quite a few cases where people created vector-like classes but
>> did not provide a "correct" subsetting method (typically you
>> should make sure both a `[[` and `[` method works!).
>>
>> Best regards,
>> Martin
>>
>> Martin Maechler
>> ETH Zurich and R Core team
>>
>>> And, going further, shouldn't mean() keep
>>> attributes as well? I have looked in R's Bugzilla and I
>>> didn't find an entry related to this issue.
>>
>>> Please, let me know if you consider that this issue should
>>> be posted in R's bugzilla.
>>
>>> Here is an example with code.
>>
>>> rndvar <- rnorm(n = 100)
>>
>>> Hmisc::label(rndvar) <- "A label for RNDVAR"
>>
>>> str(median(rndvar[-c(1,2)]))
>>
>>> Returns: "num 0.0368"
>>
>>> str(median(rndvar[-1]))
>>
>>> Returns: 'labelled' num 0.0322 - attr(*, "label")= chr "A
>>> label for RNDVAR"
>>
>>> Thanks in advance!
>>
>>> Gustavo Zapata-Wainberg
>>
>>> [[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
Re: [Rd] How to get utf8 string using R externals
First; you should configure yopu mail client to send plain text.
Can you explain what is meant by:
the characters are unicodes () instead of
utf8 encoding of the korean characters 부실.
As far as I can tell those two unicodes _are_ the utf8 encodings of 부실.
You may need to consult a couple of R help pages. I suggest:
?Quotes
?points # has examples of changing fonts used for display on console.
Sorry if I've misunderstood. I'm not on a Windows device, so posting the C++
program won't be helpful, but maybe it would for other prospective respondents.
--
David.
On 6/2/21 1:33 PM, xiaoyan yu wrote:
I have a R Script Predict.R:
set.seed(42)
C <- seq(1:1000)
A <- rep(seq(1:200),5)
E <- (seq(1:1000) * (0.8 + (0.4*runif(50, 0, 1
L <- ifelse(runif(1000)>.5,1,0)
df <- data.frame(cbind(C, A, E, L))
load("C:/Temp/tree.RData")# load the model for scoring
P <- as.character(predict(tree_model_1,df,type='class'))
Then in a C++ program
I call eval to evaluate the script and then findVar the P variable.
After get each class label from P using string_elt and then
Rf_translateChar, the characters are unicodes () instead of
utf8 encoding of the korean characters 부실.
Can I know how to get UTF8 by using R externals?
I also found the same script giving utf8 characters in RGui but unicode in
Rterm.
I tried to attach a screenshot but got message "The message's content type
was not explicitly allowed"
In RGui, I saw the output 부실, while in Rterm, .
Please help.
[[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
Re: [Rd] Recycling in arithmetic operations involving zero-length vectors
Sent from my iPhone > On Jan 16, 2023, at 6:11 PM, Duncan Murdoch wrote: > > On 16/01/2023 5:23 a.m., Roland Fuß wrote: >> Dear R-core, >> The language definition is very clear: >> "As from R 1.4.0, any arithmetic operation involving a zero-length >> vector has a zero-length result." >> Thus, `1 + numeric()` returns `numeric(0)`. However, I don't find this >> very intuitive because usually the shorter vector is recycled to the >> length of the longer vector. Would it be possible to throw at least a >> warning for such cases? I don't expect them to be intended by most users. >> Best regards, > > The previous paragraph says "If the length of the longer vector is not a > multiple of the shorter one, a warning is given." Since 1 is not a multiple > of 0, that implies a warning should be given here. > > However, R 1.4.0 was released more than 20 years ago, so I would guess there > are lots of packages intentionally using this. For example, it's a way to > propagate bad inputs through a long calculation that allows a single test at > the end. > > And even unintentional uses are unlikely to lead to problematic results: > numeric(0) is usually a pretty clear signal that something is wrong. > > So I'd suggest a documentation change: "As from R 1.4.0, any arithmetic > operation involving a zero-length vector has a zero-length result *without a > warning*." I doubt that a documentation change will help very much. Roland is responding here with his and my surprise at the lack of a warning after witnessing my answer to an R newb Q where the impression at seeing ’numeric(0) was understood as the value 0. I suggested that many interpretations were possible and that a warning was given for NA generation. I stand with Roland in thinking a warning is appropriate. David Winsemius > > Duncan Murdoch > > __ > 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] hist(..., log="y")
hist() is designed so that the total area sums to 1. You should build you desired behavior using a barchart. — David Sent from my iPhone > On Aug 5, 2023, at 11:50 PM, Ott Toomet wrote: > > Sorry if this topic has been discussed earlier. > > Currently, hist(..., log="y") fails with > >> hist(rexp(1000, 1), log="y") > Warning messages: > 1: In plot.window(xlim, ylim, "", ...) : > nonfinite axis=2 limits [GScale(-inf,2.59218,..); log=TRUE] -- corrected > now > 2: In title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) : > "log" is not a graphical parameter > 3: In axis(1, ...) : "log" is not a graphical parameter > 4: In axis(2, at = yt, ...) : "log" is not a graphical parameter > > The same applies for log="x" > >> hist(rexp(1000, 1), log="x") > Warning messages: > 1: In plot.window(xlim, ylim, "", ...) : > nonfinite axis=1 limits [GScale(-inf,0.954243,..); log=TRUE] -- corrected > now > 2: In title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) : > "log" is not a graphical parameter > 3: In axis(1, ...) : "log" is not a graphical parameter > 4: In axis(2, at = yt, ...) : "log" is not a graphical parameter > > This applies for the current svn version of R, and also a few recent > published versions. This is unfortunate for two reasons: > > * the error message is not quite correct--"log" is a graphical parameter, > but "hist" does not support it. > * for various kinds of data it is worthwhile to make histograms in log > scale. "hist" is a very nice and convenient function and support for log > scale would be handy here. > > I also played a little with the code, and it seems to be very easy to > implement. I am happy to make a patch if the team thinks it is worth > pursuing. > > Cheers, > Ott > >[[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
Re: [Rd] hist(..., log="y")
I guess my memory was off slightly. Densities are only plotted with freq=TRUE. Still there the ever present conundrum that 0 counts cannot be sensibly represented. Why not: hist( log(x), …) #? In situations where it might make sense. Sent from my iPhone > On Aug 6, 2023, at 9:01 AM, David Winsemius wrote: > > hist() is designed so that the total area sums to 1. You should build you > desired behavior using a barchart. > > — > David > > > Sent from my iPhone > >> On Aug 5, 2023, at 11:50 PM, Ott Toomet wrote: >> >> Sorry if this topic has been discussed earlier. >> >> Currently, hist(..., log="y") fails with >> >>> hist(rexp(1000, 1), log="y") >> Warning messages: >> 1: In plot.window(xlim, ylim, "", ...) : >> nonfinite axis=2 limits [GScale(-inf,2.59218,..); log=TRUE] -- corrected >> now >> 2: In title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) : >> "log" is not a graphical parameter >> 3: In axis(1, ...) : "log" is not a graphical parameter >> 4: In axis(2, at = yt, ...) : "log" is not a graphical parameter >> >> The same applies for log="x" >> >>> hist(rexp(1000, 1), log="x") >> Warning messages: >> 1: In plot.window(xlim, ylim, "", ...) : >> nonfinite axis=1 limits [GScale(-inf,0.954243,..); log=TRUE] -- corrected >> now >> 2: In title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) : >> "log" is not a graphical parameter >> 3: In axis(1, ...) : "log" is not a graphical parameter >> 4: In axis(2, at = yt, ...) : "log" is not a graphical parameter >> >> This applies for the current svn version of R, and also a few recent >> published versions. This is unfortunate for two reasons: >> >> * the error message is not quite correct--"log" is a graphical parameter, >> but "hist" does not support it. >> * for various kinds of data it is worthwhile to make histograms in log >> scale. "hist" is a very nice and convenient function and support for log >> scale would be handy here. >> >> I also played a little with the code, and it seems to be very easy to >> implement. I am happy to make a patch if the team thinks it is worth >> pursuing. >> >> Cheers, >> Ott >> >> [[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
Re: [Rd] broken link in docs for Binormial functions
On Aug 10, 2013, at 11:11 AM, Prof Brian Ripley wrote: > On 10/08/2013 14:48, Sean O'Riordain wrote: >> On the local documentation page for Binomial, i.e. >> http://127.0.0.1:/library/stats/html/Binomial.html >> >> The link to Catherine Loader's paper >> "Catherine Loader (2000). *Fast and Accurate Computation of Binomial >> Probabilities*; available from >> http://www.herine.net/stat/software/dbinom.html."; >> >> appears to be broken. > > And what should it be replaced by? (We've fixed this up at least once > before.) A copy can be had at: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC0QFjAA&url=http%3A%2F%2Fprojects.scipy.org%2Fscipy%2Fraw-attachment%2Fticket%2F620%2Floader2000Fast.pdf&ei=Q4cGUpuGA8qWyAHN6ICgAQ&usg=AFQjCNG2mDFe3iE0Xahyl0d6f2cazTKgFQ&sig2=Ghc7H91rILXLrBLlJjQTJA Ugggh. Does anyone else hate the Google encoding that was adopted a couple of years ago? http://projects.scipy.org/scipy/raw-attachment/ticket/620/loader2000Fast.pdf > > As Berners-Lee says, URIs should be permanent > >> >> Kind regards, >> Seán >> >> [[alternative HTML version deleted]] >> >> -- David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table() with quoted integers
On Sep 30, 2013, at 6:38 AM, Joshua Ulrich wrote:
> On Mon, Sep 30, 2013 at 7:33 AM, Milan Bouchet-Valat
> wrote:
>> Hi!
>>
>>
>> It seems that read.table() in R 3.0.1 (Linux 64-bit) does not consider
>> quoted integers as an acceptable value for columns for which
>> colClasses="integer". But when colClasses is omitted, these columns are
>> read as integer anyway.
>>
>> For example, let's consider a file named file.dat, containing:
>> "1"
>> "2"
>>
>>> read.table("file.dat", colClasses="integer")
>> Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, :
>> scan() expected 'an integer' and got '"1"'
>>
>> But:
>>> str(read.table("file.dat"))
>> 'data.frame': 2 obs. of 1 variable:
>> $ V1: int 1 2
>>
>> The latter result is indeed documented in ?read.table:
>> Unless ‘colClasses’ is specified, all columns are read as
>> character columns and then converted using ‘type.convert’ to
>> logical, integer, numeric, complex or (depending on ‘as.is’)
>> factor as appropriate. Quotes are (by default) interpreted in all
>> fields, so a column of values like ‘"42"’ will result in an
>> integer column.
>>
>>
>> Should the former behavior be considered a bug?
>>
> No. If you tell read.table the column is integer and it's actually
> character on disk, it should be an error.
My reading of the `read.table` help page is that one should expect that when
there is an 'integer'-class and an `as.integer` function and "integer" is the
argument to colClasses, that `as.integer` will be applied to the values in the
column. Should I be reading elsewhere?
--
David.
>
>> This creates problems when combined with read.table.ffdf from package
>> ff, since this function tries to guess the column classes by reading the
>> first rows of the file, and then passes colClasses to read.table to read
>> the remaining rows by chunks. A column of quoted integers is correctly
>> detected as integer in the first read, but read.table() fails in
>> subsequent reads.
>>
> This sounds like a issue with read.table.ffdf. The column of quoted
> integers is *incorrectly* detected as integer because they're actually
> character on disk. read.table.ffdf should rely on how the data are
> actually stored on disk (via as.is=TRUE), not how read.table might
> convert them once they're read into R.
>
>>
>> Regards
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Joshua Ulrich | about.me/joshuaulrich
> FOSS Trading | www.fosstrading.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion for help page for ?plotmath
May I suggest a minor addition to the existing help page for ?plotmath, ... immediately following: "Note that bold, italic and bolditalic do not apply to symbols, and hence not to the Greek symbols such as mu which are displayed in the symbol font. They also do not apply to numeric constants." Add: "Digits entered as text will be affected by bold, italic and bolditalic." "The paste function in plotmath does not have a 'sep' argument, and if any value other than sep="" is used with paste, that text will appear at the end of the plotted expression." -- David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] freetype 2.5.2, problem with the survival package, build R 2.15.x with gcc 4.8.x
/ . >> >> Just a reminder that the official R binaries for windows/mac OS X are >> statically >> linked with rather dated versions of freetype with a few known issues. This >> affects the cairo-based functionalities in R. So a rebuild is needed. >> >> Most unix users should just upgrade their system's libfreetype, and >> dynamic-linking should take care of the rest. > > __ > r-h...@r-project.org mailing list > 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. David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] freetype 2.5.2, problem with the survival package, build R 2.15.x with gcc 4.8.x
vignette output when code was run being from what was expected was causing a segfault under some situation that I cannot quite reconstruct. Was the implication that Mac users (of 2.15.x) need to build from sources only if they wanted to build the survival package from source? Does this have any implications for those of us who use the survival package as the binary? (And I'm using 3.0.2, so a split answer might be needed to cover 2.15.x and the current versions separately) -- David. > > Hin-Tak Leung wrote: >> The freetype people fixed the 2nd set of issues with system fonts shipped >> with >> Mac OS X, and released 2.5.1 almost immediately after that. So there are >> new bundles under http://sourceforge.net/projects/outmodedbonsai/files/R/ . >> >> Just a reminder that the official R binaries for windows/mac OS X are >> statically >> linked with rather dated versions of freetype with a few known issues. This >> affects the cairo-based functionalities in R. So a rebuild is needed. >> >> Most unix users should just upgrade their system's libfreetype, and >> dynamic-linking should take care of the rest. > > __ > r-h...@r-project.org mailing list > 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. David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [RFC] A case for freezing CRAN
On Mar 19, 2014, at 7:45 PM, Jeroen Ooms wrote: > On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt > wrote: >> Reading this thread again, is it a fair summary of your position to say >> "reproducibility by default is more important than giving users access to >> the newest bug fixes and features by default?" It's certainly arguable, but >> I'm not sure I'm convinced: I'd imagine that the ratio of new work being >> done vs reproductions is rather high and the current setup optimizes for >> that already. > > I think that separating development from released branches can give us > both reliability/reproducibility (stable branch) as well as new > features (unstable branch). The user gets to pick (and you can pick > both!). The same is true for r-base: when using a 'released' version > you get 'stable' base packages that are up to 12 months old. If you > want to have the latest stuff you download a nightly build of r-devel. > For regular users and reproducible research it is recommended to use > the stable branch. However if you are a developer (e.g. package > author) you might want to develop/test/check your work with the latest > r-devel. > > I think that extending the R release cycle to CRAN would result both > in more stable released versions of R, as well as more freedom for > package authors to implement rigorous change in the unstable branch. > When writing a script that is part of a production pipeline, or sweave > paper that should be reproducible 10 years from now, or a book on > using R, you use stable version of R, which is guaranteed to behave > the same over time. However when developing packages that should be > compatible with the upcoming release of R, you use r-devel which has > the latest versions of other CRAN and base packages. As I remember ... The example demonstrating the need for this was an XML package that cause an extract from a website where the headers were misinterpreted as data in one version of pkg:XML and not in another. That seems fairly unconvincing. Data cleaning and validation is a basic task of data analysis. It also seems excessive to assert that it is the responsibility of CRAN to maintain a synced binary archive that will be available in ten years. Bug fixes would be inhibited for years not unlike SAS and Excel. What next? Perhaps al bugs should be labeled as features? Surely this CRAN-of-the-future would be offering something that no other statistical package currently offers, nicht wahr? Why not leave it to the authors to specify the packages which version numbers were used in their publications. The authors of the packages would get recognition and the dependencies would be recorded. -- David. > > >> What I'm trying to figure out is why the standard "install the following >> list of package versions" isn't good enough in your eyes? > > Almost nobody does this because it is cumbersome and impractical. We > can do so much better than this. Note that in order to install old > packages you also need to investigate which versions of dependencies > of those packages were used. On win/osx, users need to manually build > those packages which can be a pain. All in all it makes reproducible > research difficult and expensive and error prone. At the end of the > day most published results obtain with R just won't be reproducible. > > Also I believe that keeping it simple is essential for solutions to be > practical. If every script has to be run inside an environment with > custom libraries, it takes away much of its power. Running a bash or > python script in Linux is so easy and reliable that entire > distributions are based on it. I don't understand why we make our > lives so difficult in R. > > In my estimation, a system where stable versions of R pull packages > from a stable branch of CRAN will naturally resolve the majority of > the reproducibility and reliability problems with R. And in contrast > to what some people here are suggesting it does not introduce any > limitations. If you want to get the latest stuff, you either grab a > copy of r-devel, or just enable the testing branch and off you go. > Debian 'testing' works in a similar way, see > http://www.debian.org/devel/testing. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Historical NA question
On May 6, 2014, at 1:06 PM, Hervé Pagès wrote: > On 05/06/2014 12:36 PM, William Dunlap wrote: >> When does els%in%set give a different result than is.element(els,set)? >> I assumed they were copied form S+, where they are the same except >> for argument names, but I may be wrong. > > > els <- 2:1 > > set <- 1:6 > > - els%in%set > [1] FALSE FALSE > > - is.element(els,set) > [1] -1 -1 > That is not demonstrating that " els%in%set gives a different result than is.element(els,set) ". It is again demonstrating that "-" has a higher precedence than '%in%'. > -(els%in%set) [1] -1 -1 > > - is.element(els,set) [1] -1 -1 -- David. > So following your advice doesn't really help me leave my precedence > problems behind. > > H. > >> Bill Dunlap >> TIBCO Software >> wdunlap tibco.com >> >> >> On Tue, May 6, 2014 at 12:23 PM, Hervé Pagès wrote: >>> On 05/06/2014 08:54 AM, William Dunlap wrote: >>>> >>>> You can also use is.element(els,set) instead of the equivalent >>>> els%in%set >>> >>> >>> No they are not *equivalent*. Equivalent means you could substitute >>> one by the other in your code without changing its behavior. >>> >>> H. >>> >>>> and leave your precedence problems behind. >>>> Bill Dunlap >>>> TIBCO Software >>>> wdunlap tibco.com >>>> >>>> >>>> On Mon, May 5, 2014 at 10:35 PM, peter dalgaard wrote: >>>>> >>>>> >>>>> On 06 May 2014, at 01:05 , Hervé Pagès wrote: >>>>> >>>>>> >>>>>> BTW, that %in% has precedence over arithmetic operations is surprising, >>>>>> error-prone, and doesn't cover any reasonable use case (who needs to >>>>>> multiply the logical vector returned by %in% by some value?) but that's >>>>>> another story: >>>>> >>>>> >>>>> The point here is that the %foo% operators all have the _same_ >>>>> precedence. In principle, they can be user-coded, and there is no way to >>>>> express what precedence is desirable. It may turn out slightly weird for >>>>> %in%, but think of what would happen if %*% had lower precedence than >>>>> addition. >>>>> >>>>> -- >>>>> Peter Dalgaard, Professor, >>>>> Center for Statistics, Copenhagen Business School >>>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >>>>> Phone: (+45)38153501 >>>>> Email: pd@cbs.dk Priv: pda...@gmail.com >>>>> >>>>> __ >>>>> R-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >>> -- >>> Hervé Pagès >>> >>> Program in Computational Biology >>> Division of Public Health Sciences >>> Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N, M1-B514 >>> P.O. Box 19024 >>> Seattle, WA 98109-1024 >>> >>> E-mail: hpa...@fhcrc.org >>> Phone: (206) 667-5791 >>> Fax:(206) 667-1319 > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fhcrc.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE) : error in running command
On Aug 22, 2014, at 2:53 PM, Rui Barradas wrote:
> Hello,
>
> Inline.
>
> Em 22-08-2014 22:18, Tobias Verbeke escreveu:
>> - Original Message -
>>> From: "Marius Hofert"
>>> To: "R-devel"
>>> Sent: Friday, August 22, 2014 10:03:13 PM
>>> Subject: [Rd] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE)
>>> : error in running command
>>>
>>> Hi,
>>>
>>> Both under the current R-devel (r66456) and a version from about 3
>>> months ago, I experience the following behavior:
>>>
>>>> parallel::detectCores(TRUE)
>>> Error in system(cmd, TRUE) : error in running command
>>>> traceback()
>>> 3: system(cmd, TRUE)
>>> 2: gsub("^ +", "", system(cmd, TRUE)[1])
>>> 1: parallel::detectCores(TRUE)
>>>>
>>>
>>> This is on Ubuntu 14.04. Does anybody else see this? [I currently have
>>> quite a heavy workload, otherwise I would have installed and tested it
>>> also under 3.1.1]
>>
>> Same under R 3.1.1
>>
>>> parallel::detectCores(TRUE)
>> Error in system(cmd, TRUE) : error in running command
>
> I'm Using R 3.1.1 on Windows 7 and it works.
>
> > parallel::detectCores(TRUE)
> [1] 4
> > sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
Works on a 6 year-old MacPro with R 3.1.0
> parallel::detectCores(TRUE)
[1] 8
> sessionInfo()
R version 3.1.0 Patched (2014-04-21 r65431)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
--
david.
>
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error message library()
On Oct 28, 2011, at 12:02 PM, Gabor Grothendieck wrote: On Fri, Oct 28, 2011 at 6:49 AM, Renaud Gaujoux wrote: "BTW: an ever more intuitive solution (IMHO) would be to auto- complete package names in library( ... Deepayan?;) That is non-intrusive and in line with the general use of R." (Simon) This is indeed a long wanted feature and to my surprise it actually already exists!!! (seems that Deepayan did not tell anybody about it ;) ) The help page ?completion in the utils package explains how to enable it: utils::rc.settings(ipck=TRUE) It simply worked on my Ubuntu box -- and directly went in my .Rprofile :) Hope this helps. Also in terms of what exists now, on Windows the Packages > Load Package menu on Rgui provides a gui interface to library() from which one chooses the package from a list so one can't ask for one that does not exist. On a Mac with R.app the same facility exists which I how I check to see if a package is available in one of four forms (mac-binary, mac- source, Bioc-binary, Bioc-source). -- David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in R-Forge
On Nov 18, 2011, at 1:00 PM, Jordi Gutiérrez Hermoso wrote: I'm sorry about the tone of my previous email. Let me try again in a cleaner way. The problem is: R or the organisation behind R via its infrastructure seems to be endorsing R-Forge, and R-Forge is hosting at least one project whose sole purpose is to link R with non-free software. This looks like endorsement of non-free software, which is contrary to the aims of the GNU project, of which R today claims to be a part. Are you aware that R has two other major trunks besides the Linux one? Those of us with Mac or Windows hardware/software devices might be threatened with discontinuation of our access to R if your logic prevails. There are several solutions, but the only workable ones I see are to either sever ties with the GNU project, clearly remove the endorsement of the non-free project, or to make the non-free project free. Of these, it is my sincere hope that the last one happens. This entire argument seems quasi-religious. You seem to be claiming that there is a "non-free" moral and legal sinfulness that is passed by way of links on websites. There do not seem to be any boundaries to this process that are discernable from your writings. That is all. - Jordi G. H. David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu: result
On Jan 11, 2012, at 10:02 AM, Claudia Beleites wrote: Dear list, for the benefit of people searching for this in the future (and as r-devel archives are searched by RSiteSearch, The Baron search page claims to search r-devel, but most of my attempts to follow the links it offers have failed. They end up at links like: http://finzi.psych.upenn.edu/R/R-devel/2010-December/059322.html (which 404s.) I instead search the r-devel Archive with Google Advanced Search with a domain of site:https://stat.ethz.ch/pipermail/r-devel/ I just edited the URL to see if the directory and naming conventions would agree and they do seem to, https://stat.ethz.ch/pipermail/r-devel/2010-December/059322.html so I will copy this to John Baron to see if he wants to address it. -- David. but r-sig-debian isn't): - command line completion of the R command doesn't have anything to do with R - Deepayan told me that as far as he knows, only Debian (and Ubuntu) have it, so R-sig-debian is the appropriate mailing list. Deepayan moved the discussion there. Thanks. Have a nice day, Claudia David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.spss issues
On Feb 15, 2012, at 3:28 PM, Thomas Lumley wrote:
On Wed, Feb 15, 2012 at 7:05 PM, Jeroen Ooms > wrote:
The second problem is that the spss dataformat allows to specify
'duplicate labels', whereas this is not allowed for factors.
read.spss
does not deal with this and creates a bad factor
x <- read.spss("http://www.stat.ucla.edu/~jeroen/spss/duplicate_labels.sav
",
use.value.labels=T);
levels(x$opinion);
which causes issues downstream. I am not sure if this is an issue in
read.spss() or as.factor(), but I guess it might be wise to try to
detect duplicate levels and assign them all with one and the same
integer value when converting to a factor.
I think this one would be better dealt with by giving an error.
SPSS value labels are just labels, so they don't map very well onto R
factors, which are enumerated types. Rather than force them and lose
data, I would prefer to make the user decide what to do.
I could imagine that users might appreciate the possibility of getting
the data from read.spss one pass, but also getting the labels from a
separate function that made a best guess at what was needed but did
not try to unambiguously match up variables with factor levels for all
variables. For big datasets, there might be only a few edits needed to
throw out duplicates and save a lot of typing errors.
--
David Winsemius, MD
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Convenience function to get unevaluated ... function arguments
On Jul 24, 2012, at 4:39 PM, Bert Gunter wrote:
Folks:
Herein is a suggestion for a little R convenience function mainly to
obtain unevaluated ... function arguments. It arose from a query on
R-help on how to get these arguments. The standard (I think) idiom to
do this is via
match.call(expand.dots=FALSE)$...
However, Bill Dunlap pointed out that this repeats the argument
matching of the function call and suggested a couple of alternatives
that do not, one of which I've adapted as the following function,fun
(I'll comment on naming in a second):
fun <- as.list(substitute((...), env = parent.frame()))[-1]
I think instead:
fun <- function() as.list(substitute((...), env = parent.frame()))[-1]
--
David.
Typical usage would be:
f <- function(x, ...,y)fun()
e.g.
f(x = 5,z=sin(a),y=3,stop("oh"),w=warning("Yikes"))
$z
sin(a)
[[2]]
stop("oh")
$w
warning("Yikes")
It turns out that (surprisingly to me) the substitute idiom is faster
than the match.call idiom, although the difference appears
unimportant, since both are so fast. And it is a little slower when
wrapped into a function, anyway -- I wasn't able to figure out a
convenient way to wrap the match.call version into a function.
The question is where -- if anywhere -- should this little one-liner
go? Seems to me that there are 3 possibilities:
1. Nowhere. Unnecessary and trivial. An entirely reasonable response,
imho; I leave it to guRus to make this judgment.
2. In with match.call(); in which case a name like match.dots would
seem appropriate.
3. In with substitute(); in which case something like substituteDots
to make the relationship clear might be appropriate.
If R core or others do want to use this, I would be happy to write the
line or two of additional documentation required (if no one else wants
to).
And to repeat... I know this is trivial, so no explanation or response
is needed if it is decided to ignore it.
Best,
Bert
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius, MD
Heritage Laboratories
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD SHLIB error bad value (core2) for -mtune= switch
On Oct 23, 2012, at 10:58 AM, smzyij wrote: > Thank you so much Prof Ripley. > > You are right. So instead of using Windows R, I tried to compile binary R > under Cygwin, but it errored out everytime at different places when I tried > different options to configure. So I guess I need to seek other alternate > ways. > > Is there any chance you think that I could find Windows C/C++ compilers > (rather than Cygwin compilers) to compile the codes I mentioned that's > written in conjuction with Linux R/C/C++, and then run the codes under > Windows R? Or the only way out here is to spin up a linux machine to have R > installed? > http://cran.r-project.org/bin/windows/base/rw-FAQ.html#Building-from-Source http://cran.r-project.org/doc/manuals/R-admin.html http://cran.r-project.org/doc/manuals/R-admin.html#Getting-the-tools http://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset > > -- > View this message in context: > http://r.789695.n4.nabble.com/R-CMD-SHLIB-error-bad-value-core2-for-mtune-switch-tp4645928p4647182.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- David Winsemius, MD Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Mac v Windows Mystery
I think neither of the attachments made it through, at least not to my
client. If you use the regular Mac Mail.app (or any of hte Windows
clients that I have seen). I suspect it labels the attachments as
something other than MIME-text. The best way to get things though the
R-mailing server is to give the files both .txt extensions and let the
recipients change the extension names as needed. Then both Mac and
Windows mail clients will give the proper mail headers so they reach
the R-subscribers.
--
David.
On Jan 30, 2013, at 11:37 AM, Roger Koenker wrote:
Dear All,
I'm trying to track down a problem with my quantreg package reported
by a user doing censored quantile regression.
When he runs the test4.R file attached below (which reads the csv
file also attached) on his windows machine he gets
an error like this:
Error in dimnames(B) <- list(c("tau", dimnames(x)[[2]], "Qhat"),
NULL) :
length of 'dimnames' [1] not equal to array extent
In addition: Warning message:
In rbind(grid[1:J], B, qhat) :
number of columns of result is not a multiple of vector length
(arg 2)
However, when I run the same thing on my mac there is no error, no
warning. And --
more strangely-- running this on another windows laptop here in
Urbana also encounters
no problems. I thought that this might just be a seed problem since
there is a bootstrapping
step at the end, but the original user has tried several seeds and
always gets this error.
We are all running 2.15.1 and V4.94 of quantreg. I understand that
YMMV, especially on
windows, but it is difficult to debug this sort of thing when I
can't reproduce it. Any suggestions
or other experience would be welcome. The test problem takes a
minute or so to run on my
mac.
Thanks,
Roger
url:www.econ.uiuc.edu/~rogerRoger Koenker
emailrkoen...@uiuc.eduDepartment of Economics
vox: 217-333-4558University of Illinois
fax: 217-244-6678Urbana, IL 61801
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius, MD
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
> Hi Davor,
>
> To the best of my knowledge, there's only one way to use functions
> from a suggested package: with require:
>
> if (require("suggested_package")) {
> function_from_suggested_package()
> } else {
> stop("suggested package not installed")
> }
>
> Unfortunately I don't think there's any way to use a suggested package
> without polluting the search path.
I've always wondered: How does lattice manage to use grid functions without
putting them on the search path?
--
David
>
> Hadley
>
> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
>> If in my package "Foo" I call a function from another package "Bar" if it's
>> available, according to R-exts, this sounds like I should include "Suggests:
>> Bar" in package Foo's description. But the manual is silent on how to treat
>> Bar's namespace. Should I import it? If so, should this be conditional or
>> unconditional? There is a thread from 2008 in which Duncan Murdoch suggests
>> trying conditionally importing a package if it's installed, with the caveat
>> "If this is allowed"
>> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
>> to work in current release of R, 2.15.2, but I'm still not clear if it's
>> officially allowed, much less recommended.
>>
>> The manual also says:
>>
>>> If a package only needs a few objects from another package it can use a
>>> fully qualified variable reference in the code instead of a formal import.
>>> A fully qualified reference to the function f in package foo is of the form
>>> foo::f. This is slightly less efficient than a formal import and also loses
>>> the advantage of recording all dependencies in the NAMESPACE file, so this
>>> approach is usually not recommended. Evaluating foo::f will cause package
>>> foo to be loaded, but not attached, if it was not loaded already—this can
>>> be an advantage in delaying the loading of a rarely used package.
>>>
>>
>>
>> Would this be a better solution than importing when calling into a suggested
>> package?
>>
>> Davor
>>
>>
>>[[alternative HTML version deleted]]
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recommended way to call/import functions from a Suggested package
On Feb 22, 2013, at 6:39 PM, David Winsemius wrote:
>
> On Feb 22, 2013, at 6:13 PM, Hadley Wickham wrote:
>
>> Hi Davor,
>>
>> To the best of my knowledge, there's only one way to use functions
>> from a suggested package: with require:
>>
>> if (require("suggested_package")) {
>> function_from_suggested_package()
>> } else {
>> stop("suggested package not installed")
>> }
>>
>> Unfortunately I don't think there's any way to use a suggested package
>> without polluting the search path.
>
> I've always wondered: How does lattice manage to use grid functions without
> putting them on the search path?
Maybe I am using the wrong terminology, so here is the behavior I'm referring
to:
> sessionInfo()
snipped version an locale ino
attached base packages:
[1] grDevices datasets splines graphics utils stats methods base
other attached packages:
[1] rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5 brew_1.0-6
[6] lattice_0.20-10
loaded via a namespace (and not attached):
[1] cluster_1.14.3 grid_2.15.2
Notice that lattice is loaded from my profile
> require(ggplot2)
Loading required package: ggplot2
> sessionInfo()
snipped version an locale ino
attached base packages:
[1] grDevices datasets splines graphics utils stats methods base
other attached packages:
[1] ggplot2_0.9.3 rms_3.6-2 Hmisc_3.10-1survival_2.37-2 sos_1.3-5
[6] brew_1.0-6 lattice_0.20-10
loaded via a namespace (and not attached):
[1] cluster_1.14.3 colorspace_1.2-1 dichromat_2.0-0digest_0.6.0
[5] grid_2.15.2gtable_0.1.2 labeling_0.1 MASS_7.3-22
[9] munsell_0.4plyr_1.8 proto_0.3-10 RColorBrewer_1.0-5
[13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2
> ?grid.text
No documentation for ‘grid.text’ in specified packages and libraries:
you could try ‘??grid.text’
So at least the help system cannot find a grid function.
> ?grid::grid.text
starting httpd help server ... done
> grid.text
Error: object 'grid.text' not found
Neither can the R interpreter find it. But it's clearly available if you ask
nicely:
> grid::grid.text
function (label, x = unit(0.5, "npc"), y = unit(0.5, "npc"),
just = "centre", hjust = NULL, vjust = NULL, rot = 0, check.overlap =
FALSE,
default.units = "npc", name = NULL, gp = gpar(), draw = TRUE,
vp = NULL)
{
tg <- textGrob(label = label, x = x, y = y, just = just,
hjust = hjust, vjust = vjust, rot = rot, check.overlap = check.overlap,
default.units = default.units, name = name, gp = gp,
vp = vp)
if (draw)
grid.draw(tg)
invisible(tg)
}
--
David/
>
> --
> David
>>
>> Hadley
>>
>> On Fri, Feb 22, 2013 at 6:26 PM, Davor Cubranic wrote:
>>> If in my package "Foo" I call a function from another package "Bar" if it's
>>> available, according to R-exts, this sounds like I should include
>>> "Suggests: Bar" in package Foo's description. But the manual is silent on
>>> how to treat Bar's namespace. Should I import it? If so, should this be
>>> conditional or unconditional? There is a thread from 2008 in which Duncan
>>> Murdoch suggests trying conditionally importing a package if it's
>>> installed, with the caveat "If this is allowed"
>>> (http://tolstoy.newcastle.edu.au/R/e5/devel/08/10/0488.html). This appears
>>> to work in current release of R, 2.15.2, but I'm still not clear if it's
>>> officially allowed, much less recommended.
>>>
>>> The manual also says:
>>>
>>>> If a package only needs a few objects from another package it can use a
>>>> fully qualified variable reference in the code instead of a formal import.
>>>> A fully qualified reference to the function f in package foo is of the
>>>> form foo::f. This is slightly less efficient than a formal import and also
>>>> loses the advantage of recording all dependencies in the NAMESPACE file,
>>>> so this approach is usually not recommended. Evaluating foo::f will cause
>>>> package foo to be loaded, but not attached, if it was not loaded
>>>> already—this can be an advantage in delaying the loading of a rarely used
>>>> package.
>>>>
>>>
>>>
>>> Would this be a better solution than importing when calling into a
>>> suggested package?
>>>
>>> Davor
>>>
>
Re: [Rd] Bugs due to naive copying of list elements
On Mar 12, 2013, at 3:59 AM, Radford Neal wrote: > Several bugs are present in R-2.15.3 and R-alpha due to > naive copying of list elements. > > The bug below is due to naive copying in subset.c (with > similar bugs for matrices and arrays): > > a<-list(c(1,2),c(3,4),c(5,6)) > b<-a[2:3] > a[[2]][2]<-9 > print(b[[1]][2]) This is an example of lazy evaluation, right? > > Naive copying in mapply.c leads to the following bug: > > X<-1+1 > f<-function(a,b) X > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > print(A) > X[1]<-99 > print(A) > Is this a bug in mapply()? or in print()? I thought 'print' should evaluate its argument and "force" the promise to be executed. Or does it just return the same promise as was passed to it? Compare: X<-1+1 f<-function(a,b) X A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) print(A); str(A) X[1]<-99 print(A) Could someone could comment on what 'force' actually does. I am unclear why force(A) in the code above in the pace of str(A) did not have the effect I expected, whereas str(b) or str(A) did have that effect. > a<-list(c(1,2),c(3,4),c(5,6)) > b<-a[2:3]; force(b) [[1]] [1] 3 4 [[2]] [1] 5 6 > a[[2]][2]<-9 > print(b[[1]][2]) [1] 9 #-- > X<-1+1 > f<-function(a,b) X > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > print(A); force(A) [[1]] [1] 2 [[2]] [1] 2 [[3]] [1] 2 [[1]] [1] 2 [[2]] [1] 2 [[3]] [1] 2 > X[1]<-99 > print(A) [[1]] [1] 99 [[2]] [1] 99 [[3]] [1] 99 > Similar bugs exist in eapply, rapply, and vapply. > -- David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] mean.data.frame: R 3.0.0 help page wrong?
The help page for mean still says there is a method for data.frame although this has been deprecated for several versions and in R 3.0.0 beta I get: mean(data.frame(x=rnorm(10), y=rnorm(10)) ) [1] NA Warning message: In mean.default(data.frame(x = rnorm(10), y = rnorm(10))) : argument is not numeric or logical: returning NA I read in news(): o mean() for data frames and sd() for data frames and matrices are defunct. Shouldn't the help page be amended? -- David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation request Re: [R] recode categorial vars into binary data
On May 7, 2013, at 10:54 AM, Chris Stubben wrote: > >> First off, stop using cbind() when it is not needed. You will not see the >> reason when the columns are all numeric but you will start experiencing pain >> and puzzlement when the arguments are of mixed classes. The data.frame >> function will do what you want. (Where do people pick up this practice >> anyway?) > > Maybe from help( data.frame)? > > It's in most of the examples and is not needed ... > > L3 <- LETTERS[1:3] >(d <- data.frame(cbind(x=1, y=1:10), fac=sample(L3, 10, replace=TRUE))) >## The same with automatic column names: >data.frame(cbind( 1, 1:10), sample(L3, 10, replace=TRUE)) > > Chris There are many instances of new users posting questions to R-help where they use the form: dfrm <- data.frame(cbind(1:10, letter[1:10]) ) … and predictably get a character mode for all their columns. I was pointed to the help page for `data.frame` as one possible source of this confusion. I would like to request that the examples be changed to: L3 <- LETTERS[1:3] (d <- data.frame(x = 1, y = 1:10, fac = sample(L3, 10, replace = TRUE))) ## The same with automatic column names: data.frame( 1, 1:10, sample(L3, 10, replace = TRUE)) -- David Winsemius Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
