Open nevrome opened 6 months ago
Thanks Clemens for reporting this issue!
Indeed, some functions of nlstools including nlsBoot and nlsJack rely on the use of parent environment in order to accommodate with complex models, e.g. the ones including factors where confusion may occur with the names of the starting values. This was the purpose of the last update of the package.
I understand that it unfortunately impacted on your script which cannot be ran anymore. I will try to figure out how to solve this issue.
Dear nlstools developers - thanks for the work on this great package! @trhermes and I use it for a cool research application.
Unfortunately a seemingly small change in nlstools v2.1-0 breaks the previously reliable curve fitting workflow in one of our scripts here.
Here's a minimal, reproducible example to illustrate the issue:
This now fails in v2.1-0 with
while it works with the old version of the
nlsBoot()
function here: https://github.com/lbbe-software/nlstools/blob/1ca55aa35655c8ea44e53b0fa2112d2497bd50b9/R/nlsBoot.RThe crucial line to trigger the failure in the little example above is
rm(start)
. Of course this line is nonsensical like this. But if you look into the script linked above where we apply nlstools, you'll notice how this very situation can indeed occur.I can hack around the issue and make the new version work by renaming
start
and setting a global variable (<<-
) with the new name, containing the content ofstart
. Pretty hacky and it does not resolve the larger, underlying issue:I believe
nlsBoot()
(and really any function in any R package) should not rely on the parent environment to include certain variables. This can easily backfire, as in this particular case. Even R functions should be as pure as possible. Ifstart
is necessary fornlsBoot()
, then it should just be a clearly documented input argument.