Repository navigation
chore: clean-up - #15680
Merged
Merged
chore: clean-up#15680
Conversation
The JSDoc note in `lib/enum.js` cited `HINGE == 0`, but the enumeration maps `epsilon-insensitive` to `0` and `hinge` to `1`, as does `STDLIB_ML_SGD_EPSILON_INSENSITIVE = 0` in the C header. Corrected the example to `EPSILON_INSENSITIVE == 0`, matching the member mapped to 0 (8/9 sibling packages carrying this note, 89%). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T5eqmcfD2xBYKR3EwFfPx1
…m` benchmarks Added `none` to the string and integer value lists in `benchmark/benchmark.js`, so the benchmarks cover every supported penalty, as the `penalty-enum2str` and `penalty-str2enum` benchmarks do (10/12 sibling benchmarks enumerate the full value set, 83%). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T5eqmcfD2xBYKR3EwFfPx1
…` benchmarks Added `none` to the string and integer value lists in `benchmark/benchmark.js`, so the benchmarks cover every supported penalty, as the `penalty-enum2str` and `penalty-str2enum` benchmarks do (10/12 sibling benchmarks enumerate the full value set, 83%). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T5eqmcfD2xBYKR3EwFfPx1
Contributor
Coverage Report
The above coverage report was generated for the changes in this PR. |
kgryte
marked this pull request as ready for review
September 30, 2026 09:24
kgryte
approved these changes
Sep 30, 2026
ml/base/sgd/loss-functions and add missing none penalty to benchmarks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This pull request:
ml/base/sgd/loss-functionsand completes the penalty value lists in twoml/base/sgd/penalty-resolve-*benchmarks, bringing both in line with their siblings.@stdlib/ml/base/sgd/loss-functionsThe
lib/enum.jsJSDoc note citedHINGE == 0, but the enumeration mapsepsilon-insensitiveto0(hingeis1), as doesSTDLIB_ML_SGD_EPSILON_INSENSITIVE = 0inloss_functions.h. The example now readsEPSILON_INSENSITIVE == 0, matching the member actually mapped to zero in 8/9 (89%) sibling packages carrying the note.@stdlib/ml/base/sgd/penalty-resolve-enumThe string and integer value lists in
benchmark/benchmark.jsomittednone. Addsnoneso the benchmarks cover every supported penalty, as 10/12 (83%) sibling benchmarks enumerating a value set do, includingpenalty-enum2strandpenalty-str2enum.@stdlib/ml/base/sgd/penalty-resolve-strSame omission and same fix as
penalty-resolve-enum:noneadded to both value lists inbenchmark/benchmark.js(10/12 siblings, 83%).Related Issues
No.
Questions
The
test/test.jsvalue lists inpenalty-resolve-enumandpenalty-resolve-stralso omitnone. Test updates were out of scope for this change; they are a candidate for a follow-up.Other
Namespace summary.
ml/base/sgd: 15 packages, none autogenerated. Features analyzed: file tree,package.jsonkey sets (top-level,scripts,directories), README section headings,manifest.jsonkeys, test/benchmark/example file names, public signature, return kind, validation prologue, error construction, JSDoc shape, and source dependencies. Every structural and semantic feature had a clear majority (≥75%, 12/15). The only structural deviations are inlearning-rates,loss-functions, andpenalties, which alone carryinclude/,lib/data.json,lib/enum.js,manifest.json, and a "C APIs" README section. They are the enumeration/C-header packages, so these files are intentional and were left alone. README## Notes(6/15) has no clear majority and was excluded.Validation. Structural features were extracted from the filesystem. Semantic features were extracted from
lib/main.jsandlib/index.jsby normalizing across the three families (learning rate, loss function, penalty). Each candidate went through three separate reviews (semantic intent, cross-referencing tests and docs, and structural applicability), and all three confirmed drift for both candidates. Deliberately excluded: intentional deviations (enum-table packages), test changes, and features without a clear majority. No public behavior changes: one edit is to a JSDoc comment, the rest are to benchmark inputs. I checked thatresolve( 'none' )andresolve( str2enum( 'none' ) )return values that pass each benchmark's existing type assertions.Checklist
AI Assistance
If you answered "yes" above, how did you use AI assistance?
Disclosure
This PR was written primarily by Claude Code, as part of an automated check for drift between packages in the same namespace, using a majority vote across sibling packages.
@stdlib-js/reviewers
🤖 Generated with Claude Code
https://claude.ai/code/session_01T5eqmcfD2xBYKR3EwFfPx1
Generated by Claude Code