Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#17907 closed defect (fixed)

Random failure in enum_projective_number_field

Reported by: vbraun Owned by:
Priority: major Milestone: sage-6.7
Component: algebraic geometry Keywords: random_fail
Cc: gjorgenson, bhutz, dkrumm, jdoyle Merged in:
Authors: Ben Hutz Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: 4882838 (Commits) Commit:
Dependencies: Stopgaps:

Description

enum_projective_number_field (#17386) is missing points on OSX 10.6.8, possibly other platforms. This suggests that there is a bug in the algorithm where memory locations (determining sort order of objects without coercion into a common parent) matter.

  File "src/sage/schemes/projective/projective_rational_point.py", line 162, in sa  ge.schemes.projective.projective_rational_point.enum_projective_number_field 
  Failed example: 
    enum_projective_number_field(X(K),125) 
  Expected: 
    [(0 : 0 : 1), (-1 : -1 : 1), (1 : 1 : 1), (-1/5*v^2 : -1/5*v^2 : 1), (-v : -v : 1), 
    (1/5*v^2 : 1/5*v^2 : 1), (v : v : 1), (1 : 1 : 0)] 
  Got: 
    [(0 : 0 : 1), (-1 : -1 : 1), (1 : 1 : 1), (1 : 1 : 0)] 
********************************************************************** 

Change History (8)

comment:1 Changed 3 years ago by bhutz

  • Cc dkrumm jdoyle added

I haven't been able to reproduce this yet, but the issue is likely in #15389 since #17386 is just using that algorithm. So I've added John and David to the CC.

comment:2 Changed 3 years ago by jdoyle

There seems to be an issue with the way 'bound' is defined for points_of_bounded_height. If the expected bound is an absolute height bound and you want to convert to a relative height bound, you need to raise to the power (degree of number field), not 1/(degree of number field). In particular, the expected output in this example contains points with relative height at most 5. For example, the point (2 : 2 : 1) doesn't appear in the expected output, though it certainly has height (relative and absolute) less than 125.

This doesn't address the discrepancy in the two lists, though, at least not entirely. The issue must be related to the floating point arithmetic being used for elements_of_bounded_height. The four points appearing in the "expected" list and not the "for" list have relative height exactly equal to 5, which is the bound that is being passed to the elements_of_bounded_height function. I seem to remember something like this happening when we were testing elements_of_bounded_height, where sometimes points of exact height B would appear in the output, and occasionally they would not, depending on the machine.

One last comment: Because of the floating point arithmetic involved, the output of elements_of_bounded_height cannot be guaranteed correct (as per the warning in the documentation). Probably a warning to this effect should be included in the documentation here.

comment:3 Changed 3 years ago by bhutz

  • Branch set to u/bhutz/ticket/17907
  • Created changed from 03/07/15 13:10:40 to 03/07/15 13:10:40
  • Modified changed from 03/07/15 16:52:39 to 03/07/15 16:52:39

comment:4 Changed 3 years ago by bhutz

  • Authors set to Ben Hutz
  • Commit set to 4882838bcef659df5f261d5aa0063f39021d2ff7
  • Status changed from new to needs_review

I've made a start here. I fixed the exponent on the bound. I added a precision parameter and the warning to the appropriate functions. I also upped the precision for the failed example, but since I can't reproduce, I can't be sure that will fix it.

I guess I'll mark this as needs-review, although I'm not 100% sure I've resolved it. I won't be able to work on this for a few days if someone wants to take over in the meantime.


New commits:

488283817907: fix precision issues in enum_projective_number_field

comment:5 Changed 2 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

Seems to fix the issue, at least.

Of course it would be nice to pick the right precision automatically ...

comment:6 Changed 2 years ago by bhutz

Thanks for checking this. I've been having trouble finding someone with a machine which can reproduce the original error.

Yes, there is a TODO in the enumeration of points of bounded height in number fields (from #15389) to address the precision sensitivity.

comment:7 Changed 2 years ago by vbraun

  • Branch changed from u/bhutz/ticket/17907 to 4882838bcef659df5f261d5aa0063f39021d2ff7
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:8 in reply to: ↑ description Changed 2 years ago by leif

  • Commit 4882838bcef659df5f261d5aa0063f39021d2ff7 deleted
  • Milestone changed from sage-6.6 to sage-6.7

Replying to vbraun:

enum_projective_number_field (#17386) is missing points on OSX 10.6.8, possibly other platforms.

Just seen (with Sage 6.6) on Linux x86_64 (Haswell-E CPU), FSF GCC 4.9.2 (but not e.g. 4.4.3); patch fixes the doctest failure.

Note: See TracTickets for help on using tickets.