Random failure in enum_projective_number_field

[vbraun]

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)] 
********************************************************************** 

CC: @sagetrac-gjorgenson @bhutz @sagetrac-dkrumm @sagetrac-jdoyle

Component: algebraic geometry

Keywords: random_fail

Author: Ben Hutz

Branch: 4882838

Reviewer: Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/17907

[bhutz]

comment:1

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.

[sagetrac-jdoyle]

comment:2

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.

[bhutz]

Branch: u/bhutz/ticket/17907

[bhutz]

Commit: 4882838

[bhutz]

comment:4

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:

4882838

17907: fix precision issues in enum_projective_number_field

[bhutz]

Author: Ben Hutz

[vbraun]

comment:5

Seems to fix the issue, at least.

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

[vbraun]

Reviewer: Volker Braun

[bhutz]

comment:6

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.

[vbraun]

Changed branch from u/bhutz/ticket/17907 to 4882838

[nexttime]

Changed commit from 4882838 to none

[nexttime]

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.