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

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?

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

New features: - Reset a user's password - Add a new user - Suspend/unsuspend a user - Temporary password shown for each user if one is set (Created by password reset and add user)

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.

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.

Attached patches move sage.rings.fraction_field.FractionField_generic to the new coercion model, and cythonize the sage.rings.fraction_field_element.FractionFieldElement class. They also allow homomorphisms of fraction fields to work, and make the random_element() method of fractions fields return sensible results.

I will follow these up with specialized classes for rational functions.

The patches depend on #4278.

Since one of the patches renames a file (from *.py to *.pyx) it contains a git style patch. Here are the lines you need in the .hgrc file:

[diff]
git = 1

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.

This used to work and is now broken. It is used in my modular forms book.

sage: CuspForms(45).new_subspace()
Traceback (most recent call last):
...
NotImplementedError: computation of new submodule not yet implemented

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.

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.

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.

Current coverage in Sage 2.10.3: SCORE quotient_ring_element.py: 3% (1 of 27)

Smith form is a useful canonical form for matrices over a PID. Sage already has it for ZZ. I've coded up a very basic implementation that should work over any PID Sage knows about (although it is not fast).

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

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

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

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

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

In MMA, you can thread the derivative over lists of variables and functions to compute the Jacobian. Here's a routine that wraps the sage diff function to do it.

def diff(f,*args):
    if isinstance(f, (list, tuple)):
        return [diff(component,*args) for component in f]
    else:
        if isinstance(args[0], (list, tuple)):
            return [diff(f,variable) for variable in args[0]]
        else:
            return sage.all.diff(f,*args)

and the results:

sage: var('a,b,c,d,x,y')
sage: diff((a*x+b*y,c*x+d*y),(x,y))
[[a, b], [c, d]]

well, so the result is not really a matrix, but rather a nested list that could be indexed like a matrix or turned into a matrix in the above case.

We could write the above even more simply if we had an outer product operator:

outer_product(diff,f,vars), where f and vars were lists.

This is an error to a custom patch that we have to the matplotlib code so that we can have arrows that are shortened by a certain number of points.

This week, I was drawing plot vector field using two ways : (1) plot_vector_field and (2) by simply suming up plenty of arrows as I wished. Since their was a fixed point somewhere, I came up with the problem of drawing a zero length arrow. Using sage 3.1.4, I get a zero division error. Where is this division from? The example below show that it is not from the slope as it can draw a vertical arrow.

sage: arrow((1, 1), (2, 1))
sage: arrow((1, 1), (1, 2))
sage: arrow((1, 1), (1, 1))
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last) :
...
/home/slabbe/sage/local/lib/python2.5/site-packages/matplotlib/arrow_line.pyc in draw(self, renderer)
    100         pixel_vector = (orig_t.transform_point(points[1]) - orig_t.transform_point(points[0]))
    101         pixel_length=math.sqrt(sum(pixel_vector**2))
--> 102         clip_fraction = renderer.points_to_pixels(self._arrowshorten)/pixel_length
    103         head_clip_fraction = renderer.points_to_pixels(self._arrowshorten+self._arrowheadlength*0.8)/pixel_length
    104

ZeroDivisionError: float division

In my problem, I would have been happy if arrow(x,x) would draw simply a point. I know I can define my own arrow but maybe sage's arrow could behave like myarrow ?

From http://groups.google.com/group/sage-support/t/178d0bd277044918

Yes, that looks correct.  I'm not sure why people are getting the 
error -7 under these conditions.  It means that something has gone 
wrong when trying to load the fallback method, and that usually means 
it can't read the image font definition files.  There are a couple of 
other possibilities as well:  perhaps the noImageFonts plugin was not 
able to be read (permission issue?) or the unicode fallback file could 
not be read.  Given your use of noImageFonts, I suspect it may be the 
latter.  If the users who are getting error -7 are using Firefox3, 
that may well be it.  There were changes to the same-origin security 
policy in Firefox3 that prevent jsMath from loading local files from 
directories other than the one in which the HTML file is found.  I 
worked around this in jsMath v3.6 (released Sept. 2008), so those 
users should update to the latest version of jsMath to avoid that 
problem. 
> I'm pretty sure we don't use the easy/load.js (and I'm not sure why). 

Probably because it didn't exist when jsMath support was added to 
sage.  The easy/load.js file was a relatively late addition to jsMath, 
but certainly makes things easier for people.  You might consider 
whether you want to use that instead. 

Davide

When updating to the latest jsmath the javacode should also be moved to its own spkg.

Cheers,

Michael

This ticket splits off part of #4267.

It depends on #4704

We ought to check to make sure that twisted has the gzip filter enabled and is sending things in zip encoding when it can.

Kyle Schalm suggests:

 
 
here is a matrix constructor i would like to see:
 
Matrix(M, N, f):
   for i in range(1,M+1):
     for j in range(1,N+1):
       self[i][j] = f(i,j)   # or whatever the syntax is
 
 
i might use it like this:
 
A = Matrix(3, 3, lambda i,j: i+j)
 
i'd do it myself, but i don't have a development environment set up,
and don't wanna do that right now.
 
cheers,
kyle
 

We should move jquery into its own standard spkg (and figure out how to merge the two different copies of it in sage in the process).

[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