Opened 4 years ago

Closed 3 years ago

#23582 closed enhancement (wontfix)

Robustify doctest in

Reported by: rws Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: geometry Keywords:
Cc: Merged in:
Authors: Ralf Stephan Reviewers: Frédéric Chapoton
Report Upstream: N/A Work issues:
Branch: u/rws/robustify_doctest_in_hyperbolic_geodesic_py (Commits, GitHub, GitLab) Commit: a90ce6a6d5eaf6f984dc863afb70c72de47e0a64
Dependencies: Stopgaps:

Status badges


A doctest of the midpoint code in geometry/hyperbolic_space/ relies on exact reproduction of complicated symbolic expressions involving square roots. With recent changes in Pynac the representation of the result no longer matches, although it is mathematically identical.

The ticket changes the doctest to match results numerically.

Change History (6)

comment:1 Changed 4 years ago by rws

  • Branch set to u/rws/robustify_doctest_in_hyperbolic_geodesic_py

comment:2 Changed 4 years ago by rws

  • Authors set to Ralf Stephan
  • Commit set to a90ce6a6d5eaf6f984dc863afb70c72de47e0a64
  • Status changed from new to needs_review

New commits:

a90ce6a23582: Robustify doctest in

comment:3 Changed 4 years ago by chapoton

  • Reviewers set to Frédéric Chapoton
  • Status changed from needs_review to positive_review

ok, looks good

comment:4 Changed 4 years ago by tscrim

  • Status changed from positive_review to needs_info

I'm not completely sure about this. If it is mathematically identical, why not simply change the doctest with the new version of pynac? Should then all (sufficiently complicated) symbolic expressions output not be used for doctests? IMO, this makes the doctest less likely to catch errors and feels like a tiny step backwards in that regard.

comment:5 Changed 4 years ago by rws

  • Milestone changed from sage-8.1 to sage-duplicate/invalid/wontfix
  • Status changed from needs_info to positive_review

The change is no longer necessary because the mentioned change in Pynac didn't happen. I agree to make the ticket invalid.

However, let me point out that it is highly unlikely that a symbolic error would pass such a numeric test. Note that such numeric tests additionally test the FP evaluation code so it's more likely to catch bugs.

comment:6 Changed 3 years ago by embray

  • Resolution set to wontfix
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.