[SPARK-57951][ML][TESTS] Tolerate last-ULP FP differences in MLTest single-prediction checks for macOS#57032
Closed
HyukjinKwon wants to merge 1 commit into
Closed
Conversation
…prediction checks testClassificationModelSingleRawPrediction and testProbClassificationModelSingleProbPrediction compared the DataFrame transform output against the scalar predictRaw/predictProbability output with exact === equality. On arm64 macOS the two paths can round differently in the last ULP (e.g. 1.543502002724983 vs 1.5435020027249835), failing suites such as MultilayerPerceptronClassifierSuite on the Build / Maven (JDK 21, MacOS-26) lane while Linux stays bit-identical. Compare the prediction vectors with a tight absolute tolerance (1e-9) instead, which still catches any real discrepancy. Generated-by: Claude Code
HyukjinKwon
changed the title
HyukjinKwon
changed the title
dongjoon-hyun
approved these changes
Jul 6, 2026
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…ngle-prediction checks for macOS ### What changes were proposed in this pull request? `MLTest.testClassificationModelSingleRawPrediction` and `testProbClassificationModelSingleProbPrediction` compared the DataFrame `transform` output against the scalar `predictRaw` / `predictProbability` output with exact `===` equality. This PR compares the two prediction vectors with a tight absolute tolerance (`1e-9`) via a small `assertVectorsAlmostEqual` helper instead. ### Why are the changes needed? On arm64 macOS the DataFrame path and the scalar path can round differently in the last ULP (e.g. `1.543502002724983` vs `1.5435020027249835`), so the exact `===` check fails: ``` [1.543502002724983,-1.543502002724983] did not equal [1.5435020027249835,-1.5435020027249835] (MLTest.scala:199) ``` This fails suites such as `MultilayerPerceptronClassifierSuite` on the scheduled `Build / Maven (Scala 2.13, JDK 21, MacOS-26)` lane, while the same tests are bit-identical on Linux. A `1e-9` absolute tolerance absorbs last-ULP platform rounding while still catching any real discrepancy between the two code paths. ### Does this PR introduce _any_ user-facing change? No. Test-only. ### How was this patch tested? Ran the affected classifier suites on a `macos-15` GitHub Actions runner (arm64, same class as `macos-26`): - `MultilayerPerceptronClassifierSuite`, `LogisticRegressionSuite`, `LinearSVCSuite`, `NaiveBayesSuite` — **113 tests, 0 failures** (the `prediction on single instance` cases that previously failed now pass). Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832 Before this change the same suites fail on `macos-26`: https://github.com/apache/spark/actions/runs/28753698265 ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code Closes #57032 from HyukjinKwon/ci-fix/agent4-mllib-fp-tol-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit fa81bf5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…ngle-prediction checks for macOS ### What changes were proposed in this pull request? `MLTest.testClassificationModelSingleRawPrediction` and `testProbClassificationModelSingleProbPrediction` compared the DataFrame `transform` output against the scalar `predictRaw` / `predictProbability` output with exact `===` equality. This PR compares the two prediction vectors with a tight absolute tolerance (`1e-9`) via a small `assertVectorsAlmostEqual` helper instead. ### Why are the changes needed? On arm64 macOS the DataFrame path and the scalar path can round differently in the last ULP (e.g. `1.543502002724983` vs `1.5435020027249835`), so the exact `===` check fails: ``` [1.543502002724983,-1.543502002724983] did not equal [1.5435020027249835,-1.5435020027249835] (MLTest.scala:199) ``` This fails suites such as `MultilayerPerceptronClassifierSuite` on the scheduled `Build / Maven (Scala 2.13, JDK 21, MacOS-26)` lane, while the same tests are bit-identical on Linux. A `1e-9` absolute tolerance absorbs last-ULP platform rounding while still catching any real discrepancy between the two code paths. ### Does this PR introduce _any_ user-facing change? No. Test-only. ### How was this patch tested? Ran the affected classifier suites on a `macos-15` GitHub Actions runner (arm64, same class as `macos-26`): - `MultilayerPerceptronClassifierSuite`, `LogisticRegressionSuite`, `LinearSVCSuite`, `NaiveBayesSuite` — **113 tests, 0 failures** (the `prediction on single instance` cases that previously failed now pass). Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832 Before this change the same suites fail on `macos-26`: https://github.com/apache/spark/actions/runs/28753698265 ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code Closes #57032 from HyukjinKwon/ci-fix/agent4-mllib-fp-tol-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit fa81bf5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…ngle-prediction checks for macOS ### What changes were proposed in this pull request? `MLTest.testClassificationModelSingleRawPrediction` and `testProbClassificationModelSingleProbPrediction` compared the DataFrame `transform` output against the scalar `predictRaw` / `predictProbability` output with exact `===` equality. This PR compares the two prediction vectors with a tight absolute tolerance (`1e-9`) via a small `assertVectorsAlmostEqual` helper instead. ### Why are the changes needed? On arm64 macOS the DataFrame path and the scalar path can round differently in the last ULP (e.g. `1.543502002724983` vs `1.5435020027249835`), so the exact `===` check fails: ``` [1.543502002724983,-1.543502002724983] did not equal [1.5435020027249835,-1.5435020027249835] (MLTest.scala:199) ``` This fails suites such as `MultilayerPerceptronClassifierSuite` on the scheduled `Build / Maven (Scala 2.13, JDK 21, MacOS-26)` lane, while the same tests are bit-identical on Linux. A `1e-9` absolute tolerance absorbs last-ULP platform rounding while still catching any real discrepancy between the two code paths. ### Does this PR introduce _any_ user-facing change? No. Test-only. ### How was this patch tested? Ran the affected classifier suites on a `macos-15` GitHub Actions runner (arm64, same class as `macos-26`): - `MultilayerPerceptronClassifierSuite`, `LogisticRegressionSuite`, `LinearSVCSuite`, `NaiveBayesSuite` — **113 tests, 0 failures** (the `prediction on single instance` cases that previously failed now pass). Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832 Before this change the same suites fail on `macos-26`: https://github.com/apache/spark/actions/runs/28753698265 ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code Closes #57032 from HyukjinKwon/ci-fix/agent4-mllib-fp-tol-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit fa81bf5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…ngle-prediction checks for macOS ### What changes were proposed in this pull request? `MLTest.testClassificationModelSingleRawPrediction` and `testProbClassificationModelSingleProbPrediction` compared the DataFrame `transform` output against the scalar `predictRaw` / `predictProbability` output with exact `===` equality. This PR compares the two prediction vectors with a tight absolute tolerance (`1e-9`) via a small `assertVectorsAlmostEqual` helper instead. ### Why are the changes needed? On arm64 macOS the DataFrame path and the scalar path can round differently in the last ULP (e.g. `1.543502002724983` vs `1.5435020027249835`), so the exact `===` check fails: ``` [1.543502002724983,-1.543502002724983] did not equal [1.5435020027249835,-1.5435020027249835] (MLTest.scala:199) ``` This fails suites such as `MultilayerPerceptronClassifierSuite` on the scheduled `Build / Maven (Scala 2.13, JDK 21, MacOS-26)` lane, while the same tests are bit-identical on Linux. A `1e-9` absolute tolerance absorbs last-ULP platform rounding while still catching any real discrepancy between the two code paths. ### Does this PR introduce _any_ user-facing change? No. Test-only. ### How was this patch tested? Ran the affected classifier suites on a `macos-15` GitHub Actions runner (arm64, same class as `macos-26`): - `MultilayerPerceptronClassifierSuite`, `LogisticRegressionSuite`, `LinearSVCSuite`, `NaiveBayesSuite` — **113 tests, 0 failures** (the `prediction on single instance` cases that previously failed now pass). Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832 Before this change the same suites fail on `macos-26`: https://github.com/apache/spark/actions/runs/28753698265 ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code Closes #57032 from HyukjinKwon/ci-fix/agent4-mllib-fp-tol-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit fa81bf5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
HyukjinKwon
added a commit
that referenced
this pull request
Jul 6, 2026
…ngle-prediction checks for macOS ### What changes were proposed in this pull request? `MLTest.testClassificationModelSingleRawPrediction` and `testProbClassificationModelSingleProbPrediction` compared the DataFrame `transform` output against the scalar `predictRaw` / `predictProbability` output with exact `===` equality. This PR compares the two prediction vectors with a tight absolute tolerance (`1e-9`) via a small `assertVectorsAlmostEqual` helper instead. ### Why are the changes needed? On arm64 macOS the DataFrame path and the scalar path can round differently in the last ULP (e.g. `1.543502002724983` vs `1.5435020027249835`), so the exact `===` check fails: ``` [1.543502002724983,-1.543502002724983] did not equal [1.5435020027249835,-1.5435020027249835] (MLTest.scala:199) ``` This fails suites such as `MultilayerPerceptronClassifierSuite` on the scheduled `Build / Maven (Scala 2.13, JDK 21, MacOS-26)` lane, while the same tests are bit-identical on Linux. A `1e-9` absolute tolerance absorbs last-ULP platform rounding while still catching any real discrepancy between the two code paths. ### Does this PR introduce _any_ user-facing change? No. Test-only. ### How was this patch tested? Ran the affected classifier suites on a `macos-15` GitHub Actions runner (arm64, same class as `macos-26`): - `MultilayerPerceptronClassifierSuite`, `LogisticRegressionSuite`, `LinearSVCSuite`, `NaiveBayesSuite` — **113 tests, 0 failures** (the `prediction on single instance` cases that previously failed now pass). Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832 Before this change the same suites fail on `macos-26`: https://github.com/apache/spark/actions/runs/28753698265 ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code Closes #57032 from HyukjinKwon/ci-fix/agent4-mllib-fp-tol-pr. Authored-by: Hyukjin Kwon <gurwls223@apache.org> Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com> (cherry picked from commit fa81bf5) Signed-off-by: Hyukjin Kwon <hyukjin.kwon@databricks.com>
Member
Author
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
2 participants
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.
What changes were proposed in this pull request?
MLTest.testClassificationModelSingleRawPredictionandtestProbClassificationModelSingleProbPredictioncompared the DataFrametransformoutput against the scalar
predictRaw/predictProbabilityoutput with exact===equality. This PR compares the two prediction vectors with a tight absolute tolerance
(
1e-9) via a smallassertVectorsAlmostEqualhelper instead.Why are the changes needed?
On arm64 macOS the DataFrame path and the scalar path can round differently in the last
ULP (e.g.
1.543502002724983vs1.5435020027249835), so the exact===check fails:This fails suites such as
MultilayerPerceptronClassifierSuiteon the scheduledBuild / Maven (Scala 2.13, JDK 21, MacOS-26)lane, while the same tests are bit-identicalon Linux. A
1e-9absolute tolerance absorbs last-ULP platform rounding while still catchingany real discrepancy between the two code paths.
Does this PR introduce any user-facing change?
No. Test-only.
How was this patch tested?
Ran the affected classifier suites on a
macos-15GitHub Actions runner (arm64, same class asmacos-26):MultilayerPerceptronClassifierSuite,LogisticRegressionSuite,LinearSVCSuite,NaiveBayesSuite— 113 tests, 0 failures (theprediction on single instancecases thatpreviously failed now pass).
Passed: https://github.com/HyukjinKwon/spark/actions/runs/28766568832
Before this change the same suites fail on
macos-26:https://github.com/apache/spark/actions/runs/28753698265
Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code