feat(operator): give a trainer's hyperparameter value the constraint its parameter implies

[kz930]

What changes were proposed in this PR?

The four advanced Sklearn trainers (SVC, SVR, KNN Classifier, KNN Regressor) take their hyperparameters as a table: each row picks a parameter from a dropdown and types a value beside it. The value box carried no constraint at all, so 1 for kernel, or an empty box, was accepted by the editor and only failed once the run reached scikit-learn.

The enum behind the parameter dropdown already pairs every parameter with the callable that converts the user's text. It now also carries what that parameter accepts, read out of scikit-learn rather than written from judgement: the accepted words where scikit-learn fixes a set, and one example value plus the low end of the range where it does not. The descriptor writes those rules into its own schema through a new JsonSchemaCustomizer hook on the metadata generator, and a new constrainedvalue Formly control renders what they call for: a dropdown for a fixed set, a number input for a numeric parameter, a plain text box otherwise. The value is now required as well, conditionally on parametersSource, which decides whether the row reads it from the box or from a column.

gamma also gets a new converter. It accepts either of the words scale and auto or a number, which no converter named after a type can carry, so it is now a lambda and its rule is a pattern. metric and metric_params are left alone: their converters are wrong in a different way, which is #7593's subject.

Any related issues, documentation, discussions?

Closes #7936.

How was this PR tested?

New and extended specs over the generated schema (SklearnAdvancedBaseDescSpec), the Formly branch selection and validator (formly-utils.spec.ts), and the new value control (constrained-value.component.spec.ts).

Every set, bound, pattern and example was checked against scikit-learn 1.7.2 rather than assumed, and on the boundary values of every bounded parameter the form's verdict was compared with the converter-then-scikit-learn verdict. Tried in the running application as well, on an SVM Classifier Trainer.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 5)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @Yicong-Huang, @carloea2, @aglinxinyuan
  You can notify them by mentioning @Yicong-Huang, @carloea2, @aglinxinyuan in a comment.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.50307% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.81%. Comparing base (6b8027e) to head (006ce38).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
...sklearnAdvanced/base/SklearnAdvancedBaseDesc.scala	65.21%	8 Missing and 8 partials ⚠️
frontend/src/app/common/formly/formly-utils.ts	95.83%	0 Missing and 2 partials ⚠️
...t/constrained-value/constrained-value.component.ts	90.47%	2 Missing ⚠️
...it-frame/operator-property-edit-frame.component.ts	0.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7946      +/-   ##
============================================
+ Coverage     92.52%   92.81%   +0.29%     
- Complexity     4620     4639      +19     
============================================
  Files          1175     1175              
  Lines         47466    47588     +122     
  Branches       5307     5346      +39     
============================================
+ Hits          43916    44168     +252     
+ Misses         1980     1909      -71     
+ Partials       1570     1511      -59     

Flag	Coverage Δ		*Carryforward flag
access-control-service	81.00% <ø> (ø)
agent-service	98.62% <ø> (ø)		Carriedforward from 6345c7a
amber	89.14% <82.41%> (+0.01%)	⬆️
computing-unit-managing-service	73.67% <ø> (ø)
config-service	86.73% <ø> (ø)
file-service	84.48% <ø> (ø)
frontend	95.06% <91.66%> (+0.66%)	⬆️
notebook-migration-service	79.13% <ø> (ø)
pyamber	97.52% <ø> (ø)		Carriedforward from 6345c7a
workflow-compiling-service	77.19% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

⚠️ Benchmark changes need a look

🟢 0 better · 🔴 4 worse · ⚪ 11 noise (<±5%) · 0 without baseline

Compared against main 3198595 benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	372	0.227	26,085/39,460/39,460 us	🔴 +13.3% / 🔴 +190.1%
🔴	bs=100 sw=10 sl=64	801	0.489	121,405/155,942/155,942 us	🔴 +7.5% / 🔴 +70.2%
⚪	bs=1000 sw=10 sl=64	929	0.567	1,075,927/1,119,991/1,119,991 us	⚪ within ±5% / 🔴 +28.5%

Baseline details

Latest main 3198595 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	372 tuples/sec	382 tuples/sec	908.02 tuples/sec	-2.6%	-59.0%
bs=10 sw=10 sl=64	MB/s	0.227 MB/s	0.233 MB/s	0.554 MB/s	-2.6%	-59.0%
bs=10 sw=10 sl=64	p50	26,085 us	25,595 us	10,907 us	+1.9%	+139.2%
bs=10 sw=10 sl=64	p95	39,460 us	34,828 us	13,604 us	+13.3%	+190.1%
bs=10 sw=10 sl=64	p99	39,460 us	34,828 us	16,697 us	+13.3%	+136.3%
bs=100 sw=10 sl=64	throughput	801 tuples/sec	820 tuples/sec	1,188 tuples/sec	-2.3%	-32.6%
bs=100 sw=10 sl=64	MB/s	0.489 MB/s	0.501 MB/s	0.725 MB/s	-2.4%	-32.5%
bs=100 sw=10 sl=64	p50	121,405 us	120,220 us	85,003 us	+1.0%	+42.8%
bs=100 sw=10 sl=64	p95	155,942 us	145,030 us	91,599 us	+7.5%	+70.2%
bs=100 sw=10 sl=64	p99	155,942 us	145,030 us	99,202 us	+7.5%	+57.2%
bs=1000 sw=10 sl=64	throughput	929 tuples/sec	916 tuples/sec	1,221 tuples/sec	+1.4%	-23.9%
bs=1000 sw=10 sl=64	MB/s	0.567 MB/s	0.559 MB/s	0.745 MB/s	+1.4%	-23.9%
bs=1000 sw=10 sl=64	p50	1,075,927 us	1,087,416 us	837,593 us	-1.1%	+28.5%
bs=1000 sw=10 sl=64	p95	1,119,991 us	1,144,293 us	881,015 us	-2.1%	+27.1%
bs=1000 sw=10 sl=64	p99	1,119,991 us	1,144,293 us	915,550 us	-2.1%	+22.3%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,538.25,200,128000,372,0.227,26084.74,39460.07,39460.07
1,100,10,64,20,2496.81,2000,1280000,801,0.489,121404.58,155941.64,155941.64
2,1000,10,64,20,21531.65,20000,12800000,929,0.567,1075927.33,1119990.83,1119990.83

[kz930]

@carloea2 @aglinxinyuan May you take a look at it please? Thank you!

[kz930]

/request-review @aglinxinyuan @carloea2

[carloea2]

The value validator is tied to the value control, but its rule depends on the parameter beside it. If value 1 is valid for C and the parameter changes to kernel, the value control does not change, so Angular may keep the old valid result. Please revalidate the value when the parameter changes and add a test using the real field controls.

[kz930]

Fixed in 6345c7a. The value field now re-judges itself when a parameter beside it changes, reading formly's fieldChanges so the row model is already the new one, and comparing parents so one table row leaves the others alone.

The new tests drive a rendered form over the real field controls rather than a hand-made field: with 1.0 in the value box, picking kernel now turns the field red, and the same tests fail if the revalidation is removed.