similar to: formulas and frames

Just built 3.6.3 from source and tcl doesn't work. Worked fine with the same laptop in 3.6.2. Here's the exact error. blurfle$ R --vanilla R version 3.6.3 (2020-02-29) -- "Holding the Windsock" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to

OK. I give up. I'll ask a stupid question. How do I get the $!#@*$ signif stars line printed by summaries to not look extremely bizarre in the latex produced by Sweave? For example, see p. 7 of http://www.stat.umn.edu/geyer/aster/library/aster/doc/tutor.pdf I can see what the problem is. R emits non-ascii characters (as it is supposed to do), Sweave puts them in the tex file, and

>>>>> Charles Geyer writes: > In that case, perhaps the question could be changed to could CC0 be > added to the list of R licences. Right now the only CC licence that > is in the R licenses is CC-BY-SA-4.0. Hmm, I see Name: CC0 FSF: free_and_GPLv3_compatible (https://www.gnu.org/licenses/license-list.html#CC0) OSI: NA (https://opensource.org/faq#cc-zero) URL:

is it possible to set an option inside a function ((I want to set na.action = na.fail) and have the previous state restored if there is an error so that the function doesn't change the option behind the user's back? Sorry if this has been answered before, but this subject is hard to Google. -- Charles Geyer Professor, School of Statistics University of Minnesota charlie at stat.umn.edu

I would like the unlicense (http://unlicense.org/) added to R licenses. Does anyone else think that worthwhile? -- Charles Geyer Professor, School of Statistics Resident Fellow, Minnesota Center for Philosophy of Science University of Minnesota charlie at stat.umn.edu

On Tue, 2017-01-17 at 22:46 -0500, Kevin Ushey wrote: > It appears that Unlicense is considered a free and GPL-compatible > license; however, the page does suggest using CC0 instead (which is > indeed a license approved / recognized by CRAN). CC0 appears to be > the primary license recommended by the FSF for software intended for > the public domain. I'd second the

I knew I could work around. But this shouldn't happen. And yes. Same problem with your example. blurfle$ R --vanilla R version 3.6.3 (2020-02-29) -- "Holding the Windsock" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain

I think I am using objects according to the man page. This seems to be a valid regular expression. But whether I know what I'm doing or no, it still shouldn't be doing what valgrind seems to be saying it's doing. (IMHO) ---------- start of script ---------- Script started on Mon 01 Aug 2005 02:09:00 PM PDT linux$ printenv VALGRIND_OPTS --tool=3Dmemcheck linux$ cat bar.R foo <- 1

The subject line says it all. How can I find what Error: cannot set length of non-vector means? RTFS is no help. I can find out of course that it comes from "lengthgets", but who called that? Not me! The situation is as follows. I am trying to get a package ready for CRAN. Every time I run "R CMD check" I get this error when building the package vignette. But (!)

Sorry if I was supposed to file a bug report, but I don't know whether we're supposed to do that on R devel. I just built R devel from source (2010-06-15 r52280) and tried to check a package with it and Sweave failed on the vignette. It puts the line \usepackage{/HOME/faculty/charlie/local/devel/lib64/R/share/texmf/Sweave} in the *.tex file but, that's not where Sweave.sty is oak$

No. I didn't do any of that and am now at a hockey game. But since I can't reproduce the problem after an Ubuntu online update and reboot, I assume the issue is moot. But I will check these things in an hour or so. On Sat, Feb 29, 2020, 3:24 PM Dirk Eddelbuettel <edd at debian.org> wrote: > > Charles, > > Did you try a build of the provided alpha, beta and rc releases

R CMD check --use-valgrind <packagename> used to run valgrind on the tests in the tests directory of the package. But it seems to have stopped. R-2.9.1 doesn't -- at least on my box -- and neither does R-2.10.0 (devel). I am not sure when this stopped. I think 2.8.x did this. The only old R I have around is 2.6.0 and it certainly does. R CMD check --help for 2.9.1 says (among other

The functions metrop and temper in the mcmc package have a debug = FALSE argument that when TRUE adds a lot of debugging information to the returned list. This is absolutely necessary to test the functions, because one generally knows nothing about the simulated distribution except what what one learns from MCMC samples. Hence you must expose all details of the simulation to have any hope of

Full_Name: Charles J. Geyer Version: 1.8.0 OS: i686-pc-linux-gnu (Suse 8.2) Submission from: (NULL) (134.84.86.22) Two bugs (perhaps related, perhaps independent) revealed by the same Poisson regression with offset mydata <- read.table(url("http://www.stat.umn.edu/geyer/5931/mle/seeds.txt")) out.fubar <- glm(seedlings ~ burn01 + vegtype * burn02 + offset(log(totalseeds)),

The note to 1004 says "fixed for 1.3.1" Uh. No. It ain't. The problem was more serious than guessed as even the simplest testing would show. For example, Example 5.4 in Hollander and Wolfe (Nonparametric Statistical, Methods, 2nd ed., Wiley, 1999, pp. 180-181) R Version 1.3.1 (SuSE Linux 7.1) > X <-

Can anyone tell me if the following C code (which proved very useful when using the snow package -- use it to nice slaves) compiles and dyn.loads under Windoze or Mac? It is (apparently) POSIX, so I suppose it is fine in OS X, but does Windoze's advertized POSIX compliance mean anything here? If it doesn't work on some platform, how do I deal with that? I want to submit as contributed

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

The point estimates produced by wilcox.test are perverse (not wrong, just brain damaged). The Hodges-Lehmann estimator that goes with the signed rank test is the median of the Walsh averages. The Hodges-Lehmann estimator that goes with the rank sum test is the median of the pairwise differences. wilcox.test agrees except that it uses the following very peculiar definition of "sample

I have hit a problem with the design of the mcmc package I can't figure out, possibly because I don't really understand the R function call mechanism. The function metrop in the mcmc package has a ... argument that it passes to one or two user-supplied functions, which are other arguments to metrop. When the two functions don't have the same arguments, this doesn't work.