The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
This is a computationally intensive procedure. n_sample = 100
is preferred but for demonstration, n_sample = 10
is used. Expressions are used to delay the execution of commands.
In combi_run_rcurvep
function, functions from furrr package are embedded. Use future::plan()
to control the types of calculation.
# sequential run
seq_run_multi <- expression(
# set up the plan
future::plan(sequential),
# calculation
combi_run_rcurvep(
zfishdev_all,
n_sample = 10,
TRSH = seq(5, 95, by = 5),
RNGE = 1000000,
keep_sets = "act_set",
seed = 300
)
)
# parallel run
par_run_multi <- expression(
# set up the plan
future::plan(multisession, workers = 10),
# calculation
combi_run_rcurvep(
zfishdev_all,
n_sample = 10,
TRSH = seq(5, 95, by = 5),
RNGE = 1000000,
keep_sets = "act_set",
seed = 300
),
# re-set the plan back
future::plan(sequential)
)
Due to the long time, the results are pasted below. Parallel calculation is faster.
inp_tb <- bmrd |>
nest_join(
zfishdev_all, by = c("endpoint"), keep = TRUE, name = "data"
) |>
select(RNGE, endpoint, bmr_exp, data)
# input_data for combi_run_rcurvep
rmarkdown::paged_table(inp_tb)
n_sample = 1000
is preferred but for demonstration, n_sample = 100
is used.
For sequential run, purrr::pmap
is used. For parallel run, furrr::future_pmap
is used
# sequential run
seq_run_bmr <- expression(
future::plan(sequential),
pmap(inp_tb, ~ combi_run_rcurvep(..4, TRSH = ..3, RNGE = ..1, n_samples = 100, seed = 300, keep_sets = c("act_set")))
)
# parallel run
par_run_bmr <- expression(
future::plan(multisession, workers = 10),
# calculation
# there is no need to use future_pmap here
pmap(inp_tb, ~ combi_run_rcurvep(..4, TRSH = ..3, RNGE = ..1, n_samples = 100, seed = 300, keep_sets = c("act_set"))),
future::plan(sequential)
)
Due to the long time, the results are pasted below. Parallel calculation is faster.
In run_fit
function, functions from furrr package are embedded. Use future::plan()
to control the types of calculation.
n_sample = 1000
is preferred but for demonstration, n_sample = 100
is used. Also, create_dataset
function is used to convert the incidence data into response data.
# sequential run
seq_fit_hill_boot <- expression(
future::plan(sequential),
run_fit(create_dataset(zfishdev), hill_pdir = 1, n_samples = 100, modls = "hill")
)
# parallel run
seq_fit_hill_boot <- expression(
future::plan(multisession, workers = 10),
# calculation
run_fit(create_dataset(zfishdev), hill_pdir = 1, n_samples = 100, modls = "hill"),
future::plan(sequential)
)
Due to the long time, the results are pasted below. Parallel calculation is faster.
We can also use similar syntax as combi_run_rcurvep
to run multiple datasets.
# make the incidence data as response data
inp_tb_resp <- inp_tb |> mutate(data = map(data, create_dataset))
# sequential run
seq_fit_hill_multi <- expression(
future::plan(sequential),
pmap(inp_tb_resp, ~ run_fit(..4, modls = "hill", hill_pdir = ifelse(..3 < 0, -1, 1), n_samples = 100, keep_sets = c("fit_set")), .options = furrr_options(seed = 2023))
)
# parallel run
para_fit_hill_multi <- expression(
future::plan(multisession, workers = 10),
# calculation, no need to use future_pmap
pmap(inp_tb_resp, ~ run_fit(..4, modls = "hill", hill_pdir = ifelse(..3 < 0, -1, 1), n_samples = 100, keep_sets = c("fit_set")), .options = furrr_options(seed = 2023)),
future::plan(sequential)
)
Due to the long time, the results are pasted below. Parallel calculation is faster.
In run_fit
function, functions from furrr package are embedded. Use future::plan()
to control the types of calculation.
Two parameters are tested: hill and cc2. hill is 3-parameter Hill equation implemented using R. cc2 is 4-parameter Hill equation implemented using Java.
The dataset - respd_1 - includes 3000 curves, is not available in the package. If the dataset is too small, it might not worthwhile to start the parallel computing.
Due to the long time, the results are pasted below. Parallel calculation is faster.
run_speed_hit_hill_ori <- microbenchmark(
eval(seq_fit_hill_ori),
eval(par_fit_hill_ori),
times = 5
)
Due to the long time, the results are pasted below. Parallel calculation does not improve much. It could be because the cc2 is implemented using Java.
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.