I put a band-aid type fix of this rational point issue in ticket #25239.
However, I was unable to create a simpler example than the one listed
below. If someone better understands how QQbar arithmetic is exact/inexact
could take a look at this behavior that would be appreciated.
Ben
On Saturday, January 27, 2018 at 7:47:23 AM UTC-6, Ben Hutz wrote:
>
> I'm trying to track down a rational point failure. Here is a simple
> reproduction
>
> this way gives an error that the point is not on the scheme (doesn't
> satisfy the equations)
> P.<x,y,z,w>=ProjectiveSpace(QQ,3)
> X=P.subscheme([-7/4*z-w, x-7/4*z, -3/4*x+y-9/16*z+3/4*w])
> X.change_ring(QQbar).rational_points()
>
> But this way fails
> P.<x,y,z,w>=ProjectiveSpace(QQbar,3)
> X=P.subscheme([-7/4*z-w, x-7/4*z, -3/4*x+y-9/16*z+3/4*w])
> X.rational_points()
>
> In tracking this down, everything is fine in the first case until your
> normalize the point in initialization. For projective points defined over
> fields, Sage has the convention to make the last coordinate 1 by dividing
> through by the last coordinate. Before that division, the point satisfies
> the equations, after that division evaluating the polynomials gives
> ~1*10^{-19) so is not == 0. I thought QQbar was supposed to be exact
> arithmetic. However, it seems that if I 'touch' the coordinates with
>
> c.as_number_field_element()
>
> even without actually doing anything to the point, then it works and says
> the point is on the scheme.
>
> Am I supposed to have to 'touch' QQbar elements like this before I can
> check exact polynomial evaluation with them? or Is there something else
> going wrong here?
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
