{5} Assigned, Active Tickets by Owner (Full Description) (135 matches)

This was reported by William Stein at #4106:

I did notice this unfortunate property of the _polynomial_ function that is used to implement this patch, namely it does something dumb when given x+y as input:

  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

I think in this case it should raise a TypeError.

Take the static page at http://timothyclemans.com/nb_homepage/ and merge it into the Sage Notebook code.

This is a first step in making the Notebook code more modular like Knoboo's.

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:

• faces are always convex
• there won't ever be faces with no vertices

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.

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.

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. ;)

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.

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.

Includes capabilities for options pricing using the Black-Scholes model. The primary class of this ticket is finance.Option, which uses finance.Stock.

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.

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.)

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)

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|
> 
> }}}
> 

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

sage: var('x')
x
sage: x.conjugate()
x

Under the assumption that x might be complex, this should really return conjugate(x).

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

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 ):

• user can pass in a "complexity function" which determines how simple an expression is
• user can pass in a time limit for the simplification
• user can pass in a list of things that won't be simplified
• etc.

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).

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...

[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.

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

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

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

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

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

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