library("rplatypus")
available_losses()
#> name arguments
#> 1 boundary region, alpha
#> 2 cce label_smoothing
#> 3 cce_dice cce_weight, smooth
#> ...
# Which metrics take an argument at all, and which do not.
available_metrics()[, c("name", "arguments")]
# The entry point, for somebody who has read nothing yet.
available_tasks()
# The two instance axes: what a model can predict, and how those channels become objects.
available_separations()[, c("name", "head_channels")]
available_decodings()[, c("name", "needs")]
# Detection says what it has instead of a loss to choose.
try(available_losses("object_detection"))What this package can do, asked of the package
Description
Six listings beside available_transforms() and available_weights(): the losses, the metrics, the architectures, the optimisers, the callbacks and the tasks. Three columns - the name you write in a specification, the arguments you may tune, and what it is for.
Usage
available_losses(task = "semantic_segmentation")
available_metrics(task = "semantic_segmentation")
available_models(task = "semantic_segmentation")
available_optimizers()
available_callbacks()
available_tasks()
available_separations()
available_decodings()
Arguments
task
|
“semantic_segmentation”, “instance_segmentation” or “object_detection”. Which components a specification may name depends on what it is asking for, and for losses it genuinely differs: the three regression losses are listed only at the instance task, which is the only one with a target for them. No count is written here on purpose - the counts are asserted in the test suite against the pinned engine, which is where a number nobody can re-measure from a help page belongs. This parameter listed two tasks until the pin moved to 0.8.0a22; the third arrived in the engine’s 0.8.0a20.
|
Details
Worth having because the alternative is leaving R for a website. The number of named components grows with every release, and these are read from the engine’s own schema, so a loss added there appears here with nothing in this package edited. Nothing is maintained by hand; a list maintained by hand is a list that will be wrong.
description is the component’s summary line. The rest of what the engine knows about it - including the measurements, where there are any - is on the configuration reference of the engine’s own site, which is generated from the same text.
Value
A data frame with name, arguments and description. arguments is a single string per row, comma-separated, because a column of vectors prints as something nobody can read; strsplit(x, “,”) takes it apart.
Two listings carry one column more, and it is the column they are asked for: available_decodings() has needs, the separation a decoding requires - empty where it requires none, which is connected_components and is why that one is always available - and available_separations() has head_channels, how wide a head that target makes. Taken from the engine’s own rows rather than named on this side, so a listing that grows a field arrives here without R changing.
Detection chooses fewer things, and says so
A detection specification chooses no loss component and no metrics at all. Its objective is fixed, with box_loss on the model picking the box term, and every detection run reports the same set - map_50, map_50_95, mean_matched_iou - which comes out of the run rather than going into the specification.
So available_losses(“object_detection”) and available_metrics(“object_detection”) raise a condition whose message says that, rather than returning a table with no rows. An empty table reads as "there are none", which is a different and wrong answer.
See Also
available_transforms() and available_weights(), the two that came first, separations and decodings for the constructors these two listings name, and platypus_spec(), where all of them are written.