On Nov 14, 2011, at 18:04 , Dan Drake wrote:
> This is not fun:
>
> sage: from sage.rings.complex_number import ComplexNumber as CN
> sage: parent(1+I)
> Symbolic Ring
> sage: coerce(CN, 1+I)
> BOOM
>
> (with 4.8.alpha1 and 4.7.2 in 64-bit Linux)
>
> It looks like mpfr is extremely unhappy ab
On Tuesday, 15 November 2011 13:14:09 UTC+8, Dan Drake wrote:
>
> On Mon, 14 Nov 2011 at 08:11PM -0600, Jason Grout wrote:
> > It looks like something bad happens also on 4.7. At least, when I
> > try on demo.sagenb.org (running 4.7 currently), after I do the
> > coerce statement above, it appea
On Mon, 14 Nov 2011 at 08:11PM -0600, Jason Grout wrote:
> It looks like something bad happens also on 4.7. At least, when I
> try on demo.sagenb.org (running 4.7 currently), after I do the
> coerce statement above, it appears that the worksheet is abruptly
> reset and CN is no longer defined.
I
On 11/14/11 8:04 PM, Dan Drake wrote:
This is not fun:
sage: from sage.rings.complex_number import ComplexNumber as CN
sage: parent(1+I)
Symbolic Ring
sage: coerce(CN, 1+I)
BOOM
(with 4.8.alpha1 and 4.7.2 in 64-bit Linux)
It looks like mpfr is extremely unhappy about something.
Also, if I jus
This is not fun:
sage: from sage.rings.complex_number import ComplexNumber as CN
sage: parent(1+I)
Symbolic Ring
sage: coerce(CN, 1+I)
BOOM
(with 4.8.alpha1 and 4.7.2 in 64-bit Linux)
It looks like mpfr is extremely unhappy about something.
Also, if I just use the regular ComplexNumber in the
Hi all:
I'd like to extend Sage's partial fraction decomposition function in
the QuotientField class to a function that works on quotients of
*multivariate* polynomials. To this end, i've found it convenient to
store a rational expression $F = P/(Q_1^{e_1} \cdots Q_m^{e_m})$ as a
Python list of th
On Mon, Nov 14, 2011 at 1:13 PM, Tom Boothby wrote:
> I'll doctest polynomial_compiled this week, since it's 100% my fault.
Excellent. I've made a ticket for you at
http://trac.sagemath.org/sage_trac/ticket/12033
and added a link from
http://trac.sagemath.org/sage_trac/ticket/12024
I t
On Mon, Nov 14, 2011 at 03:15:41PM -0800, Simon King wrote:
> Hi Florent,
>
> On 15 Nov., 00:05, Florent Hivert wrote:
> > For the record, I think I answered all of this on #12029.
>
> Your code seems to work, but you didn't answer my question. Since the
> only difference to my code is your use
On Mon, Nov 14, 2011 at 03:07:29PM -0800, Simon King wrote:
> On 14 Nov., 23:54, Simon King wrote:
> > But why am I still getting segfaults with the following code,
> > where I manually add a reference?
> > cdef int i, o
> > cdef list L = PyList_New(self._len)
> > for i fr
Hi Florent,
On 15 Nov., 00:05, Florent Hivert wrote:
> For the record, I think I answered all of this on #12029.
Your code seems to work, but you didn't answer my question. Since the
only difference to my code is your use of PyInt_FromLong, I don't see
yet why it works, while my code doesn't.
On 14 Nov., 23:54, Simon King wrote:
> But why am I still getting segfaults with the following code,
> where I manually add a reference?
> cdef int i, o
> cdef list L = PyList_New(self._len)
> for i from 0<=i o = self._list[i]
> Py_INCREF(o)
>
On Mon, Nov 14, 2011 at 02:54:19PM -0800, Simon King wrote:
> Hi!
>
> I am sure that the following problem has a solution that is well-known
> - but not well-known to me, and also I did not succeed in googling it.
>
> Background is #12029.
>
> In the following, self is a ClonableIntArray, but I
Hi!
I am sure that the following problem has a solution that is well-known
- but not well-known to me, and also I did not succeed in googling it.
Background is #12029.
In the following, self is a ClonableIntArray, but I guess the problem
is more general. self._list is some "int *" array of known
I'll doctest polynomial_compiled this week, since it's 100% my fault.
On Sun, Nov 13, 2011 at 12:41 PM, William Stein wrote:
> Hi Sage Developers,
> After deleting the server directory we need to add doctests to
> about588 more functions to get coverage to 90%, which is a major goal
> forsage-5.0
The documentation of find_maximum_on_interval shows this is a
numerical function that is not prepared to take symbolic expressions.
However, the error message is deplorable. Ticket:
http://trac.sagemath.org/sage_trac/ticket/12032
--
To post to this group, send an email to sage-devel@googlegroups
On 2011-11-13 02:52, John H Palmieri wrote:
> This file should be deleted. It is a remnant of a failed attempt to
> merge trac #21, and somehow the file never got removed when the patch
> was backed out.
I'm taking this as a positive_review to
http://trac.sagemath.org/sage_trac/ticket/12031
--
On 11/14/11 8:44 AM, David Roe wrote:
I think I'd describe it as a feature to reduce the number of GF(7)s
floating around. There's no coercion from ZZ[x] to GF(p), regardless
of the choice of modulus. The modulus function on
FiniteField_prime_modn is there for consistency of interface with the
I think I'd describe it as a feature to reduce the number of GF(7)s
floating around. There's no coercion from ZZ[x] to GF(p), regardless
of the choice of modulus. The modulus function on
FiniteField_prime_modn is there for consistency of interface with the
other finite fields. Is there a reason
I find that this is not coherent with documentation of Finite Field.
"""
sage: G=GF(7,'a',modulus=QQ[x](x+2))
sage: G.modulus()
x + 6
sage: G.variable_name()
'x'
sage: G.polynomial_ring().hom([G.gen()])
Ring morphism:
From: Univariate Polynomial Ring in x over Finite Field of size 7
To: Fini
About the failing test
sage -t -force_lib "devel/sage/sage/graphs/digraph.py" # Killed/
crashed
I ran the test again with -verbose
I think its connected to the routine dcycle.feedback_edge_set (in line
1252) and maybe its an integer / floating error
Trying:
cycle.size()###line 1338:_sage_
On it.
-Keshav
Join us in #sagemath on irc.freenode.net !
--
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/sa
> We should change the doctest to execute "rm -rf /" instead. This will also
> provide a valuable lesson for people that use privileged accounts for
> everything :-)
Not to mention that all free softwares are distributed with the
warning "You use this code at your own risk" and that we never had
On Sunday, November 13, 2011 3:05:32 PM UTC+1, Emil Widmann wrote:
>
> I checked that the directory was created and the permissions were set
> to correctly.
> Is this critical or can it be fixed with some sort of setting?
>
> EDIT: I found the culprit - I ran doctest as root.
> If I run th
23 matches
Mail list logo
