MakeTape throws an error when using a user defined alias of a base function

[telenskyt]

I am not sure if this is bug or a feature, in any case, it is a GOTCHA and I think it should be documented, and this way one can easily refer to it.

Since I never remember how to calculate inverse logit function, I have created this alias in my R profile:

inv.logit <- plogis

Then, when I call this function from a function passed to MakeTape, it throws an error:

inv.logit <- plogis

library(RTMB)

ll_pa <- function (par)
{
	p <- inv.logit(par)
	log(p)
}

F <- MakeTape(ll_pa, numeric(1))

Error in inv.logit(par) : Non-numeric argument to mathematical function

I figured that it is because the alias inv.logit <- plogis was created before library(RTMB). If I move the command after library(RTMB), the error disappears.

Before loading library(RTMB), printing plogis looks like this:

> plogis
function (q, location = 0, scale = 1, lower.tail = TRUE, log.p = FALSE) 
.Call(C_plogis, q, location, scale, lower.tail, log.p)
<bytecode: 0x00000187ec56c4f8>
<environment: namespace:stats>

After library(RTMB), the plogis looks like this:

> plogis
standardGeneric for "plogis" defined from package "stats"

function (q, location = 0, scale = 1, lower.tail = TRUE, log.p = FALSE) 
standardGeneric("plogis")
<environment: 0x00000187f4f3dba0>
Methods may be defined for arguments: q, location, scale, lower.tail, log.p
Use  showMethods(plogis)  for currently available ones.

Using RTMB version 1.5 on R 4.4.1.

[telenskyt]

Note: even in case this would not be considered a bug, it would be great to have a better error message. Since this one

Error in inv.logit(par) : Non-numeric argument to mathematical function

is confusing.

[phillipbvetter]

Just to explain why:
The issue is that your alias points to stats::plogis, not to the generic plogis exported by RTMB after loading the library.

library(RTMB)

ll_pa <- function (par)
{
	p <- stats::plogis(par) #error
	# p <- plogis(par) #no error
	log(p)
}

F <- MakeTape(ll_pa, numeric(1))

The error occurs because stats::plogis receives an advector(par) as its first argument rather than a numeric hence the error message. It is only the generic plogis exported by RTMB which has a method to support the advector case:

RTMB/RTMB/R/methods.R

Line 330 in 8e98a14

setMethod("plogis", c("advector", "missing", "missing", "missing", "missing"),

[kaskr]

As @phillipbvetter explains, this is not a bug in RTMB. But I do think something should be done to explain the problem, which goes well beyond the example demonstrated here; I've seen many examples where, by mistake, a base version of a function was used instead of the corresponding RTMB version. e.g. #25 where unexpectedly the base::solve was used instead of RTMB::solve because RTMB had not been loaded... Another common example is when combining RTMB with functions from another unrelated package, e.g. the ODE solve pracma::rk4sys. Because the package namespace is linked to the base namespace, it's impossible to get pracma::rk4sys to use the RTMB methods. Apparently, the only workaround is to copy the source code of the function into your own workspace - very inconvenient!

Regarding the error message, it's triggered by a base R implementation receiving an RTMB advector object. There's no way we can control that behavior, as we can't possibly change all base R functions... FWIW I actually think that, in this case, the message

Error in inv.logit(par) : Non-numeric argument to mathematical function

is reasonably accurate and useful. It tells you which function is the problem, and that an invalid argument type has been passed to it. It can get much worse - see #33 :)

[telenskyt]

Thank you Kasper and Phillip for explanations! This gives some new insight into how RTMB works, and brings up some (burning?) questions:

1. Does this mean that RTMB is basically redefining implementations of all/most basic mathematical functions (like e.g. the plogis), so while I am thinking I am using the internal stats version of the function, I am actually using some different RTMB implementation?

2. Do these modified implementations take place only in the taped functions, or does this change happen globally just after loading RTMB?

3. Can these modified implementations result in a slower code when called inside/outside of the taped functions? (Since they are possibly doing some extra AD job..)

Thanks!