Re: [Rd] zapsmall(x) for scalar x
Isn’t that the correct outcome? The user can change the number of digits if
they want to see small values…
--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale
> On Dec 17, 2023, at 12:11 AM, Steve Martin wrote:
>
> Zapping a vector of small numbers to zero would cause problems when
> printing the results of summary(). For example, if
> zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
> print(summary(2.220446e-16), digits = 7) would print
> Min. 1st Qu. MedianMean 3rd Qu.Max.
>0 00 0 0 0
>
> The same problem can also appear when printing the results of
> summary.glm() with show.residuals = TRUE if there's little dispersion
> in the residuals.
>
> Steve
>
>> On Sat, 16 Dec 2023 at 17:34, Gregory Warnes wrote:
>>
>> I was quite suprised to discover that applying `zapsmall` to a scalar value
>> has no apparent effect. For example:
>>
>>> y <- 2.220446e-16
>>> zapsmall(y,)
>> [1] 2.2204e-16
>>
>> I was expecting zapsmall(x)` to act like
>>
>>> round(y, digits=getOption('digits'))
>> [1] 0
>>
>> Looking at the current source code, indicates that `zapsmall` is expecting a
>> vector:
>>
>> zapsmall <-
>> function (x, digits = getOption("digits"))
>> {
>>if (length(digits) == 0L)
>>stop("invalid 'digits'")
>>if (all(ina <- is.na(x)))
>>return(x)
>>mx <- max(abs(x[!ina]))
>>round(x, digits = if (mx > 0) max(0L, digits - as.numeric(log10(mx)))
>> else digits)
>> }
>>
>> If `x` is a non-zero scalar, zapsmall will never perform rounding.
>>
>> The man page simply states:
>> zapsmall determines a digits argument dr for calling round(x, digits = dr)
>> such that values close to zero (compared with the maximal absolute value)
>> are ‘zapped’, i.e., replaced by 0.
>>
>> and doesn’t provide any details about how ‘close to zero’ is defined.
>>
>> Perhaps handling the special when `x` is a scalar (or only contains a single
>> non-NA value) would make sense:
>>
>> zapsmall <-
>> function (x, digits = getOption("digits"))
>> {
>>if (length(digits) == 0L)
>>stop("invalid 'digits'")
>>if (all(ina <- is.na(x)))
>>return(x)
>>mx <- max(abs(x[!ina]))
>>round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L, digits -
>> as.numeric(log10(mx))) else digits)
>> }
>>
>> Yielding:
>>
>>> y <- 2.220446e-16
>>> zapsmall(y)
>> [1] 0
>>
>> Another edge case would be when all of the non-na values are the same:
>>
>>> y <- 2.220446e-16
>>> zapsmall(c(y,y))
>> [1] 2.220446e-16 2.220446e-16
>>
>> Thoughts?
>>
>>
>> Gregory R. Warnes, Ph.D.
>> g...@warnes.net
>> Eternity is a long time, take a friend!
>>
>>
>>
>>[[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
Re: [Rd] Recent changes to as.complex(NA_real_)
It sounds like we need to add arguments (with sensible defaults) to complex(), Re(), Im(), is.na.complex() etc to allow the user to specify the desired behavior. -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On Sep 23, 2023, at 12:37 PM, Mikael Jagan wrote: > > > > On 2023-09-23 9:43 am, Martin Maechler wrote: >>> Hervé Pagès >>> on Fri, 22 Sep 2023 16:55:05 -0700 writes: >> > The problem is that you have things that are >> > **semantically** different but look exactly the same: >> > They look the same: >> >> x >> > [1] NA >> >> y >> > [1] NA >> >> z >> > [1] NA >> >> is.na(x) >> > [1] TRUE >> >> is.na(y) >> > [1] TRUE >> >> is.na(z) >> > [1] TRUE >> >> str(x) >> > cplx NA >> >> str(y) >> > num NA >> >> str(z) >> > cplx NA >> > but they are semantically different e.g. >> >> Re(x) >> > [1] NA >> >> Re(y) >> > [1] -0.5 # surprise! >> >> Im(x) # surprise! >> > [1] 2 >> >> Im(z) >> > [1] NA >> > so any expression involving Re() or Im() will produce >> > different results on input that look the same on the >> > surface. >> > You can address this either by normalizing the internal >> > representation of complex NA to always be complex(r=NaN, >> > i=NA_real_), like for NA_complex_, or by allowing the >> > infinite variations that are currently allowed and at the >> > same time making sure that both Re() and Im() always >> > return NA_real_ on a complex NA. >> > My point is that the behavior of complex NA should be >> > predictable. Right now it's not. Once it's predictable >> > (with Re() and Im() both returning NA_real_ regardless of >> > internal representation), then it no longer matters what >> > kind of complex NA is returned by as.complex(NA_real_), >> > because they are no onger distinguishable. >> > H. >> > On 9/22/23 13:43, Duncan Murdoch wrote: >> >> Since the result of is.na(x) is the same on each of >> >> those, I don't see a problem. As long as that is >> >> consistent, I don't see a problem. You shouldn't be using >> >> any other test for NA-ness. You should never be >> >> expecting identical() to treat different types as the >> >> same (e.g. identical(NA, NA_real_) is FALSE, as it >> >> should be). If you are using a different test, that's >> >> user error. >> >> >> >> Duncan Murdoch >> >> >> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: >> >>> We could also question the value of having an infinite >> >>> number of NA representations in the complex space. For >> >>> example all these complex values are displayed the same >> >>> way (as NA), are considered NAs by is.na(), but are not >> >>> identical or semantically equivalent (from an Re() or >> >>> Im() point of view): >> >>> >> >>> NA_real_ + 0i >> >>> >> >>> complex(r=NA_real_, i=Inf) >> >>> >> >>> complex(r=2, i=NA_real_) >> >>> >> >>> complex(r=NaN, i=NA_real_) >> >>> >> >>> In other words, using a single representation for >> >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would >> >>> avoid a lot of unnecessary complications and surprises. >> >>> >> >>> Once you do that, whether as.complex(NA_real_) should >> >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_, >> >>> i=NA_real_) becomes a moot point. >> >>> >> >>> Best, >> >>> >> >>> H. >> Thank you, Hervé. >> Your proposition is yet another one, >> to declare that all complex NA's should be treated as identical >> (almost/fully?) everywhere. >> This would be a possibility, but I think a drastic one. >> I think there are too many cases, where I want to keep the >> information of the real part independent of the values of the >> imaginary part (e.g. think of the Riemann hypothesis), and >> typically vice versa. >> With your proposal, for a (potentially large) vector of complex numbers, >> after >> Re(z) <- 1/2 >> I could no longer rely on Re(z) == 1/2, >> because it would be wrong for those z where (the imaginary part/ the number) >> was NA/NaN. >> Also, in a similar case, a >> Im(z) <- NA >> would have to "destroy" all real parts Re(z); >> not really typically in memory, but effectively for the user, Re(z) >> would be all NA/NaN. >> And I think there are quite a few other situations >> where looking at Re() and Im() separately makes a lot of sense. > > Indeed, and there is no way to "tell" BLAS and LAPACK to treat both the real > and > imaginary parts as NA_REAL when either is NA_REAL. Hence the only reliable > way > to implement such a proposal would be to post-process the result of any > computation returning a complex type, testing for NA_REAL and setting both > parts > to NA_REAL in that case. My expectation is that such
Re: [Rd] Programming Tools CTV
I second the motion for a Programming Tools CRAN Task View. I would also think it could contain things like Rcpp, R6, etc. -Greg On Jan 22, 2015, at 10:20 AM, Max Kuhn mxk...@gmail.com wrote: I've had a lot of requests for additions to the reproducible research task view that fall into a grey area (to me at least). For example, roxygen2 is a tool that broadly enable reproducibility but I see it more as a tool for better programming. I'm about to check in a new version of the task view that includes packrat and checkpoint, as they seem closer to reproducible research, but also feel like coding tools. There are a few other packages that many would find useful for better coding: devtools, testthat, lintr, codetools, svTools, rbenchmark, pkgutils, etc. This might be some overlap with the HPC task view. I would think that rJava, Rcpp and the like are better suited there but this is arguable. The last time I proposed something like this, Martin deftly convinced me to be the maintainer. It is probably better for everyone if we avoid that on this occasion. * Does anyone else see the need for this? * What other packages fit into this bin? * Would anyone like to volunteer? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reimplement stats:::plotNode as iterative to avoid recursion limits?
Hi All, I've gotten a number of reports from users about gplots::heatmap.2 generating 'node stack overflow' errors. As it turns out, these errors originate in stats:::plotNode, and are triggered when it is passed a dendrogram that is too deeply nested. While increasing the stack size (which is a compile-time option for byte coded functions) can allow a particular instance to succeed, a better solution would be to modify stats:::plotNode to use a recursive, rather than iterative algorithm. Anyone want to take this up as a programming challenge? -Greg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr
And I’ll pick up hexbin. -Greg On Sep 7, 2014, at 12:17 PM, Romain Francois rom...@r-enthusiasts.com wrote: I'll pick up operators. Le 7 sept. 2014 à 18:03, Uwe Ligges lig...@statistik.tu-dortmund.de a écrit : On 05.09.2014 20:25, Greg Snow wrote: Uwe, Have all of these packages found new maintainers? if not, which ones are still looking to be adopted? Thanks for asking, the ones still looking to be adaopted are: SemiPar cghseg monreg operators Best, Uwe Ligges thanks, On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges uwe.lig...@r-project.org wrote: Dear maintainers and R-devel, Several orphaned CRAN packages are about to be archived due to outstanding QC problems, but have CRAN and BioC packages depending on them which would be broken by the archival (and hence need archiving alongside). Therefore we are looking for new maintainers taking over maintainership for one or more of the following packages: R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr Package maintainers whose packages depend on one of these may be natural candidates to become new maintainers. Hence this messages is addressed to all these maintainers via BCC and to R-devel. See http://CRAN.R-project.org/package=R2HTML http://CRAN.R-project.org/package=SemiPar http://CRAN.R-project.org/package=cghseg http://CRAN.R-project.org/package=hexbin http://CRAN.R-project.org/package=lgtdl http://CRAN.R-project.org/package=monreg http://CRAN.R-project.org/package=muhaz http://CRAN.R-project.org/package=operators http://CRAN.R-project.org/package=pamr for information on the QC issues and the reverse dependencies. Best wishes, Uwe Ligges (for the CRAN team) __ 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] Reducing RAM usage using UKSM
Hi Varadharajan, Linux uses a copy-on-write for the memory image of forked processes. Thus, you may also get significant memory savings by launching a single R process, loading your large data object, and then using fork::fork() to split off the other worker process. -Greg Sent from my iPad On Jul 16, 2014, at 5:07 AM, Varadharajan Mukundan srinath...@gmail.com wrote: [Sending it again in plain text mode] Greetings, We've a fairly large dataset (around 60GB) to be loaded and crunched in real time. The kind of data operations that will be performed on this data are simple read only aggregates after filtering the data.table instance based on the parameters that will passed in real time. We need to have more than one instance of such R process running to serve different testing environments (each testing environment has fairly identical dataset but do have a *small amount of changes*). As we all know, data.table loads the entire dataset into memory for processing and hence we are facing a constraint on number of such process that we could run on the machine. On a 128GB RAM machine, we are coming up with ways in which we could reduce the memory footprint so that we can try to spawn more instances and use the resources efficiently. One of the approaches we tried out was memory de-duplication using UKSM (http://kerneldedup.org/en/projects/uksm/introduction), given that we did have few idle cpu cores. Outcome of the experiment was quite impressive, considering that the effort to set it up was quite less and the entire approach considers the application layer as a black box. Quick snapshot of the results: 1 Instance (without UKSM): ~60GB RAM was being used 1 Instance (with UKSM): ~53 GB RAM was being used 2 Instance (without UKSM): ~125GB RAM was being used 2 Instance (with UKSM): ~81 GB RAM was being used We can see that around 44 GB of RAM was saved after UKSM merged similar pages and all this for a compromise of 1 CPU core on a 48 core machine. We did not feel any noticeable degradation of performance because the data is refreshed by a batch job only once (every morning); UKSM gets in at this time and performs the same page merging and for the rest of day, its just read only analysis. The kind of queries we fire on the dataset at most scans 2-3GB of the entire dataset and hence the query subset spike was low as well. We're interested in knowing if this is a plausible solution to this problem? Any other points/solutions that we should be considering? On Tue, Jul 15, 2014 at 9:25 PM, Varadharajan Mukundan srinath...@gmail.com wrote: Greetings, We've a fairly large dataset (around 60GB) to be loaded and crunched in real time. The kind of data operations that will be performed on this data are simple read only aggregates after filtering the data.table instance based on the parameters that will passed in real time. We need to have more than one instance of such R process running to serve different testing environments (each testing environment has fairly identical dataset but do have a *small amount of changes*). As we all know, data.table loads the entire dataset into memory for processing and hence we are facing a constraint on number of such process that we could run on the machine. On a 128GB RAM machine, we are coming up with ways in which we could reduce the memory footprint so that we can try to spawn more instances and use the resources efficiently. One of the approaches we tried out was memory de-duplication using UKSM (http://kerneldedup.org/en/projects/uksm/introduction), given that we did have few idle cpu cores. Outcome of the experiment was quite impressive, considering that the effort to set it up was quite less and the entire approach considers the application layer as a black box. Quick snapshot of the results: 1 Instance (without UKSM): ~60GB RAM was being used 1 Instance (with UKSM): ~53 GB RAM was being used 2 Instance (without UKSM): ~125GB RAM was being used 2 Instance (with UKSM): ~81 GB RAM was being used We can see that around 44 GB of RAM was saved after UKSM merged similar pages and all this for a compromise of 1 CPU core on a 48 core machine. We did not feel any noticeable degradation of performance because the data is refreshed by a batch job only once (every morning); UKSM gets in at this time and performs the same page merging and for the rest of day, its just read only analysis. The kind of queries we fire on the dataset at most scans 2-3GB of the entire dataset and hence the query subset spike was low as well. We're interested in knowing if this is a plausible solution to this problem? Any other points/solutions that we should be considering? -- Thanks, M. Varadharajan Experience is what you get when you didn't get what you wanted -By Prof. Randy Pausch in The Last Lecture My Journal :-
Re: [Rd] Reducing RAM usage using UKSM
On Jul 16, 2014, at 9:51 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On 16/07/2014 14:07, Gregory R. Warnes wrote: Hi Varadharajan, Linux uses a copy-on-write for the memory image of forked processes. But Linux copied it from Unix and I see no mention of Linux in the posting being replied to. The reference was indirect. The UKSM documentation indicates that it is implemented as a patch for the Linux kernel. Thus, you may also get significant memory savings by launching a single R process, loading your large data object, and then using fork::fork() to split off the other worker process. Or using the more refined interface in package 'parallel' (which is portable, unlike package 'fork': see its CRAN check results). Thank you for pointing out the issues with fork, I’ll take a look at what is going on with Solaris. -Greg -Greg Sent from my iPad On Jul 16, 2014, at 5:07 AM, Varadharajan Mukundan srinath...@gmail.com wrote: [Sending it again in plain text mode] Greetings, We've a fairly large dataset (around 60GB) to be loaded and crunched in real time. The kind of data operations that will be performed on this data are simple read only aggregates after filtering the data.table instance based on the parameters that will passed in real time. We need to have more than one instance of such R process running to serve different testing environments (each testing environment has fairly identical dataset but do have a *small amount of changes*). As we all know, data.table loads the entire dataset into memory for processing and hence we are facing a constraint on number of such process that we could run on the machine. On a 128GB RAM machine, we are coming up with ways in which we could reduce the memory footprint so that we can try to spawn more instances and use the resources efficiently. One of the approaches we tried out was memory de-duplication using UKSM (http://kerneldedup.org/en/projects/uksm/introduction), given that we did have few idle cpu cores. Outcome of the experiment was quite impressive, considering that the effort to set it up was quite less and the entire approach considers the application layer as a black box. Quick snapshot of the results: 1 Instance (without UKSM): ~60GB RAM was being used 1 Instance (with UKSM): ~53 GB RAM was being used 2 Instance (without UKSM): ~125GB RAM was being used 2 Instance (with UKSM): ~81 GB RAM was being used We can see that around 44 GB of RAM was saved after UKSM merged similar pages and all this for a compromise of 1 CPU core on a 48 core machine. We did not feel any noticeable degradation of performance because the data is refreshed by a batch job only once (every morning); UKSM gets in at this time and performs the same page merging and for the rest of day, its just read only analysis. The kind of queries we fire on the dataset at most scans 2-3GB of the entire dataset and hence the query subset spike was low as well. We're interested in knowing if this is a plausible solution to this problem? Any other points/solutions that we should be considering? -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] type.convert and doubles
On Apr 26, 2014, at 4:59 PM, Martin Maechler maech...@stat.math.ethz.ch wrote: I think there should be two separate discussions: a) have an option (argument to type.convert and possibly read.table) to enable/disable this behavior. I'm strongly in favor of this. In my (not committed) version of R-devel, I now have str(type.convert(format(1/3, digits=17), exact=TRUE)) Factor w/ 1 level 0.1: 1 str(type.convert(format(1/3, digits=17), exact=FALSE)) num 0.333 where the 'exact' argument name has been ``imported'' from the underlying C code. Looks good to me! snip Instead of only TRUE/FALSE, we could consider NA with semantics FALSE + warning or also TRUE + warning”. b) decide what the default for a) will be. I have no strong opinion, I can see arguments in both directions I think many have seen the good arguments in both directions. I'm still strongly advocating that we value long term stability higher here, and revert to more compatibility with the many years of previous versions. If we'd use a default of 'exact=NA', I'd like it to mean FALSE + warning, but would not oppose much to TRUE + warning. I vote for the default to be “exact=NA” meaning “FALSE + warning -Greg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ASCIIfy() - a proposal for package:tools
Hi Arni, I’ll be glad to drop ASCIIfy into gtools. Let me know if this OK. -Greg On Apr 17, 2014, at 9:46 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: Nobody else has replied to this, so I will. It's very unlikely that we would incorporate this function into base R. For one thing, the tools package is intended to be tools used by R, not by users. R doesn't need this function, so it doesn't belong in tools. (Some other functions in tools like showNonASCII have come to be used by users, but their primary purpose is for R.) Utility functions that are maintained by R Core and are useful to users belong in the utils package. But I wouldn't add ASCIIfy to that package either, because I don't want to impose its maintenance on R Core. Utility functions that are maintained by others belong in contributed packages. So I'd suggest that you add this function to some package that you maintain (perhaps a new one, containing a collection of related utility functions), or search CRAN for an appropriate package with a maintainer who is willing to take this on. Duncan Murdoch On 15/04/2014 1:48 PM, Arni Magnusson wrote: Hi all, I would like to propose the attached function ASCIIfy() to be added to the 'tools' package. Non-ASCII characters in character vectors can be problematic for R packages, but sometimes they cannot be avoided. To make packages portable and build without 'R CMD check' warnings, my solution has been to convert problematic characters in functions and datasets to escaped ASCII, so plot(1,main=São Paulo) becomes plot(1,main=S\u00e3o Paulo). The showNonASCII() function in package:tools is helpful to identify R source files where characters should be converted to ASCII one way or another, but I could not find a function to actually perform the conversion to ASCII. I have written the function ASCIIfy() to convert character vectors to ASCII. I imagine other R package developers might be looking for a similar tool, and it seems to me that package:tools is the first place they would look, where the R Core Team has provided a variety of tools for handling non-ASCII characters in package development. I hope the R Core Team will adopt ASCIIfy() into the 'tools' package, to make life easier for package developers outside the English-speaking world. I have of course no problem with them renaming or rewriting the function in any way. See the attached examples - all in flat ASCII that was prepared using the function itself! The main objective, though, is to ASCIIfy functions and datasets, not help pages. Arni __ 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 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
I have, at times, been a heavy user of R CMD Sweave and would prefer to see it fixed! I encountered this error while preparing notes for a guest lecture last fall, and was too busy to identify the source of the error, so worked around it (thank goodness for version control, making file restores easy) rather than reporting the bug…. -Greg On Apr 15, 2014, at 10:11 AM, Hadley Wickham h.wick...@gmail.com wrote: I use Rscript, and I expect most others do too, but I was wrong about how long this went unreported. Martin Morgan reported it in February in R-devel and I didn't notice. He even gave a link to it in a message in March on another topic; I replied to the March message, but didn't follow the link. We discourage people from using bugs.r-project.org for pre-release issues; perhaps we shouldn't do that. Regardless of the venue, the cost for submitting an issue that doesn't turn out to be a bug is quite high - you're likely to get a nasty message. If you want more people to submit bug reports, I think you have to be prepared to receive reports about things that users think are bugs, but developers do not. If you want to encourage people to submit bugs, then you have to make it a pleasant (or at least not unpleasant) experience. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] type.convert and doubles
Hi All, I see this in the NEWS for R 3.1.0: type.convert() (and hence by default read.table()) returns a character vector or factor when representing a numeric input as a double would lose accuracy. Similarly for complex inputs. This behavior seems likely to surprise users. Would it be possible to issue a warning when this occurs? Aside: Im very happy to see the new s and f browser (debugger) commands! -Greg [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Internet error on Mac OS X 10.9 with 3.1.0 RC
Hi Simon,
sessionInfo()
R version 3.1.0 RC (2014-04-04 r65373)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I just reinstalled, and can’t duplicate the error now. The only difference,
AFAIC, is that this time I left R 3.0.3 installed by running sudo pkgutil
--forget org.r-project.R.x86_64.fw.pkg” first.
-Greg
On Apr 5, 2014, at 7:00 PM, Simon Urbanek simon.urba...@r-project.org wrote:
Greg,
since we have more than one build now, could you, please, include
sessionInfo()?
Thanks
Simon
On Apr 5, 2014, at 1:39 PM, Gregory R. Warnes g...@warnes.net wrote:
OS X 10.9.2
R 3.1.0 RC (2014-04-04 r65373) installer from http://r.research.att.com
Attempting to install packages yields the following:
install.packages( c('gregmisc','RUnit') )
--- Please select a CRAN mirror for use in this session ---
Error in url(http://cran.r-project.org/CRAN_mirrors.csv;) :
internet routines cannot be accessed in module
-Greg
[[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] Internet error on Mac OS X 10.9 with 3.1.0 RC
Hi Simon,
sessionInfo()
R version 3.1.0 RC (2014-04-04 r65373)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I just reinstalled, and can’t duplicate the error now. The only difference,
AFAIC, is that this time I left R 3.0.3 installed by running sudo pkgutil
--forget org.r-project.R.x86_64.fw.pkg” first.
-Greg
On Apr 5, 2014, at 7:00 PM, Simon Urbanek simon.urba...@r-project.org wrote:
Greg,
since we have more than one build now, could you, please, include
sessionInfo()?
Thanks
Simon
On Apr 5, 2014, at 1:39 PM, Gregory R. Warnes g...@warnes.net wrote:
OS X 10.9.2
R 3.1.0 RC (2014-04-04 r65373) installer from http://r.research.att.com
Attempting to install packages yields the following:
install.packages( c('gregmisc','RUnit') )
--- Please select a CRAN mirror for use in this session ---
Error in url(http://cran.r-project.org/CRAN_mirrors.csv;) :
internet routines cannot be accessed in module
-Greg
[[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
[Rd] Internet error on Mac OS X 10.9 with 3.1.0 RC
OS X 10.9.2
R 3.1.0 RC (2014-04-04 r65373) installer from http://r.research.att.com
Attempting to install packages yields the following:
install.packages( c('gregmisc','RUnit') )
--- Please select a CRAN mirror for use in this session ---
Error in url(http://cran.r-project.org/CRAN_mirrors.csv;) :
internet routines cannot be accessed in module
-Greg
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
