Skip to content

CI: test macOS #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Apr 6, 2025
Merged

CI: test macOS #19

merged 11 commits into from
Apr 6, 2025

Conversation

lucascolley
Copy link
Member

@lucascolley lucascolley commented Apr 5, 2025

TODO:

  • fix Linux errors:
	 32 - cyl_bessel_i dd->d scipy_special_tests (Failed)
	 33 - cyl_bessel_i dD->D scipy_special_tests (Failed)
  • set up tolerances for macos

Copy link
Member Author

@lucascolley lucascolley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@steppi here are all the changes needed to get macOS tests running in CI. Of course, the tolerances need adjustments.


As a separate bit of fun, CI is now exactly reproducing the errors I saw on my linux box.

@lucascolley lucascolley marked this pull request as ready for review April 5, 2025 13:58
This was referenced Apr 5, 2025
Co-authored-by: Albert Steppi <[email protected]>
@lucascolley
Copy link
Member Author

The default compiler for macOS from conda-forge looks to be Clang 18.1.8

@lucascolley
Copy link
Member Author

okay, I see

75% tests passed, 58 tests failed out of 231

locally, let's see if CI agrees

Comment on lines 140 to 144
std::string get_platform_str() {
/* This is going to get a string "<compiler>-<os>-<architecture>" using conditional
* compilation, but for now we're just stubbing things out. */
return "gcc-linux-x86_64";
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the tolerance files for Mac, but we need to use preprocessor directives here to make sure the correct file gets selected for each platform. I was looking at this, https://stackoverflow.com/questions/152016/detecting-cpu-architecture-compile-time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, cool.

Long-term, we could look at specifying the compiler version here as well? Thinking ahead, having a shared Pixi workspace between xsf and xsfref should allow the reference values to be generated by the same envs as they are tested in against the implementations.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I originally did specify the compiler version but was trying to avoid having too many files. Long term I think we should be using some kind of cloud storage solution instead of stashing the parquet files on Github, and then it should be fine to get very granular with the platforms/compilers/whatever in the tolerance files. For now, maybe it's fine to just allow individual adjustments of the wiggle factor in adjust_tolerance in tests.

@@ -127,25 +131,20 @@ Catch::Generators::GeneratorWrapper<std::tuple<T1, T2, T3>> xsf_test_cases(
);
}


template <typename T>
T adjust_tolerance(T tol) {
// Add some wiggle room to tolerance from table.
return 4 * std::max(std::numeric_limits<T>::epsilon(), tol);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For failures due to different compiler versions, like the currently failing Linux tests, I think it's fine just to increase the wiggle room factor here for now, as long as it doesn't get too large.

@steppi
Copy link
Collaborator

steppi commented Apr 6, 2025

The 3 Mac OS failures look real. I think SciPy uses a wrapper for those functions which handles the n non-finite case.

@steppi
Copy link
Collaborator

steppi commented Apr 6, 2025

I just yanked those failing tests out. bdtr, bdtri, and bdtrc for non-integer n don't even exist in xsf, those overloads are defined in SciPy (and are deprecated there). There are other cases like this I think, but I'm just doing the minimum to get tests to pass. The corresponding tables should be removed from xsref too.

Copy link
Collaborator

@steppi steppi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is passing now. Thanks @lucascolley! I'm going to go ahead and merge this so we can continue iterating from here.

@steppi steppi merged commit 02ed86b into scipy:main Apr 6, 2025
2 checks passed
@lucascolley lucascolley deleted the macos branch April 6, 2025 07:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants