This could be achieved by defining Eq's behaviour wrt addition,
multiplication by expressions or other Eq objects.
On Friday, September 12, 2014 5:07:56 AM UTC+2, Rathmann wrote:
I have been playing with SymPy and IPython Notebook and thought it
would be useful to be able to explicitly
Some of Eq's problems:
In [1]: srepr(Eq(x, y)*2)
Out[1]: Mul(Integer(2), Equality(Symbol('x'), Symbol('y')))
In [2]: Eq(x, y)*2
Out[2]: 2⋅x = y
The formatted output is wrong, the tree expression corresponds to Mul(2,
Eq(x, y)), not to Eq(Mul(2, x), y) as it looks like in the formatted output.
Here we go: https://github.com/sympy/sympy/pull/8023
--
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
We need to make sympy.diffgeom and sympy.tensor.tensor work together.
Unfortunately the way is still long.
Basically, sympy.tensor.tensor is meant to represent tensors by a symbol.
It currently supports tensor polynomials in the abstract index notation,
but I am (slowly) working on expressing
On Saturday, August 30, 2014 1:21:36 PM UTC+2, Sergey Kirpichev wrote:
I don't think there's a big issue with this, because already
`ask(Q.real(x))` and `x.is_real` are different. My proposal is to have the
first call the second but not the other way around.
That's impossible now.
I fear that SymPy's matching of multiplicative inverses may be a problem in
RUBI, as the matcher may match too much.
By the way, assumptions should get to work on the patterns, currently they
seem not to work:
In [2]: x = symbols('x', real=False)
In [3]: w = Wild('w', real=True)
In [4]:
OK, by the way I see it an alternative structure for SymPy's pattern
matcher could be to define .match( ) in Basic only and cleverly use method
inheritance. That is:
- express associativity through a static field (e.g. is_Associative)
- same if the type is an identity when given only one
*:
- associativity awareness (i.e. f(a, b, c) = f(a, f(b, c)) and similar):
(a+b+c).match(a+w) == {w: b+c}
- commutativity awareness:
(a+b).match(w+a) == {w: b}
- one-identity awareness (f is one-identical if f(x) = x for any x):
x.match(Add(w, evaluate=False)) == {w: x
On Saturday, August 23, 2014 9:26:55 PM UTC+2, Aaron Meurer wrote:
For example, an addition of n terms has 2**n sub-expressions of just
taking all possible combinations of terms to make smaller additions (that
doesn't even count the subexpressions of the terms themselves). That also
What about creating a new branch on github to gradually integrate the new
assumptions? This could be merged with master once the integration is
complete.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop
I think your problem is a bit general, and it requires a combination of
tools.
On Saturday, August 23, 2014 1:38:36 AM UTC+2, Ondřej Čertík wrote:
Some examples:
e = x^2+2*x*y+*y*^2
s1 = x+y
Maybe this could be done using a solver, the condition *e-s1* being true
for all *x, y*?
Maybe this could be a good opportunity to introduce the multiple dispatch
library to SymPy. Maybe integrate could become a generic method. @Matthew what
do you think?
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and
Concerning the new assumptions to be added for the pattern matcher, is it
possible to use the assumption system by creating new assumptions outside
of the assumptions module?
For example, Q.freeof( ) would be better placed in a pattern matching
module, rather than in the assumptions module,
On Friday, July 18, 2014 5:33:02 PM UTC+2, Aaron Meurer wrote:
On Fri, Jul 18, 2014 at 6:38 AM, F. B. franz@gmail.com javascript:
wrote:
On Friday, July 18, 2014 5:05:37 AM UTC+2, Ondřej Čertík wrote:
This is also the sort of thing that would benefit from a performant
On Saturday, July 19, 2014 9:30:34 PM UTC+2, F. B. wrote:
Consider the wild *a_.* in the expression above. *a_* would be an
ordinary wild, while the dot tells you that if there is no match for *a_*
in the expression, than *a_ *should be matched as the identity element of
operation
On Tuesday, July 15, 2014 11:28:11 PM UTC+2, Matthew wrote:
Use sympy.stats, not sympy.statistics
sympy.statistics has been removed from the master branch. It will no longer
exist as soon as the next SymPy version is released.
--
You received this message because you are subscribed to
On Saturday, July 12, 2014 6:02:50 AM UTC+2, Richard Fateman wrote:
In addition to Mathics, you could look at MockMMA, free of license
restrictions,
written in Lisp.
I had a look at http://sourceforge.net/projects/mockmma/
It says it's licensed under the GPL, which is incompatible with
On Wednesday, July 9, 2014 5:29:51 PM UTC+2, Joseph Smidt wrote:
Sympy has a great tensor and differential geometry module. I would
appreciate if the developers added spin connections [1] to one of these
modules. Thanks.
[1] http://en.wikipedia.org/wiki/Spin_connection
There is still
On Sunday, July 6, 2014 8:36:38 AM UTC+2, Joachim Durchholz wrote:
I agree it would be nice to be able to explore the different ways to
apply matches.
All of SymPy's matchers so far were concerned in matching the whole
expression. A user may have a huge expression, and be willing
On Saturday, July 5, 2014 9:30:36 PM UTC+2, Sachin Joglekar wrote:
Hello everyone,
In designing the vector module, I have defined a class called 'Del', whose
instances will act as the Del operator http://en.wikipedia.org/wiki/Del
for the coordinate system it is assigned to.
An example
On Friday, July 4, 2014 9:14:29 PM UTC, Joachim Durchholz wrote:
Am 03.07.2014 21:39, schrieb F. B.:
I updated the draft:
https://github.com/sympy/sympy/wiki/Proposal-for-a-new-pattern-matching
The page uses the term unification without defining it.
Given that there are multiple
On Friday, July 4, 2014 4:12:25 PM UTC, Matthew wrote:
Only semi-related, but here is a small pattern matching project. It's
strictly for non-associative operators and so not appropriate for SymPy.
It does function decently though
https://github.com/mrocklin/unification
By the way,
On Friday, July 4, 2014 1:08:41 AM UTC+2, Aaron Meurer wrote:
I see. Wouldn't the pattern matcher not match in that case, because
Basic(a, b, c, d) has four arguments and Symbol('x') has none?
Suppose you have Symbol(wild_sequence), i.e. ordinary wilds match only one
node, while wild
On Friday, July 4, 2014 2:20:07 AM UTC+2, Matthew wrote:
This is easier if we stop automatic evaluation on classes. I usually
propose that the classes like `Add` do no construction logic while paired
functions like `add` take on all of the construction logic. Then you can
create
I updated the draft:
https://github.com/sympy/sympy/wiki/Proposal-for-a-new-pattern-matching
The two problems I have identified so far:
- type inheritance and subelement matching (see Typed patterns section)
- Non-commutative elements (see Orderless and SymPy section)
Any ideas?
--
On Thursday, July 3, 2014 11:43:13 PM UTC+2, Aaron Meurer wrote:
I'm just now catching up on the other thread. I'll post more comments
there.
To answer your question, A subclass shall match its parent, but in
case its parent's constructor accepts different parameters, strange
things
On Friday, July 4, 2014 12:09:37 AM UTC+2, F. B. wrote:
otherwise an exception is probably going to be raised.
By the way, that's another major problem. Mathematica allows to write any
expression tree, even those that are mathematically incorrect. In SymPy,
many constructors raise
On Thursday, July 3, 2014 11:46:21 PM UTC+2, Aaron Meurer wrote:
On Mon, Jun 23, 2014 at 10:02 AM, F. B. franz@gmail.com javascript:
wrote:
I suggest to keep the Mathics implementation of pattern matching as a
reference. It should be compatible with Mathematica, but, unlike
I suggest to keep the Mathics implementation of pattern matching as a
reference. It should be compatible with Mathematica, but, unlike
Mathematica, we can access Mathics' source code.
On Sunday, June 22, 2014 9:29:29 PM UTC+2, Aaron Meurer wrote:
Thanks for writing this up. My
On Monday, June 23, 2014 5:02:27 PM UTC+2, F. B. wrote:
I mean, you can use the alternatives to match more patterns at the same
time. Something like:
x_**n_ | x_
which would match both Symbol(x) and Pow(x, n).
This is also an example in which default values could be useful. In case
On Saturday, June 21, 2014 5:37:52 AM UTC, Saurabh Jha wrote:
I think this should not be very difficult to implement using inbuilt 're'
module of python. I can submit a PR regarding this thing
Why the 're' module?
--
You received this message because you are subscribed to the Google
On Monday, June 16, 2014 2:27:32 PM UTC+2, Sachin Joglekar wrote:
Once this gets polished, I can move on to implementing coordinate systems.
Currently all operations occur in a single, 'default' frame.
Maybe you should have a look at CoordSystem in the differential geometry
module:
I wrote some ideas:
https://github.com/sympy/sympy/wiki/Proposal-for-a-new-pattern-matching
On Monday, June 9, 2014 9:36:50 AM UTC+2, F. B. wrote:
On Sunday, June 8, 2014 3:38:23 AM UTC+2, Matthew wrote:
I think that SymPy needs a better term rewriting system. And also a
better pattern
I was pondering about a possible way to create a C++ code generator from
SymPy.
The latest C++ standard (C++11) introduced some kinds of features that
could make the code generation easier, especially lambda functions and auto
variables. The boost C++ library also offers a great range of tools
On Sunday, June 8, 2014 3:38:23 AM UTC+2, Matthew wrote:
I think that SymPy needs a better term rewriting system. And also a
better pattern matcher.
@Franz Are you interested in doing work in this area?
Maybe the best we can do is to set up a page on SymPy's wiki to propose an
The point is that the current pattern matcher only matches exact subtrees
starting at one node, i.e. the tree of that node has to be matched entirely,
while in many cases partial subtree matches would be desired.
In any case the expression to_abs can be further simplified. Try something like
Sorry instead of rl try to put lambda x: next(rl(x)) into the exhaust ( ... )
expression.
--
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
As you have a string representation of your object, a non-sympy way is by
using string regex:
In [1]: expr = eval(Add(Mul(Integer(-1), Integer(2), Symbol('g'),
Symbol('psi^ss_1'), conjugate(Symbol('psi^ss_1'))), Mul(Integer(-1),
Integer(2), Symbol('g'), Symbol('psi^ss_2'),
₂ + ─
4⋅m
On Friday, June 6, 2014 9:13:15 AM UTC+2, F. B. wrote:
As you have a string representation of your object, a non-sympy way is by
using string regex:
In [1]: expr = eval(Add(Mul(Integer(-1), Integer(2), Symbol('g'),
Symbol('psi^ss_1'), conjugate(Symbol('psi^ss_1'))), Mul(Integer
On Friday, June 6, 2014 2:36:34 AM UTC+2, jeanbi...@gmail.com wrote:
var('A,B,C,D,u,v,qi,qf')
qi = 1/(u-I*v)
qf = (A+B/qi)/(C+D/qi)
First of all, you don't need to declare *qi* and *qf* in var( ... ),
because they get overwritten in the next expressions.
By the way, maybe you mean that
On Friday, June 6, 2014 12:22:14 PM UTC+2, Andrei Berceanu wrote:
Tnx!
I think there is an error in the line (unbalanced paranthesis):
return node.xreplace ({e: S.One, conjugate(e): S.One})*abs(e)**2)
Yes, sorry, just remove the last parenthesis.
Also, do you know how I can force the
unchanged :)
On Friday, June 6, 2014 1:07:26 PM UTC+2, F. B. wrote:
On Friday, June 6, 2014 12:22:14 PM UTC+2, Andrei Berceanu wrote:
Tnx!
I think there is an error in the line (unbalanced paranthesis):
return node.xreplace ({e: S.One, conjugate(e): S.One})*abs(e)**2)
Yes, sorry, just
On Friday, June 6, 2014 1:34:04 PM UTC+2, Andrei Berceanu wrote:
The unflatten_mul function factorized the 2, but not the g, i.e. it returns
2(g*|psi1|**2 + g*|psi2|**2)
instead of
2g*(|psi1|**2 + |psi2|**2)
Try to do so:
def get_unflattener(m):
m_args = list(m.args)
I think that SymPy needs a better term rewriting system. And also a better
pattern matcher.
--
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
I had a look at SymPy, it looks like this:
In [1]: solve(cos(3*x), x)
Out[1]:
⎡π π⎤
⎢─, ─⎥
⎣6 2⎦
In [2]: solve(cos(n*x), x)
Out[2]:
⎡ π 3⋅π⎤
⎢───, ───⎥
⎣2⋅n 2⋅n⎦
It looks like the cos( ) solver just thinks that cos( ) can be zero at two
points (pi/2 and 3*pi/2), then calls a solver to
On Saturday, May 31, 2014 1:26:59 AM UTC+2, Aaron Meurer wrote:
There is the Subs object. Is that what you're looking for?
I had a look, unfortunately the Subs object does not retain the tensor
class structure, that is one cannot perform operations such as
.substitute_indices( ) on a
On Saturday, May 31, 2014 9:12:08 AM UTC+2, mario wrote:
One could rename the current tensors, calling them tensor polynomials,
reserving the name tensor expressions to your new version.
The former can be used when one needs fast tensor polynomial manipulations
(always expanded
More than the logic contained in PRESS, I would get inspiration for the
programming style.
The current sympy solve has a lot of manual dispatching through IF and
recursion. The code is hard to read, and you also need a debugger to
understand what happens to expressions. I would suggest to
By the way, just some considerations about the Prolog approach to equation
solving. In short, Prolog tries to determine the largest set that satisfies
all given rules. I guess that if PRESS misses some rules, it will end up
showing too many solutions, because the solution set has not been
I am currently refactoring sympy.tensor.tensor in order to express tensor
expressions as argument trees (the current master version only allows
expanded polynomials). Basically, in my new concept, objects inheriting
TensExpr will possess methods allowing to access the index structure. Every
On Thursday, May 29, 2014 2:29:26 AM UTC+2, rl wrote:
Hi,
If we want to improve our equation solver in the range of transcendental
equations, it might be interesting to look at PRESS [1]:
PRESS (PRolog Equation Solving System) is a system for solving
symbolic, transcendental,
On Tuesday, May 13, 2014 8:02:22 PM UTC+2, Abhishek K Das wrote:
It requires an Interval as the third input parameter , what you are
passing is basically a tuple of two numbers . If you write it as
Interval(0,oo) instead of (0.oo) .
It works fine !
In [4]: X = ContinuousRV(x,
On Wednesday, May 14, 2014 8:41:35 AM UTC+2, Abhishek K Das wrote:
I was checking the physics module and saw there is nothing on relativistic
mechanics as of now .
Is anyone working on that ? I would like to contribute in that or
otherwise start implementing it .
Are you interested in
Sorry for the logic error in my previous post. In any case, what about this:
In [15]: X = ContinuousRV(x, exp(-x), Interval(0, oo))
In [16]: P(X 1/2)
Out[16]:
-1/2
- ℯ + 1
In [17]: P(X log(2))
AttributeError: 'bool' object has no attribute 'is_Piecewise'
This one still looks like
Sorry again, I wasn't using the latest version from master, in any case:
In [1]: from sympy.stats import *
In [2]: from sympy import *
In [3]: ;var x
Out[3]: x
In [4]: X = ContinuousRV(x, exp(-x), Interval(0, oo))
In [5]: P(X log(2).n())
Out[5]: 0.500
In [6]: P(X log(2))
On Wednesday, May 14, 2014 10:07:12 AM UTC+2, Abhishek K Das wrote:
I am interested in special relativity .
Okay , the thing is I am currently an undergraduate in electrical
engineering . I had a basic course on special relativity .
I don't know about Minkowski space and stuff . I was
On Wednesday, May 14, 2014 10:55:47 AM UTC+2, Abhishek K Das wrote:
How much have you implemented ? May be I can also help . I will study the
theory that is required .
Concerning relativity itself, I haven't implemented anything.
If you are willing to go on, may I suggest you a simple
On Wednesday, May 14, 2014 11:28:54 PM UTC+2, Matthew wrote:
Generally when debugging sympy.stats I recommend inspecting the integrals
that it produces using the evaluate=False keyword. Sympy.stats almost
always shoves off most of the hard work onto another SymPy module like
integrals.
I tried this:
In [1]: from sympy.stats import ContinuousRV, P
In [2]: var('x')
Out[2]: x
In [3]: X = ContinuousRV(x, exp(-x), (0, oo))
In [4]: P(X Rational(1,2))
TypeError: Input must be Sets or iterables of Sets
I get the right answer when avoiding the stats module:
In [6]: var('k')
It looks like someone is experimenting a new CAS in clojure using logic
programming via a Clojure port of miniKanren (clojure.core.logic):
https://github.com/clojure-numerics/expresso
I just want to share this in case anyone is interested. It looks like the
code is very concise.
--
You
I use either Eclipse with the PyDev plugin, or vim and ctags. They can both
perform regex search on Python's AST.
Eclipse has also an excellent and easy-to-use debugger.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group
I think it's a problem with the printer:
In [1]: a = Add(3, 2, evaluate=False)
In [2]: a.args
Out[2]: (3, 2)
In [3]: a
Out[3]: 2 + 3
The args are created in the correct order, it's the printer that apparently
reorders the values. The structural equality is False because (2, 3) is not
the
I am not very expert of parallel processing in Python, but as no one else
is answering, and supposing you mean multithreading, I'll point out the
problem concerned with multithreading in Python.
Python's main implementation, CPython, has a Global Interpreter Lock (GIL),
which forbids the
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
On Thursday, April 24, 2014 12:43:11 AM UTC+2, Matthew wrote:
Things like Function threw me off when I melded SymPy with LogPy (my
little logic programming system) or with Theano. It'll be nice for others
to run into these.
By the way, is there any implementation of MiniKanren in C++?
On Friday, April 18, 2014 4:15:36 AM UTC+2, Ondřej Čertík wrote:
Yes, this is a very cool feature of Julia. Btw, if any of you are
interested in this,
you can help us write and test Julia wrappers for CSymPy:
https://github.com/sympy/csympy
https://github.com/sympy/csympy/issues/150
On Friday, April 18, 2014 8:32:31 PM UTC+2, Aaron Meurer wrote:
Has anyone yet tried translating CSymPy to Julia and benchmarking it? I
personally would get more excited about Julia than C++. It has a vibrant
community, a cleaner design, higher level abstractions, and I think what
By the way, the dev docs are stuck to version 0.7.3
http://docs.sympy.org/dev/
--
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
I don't believe that the overhead caused by multiple dispatching would be a
problem for xreplace, considering that xreplace( ) opens recursively all of
the objects contained in the args tree and creates a new object. The major
issues are rather those concerning the API change.
In any case, as
In a recent PR I submitted it emerged that using sympy's Tuple instead of
list or tuple seems to cause a significant slow down of the code execution.
I blamed this behavior to the necessity of copying data from the list to
the Tuple object once the list has been created.
Currently args in
On Tuesday, April 15, 2014 11:28:58 AM UTC+2, Joachim Durchholz wrote:
Am 15.04.2014 11:04, schrieb F. B.:
What about turning methods such as xreplace(), subs(), has(), atoms(),
match() to multiple dispatched functions?
Performance?
Somebody (you) said that MD does not come for free
By the way, dictionary search in Python has a time complexity of O(1)
https://wiki.python.org/moin/TimeComplexity
I wouldn't bother too much about the overhead of using multiple dispatch.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe
On Friday, April 11, 2014 1:29:11 AM UTC+2, Aaron Meurer wrote:
There are probably little ways around these things, but nothing clean
without dispatching in the core.
Another point in favor of multiple dispatching.
By the way, tensor expressions should just become ordinary expression with
On Wednesday, April 9, 2014 1:36:56 AM UTC+2, Aaron Meurer wrote:
Yes, exactly. In Python, __eq__ really means equality, and things like
sets and lists will assume objects that return True with __eq__ can be
interchanged with one another. SymPy follows this convention. If a == b,
any
On Thursday, April 3, 2014 5:04:36 PM UTC+2, Aaron Meurer wrote:
Some people on this list might be interested in this
https://github.com/ContinuumIO/pyalge.
Indeed, that can be very powerful to symbolic math.
I don't really like their style of putting the string of the expression
inside
On Thursday, April 3, 2014 10:18:27 AM UTC+2, Joachim Durchholz wrote:
MRO is a reaonably good solution for 99% of the cases. 100% solutions do
exist but Python did not choose them (nor did any other language that
I'm aware of).
The latest edition of Java, i.e. Java 8 supports multiple
On Wednesday, April 2, 2014 6:41:39 AM UTC+2, Brian Granger wrote:
I strongly think that multipledispatch should be a separate project.
There is a good chance we would use this over time in IPython and I
definitely plan on using in various codes I write outside of SymPy.
Maybe multiple
By the way, what about using the test cases to tag the types of all of
SymPy's methods by the @dispatch decorator?
That can be useful to try an automated translation to C++ or some other
language.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To
On Wednesday, April 2, 2014 5:09:19 PM UTC+2, Ondřej Čertík wrote:
As far as performance goes --- what are the bottlenecks? Is Julia's
multipledispatch the same fast?
If it is faster, can multipledispatch be made faster too?
Julia uses type inference and LLVM. I think that whenever the
OK, after the last PR has been merged, I did some tests on the indices and
there are still problems with .match( ) and .replace( ), while .subs( ),
.replace(..., simultaneous=False), and .xreplace( ) seem to work. The
current problem is that wilds are not allowed in the expression tree,
On Wednesday, April 2, 2014 7:35:45 PM UTC+2, Matthew wrote:
Yeah, Wild subclasses from Expr, alas. The logpy solution is to have a
dispatched isvar function.
It seems to me that the all tensor indices are in some sense wild.
Shouldn't A[i, -i] unify to A[j, -j] ?
Actually not,
On Wednesday, April 2, 2014 9:56:29 PM UTC+2, Matthew wrote:
Right, but ideally A(i, -i, j) and A(j, -i, i) *wouldn't unify. *Actually
in this sort of case I suppose that they would because it could be that i
== j.
Mmm, you're right. I didn't consider this problem. I believe that some
On Sunday, March 30, 2014 4:09:47 PM UTC+2, Stefan Krastanov wrote:
Here is an example why `__eq__` should correspond to structural equality:
class a(object):
... def __eq__(self, other):
... raise NotImplementedError()
...
i = a()
list = [1,2,3,i]
By the way, I missed another point in my previous posts, we also need a
representation for tensor fields, i.e. tensors depending on another
scalar/tensor, like $$ A^\mu (x^\nu) $$.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from
OK, I addressed the issue pointed out by Krastanov, namely that *__eq__*should
be a structural equality, and not a mathematical equality:
https://github.com/sympy/sympy/pull/7357
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this
On Saturday, March 29, 2014 3:34:47 AM UTC+1, Aaron Meurer wrote:
On Fri, Mar 28, 2014 at 9:13 PM, Stefan Krastanov
stefan.k...@yale.edu javascript: wrote:
Stefan, can you give a brief explanation of your experience? In
particular
what difficulties did you run into?
The
By the way, when I was referring to an external tensor index symmetry
container, I meant something like what I'm doing here for the tensor
components:
https://github.com/sympy/sympy/pull/2805
This PR solves the issues of associating tensor components data to tensor
objects. Previously they
Actually I refactored the tensor module the last autumn and it now should have
invariant argument trees.
I don't know whether __eq__ overloading may be an issue to unify, as well as
the standard __hash__ for tensor expressions.
The issue now is more about how to represent operators on tensors
I came to the conclusion that the best solution to implement Quantum Field
Theory in SymPy is to use the *unify* module combined with the new
*tensor*module.
Unfortunately the new *tensor* module has a complicated arg-tree structure.
The main problems concerning the implementation of QFT
The second point concerns unification of tensor, there are some issues on
contracted indices, with some boilerplate
from sympy.tensor.tensor import *
L = TensorIndexType('L')
i0, i1, i2 = tensor_indices('i0:3', L)
A = tensorhead('A', [L]*2, [[1]*2])
The arguments
A(i0, i1).args
(1, (A(L,L),),
On Friday, March 21, 2014 4:35:08 PM UTC+1, Matthew wrote:
Efficient pattern dispatch is hard, particularly when you have associative
and commutative operators. If we don't care about
associativity/commutitivity then it's fairly doable. This is the sort of
thing I would build in my
Please also take care of this bug:
https://github.com/sympy/sympy/blob/master/sympy/physics/hep/gamma_matrices.py#L8
DiracSpinorIndex is the index for the Dirac matrices, its dimension is
fixed to 4, it is a TensorIndexType, i.e. the class used to generate the
actual indices to be placed into
On Saturday, March 22, 2014 3:26:36 PM UTC+1, Matthew wrote:
@Matthew Rocklin: would you try to generalize your multiple dispatch
module to pattern dispatch?
The multipledispatch package will only be about dispatch against types.
This package is intended for general programming and so
On Saturday, March 8, 2014 4:23:50 AM UTC+1, Matthew wrote:
I do like the idea of dispatch. I'm not sure that I understand the rest
though. Maybe I need a more explicit example. We'll probably have to
convert back at some point.
As soon as there is multiple dispatch, an approach
On Monday, March 10, 2014 7:16:41 PM UTC+1, Joseph Smidt wrote:
Brombo,
I appreciate that there is an alternative formulation of EM but I am
wondering is sympy has the capability to do these calculations? If so, is
there any relevant documentation or examples in sympy you could point
On Thursday, March 6, 2014 1:41:21 PM UTC+1, F. B. wrote:
On Thursday, March 6, 2014 6:10:10 AM UTC+1, Matthew wrote:
I actually do believe that a core for expressions with indices is
possible here. But I don't have as much experience as Kasper, so I could
be wrong.
What about
On Thursday, March 6, 2014 6:10:10 AM UTC+1, Matthew wrote:
I actually do believe that a core for expressions with indices is possible
here. But I don't have as much experience as Kasper, so I could be wrong.
What about using type conversion and promotion? A tensor core wouldn't
really
On Wednesday, March 5, 2014 2:53:29 AM UTC+1, Charlie Paul wrote:
I'm interested in doing the Tensor Core project for GSoC.
That's good news.
Other than the standard physics fare and a couple semesters of linear
algebra, I've also taken differential geometry.
SymPy currently also
On Tuesday, March 4, 2014 6:18:18 AM UTC+1, Chase Relock wrote:
I was looking at SymPy's matrix code and was curious if that supports
symbolic computation right now or is it only numeric?
Of course you can put symbols inside sympy matrices (if that is what you
mean), for numeric-only
On Wednesday, February 19, 2014 9:04:22 PM UTC+1, Matthew wrote:
I've recently become interested in multiple dispatch. I know that this
has been a topic of conversation before. Can anyone point me to relevant
threads? I've gone through the recent PR by @Upapjojr
1 - 100 of 250 matches
Mail list logo
