oh and forgot to mention, because of the way sage tries (and fails since Singular is very uncooperative) to map the points it knowns to points in Singular, the example above becomes (10,0,0,-1,0,3) (which again might change a sometimes since this depends on C[1][5]->POINTS).
Now mapping this vector to C[3], the place of degree 6 gets 10 which explains why we get such a high dimension. So I am guessing the underlined algorithm is correct but the way to get a hold of the points is screwy and until C[1][5]->POINTS relates properly to C[3] this can't be fixed on SAGE's side. Rado On Aug 3, 10:52 pm, Rado <rki...@gmail.com> wrote: > The problem is that there is a place of degree 6 at position 0 (or 1 > in Singular world). I think Singular used the places listed at C[3] > for RR computations (if i am > readinghttp://www.singular.uni-kl.de/Manual/latest/sing_1341.htm#SEC1418 > correctly) and not C[1][5]->Points (which is random and different). > > for the curve in question (run in Singular):>LIB "brnoeth.lib"; > >ring s=5,(x,y,z),lp; > >list C = Adj_div(x7+y7+z7); > >C = NSplaces(1,C); > >C = extcurve(1,C); > >C[3]; > > [1]: > 6,1 > [2]: > 1,1 > [3]: > 1,2 > [4]: > 1,3 > [5]: > 1,4 > [6]: > 1,5 > [7]: > 1,6 > > I think the output from set C[1][5] -> POINTS is deceiving since the > order seems to be random while , but don't know how to get the point > coordinates from C[3]. > > I actually need this for my research, so I can spend guilt-free time > trying to fix it (singular sintax is big road block for now). > > Rado > > On Jul 18, 7:01 pm, William Stein <wst...@gmail.com> wrote: > > > On Fri, Jul 17, 2009 at 6:35 AM, David Joyner<wdjoy...@gmail.com> wrote: > > > > On Fri, Jul 17, 2009 at 9:13 AM, David Joyner<wdjoy...@gmail.com> wrote: > > >> On Thu, Jul 16, 2009 at 5:19 AM, Martin > > >> Albrecht<m...@informatik.uni-bremen.de> wrote: > > > >>> On Thursday 16 July 2009, David Joyner wrote: > > >>>> On Wed, Jul 15, 2009 at 7:31 PM, Kiran Kedlaya<ksk...@gmail.com> wrote: > > >>>> > One pet complaint that you might bring up with the Singular team: I > > > >>>> Speaking of pet complaints, can you ask if they will at some point fix > > >>>> the bugs in the Riemann-Roch computations in the Brill-Noether > > >>>> routines? > > >>>> To be honest, I have not checked them recently but as of a few years > > >>>> ago they were unreliable. The Sage modulesage/coding/ag_codes.py > > >>>> (from 2006) is waiting for some Singular routines to be fixed I think. > > >>>> I do not know of an open source correct and functional implementation > > >>>> of > > >>>> any general algorithm to compute a basis for a Riemann-Roch space > > >>>> of a curve over a finite field. > > > >>> Hi David, > > > >>> this is now > > > >>> http://www.singular.uni-kl.de:8002/trac/ticket/153 > > > >>> Would you mind giving concrete examples there? > > > >> Thanks for creating it. > > > >> I've looked through my emails from 2006 and cannot find a trace of the > > >> examples I had then. I vaguely remember a certain example which would > > > This is in the Sage source code project_curve.py file: > > > The following example illustrates that the Riemann-Roch space > > function in Singular doesn't *not* work correctly. > > > :: > > > sage: R.<x,y,z> = GF(5)[] > > sage: f = x^7 + y^7 + z^7 > > sage: C = Curve(f); pts = C.rational_points() > > sage: D = C.divisor([ (3, pts[0]), (-1,pts[1]), (10, pts[5]) ]) > > sage: C.riemann_roch_basis(D) # output is random (!!!!) > > [x/(y + x), (z + y)/(y + x)] > > > The answer has dimension 2 (confirmed via Magma). But it varies > > between 1 and quite large with Singular. > > > When I run this today it consistently gives the same number of basis > > elements: > > > sage: len(C.riemann_roch_basis(D) ) > > 48 > > sage: len(C.riemann_roch_basis(D) ) > > 48 > > sage: len(C.riemann_roch_basis(D) ) > > 48 > > > I don't know why it always gives 48 now, which is very wrong, since the > > output > > should have length 2. At least the length isn't random now. The > > output still is (but this is OK given the problem): > > > sage: v = C.riemann_roch_basis(D) > > sage: w = C.riemann_roch_basis(D) > > sage: set(v) == set(w) > > False > > sage: len(v) > > 48 > > sage: len(w) > > 48 > > > -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
