-
Notifications
You must be signed in to change notification settings - Fork 176
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
Eigen 3.4 compatibility #2368
Eigen 3.4 compatibility #2368
Conversation
Since these are defined in Eigen 3.4 and cause conflicts. Instead, just use the standard Eigen::Vector3d typedef, which is identical currently. This may cause issues if we ever decide to revert the default_type typedef from double (its current value) to float or something, but I don't see that happening any time soon.
Looks like Eigen 3.4 introduces subtle differences in precision. Actually not so subtle in the case of For now, I reckon we pin the Eigen version to 3.3 in homebrew for the macOS CI - that'll at least allow the CI to complete, we can investigate the issues with precision at a later time. |
@maxpietsch: any idea how to request |
I don't think it's supposed to be possible in homebrew to get legacy versions of packages. There seems to be a workaround using the old formula but maybe just clone eigen from https://gitlab.com/libeigen/eigen/-/tree/3.3? Edit: Actually, the raw formula trick does not work anymore, results in
|
Question is whether or not we should explicitly test whether or not |
Well, Eigen's |
So can we add that to the CI workflow for macOS? |
Tests also failed with eigen 3.3.9, trying 3.3.7 as in eigen 3.3.8, |
Good find @maxpietsch! Question then is whether the later versions actually provide more accurate results, in which case maybe we should update the test data to match...? This would then mean that testing against older versions of Eigen would fail... Not sure how best to deal with this. |
Save pre-calculated results using both versions; flag as error if test output matches neither. |
Yes, that's more or less what was going through my mind too... I'll need to spend a bit of time figuring this out. In which case there would be no point in tweaking the CI tests, @maxpietsch, let's leave them as-is for now. |
c819219
to
c5e852f
Compare
This is due to changes in Eigen causing differences in output. Some of these are substantial, but not unexpected (dwidenoise in particular relies on precision of smallest eigenvalues, so minor changes in precision can lead to relatively large changes in output).
I had a look into the test failures with Eigen 3.4, and they're really due to quite minor differences in precision. For |
Looks good! |
OK, I'll merge this to |
The latest stable version fails to build with latest eigen (> 3). MRtrix3/mrtrix3#2368
The latest stable version fails to build with latest eigen (> 3). MRtrix3/mrtrix3#2368 (cherry picked from commit b1d95dc)
Remove
Eigen::Vectors/4
typedefs since these are defined in Eigen 3.4 and cause conflicts. Instead, just use the standardEigen::Vector3d
typedef, which is identical currently. This may cause issues if we ever decide to revert thedefault_type
typedef fromdouble
(its current value) to float or something, but I don't see that happening any time soon. Besides, even if we do changedefault_type
, there's a good argument that this shouldn't influence the vast majority of these instance ofVector3
, since this is likely to break all kinds of operations.These changes are required to pass CI on macOS, since homebrew now ships with Eigen 3.4.