Hello,
The bug is caused by FreeModule_generic._mul_():
Cool! You got the bug. Did you opened a ticket? If you do so, please cc'me.
This is now http://trac.sagemath.org/ticket/17705
Pete
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To
Hello,
The bug is caused by FreeModule_generic._mul_():
def _mul_(self, other, switch_sides=False):
if switch_sides:
return self.span([v * other for v in self.basis()])
return self.span([other * v for v in self.basis()])
It looks like the effect of the switch_sides flag is
Hello,
In the latest version of sage 6.4.1 the following code failed.
I didn't have any problem with 6.2 version of sage.
[...]
Sage failed to compute the canonical height.
any ideas?
This computation is actually done by PARI; this was upgraded between
versions 6.2 and 6.4.1. The
It seems to be a precision issue; the error disappears when increasing the
precision.
From within Sage:
sage: point.height(precision=200)
242.47010035195076100129810400142304776375572634483556206582
Or directly in PARI:
gp \p 100
realprecision = 115 significant digits (100 digits
I reported this bug to the PARI developers.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send
Op vrijdag 21 november 2014 04:34:44 UTC+1 schreef Nils Bruin:
On Thursday, November 20, 2014 7:10:15 PM UTC-8, Bozh wrote:
Are these warnings signs that maxima is still compiling itself every time
I started?
It looks like Peter correctly identified the problem. According to his
Op dinsdag 18 november 2014 04:07:56 UTC+1 schreef Nils Bruin:
On Monday, November 17, 2014 5:49:14 PM UTC-8, Bozh wrote:
;;; (RUN-PROGRAM gcc (-I. -I/Applications/sage/local/lib/ecl/
-I/Users/buildslave-sage/slave/sage_git/build/local/include
Op donderdag 20 november 2014 21:07:55 UTC+1 schreef Nils Bruin:
On Thursday, November 20, 2014 4:36:52 AM UTC-8, Peter Bruin wrote:
It could be caused by the following lines in the Maxima source code (in
src/commac.lisp):
(defparameter trailing-zeros-regex-f-0 (compile nil
(maxima
Hello,
This appears to be a bug in the evaluation of the incomplete Gamma function
in the older PARI version(s) used by Sage up to and including 6.3. The
computation is correct in the newly released Sage 6.4, which uses the
recent stable PARI release 2.7.1.
(See also
Hello,
Somebody just complained about this on gitter
(https://gitter.im/sagemath/cloud):
The simplify command is completely ignoring that the variable is
supposed to be complex:
```
t = var('t', domain='complex')
(conjugate(t)*t).simplify()
```
outputs `t^2`. This
Hello,
I want to do some symbolic operations (matrix/vector) in the GF(2).
Here is an alternative approach (assuming all your expressions are
polynomials in m1, m2, m3 and m4):
sage: R.m1,m2,m3,m4 = PolynomialRing(GF(2))
sage: q = Matrix(R, [[m1, m2], [m3, m4]])
sage: q
[m1 m2]
[m3 m4]
sage:
Hello,
Let be the field
q = 2
K.t = GF(q^n)
and the Polynomial Ring
PR = PolynomialRing(K,X)
Let be a random monomial of PR for example
P = t*X^(q^a).
Is there any method in sage to reduce X degree of polynomial P, such that
equivalent polynomial is t*X^(q^b) where b =
Hello Robert,
Hmm, what method does PARI/GP use? The documentation for intnum
doesn't seem to mention any algorithms. ... I just looked at the
source code (intnum.c) and I can't tell what's going on. There is
some code for Romberg's method (intnumromb) but it's not called from
intnum
Hello,
I seem to have run across a potential bug on Sage:
p = previous_prime(2^64)
F.x = GF(p^2)
x * 2**63
throws a overflow in t_INT--long assignment exception creating the
element x * 2**63.
This is indeed a bug. Sage calls the wrong PARI function for this
conversion: it should
Hello,
It seems like quotient_ring doesn't have '__call__'. Does it a bug or a
feature?
sage: K = GF(2^8,'a')
sage: P = PolynomialRing(K,'x')
sage: Q = P.quotient_ring(P(x^256+x),'y')
sage: f = Q.random_element()
sage: f.subs(y=K.random_element()) # random
(a^7 + a^6 + a^3 + a)*y^255 +
Hello,
However, I seem to be having trouble with the incomplete gamma function.
Here are two difficulties. First, in trying to evaluate the incomplete
gamma function at a point where the result should be very small, I just
get
zero even if I increase the precision arbitrarily. In
This is in fact a long-standing bug, reported here:
http://trac.sagemath.org/ticket/7099 (serious incomplete gamma function
precision bugs)
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving
Correction: it is not exactly the same bug, but the two are certainly
related.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
are discovering that the ability of Sage to work
with relative extensions of finite fields is not as good as it should
be. There has been fairly recent work on this, and maybe Peter Bruin
knows what stage that has reached.
John
On Thursday, April 24, 2014 11:33:52 PM UTC+2, Peter Bruin wrote
Can you post a complete example? The following (simple) example works for
me (at least in 6.2.beta8):
sage: F=GF(5).extension(2)
sage: A1.y=F.extension(x^2+3)
sage: A2.z=F.extension(x^2+3)
sage: A1.hom([z],A2)
Ring morphism:
From: Univariate Quotient Polynomial Ring in y over Finite Field in
A certain amount of work on adding functionality for hyperbolic geometry to
Sage has been done in recent years, see here:
http://trac.sagemath.org/ticket/9439
There seem to be several different implementations by different authors; I
am not sure about the status of all this work and how much
Hello,
I want to define a polynomial that I know lies in GF(p^2,'b')[x],
p=371. The problem is that I have to define it as a product
E=(X-a_1)*(X-a_2)*(X-a_3)*(X-a_4)*(X-a_5)*(X-a_6), where every a_j is in
GF(p^13,'a')[X].
I tried to do GF(p^2,'b')[x](E), but then Sage just changes the
This works for me in Sage 5.13 (I don't have an older version installed),
after replacing the definition of FFps by
FFps.X=PolynomialRing(Fps) # the .X was missing
However, without the .X the error I got was different from yours
(TypeError: You must specify the names of the variables.)
Op
Hello,
I'm also a git beginner, so the experts should correct me if there is a
better way, but what I normally do in such situations is
$ git stash
$ git pull git://trac.sagemath.org/sage.git develop
$ git stash pop
Since you say your change is just one line, this is probably the
least-effort
Hello,
Sage only supports equations where the coefficients of y^2 and x^3 are 1;
you first need to multiply the equation by A^2 and then put A*y = Y and A*x
= X, so the equation becomes
Y^2 = X^3 + B*X^2 + A*C*X + A^2*D
You can construct this (assuming A, B, C, D are set to suitable values)
Dear Bhavin,
Thank you very much for your answer. It helps but still I do not know how
to see the answer to my exact problem.
My exact problem is the see the graph of y^2=x(x+1)(2*x+1)/6.
If you have constructed an elliptic curve (after scaling the variables),
say E, then you can do
sage:
Bonjour,
Il est malheureusement un peu problématique de construire des tours
(extensions successives) de corps. Sage sait bien vérifier que votre F6
est un corps, mais F6 est toujours représenté comme anneau quotient et
non comme corps fini ; c'est pourquoi certaines opérations naturelles ne
Hello,
I am working on a Z80 project and I needed 72 bits of precision for 64
elements of the form log2(1+2^-i) (so log2(3/2), log2(5/4),...). I
needed to convert these to hexadecimal, and it worked until I tried
the following for i=56:
int(256*log(1+2^-56,2))
This returns 1, when in fact
It is not a bug, but a consequence of a different convention. In Sage,
nullity means left nullity, i.e. the dimension of the left kernel. In this
example, m.nullity() + m.rank() = m.nrows(). For the more common right
nullity (resp. kernel), use m.right_nullity() (resp. m.right_kernel())
Hi Dima,
Is there something wrong in documentation regarding them?
Possibly: the documentation of m.nullity() says
Return the (left) nullity of this matrix, which is the dimension of
the (left) kernel of this matrix acting from the right on row
vectors.
This should probably be acting from
Hello John,
Surely not? For the left nullity the vectors are row vectors on the
left, but the matrix is acting on the right (unless I got out of bed
on the wrong side this norming).
Yes, I now realise that I read the phrase in a left-associative way,
interpreting kernel of this matrix
Hello Tristan,
n = 100; d=3
load DATA+'my_functions.py'
coefficients = poly_expand(n,int(n**(1/d)),d)
R.t,s = ZZ[]
f = 0
for c in coefficients:
f += c*t^d
d -= 1
g = f.homogenize('s')
Running this returns AttributeError: 'GlobalPolynomialRing' object has no
attribute
Hello,
I'm a bit confused about Sage's answer if Ideal(1) is prime.
R.x,y= QQ[]
I = Ideal(R(1))
I.is_prime()
Sage (5.11, not only) says yes,
conflicting to the definition,
http://en.wikipedia.org/wiki/Prime_ideal
Has somebody an expanation of this behaviour?
The example Singular
Hello,
I've been using Sage's hyperbolic_triangle function quite a lot to produce
a few pictures. I'm very happy with them, but I was also wondering whether
Sage could handle the disc model for hyperbolic triangles... Only the
upper half-plane model seems to be available, but I may be
The problem is indeed fixed by applying #13951 (which still needs
reviewing).
Peter
Op vrijdag 8 november 2013 17:35:01 UTC schreef John Cremona:
On 8 November 2013 16:11, Georgi Guninski guni...@guninski.comjavascript:
wrote:
I am not an expert, but is it normal to get negative
The results of all GP command are stored in an array named 'sage' inside
GP. If you execute too many commands, this array apparently isn't enlarged
anymore. I suspect that this is because GP runs out of stack space and
that Sage's GP interface does not notice this.
I don't see a quick and
Op vrijdag 22 november 2013 18:48:27 UTC schreef Nils Bruin:
On Friday, November 22, 2013 10:26:52 AM UTC-8, Peter Bruin wrote:
The results of all GP command are stored in an array named 'sage' inside
GP. If you execute too many commands, this array apparently isn't enlarged
anymore. I
To partially solve the above bug, we should make sure doubling of the
sage array works when an allocatemem() has to be done; this seems to be
broken, and I just opened a ticket for it (#15446). It is only a partial
fix because doing GP calculations still leaks memory.
I also opened
271). The method __compute_general_case of the
class EisensteinSeries in modular/modform/element.py reproduces this
formula in the form
v.append(sum([psi(n)*chi(m/n)*n**(k-1) for n in rings.divisors(m)]))
Here psi should be ~psi.
Thanks,
Peter Bruin
39 matches
Mail list logo
