On Friday, April 25, 2014 1:16:19 AM UTC+2, Aaron Meurer wrote:
>
> If we override _eval_derivative on MatrixElement can we make it do the
> right thing?
>
No. Because in the case that fails, MatrixElement._eval_derivative is never
called. That's the whole point of the existing _diff_wrt interf
On Friday, April 25, 2014 2:49:15 AM UTC+2, Matthew wrote:
>
> I haven't thought about this issue much. Generally speaking though
> MatrixElement and derivatives and Matrix Expressions are absolutely in a
> not so perfect state. Help here is welcome.
>
I'll see what I can do.
Imo the next thi
>
>
I do not know what exactly these are.
I read that AC unification can be polynomial, which sounds like a
potential performance bottleneck; do we really need it?
>>>
>>> Given expression (like sin(2*x) + cos(2*x)) we need to match against many
>>> possible patterns (like, ever
Yeah, Aaron has been on me to remove the string from MatrixSymbol. My
opinion is that we should allow non-basics in args. This will help us
avoid recreating all of Python. I generally lose this argument.
Where I win though is with the claim that Symbol is way too magical and big
to be used in M
all of the patterns in a good data structure so that we can check them
all
simultaneously (see Trie for something similar). We need to do this
matching in a way that is aware of commutative operators (like +).
Naive
solutions to this are very slow. There exists sophi
Yeah, it's a pretty swell algorithm. Kudos to Chris Smith.
It's also a great usecase of the strategies / decision tree stuff. I'm
happy to go over this with anyone if they're interested.
On Fri, Apr 25, 2014 at 9:01 AM, Ondřej Čertík wrote:
> all of the patterns in a good data structure
Has anyone had any experience in using parallel python with sympy. It
seems to me that there are probably a lot of loops that have independent
operations.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receivi
On Friday, April 25, 2014 5:04:47 PM UTC+2, Matthew wrote:
>
> Yeah, Aaron has been on me to remove the string from MatrixSymbol. My
> opinion is that we should allow non-basics in args. This will help us
> avoid recreating all of Python. I generally lose this argument.
>
Well, I've only been
Matrix expressions use new assumptions so assumptions are stored outside of
the expression. There are good reasons for this. See distinction here
http://matthewrocklin.com/blog/work/2013/02/05/Assuming/ . See example
here
http://scicomp.stackexchange.com/questions/74/symbolic-software-packages-f
On Friday, April 25, 2014 6:33:26 PM UTC+2, Matthew wrote:
>
> Regarding Symbol in MatrixSymbol what we really need is a Basic that just
> holds a name/string. The current Symbol object does that plus a whole lot
> of other things that we don't need. Probably we just need a String(Basic)
> cla
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(...)
Do you use scipy.sparse? I has sparse solvers that should able to compute
L.inv()*R efficiently and then supports addition, multiplication and
squaring. Why do you get crappy eigenvalues when doing this numerically?
Secondly, shouldn't you use
http://docs.sympy.org/dev/modules/matrices/sparse.html
Hi Peter,
On Fri, Apr 25, 2014 at 11:35 AM, Peter Brady wrote:
> 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
On Friday, April 25, 2014 5:02:19 PM UTC+2, Matthew wrote:
>
>
> I used the strategies module to pull out the tree search stuff. See
> either sympy.strategies or github.com/logpy/strategies/
> It is used in fu simp here
>
>
> https://github.com/sympy/sympy/blob/821fc389bcb728f6ec46c32afa38f
It is convenient to know that all information about a term is in it's type
and it's .args. This is true for *almost *all of sympy and it makes it
very convenient to interact with from other systems. Any occasion where
this doesn't occur (e.g. Symbol, Integer, AppliedPredicate) ends up being a
hug
On Fri, Apr 25, 2014 at 11:54 AM, Ondřej Čertík wrote:
> Hi Peter,
>
> On Fri, Apr 25, 2014 at 11:35 AM, Peter Brady wrote:
>> 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 matri
I've created a gist with the text for my L and R matrices as well as a
simple function to read them in and turn them into SparseMatrices at
https://gist.github.com/pbrady/11303375
I can switch from B = L.inv()*R to B = solve(L,R) but most of the time is
not spent computing B but rather A from
On Fri, Apr 25, 2014 at 5:23 AM, Clifford Wolf wrote:
> On Friday, April 25, 2014 1:16:19 AM UTC+2, Aaron Meurer wrote:
>>
>> If we override _eval_derivative on MatrixElement can we make it do the
>> right thing?
>
>
> No. Because in the case that fails, MatrixElement._eval_derivative is never
> c
Funny you should mention that, because that was actually the idea that
we came up with a while back that was considered the best (well at
least I considered it the best). See
https://groups.google.com/d/msg/sympy/pyzfmCq_thI/UwFLv_RDX2IJ. You're
starting to dive into a controversial topic here, whi
Yeah, just to be clear, while I'll argue pretty strongly against injecting
Symbol I should say that it's a perfectly rational thing to do.
Clifford I'm actually pretty impressed that you touched this fairly deep
issue. Have you been developing on SymPy long?
On Fri, Apr 25, 2014 at 2:22 PM, Aar
On Fri, Apr 25, 2014 at 3:17 PM, Peter Brady wrote:
> I've created a gist with the text for my L and R matrices as well as a
> simple function to read them in and turn them into SparseMatrices at
> https://gist.github.com/pbrady/11303375
>
> I can switch from B = L.inv()*R to B = solve(L,R) but mo
Does this work for you?
from __future__ import division
import numpy as np
from scipy.sparse import csr_matrix
from scipy.sparse.linalg import spsolve
def get_matrix(filename):
d = np.zeros(238)
row = np.zeros(238)
col = np.zeros(238)
with open(filename,'r') as f:
for k,
On Fri, Apr 25, 2014 at 3:52 PM, Jason Moore wrote:
> Does this work for you?
>
> from __future__ import division
> import numpy as np
> from scipy.sparse import csr_matrix
> from scipy.sparse.linalg import spsolve
>
> def get_matrix(filename):
>
> d = np.zeros(238)
> row = np.zeros(238)
>
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 'LinearOperator' function before. I tried your idea
> and ended up with an arpack error:
>
> ValueError: Error in inverting M: functio
Sadly, I forgot to upload my data before I left the office. However, a new
thought occurred to me. I've been trying to determine the eigenvalues of
this system to determine the stability of a finite difference scheme
(unstable if any Re(lambda) > 0). This scheme will (of course) be coded up
On Fri, Apr 25, 2014 at 5:30 PM, Peter Brady wrote:
> Sadly, I forgot to upload my data before I left the office. However, a new
> thought occurred to me. I've been trying to determine the eigenvalues of
> this system to determine the stability of a finite difference scheme
> (unstable if any Re
On Friday, April 25, 2014 11:30:17 PM UTC+2, Matthew wrote:
>
> Clifford I'm actually pretty impressed that you touched this fairly deep
> issue. Have you been developing on SymPy long?
>
haha. I actually don't think of myself as developing on SymPy yet. I
started _using_ sympy on monday (i.e.
27 matches
Mail list logo