[Rd] bug in nlme::getVarCov
Greetings, I noticed a bug in the getVarCov function from nlme. I am posting here because it is not currently possible to register and file a report through https://bugs.r-project.org/. (If this is not the appropriate venue for this, I'd be grateful if someone could point me to the right place.) The issue can be seen by observing that getVarCov is sensitive to the order in which the data are sorted, as demonstrated in the following: library(nlme) data(Ovary) gls_raw <- gls(follicles ~ sin(2*pi*Time) + cos(2*pi*Time), data = Ovary, correlation = corAR1(form = ~ 1 | Mare), weights = varPower()) Mares <- levels(gls_raw$groups) V_raw <- lapply(Mares, function(g) getVarCov(gls_raw, individual = g)) Ovary_sorted <- Ovary[with(Ovary, order(Mare, Time)),] gls_sorted <- update(gls_raw, data = Ovary_sorted) V_sorted <- lapply(Mares, function(g) getVarCov(gls_sorted, individual = g)) all.equal(gls_raw$modelStruct, gls_sorted$modelStruct) all.equal(V_raw, V_sorted) See here for more details and a simple patch: http://jepusto.github.io//Bug-in-nlme-getVarCov Or here for just the R code: https://gist.github.com/jepusto/5477dbe3efa992a3d42c2073ccb12ce4 James [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] table(exclude = NULL) always includes NA
I stand corrected. The part "If set to 'NULL', it implies 'useNA="always"'." is
even in the documentation in R 2.8.0. It was my fault not to check carefully.
I wonder, why "always" was chosen for 'useNA' for exclude = NULL.
Why exclude = NULL is so special? What about another 'exclude' of length zero,
like character(0) (not c(), because c() is NULL)? I thought that, too. But
then, I have no opinion about making it general.
It fits my expectation to override 'useNA' only if the user doesn't explicitly
specify 'useNA'.
Thank you for looking into this.
My points:
Could R 2.7.2 behavior of table(, exclude = NULL) be brought back?
But R 3.3.1 behavior is in R since version 2.8.0, rather long.
If not, I suggest changing summary().
On Thu, 11/8/16, Martin Maechler wrote:
Subject: Re: [Rd] table(exclude = NULL) always includes NA
@r-project.org
Cc: "Martin Maechler"
Date: Thursday, 11 August, 2016, 12:39 AM
> Martin Maechler
> on Tue, 9 Aug 2016 15:35:41 +0200 writes:
> Suharto Anggono Suharto Anggono via R-devel
> on Sun, 7 Aug 2016 15:32:19 + writes:
> > This is an example from
> > https://stat.ethz.ch/pipermail/r-help/2007-May/132573.html .
>
> > With R 2.7.2:
>
> > > a <- c(1, 1, 2, 2, NA, 3); b <- c(2, 1, 1, 1, 1, 1)
> > > table(a, b, exclude = NULL)
> > b
> > a 1 2
> > 11 1
> > 22 0
> > 31 0
> >1 0
>
> > With R 3.3.1:
>
> > > a <- c(1, 1, 2, 2, NA, 3); b <- c(2, 1, 1, 1, 1, 1)
> > > table(a, b, exclude = NULL)
> > b
> > a 1 2
> > 11 10
> > 22 00
> > 31 00
> >1 00
> > > table(a, b, useNA = "ifany")
> > b
> > a 1 2
> > 11 1
> > 22 0
> > 31 0
> >1 0
> > > table(a, b, exclude = NULL, useNA = "ifany")
> > b
> > a 1 2
> > 11 10
> > 22 00
> > 31 00
> >1 00
>
> > For the example, in R 3.3.1, the result of 'table' with
> > exclude = NULL includes NA even if NA is not present. It is
> > different from R 2.7.2, that comes from factor(exclude = NULL),
> > that includes NA only if NA is present.
>
> I agree that this (R 3.3.1 behavior) seems undesirable and looks
> wrong, and the old (<= 2.2.7) behavior for table(a,b,
> exclude=NULL) seems desirable to me.
>
>
> > >From R 3.3.1 help on 'table', in "Details" section:
> > 'useNA' controls if the table includes counts of 'NA' values: the allowed
> > values correspond to never, only if the count is positive and even for zero
> > counts. This is overridden by specifying 'exclude = NULL'.
>
> > Specifying 'exclude = NULL' overrides 'useNA' to what value? The
> > documentation doesn't say. Looking at the code of function 'table', the
> > value is "always".
>
> Yes, it should be documented what happens for this case,
> (but read on ...)
and it is *not* true that the documentation does not say, since
2013, it has contained
exclude: levels to remove for all factors in ‘...’. If set to ‘NULL’,
it implies ‘useNA = "always"’. See ‘Details’ for its
interpretation for non-factor arguments.
> > For the example, in R 3.3.1, the result like in R 2.7.2 can be obtained
> > with useNA = "ifany" and 'exclude' unspecified.
>
> Yes. What should we do?
> I currently think that we'd want to change the line
>
> useNA <- if (!missing(exclude) && is.null(exclude)) "always"
>
> to
>
> useNA <- if (!missing(exclude) && is.null(exclude)) "ifany" # was
> "always"
>
>
> which would not even contradict documentation, as indeed you
> mentioned above, the exact action here had not been documented.
The last part ("which ..") above is wrong, as mentioned earlier.
The above change entails behaviour which looks better to me;
however, the change *is* "against the current documentation".
and after experimentation (a "complete factorial design" of
argument settings), I'm not entirely happy with the result and one reason
is that 'exclude = NULL' and (e.g.) 'exclude = c()'
are (still) handled differently: From a usual interpreation,
both should mean
"do not exclude any factor entries (and levels) from tabulation"
but one of the two changes the default of 'useNA' and the other
does not. If we want a change anyway (and have to update the doc),
it could be "more logical" to replace the line above by
useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in% exclude))
"always"
notably, replacing 'useNA' *only* if it has not been specified,
which seems much closer to "typically expected" behavior..
> The change above at least does not break any of the standard R
> tests ('make check-all', i.e., including the recommended
> packages), which for me confirms that it may be "what is
> best"...
>
>
>
> Thank you for mentioning the important consequence for summary().
> They can helping insight what a "probably best" behavior should
> be for these cases of table().
>
> Ma
[Rd] Suppress LaTeX log during R CMD build
Hi,
When a package's documentation contains \Sexpr{}, R CMD build will
build the manual to PDF. I wonder if the full LaTeX log could be
suppressed in this case. Currently it looks like this:
$ R CMD build foo
* checking for file ‘foo/DESCRIPTION’ ... OK
* preparing ‘foo’:
* checking DESCRIPTION meta-information ... OK
* installing the package to process help pages
* building the PDF package manual
Hmm ... looks like a package
Converting Rd files to LaTeX ..
Creating pdf output from LaTeX ...
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(/private/var/folders/8r/zh8x49md6vsgskh23jrmy7p8gn/T/RtmpWxPLW3/Rbuild52f3
1a8c19c2/foo/.Rd2pdf21235/Rd2.tex
LaTeX2e <2016/03/31>
Babel <3.9r> and hyphenation patterns for 22 language(s) loaded.
(/usr/local/texlive/2016basic/texmf-dist/tex/latex/base/book.cls
Document Class: book 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2016basic/texmf-dist/tex/latex/base/bk10.clo))
(/Library/Frameworks/R.framework/Resources/share/texmf/tex/latex/Rd.sty
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quote symbol names under EXPORTS in tmp.def on Windows
Attaching a proper patch for this issue. I will post a bug report
whenever new registrations are allowed.
Best Regards,
Kyle
On Sat, Aug 6, 2016 at 11:51 PM, Kyle Baron wrote:
>
> I originally posted on this topic on a different thread:
> https://stat.ethz.ch/pipermail/r-devel/2016-August/072938.html
>
> These sources suggested that a safe practice might be to put double
> quotes around symbol names in EXPORTS in case the symbol name is the
> same as a linker keyword:
>- https://sourceware.org/binutils/docs/ld/Symbols.html#Symbols
>- https://msdn.microsoft.com/en-us/library/163abkbh.aspx
>
> I wasn't sure how that related specifically to what Rtools is using,
> but when I made the following change to winshlib.mk (double quotes
> around symbol names in tmp.def), I was able to compile code without
> issue and get symbols like BASE (or other keywords) exported.
>
>
> Kyle
>
>
>
>
> ## ${R_HOME}/share/make/winshlib.mk
> 6a7,8
> > ADDQU = 's/[^ ][^ ]*/"&"/g'
> >
> 17c19
> < $(NM) $^ | $(SED) -n $(SYMPAT) $(NM_FILTER) >> tmp.def; \
> ---
> > $(NM) $^ | $(SED) -n $(SYMPAT) $(NM_FILTER) | $(SED) $(ADDQU) >>
> > tmp.def; \
>
>
>
> code <- '
>
> void BASE(int *nin, double *x) {
>int n = nin[0];
>for (int i=0; i }
>
> void rd(int *nin, double *x) {
>int n = nin[0];
>for (int i=0; i }
>
> double EXPORTS = 2.1;
> int LIBRARY = 3;
> '
>
> writeLines(code, "src1.c")
>
> system("R CMD SHLIB src1.c")
> dyn.load("src1.dll")
>
> is.loaded("EXPORTS",PACKAGE="src1")
> is.loaded("BASE",PACKAGE="src1")
> is.loaded("rd",PACKAGE="src1")
>
> dyn.unload("src1.dll")
>
>
>
> --
> Kyle Baron
> Metrum Research Group
--
Kyle Baron
Metrum Research Group
ky...@metrumrg.com
Index: winshlib.mk
===
--- winshlib.mk (revision 71059)
+++ winshlib.mk (working copy)
@@ -4,6 +4,8 @@
BASE = $(shell basename $(SHLIB) .dll)
+ADDQU = 's/[^ ][^ ]*/"&"/g'
+
## do it with explicit rules as packages might add dependencies to this target
## (attempts to do this GNUishly failed for parallel makes,
## but we do want the link targets echoed)
@@ -14,7 +16,7 @@
$(SHLIB_LD) -shared $(DLLFLAGS) -o $@ $(BASE)-win.def $(OBJECTS)
$(ALL_LIBS); \
else \
echo EXPORTS > tmp.def; \
- $(NM) $^ | $(SED) -n $(SYMPAT) $(NM_FILTER) >> tmp.def; \
+ $(NM) $^ | $(SED) -n $(SYMPAT) $(NM_FILTER) | $(SED) $(ADDQU) >>
tmp.def; \
echo $(SHLIB_LD) -shared $(DLLFLAGS) -o $@ tmp.def $(OBJECTS)
$(ALL_LIBS); \
$(SHLIB_LD) -shared $(DLLFLAGS) -o $@ tmp.def $(OBJECTS)
$(ALL_LIBS); \
$(RM) tmp.def; \
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
