{5} Assigned, Active Tickets by Owner (Full Description) (135 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
AlexGhitza
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4218 | Extensions of Finite Fields don't work well | algebra | sage-3.2 | defect | 09/29/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The following sage snippets show (some of) the problems. First, we set the stage: sage: F1.<a> = GF(2^7) sage: P1.<x>=PolynomialRing(F1) sage: f=x^2+x+F1(1) sage: F2=F1.extension(f,'u') sage: F2 Univariate Quotient Polynomial Ring in u over Finite Field in a of size 2^7 with modulus u^2 + u + 1 sage: a in F2 True First problem: sage: for i in xrange(100): ....: r = F2.random_element() ....: if r != F2(0) and r != F2(1): ....: print "Yoicks! r=%s"%r ....: sage: No output means that 100 random elements of F2 are either 0 or 1, which seems somehow incorrect. The next oddity is sage: F1.order() 128 sage: F2.order() --------------------------------------------------------------------------- NotImplementedError Traceback (most recent call last) /SandBox/Justin/sb/sage-3.1.1/<ipython console> in <module>() /SandBox/Justin/sb/sage-3.1.1/ring.pyx in sage.rings.ring.Ring.order (sage/rings/ring.c:4108)() NotImplementedError: Shouldn't .order() work for extensions as well as those directly defined? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4246 | [with patch, needs work] bug in coercing symbolic expressions to polynomial rings | calculus | sage-3.2 | defect | 10/05/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This was reported by William Stein at #4106:
sage: var('x')
x
sage: var('y')
y
sage: S = PolynomialRing(Integers(4),1,'x')
sage: S(x+y)
2*x
sage: (x+y)._polynomial_(S)
2*x
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TimothyClemans
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3849 | [with patch, do not review] notebook -- Internal Server Error given when input to File upload or Data attachment is invalid | notebook | sage-3.2 | defect | 08/14/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
(1) In Google Docs if one fills in both "Browse your computer ..." and "Or enter the url of a ...", the server just deals with the first input box. The Notebook instead deals with the second. Do what Google does. (2) Google uses JavaScript? alert boxes to report errors. The Notebook just gives a "Internal Server Error." The Notebook should do inline error reporting just as is done on the Registration page. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3525 | [with patches, don't review] notebook -- new welcome page | notebook | sage-3.2 | enhancement | 06/27/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Take the static page at http://timothyclemans.com/nb_homepage/ and merge it into the Sage Notebook code. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3619 | [with patch, needs work] notebook -- record date & time each user logs in | notebook | sage-3.2 | enhancement | 07/08/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3463 | [with patch, not ready for review] notebook -- create a resource folder and move AnonymousToplevel to it | notebook | sage-3.2 | task | 06/18/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is a first step in making the Notebook code more modular like Knoboo's. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #338 | In doc browser make hyper links to referenced code in SAGE library | notebook | sage-feature | enhancement | 03/31/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
For example: On page http://sagenb.com/doc_browser?/const/?node72.html, reference to sage/modular/dims.py would be a hyper link to the actual code. On page http://sagenb.com/doc_browser?/prog/?node15.html, reference to SAGE_ROOT/devel/sage/sage/graphs/graph.py would be a hyper link to the actual code. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
anakha
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4164 | [with patch, needs review] Make triangulated_facial_incidences() work in all cases | graphics | sage-3.2 | defect | 09/21/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The attached patch switches from random lifting to the fan algorithm for triangularization which work in all cases and should work with all dimensions. I left some safeguard code in there just in case I made assumptions that aren't always true (or have some bugs). For the record the assumptions are:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
anovocin
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4283 | [with proto-patch] A Speed-up Patch for NTL's ZZXFactoring.c | factorization | sage-3.2 | enhancement | 10/14/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The goal of this patch is to speed-up NTL's factoring algorithm for polynomials in Z[X]. The speed-up comes from using fpLLL rather than NTL's native LLL algorithm. We do this by converting a ZZ_mat of ZZ's (NTL's multi-precision integers) and passing them into a mat_ZZ<mpz_t> matrix of mpz_t's (fpLLL's native format). Then run fpLLL on the new matrix and pass the entries back to NTL. I don't replace NTL's LLL just pass what should be an already reduced basis to NTL's LLL. (NTL computes extra information that would require a hack into fpLLL to get and might not be worth it.) This patch allows NTL to beat MAGMA on many examples (it still is a little slower than MAGMA (but faster than SAGE) on irreducible polynomials). I think that the cross over between Pari's factoring and NTL's factoring should be re-evaluated (currently Pari is used for polynomials of degree 30 through 300) if not just use NTL for all polynomials now. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
burcin
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1611 | polybori should use the m4ri library from libm4ri spkg | packages | sage-3.2 | enhancement | 12/27/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PolyBoRi? comes with its own copy of m4ri libraries. After #1505, Sage provides these libraries through a package. The PolyBoRi? build process should be changed to use the library and headers provided by libm4ri-*.spkg. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
cpernet
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4260 | use LinBox as native matrix representation for dense matrices over GF(p) | linear algebra | sage-3.2 | enhancement | 10/10/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Copying to and from LinBox? uses up precious RAM and the point of fast linear algebra is to deal with large matrices. We should consider switching to LinBox? as the native representation of matrices over GF(p) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
craigcitro
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2535 | [with patch, needs work] Problem with cuspidal_subspace and new_subspace for modular symbols | modular forms | sage-3.2 | defect | 03/15/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
There's some error with plus_submodule and cuspidal_submodule not being "commutative." Here's an example: sage: M = ModularSymbols(11,2)
sage: Mpc = M.plus_submodule().cuspidal_submodule()
sage: Mcp = M.cuspidal_submodule().plus_submodule()
sage: Mcp.q_expansion_basis(10)
[
q - 2*q^2 - q^3 + 2*q^4 + q^5 + 2*q^6 - 2*q^7 - 2*q^9 + O(q^10)
]
sage: Mpc.q_expansion_basis(10)
---------------------------------------------------------------------------
<type 'exceptions.RuntimeError'> Traceback (most recent call last)
/Users/craigcitro/<ipython console> in <module>()
/sage/local/lib/python2.5/site-packages/sage/modular/modsym/space.py in q_expansion_basis(self, prec, algorithm)
458 algorithm = 'hecke'
459 if algorithm == 'hecke':
--> 460 return Sequence(self._q_expansion_basis_hecke_dual(prec), cr=True)
461 elif algorithm == 'eigen':
462 return Sequence(self._q_expansion_basis_eigen(prec), cr=True)
/sage/local/lib/python2.5/site-packages/sage/modular/modsym/space.py in _q_expansion_basis_hecke_dual(self, prec)
913 t = misc.verbose('computing basis to precision %s'%prec)
914 while V.dimension() < d and i >= 0:
--> 915 v = [self.dual_hecke_matrix(n).column(i) for n in range(1,prec)]
916 t = misc.verbose('iteration: %s'%j,t)
917 X = M(v).transpose()
/sage/local/lib/python2.5/site-packages/sage/modular/hecke/module.py in dual_hecke_matrix(self, n)
725 self._dual_hecke_matrices = {}
726 if not self._dual_hecke_matrices.has_key(n):
--> 727 T = self._compute_dual_hecke_matrix(n)
728 self._dual_hecke_matrices[n] = T
729 return self._dual_hecke_matrices[n]
/sage/local/lib/python2.5/site-packages/sage/modular/hecke/submodule.py in _compute_dual_hecke_matrix(self, n)
108 A = self.ambient_hecke_module().dual_hecke_matrix(n)
109 check = arith.gcd(self.level(), n) != 1
--> 110 return A.restrict(self.dual_free_module(), check=check)
111
112 def _compute_hecke_matrix(self, n):
/sage/local/lib/python2.5/site-packages/sage/modular/hecke/submodule.py in dual_free_module(self, bound, anemic)
295 # failed
296 raise RuntimeError, "Computation of embedded dual vector space failed " + \
--> 297 "(cut down to rank %s, but should have cut down to rank %s)."%(V.rank(), self.rank())
298
299
<type 'exceptions.RuntimeError'>: Computation of embedded dual vector space failed (cut down to rank 2, but should have cut down to rank 1).
I'll look at this soon. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #812 | add Pollack/Stevens overconvergent modular symbols code | modular forms | sage-feature | enhancement | 10/03/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm just starting to work on implementing Pollack & Stevens' methods for using overconvergent modular symbols for p-adic L-functions, Stark-Heegner points, etc. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #685 | Make Eisenstein series code handle eisenstein series with character | modular forms | sage-3.2 | enhancement | 09/17/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The eisenstein_series_qexp function currently only handles eisenstein series for level 1. It wouldn't be hard to make this handle eisenstein series for higher level and with character. I'm going to take care of this soon, but this is here in case I forget. ;) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #864 | Asymptotically slow pari <--> python long conversions | interfaces | sage-3.2 | enhancement | 10/12/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is really a leftover from ticket #467, split because I wanted the first half of the fix to make it into 2.8.7. Here's a summary of the badness: sage: x = 10^100000 sage: time y = pari(x) CPU times: user 1.18 s, sys: 0.01 s, total: 1.19 s Wall time: 1.26 sage: time z = Integer(y) CPU times: user 0.00 s, sys: 0.00 s, total: 0.01 s Wall time: 0.02 sage: time u = int(y) CPU times: user 1.94 s, sys: 1.33 s, total: 3.27 s Wall time: 3.58 sage: time u = int(Integer(y)) CPU times: user 0.00 s, sys: 0.00 s, total: 0.01 s Wall time: 0.03 sage: x = 10^1000000 sage: time y = pari(x) CPU times: user 105.12 s, sys: 1.26 s, total: 106.38 s Wall time: 121.86 sage: time z = Integer(y) CPU times: user 0.03 s, sys: 0.02 s, total: 0.05 s Wall time: 0.09 sage: time u = int(y) CPU times: user 188.17 s, sys: 145.12 s, total: 333.28 s Wall time: 364.80 sage: time u = int(Integer(y)) CPU times: user 0.04 s, sys: 0.02 s, total: 0.06 s Wall time: 0.07 And here's the state of affairs after the first patch: sage: x = 10^100000 sage: time y = pari(x) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 sage: time z = Integer(y) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 sage: time u = int(y) CPU times: user 1.64 s, sys: 1.09 s, total: 2.73 s Wall time: 2.79 sage: time u = int(Integer(y)) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 sage: x = 10^1000000 sage: time y = pari(x) CPU times: user 0.00 s, sys: 0.00 s, total: 0.01 s Wall time: 0.01 sage: time z = Integer(y) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 sage: time u = int(y) CPU times: user 220.90 s, sys: 137.34 s, total: 358.24 s Wall time: 408.11 sage: time u = int(Integer(y)) CPU times: user 0.00 s, sys: 0.00 s, total: 0.01 s Wall time: 0.01 Clearly that third function call needs to be fixed, and it will be within a few days. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1770 | Make fast pari <--> p-adic conversions for fixedmod and capped-abs types | interfaces | sage-3.2 | enhancement | 01/13/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I already wrote the corresponding code for capped-rel elements, and it should be done for these other types. I'm assigning this to myself for now, but if anyone wants to do this, it's pretty easy -- you could mostly copy what I did in the capped-rel case, and do this with essentially no knowledge of how the pari stuff works. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2329 | [with patch, pending another patch] add interface to Pari's rnfisnorm | number theory | sage-3.2 | enhancement | 02/27/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This patch adds support to solve norm equations via Pari. Quick summary: given an element x of any number field (even QQ), x.is_norm(L) will return False if x is not a norm from L, and if x is a norm from L, will return an element of L whose norm is x. According to the Pari documentation, these functions depend on GRH when L/K is not known to be Galois, and work independent of any such hypothesis otherwise (at least, that's what I got from reading the Pari manual). The data used by Pari to compute whether or not an element is a norm can be computed once for each extension L/K. The function pari_rnfnorm_data computes exactly this, and its result can be passed to is_norm to avoid recomputing it each time in the case that K != QQ. If K is QQ, there is no need to save any such data -- the only data needed is that of K.pari_bnf(), which is used instead, and is already cached by K. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
cswiercz
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3621 | [with patch, needs review] sage.finance - add expand and refine finance.Stock | finance | sage-3.2 | defect | 07/08/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
There was an issue with Stock.historical() only returning stock information from Jan 1, 1990 onward and no earlier. The addition of an explicit enddate to the Google Finance query seems to fix this. Fix is demonstrated in the doctests of Stock.historical() Uses the datetime.date python module. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3573 | [with patch, with spkg, needs review] finance - Implementation of Sage interface to opentick | finance | sage-feature | enhancement | 07/06/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
opentick is a collection of APIs for obtaining free real-time and historical market data for trading systems and trading platforms. With these APIs, we will enable Sage to be able to stream and manipulate real-time market data. This ticket depends on #3621. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4083 | [with patch, needs review] sage.finance - Options pricing implementation | finance | sage-3.2 | enhancement | 09/08/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Includes capabilities for options pricing using the Black-Scholes model. The primary class of this ticket is finance.Option, which uses finance.Stock. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2507 | [with patch; needs work] Docstrings and Doctests for rings/quotient_ring_element.py | doctest | sage-3.2 | defect | 03/13/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current coverage in Sage 2.10.3: SCORE quotient_ring_element.py: 3% (1 of 27) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
cwitty
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1365 | golden_ratio._algebraic_() should synthesize the value | algebraic geometry | sage-3.2 | enhancement | 12/01/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Robert Bradshaw points out that golden_ratio._algebraic_ might as well synthesize the value, instead of using a special-purpose function in qqbar.py (and there's a patch to do this as part of Robert's patch at #1275). But I want to make qqbar.py a bit more efficient for that case, before making the change. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
davidloeffler
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4190 | [with patch, needs work] division of number field order elements doesn't check for membership | number theory | sage-3.2 | defect | 09/24/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I think this just about says it all: sage: OK = NumberField(x^2 - x + 2, 'w').ring_of_integers() sage: w = OK.ring_generators()[0] sage: 1/w in OK True I tested this for cubic fields as well, and the same problem comes up. I can't work out why this happens -- it must be something weird in the coercion framework, as there isn't a specific method for division or inversion of elements of orders: it falls back to NumberFieldElement?.invert and then somehow coerces the result back to an OrderElement? without doing any checks along the way. I discovered this when trying to find out whether one element of OK was divisible by another -- "x.divides(y)" raises an error, and "y/x in OK" always returns True, which isn't very helpful; the best I could find was "y in x*OK" which seems to give the right results. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3959 | [with patch, positive review] General group algebras class | algebra | sage-3.2 | enhancement | 08/26/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've attempted to write a generic class for group algebras R[G] where R is any commutative ring and G is any group; it derives from the existing Algebra class, and most of the work is done by the existing FormalSums class. In the process I've uncovered a bizarre coercion wrinkle: if we try and make elements of R and elements of G coerce into R[G] automatically, it breaks, because (for example) 2 might coerce into G (e.g. if G = GL(n, ZZ)) and the compositions of the obvious maps ZZ -> G -> R[G] and ZZ -> R -> R[G] aren't the same! [*] I've got around this by not adding automatic coercion from G to R[G], but I'm not sure if this is the right thing. In fact I'd very much appreciate any input on whether or not I've understood Sage's coercion framework and other "house rules" generally, as this is my first attempt to contribute anything where that's relevant. Note: this is rather orthogonal to David Joyner's PermutationGroupRing class deriving from CombinatorialAlgebra -- what I'm trying to do is much more general but has almost no methods, and PermutationGroupRing might work well as a subclass of my general GroupAlgebra. ([*] I seem to recall mentioning this as a theoretical example in a discussion at Sage Days 6, but I can't remember what came of it at the time.) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3934 | [with patches; under review by Ken McMurdy] Eta product modular functions | modular forms | sage-feature | enhancement | 08/23/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
At the Heilbronn Institute workshop "Computations with Modular Forms", Ken McMurdy requested code for handling eta products on X_0(N). Theory background and wish-list here: http://maths.pratum.net/CMF/resources/McMurdyTalk.pdf. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
gfurnish
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2452 | heaviside step function needed | calculus | sage-3.2 | enhancement | 03/10/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Symbolic heaviside step function is needed for ease of plotting. Right now you must sage: def u(x):
if(x<0):
return 0
else:
return 1*cos(x)
sage: plot(u,-5,5)
instead of plot(heaviside(t)*cos(t),t,-5,5) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #385 | implement at for symbolics | calculus | sage-3.2 | defect | 06/07/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
On 6/7/07, Randy LeVeque <rjl@amath.washington.edu> wrote:
> By the way, I'm just trying to figure out how sage does Taylor series.
> Maybe you can pass this on to whoever the best person is to chat with about
> this...
>
> In maple I can do things like
>
> > mtaylor(u(x+h,t+k),[h,k],3);
> 2
> u(x, t) + D[1](u)(x, t) h + D[2](u)(x, t) k + 1/2 D[1, 1](u)(x, t) h
>
> 2
> + h D[1, 2](u)(x, t) k + 1/2 D[2, 2](u)(x, t) k
>
>
> which is very convenient for numerical analysis when computing truncation
> errors of finite difference methods (h and k are mesh widths in space and
> time). In sage a general expansion of this sort doesn't seem possible even
> in a single variable, e.g.,
>
> sage: taylor(u(x+h),h,0,4)
> x + h
>
> Apparently an undefined function like u(x) is taken to be the identity map?
To define a formal function, do u = function('u'). Then
sage: u = function('u')
sage: u(x + h)
u(x + h)
sage: diff(u(x+h), x)
diff(u(x + h), x, 1)
To get the Taylor expansion you would do this:
sage: taylor(u(x+h),h,0,4)
-- however -- this currently doesn't work in SAGE since we hadn't considered
doing this yet. What happens is Maxima does the computation and outputs
the following expression:
'u(x)+(?%at('diff('u(x+h),h,1),h=0))*h+(?%at('diff('u(x+h),h,2),h=0))*h^2/2+(?%at('diff('u(x+h),h,3),h=0))*h^3/6+(?%at('diff('u(x+h),h,4),h=0))*h^4/24
SAGE doesn't know yet how to parse the "at" function, so you get
an error -- it will have to be added. [Note that I don't necessarily consider
maxima the ultimate underlying engine for SAGE's symbolic computation
capabilities -- but it does provide a very quick way for SAGE to have
a powerful symbolic system for which a lot of subtle bugs have
already been fixed (over the last 40 years of Maxima development). ]
Definitely point out lots of things like this in your talk at SD4!
-- William
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #780 | calculus integration failing due to maxima interacting when it shouldn't | calculus | sage-3.2 | defect | 10/01/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi,
This is a quick and possibly not so useful answer.
(1) I think you're running into a bug in Maxima (hence Sage) below, since
your assumption should be passed through. It's pretty hard for us Sage
developers to fix bugs in Maxima, unfortunately. Nonetheless, we are
very thankful for the bug report.
(2) Possibly doing the following workaround would be OK for you, i.e.,
just compute the definite integral you want by computing an antiderivative
and use the fundamental theorem of calculus:
sage: x,y=var('x,y')
sage: f = log(x^2+y^2)
sage: integrate(f,x)
x*log(y^2 + x^2) - 2*(x - atan(x/y)*y)
sage: g = integrate(f,x)
sage: h = g(x=1.) - g(x=0.0001415); h # this is what you want.
1.00000000000000*log(y^2 + 1.00000000000000) - 0.0001415000000000000000*log(y^2 + 0.000000020022250000000000000000) - 2*(1.00000000000000 - atan(1.00000000000000/y)*y) + 2*(0.0001415000000000000000 - atan(0.0001415000000000000000/y)*y)
sage: h(y=5)
3.231596665591034
On 10/1/07, Eliz <elyip@comcast.net> wrote:
>
> Attached is the 'edit' view of my worksheet. When I changed the lower
> bound of the definite integral from 0.0001415 to 0.0001414, we got
> into trouble.
>
> Elizabeth
> ------------------------------------------------------------------------------------------------------------
> integration_exercise
> system:sage
>
> {{{id=0|
> x,y=var('x,y')
> f=log(x^2+y^2)
> integrate(f,x)
> ///
> x*log(y^2 + x^2) - 2*(x - atan(x/y)*y)
> }}}
>
> {{{id=11|
> assume(y^2>1)
> integrate(f,x,0.0001415,1.)
> ///
> 1.00000000000000*log(1.00000000000000*y^2 + 1.00000000000000) -
> 0.0001415000000000000000*log(1.00000000000000*y^2 +
> 0.000000020022250000000000000000) +
> 2.00000000000000*atan(1.00000000000000/y)*y -
> 2.00000000000000*atan(0.0001415000000000000000/y)*y - 1.99971700000000
> }}}
>
> {{{id=16|
> assume(y^2<1)
> integrate(f,x,0.0001415,1.)
> ///
> 1.00000000000000*log(1.00000000000000*y^2 + 1.00000000000000) -
> 0.0001415000000000000000*log(1.00000000000000*y^2 +
> 0.000000020022250000000000000000) +
> 2.00000000000000*atan(1.00000000000000/y)*y -
> 2.00000000000000*atan(0.0001415000000000000000/y)*y - 1.99971700000000
> }}}
>
> {{{id=17|
> assume(y^2==1)
> integrate(f,x,0.0001415,1.)
> ///
> 1.00000000000000*log(1.00000000000000*y^2 + 1.00000000000000) -
> 0.0001415000000000000000*log(1.00000000000000*y^2 +
> 0.000000020022250000000000000000) +
> 2.00000000000000*atan(1.00000000000000/y)*y -
> 2.00000000000000*atan(0.0001415000000000000000/y)*y - 1.99971700000000
> }}}
>
> {{{id=19|
> assume(y^2>1)
> integrate(f,x,0.0001414,1.)
> ///
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/home/yip/sage_notebook/worksheets/admin/10/code/47.py", line
> 5, in <module>
> exec
> compile(ur'integrate(f,x,RealNumber(\u00270.0001414\u0027),RealNumber(\u00271.\u0027))'
> + '\n', '', 'single')
> File "/local/sage-2.8.5.1/data/extcode/sage/", line 1, in <module>
>
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> calculus/functional.py", line 175, in integral
> return f.integral(*args, **kwds)
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> calculus/calculus.py", line 1652, in integral
> return self.parent()(self._maxima_().integrate(v, a, b))
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/maxima.py", line 1391, in integral
> return I(var, min, max)
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/expect.py", line 884, in __call__
> return self._obj.parent().function_call(self._name, [self._obj] +
> list(args))
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/expect.py", line 831, in function_call
> return self.new("%s(%s)"%(function, ",".join([s.name() for s in
> args])))
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/expect.py", line 733, in new
> return self(code)
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/maxima.py", line 376, in __call__
> return Expect.__call__(self, x)
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/expect.py", line 678, in __call__
> return cls(self, x)
> File "/local/sage-2.8.5.1/local/lib/python2.5/site-packages/sage/
> interfaces/expect.py", line 919, in __init__
> raise TypeError, x
> TypeError: Computation failed since Maxima requested additional
> constraints (use assume):
> Is (y-1)*(y+1) positive, negative, or zero?
> }}}
>
> {{{id=20|
>
> }}}
>
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1163 | assume seems to have some undesired side-effects | calculus | sage-3.2 | defect | 11/13/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sage: assume(x > 0) sage: sqrt(x^2) x sage: assume(x < 0) sage: sqrt(x^2) x Maybe it is not allowed to make two assumptions on the same variable, without any forget inbetween, anyway the documentation should be clear about this, or a warning should be issued. Also, is there a way to know which assumptions were made on a given variable (like about in Maple)? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1773 | piecewise functions and integration / arithmetic do not play well together | calculus | sage-3.2 | defect | 01/13/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
On 1/13/08, Hector Villafuerte <> wrote: > > I defined a piecewise function (specifically, a triangular wave) like this: > > sage: f1(x) = -abs(x) + 1 > sage: f2(x) = abs(x - 2) - 1 > sage: tri_wave = piecewise([ [(-1,1), f1], [(1,3), f2]]) > > One can plot it and it looks very nice: > > sage: tri_wave.plot() > > But while calculating this integral I get "ValueError: Value not > defined outside of domain." > > sage: integrate(tri_wave(x)^2, x, -1, 3) > > Is there a way to integrate piecewise-defined functions? > As always, thanks for your help, This is clearly broken. As a band-aide, you can at least numerically integrate as follows: sage: integral_numerical(lambda x: tri_wave(x)^2, -1, 3) (1.3333333333333333, 1.4765966227514582e-14) The first output (1.3333...) is the answer, and the second is an error bound. -- William |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2025 | bug in applying functions to a symbolic matrix | calculus | sage-3.2 | defect | 02/01/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note below that the stupid constant term of the taylor expansion inside the matrix keeps getting pushed off to the far right! sage: m = matrix(1,[-x/(2*x-4)]) sage: m.apply_map(lambda e: taylor(e,x,0,4)) [x^4/32 + x^3/16 + x^2/8 + x/4] sage: m.apply_map(lambda e: taylor(e,x,0,4)) [x^4/32 + x^3/16 + x^2/8 + x/4] sage: m.apply_map(lambda e: taylor(e,x,1,4)) [x + (x - 1)^4 + (x - 1)^3 + (x - 1)^2 - 1/2] sage: m.apply_map(lambda e: taylor(e,x,2,4)) [-1/(x - 2) - 1/2] sage: m.apply_map(lambda e: taylor(e,x,3,4)) [x - (x - 3)^4 + (x - 3)^3 - (x - 3)^2 - 9/2] sage: m[0,0].taylor(x,3,4) -3/2 + x - 3 - (x - 3)^2 + (x - 3)^3 - (x - 3)^4 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2071 | SymbolicExpression conjugate() method assumes variables are real | calculus | sage-3.2 | defect | 02/05/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sage: var('x')
x
sage: x.conjugate()
x
Under the assumption that x might be complex, this should really return conjugate(x). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2341 | vector subs over symbolic does not work | linear algebra | sage-3.2 | defect | 02/27/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ricardo Massaro to sage-devel
show details 8:28 PM (18 minutes ago)
Reply
Hello all,
First of all, I'd like to thank you for Sage, it's really helping me a
lot.
I found a strange behavior that i *think* it's a bug, but I'm not
sure, since I'm a completely newbie to Sage and Python:
sage: a = var('a')
sage: m = matrix(SR, 2, [a,a,a,a])
sage: v = vector(SR, 2, [a,a])
Then,
sage: m.subs(a=1)
[1 1]
[1 1]
but
sage: v.subs(a=1)
(a, a)
I *think* the problem is in the Element.subs() method in devel/sage/
sage/structure/element.pyx. It seems to assume that the generators are
symbols, which is not true in the example vector.
Am I missing something, or is it really a bug?
Here's a dirty fix that apparently fixes this problem, but will likely
beak something else:
def subs(self, in_dict=None, **kwds):
v = [a.subs(in_dict, **kwds) for a in self.list()]
return self.parent()(v)
Thanks,
Ricardo
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2785 | [with spkg, needs work] The glitelib ticket | packages | sage-3.2 | defect | 04/02/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is the ticket for the glitelib spkg. It requires an extcode patch. Obtain at http://sage.math.washington.edu/home/gfurnish/spkg/glitelib-2.15.6.spkg |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2930 | [with patch, needs work after coercion merge] CDF is slow, fix it. | basic arithmetic | sage-3.2 | defect | 04/14/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Add a CDF pool, optimize CD creation. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2662 | simplify_full function | calculus | sage-3.2 | enhancement | 03/24/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Create a simplify_full function that (somewhat intelligently?) applies a battery simplifications to try to get a function to be simpler. It would be nice to support some of the options that FullSimplify? in Mma has (see http://reference.wolfram.com/mathematica/ref/FullSimplify.html?q=fullsimplify&lang=en ):
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #22 | 32/64/32-bit building switch | build | sage-3.2 | enhancement | 09/12/2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Should there be something to keep people from building on 32-bit then 64-bit then 32-bit. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1158 | mathematical functions should remain symbolic | calculus | sage-3.2 | enhancement | 11/12/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some mathematical functions automatically evaluate to floating-point, even for a symbolic input (integer or variable): sage: Ei(10)
2492.22897624
sage: bessel_J(0,10)
-0.245935764451348
sage: bessel_J(0,x)
---------------------------------------------------------------------------
<type 'exceptions.TypeError'> Traceback (most recent call last)
/tmp/gmp-4.2.2/tune/<ipython console> in <module>()
/usr/local/sage-2.8.12/sage/local/lib/python2.5/site-packages/sage/functions/special.py in bessel_J(nu, z, alg, prec)
492 else:
493 K,a = _setup(prec)
--> 494 b = K(nu.besselj(z))
495 pari.set_real_precision(a)
496 return b
/tmp/gmp-4.2.2/tune/real_mpfr.pyx in sage.rings.real_mpfr.RealField.__call__()
/tmp/gmp-4.2.2/tune/real_mpfr.pyx in sage.rings.real_mpfr.RealNumber._set()
<type 'exceptions.TypeError'>: Unable to convert x (='1-1/4*x^2+1/64*x^4-1/2304*x^6+1/147456*x^8-1/14745600*x^10+1/2123366400*x^12-1/416179814400*x^14+1/106542032486400*x^16+O(x^17)') to real number.
In my opinion, foo(10) should evaluate to foo(10), and similarly foo(x). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
jason
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3543 | Unify jquery libraries in devel/sage and data/extcode | build | sage-3.2 | defect | 07/02/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We currently ship two copies of the jquery javascript library:
But we should on ship one copy. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mabshoff
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3122 | after make install, sage tries to write in /usr/local | relocation | sage-3.2 | defect | 05/07/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I compiled sage-3.0 on the machines of my lab, and installed it under /usr/local/sage-3.0 with make install DESTDIR=/usr/local/sage-3.0. I am the Unix owner of the files under /usr/local/sage-3.0. When I run sage myself, it is ok. However, when other people in my lab run it, they get: < bissogae@hector:~$ sage < ---------------------------------------------------------------------- < | SAGE Version 3.0, Release Date: 2008-04-23 | < | Type notebook() for the GUI, and license() for information. | < ---------------------------------------------------------------------- < Traceback (most recent call last): < File "/usr/local/sage-3.0/sage/local/bin/sage-location", line 66, in <module> < t, R = install_moved() < File "/usr/local/sage-3.0/sage/local/bin/sage-location", line 11, in install_moved < O = open(location_file,'w') < IOError: [Errno 13] Permission denied: '/usr/local/sage-3.0/sage/local/lib/sage-current-location.txt' < < sage: I'm not sure it is ok that SAGE writes in /usr/local... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3123 | blacklist "gcc version 4.1.0 (SUSE Linux)" | build | sage-3.2 | defect | 05/07/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
gcc version 4.1.0 (SUSE Linux) from OpenSuSE 10.1 is know broken and will fail to file Sage with sage/modules/real_double_vector.c: In function ‘__pyx_pf_4sage_7modules_18real_double_vector_28RealDoubleVectorSpaceElement_ __init__’: sage/modules/real_double_vector.c:2012: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.suse.de/feedback> for instructions. error: command 'gcc' failed with exit status 1 Blacklist it. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3787 | make ATLAS use extended cpuid | build | sage-3.2 | defect | 08/06/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[7:14pm] cwitty: 1) My spiffy new Xeon-branded core 2 quad computer is very slow at compiling ATLAS. [7:14pm] mabshoff: mhhh, how long? [7:15pm] cwitty: I think ATLAS doesn't support the extended cpuid. [7:15pm] cwitty: About 2 hours. [7:15pm] mabshoff: On an Itanium 2 with loads of memory it takes about 3 hours with loads of cache. [7:15pm] mabshoff: Can you check the ARCH in the makefile? [7:16pm] cwitty: PIII64SSE3 [7:17pm] mabshoff: Ok, then it is identified. We might not have tuning info. [7:18pm] mabshoff: Let me check in a little while, but the compile time depends on the L2 size. [7:18pm] cwitty: Umm... Pentium 3? I'm pretty sure it's not a pentium 3. [7:18pm] mabshoff: Oops [7:18pm] mabshoff: Yeah, you are right. [7:18pm] mabshoff: ATLAS uses cpuid, not extended cpuid. [7:18pm] mabshoff: I am not sure if 3.8.2 fixes that, but I can patch it in case it does not. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3898 | [with spkg, needs review] Make an optional, self contained gcc 4.3.2.spkg | packages | sage-3.2 | defect | 08/19/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This spkg requires a working Sage to build and is Linux only for now. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3984 | Sage 3.1.2.alpha1 - Linux Itanium - segfaults in chmm.pyx and hmm.pyx | doctest | sage-3.2 | defect | 08/28/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note: most of the valgrind fix issues have been moved to #4067. Those fixes do not prevent the segfault, so I broke them out. Cheers, Michael On Iras: mabshoff@iras:~/build-3.1.2.alpha2/sage-3.1.2.alpha1-iras-gcc-4.3.1> ./sage -t -long devel/sage/sage/stats/hmm/chmm.pyx
sage -t -long devel/sage/sage/stats/hmm/chmm.pyx
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).
------------------------------------------------------------
A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest.
[4.4 s]
exit code: 768
----------------------------------------------------------------------
The following tests failed:
sage -t -long devel/sage/sage/stats/hmm/chmm.pyx
Total time for all tests: 4.4 seconds
mabshoff@iras:~/build-3.1.2.alpha2/sage-3.1.2.alpha1-iras-gcc-4.3.1> ./sage -t -long devel/sage/sage/stats/hmm/hmm.pyx
sage -t -long devel/sage/sage/stats/hmm/hmm.pyx
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).
------------------------------------------------------------
A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest.
[3.0 s]
exit code: 768
----------------------------------------------------------------------
The following tests failed:
sage -t -long devel/sage/sage/stats/hmm/hmm.pyx
Total time for all tests: 3.0 seconds
mabshoff@iras:~/build-3.1.2.alpha2/sage-3.1.2.alpha1-iras-gcc-4.3.1>
All other doctests for 3.1.2.alpha1 pass on that box. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3785 | upgrade atlas in sage to version 3.8.2 | linear algebra | sage-3.2 | enhancement | 08/06/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is a non-negotiable blocker for Sage-3.1. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1641 | Make ATLAS restart build on tolerance error | packages | sage-3.2 | defect | 12/30/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
When the ATLAS build fails due to tolerance errors we can restart the build by restarting the build process via "make". We should do it a set number of times, i.e. 5 and then finally fail. I have hit the problem repeatedly while building in a VMWare machine and have little to no control to prevent the issue from happening. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2999 | Some packages don't respect the CC environment variable | build | sage-3.2 | defect | 04/22/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Packages which seem to not honor CC environment variable (they use "gcc"): flint-1.06.p2 atlas-3.8.1.p1 f2c-20070816.p0 symmetrica-2.0.p2 polybori-0.3.1.p1 rubiks-20070912.p5 zn_poly-0.8.p0 sage-3.0.rc1 gap-4.4.10.p7 // guava3.4 tachyon-0.98beta.p5 palp-1.1.p1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3000 | Some packages don't respect the CXX environment variable | build | sage-3.2 | defect | 04/22/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Packages which seem not to honor CXX environment variable (they use "g++") polybori-0.3.1.p1 rubiks-20070912.p5 sage-3.0.rc1 gfan-0.3.p3 flintqs-20070817.p3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3001 | sage ignores custom environment variables | build | sage-3.2 | defect | 04/22/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
In sage-spkg "gcc -v" is used, instead of "${CC-gcc} -v". Easy fix:
---------------------------------------------------------------
--- a/sage-spkg Mon Apr 21 01:43:53 2008 -0700
+++ b/sage-spkg Tue Apr 22 12:37:48 2008 -0300
@@ -241,8 +241,8 @@
echo "****************************************************"
echo "GCC Version"
-echo "gcc -v"
-gcc -v
+echo "${CC-gcc} -v"
+${CC-gcc} -v
if [ $? -ne 0 ]; then
echo "Unable to determine gcc version."
fi
---------------------------------------------------------------
In sage-env, tests if CC is gcc, which means "CC=gcc-4.3" might not work exactly the same as if gcc is a symlink to gcc-4.3, for instance: if [ "$SAGE64" = "yes" -a CC = "gcc" ]; then CFLAGS="$CFLAGS -m64" fi |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #479 | linbox-20070814.spkg abuses [CPP|CXX|C]FLAGS in spkg-install | packages | sage-3.2 | defect | 08/22/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello, The current LinBox? package in Sage 2.8.2 has the following assignments in spkg-install CFLAGS="$CFLAGS -fPIC -I\"$SAGE_LOCAL/include\" -I\"$SAGE_LOCAL/include/linbox\"-L\"$SAGE_LOCAL/lib\"" CXXFLAGS="$CXXFLAGS -fPIC -I\"$SAGE_LOCAL/include\" -I\"$SAGE_LOCAL/include/linbox\" -L\"$SAGE_LOCAL/lib\"" CPPFLAGS="$CPPFLAGS -I\"$SAGE_LOCAL/include/linbox\" -I\"$SAGE_LOCAL\"/include" but uses the configure with the following options: ./configure --prefix="$SAGE_LOCAL" --with-givaro="$SAGE_LOCAL" --with-gmp="$SAGE_LOCAL" --with-ntl="$SAGE_LOCAL" $OPS --with-blas="$LINBOX_BLAS" This is due to a bug in LinBox? where for exmaple GMP_CFLAGS is not propagated down into the Makefiles (via Makefile.am). I have fixed this for the GMP and I assume that it is the same fix for NTL and Givaro. The GMP fix already made it into LinBox?-20070814.spkg and I did verify on my systems that the right gmp selected during configure is also linked against. Once I have made the fixes for NTL and Givaro I will push those fixes toward LinBox? upstream. Cheers, Michael I |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #536 | off by one in NZL::vec_ZZ::SetLength(long) (from modular/dirichlet.py) | memleak | sage-3.2 | defect | 08/30/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
From Sage 2.8.3rc3: ==25034== Address 0x24DB2020 is 8 bytes before a block of size 64 alloc'd ==25034== by 0x97D3C09: NTL::vec_ZZ::SetLength(long) (in /tmp/Work2/sage-2.8.3.rc3/local/lib/libntl.so) ==25034== by 0x972D78F: NTL::PlainPseudoDivRem(NTL::ZZX&, NTL::ZZX&, NTL::ZZX const&, NTL::ZZX const&) (in /tmp/Work2/sag e-2.8.3.rc3/local/lib/libntl.so) ==25034== by 0x972D9E6: NTL::PlainPseudoRem(NTL::ZZX&, NTL::ZZX const&, NTL::ZZX const&) (in /tmp/Work2/sage-2.8.3.rc3/lo cal/lib/libntl.so) ==25034== by 0x9732BA2: NTL::rem(NTL::ZZX&, NTL::ZZX const&, NTL::ZZX const&) (in /tmp/Work2/sage-2.8.3.rc3/local/lib/lib ntl.so) ==25034== by 0x9732E1C: NTL::MulMod(NTL::ZZX&, NTL::ZZX const&, NTL::ZZX const&, NTL::ZZX const&) (in /tmp/Work2/sage-2.8 .3.rc3/local/lib/libntl.so) ==25034== by 0x1B790919: __pyx_f_20number_field_element_18NumberFieldElement__mul_c_impl(__pyx_obj_20number_field_element _NumberFieldElement*, __pyx_obj_4sage_9structure_7element_RingElement*) (number_field_element.cpp:4198) ==25034== by 0xE3C999D: __pyx_f_7element_11RingElement__mul_c (element.c:8340) ==25034== by 0xE3BD3E4: __pyx_f_7element_11RingElement___mul__ (element.c:7922) ==25034== by 0x41596C: binary_op1 (abstract.c:398) ==25034== by 0x418EC3: PyNumber_InPlaceMultiply (abstract.c:744) ==25034== by 0x481053: PyEval_EvalFrameEx (ceval.c:1274) Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #537 | leak in _ntl_gsetlength (from modular/dirichlet.py) | memleak | sage-3.2 | defect | 08/30/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
From Sage 2.8.3rc3: ==25034== 48 bytes in 1 blocks are definitely lost in loss record 746 of 2,712 ==25034== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==25034== by 0x9774DD5: _ntl_gsetlength (in /tmp/Work2/sage-2.8.3.rc3/local/lib/libntl.so) ==25034== by 0x9775D6F: _ntl_gmul (in /tmp/Work2/sage-2.8.3.rc3/local/lib/libntl.so) ==25034== by 0x1B7908F4: __pyx_f_20number_field_element_18NumberFieldElement__mul_c_impl(__pyx_obj_20number_field_element _NumberFieldElement*, __pyx_obj_4sage_9structure_7element_RingElement*) (ZZ.h:384) ==25034== by 0xE3C999D: __pyx_f_7element_11RingElement__mul_c (element.c:8340) ==25034== by 0xE3BD3E4: __pyx_f_7element_11RingElement___mul__ (element.c:7922) ==25034== by 0x41596C: binary_op1 (abstract.c:398) ==25034== by 0x418EC3: PyNumber_InPlaceMultiply (abstract.c:744) ==25034== by 0x481053: PyEval_EvalFrameEx (ceval.c:1274) ==25034== by 0x485025: PyEval_EvalFrameEx (ceval.c:3650) ==25034== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==25034== by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #557 | missing dictionary deallocation in Cython's init code | memleak | sage-3.2 | defect | 09/01/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Okay, the problem I found is deep in Cython generated code and maybe not the fault of Cython, but might be an underlying issue in Python. For each of the 244 pyx files we have in the tree we do not deallocate a dictionary. While this isn't a defect per se it makes the valgrind output more noise and therefor more difficult to parse. The example output below is from rational.pyx. The function initrational is created via Cython (there is no init-method, but that comes out of the creation of the class as far as I can tell): ==25825== 3,072 bytes in 1 blocks are still reachable in loss record 2,268 of 2,539 ==25825== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==25825== by 0x43F179: dictresize (dictobject.c:513) ==25825== by 0x45B00C: PyType_Ready (typeobject.c:5575) ==25825== by 0x169D79A0: initrational (rational.c:10789) ==25825== by 0x49F762: _PyImport_LoadDynamicModule (importdl.c:53) ==25825== by 0x49D63E: import_submodule (import.c:2394) ==25825== by 0x49DB11: load_next (import.c:2214) ==25825== by 0x49DD6E: import_module_level (import.c:2002) ==25825== by 0x49E1A4: PyImport_ImportModuleLevel (import.c:2066) ==25825== by 0x47D5D8: builtin___import__ (bltinmodule.c:47) ==25825== by 0x4156A2: PyObject_Call (abstract.c:1860) ==25825== by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) The exact line from rational.c:10789 is: if (PyType?_Ready(&pyx_type_8rational_Rational) < 0) {pyx_filename = pyx_f[1]; pyx_lineno = 126; goto pyx_L1;} It mentions line 126 which in rational.pyx is: cdef class Rational(sage.structure.element.FieldElement?): So can be dereference the class somehow upon exit? Looking at valgrind-sessions from python it appears that this is possible because otherwise there would be a large number of leak dictionaries from the buildin c-libraries. Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #620 | memory still reachable in vector_rational_dense_21Vector_rational_dense__init | memleak | sage-3.2 | defect | 09/07/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is caused when running Sage 2.8.3.6+malb's fix for #566: for i in range(3):
get_memory_usage()
m = ModularSymbols(501,2).decomposition(3);
del m; ModularSymbols_clear_cache();
get_memory_usage()
and results in ==8920== LEAK SUMMARY: ==8920== definitely lost: 1,518,830 bytes in 183,739 blocks. ==8920== indirectly lost: 288,408 bytes in 610 blocks. ==8920== possibly lost: 489,439 bytes in 1,002 blocks. ==8920== still reachable: 160,311,066 bytes in 872,845 blocks. ==8920== suppressed: 0 bytes in 0 blocks. The exact problem: ==8920== 1,612,736 bytes in 446 blocks are still reachable in loss record 2,367 of 2,372 ==8920== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==8920== by 0x210A2D65: __pyx_f_21vector_rational_dense_21Vector_rational_dense__init (vector_rational_dense.c:770) ==8920== by 0x210A0DE7: __pyx_tp_new_21vector_rational_dense_Vector_rational_dense (vector_rational_dense.c:865) ==8920== by 0x45A272: type_call (typeobject.c:422) ==8920== by 0x4156A2: PyObject_Call (abstract.c:1860) ==8920== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==8920== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==8920== by 0x4CFED0: function_call (funcobject.c:517) ==8920== by 0x4156A2: PyObject_Call (abstract.c:1860) ==8920== by 0x41BE0C: instancemethod_call (classobject.c:2497) ==8920== by 0x4156A2: PyObject_Call (abstract.c:1860) ==8920== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #621 | memory still reachable in matrix_integer_dense_Matrix_integer_dense | memleak | sage-3.2 | defect | 09/07/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is caused when running Sage 2.8.3.6+malb's fix for #566: for i in range(3):
get_memory_usage()
m = ModularSymbols(501,2).decomposition(3);
del m; ModularSymbols_clear_cache();
get_memory_usage()
and results in ==8920== LEAK SUMMARY: ==8920== definitely lost: 1,518,830 bytes in 183,739 blocks. ==8920== indirectly lost: 288,408 bytes in 610 blocks. ==8920== possibly lost: 489,439 bytes in 1,002 blocks. ==8920== still reachable: 160,311,066 bytes in 872,845 blocks. ==8920== suppressed: 0 bytes in 0 blocks. The exact problem: ==8920== 2,603,712 bytes in 5 blocks are still reachable in loss record 2,370 of 2,372 ==8920== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==8920== by 0x205E1766: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___new__ (matrix_integer_dense.c:2966) ==8920== by 0x205E1BE0: __pyx_tp_new_20matrix_integer_dense_Matrix_integer_dense (matrix_integer_dense.c:17692) ==8920== by 0x45A272: type_call (typeobject.c:422) ==8920== by 0x4156A2: PyObject_Call (abstract.c:1860) ==8920== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==8920== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==8920== by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==8920== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==8920== by 0x4CFF37: function_call (funcobject.c:517) ==8920== by 0x4156A2: PyObject_Call (abstract.c:1860) ==8920== by 0x41BE0C: instancemethod_call (classobject.c:2497) Cheers, Michael |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #748 | [ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||