On Fri, Dec 14, 2012 at 3:05 AM, Aaron Meurer wrote:
>
> I agree that a slice should return a Matrix, though, to be consistant.
Hi and thanks people for your replies.
It is good to know that there is a workaround by using index by tuple
(i.e. [5,:] or [5:,:]) notation for now, but I also would e
Hello Sympifiers,
I noticed some incorrect results for the following expressions
(1*sin(oo)).n() # nan, correct
(2*sin(oo)).n() # 0, should be nan
(sin(oo)+cos(oo)).n() # 0.e-162, should be nan
Using Kununtu 12.04, SymPy 0.7.2-git (Python 2.7.3-64-bit) (ground types:
gmpy)
**
--
You received
Just like we have a submodule of the physics module dealing with mechanics,
could we add a submodule dealing wit electrical and electronical concepts?
A few of them would include potentials, potential gradients(fields),
charges, induction,magnetism and also maybe an extension involving
gravitat
Sounds like an appropriate contribution to me and a nice addition to the
family of physics submodules.
What mathematics infrastructure would be involved in such a module? What
parts of SymPy would be useful?
On Fri, Dec 14, 2012 at 11:00 AM, Sachin Joglekar
wrote:
> Just like we have a submodu
At the basic level, all the calculus algorithms. As we go further, we could
use geometry, solvers etc to extend the usage. Plotting would also be a
nice addition. I will send a PR in a short while and we could take it
further from there.
--
You received this message because you are subscribed to
Hello. I am having to replace certain functions in expressions
contained in a matrix (which I derived from using jacobian) but I find
that I cannot do replace on a Matrix -- I have to do
replace-assignment on each individual item in the Matrix:
>>> from sympy import symbols,Function,Matrix
>>> F,G
This is mostly issue of how it is implemented. Due to the fact that
Matrix is a bit outside of the usual class hierarchy of sympy much of
the interface has to be reimplemented from scratch and we have not yet
done it. If you feel like it, just submit a pull request where you add
these methods.
The
>>> F,G=map(Function,'FG')
>>> M=Matrix(2,2, lambda i,j: F(i+j)); M
[F(0), F(1)]
[F(1), F(2)]
>>> M.applyfunc(lambda x: x.replace(F, G))
[G(0), G(1)]
[G(1), G(2)]
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to symp
On Fri, Dec 14, 2012 at 8:58 PM, Shriramana Sharma wrote:
> On Fri, Dec 14, 2012 at 3:05 AM, Aaron Meurer wrote:
> >
> > I agree that a slice should return a Matrix, though, to be consistant.
>
> Hi and thanks people for your replies.
>
> It is good to know that there is a workaround by using ind
If you use ImmutableMatrix instead of Matrix, then it will have the
replace method (as well as any other method of Basic). The downside
is that the matrix won't be mutable.
Aaron Meurer
On Fri, Dec 14, 2012 at 3:48 PM, Stefan Krastanov
wrote:
> This is mostly issue of how it is implemented. Due
On Fri, Dec 14, 2012 at 8:13 AM, Shriramana Sharma wrote:
> On Fri, Dec 14, 2012 at 3:05 AM, Aaron Meurer wrote:
>>
>> I agree that a slice should return a Matrix, though, to be consistant.
>
> Hi and thanks people for your replies.
>
> It is good to know that there is a workaround by using index
Ah, OK. I didn't realize that that worked. Still, in a true view,
any mutable operation would apply to the given slice in place.
Aaron Meurer
On Thu, Dec 13, 2012 at 9:05 PM, smichr wrote:
>
>
> On Friday, December 14, 2012 3:20:26 AM UTC+5:45, Aaron Meurer wrote:
>>
>> First off, what you are
I've opened https://code.google.com/p/sympy/issues/detail?id=3561 for these.
Aaron Meurer
On Fri, Dec 14, 2012 at 9:00 AM, Andreas Doerfler
wrote:
> Hello Sympifiers,
>
>
> I noticed some incorrect results for the following expressions
> (1*sin(oo)).n() # nan, correct
> (2*sin(oo)).n() # 0, shou
Le 14/12/2012 15:13, Shriramana Sharma a écrit :
How about this -- it doesn't seem as if Matrix has any operator() i.e. __call__:
from sympy import Matrix
a=Matrix(2,2,(1,2,3,4))
a(1,1)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'MutableMatrix' object is not callabl
Thanks people for your replies.
On Sat, Dec 15, 2012 at 7:07 AM, Aaron Meurer wrote:
> If you use ImmutableMatrix instead of Matrix, then it will have the
> replace method (as well as any other method of Basic). The downside
> is that the matrix won't be mutable.
OK, but I don't get it -- what
On Fri, Dec 14, 2012 at 9:17 PM, Shriramana Sharma wrote:
> Thanks people for your replies.
>
> On Sat, Dec 15, 2012 at 7:07 AM, Aaron Meurer wrote:
>> If you use ImmutableMatrix instead of Matrix, then it will have the
>> replace method (as well as any other method of Basic). The downside
>> is
16 matches
Mail list logo
