Replies: 3 comments 1 reply
-
Thanks for reporting. There has been reports on future 1.40.0 introducing regression bugs, where some users have reported on Futureverse failing to pick up some variable, whereas it worked in future 1.34.0 (#778). If this is affecting you too, then:
https://cran.r-project.org/src/contrib/Archive/future/future_1.34.0.tar.gz If it works with future 1.34.0, then it's likely that this is the same bug. If so, then continue trying with:
remotes::install_github("futureverse/globals", ref = "develop")
remotes::install_github("futureverse/future", ref = "develop") If that works, then "awesome!", because then I know the bug has been fixed. If the above does not do the trick, please try to minimize your reproducible example under "Reproduce example", so I don't have to spend time doing it. For example, I doubt the progressr code makes a difference, so you should be able to remove all that code. There's also lots of meaty pieces of code that I think could start peeling off one by one, while making sure the bug is still there. Eventually, you should end up with a minimal reproducible example that I can work with, e.g. check if it is a mistake in the code, or a bug in the futureverse code. |
Beta Was this translation helpful? Give feedback.
-
Thank you for that! Unfortunately both things above that didn't work. So it's not the same issue. hrm. I did want to apologise for the massive code example – I had typed this up at 3am and was trying to get something viable out. Now that I'm decently awake, I'm working on a minimal reproducible example for ya :) thank you for your massively timely response, I'm very impressed with that, and the help you've already offered! Minimal Reproducible Example
It appears that the issue is present with the multisession plan. Unsure how to test multicore with a qmd file. It appears to me that qmds do not support multicore. note: trying the alternative
with And as a final double-check,
does in fact allow the function to generate results properly. |
Beta Was this translation helpful? Give feedback.
-
You have the objective function: obj_pen <- function(pars)
{
res_model <- af_net(train_X,train_Y,pars,m,nu)
return(res_model$E2)
} that you minimize via: res_opt <- nlm(obj_pen,theta_rand,iterlim=max_iter) If you read In other words, the best-practices way is to pass all variables that Then reason your current code complaints about In the end of the day, do you want to fit: res_model <- af_net(train_X,train_Y,pars,m,nu) using the global, constant |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
in my code below: I am experiencing a strange "object 'nu' not found" coming from the traceback soon after the foreach function is run. The thing is, nu is defined within that foreach which is going directly into the %dofuture%!
Judging by the fact that I simply merged the structure of supplied code from both progressr and dofuture to fit my needs, I am really shocked that this didn't work, and that I'm unable to figure out precisely why.
This file is found on my partner's GitHub repository under Ass2.qmd. This should make this easier to see how the error actually came up.
I've now spent a couple of hours debugging this without coming to any reasonable conclusions about how the nu value is not available to the dofuture section
The line of code in question begins "Val_error<-" within the "with_progress" block
This is a chunk within a qmd file.
Reproduce example
If I paste in the other user defined sections that will get this to run, I get this:
Expected behavior
The nu value should be one of the most accessible values to the parallelised function, so this error really does feel shocking.
Session information
Beta Was this translation helpful? Give feedback.
All reactions