R help - Jul 2022 - Error generated by nlme::gnls

On Sun, 24 Jul 2022 07:58:01 +0300
Ivan Krylov <krylov.r00t at gmail.com> wrote:
> On Sun, 24 Jul 2022 16:03:24 +1200
> Rolf Turner <r.turner at auckland.ac.nz> wrote:
> 
> > My impression is that if the right hand side of a formula gets
"too
> > long", then it gets split into parts --- which messes everything
up.
> 
> For new enough R (? 4.0), it's possible to use deparse1() [*], which
> guarantees to return a single string. Otherwise, the simplest
> workaround would be paste(deparse(...), collapse = ' '), which is
> similar to how deparse1 is defined.
> 
Yes but .....

I guess my posting did not make things clear.  Sorry 'bout that! My
posting, and Ben Tupper's posting, were in response to an earlier
posting by Aaron Crowley which dealt with an error that now results
from a call to gnls(). Apparently the exact same call had worked
without error in the past.

The call to deparse(), which triggers the error, is in the code
of gnls().  (Line 223 of gnls.R.)

The maintainer of the nlme package (who is, according to maintainer(),
"R-core") could change the code so that it uses invokes deparse1()
rather than deparse, but the user cannot do so, not without in effect
re-creating the package.

Also, the question remains:  why did Aaron Crowley's code work in the
past, whereas now it throws an error?  What changed?

cheers,

Rolf Turner

P.S. Aaron Crowley tells us that he is currently running R 4.2.1.
However he did not tell us what version of R he was running at the time
("approximately six months ago") when the call to gnls() executed
successfully.  Perhaps that version was older than 4.0.  Even so, it's
all a bit mysterious.

R. T.

-- 
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

Sorry for being too terse in my previous e-mail!

On Sun, 24 Jul 2022 23:03:02 +1200
Rolf Turner <r.turner at auckland.ac.nz> wrote:
> The maintainer of the nlme package (who is, according to maintainer(),
> "R-core") could change the code so that it uses invokes
deparse1()
> rather than deparse, but the user cannot do so, not without in effect
> re-creating the package.
You're right. I think there's a buglet in nlme::gnls that nobody
noticed until R 4.2.0 was released *and* Aaron Crowley used the
function with a sufficiently long formula.
> Also, the question remains:  why did Aaron Crowley's code work in the
> past, whereas now it throws an error?  What changed?
gnls() may have been performing the `if (deparse(...) != '1')` test for
a long time, but never crashed before because it wasn't a fatal error
until R 4.2.0. Previously, if() would issue a warning and use the first
element of the boolean vector.

R 4.2.0 was released this April, which was less than 6 months ago. I
think it all fits.

A temporary solution would be to make use of the fact that R is a very
dynamic language and perform surgery on a live function inside a loaded
package:

library(codetools)

nlme <- loadNamespace('nlme')
unlockBinding('gnls', nlme)
nlme$gnls <- `body<-`(fun = nlme$gnls, value = walkCode(
	body(nlme$gnls), makeCodeWalker(
		call = function(e, w)
			as.call(lapply(as.list(e), function(ee)
				if (!missing(ee)) walkCode(ee, w)
			)),
		leaf = function(e, w)
			if (is.symbol(e) && e == 'deparse') {
				as.name('deparse1')
			} else e
	)
))
lockBinding('gnls', nlme)
rm(nlme)

grep('deparse', deparse(nlme::gnls), value = TRUE)
# [1] "                deparse1(pp[[3]]), sep = \"~\"), collapse
\",\"), " # [2] "        if (deparse1(params[[nm]][[3]]) !=
\"1\") {"
# [3] "        list(row.names(dataModShrunk), deparse1(form[[2]]))), "

Aaron's example seems to work after this, modulo needing 12 starting
values instead of 13.

-- 
Best regards,
Ivan