Hi,
"primitive element" is meant as "generator for the multiplicative group
GF(p)^*" and not the additive group GF(p). The OP question is about the
former and Johan answer is about the latter.
For very large p such as what you asked for is likely to be delicate
(but I am not a specialist).
On 11 May 2017 at 08:16, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Hi,
>
> "primitive element" is meant as "generator for the multiplicative group
> GF(p)^*" and not the additive group GF(p). The OP question is about the
> former and Johan answer is about the latter.
Not really: gener
On Thursday, May 11, 2017 at 3:53:33 AM UTC+1, Jim Mooney wrote:
>
>
>
> On Thursday, May 4, 2017 at 5:02:57 PM UTC-7, Dima Pasechnik wrote:
>>
>> You can do the usual Linux administration things by logging into the
>> Linux console on the VM.
>> See sections 5 and 6 in
>> https://wiki.sagemath
> "primitive element" is meant as "generator for the multiplicative group
> GF(p)^*" and not the additive group GF(p). The OP question is about the
> former and Johan answer is about the latter.
Yes, I just realised that too - sorry about the noise. I'll think more
about the multiplicative group
On Wednesday, May 10, 2017 at 11:05:40 AM UTC+1, Panos Phronimos wrote:
>
>
> Hello everyone,
>
> I am trying to calculate a primitive element (g) of a big Finite Field:
> GF(p) where p is prime number > 2^2048
>
> So then, i could share a secret integer (r) as: m=g^r, but it seems
> impossible
> Not really: generators of the additive group are coprime to p, not to p-1.
>
> Perhaps Johan was thinking of the fact that if g is one multiplicative
> generator (aka primitive root) then g^k is another if and only if
> gcd(k,p-1)=1.
I think I should just not answer sage-support questions before
>>
>> Generalisation. Sometimes that judgement is an error, sometimes it's
>> not.
>>
>
> Unless there is a majority, or even better, a consensus, for doing this,
> I'd much prefer improving the existing code. It's much more incremental,
> and thus less error-prone (although more boring, of cours
Is there any particular change to test?
El miércoles, 10 de mayo de 2017, 16:12:26 (UTC+2), Dima Pasechnik escribió:
>
> Please test https://github.com/sagemath/sagenb/tree/1.0.rc0 (copy of the
> current master) before I go ahead with making a new Sage package. It works
> for me following the i
On Thursday, May 11, 2017 at 1:32:39 PM UTC+1, Enrique Artal wrote:
>
> Is there any particular change to test?
>
it's hard to say. It's an incremental update, incorporating perhaps 50 or
so minor changes and tweaks.
The biggest changes are in making the code more Python-3 ready.
>
> El mi
Hi,
the "sage -sws2rst" command does not display code block properly (see
https://trac.sagemath.org/ticket/22512).
The following pull request should fix it (to be typed from the sagenb/
repository at <1.0.rc0>):
git pull http://tmpsagenb.metelu.net/sagenb.git master
(the sha256sum of the co
On Thursday, May 11, 2017 at 4:19:22 PM UTC+1, Thierry
(sage-googlesucks@xxx) wrote:
>
> Hi,
>
> the "sage -sws2rst" command does not display code block properly (see
> https://trac.sagemath.org/ticket/22512).
>
> The following pull request should fix it (to be typed from the sagenb/
> repos
On Thursday, May 11, 2017 at 1:01:41 PM UTC+1, Johan S. H. Rosenkilde wrote:
>
> >>
> >> Generalisation. Sometimes that judgement is an error, sometimes it's
> >> not.
> >>
> >
> > Unless there is a majority, or even better, a consensus, for doing this,
> > I'd much prefer improving the exi
The German school thinks differently. There is a different (well known)
algorithm due to Gauss. Take an arbitrary number a coprime to p. Find its
order. If it is the primitive root, we are done. If not, choose another b and
check whether order of ab is greater than the order of a. If it is, repl
13 matches
Mail list logo
