ith non-Python
> variable names, so it would probably need some extension to work with
> this.
>
> The other way that always works is to wrap the name with Symbol, like
> sympify("Symbol('a_{2, 2}')"). You also need do some extra things to
> parse the =.
Hello all,
I'm trying to parse expressions with multiple subscripts and am running
into errors.
For example, the following works:
sympy.symbol("a_{2,2}")
But parsing an expression does not:
sympy.S("a_{2,2} = a_{3,1}+2")
Can someone explain how to make this work?
Thanks,
Peter.
--
You recei
Thanks Aaron! That's significantly cleaner than my implementation.
On Mon, May 9, 2016 at 10:45 AM, Aaron Meurer wrote:
> On Mon, May 9, 2016 at 11:26 AM, Peter Brady
> wrote:
> > I have some expressions that are being written to a fortran file and
> sympy
> > is k
I have some expressions that are being written to a fortran file and sympy
is keeping them in a form that involves coefficients that are too large.
For example, here's one of my coefficients:
(6447959512020*c21*r**10 + 89877391198101*c21*r**9 + 482379015493674*c21*r**8 +
1955782912118958*c21*r
I opened an issue: http://bugs.python.org/issue25295
On Thursday, October 1, 2015 at 9:31:04 PM UTC-6, Peter Brady wrote:
>
> The big concern is that we shouldn't ever trigger a KeyError. I suspect
> the new lru_cache in 3.5 was not supposed to change this behavior but was
> s
The big concern is that we shouldn't ever trigger a KeyError. I suspect
the new lru_cache in 3.5 was not supposed to change this behavior but was
simply supposed to be more performant than the 3.4 version
On Thu, Oct 1, 2015 at 8:45 PM, Kate MacInnis wrote:
> I don't have any previous experienc
Any ideas on how to test this and turn it into a reasonable bug report?
On Tue, Sep 29, 2015 at 10:27 AM, Aaron Meurer wrote:
> On Mon, Sep 28, 2015 at 8:06 PM, Kate MacInnis
> wrote:
> > Oh, sure. Didn't mean to imply that it doesn't, I'm just happy that I
> can
> > start my next project usin
==
True
Seems like a bug in the new 3.5 lru_cache
On Tuesday, September 29, 2015 at 6:40:22 AM UTC-6, Peter Brady wrote:
>
> 3.5 also introduced an lru_cache in c.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe
3.5 also introduced an lru_cache in c.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@go
.mul.Mul: 72, 0, n/a, _inst_refs
>>class sympy.core.numbers.Half: 80, 0, n/a, _inst_refs
>>class sympy.core.numbers.Integer: 88, 0, n/a, _inst_refs
>>class sympy.core.numbers.NegativeOne: 88, 0, n/a, _inst_refs
>>class sympy.core.numbers.Rat
Thanks for trying that out. I had never heard of pympler before. The
current caching mechanism is based on hashing. By my tests,
'pympler.asizeof' is 500-1000x slower than hashing. That's a strong
deficit for cachey to overcome (as far as sympy objects are concerned).
In [1]: import sympy
In
As of 0.7.6 sympy uses an LRU cache by default. cachey looks interesting
but I think the "nbytes" may be challenging to compute for sympy objects
and operations.
There was some discussion of adopting a similar caching policy a while
ago: https://github.com/sympy/sympy/issues/6321
On Wednesd
If we increase the default cache size and it speeds things up it might be
worthwhile to revisit the travis test splits again.
On Monday, July 20, 2015 at 4:36:45 PM UTC-6, Jason Moore wrote:
>
> I've got a machine that I don't use, so I'm going periodically run the
> benchmarks from Bjorn's repo
not
appropriate for a particular problem.
Problem 2 is much harder to quantify and solve efficiently and could easily
be the cause of the significant slowdown on some tests. We could just make
the cache bigger...
On Monday, July 20, 2015 at 10:30:11 AM UTC-6, Peter Brady wrote:
>
> We v
Jason Moore > wrote:
> > Yes, it seems that the new cache commit is the slow down in these tests.
>
> If this is the case, then I know that Peter Brady who wrote it will be
> interested in this. We should get to the bottom of the issue.
>
> Ondrej
>
--
You rece
Do pip or conda provide stats on which versions are downloaded?
Sent from my TI-83
On Jun 23, 2015 7:21 PM, "Joachim Durchholz" wrote:
> Am 24.06.2015 um 01:24 schrieb Francesco Bonazzi:
>
>>
>> I still use Python 2.7. Is there anyone else like me here?
>>
>
> I'm using 2.6, but that's so that I
Python 3 is scheduled to be the default for Fedora
23 https://fedoraproject.org/wiki/Changes/Python_3_as_Default. Fedora 22
will be maintained until 1 month after Fedora 24 comes out which likely
means May/June 2016.
On Tuesday, June 23, 2015 at 6:35:09 AM UTC-6, Joachim Durchholz wrote:
>
> H
moorepants.info
> +01 530-601-9791
>
> On Mon, Jun 15, 2015 at 1:23 PM, Peter Brady
> wrote:
>
>> As a hacky fix, I now specify the all the the local+module variables to
>> codegen and then remove the extraneous arguments/statements from the
>> returned stri
heck isn't needed.
>>
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>> On Mon, Jun 15, 2015 at 11:00 AM, Peter Brady > > wrote:
>>
>>> So I'm trying to generate some fortran functions that have a uniform
>>> signa
So I'm trying to generate some fortran functions that have a uniform
signature (x, y, z, t). While this can be accomplished using the
'argument_sequence' option to 'codegen', my functions make use of module
level (i.e. global) variables which I do not want to pass in as function
parameters. B
https://github.com/sympy/sympy/issues/9135
On Tuesday, May 19, 2015 at 2:33:03 PM UTC-6, Jonathan Lindgren wrote:
>
> Well, that is exactly the problem, and what I think is a bugit should
> not work like that..
>
> Den tisdag 19 maj 2015 kl. 22:00:46 UTC+2 skrev Alexander Lindsay:
>>
>> Not
> On Tue, May 12, 2015 at 12:45 PM, Sumith 1896 > wrote:
> > Is there a need for an issue to be opened?
> >
> >
> > On Tue, May 12, 2015 at 10:59 PM Peter Brady > wrote:
> >>
> >> Just tried:
> >>
> >> In [1]: from sympy import
Just tried:
In [1]: from sympy import *
In [3]: x,y = symbols("x y")
In [11]: rhs = floor(Mod(floor(y/17)*2**(-17*floor(x)-Mod(floor(y),17)),2))
In [14]: s = "960 939 379 918 958 884 971 672 962 127 852 754 715 004 339
660 129 306 651 505 519 271 702 802 395 266 424 689 642 842 174 350 718 121
>
> Doesn't the test runner do a clear_cache before each test?
No. Just at the start of each file.
On Wed, May 6, 2015 at 2:49 PM, Joachim Durchholz wrote:
> Am 06.05.2015 um 21:51 schrieb Aaron Meurer:
>
>> In my experience, you'll want to run the whole test suite without the
>> cache (I know
12:45 PM, Aaron Meurer wrote:
> Can't you do ./bin/test -C ?
>
> Aaron Meurer
>
> On Wed, May 6, 2015 at 11:46 AM, Peter Brady
> wrote:
> > Not really, caching is a decision made at import time (there's probably a
> > more precise language for this). I think
Not really, caching is a decision made at import time (there's probably a
more precise language for this). I think there are two options here:
1) Write a context manager that forces calls to f.__wrapped__ rather than f
so that the cache is bypassed. This may not be possible.
2) Have a set of
The latest release of sympy uses an LRU cache to limit memory usage. The days
of a 4GB integral should be over. The size of the cache can be controlled via
the environment variable SYMPY_CACHE_SIZE.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To
> 'distribute' version is on 0.6.24 and not the 0.6.28 as required, and
> theres no way to update to 0.6.28.
> not using pip, not through the repo.
>
> Any Ideas?
>
> On Thursday, 18 December 2014 19:08:36 UTC+5:30, Peter Brady wrote:
>>
>> Are you u
Are you using the latest version of numexpr?
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sy
I was perusing the pytest docs and
found http://pytest.org/latest/skipping.html. It appears that in the
pytest xfail decorator one can specify the error with raises. Here's a
little test
import pytest
@pytest.mark.xfail(raises=IndexError)
def test_false_xfail():
x= [1, 2, 3]
assert
Here's a PR advocating skipping the slowest of the slow since we don't
allow them run to completion anyway
https://github.com/sympy/sympy/pull/8123
On Mon, Sep 29, 2014 at 2:37 PM, Peter Brady wrote:
> Just learned that to time all tests (note that this will include
> setup/ca
Just learned that to time all tests (note that this will include
setup/call/teardown) one simply specifies "--durations 0"
On Sat, Sep 27, 2014 at 3:30 PM, Peter Brady wrote:
> I don't know if py.test prints the mark (i.e. slow) but there are many
> extensions so it may be
Meurer
On Sat, Sep 27, 2014 at 5:19 PM, Peter Brady wrote:
> The failures in sympy/utilities/tests/test_pytest.py are due to a
> fundamental difference between bin/test and py.test (perhaps this was not
a
> difference when the tests were written)
&g
The failures in sympy/utilities/tests/test_pytest.py are due to a
fundamental difference between bin/test and py.test (perhaps this was not a
difference when the tests were written)
The failing tests:
=== FAILURES
===
___
/paste from the output of
py.test with test names/times sorted in descending order.
On Sat, Sep 27, 2014 at 12:27 AM, Joachim Durchholz
wrote:
> Just my thinking.
>
> Am 26.09.2014 um 22:23 schrieb Peter Brady:
>
>> One of the reasons for the poor maintenance of the @slow labe
Thanks for clearing that up. I've made an issue based on your gist
https://github.com/sympy/sympy/issues/8121
On Sat, Sep 27, 2014 at 8:46 AM, Ronan Lamy wrote:
> Le 26/09/14 20:14, Peter Brady a écrit :
>
> I've been trying to get better compatibility with py.test recent
substantially easier to monitor which tests should be @slow (or skipped
altogether) as one could get timing data with something simple like
`py.test sympy --durations 100`
On Fri, Sep 26, 2014 at 2:12 PM, Joachim Durchholz wrote:
> Am 26.09.2014 um 17:13 schrieb Peter Brady:
>
>> 1. Mark a
I've been trying to get better compatibility with py.test recently and have
come across a very strange error:
$ py.test sympy/physics/vector/tests -k test_coordinate_vars -v
= test session starts
==
platform linux -- Python 3.4.1 -- py-1.4.
}
# Linearizes the forcing vector; the equations are set up as MM
udot =
# forcing, where MM is the mass matrix, udot is the vector
representing the
# time derivatives of the generalized speeds, and forcing is a
vector which
# contains both external forcing terms a
>
>>> The `test_kane3` test I think is not a good test in general. It's going
>>> to run slow, and personally I've never had it complete (although my laptop
>>> is slow). It's a fine example of the capabilities of our library, but as
Thanks to some recent PR's I was able to run the slow tests under py.test
which supports a --durations flags. Here are the slowest of the slow tests:
== slowest 15 test durations
===
6745.05s call sympy/physics/mechanics/tests/test_kane3.py::t
>
> Cheers,
>
> Tim.
>
>
> On 22 Sep 2014, at 18:20, Peter Brady wrote:
>
> Sorry for the terrible formatting.
>>
>> On Mon, Sep 22, 2014 at 4:17 PM, Peter Brady
>> wrote:
>>
>> Most of the matrices I deal with have a banded structure
Sorry for the terrible formatting.
On Mon, Sep 22, 2014 at 4:17 PM, Peter Brady wrote:
> Most of the matrices I deal with have a banded structure coming from a
> finite-difference representation. I noticed that for such matrices, the DOK
> implementation is far from optimal so I impl
Most of the matrices I deal with have a banded structure coming from a
finite-difference representation. I noticed that for such matrices, the DOK
implementation is far from optimal so I implemented a matrix diagonal
storage form
(http://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg
I know this is an old thread but I think I finally figured out why the
fastcache bencmark was slower: C-extensions and signals don't play well
together! This is also the cause of all the slow test timeouts.
https://github.com/pbrady/fastcache/issues/26
On Thursday, August 7, 2014 2:53:22 PM
I don't have anything to contribute to the topic of licenses and such but
how would you bundle a python library in an android app?
On Wednesday, August 27, 2014 5:15:20 PM UTC-6, Ondřej Čertík wrote:
>
> On Wed, Aug 27, 2014 at 4:49 PM, Ambar Mehrotra > wrote:
> > Thanks Ondrej.
> >
> > But I
This is mostly a software design/engineering question:
There are a large number of XFAILed tests in the test suite and some of
them are rather slow. Here's a sample output:
sympy/core/tests/test_wester.py[396]
.ff
fXffwwff
built with setup.py install. I was using pyinstrument, so it's
> possible that that had a negative impact (the overhead is minimal,
> though, because it uses signals).
>
> Aaron Meurer
>
> On Sun, Aug 3, 2014 at 6:18 PM, Peter Brady wrote:
> > This isn't really
This isn't really related to the current thread but I have a hard time
believing that fastcache could be slower than the pure python lru cache.
Are you sure you are using the latest version (0.4.0)? Do you mind
sending the benchmark script? The only reasons that fastcache would be
slower (I
Sounds good. See https://github.com/sympy/sympy/pull/7677
On Tue, Jul 1, 2014 at 1:25 PM, Ondřej Čertík
wrote:
> On Tue, Jul 1, 2014 at 1:12 PM, Ondřej Čertík
> wrote:
> > On Tue, Jul 1, 2014 at 12:53 PM, Peter Brady
> wrote:
> >> So essentially then, before PR 76
42 PM, Ondřej Čertík
wrote:
> On Tue, Jul 1, 2014 at 12:39 PM, Peter Brady
> wrote:
> > Since facf9dfd9eecf681084dbd fails without caching, doesn't that mean
> that
> > either test_lie_group is broken or there is something wrong with the
> commit
> > which (for s
Since facf9dfd9eecf681084dbd fails without caching, doesn't that mean that
either test_lie_group is broken or there is something wrong with the commit
which (for some reason) caching was able to cover up?
On Tuesday, July 1, 2014 10:36:49 AM UTC-6, Peter Brady wrote:
>
> The deepcopy
The deepcopy bug showed itself by sometimes modifying the assumptions of a
symbol it found in the cache (depending on how things hashed). It may have
also modified some of the "is_" attributes (haven't checked this) which
the simplify routines seem to use. However, if deepcopy erroneously
se
riday, April 25, 2014 4:43:56 PM UTC-6, Ondřej Čertík wrote:
>
> On Fri, Apr 25, 2014 at 4:29 PM, Peter Brady
> >
> wrote:
> > Hi guys,
> >
> > I appreciate you taking the time to test some things out. Ondrej, I had
> > never looked into the 'Line
from B. (i.e in computing A=-c*B+d*B**2)
@Ondrej, I don't think I know what 'x' is
On Friday, April 25, 2014 2:30:24 PM UTC-6, Ondřej Čertík wrote:
>
> On Fri, Apr 25, 2014 at 11:54 AM, Ondřej Čertík
> >
> wrote:
> > Hi Peter,
> >
> > On Fri,
So I start with two sparse matrices, L, and R each with data on just a few
bands (ie 3 to 5)
My goal is compute the largest and smallest eigenvalues of the matrix A
given by:
A = -c*(L^-1*R)+d*(L^-1*R)**2 where c and d are constants
In my code this is written as:
L = SparseMatrix(...)
56 matches
Mail list logo
