Hi Panos
The snippet you gave certainly does not work since it will compute the gcd
of 1 and something else, which is - of course - 1.
What you need is to compute the *half gcd* of R and g, i.e. run the
Extended Euclidean algorithm about half-way and then stop. The Bezout
relation from that i
On Sunday, January 8, 2017 at 10:14:32 AM UTC+1, Marc Mezzarobba wrote:
>
> Simon King wrote:
> > Wouldn't it be better to [...] or change the
> > arithmetic operations by *avoiding* a call to __init__()?
>
> That's what the branch I pointed to tries to do, to some extent at
> least. But the st
Hi Panos,
> I finally implement the decoder using lattice basis reduction (using LLL)
I presume you mean F[x]-lattice basis reduction, i.e. row reduction of
F[x] matrices (the LLL is for integer matrices).
> The only thing left is to reduce the execution time of the decoder by
> finding the mo
'Peter Mueller' via sage-support writes:
> The functions and their docs in codes.bounds.* still seem to be a mess (as
> they have been since many years now). (...)
Indeed, these bounds are a catastrophe. Names, order of parameters, and
documentation is sorely lacking. In particular, none of the
the constructions - requiring Nathann'esque ardour. I
completely agree that it would be great if Sage had this, but it's
hardly on the same scale as improving the small set of bounds we
currently support in Sage (which we'd need in any case).
Best,
Johan
Dima Pasechnik writes:
ode constructions and code manipulations.
To properly supersede codetables.de, we would also need the search
algorithm for finding good derived codes from base constructions.
Best,
Johan
Dima Pasechnik writes:
> On Wednesday, May 10, 2017 at 8:47:21 AM UTC+1, Johan S. H. Rosenkilde
> wrote
Hi Panos
In GF(p) then an element g is primitive if its embedding into ZZ is
coprime with p-1. Since Euclidean algorithm is so fast, you can test
this:
sage: p = Primes().next(2^2048) #long
sage: g1 = 3
sage: gcd(g1, p-1)
3
sage: g2 = 5
sage: gcd(g2, p-1)
1
So 3 is not a primitive element in GF(
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).
>
> Vincent
>
> On 11/05/2017 08:45, Johan S. H. Rosenkilde wrote:
>> Hi Panos
>>
>> In GF(p) the
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.
>
> John Cremona
>
>>
>> For very large p such as what you asked for is likely to be delicate (but I
>> am not a specialist).
>>
&g
ithm
where the currently best known codes are applied all known modifiers.
The same is true for the lower and upper bounds of Brouwer's tables.
> IMHO much more urgent project than redoing from scratch what already is
> there.
You pointedly keep missing my point, but oh well...
Best,
Hi Juan
You can just compute it from the result:
sage: H = random_matrix(GF(2), 15, 20)
sage: S = H.echelon_form(transformation=True)
sage: full_rank_submatrix = H.matrix_from_columns(S.pivots())
sage: U = full_rank_submatrix.inverse()
sage: U*H == S
True
Note: this only works if m has full row
Hi Christian,
The most inefficient part of _matrix_to_digraph seems to be the
following line:
> x = edge_labels.index((a,b))
which runs in linear time on the length of edge_labels. If all the pairs
(a,b) are different on your input matrix, that gives an n^3 running time
for t
Hi,
It is not related to exponentiation; it is due to the difference between
symbolic evaluation and real-valued evaluation when dividing by zero.
Real-valued arithmetic mirrors the IEEE floating point standard, I expect:
sage: 1.0/0
+infinity
While symbolic evaluation gives the divide-by-zero
13 matches
Mail list logo
