Ceres Solver Version 2.2.0 Release Candidate 1

[Sameer Agarwal]

Hello Everyone,

The recent changes to SuiteSparse have broken the build for 2.1.0. Combined with the fact that it is a 18 month old release we decided that releasing 2.2.0 is the right thing to do. So here we are.

http://ceres-solver.org/ceres-solver-2.2.0rc1.tar.gz

is available for your testing pleasure. 

I wanted to highlight some of the bigger changes in this release.

1. Dmitriy Korchemkin has done some remarkable work simplifying and improving the threading performance in Ceres. Every part of ceres is better as a result of this work.
2. We now have mixed precision support in our linear solvers and for well conditioned problems it should lead to very nice performance improvements. The documentation is a bit scarce but I am going to work on improving it. I do recommend giving it a try.
3. We now support Nested Dissection as an ordering algorithm for sparse cholesky which for some problems can make an enormous difference in the memory and time usage.
4. Mark Shackov has contributed an implementation of Power Bundle Adjustment which can be used both as a linear solver as well as a preconditioner. (again the documentation is a bit sparse, but the header docs in solver.h should get you going)
5. Thanks to HS Nelson Go we have a really nice Euler angle API.
6. Joydeep Biswas got CGNR running on CUDA. For general sparse problems this maybe a viable option now. The CPU based CGNR was usually too slow. 

The biggest backward incompatible change is that LocalParameterization is no more, and we are now reliant on c++17. CXSparse support has also been removed. Eigen should offer you the same or better performance.

The code is fairly stable so we do not expect any major bugs. Our CI on GitHub has gotten much better this cycle too (Thanks Sergiu!), so the number of build issues you will encounter should also be much smaller. That said, there are only so many combinations of toolchains and platforms we can test,  we rely on you to make sure that Ceres Solver continues to work well & fast for your use cases. So please try this release out and give us feedback. 

We would like to make this a relatively short release cycle and try and get a release out by the first week of October, so please use this email thread or GitHub to report issues. 

Happy Optimizing,

Sameer for the Ceres Solver Team

[Andreu Corominas Murtra]

Hi Sameer ,

first of all , big thanks to all contributors for this next release.

Regarding the sentence "The biggest backward incompatible change is that LocalParameterization is no more", can you explain a little bit which will be the proposed alternative to deal with paremetr blocks with dimensions greater than degrees of freedom (for instance the quaternion case) ?

thanks a lot!

Andreu

-- 
------------------------------------
Andreu Corominas Murtra
PhD Engineer
Business Director & Co-founder
and...@beta-robots.com
+34 635 575 864
www.beta-robots.com
------------------------------------

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUA29iJ-qNAFvvpLCCHJohPk6LJzNW8UGgZJP7UamzQLOw%40mail.gmail.com.

[Sameer Agarwal]

Andrew Manifolds are the new LocalParameterization.

https://github.com/ceres-solver/ceres-solver/blob/master/include/ceres/manifold.h

they are a drop in replacement for LocalParameterizations.

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/1e863cdb-d29f-1bc9-e3c2-a74959e65d05%40beta-robots.com.

[Andreu Corominas Murtra]

ok! cool !

thanks

Andreu

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUDZir4R4uGBA33YpFyXVYGjETaFmPmHzFRZKRBAzK0g1g%40mail.gmail.com.

[Roger Labbe]

Since this supports c++17, can you change the definition of has_denorm in jet.h? It is causing deprecation warnings in the most recent version of visual studio. I think this is the up-to-date way to write it, but I have no way to test if it works in other compilers&environments.

static constexpr auto has_denorm = std::numeric_limits<T>::has_denorm;

[Sameer Agarwal]

Roger,

Can you share the warning you are getting from VSCode? Also what C++ standard are you using when compiling your own code that uses ceres?

I am not entirely clear why I have to replace std::float_denorm_style with auto. I would like to understand this better.

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/30eb4346-646c-4065-9b0d-b58c9b2cff01n%40googlegroups.com.

[Roger Labbe]

Apologies for the incomplete description and probably rush to email. The issue is deprecation of the float_denorm_style et. al. It is not until 2023, but MSVC is very annoyingly warning about this now. I'm running VS 2022 17.7.3, .NET 4.8.09037,  building for/std:c++latest. This popped up when I updated Visual Studio, and all our projects for better/worse are set to warnings set to error.  Changing to /std:c++20 makes the warning not appear. Another work-around is setting Warning Version to 4.8 (/Wv:"4.8"). I also should have said this happens with 2.1.0, it is not specific to 2.2.0, I just hoped you could address this since you have a release coming soon. 

Deprecation documented here: https://en.cppreference.com/w/cpp/types/numeric_limits/has_denorm

 and https://github.com/cplusplus/papers/issues/1278

Reading a bit more I am not sure why my proposed change stops the warning, as has_denorm itself seems to also be deprecated, though it does. I am not a C++ language lawyer, it just worked, and obviously you shouldn't just make the change due to 'it worked'.

Earlier I tried modifying internal/disable_warnings.h, but the warnings were still emitted.

I do recognize we can either use the flags above or define macros mentioned in the warning to silence this, but you seem to have to do it 'globally' if using the macros; if I put it before #include <ceres/jet.h> (and any other ceres include)  for example, the warning is still generated. Not the end of the world, but I kind of like warnings and don't want to suppress them across our code, nor do I want to change hundreds of vsxprojs now to compile, and then remember to change them again in a few years when Ceres becomes c++23 compliant. To be honest, I'll just edit jet.h locally if you decide to not support this now. 

1>M:\work\3rdParty\ceres-solver-2.1.0\include\ceres\jet.h(1267,3): error C2220: the following warning is treated as an error
1>M:\work\3rdParty\ceres-solver-2.1.0\include\ceres\jet.h(1267,3): warning C4996: 'std::float_denorm_style': warning STL4042: std::float_denorm_style, std::numeric_limits::has_denorm, and std::numeric_limits::has_denorm_loss are deprecated in C++23. You can define _SILENCE_CXX23_DENORM_DEPRECATION_WARNING or _SILENCE_ALL_CXX23_DEPRECATION_WARNINGS to suppress this warning.
1>M:\work\3rdParty\ceres-solver-2.1.0\include\ceres\jet.h(1314,2): message : see reference to class template instantiation 'std::numeric_limits<ceres::Jet<T,N>>' being compiled

[Sameer Agarwal]

Thanks for the details Roger. Let me see what we can do.

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/ead58941-47da-4192-9e2c-0776121f2c59n%40googlegroups.com.

[Sameer Agarwal]

Roger,

Sergiu has just committed a fix for this at head. Could you try it out and let us know if this works for you?

Sameer

[Roger Labbe]

Yes, warnings are suppressed. Thank you.

[Sameer Agarwal]

Excellent, ty for testing and letting us know.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/459f1321-b76d-4263-8df6-485b818089a1n%40googlegroups.com.