Open cbarcelo-bdai opened 1 month ago
Interesting!
p.s. Your links are to line numbers on the master
branch, which will eventually go out of date. When you're on the page with the line number, if you push y
on your keyboard it will switch the URL to be a permalink. When you have a moment, please update your hyperlinks in the original to be permalinks.
I'd say someone got carried away with trying to delegate between operator op
and operator op=
similar functions. If you simplify the code, does it work better for you:
If this seems to help, you could extend the pattern to the rest of the spatial_algebra files.
If you simplify the code, does it work better for you:
Alright, so I've implemented the following changes:
And this is the diff on the list of failing tests I have:
Which is weird because although the test I was pointing to (frame_kinematics_test
) and even spatial_algebra_test
start passing, new failing tests appear now.
Not only that, but if I re-run the tests a second time (without a bazel clean
in between) all pydrake
tests fail with undefined symbol error (something that does not happen on master)
/pydrake/__init__.py", line 163, in <module>
from . import common
ImportError: /home/cbarcelo_theaiinstitute_com/.cache/bazel/_bazel_cbarcelo_theaiinstitute_com/aa900abf41791df073d1b5a78180283d/sandbox/linux-sandbox/134019/execroot/drake/bazel-out/aarch64-opt/bin/bindings/pydrake/multibody/py/inverse_kinematics_test.runfiles/drake/bindings/pydrake/common/../../../_solib_aarch64/_U_S_Stools_Sinstall_Slibdrake_Cdrake_Ushared_Ulibrary___Utools_Sinstall_Slibdrake/libdrake.so: undefined symbol: __builtin_copysignq
I can't see any way that patch would be the actual cause of those new error messages. The patch seems like an improvement, so I would say please open a PR with that, we can review and merge it, and then circle back to any remaining errors after that.
What happened?
When Drake is run on Ubuntu 22.04 and arm64, several tests fail. While some failures due to unmet tolerances in floating point calculations, I've found some tests that fail not because of Drake's internal calculations, but because the expected values themselves are incorrect (those values manually calculated as part of the tests)
For example, this
EXPECT_TRUE
assertion in frame_kinematics_test fails because w_L3E_E_expected contains an incorrect value. When investigating why the calculations didn't produce the expected value, I discovered that simply printing the values used for this subtraction (right before the return statement) makes the test pass.This not only points back to the same class an UB was previously found (here), but the code itself, although correct, looks strange. It returns whatever comes from the subtraction, but
operator-
gets the reference, creates a copy of one of theSpatialVelocity
, callsoperator-=
fromSpatialVelocity
's base class (SpatialVector
) and returns in place.I'd appreciate feedback on whether this code looks correct or if it requires refactoring. If refactoring is needed and you have a theory on what needs to be done to have it fixed, I'd be happy to contribute.
Version
master
What operating system are you using?
Ubuntu 22.04, Other
What installation option are you using?
compiled from source code using Bazel
Relevant log output
No response