Vasily Golyshev on Wed, 16 Oct 2002 23:32:32 +0400 (MSD) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: ellisoncurve() and ellpointtoz() [2] |
On Wed, 16 Oct 2002, Karim BELABAS wrote: > 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. > It seems to me that ellheight is something that you would only want to apply to exact data. Ellpointtoz, on the other hand, will be safer with a possibility of a check. A compromise could be an ellpointtoz with a 'float' flag, returning the result and also the abs(RHS-LHS) of the defining equation, for the user to decide for himself whether to consider the result valid. Vasily.