Michael Stoll said at SD6 that he had written such a generic program
in Magma. You could ask him to dig it out and pass it on.
For the specific elliptic curve case I'm sure that using a custom
program will be better in many respects, since you know so much more
about the group structure's possib
On Nov 19, 2007, at 10:10 AM, David Joyner wrote:
>> I think the idea is supposed to be that part of the definition of the
>> black box is that it can produce random elements, regardless of
>> whether you know the generators. So for example, suppose our group is
>> the multiplicative group of Z/
On Nov 19, 2007 7:27 AM, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 19, 2007, at 6:59 AM, David Joyner wrote:
>
> >> Further down the road, Drew Sutherland is thinking about writing a C+
> >> + library for computing things like orders, exponents, structures of
> >> generic abelian groups
On Nov 19, 2007, at 6:59 AM, David Joyner wrote:
>> Further down the road, Drew Sutherland is thinking about writing a C+
>> + library for computing things like orders, exponents, structures of
>> generic abelian groups. Basically you give it a "black box" that
>> knows how to add group elements
On Nov 19, 2007 6:33 AM, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
>
> On Nov 19, 2007, at 4:55 AM, Martin Albrecht wrote:
>
> >> I still don't believe this algorithm.
> >>
> >> Look at this example:
> >>
> >> sage: K. = GF(3^4)
> >> sage: K.polynomial()
> >> a^4 + 2*a^3 + 2
> >> sage: E = Ellip
On Nov 19, 2007, at 4:55 AM, Martin Albrecht wrote:
>> I still don't believe this algorithm.
>>
>> Look at this example:
>>
>> sage: K. = GF(3^4)
>> sage: K.polynomial()
>> a^4 + 2*a^3 + 2
>> sage: E = EllipticCurve(K, [2*a^2 + 2*a + 2, 2*a^3 + 2*a + 1])
>> sage: points = E.points()
>> sage: len
One short update:
* various people fixed the doctest failures with numpy/sciyp (Josh
Kantor), the failed g0n doctest (me + William)
* the libfplll issues (blocker #1188) has been fixed by wjp, a.k.a.
Willem Jan Palenstijn
* reverting to sqlite from 2.8.12 fixes the segfault in sage/databases/
dat
That is about right. Also n_2 divides q-1 where q is the field order,
which is also useful for cutting down the possibilities.
However you cannot compute the group order _just_ by computing the
orders of random elements. For example, structures 2*8 and 16 would
not be distinguished unless you h
On Sunday 18 November 2007, David Harvey wrote:
> On Nov 18, 2007, at 8:49 AM, Martin Albrecht wrote:
> > On Sunday 18 November 2007, David Harvey wrote:
> >> On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote:
> #1130
> >>>
> >>> This seems to rely on an earlier patch. (#1120?) See comments
I only just spotted this sub-thread since the whole thread concerns
many different things.
I will look into that code since it is doing what is already
implemented twice in Sage-contributed code written by me: in mwrank
and in my gp scripts.
John
On 18/11/2007, David Harvey <[EMAIL PROTECTED]>
On Nov 18, 3:02 pm, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
> > * the new scipy.spkg does not build on sage.math in case you compile
> > 2.8.12 from scratch. If you take the 2.8.12 binary from sage.math it
> > does work. You are required to build the new numpy first, though. I
> > tried fixin
On Nov 18, 2007, at 8:49 AM, Martin Albrecht wrote:
>
> On Sunday 18 November 2007, David Harvey wrote:
>> On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote:
#1130
>>>
>>> This seems to rely on an earlier patch. (#1120?) See comments on
>>> trac.
>>
>> I'm very concerned about this patch
> * the new scipy.spkg does not build on sage.math in case you compile
> 2.8.12 from scratch. If you take the 2.8.12 binary from sage.math it
> does work. You are required to build the new numpy first, though. I
> tried fixing this, but after 8 hours I have given up. Once the new
> scipy failed ev
On Sunday 18 November 2007, David Harvey wrote:
> On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote:
> >> #1130
> >
> > This seems to rely on an earlier patch. (#1120?) See comments on trac.
>
> I'm very concerned about this patch. It is not the case that the LCM
> of the orders of all elements o
A short status update:
* the new scipy.spkg does not build on sage.math in case you compile
2.8.12 from scratch. If you take the 2.8.12 binary from sage.math it
does work. You are required to build the new numpy first, though. I
tried fixing this, but after 8 hours I have given up. Once the new
s
On Nov 18, 2007, at 4:16 AM, Robert Bradshaw wrote:
>> #1130
>
> This seems to rely on an earlier patch. (#1120?) See comments on trac.
I'm very concerned about this patch. It is not the case that the LCM
of the orders of all elements of E(GF(q)) will equal the order of E(GF
(q)). I haven't
Here's some comments. (Sorry for taking all the low-hanging fruit...)
- Robert
On Nov 17, 2007, at 10:03 PM, mabshoff wrote:
> Ok, various people have gone over track and commented on tickets.
>
> But the following patches need reviews:
>
> #1107
Minkowski bound...I heard about that somewher
Ok, various people have gone over track and commented on tickets.
But the following patches need reviews:
#980
#1077
#1107
#1119
#1120
#1122
#1130
#1131
#1134
#1136
#1141
#1148
#1156
#1174
#1181
#1186
#1190
#1194
#1196
A lot of the patches by malb concern libSingular and also elliptic
curves.
18 matches
Mail list logo
