GTSAM 4.0 Release Milestones

Issue #132 wontfix
Andrew Melim created an issue

The below issues should be fixed for 4.0 release (and possibly an intermediate hotfix):

Additionally, the following branches should be merged into develop when they are finished

  • feature/ordering
  • feature/BAD

Finally, this release will see the move to public gtsam!

Any other issues/features should be addressed?

Reference: @fdellaert @jdong37 @cbeall3 @lucacarlone @thduynguyen @ydjian

Comments (23)

  1. Andrew Melim reporter

    We can leave this open for a more long term plan this semester and do a targeted maintenance version to address bug fixes.

  2. Andrew Melim reporter

    I would classify everything that crashes/ fails to compile, or fails unit tests. It seems all the issues other than issue #130 qualify as that, I'll move to a separate issue.

  3. Frank Dellaert

    I have to stop coding for a while. But here’s my current thinking (best read in an Evernote that has some links

    We are using ptr_map for Values. Could still be OK, but internally we simply create a Chart object. DerivedValue and Value will no longer be visible outside. With a chart and traits, might not need to. @mikebosse if you have time to try this please go ahead, otherwise it'll have to wait until I'm a coding funk again.

    Erasing types is cool. Conclusions in part IV by (very cool) Andrzej. Some timings are here. Might or might not need any(!) of this, as ptr_map does trick.

    I still need to improve performance of expressions by trying unordered. I created an issue so @stan84 might have a go at this.

    Values compatibility, trait implementations, etc can all benefit from SFINAE or tag forwarding.

    I want to use Fusion more in Expressions, even to the point of having no custom classes for functions: everything is deduced from function passed. Possible? After @stan84 is successful with unordered, it might be something he might be interested in tackling.

  4. Luca Carlone

    @stan84: it would be great to include smart factors in GTSAM 4.0 after your fixes! let's discuss this during tomorrow's meeting.

  5. Richard Roberts

    Hi guys, given the slowness with incorporating our special matrix/vector initialization patch into Eigen, I suggest that I remove that feature for the 4.0 release. I'm glad to do that, i.e. refactor GTSAM (mostly the unit tests).

    An update on the patches - some internal expression template changes in the latest dev version of Eigen render our patches not working, and so far I haven't been able to figure it out, nor have I heard back on the message I sent the Eigen developers. Though, even after it's fixed and they incorporate the patch, it will take quite a while for the next Eigen version to filter down into system installs for Ubuntu. So, it was probably a mistake to make these changes in the first place (sorry!).

  6. Frank Dellaert

    Richard, does that mean the solution I suggested, having a header-file patch in GTSAM-Eigen-includes.h, has no chance of working?

  7. Richard Roberts

    Hi Frank, I replied about that earlier but it sounds like I misunderstood what you meant when you said "header file patches" previously, since it sounds like you're not talking about patching the system-installed Eigen. Can you explain what you mean by a header-file patch? Are you thinking of including some special code in GTSAM-Eigen-includes.h that somehow modifies the << operator?

  8. Andrew Melim reporter

    Definitely need eyes on my METIS pull request so we can get it integrated with the BAD changes and see if any build/execution issues exist.

  9. Frank Dellaert

    Nothing scheduled yet. When we have volunteers helping us out with the crucial things :-)

    Best Frank

  10. Log in to comment