DevNet has no class docstring, and five of its ten constructor parameters are stored but never read. One of them is random_seed, so runs are not reproducible.
Evidence
DevNet.__doc__ is None — the class goes straight from class DevNet(BaseDetector): at line 209 to def __init__ at line 210. It is the only detector in pyod/models/ with no class docstring, so it renders as a bare signature on the API page and help(DevNet) shows nothing.
Of the ten constructor parameters, these five are assigned to self and then never referenced again anywhere in the module:
| Parameter |
Only occurrences |
nb_batch |
signature (214), assignment (226) |
known_outliers |
signature (215), assignment (227) |
cont_rate |
signature (216), assignment (228) |
random_seed |
signature (218), assignment (230) |
data_format |
signature (217), assignment (229) — plus the separate problem below |
data_format is worse than unused. A module-level data_format = 0 exists at line 23, and inside the training path line 190 re-assigns a local data_format = 0 immediately before the branch that reads it:
# Assuming data_format variable should be defined somewhere in the context or as a parameter
data_format = 0 # Assuming it's set correctly according to your use-case
if data_format == 0:
So self.data_format is shadowed by a hardcoded local, and passing data_format=1 has no effect. The two "Assuming ..." comments suggest this was left unfinished.
Why it matters
random_seed is the sharpest one: a user who sets it expects reproducible results and does not get them, with nothing to indicate why. known_outliers and cont_rate are core DevNet concepts from the paper (it is a weakly-supervised method that trains against a small set of labelled anomalies), so a user tuning them and seeing no change has reason to doubt the implementation rather than their own usage.
Suggested resolution
- Wire up
random_seed (seed torch, numpy, and Python random at the start of fit) — this one is worth doing regardless of what happens to the others.
- Either implement
nb_batch, known_outliers, cont_rate, and data_format, or remove them from the signature so the API stops promising behavior that is not there.
- Delete the shadowing local at line 190 and the module-level
data_format at line 23 once the parameter is either honoured or removed.
- Add a class docstring in the numpydoc style used by the other detectors, documenting whatever parameter set survives.
A recent documentation pass deliberately skipped this class rather than writing prose describing parameters that do nothing, since every resolution here changes behavior. Found while auditing constructor signatures against their docstrings.
DevNethas no class docstring, and five of its ten constructor parameters are stored but never read. One of them israndom_seed, so runs are not reproducible.Evidence
DevNet.__doc__isNone— the class goes straight fromclass DevNet(BaseDetector):at line 209 todef __init__at line 210. It is the only detector inpyod/models/with no class docstring, so it renders as a bare signature on the API page andhelp(DevNet)shows nothing.Of the ten constructor parameters, these five are assigned to
selfand then never referenced again anywhere in the module:nb_batchknown_outlierscont_raterandom_seeddata_formatdata_formatis worse than unused. A module-leveldata_format = 0exists at line 23, and inside the training path line 190 re-assigns a localdata_format = 0immediately before the branch that reads it:So
self.data_formatis shadowed by a hardcoded local, and passingdata_format=1has no effect. The two "Assuming ..." comments suggest this was left unfinished.Why it matters
random_seedis the sharpest one: a user who sets it expects reproducible results and does not get them, with nothing to indicate why.known_outliersandcont_rateare core DevNet concepts from the paper (it is a weakly-supervised method that trains against a small set of labelled anomalies), so a user tuning them and seeing no change has reason to doubt the implementation rather than their own usage.Suggested resolution
random_seed(seedtorch,numpy, and Pythonrandomat the start offit) — this one is worth doing regardless of what happens to the others.nb_batch,known_outliers,cont_rate, anddata_format, or remove them from the signature so the API stops promising behavior that is not there.data_formatat line 23 once the parameter is either honoured or removed.A recent documentation pass deliberately skipped this class rather than writing prose describing parameters that do nothing, since every resolution here changes behavior. Found while auditing constructor signatures against their docstrings.