Re: ellisoncurve() and ellpointtoz()

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

On Mon, 14 Oct 2002, Vasily Golyshev wrote:
> here is an irregularity in ellisoncurve():
>
> ? C=ellinit([0,0,0,0,1])
> %1 = [0, 0, 0, 0, 1, 0, 0, 4, 0, 0, -864, -432, 0,
> [-1.000000000000000000000000000, 0.5000000000000000000000000000 -
> 0.8660254037844386467637231707*I, 0.5000000000000000000000000000 +
> 0.8660254037844386467637231707*I]~, 4.206546315976362783525057237,
> -2.103273157988181391762528618 + 1.214325323943790805909970844*I,
> -1.293554779614895267476757512 + 1.44309482 E-29*I,
> 0.6467773898074476337383787562 - 1.120251300333280219655206320*I,
> 5.108115717832556535122194506]
>
>
> ? ellisoncurve(C,[Mod(t,t^2-t+1),0])
> %2 = 1
> ? ellisoncurve(C,[1/2-sqrt(3)/2*I,0])
> %3 = 0
>
> Now, what I actually need for my purposes is to find
> (up to a sign) ellpointtoz() of a point, given only its abscissa,
> but it appears that I have to do
>
>  ellpointtoz(C,[p[1],ellordinate(C,p[1])[1]])
>
> first, which fails in this case.

[Cc-ed to pari-dev]

For non-exact input, ellisoncurve() is quite kludgy (it needs to decide
whether some floating point coordinates are non-zero).

There was a bug in the current kludge which caused it to err when the
y-coordinate was exactly 0. I've complicated it further in order to fix this
specific problem.

But this is really not a proper fix. In fact, the only reliable fix I see is
to decline to check that the point is on the curve when some of the data is
inexact. Currently, only ellpointtoz and ellheight perform this check. I am
not sure why, or whether it should not be cancelled altogether (possibly
unless debugging level is high enough).

Cheers,

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/