#17907 closed defect (fixed)
Random failure in enum_projective_number_field
Reported by:  vbraun  Owned by:  

Priority:  major  Milestone:  sage6.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 4 years ago by
 Cc dkrumm jdoyle added
comment:2 Changed 4 years ago by
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 4 years ago by
 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 4 years ago by
 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 needsreview, 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

comment:5 Changed 4 years ago by
 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 4 years ago by
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 4 years ago by
 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 4 years ago by
 Commit 4882838bcef659df5f261d5aa0063f39021d2ff7 deleted
 Milestone changed from sage6.6 to sage6.7
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.