3 Jul 12:58 2015

### Is it possible to calculate inverse Laplace Transform of exponent?

I want to calculate inverse laplace of e^(-2s) which is dirac(t-2), but sympy gives unevaluated.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
2 Jul 19:18 2015

### Solving matrices in a finite field

For my project, I need to solve for a matrix X given matrices Y and K. (X*Y=K) The elements of each matrix must be integers modulo a random 256-bit prime. My first attempt at solving this problem used SymPy's mod_inv(n) function. The problem with this is that I'm running out of memory with matrices of around size 30. My next thought was to perform matrix factorization, as that might be less heavy on memory. However, SymPy seems to contain no solver that can find matrices modulo a number. Any workarounds or self-made code I could use?

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
2 Jul 17:30 2015

### Strange behavior from custom matrix printer

I have implemented a custom matrix printer with "_print_MatrixBase(self, expr)."  I am running "jupyter notebook" with the output of
"_print_MatrixBase(self, expr)" being given by -

def _print_MatrixBase(self, expr):
rows = expr.rows
cols = expr.cols

out_str = ' \\left [ \\begin{array}{' + (cols * 'c') + '} '
for row in range(rows):
for col in range(cols):
out_str += latex(expr[row,col]) + ' & '
out_str = out_str[:-2] + ' \\\\ '
out_str = out_str[:-4] + ' \\end{array}\\right ] '

if isinteractive():
return display(Math(out_str))
else:
return out_str

for "jupyter notebook" the output is "return display(Math(out_str))" where the out_str ins the tex output for the matrix.  The notebook output is -

See attached file

Where  sp3.g is a sympy Matrix.  Why is "None"  output along with the correct matrix output?

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
2 Jul 03:09 2015

### Strange behavior from custom matrix printer

I have implemented a custom matrix printer with "_print_MatrixBase(self, expr)."  I am running "jupyter notebook" with the output of
"_print_MatrixBase(self, expr)" being given by -

def _print_MatrixBase(self, expr):
rows = expr.rows
cols = expr.cols

out_str = ' \\left [ \\begin{array}{' + (cols * 'c') + '} '
for row in range(rows):
for col in range(cols):
out_str += latex(expr[row,col]) + ' & '
out_str = out_str[:-2] + ' \\\\ '
out_str = out_str[:-4] + ' \\end{array}\\right ] '

if isinteractive():
return display(Math(out_str))
else:
return out_str

for "jupyter notebook" the output is "return display(Math(out_str))" where the out_str ins the tex output for the matrix.  The notebook output is -

see Capture.PNG

Where  sp3.g is a sympy Matrix.  Why is "None"  output along with the correct matrix output?

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALOxT-mhU--urwGR19u%3Dt4v%2BT4%2B%3DEpbqxbcTHefrpiL1DTSBvA%40mail.gmail.com.
1 Jul 19:41 2015

### solveset_real(exp(I*x), x) for real x

Hi all
Though solveset_real claimes to be complete in terms of real solution returned
But for this

>>> x = Symbol('x', real=True)
>>> solveset_real(exp(I*x), x)
FiniteSet(0)

But probably the solution is what is returned for the solveset_complex
>>> y = Symbol('y')
>>> solveset_complex(exp(I*y), y)
ImageSet(Lambda(_n, 2*_n*pi), Integers()) # correct solution returned # same should be returned for solveset_real ?
Is there any reason why we just get FiniteSet(0) ?CheersGaurav

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
1 Jul 10:54 2015

### very basic question about plotting and matplotlib

Hi !

I've been using sympy for a while, mostly through Sage but sometimes also on its own. For a number of reasons, I have decided to use sympy with my students next fall, and i need to learn a few basic things, for which I normally rely on Sage.

Mostly, I mean plotting. All my plots are normally done with Sage, and matplotlib is another library which I have never used independently of Sage... I have looked at sympy's documentation but failed to find an A to Z guide to plotting (I guess it is assumed that the user knows matplotlib better than I do).

Here are the things I have tried -- the first worked but is not ideal, the others failed.

(1) The Sage cell at http://sagecell.sagemath.org/. I select python as a language, then enter

from sympy import *

x= Symbol("x")
plot(x*x)

and it works !

(2) Sympy live at http://live.sympy.org/.

I have tried plot(x*x) and plot(x*x).show() (I had my hopes on the second one) but nothing pops up. That's disapppointing, as I wanted to advertise the sympy live functionality to my students.

(3) On my local machine. I go "sage -ipython" which launches a copy of python with all the libraries that you could think of, certainly sympy and matplotlib.

Again plot(x*x) and plot(x*x).show() fail to display anything.

I'm guessing in this case it's a (simple?) matter of telling sympy to talk to matplotlib, and perhaps of telling matplotlib to start itself. I have no idea how to proceed though!

Thank you for any help...

Pierre
PS I'm using Mac OSX.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
1 Jul 06:40 2015

### utilities.autowrap.ufuncify fails with symbol lists of length >= 32

Hi friends, please allow me to introduce myself. My name is Mike Roberts. I am a computer science PhD student at Stanford. I've been using sympy recently to help me solve some fun optimization problems.

I have encountered some unexpected behavior in the sympy.utilities.autowrap module. I believe I am running into an undocumented hard-coded limit on the number of symbols I can pass into sympy.utilities.autowrap.ufuncify(...). Here is the code snippet that demonstrates the unexpected behavior I'm seeing.

from pylab import *
import sympy
import sympy.utilities.autowrap

zero_expr = sympy.sympify("0")

num_syms           = 31
syms               = [ sympy.Symbol("x_%02d"%i) for i in range(num_syms) ]
vals               = zeros(len(syms))
zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True)

# works
print zero_expr_ufuncify(*vals)
print

num_syms           = 31
syms               = [ sympy.Symbol("x_%099d"%i) for i in range(num_syms) ]
vals               = zeros(len(syms))
zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True)

# also works
print zero_expr_ufuncify(*vals)
print

num_syms           = 32
syms               = [ sympy.Symbol("x_%02d"%i) for i in range(num_syms) ]
vals               = zeros(len(syms))
zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True)

# doesn't work
print "about to evaluate ufunc with 32 args..."
print zero_expr_ufuncify(*vals)
print

The first two calls to zero_expr_ufuncify(*vals) behave as expected, returning 0.0. But the last call to zero_expr_ufuncify(*vals) causes a segmentation fault. The exact error I'm getting is as follows.

Segmentation fault: 11

The only difference between these calls is that sympy.utilities.autowrap.ufuncify(...) was called with symbol lists of different lengths. For both behaves-as-expected calls, the corresponding symbol list is of length 31. For the does-not-behave-as-expected call, the corresponding symbol list is of length 32.

Note that the second call has a corresponding symbol list of length 31, but the symbols have very long names. Since this call behaves as expected, I believe this is not a problem of the generated C code having too many ASCII characters on a single line.

Note that I also found a post describing a similar issue on the Google Group. However, the code example from the Google Group is targeting a Fortran backend. Therefore, I believe the issue on the Google Group is different to the one I'm reporting here.

I'm running sympy 0.7.6-1, which I installed via the Canopy Package Manager on OSX Yosemite 10.10.3, 64 bit.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
1 Jul 07:05 2015

### Fwd: utilities.autowrap.ufuncify fails with symbol lists of length >= 32

As reported by Mike Roberts here:  https://github.com/sympy/sympy/issues/9593

I have encountered some unexpected behavior in the sympy.utilities.autowrap module. I believe I am running into an undocumented hard-coded limit on the number of symbols I can pass intosympy.utilities.autowrap.ufuncify(...). Here is the code snippet that demonstrates the unexpected behavior I'm seeing.

from pylab import * import sympy import sympy.utilities.autowrap zero_expr = sympy.sympify("0") num_syms = 31 syms = [ sympy.Symbol("x_%02d"%i) for i in range(num_syms) ] vals = zeros(len(syms)) zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True) # works print zero_expr_ufuncify(*vals) print num_syms = 31 syms = [ sympy.Symbol("x_%099d"%i) for i in range(num_syms) ] vals = zeros(len(syms)) zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True) # also works print zero_expr_ufuncify(*vals) print num_syms = 32 syms = [ sympy.Symbol("x_%02d"%i) for i in range(num_syms) ] vals = zeros(len(syms)) zero_expr_ufuncify = sympy.utilities.autowrap.ufuncify(args=syms,expr=zero_expr,backend="numpy",verbose=True) # doesn't work print "about to evaluate ufunc with 32 args..." print zero_expr_ufuncify(*vals) print

The first two calls to zero_expr_ufuncify(*vals) behave as expected, returning 0.0. But the last call tozero_expr_ufuncify(*vals) causes a segmentation fault. The exact error I'm getting is as follows.

Segmentation fault: 11

The only difference between these calls is that sympy.utilities.autowrap.ufuncify(...) was called with symbol lists of different lengths. For both behaves-as-expected calls, the corresponding symbol list is of length 31. For the does-not-behave-as-expected call, the corresponding symbol list is of length 32.

Note that the second call has a corresponding symbol list of length 31, but the symbols have very long names. Since this call behaves as expected, I believe this is not a problem of the generated C code having too many ASCII characters on a single line.

Note that I also found a post describing a similar issue on the Google Group. However, the code example from the Google Group is targeting a Fortran backend. Therefore, I believe the issue on the Google Group is different to the one I'm reporting here.

I'm running sympy 0.7.6-1, which I installed via the Canopy Package Manager on OSX Yosemite 10.10.3, 64 bit.

AMiT Kumar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
29 Jun 21:32 2015

### Installing Sympy Mac OS 10.10.3

Hi everyone! I'm trying to install sympy with the

python setup.py install

command, but I'm running into an error message:

error: could not create '/System/Library/Frameworks/Python.framework/Versions/2.7/share': Permission denied

I was previously getting the error message

error: could not create '/Library/Python/2.7/site-packages/sympy': Permission denied

But didn't get it after giving myself read-write privileges to the site-packages folder (this is on my laptop, so I'm running this as admin). After getting this new error message I tried to deal with it by giving myself read-write privileges for the Versions folder, but it's not working.

Also, I don't actually have a ~/Versions/2.7 directory. The only folder I have in the Versions directory is 3.3.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
28 Jun 10:35 2015

### Enabling SymPy for external dependencies

I just hit another situation where I would really have liked to use an
external (small) library that was packaging a huge amount of research
and knowledge in a relatively small but well-done codebase.
(See the end of this message for details.)
My realization is that the Python ecosystem has (finally) started to
accumulate libraries that are actually worth reusing: Less work to learn
and integrate than to write the thing ourselves.

So I'd really like to get us into a shape where we can easily use
external dependencies.

What are the problems?
Can we turn them into tasks?
How to we complete the tasks?

I.e. I want the problems listed with an eye towards "how to we solve
that", not with a perspective of "that's why we do not do that".
Obviously, it's not going to be easy, but probably easier than dealing
with decorators.

Regards,
Jo

--
FWIW the latest use case that I had (I had more in the past): Decorators.
I spend an ungodly amount of time trying to understand them (easy) and
their implication (TONS of research, decorators need to understand all
protocols that are involved in classes, calls, and introspection, plus
there are differences between Python versions). During that research, I
found Graham Dumpleton's essay about doing decorators right:
http://blog.dscpl.com.au/2014/01/how-you-implemented-your-python.html
Turns out there were issues I *still* wasn't aware of. (That guy is
simply awesome.)
Even better, he went on and wrote wrapt:
https://github.com/GrahamDumpleton/wrapt
It's making writing decorators easier. You write a decorator function as
before, but you get not just the function you wrap, you get its class,
and the resulting decorator will properly deal with functions, methods,
static methods, and class methods, it will properly forward __name__,
__module__, it will work around incomplete/buggy decorator protocol
implementations in the standard library, and probably a few other
details that I didn't notice.
That guy is awesome. I couldn't do what he did, and I know I can do
quite a lot.
And I want his code.

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe@...
To post to this group, send email to sympy@...
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/558FB1E7.8000102%40durchholz.org.


26 Jun 22:57 2015

### Is there any way to build a differentiable sum of indexed types?

I'd like to do this:

>>> r = IndexedBase['m']
>>> i = idx('i')
>>> h = Symbol('h')
>>> N = Symbol('N', integer=True)
>>> J = Sum(h * r[i]**2, (i, 1, N))
>>> J.diff(r[i])
2 * h * r[i]

This currently doesn't work (Sum doesn't like idx). But are there other ways to do this in SymPy? Or should this work?

The big picture is that I want to be able write a scalar expression that involves integrals of continuous functions, but then numerically approximate it with various numerical integration patterns. And finally I need to find the gradient of the expression with respect to discrete variables, like r[i] above.

Jason
moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.