Re: [sympy] What is out there for SymPy code generation / optimizing compiler effort?
> > what is your wishlist for SymPy? ND-Arrays -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EBfwDuBxH_angWKnKYdf1LKkD5kjAUzee8yvvy6fduAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Integrate over Union of Interval's
Matthew... what do you think of the union of intervals as an alternative
to the usual ranges in integrate/Integral?
Seems like a decent plan. I haven't been actively working on stats in a
while so I don't have strong opinions here.
On Thu, Mar 26, 2015 at 6:50 PM, Aaron Meurer asmeu...@gmail.com wrote:
I think integrating over sets is a useful thing to allow, but we
definitely need to be more careful about symbolic intervals. And given
that, it probably means that sympy.stats should just do normal
integrals, since it can make assumptions about symbolic intervals that
won't be present when passed to Integral.
Aaron Meruer
On Thu, Mar 26, 2015 at 6:54 PM, Francesco Bonazzi
franz.bona...@gmail.com wrote:
Matthew... what do you think of the union of intervals as an alternative
to
the usual ranges in integrate/Integral?
I suppose that you wrote the code outputting that integral, which
currently
does not work, and I want to make it work.
I am undecided on whether to edit sympy.stats in order to give Integral(
...
, (x, -oo, -1)) + Integral( ... , (x, 1, oo)) instead of Integral( ... ,
(x,
Union(Interval(-oo, -1), Interval(1, oo.
On the other hand, this alternative notation may be useful.
Unfortunately it
would require some algorithmic changes and I am a bit wary about a
substantial edit of the integration algorithm.
On Thursday, March 26, 2015 at 9:12:37 PM UTC+1, Matthew wrote:
You don't need to square the random variable to compute the result. You
just need to integrate the pdf over x -1 and x 1
On Thu, Mar 26, 2015 at 5:42 AM, Francesco Bonazzi franz@gmail.com
wrote:
Well, I was a bit surprised too, but the stats module apparently does
so,
as shown in this example:
In [1]: from sympy.stats import *
In [2]: var('sigma', positive=True)
Out[2]: σ
In [3]: N = Normal('X', mu, sigma)
In [6]: P(N**21, evaluate=False)
Out[6]:
(-∞, -1) ∪ (1, ∞)
⌠
⎮2
⎮-(z - μ)
⎮──
⎮ 2
⎮ ___ 2⋅σ
⎮ ╲╱ 2 ⋅ℯ
⎮ ─ dz
⎮ ___
⎮ 2⋅╲╱ π ⋅σ
⌡
In [7]: srepr(P(N**21, evaluate=False))
Out[7]: Integral(Mul(Rational(1, 2), Pow(Integer(2), Rational(1, 2)),
Pow(pi, Rational(-1, 2)), Pow(Symbol('sigma'), Integer(-1)),
exp(Mul(Integer(-1), Rational(1, 2), Pow(Symbol('sigma'), Integer(-2)),
Pow(Add(Dummy('z'), Mul(Integer(-1), Symbol('mu'))), Integer(2),
Tuple(Dummy('z'), Union(Interval(-oo, Integer(-1), S.true, S.true),
Interval(Integer(1), oo, S.true, S.true
Apart the fact that such an integral looks wrong to me, i.e. there is
no
account for the random variable being squared (or am I missing
something?),
it looks like SymPy is OK with intervals, but not with unions of
intervals:
https://github.com/sympy/sympy/blob/9242d31f6d31a1d9c3464264a5a6e61eab8acfb8/sympy/concrete/expr_with_limits.py#L37
That's the point where an Interval gets parsed by the integration
algorithm.
I think it's an easy fix to add the processing for unions of intervals.
--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/230fe8c3-a834-4074-920d-435a2687be36%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/c3701c8c-3577-45a0-afdd-2a000bcd32d8%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6LbcosAeX6FeM0y%2Bb%3D50yrpDUK%3DiVpKhsNqKEh7A46W5A%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed
Re: [sympy] Integrate over Union of Interval's
You don't need to square the random variable to compute the result. You
just need to integrate the pdf over x -1 and x 1
On Thu, Mar 26, 2015 at 5:42 AM, Francesco Bonazzi franz.bona...@gmail.com
wrote:
Well, I was a bit surprised too, but the stats module apparently does so,
as shown in this example:
In [1]: from sympy.stats import *
In [2]: var('sigma', positive=True)
Out[2]: σ
In [3]: N = Normal('X', mu, sigma)
In [6]: P(N**21, evaluate=False)
Out[6]:
(-∞, -1) ∪ (1, ∞)
⌠
⎮2
⎮-(z - μ)
⎮──
⎮ 2
⎮ ___ 2⋅σ
⎮ ╲╱ 2 ⋅ℯ
⎮ ─ dz
⎮ ___
⎮ 2⋅╲╱ π ⋅σ
⌡
In [7]: srepr(P(N**21, evaluate=False))
Out[7]: Integral(Mul(Rational(1, 2), Pow(Integer(2), Rational(1, 2)),
Pow(pi, Rational(-1, 2)), Pow(Symbol('sigma'), Integer(-1)),
exp(Mul(Integer(-1), Rational(1, 2), Pow(Symbol('sigma'), Integer(-2)),
Pow(Add(Dummy('z'), Mul(Integer(-1), Symbol('mu'))), Integer(2),
Tuple(Dummy('z'), Union(Interval(-oo, Integer(-1), S.true, S.true),
Interval(Integer(1), oo, S.true, S.true
Apart the fact that such an integral looks wrong to me, i.e. there is no
account for the random variable being squared (or am I missing something?),
it looks like SymPy is OK with intervals, but not with unions of intervals:
https://github.com/sympy/sympy/blob/9242d31f6d31a1d9c3464264a5a6e61eab8acfb8/sympy/concrete/expr_with_limits.py#L37
That's the point where an Interval gets parsed by the integration
algorithm.
I think it's an easy fix to add the processing for unions of intervals.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/230fe8c3-a834-4074-920d-435a2687be36%40googlegroups.com
https://groups.google.com/d/msgid/sympy/230fe8c3-a834-4074-920d-435a2687be36%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-GTu35YvjPBpApeokZ6fued9iBHYzD7o9vB1YUSmDryJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: PyDy Website Sprint this weekend Sat February 7, 2015 18:00-3:00 UTC
Locations Davis/Sacramento (10:00 - 19:00 PST) Gilbert Chris Jason Luke Minneapolis (12:00 - 21:00 CT) Jim Clearly Jim needs to move out to the West Coast. On Mon, Feb 2, 2015 at 1:27 PM, Jason Moore moorepa...@gmail.com wrote: BTW, if you are intending to apply to GSoC (which we are likely to do again this year), this would be a good time to introduce yourself and get acquainted with the project. Jason moorepants.info +01 530-601-9791 On Mon, Feb 2, 2015 at 1:08 PM, Jason Moore moorepa...@gmail.com wrote: Howdy PyDy and SymPy folks, We are having a small one day sprint this weekend to get the PyDy website into the modern age. Some of us will be in the same physical location and others working elswhere via a Google Hangout. Details are posted here: https://github.com/pydy/pydy/wiki/PyDy-Website-Sprint-February-2015 and new info will be posted as the date arrives. Any and all are welcome to join. 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+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AivaRYfmqw711z1VbWBcAW6T4hwhbgys6nx67RhjjJ-8w%40mail.gmail.com https://groups.google.com/d/msgid/sympy/CAP7f1AivaRYfmqw711z1VbWBcAW6T4hwhbgys6nx67RhjjJ-8w%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FAFMvdTK%3DkSzqoYo0JEiqtJ1ar1NdfHbS72VjQk%2B-aNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Wow. (was: Add pep8 config, use pep8 in travis (#8538))
Looking at the conversation you two look frustrated but still pretty civil; I'm actually impressed at how civil both of you are given that it's a PEP8 conversation. I have experienced far less civil and constructive conversations on PRs in SymPy without them being locked to people officially listed as collaborators. Personally I'm wary of locking issues. Historically SymPy has done really well at making people feel welcome. This has been really helpful for the project. Locking a conversation risks pushing someone away for good. Joachim has been around a while and I've found that he generally has useful things to say. It'd be a shame if he was pushed away. Still, prolonged conversation can get in the way of actual progress. My preferred method of conflict resolution is to appeal to Aaron to make a final decision. I think that all of us trust Aaron to listen to all sides and then make decisions that are best for the project. Just my two cents, Best, -Matt On Fri, Jan 2, 2015 at 4:02 AM, Sergey Kirpichev skirpic...@gmail.com wrote: On Friday, January 2, 2015 10:37:40 AM UTC+3, Joachim Durchholz wrote: Wow. Locked out without fair warning. No community consensus either. Yes. I would like to see constructive discussion in that thread. When (and if) consensus will be reached among collaborators, we can unlock the thread again. After all, this PR is not so important. Am 01.01.2015 um 20:00 schrieb Sergey B Kirpichev: On Thu, Jan 01, 2015 at 09:33:20AM -0800, Joachim Durchholz wrote: You can't claim that you're impartial after all. Why not? Conflict of interest. Duh. I don't have other interests here, except for making SymPy better. And we have a clear policy on how to do this: https://github.com/sympy/sympy/wiki/Development-workflow#requirements-for-inclusion -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ffec5b8b-ee6e-4cfc-a6b5-23c4f2834c61%40googlegroups.com https://groups.google.com/d/msgid/sympy/ffec5b8b-ee6e-4cfc-a6b5-23c4f2834c61%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EPdQv6adGTgAz%3DLS2CvcNk8f7qktAJe2uLoghub_DUcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Convolution of a size-one pulse with itself
Hrm, that is unfortunate. Hopefully the issue helps. I've taken the liberty of renaming it to terms that I think will stand out in Sympain's minds, On Thu, Jan 1, 2015 at 9:51 PM, Mark Wiebe mwwi...@gmail.com wrote: I've tried a few different ways to get sympy to integrate a convolution of a pulse from -0.5 to 0.5 with itself, but everything I try produces exceptions or what looks like incorrect results. I've got a gist showing a couple of my attempts at http://nbviewer.ipython.org/gist/mwiebe/48bed4e5d52335c47e25 . I worked this out with pen+paper, but wanted to show how nicely one could use sympy to derive it, only to find that everything I try fails. Any suggestions for this, or is this something I shouldn't expect sympy to be able to do? Thanks, Mark -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/af263990-8900-454b-b0e7-726038f59e50%40googlegroups.com https://groups.google.com/d/msgid/sympy/af263990-8900-454b-b0e7-726038f59e50%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fc-CxeZiUe4%2BiXyfuPahN%2BN%2B%3DSuSn_H9pmyKQS%2BRZztw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Writing a fast pattern matcher, updates and questions
Matching against identities can be valuable. Writing out several variations for a intended single pattern feels like a hack. Or at least, that was my experience with my matrix expressions system. I wasn't able to cleanly add in identities so I shoved in lots more patterns. Things worked. The prototype https://github.com/mrocklin/matrix-algebra, written in Maude, supported identities. I found this pleasant (though reimplementing Maude seems hard). On Sat, Nov 29, 2014 at 2:57 PM, Joachim Durchholz j...@durchholz.org wrote: Am 29.11.2014 um 18:52 schrieb James Crist: The system described in the Jenks paper would work better than what I've written if we plan to use relatively small sets of small patterns. Larger patterns, or larger rulesets will work better with what I'm writing, (I think), as they will have more potential paths, and generating specialized predicates for each path will get increasingly expensive. If you're after how a standard set of patterns might look like, Rubi might be a good start. See http://www.apmaths.uwo.ca/~arich/ . It's several thousand rules. IIRC, they have been carefully constructed to be non-overlapping (you can only apply a single rule at any time), so they might be too easy to really test the algorithm's design. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/547A4F57.6050902%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-ETMvEqcDzR2H6zseeQidJP7BkCL1Lyk_5WADttYxEFYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Writing a fast pattern matcher, updates and questions
Response in line
On Wed, Nov 26, 2014 at 3:19 PM, James Crist crist...@umn.edu wrote:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it needs some serious cleanup),
but as of now it is partly functional. Some notation:
T = set of known patterns. A trie like data structure is used to
preprocess these patterns to aid in fast matching.
s = expression to be matched
x, y = variables
a, b, c = constants
Awesome, thanks for doing this.
Currently the matcher can determine what patterns in T match s, in the
presence of associative and commutative symbols, as long as the pattern is
linear. By linear, I mean no repeated *variable* symbols (`x + y` is
acceptable, `x + x` is not). If no associative and commutative symbols are
present, it can also determine a match substitution to make `s` equivalent
with the pattern.
Some design questions before I continue work:
- Is there any use for just determining what patterns match, without
generating a match substitution? Determining if a match exists is faster
than determining a specific substitution. However, in the presence of
nonlinear patterns a substitution needs to be found to verify the match is
valid. This decision determines how tightly coupled the two algorithms will
be.
I can think of use cases but they're secondary. One might ask questions
like is this expression an element of known class of special functions?.
- Is there need for nonlinear patterns? I plan to account for them, but
they make the algorithm a bit more complicated. Nonlinear, AC pattern
matching is NP complete. Linear AC pattern matches can be found in
polynomial time.
I haven't thought much about this. Is X*X.T non-linear?
- In a general case, there can be many substitutions that match a specific
pattern mod AC. For example, given `t = x*y`, and `s = a*b*c`, this can
match with {x: a*b, y: c}, or {x:a, y: b*c}, etc... This is easy to account
for, and can be done lazily. Api-wise, are there cases where generating
more than one matching substitution are needed?
I believe so. Sometimes we have a condition that can't be expressed in
terms of patterns (e.g. pulling in assumptions) and so we fall back to
python iteration and finding the first in the sequence that matches some
python condition.
Another major use case is selecting the best match. In this case we
might also want to control the order in which matches come out of the
sequence so that matches that we think are best come first.
- The algorithm lazily determines matches. Currently preference is given to
matching variables before constants, but it could go the other way around.
i.e. if T = {a + b, x + b}, and s = a + b, then the matcher will find `x +
b` before `a + b`. I'd rather not make this configurable, as it complicates
things. The question is, do we want the most general match first, or the
most specific?
In my ideal world I might be able to decide the order in which we traverse
the tree of possible matches. I don't know exactly how your algorithm
works but, in some algorithms, we obtain a set of partial matches at each
step and then have to decide which branch to pursue first. I've found that
accepting a user-provided objective function is useful. It allows the user
to specify a greedy search strategy.
More generally I've found that controlling the traversal midstream is of
high-value. This might have been in my particular use case though.
- At the moment, the code is completely removed from dependence on sympy,
and can function on its own. As such, I'm planning on making it a separate
library that can be used by SymPy as a dependency. I understand we were
against that in the past, but this may be changing? I'd rather not maintain
two separate codebases.
Hooray!
- There's a `commutative` assumption in sympy, but there doesn't seem to
be an `associative` one. How can I check if a function/operator is
associative? Does this information need to be kept elsewhere?
Aaron mentioned AssocOp. FWIW I'm not sure that any Sets or MatrixExprs
use this, despite being at times associative. Perhaps they should. If one
wanted a hack they could just keep a set of known associative types
somewhere.
- Jim
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/42d9511d-e963-416f-9d4e-3e0435461422%40googlegroups.com
https://groups.google.com/d/msgid/sympy/42d9511d-e963-416f-9d4e-3e0435461422%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options,
Re: [sympy] The slowest of the slow
The stats test could be made significantly faster. Probably in many of these cases tests could be sped up with little effort. Knowing where to focus this effort seems really helpful. Thanks! On Sep 26, 2014 4:23 PM, Peter Brady petertbr...@gmail.com wrote: One of the reasons for the poor maintenance of the @slow label is (IMO) the lack of hard data. The native test suite via bin/test does not support timing. This is supported with py.test but the compatibility is still a bit sketchy. If we can get full py.test compatibility it will be 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 j...@durchholz.org wrote: Am 26.09.2014 um 17:13 schrieb Peter Brady: 1. Mark all the tests which report runtimes over 180s as skip 2. Introduce a new mark 'veryslow` or something like that so that these tests can still be run if someone chooses by setting the appropriate flag. Any thoughts? Votes? A test that's so slow that nobody is going to run it to completion is worthless. (Such a test might become useful as SymPy's algorithms improve.) I remember having seen slow tests complete in less than a second, and ordinary tests take a minute. Obviously, the @slow annotations aren't properly updates (I can imagine several reasons, many legit, how this can happen). I'd like to see that problem fixed before adding to it by introducing yet another annotation that isn't going to be maintained properly. Actually I suspect that the problem isn't that we don't mark @veryslow tests, but that the @slow markers aren't maintained well enough (I may be wrong, it's just a hunch). No votes from my side, just thoughts. :-) -- You received this message because you are subscribed to a topic in the Google Groups sympy group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/sympy/xDM4NHWP9cA/unsubscribe. To unsubscribe from this group and all its topics, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/5425C8A9.6010402%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALoNiQd8h7CFGQ9QjWk2y3wOXsdAdUybWdAuPFE8SCK5R%2BMoHg%40mail.gmail.com https://groups.google.com/d/msgid/sympy/CALoNiQd8h7CFGQ9QjWk2y3wOXsdAdUybWdAuPFE8SCK5R%2BMoHg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-H%3DNA7o1UeyfwdJxaG_-C-TeVvjYkKNh5SrzT7mu86uKQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] ufuncify now creates actual ufuncs
Cool
On Wed, Aug 27, 2014 at 8:07 PM, James Crist crist...@umn.edu wrote:
I still need to do some cleanups and add tests, but I finally have this
working and thought I'd share. I'm really happy with this:
In [1]: from sympy import *
In [2]: a, b, c = symbols('a, b, c')
In [3]: expr = (sin(a) + sqrt(b)*c**2)/2
In [4]: from sympy.utilities.autowrap import ufuncify
In [5]: func = ufuncify((a, b, c), expr)
In [6]: func(1, 2, 3)
Out[6]: 6.7846965230828769
In [7]: func([1, 2, 3, 4, 5], [6, 7, 8, 9, 10], 3)
Out[7]: array([ 11.44343933, 12.36052961, 12.79848207, 13.12159875,
13.75078733])
In [8]: from numpy import arange
In [9]: a = arange(10).reshape((2, 5))
In [10]: c = arange(10, 20).reshape((2, 5))
In [11]: b = 25
In [12]: func(a, b, c)
Out[12]:
array([[ 250., 302.92073549, 360.45464871, 422.57056 ,
489.62159875],
[ 562.02053786, 639.86029225, 722.8284933 , 810.49467912,
902.70605924]])
In [13]: type(func)
Out[13]: numpy.ufunc
This now does everything a numpy `ufunc` does normally, as it *is* a
ufunc. Codegen is hooked up to numpy api. Type conversion and broadcasting
are done automagically.
Caveats: only functions with a single output are accepted (this could be
changed to accept multi-output without much effort though). Also, as with
all unfuncs, input/outputs must all be scalars (no matrix/Indexed
operations allowed).
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/76e0fbbe-5ce4-43b7-855b-6ac821f6b8ae%40googlegroups.com
https://groups.google.com/d/msgid/sympy/76e0fbbe-5ce4-43b7-855b-6ac821f6b8ae%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-EHZXbd5aFFNRy7gJ0hcydpAsG2qxv7Py65DQ9cA9VUUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SymPy 0.7.6 release
Harsh's work isn't yet in. https://github.com/sympy/sympy/pull/7523 On Tue, Aug 26, 2014 at 9:28 PM, Tim Lahey tim.la...@gmail.com wrote: All of Kundan's pull requests that I reviewed have been merged, so unless he did some work after the deadline, all of his are in. Nothing from his work should block the release. He did find some issues with the non-linear ODE solver, but they shouldn't block the release. Cheers, Tim. On 27 Aug 2014, at 0:10, Aaron Meurer wrote: Now that GSoC is over, let's start thinking about doing a 0.7.6 release. Are there any major pull requests from GSoC that are still to be merged? Any other known changes that should block on the release? Aaron Meurer -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/CAKgW%3D6LtVFLB3pTqr2G1%3DvHoFnrQnCqqaxACTVjihToO6f0je g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/FB690B65-E1E4-4990-8380-2D54D5A3E3EB%40gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fj0uqifQEhFW%3DUbb_06%3DE%3D1EBKt9YV%2BF5qz_puR8jjTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Autowrap, ufuncify, and matrices
1. Maybe if mat is NULL then we malloc? But probably the answer is what you suggest with an explicit kwarg 2. Theano has a solution for this. It may be worth looking at how they handle broadcasting. While this is accessible through SymPy it looks like the SymPy documentation on this feature is sparse. My apologies. On Thu, Aug 14, 2014 at 3:11 PM, James Crist crist...@umn.edu wrote: This is part of my continuing my work on making sympy capable of generating code for evaluating matrix functions. So far the codeprinters and codegen is done(ish); all that's left is autowrap. Questions: 1. Should functions created by autowrap create matrices that would be in-out parameters in the resulting C code? Suppose the C header is: void func(double a, double b, double c, double mat[3][4]) Should `mat` be created in the wrapper code, so that the python function header is func(a, b, c)? The performance benefits vs pythonic-ness really have to do with the nature of the calculations. If `mat` is small, but has elements with lots of operations (as seen in sympy.physics.mechanics) then the performance hit is neglible. In contrast, if `mat` is big, but has simple elements, the hit is relatively large. Perhaps a kwarg? Or maybe if autowrap is passed (Eq(x, mat)) it will set an input matrix `x` to `mat`, otherwise it will return matrix `mat`? 2. What should `ufuncify` do with matrices? Jason messaged me earlier with a thought on this, I'll just paste his use case here as it explains it fairly well. A very common use case that I'm finding in all my dynamics work is to evaluate matrices in a tight loop for millions of iterations. It would be cool to pass in a sympy matrix and generate a function that would return a 3D numpy array when you evaluate the function with equal length arrays (or scalars) as args. For example: expr = Matrix([[a, b], [c, d]]) f = ufuncify((a, b, c, d), expr) out = f(rand(1e6), rand(1e6), rand(1e6), 1.5) out.shape == (1e6, 4, 4) This kind of broadcasting would be doable (but maybe complicated? I'm not sure.). The big question is, does this kind of behavior for `ufuncify` make sense? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/771f1dfa-0a80-49ed-9a88-76a690f4aa96%40googlegroups.com https://groups.google.com/d/msgid/sympy/771f1dfa-0a80-49ed-9a88-76a690f4aa96%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HYNuqbsU4iXsPi7KTbu4C1t5GO95jjyALOngnWySpeLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Matrix Code Generation Opinion Thread
@Matthew: Thanks, I think a lot of people could really use this. What my main goal is right now is to get the basework down for *evaluating* single matrices with expressions as elements. After that I plan on working though correlating MatrixExpr with blas/lapack functionality so that these operations can be low-leveled as well. I watched your SciPy talk on that, it was really interesting! Little more than I'm interested in (or capable of implementing), but it's a great idea. A more practical version of what was laid out in that talk would be useful. Currently my practical solution to that is to use Theano. The SymPy-Theano code generators translate sympy matrix expressions to theano array expressions nicely. Of course, this requires that you have Theano installed. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EFHqJP4ZGYCBJpv21D%3D9eE4fN7AYhodvrsJcLAiUuCYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Matrix Code Generation Opinion Thread
Thank you for working on this. I think that this is important work.
I would express my views by they happen to be completely in line with Tim's
response which mostly says that your intuition on this problem seems
sensible.
Thanks again,
-Matt
On Mon, Aug 4, 2014 at 4:13 PM, Jason Moore moorepa...@gmail.com wrote:
Jason
moorepants.info
+01 530-601-9791
On Mon, Aug 4, 2014 at 3:27 PM, James Crist crist...@umn.edu wrote:
I'm working on adding support ofr codegeneration with Matrix objects.
Currently an `indexed` type is supported that results in low-level
contiguous arrays. These are always converted into loops though (and I
don't really understand what they're for). In contrast, the intent here is
to provide support for generating matrices that are comprised of sympy
expressions (as seen frequently in `mechanics`). For example, the following
should *work* after this update:
mat = Matrix([sin(a), cos(b), tan(c)])
func = autowrap(mat)
func(1, 2, 3)
array([ 0.84147098, -0.41614684, -0.14254654])
I have some stuff working already, but have some question before I
progress further.
*1. Sympy Matrices are always 2 dimensional, should this be true of the
generated code as well?*
In numpy, the default is the minimum number of dimensions required. For
example, `array([1, 2, 3])` has only one dimension. In contrast, with sympy
`Matrix([1, 2, 3])` has 2 dimensions always (no way around). For
expressions that are inherently column/row vectors should a single
dimension array be created?
*- Pros:* Less nested data, many scipy routines require single dimension
arrays only (odeint)
*- Cons:* Multiplication and indexing will be different. For this reason
I'm kind of against switching, but I could be swayed. For example:
np_a = array([1, 2, 3])
sym_a = Matrix([1, 2, 3])
np_a.dot(np_a.T)# Perform Multiplication as done in
numpy
14
sym_a * sym_a.T # Perform Multiplication as done in
sympy
Matrix([
[1, 2, 3],
[2, 4, 6],
[3, 6, 9]])
np_a_res = np_a.reshape((3,1))# Reshape the array to be 2
dimensional
np_a_res.dot(np_a_res.T)# Multiply the 2 dimensional
numpy arrays. This results in the same as sympy
array([
[1, 2, 3],
[2, 4, 6],
[3, 6, 9]])
np_a[1, 0]
IndexErrorTraceback (most recent call
last)
ipython-input-265-9a4f4bee3353 in module()
1 np_a[1,0]
IndexError: too many indices
np_a_res[1,0]# Indexing works the same
in 2d as it would in sympy normally
2
SymPy only has 2D arrays (matrices) and column vectors are still
represented as 2D arrays (like Matlab). So I think we should stick to that
paradigm. You could have a flag that says make vectors 1D arrays if you
want to support that. But the C code in the backend, for example, is all
based on 1D arrays. The indexing in C to nD arrays is just syntactic sugar.
I suspect that is the same in fortran too.
Many numpy functions will broadcast so it may be the case that 2D column
vectors will work in most cases, but otherwise the user may need to use
.squeeze() to remove the unneeded dimension.
It makes sense to me to retain the same indexing in the numpy array as the
sympy matrix.
*2. Should the default be numpy arrays?*
I think yes. They are pretty much used everywhere in scientific python,
and should be supported. numpy.matrix is on its way out, and should not be
used in my opinion. Cython offers some support for generality, so that
anything that offers the buffer protocol can be used. f2py may do the same,
but I have little experience with it. Currently autowrap supports lists as
well. I think this is silly, and results in some inefficiencies. As they're
transformed into numpy.array internally in the call, the user must have
numpy installed, and should be able to do this themselves.
Yes, we should default to outputting numpy arrays and not support the
numpy matrix type. The numpy matrix type is going to eventually be
deprecated in numpy. No reason to use it in anything new.
*3. For inputting matrices to functions, `MatrixSymbol`, or
`DeferredVector`?*
Sometimes you may have a lot of input variables, have those variables
expressed as a vector of *known* length. Sympy offers two options for this:
`MatrixSymbol` and `DeferredVector`. They both seem to offer the same
intention, although `MatrixSymbol` seems to be used *way* more/have more
functionality. Currently I'm only supporting `MatrixSymbol`. The idea is
that this should be possible:
x = MatrixSymbol('x', 3, 1) #Acts as a vector
expr = x[1,1] + sin(x[2,1]) + cos(x[3,1])
func = autowrap(expr)
inp = np.array([1, 2, 3])
func(inp)
0.9193049302252362
Note that this is the inverse of the issue described in #1. This time
it's the function input that will have dimesion mismatch between what is
being input (a single dimension numpy vector, compared to a 2 dimension
Re: [sympy] SymPy talk at PyData Berlin
https://www.youtube.com/watch?v=XSRr2HHedrY
On Tue, Jun 10, 2014 at 8:57 AM, Aaron Meurer asmeu...@gmail.com wrote:
The SymPy code printers are also very extensible. It should not be
hard to add matrices support to the C printer, or to add a Matlab
printer (you can do so in your own code by subclassing the printer,
but we would also gladly accept pull requests that added this).
Aaron Meurer
On Tue, Jun 10, 2014 at 8:58 AM, Matthew Rocklin mrock...@gmail.com
wrote:
We do have ccode and fcode for C and Fortran
In [25]: fcode(sin(x)**2)
Out[25]: ' sin(x)**2'
In [26]: ccode(sin(x)**2)
Out[26]: 'pow(sin(x), 2)'
These don't support matrices though.
The Theano code printer produces Theano expressions. The Theano project
then compiles these expressions down to C code.
In [27]: from sympy.printing.theanocode import theano_function
In [28]: X = Matrix([x, x**2])
In [29]: f = theano_function([x], X, dims={x: 1})
In [30]: f([1, 2, 3])
Out[30]: [array([ 1., 2., 3.], dtype=float32), array([ 1., 4., 9.],
dtype=float32)]
You should also ask the PyDy folks. They generate C++ code from large
sympy
matrices. Your application looks very similar to theirs.
On Mon, Jun 9, 2014 at 11:36 PM, Paul balze...@gmail.com wrote:
Hi! Received the Mention. :)
Matthew, you are completely right! I used Sympy just for the calculation
of the Jacobians and then retyped it manually (probably with errors?!)
again
as Python code. Did not know, that there are easier methods in Sympy.
But anyways, I developed the Kalman Filter in Python and with the help
of
Sympy, but need the raw code for other languages like C or Matlab, so
lambdify might not be very useful. Are there any other ways to get the
code
I typed manually?
The way the print latex(As) function is very very useful. If there might
be a print code(As) function... :)
Thanks!
Am Donnerstag, 5. Juni 2014 22:36:42 UTC+2 schrieb Matthew:
I only looked at one of his notebooks but my synopsis is that he uses
SymPy to derive a matrix of scalar expressions using basic math and
derivatives. He then translates these equations by hand into numpy
expressions. He then does some application specific analysis.
From the SymPy perspective it looks like his work might be improved by
looking into SymPy's capabilities for code generation. It seems like
he's
doing a fair amount of unnecessary/error-prone work, rewriting sympy
expressions into numpy code. Presumably either sympy,lambdify or
sympy.printing.theanocode could be of use.
His work is computationally very similar to the PyDy project. Perhaps
interaction with that project would be fruitful.
I can't find his e-mail address but am @mentioning him in a tweet to
this
post.
On Thu, Jun 5, 2014 at 12:32 PM, Aaron Meurer asme...@gmail.com
wrote:
http://pydata.org/berlin2014/speakers/#306
Aaron Meurer
--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2Bsua%3DENaUbr5mcbP_fuzB8%3D0md%3DBO1mCXQnHQa41efUQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/509c31ed-b23f-4fdc-9b30-ac7f5b9a3a65%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HzCNzH-5cR_n4qRSaekE0JyBS5sVYmRjjJb7%3DV%3Dw30%2BA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com
Re: [sympy] Re: Pattern matching
On Thursday, July 17, 2014 7:07:19 PM UTC-7, Matthew wrote: The benefit of pattern matching is that 1 complex if-then-else constructions are hard to write well. Writing 10,000 rules and being sure that you have 100% coverage of all possible case and no overlap is a challenge. It's hard for humans, it is impossible to guaranteed by computer analysis. (That is, given two patterns with associated predicates, associative, commutative etc.. is one pattern a subset of the other? do they both match some particular set of expressions? Note that pattern matching systems of a particularly simple form, Thue or Semi-Thue systems are already Turing complete.) And yet testing for confluence and termination is a topic of research with some decent implementations in the aforementioned languages. Again, I recommend actually reading about this topic. Richard the popularity of pattern matching has been pretty much dead since the 90s. I'm not sure what population is being used here -- users / applications? For example, parsers using BNF can be said to be using pattern matching, though compiler-compilers (as they used to be called) generally take the BNF and produce tables. Or possibly if-then-else trees. This is exactly why I appended my previous e-mail with the change this kind of rich pattern matching. That being said it isn't a poor crutch, languages like Maude, Elan, and more recently Stratego/XT demonstrate proof of concept pretty well (IMO.) I don't know what needs to be proved. YACC is quite old, and of course there was older stuff as well. Then there was a slew of expert system frameworks like OPS5. (I think it used the Rete algorithm, which may be a version of discrimination net) There is a general problem that in the hands of novices, and maybe even experts, large rulesets tend to become unmanageable. I would suggest reviewing these projects and their associated literature before deprecating it further. I looked briefly at Stratego. Given how frequently you belittle others for not reading historical work I'm surprised that you only looked briefly at these projects. I would expect someone of your stature and experience to review existing literature before making strong claims like you do in your e-mails. The standard paper on Stratego/XT is actually a very good read. Why didn't you think it was worth reading before commenting here? I see it was used to build a compiler for Tiger (used by Andrew Appel in [several] textbooks). I actually used that Tiger language for a compiler class. I suppose one could muck about with patterns, but I used a small compiler compiler that generated Lisp code. Then the abstract syntax tree could either be interpreted or compiled. So in the end one was not doing pattern matching at all. This is kind of like saying Oh yes, I looked at Java, I see that it was used to build the program Hello, world! which is actually used all over the place. I built it once The fact that they built a compiler for Tiger is not interesting (this is clearly possible in any system) what's interesting is how they built it. Again, I'd suggest actually reading about these projects rather than looking cursorily at their webpages. Generally speaking this is a doable but difficult computer science problem. Known solutions exist but they're in papers, not in textbooks. I think that this work would be appropriate for a GSoC student over a summer or for a clever computer science student over a week or two. I don't personally expect any of the core-devs-with-other-jobs to get around to it for a while though of course I'd be thrilled if that were the case. (Prove me wrong Ondrej!) This is also the sort of thing that would benefit from a performant core. We would write patterns in SymPy and then match them using some C++ matching system. This is likely a purely structural operation and so shouldn't require any of the Python logic code. The patterns would probably translate well between SymPy and CSymPy. I don't understand why a purely structural pattern matching program would require more that a half page of code, or why it would be of interest to deploy such a program in the context of symbolic algebraic mathematical expressions, fast or slow. But maybe you are talking about something different from this. Associative/Commutative operators vastly complicate matching systems. However, just because a problem is in general difficult or impossible does not mean that a partial solution can't be very handy. Computer algebra systems rely on this. Fully agree here -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this
Re: [sympy] Draft for a new pattern matcher
Hmm. What's wrong with x = Wild('x', integer=True, odd=True), like
Symbol?
+1
On Sat, Jul 19, 2014 at 9:58 AM, Sergey Kirpichev skirpic...@gmail.com
wrote:
On Monday, July 14, 2014 11:36:19 AM UTC+4, F. B. wrote:
x = Wild('x')
x.is_integer().OddQ()
Hmm. What's wrong with x = Wild('x', integer=True, odd=True), like Symbol?
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/52b83187-763d-44e7-92da-a424e2922560%40googlegroups.com
https://groups.google.com/d/msgid/sympy/52b83187-763d-44e7-92da-a424e2922560%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-Ge2R4n-gX03E0f5XqPNUw2_xRsSWYDvdAZJphj-YVG_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] FOL Constants and Unification
What is the class of constants that you'd like to include in your
expressions? Are they all valid sub-expressions? If so, and if you're ok
with a hack, you could always differentiate between constant Symbols and
wild-card Symbols by using some odd convention, like the names start with
`~` or they have a particular assumption that wouldn't make sense normally.
In other unification projects when I've been in similar situations I've
used a special set of symbols as wildcards
variables = set([A, B, C, D])
def isvariable(expr):
return expr in variables
This has the advantage of working in lots of different systems.
In my unification library I support a few mechanisms. The mechanism above
I describe here
https://github.com/mrocklin/unification/blob/master/unification/variable.py#L49
On Thu, Jul 17, 2014 at 7:36 AM, Soumya Biswas sdb1...@gmail.com wrote:
Hello Everyone,
I have been working on building the First Order Logic module for SymPy and
the (basic) architecture is almost complete. However I have run into a
problem that I can't seem to be able to solve.
As many of you would be aware of, FOL uses predicates, functions,
variables, constants and quantifiers in its expressions. Instead of reusing
the existing Predicates and Functions, I have written new classes for
these. However I have used the Symbol class for variables. Now comes the
question of constants. As of now I am using non-SymPy objects like strings
and integers as constants. However this isn't working out very well. So my
initial idea was to add a constants class inside FOL, or if it is of use to
other modules, then inside core. However since then it has been pointed out
to me, and quite rightly so, that using constants isn't really required.
Variables can be used for accomplishing the same thing. In FOL
particularly, one can replace a constant with a variable and simply provide
it with the appropriate value during interpretation. For e.g. instead of
And(a, b, True), one can simply say And(a, b, c) with c = True for the
entire scope. It will make a difference where the existence of the constant
would have prompted some evaluation (like And(a, False) becomes False), but
for most part of FOL such evaluations are not of consequence.
However there seems to be one place where it is necessary to differentiate
between variables and constants namely in unification. I am trying to find
out if some pre-existing SymPy construct can substitute for constants here.
Here mgu stands for the most general unifier.
mgu(P(f(X), g(Z)), P(Y, A))
{Y: f(X), Z: 'a'}
mgu(P(f(X), g(Z)), P(Y, 'A'))
False
Here A is a variable while 'A' is a constant.
To unify two predicates, I am checking if its corresponding arguments can
be (recursively) unified. Something can be unified if there exists a
variable on one side and any term i.e. function (not containing the same
variable), variable or constant on the other side. As can also be seen from
the example, we need to be able to distinguish between constants and
variables while unification.
Hence I am looking for some way such that the above can be accomplished
using some existing SymPy object (without introducing a new constants
class),
Thank You
SD
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/d2bbb752-68b4-499e-95b9-c0dfe59a0bea%40googlegroups.com
https://groups.google.com/d/msgid/sympy/d2bbb752-68b4-499e-95b9-c0dfe59a0bea%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-GdipFuQZ1wUsK%3DrZ%3DhhQZp2RYaCXPv_B5di13uOXjycw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] FOL Constants and Unification
The problem with a separate class is that you suddenly need make new
subclasses for lots of different situations (exprs, sets, matrices).
Although maybe Soumya is working in a simpler setting.
On Thu, Jul 17, 2014 at 4:52 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Thu, Jul 17, 2014 at 6:50 PM, Matthew Rocklin mrock...@gmail.com
wrote:
What is the class of constants that you'd like to include in your
expressions? Are they all valid sub-expressions? If so, and if you're
ok
with a hack, you could always differentiate between constant Symbols and
wild-card Symbols by using some odd convention, like the names start with
`~` or they have a particular assumption that wouldn't make sense
normally.
I'm not a fan of naming conventions. Using a different class seems better.
I would either use a separate class for constants, or pass in the
symbols that should be constant as a parameter to the unification
function.
Aaron Meurer
In other unification projects when I've been in similar situations I've
used
a special set of symbols as wildcards
variables = set([A, B, C, D])
def isvariable(expr):
return expr in variables
This has the advantage of working in lots of different systems.
In my unification library I support a few mechanisms. The mechanism
above I
describe here
https://github.com/mrocklin/unification/blob/master/unification/variable.py#L49
On Thu, Jul 17, 2014 at 7:36 AM, Soumya Biswas sdb1...@gmail.com
wrote:
Hello Everyone,
I have been working on building the First Order Logic module for SymPy
and
the (basic) architecture is almost complete. However I have run into a
problem that I can't seem to be able to solve.
As many of you would be aware of, FOL uses predicates, functions,
variables, constants and quantifiers in its expressions. Instead of
reusing
the existing Predicates and Functions, I have written new classes for
these.
However I have used the Symbol class for variables. Now comes the
question
of constants. As of now I am using non-SymPy objects like strings and
integers as constants. However this isn't working out very well. So my
initial idea was to add a constants class inside FOL, or if it is of
use to
other modules, then inside core. However since then it has been pointed
out
to me, and quite rightly so, that using constants isn't really required.
Variables can be used for accomplishing the same thing. In FOL
particularly,
one can replace a constant with a variable and simply provide it with
the
appropriate value during interpretation. For e.g. instead of And(a, b,
True), one can simply say And(a, b, c) with c = True for the entire
scope.
It will make a difference where the existence of the constant would have
prompted some evaluation (like And(a, False) becomes False), but for
most
part of FOL such evaluations are not of consequence.
However there seems to be one place where it is necessary to
differentiate
between variables and constants namely in unification. I am trying to
find
out if some pre-existing SymPy construct can substitute for constants
here.
Here mgu stands for the most general unifier.
mgu(P(f(X), g(Z)), P(Y, A))
{Y: f(X), Z: 'a'}
mgu(P(f(X), g(Z)), P(Y, 'A'))
False
Here A is a variable while 'A' is a constant.
To unify two predicates, I am checking if its corresponding arguments
can
be (recursively) unified. Something can be unified if there exists a
variable on one side and any term i.e. function (not containing the same
variable), variable or constant on the other side. As can also be seen
from
the example, we need to be able to distinguish between constants and
variables while unification.
Hence I am looking for some way such that the above can be accomplished
using some existing SymPy object (without introducing a new constants
class),
Thank You
SD
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/d2bbb752-68b4-499e-95b9-c0dfe59a0bea%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-GdipFuQZ1wUsK%3DrZ%3DhhQZp2RYaCXPv_B5di13uOXjycw
Re: [sympy] Re: Pattern matching
The benefit of pattern matching is that 1 complex if-then-else
constructions are hard to write well. Richard the popularity of pattern
matching has been pretty much dead since the 90s. That being said it isn't
a poor crutch, languages like Maude, Elan, and more recently Stratego/XT
demonstrate proof of concept pretty well (IMO.) I would suggest reviewing
these projects and their associated literature before deprecating it
further.
Ondrej my understanding is that if you don't care about
associativity/commutativity then you can do many-patterns-to-one-expression
matching with a Trie http://en.wikipedia.org/wiki/Trie. If you do care
about associative/commutative operators (which you probably do) then this
is harder. The data structure I've heard tossed around is the
discrimination net. I have a paper lying around on the topic that I can
dig it up if someone is interested (thank you Mendeley.)
Generally speaking this is a doable but difficult computer science problem.
Known solutions exist but they're in papers, not in textbooks. I think
that this work would be appropriate for a GSoC student over a summer or for
a clever computer science student over a week or two. I don't personally
expect any of the core-devs-with-other-jobs to get around to it for a while
though of course I'd be thrilled if that were the case. (Prove me wrong
Ondrej!)
This is also the sort of thing that would benefit from a performant core.
We would write patterns in SymPy and then match them using some C++
matching system. This is likely a purely structural operation and so
shouldn't require any of the Python logic code. The patterns would
probably translate well between SymPy and CSymPy.
On Thu, Jul 17, 2014 at 6:38 PM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
On Thu, Jul 17, 2014 at 7:27 PM, Richard Fateman fate...@gmail.com
wrote:
Rubi is apparently structured so that at any time at most one rule will
be
applicable,
and it should be easy to figure out how to exclude everything else. I
think
that
Albert Rich even expressed the notion that Rubi did not actually need to
be
structured as rules..
--- just If/then/else
That's a good point --- it is my understanding as well, that the rules
are mutually exclusive.
So perhaps one doesn't need a general pattern matching for that, just
a specialized version,
essentially if/then/else, as you said.
Ondrej
The point of the matching/ rule stuff in Macsyma (Maxima) is that
if you are using a pattern to find A and B in
z = A*x+Bwith A,B, free of x, then maybe you should compile the
match
into a call to
compute the simplified polynomial form of z as a linear polynomial in
x.
Pick off the
coefficients A and B. test them with whatever you need to do. e.g. A
is
non-zero and
of course free of x by construction. B is of course free of x as well.
And there is no
higher power of x.Instead of groveling around looking for terms to
collect under the
name A and B, rearranging stuff and discovering later that you have to
rearrange again
to satisfy predicates attached later...
If pattern matching is a crutch, and a poor one at that, maybe its use
should be
limited, and its popularity toned down.
RJF
On Thursday, July 17, 2014 5:52:48 PM UTC-7, Ondřej Čertík wrote:
On Thu, Sep 26, 2013 at 6:37 PM, Aaron Meurer asme...@gmail.com
wrote:
My idea was to put assumptions on Wild expressions. I guess using the
new assumptions system, the assumptions do not need to be, nor should
they be, actually tied to the symbols. This will also make it easy to
add assumptions about general expressions, not just Wilds (and make it
easier to do the sorts of things Angus was talking about). So
something like
expr = x + 2
a = Wild('a', exclude=[x])
expr.match(x + a, assumptions=Q.positive(a))
would work, but for
expr = x - 2
it would not match.
One could then specify arbitrary assumptions, and match would refuse
to return any result where the assumptions are False. Or you could add
a flag to make it even stronger: don't return a result unless the
assumptions are True (as opposed to None).
This may be far reaching and could be a bad idea, but I think we could
then extend the assumptions system to allow assumptions like
Q.free_of(a, x) to mean that a does not depend on x, or
Q.isinstance(a, Mul) to mean that a is a Mul.
The new assumptions system is still relatively weak and needs to be
integrated into SymPy better, so this would be a lofty goal. But
assuming we can unify the system, and get something like
https://code.google.com/p/sympy/issues/detail?id=3929, I think this
would be a nice way to specify things, much better (and more powerful)
than throwing a bunch of lambdas around.
So we definitely need to implement Rubi, I created an issue for it
with motivation + steps to do:
Re: [sympy] Moments of a normal distribution
Cool. It's nice to see SymPy used in this way.
On Wed, Jul 16, 2014 at 5:04 PM, Justin Vincent justi...@gmail.com wrote:
A little notebook that came out of this work, is case anyone is interested:
http://nbviewer.ipython.org/github/justinvf/algorithmshop/blob/master/20140715-mixture-models/pearson_gaussian_mixtures.ipynb
On Wednesday, July 16, 2014 1:13:42 PM UTC-7, Justin Vincent wrote:
Thanks! This works great.
On Tuesday, July 15, 2014 2:28:11 PM UTC-7, Matthew wrote:
Use sympy.stats, not sympy.statistics
In [1]: x, mu = symbols('x,mu', real=True)
In [2]: sigma = symbols('sigma', positive=True)
In [3]: from sympy.stats import *
In [4]: X = Normal('X', mu, sigma)
In [5]: moment?
Type:function
String form: function moment at 0x7fc3fbbe2b18
File:/home/mrocklin/workspace/sympy/sympy/stats/rv_interface.py
Definition: moment(X, n, c=0, condition=None, **kwargs)
Docstring:
Return the nth moment of a random expression about c i.e. E((X-c)**n)
Default value of c is 0.
Examples
from sympy.stats import Die, moment, E
X = Die('X', 6)
moment(X, 1, 6)
-5/2
moment(X, 2)
91/6
moment(X, 1) == E(X)
True
In [6]: moment(X, 1)
Out[6]: μ
In [7]: moment(X, 2)
Out[7]:
22
μ + σ
In [8]: moment(X, 3)
Out[8]:
32
μ + 3⋅μ⋅σ
In [9]: moment(X, 4)
Out[9]:
4 2 2 4
μ + 6⋅μ ⋅σ + 3⋅σ
On Tue, Jul 15, 2014 at 1:40 PM, Justin Vincent just...@gmail.com
wrote:
Wanted to get the moments of a Normal distribution WRT mu and sigma, a
la:
http://en.wikipedia.org/wiki/Normal_distribution#Moments
For starters, this outputs 1 for one for one crazy domains, and then
leaves the integral unevaluated on the rest of the domain. But it gets one,
so I'm cool with that.
from sympy.statistics import Normal
from sympy import symbols, integrate
f = Normal(mu, sigma).pdf(x)
x, mu, sigma = symbols('x mu sigma')
integrate(f, (x,-oo, oo))
Then when I get the first moment, it really starts to go crazy though,
and leaves it all indefinite:
integrate(f * x, (x, -oo, oo))
What approach should I take here if I wanted to get those values cited
in wikipedia? Haven't used Sympy much before. Thanks in advance.
Justin
--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/
msgid/sympy/2babc41b-0ab4-443c-a75b-d5910ce16c21%40googlegroups.com
https://groups.google.com/d/msgid/sympy/2babc41b-0ab4-443c-a75b-d5910ce16c21%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/8e7e3a2a-639c-4816-a892-872e94e10ac9%40googlegroups.com
https://groups.google.com/d/msgid/sympy/8e7e3a2a-639c-4816-a892-872e94e10ac9%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HkTkQUjmep0D3dpA67ZXUy2XCNkydSmfWZngeeKxJadQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Meeting sometime this week?
@Fred, the problems that Jason has are small matrices containing many complex scalar expressions. Is Theano still competitive for these applications? I'm +1 on adding support for sympy.Matrix -like functionality to fcode and ccode. On Wed, Jul 9, 2014 at 11:52 AM, Frédéric Bastien no...@nouiz.org wrote: On Wed, Jul 9, 2014 at 12:21 PM, Jason Moore moorepa...@gmail.com wrote: [...] Alot of this functionality exists in SymPy. Read the code printers, the code gen, the autowrap, ufuncify, and lambdify codes in SymPy to get an idea of how this works. I wouldn't worry too much about Theano yet either as it it doesn't have good performance for the kind of problems we have (evaluating huge math expressions). Just to clarify, Theano is fast for tensor math expressions. It is just for scalar expression that we have too much overhead. So for your matrix cases, Theano should be pretty fast. If you have a benchmark where this isn't true, I'll be happy to look at it. The current benchmark in pydy work on scalars. It is probably the worts benchmark you could do in Theano and not representative of matrix expression speed. Fred -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADKKbtiC2iHpkxV%2BVnmURmd-%2Bv3ffoEEMyB-VRjdX1C0XhYS7A%40mail.gmail.com https://groups.google.com/d/msgid/sympy/CADKKbtiC2iHpkxV%2BVnmURmd-%2Bv3ffoEEMyB-VRjdX1C0XhYS7A%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EWo-uN6VdOWMFrtoY0wTGvVU4PMb6OtY1_cn-ZES2FFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Draft for a new pattern matcher
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 On Fri, Jul 4, 2014 at 12:49 AM, F. B. franz.bona...@gmail.com wrote: 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 patterns like Add(oo, 'x') without fear that they will change to something else. That is an interesting idea. Maybe no SymPy object should overload the __new__ constructor? Mathematica uses attributes to define some automatic evaluations, for example Flat, have a look at this example: In[1]:= f[a, b, f[c, d, e]] Out[1]= f[a, b, f[c, d, e]] In[2]:= SetAttributes[f, Flat] In[3]:= f[a, b, f[c, d, e]] Out[3]= f[a, b, c, d, e] This could be emulated by putting a static variable *flat* in *Expr*: class Expr(Basic): ... flat = False class Add(...): ... flat = True Whenever flat is True, flattening automatically happens upon construction. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/be1ffa00-fe05-4f85-beeb-ba245ea4d3a6%40googlegroups.com https://groups.google.com/d/msgid/sympy/be1ffa00-fe05-4f85-beeb-ba245ea4d3a6%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GN6XF96NCiLfG70Wh5t-GU%2B8DJOrQzP8QYAdNGvD%3DPig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Draft for a new pattern matcher
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 exceptions if they don't recognize the arguments. The pattern matcher could incur into this problem if the rewrite rules are not properly written. 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 patterns like Add(oo, 'x') without fear that they will change to something else. On Thu, Jul 3, 2014 at 4:08 PM, Aaron Meurer asmeu...@gmail.com wrote: When would it not indicate an error, though? Aaron Meurer On Thu, Jul 3, 2014 at 5:12 PM, F. B. franz.bona...@gmail.com wrote: 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 exceptions if they don't recognize the arguments. The pattern matcher could incur into this problem if the rewrite rules are not properly written. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/1a4268ab-cdd7-4ffb-a7d0-cdf65f1fede2%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KnuMvUPzVLXgi7tRkBALWt6YW6h0LmbEBpefKQcQWoHA%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Gtqqz5zwkxk74i3ajLHhv3X_ze%3Du7b41uNn-NCyTvNcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Converting dict containing SymPy objects to JSON
Sympy terms can be serialized/deserialized somewhat robustly with str and
sympify.
On Jun 20, 2014 11:53 AM, Aaron Meurer asmeu...@gmail.com wrote:
You should probably just store the name of the symbol in the dictionary as
a string. You may also want to do that for the floats if precision issues
come up.
Aaron Meurer
On Fri, Jun 20, 2014 at 1:20 PM, TARUN GABA tarun.ga...@gmail.com wrote:
Hi
I have a dict containing symbols as keys, mapped to float values. I need
to convert it to JSON format(for passing to Javascript).
Here is an example dict:
constants = {l: 10.0, m: 10.0, g: 9.81}
python's json module cannot parse these symbols.What should be the best
approach to implement this?
Thanks
Tarun Gaba
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHAono2rMOfWi%3Dvx0Q1eKH2iQPQDhkEZ5HvTmAn94f2tpUpM-w%40mail.gmail.com
https://groups.google.com/d/msgid/sympy/CAHAono2rMOfWi%3Dvx0Q1eKH2iQPQDhkEZ5HvTmAn94f2tpUpM-w%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BhODMQrNoKh4Q%3DPy2n1sSEHSPFEKbJQeziHSotuK6AbQ%40mail.gmail.com
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BhODMQrNoKh4Q%3DPy2n1sSEHSPFEKbJQeziHSotuK6AbQ%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HXkrA0Off9w0CRw7gagXgiJM2ucmEJ6dzDCiaAQqHRQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] GSoC Reunion Lottery
I don't think Google is paying expenses. I think that you're responsible for airfare and hotel. On Thu, Jun 12, 2014 at 10:39 AM, Aaron Meurer asmeu...@gmail.com wrote: This year, instead of a mentor summit, Google is having a reunion, which is open to all current and former GSoC participants (students, mentors, and org admins). We have already chosen our two main mentor delegates (myself and Ondrej), but If you are interested in going, you can enter a lottery. Google will pay the expenses if you are chosen. See https://sites.google.com/site/gsocmentorsummitstudentreunion/lottery-information . I encourage all current and former students to enter if you are interested. There is more information on that page. The deadline to enter the lottery is June 16. Aaron Meurer -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2ByuyP29z943N8wMyPn%2BBmyPOgYdx%2BNLNS1nh09Y8ocqA%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FpABEYs7-SGMxVvJ9tau7Ct8u3GR3L5swpANUXdhcZ8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SciPy 2014 SymPy BoF
Done. https://conference.scipy.org/scipy2014/proposals/202/ On Wed, Jun 11, 2014 at 12:37 PM, Kyle Mandli kyle.man...@gmail.com wrote: Matthew, if you are willing can you submit a BoF to the website so we can keep track of it. This is not a set-in-stone I will come find you and say mean things to you if you do not feel comfortable leading the discussion depending on numbers, I mostly want to know interest and space requirements so we can keep track of everything at this point. My guess is that you will get a few non-devs that might have questions or may just be curious on what the plan for the future is. This is also a good place to think about what you may want to accomplish in the sprints later in the week. On Thursday, June 5, 2014 5:12:08 PM UTC-5, Aaron Meurer wrote: I guess it depends on who will attend. If it is just SymPy devs, then we can discuss the future of the project (or whatever). If there are a lot of non-devs, it can be a panel for questions or something like that. A Q/A style is great for avoiding the issue you are worried about if there are a lot of SymPy users present. Aaron Meurer On Thu, Jun 5, 2014 at 4:44 PM, Matthew Rocklin mroc...@gmail.com wrote: If this is just folks entering a room and chatting then yeah, i can moderate that (assuming someone like Aaron doesn't want to take charge). If it's a few SymPy folks having a panel discussion then I'm also happy to come with a few prepared insighful/annoying questions to get the discussion started. If that's the level of commitment necessary then you can safely assume that we're committed. One thing that concerns me is that I expect those present to be roughly 4-5 SymPy experts who would normally talk about nitty-gritty annoying details within the core of SymPy and 5-10 SymPy users for whom this in-depth discussion would be completely wasted. I'm sure we can tailor the experience to something reasonable based on those who show up but I'd welcome any insight you have here from previous BoFs. On Thu, Jun 5, 2014 at 1:12 PM, Kyle Mandli kyle@gmail.com wrote: I am willing to help out with organization but I am not knowledgable enough to lead the discussion. Our main goal is to encourage you guys to organize even something informally to discuss the future of SymPy and/or take questions, comments or concerns from others attending the conference. What format this takes is up to you. Kyle On Wednesday, June 4, 2014 6:36:08 PM UTC-5, Matthew wrote: Also attending and happy to participate. Probably not willing to organize. Kyle were you just gauging interest or were you asking for someone to spearhead the BOF. On Wed, Jun 4, 2014 at 11:09 AM, Aaron Meurer asme...@gmail.com wrote: I will be at the conference and will definitely attend anything SymPy related. Aaron Meurer On Tue, Jun 3, 2014 at 6:19 PM, Kyle Mandli kyle@gmail.com wrote: Hello SymPy peeps, As one of the co-chairs in charge of organizing the birds-of-a-feather sesssions at the SciPy conference this year, I wanted to solicit through the SymPy google group to see if we could get enough interest to hold a SymPy centered BoF this year. The BoF format would be up to those who would lead the discussion, a couple of ideas used in the past include picking out a few of the lead devs to be on a panel and have a QA type of session or an open QA with perhaps audience guided list of topics. Thanks! Kyle Manldi (and via proxy Matt McCormick) -- 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+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3fb88077-d09f- 48e2-b3d0-2cb5ebd04a85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW% 3D6J6741FLNPksEj8WWPMG4iinPheA4mhV1jUx-C6qSWuRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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+un...@googlegroups.com. To post to this group, send
Re: [sympy] SymPy talk at PyData Berlin
We do have ccode and fcode for C and Fortran
In [25]: fcode(sin(x)**2)
Out[25]: ' sin(x)**2'
In [26]: ccode(sin(x)**2)
Out[26]: 'pow(sin(x), 2)'
These don't support matrices though.
The Theano code printer produces Theano expressions. The Theano project
then compiles these expressions down to C code.
In [27]: from sympy.printing.theanocode import theano_function
In [28]: X = Matrix([x, x**2])
In [29]: f = theano_function([x], X, dims={x: 1})
In [30]: f([1, 2, 3])
Out[30]: [array([ 1., 2., 3.], dtype=float32), array([ 1., 4., 9.],
dtype=float32)]
You should also ask the PyDy folks. They generate C++ code from large
sympy matrices. Your application looks very similar to theirs.
On Mon, Jun 9, 2014 at 11:36 PM, Paul balze...@gmail.com wrote:
Hi! Received the Mention. :)
Matthew, you are completely right! I used Sympy just for the calculation
of the Jacobians and then retyped it manually (probably with errors?!)
again as Python code. Did not know, that there are easier methods in Sympy.
But anyways, I developed the Kalman Filter in Python and with the help of
Sympy, but need the raw code for other languages like C or Matlab, so
lambdify might not be very useful. Are there any other ways to get the code
I typed manually?
The way the print latex(As) function is very very useful. If there might
be a print code(As) function... :)
Thanks!
Am Donnerstag, 5. Juni 2014 22:36:42 UTC+2 schrieb Matthew:
I only looked at one of his notebooks but my synopsis is that he uses
SymPy to derive a matrix of scalar expressions using basic math and
derivatives. He then translates these equations by hand into numpy
expressions. He then does some application specific analysis.
From the SymPy perspective it looks like his work might be improved by
looking into SymPy's capabilities for code generation. It seems like he's
doing a fair amount of unnecessary/error-prone work, rewriting sympy
expressions into numpy code. Presumably either sympy,lambdify or
sympy.printing.theanocode could be of use.
His work is computationally very similar to the PyDy http://pydy.org/
project. Perhaps interaction with that project would be fruitful.
I can't find his e-mail address but am @mentioning him in a tweet to this
post.
On Thu, Jun 5, 2014 at 12:32 PM, Aaron Meurer asme...@gmail.com wrote:
http://pydata.org/berlin2014/speakers/#306
Aaron Meurer
--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/
msgid/sympy/CAKgW%3D6%2Bsua%3DENaUbr5mcbP_fuzB8%3D0md%
3DBO1mCXQnHQa41efUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/509c31ed-b23f-4fdc-9b30-ac7f5b9a3a65%40googlegroups.com
https://groups.google.com/d/msgid/sympy/509c31ed-b23f-4fdc-9b30-ac7f5b9a3a65%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HzCNzH-5cR_n4qRSaekE0JyBS5sVYmRjjJb7%3DV%3Dw30%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Help with Vector
I think that it is reasonable for the first couple lines of any sympy
function foo to be
def foo(expr, ...):
if hasattr(expr, '_eval_foo'):
return expr._eval_foo()
This would work well for trigsimp
On Sat, Jun 7, 2014 at 11:59 PM, Sachin Joglekar srjoglekar...@gmail.com
wrote:
I see your point. But in that case, would the API remain the same? What
you suggest, would involve either-
A. modifying the code for trigsimp itself
or
B. having a 'trigsimp' method in Vector itself (already done this)
On Sun, Jun 8, 2014 at 11:26 AM, Matthew Rocklin mrock...@gmail.com
wrote:
1. How do I ensure methods like 'trigsimp' work with these classes?
Currently, passing a vector like *(sin(a)+cos(a))**2*i - j* to trigsimp
returns the correct answer mathematically, _but_ the instance is of type
Add (instead of the expected VectorAdd). How do I prevent this?
I ran into this when I was building MatrixExprs which have the same
issues (We have a MatrixAdd but wanted to use core SymPy utilities, which
use Add). For a while I got away with using the core functions and then
calling matrixify, which walked through the tree changing all Adds to
MatrixAdds, etc. if the tree contained any matrices. This worked for a
while but eventually became too much of a pain. MatrixExprs now avoid
interacting with Exprs as much as possible. Expr code assume that it deals
with scalars. This is everywhere in the code.
My suggestion would be to subs out all of your vectors for scalars, call
trigsimp, subs back the scalars to vectors, then do some sort of
Add-to-VectorAdd operation. Maybe you can generalize this to any SymPy
scalar operation.
2. Regarding bases
I agree with Franz that, if possible, it is good to leverage existing
work.
On Fri, Jun 6, 2014 at 8:40 AM, F. B. franz.bona...@gmail.com wrote:
On Friday, June 6, 2014 3:44:51 PM UTC+2, Sachin Joglekar wrote:
1. How do I ensure methods like 'trigsimp' work with these classes?
Currently, passing a vector like *(sin(a)+cos(a))**2*i - j* to
trigsimp returns the correct answer mathematically, _but_ the instance is
of type Add (instead of the expected VectorAdd). How do I prevent this?
Maybe this is a bug. I would look for the place where the Add object is
constructed. Maybe it's a bug in your code, maybe it's a bug in trigsimp.
2. How do I get 'solve' to work with these classes? For example,
consider a problem solved (in the future) using the module -
*Do the following vectors form a basis for R^3: {(2,-3,1), (4,1,1),
(0,-7,1)}?*
Why don't use matrix determinant?
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/9242d264-961c-407e-a6c5-3a8dc604aae7%40googlegroups.com
https://groups.google.com/d/msgid/sympy/9242d264-961c-407e-a6c5-3a8dc604aae7%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups sympy group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sympy/6iK_KpRnHvA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-F%3DsDqDtH5qcq4V8V0fAYdqadC_1HFzBAr34U%2BM-O7bqw%40mail.gmail.com
https://groups.google.com/d/msgid/sympy/CAJ8oX-F%3DsDqDtH5qcq4V8V0fAYdqadC_1HFzBAr34U%2BM-O7bqw%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CALMMyxaYCOY5OSO8r3U8mw6qJufeVQh0r7kA_-ZJeRONrPyZEA%40mail.gmail.com
https://groups.google.com/d/msgid/sympy/CALMMyxaYCOY5OSO8r3U8mw6qJufeVQh0r7kA_-ZJeRONrPyZEA%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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
Re: [sympy] Re: pattern replacement for complex numbers and manual factorization
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? On Sat, Jun 7, 2014 at 10:39 AM, F. B. franz.bona...@gmail.com wrote: 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5f84201b-2daa-46c4-902b-1d365622a52a%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GsNGsmh3nWdbCLZ1UBM7yFO6qvgfTigDV7VPrp85UTDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: pattern replacement for complex numbers and manual factorization
Also I'm glad to see people using strategies. I've since pulled it out to an external package. Although this wouldn't support SymPy tree traversals like bottom_up without slightly more work. https://github.com/logpy/strategies On Sat, Jun 7, 2014 at 6:38 PM, Matthew Rocklin mrock...@gmail.com 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? On Sat, Jun 7, 2014 at 10:39 AM, F. B. franz.bona...@gmail.com wrote: 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5f84201b-2daa-46c4-902b-1d365622a52a%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GxkP1OKojyP1U7FH9ng2cD%2Bi9nqKt6dFvtOSe63muEtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Help with Vector
1. How do I ensure methods like 'trigsimp' work with these classes?
Currently, passing a vector like *(sin(a)+cos(a))**2*i - j* to trigsimp
returns the correct answer mathematically, _but_ the instance is of type
Add (instead of the expected VectorAdd). How do I prevent this?
I ran into this when I was building MatrixExprs which have the same issues
(We have a MatrixAdd but wanted to use core SymPy utilities, which use
Add). For a while I got away with using the core functions and then
calling matrixify, which walked through the tree changing all Adds to
MatrixAdds, etc. if the tree contained any matrices. This worked for a
while but eventually became too much of a pain. MatrixExprs now avoid
interacting with Exprs as much as possible. Expr code assume that it deals
with scalars. This is everywhere in the code.
My suggestion would be to subs out all of your vectors for scalars, call
trigsimp, subs back the scalars to vectors, then do some sort of
Add-to-VectorAdd operation. Maybe you can generalize this to any SymPy
scalar operation.
2. Regarding bases
I agree with Franz that, if possible, it is good to leverage existing work.
On Fri, Jun 6, 2014 at 8:40 AM, F. B. franz.bona...@gmail.com wrote:
On Friday, June 6, 2014 3:44:51 PM UTC+2, Sachin Joglekar wrote:
1. How do I ensure methods like 'trigsimp' work with these classes?
Currently, passing a vector like *(sin(a)+cos(a))**2*i - j* to trigsimp
returns the correct answer mathematically, _but_ the instance is of type
Add (instead of the expected VectorAdd). How do I prevent this?
Maybe this is a bug. I would look for the place where the Add object is
constructed. Maybe it's a bug in your code, maybe it's a bug in trigsimp.
2. How do I get 'solve' to work with these classes? For example, consider
a problem solved (in the future) using the module -
*Do the following vectors form a basis for R^3: {(2,-3,1), (4,1,1),
(0,-7,1)}?*
Why don't use matrix determinant?
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/9242d264-961c-407e-a6c5-3a8dc604aae7%40googlegroups.com
https://groups.google.com/d/msgid/sympy/9242d264-961c-407e-a6c5-3a8dc604aae7%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-F%3DsDqDtH5qcq4V8V0fAYdqadC_1HFzBAr34U%2BM-O7bqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SymPy talk at PyData Berlin
I only looked at one of his notebooks but my synopsis is that he uses SymPy to derive a matrix of scalar expressions using basic math and derivatives. He then translates these equations by hand into numpy expressions. He then does some application specific analysis. From the SymPy perspective it looks like his work might be improved by looking into SymPy's capabilities for code generation. It seems like he's doing a fair amount of unnecessary/error-prone work, rewriting sympy expressions into numpy code. Presumably either sympy,lambdify or sympy.printing.theanocode could be of use. His work is computationally very similar to the PyDy http://pydy.org/ project. Perhaps interaction with that project would be fruitful. I can't find his e-mail address but am @mentioning him in a tweet to this post. On Thu, Jun 5, 2014 at 12:32 PM, Aaron Meurer asmeu...@gmail.com wrote: http://pydata.org/berlin2014/speakers/#306 Aaron Meurer -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2Bsua%3DENaUbr5mcbP_fuzB8%3D0md%3DBO1mCXQnHQa41efUQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-F44HfqNJGaaTRFFqJziwCvhm4_rmv3rVQRYMJv9kLevg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SciPy 2014 SymPy BoF
If this is just folks entering a room and chatting then yeah, i can moderate that (assuming someone like Aaron doesn't want to take charge). If it's a few SymPy folks having a panel discussion then I'm also happy to come with a few prepared insighful/annoying questions to get the discussion started. If that's the level of commitment necessary then you can safely assume that we're committed. One thing that concerns me is that I expect those present to be roughly 4-5 SymPy experts who would normally talk about nitty-gritty annoying details within the core of SymPy and 5-10 SymPy users for whom this in-depth discussion would be completely wasted. I'm sure we can tailor the experience to something reasonable based on those who show up but I'd welcome any insight you have here from previous BoFs. On Thu, Jun 5, 2014 at 1:12 PM, Kyle Mandli kyle.man...@gmail.com wrote: I am willing to help out with organization but I am not knowledgable enough to lead the discussion. Our main goal is to encourage you guys to organize even something informally to discuss the future of SymPy and/or take questions, comments or concerns from others attending the conference. What format this takes is up to you. Kyle On Wednesday, June 4, 2014 6:36:08 PM UTC-5, Matthew wrote: Also attending and happy to participate. Probably not willing to organize. Kyle were you just gauging interest or were you asking for someone to spearhead the BOF. On Wed, Jun 4, 2014 at 11:09 AM, Aaron Meurer asme...@gmail.com wrote: I will be at the conference and will definitely attend anything SymPy related. Aaron Meurer On Tue, Jun 3, 2014 at 6:19 PM, Kyle Mandli kyle@gmail.com wrote: Hello SymPy peeps, As one of the co-chairs in charge of organizing the birds-of-a-feather sesssions at the SciPy conference this year, I wanted to solicit through the SymPy google group to see if we could get enough interest to hold a SymPy centered BoF this year. The BoF format would be up to those who would lead the discussion, a couple of ideas used in the past include picking out a few of the lead devs to be on a panel and have a QA type of session or an open QA with perhaps audience guided list of topics. Thanks! Kyle Manldi (and via proxy Matt McCormick) -- 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+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3fb88077-d09f- 48e2-b3d0-2cb5ebd04a85%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/CAKgW%3D6J6741FLNPksEj8WWPMG4iinPheA 4mhV1jUx-C6qSWuRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c67ec33c-8bfe-4dcd-94c6-3607d2294030%40googlegroups.com https://groups.google.com/d/msgid/sympy/c67ec33c-8bfe-4dcd-94c6-3607d2294030%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Hi7B7UFjmgBDaG1qR6%3DSckVHRFGb6aPXKJRE_Xy3wfcw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Proposal for StackExchange site for Sage and ALL its subcomponents
Stackoverflow seems sufficient for SymPy. I think that the SymPy questions benefit from being within the broader stackoverflow framework. They get broad exposure and more consistent review/moderation. I don't think that the Sage/SymPy community is large enough to power a self-sustained stack exchange. I'd be happy to be wrong. On Thu, Jun 5, 2014 at 3:36 PM, Aaron Meurer asmeu...@gmail.com wrote: I started a discussion with some of my concerns at http://discuss.area51.stackexchange.com/q/14746/29342. Aaron Meurer On Thu, Jun 5, 2014 at 5:29 PM, Kannappan Sampath kntri...@gmail.com wrote: Yes, most certainly! In particular, we would like to have both questions purely about Sympy and those about Sage-Sympy interactions. The point is to have all the user-support for Sage and all its subcomponents under one umbrella. By the way, thank you for following the proposal. With Sincere Regards, Kannappan. On Friday, June 6, 2014 3:49:50 AM UTC+5:30, Aaron Meurer wrote: There are already quite a few SymPy questions on the SymPy tag on StackOverflow. Since SymPy is a library, questions about it are on-topic for that site. Several core devs (including myself) follow this tag, and answer questions when they come up. Will SymPy questions still be on-topic even if someone uses SymPy outside of Sage (most people do, at least based on what I've seen from existing StackOverflow questions)? Aaron Meurer On Thu, Jun 5, 2014 at 4:18 PM, Kannappan Sampath kntr...@gmail.com wrote: Hello Sympy Users and developers, I proposed a Stack Exchange site for Sage. Sympy being shipped with Sage, all questions about Sympy will be on-topic for this site. Please go and follow it; add example questions and vote up (down) questions that you think should be on-topic (resp. off-topic) for the upcoming site. http://area51.stackexchange.com/proposals/70511/sage?referrer=8adE6ec0VyqQCyB1kFgF7g2 Looking forward to your support and cooperation for the success of this adventure on Stack Exchange. PS. At the moment, while there is a Sympy Support mailing list and chat, searchability and linking dupes are all quite difficult. I think a Stackexchange site can ease this. While a stackexchange site will not replace this mailing list, we could encourage more focussed questions be asked on the StackExchange site thus creating a searchable database of questions and answers for further use. With Sincere Regards, Kannappan. -- 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+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/80f52e6a-29b8-4c9a-9502-e8bf59ab5a7b%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/905e4292-81ef-4da5-8d75-a3eb7c13ca09%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Ldu8Ujj62GmgNLa4zA-59uZwjUO%3DUdSc6P7--dMF19fw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GL3codz_JV0kBqjUSaypdAXV3EZ6gY_boDxsLk0JBxmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SciPy 2014 SymPy BoF
Also attending and happy to participate. Probably not willing to organize. Kyle were you just gauging interest or were you asking for someone to spearhead the BOF. On Wed, Jun 4, 2014 at 11:09 AM, Aaron Meurer asmeu...@gmail.com wrote: I will be at the conference and will definitely attend anything SymPy related. Aaron Meurer On Tue, Jun 3, 2014 at 6:19 PM, Kyle Mandli kyle.man...@gmail.com wrote: Hello SymPy peeps, As one of the co-chairs in charge of organizing the birds-of-a-feather sesssions at the SciPy conference this year, I wanted to solicit through the SymPy google group to see if we could get enough interest to hold a SymPy centered BoF this year. The BoF format would be up to those who would lead the discussion, a couple of ideas used in the past include picking out a few of the lead devs to be on a panel and have a QA type of session or an open QA with perhaps audience guided list of topics. Thanks! Kyle Manldi (and via proxy Matt McCormick) -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3fb88077-d09f-48e2-b3d0-2cb5ebd04a85%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J6741FLNPksEj8WWPMG4iinPheA4mhV1jUx-C6qSWuRw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EeAVw6xy1S23SCJRG5Mp%2BkcAGMtaL%3DcjaZXU-5d%2B6PsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Implementing Neural Networks in sympy
Beware that computations in SymPy are much much slower than computations in Theano. Also symbolic computations that involve many many operations quickly become very complex. On Sat, May 24, 2014 at 4:52 AM, AS1 aniketsinghresea...@gmail.com wrote: Hi, I want to use sympy to implement a symbolic neural network. I have worked in theano, where I can perform operations such as sigmoid in an elementwise manner on matrices. Does sympy provide support for evaluating general functions in an elementwise manner on symbolic matrices? Or could you suggest any other way to do this? thanks -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/cb591196-c90b-42dd-8959-2ce9a7fe2ff4%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/cb591196-c90b-42dd-8959-2ce9a7fe2ff4%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HJGAntNGvgL7F3yWE5-Yq6OVvGSwU3yHou%2BKt00X-kGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[sympy] Planet SymPy
Can anyone recommend an RSS e-mail delivery mechanism? I'd like to follow our GSoC students posts on planet.sympy but have stopped regularly visiting my normal RSS readers. Also, just a general recommendation for folks to check out the blogposts. There are already a few up there. I find that following along and commenting on the blogposts really enriches the Summer projects. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Hb2uS_tXT%3D9YRaB9WFqM_Ni_W-Zqb8s1Yyb%2ByHLVREmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Simplification question
Short answer, No. In full generality what you're describing is actually a challenging search problem. We've thought about attacking this problem more rigorously in SymPy but haven't gotten around to it except in a few small cases like trig simplification (see fu function). On Mon, May 19, 2014 at 2:54 PM, Mike Witt msg...@gmail.com wrote: Is it typical to have to fiddle around with different forms of an expression to get it to simplify? For example: In [7]: from sympy import sqrt In [8]: foo=-sqrt(-2*sqrt(2)+3)+sqrt(2*sqrt(2)+3) In [9]: print foo -sqrt(-2*sqrt(2) + 3) + sqrt(2*sqrt(2) + 3) In [10]: print foo.simplify() -sqrt(-2*sqrt(2) + 3) + sqrt(2*sqrt(2) + 3) In [11]: print (foo**2).expand() -2*sqrt(-2*sqrt(2) + 3)*sqrt(2*sqrt(2) + 3) + 6 In [12]: print (foo**2).expand().simplify() 4 Or is there some kind of general strategy that will always work (assuming there is clearly a simplification possible, like an integer as above)? -Mike -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/1400536494.2532.18%40Vector. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GcukOnuDvtFUJ2ukp_8v%2BtKYGogdSKRRxDZTbdkDnVtg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Simplification question
Just to increase awareness we *do* have a sexy search mechanism in SymPy living in sympy.strategies.tree (by my definition of sexiness). In [1]: from sympy.strategies.tree import greedy, brute In [2]: funcs = [simplify, expand, fu, powsimp, sqrtdenest] In [3]: objective = lambda x: len(str(x)) # minimize string length In [4]: megasimp = greedy((funcs, funcs), objective) megasimp tries each of simplify, expand, fu, powsimp, and sqrtdenest, then selects the result that minimizes the object (string length). It then tries each of those functions again on the result (this is the result of including funcs twice in a tuple.) We could swap out greedy for brute and it would try all 5 squared combinations. In [5]: foo = -sqrt(-2*sqrt(2)+3)+sqrt(2*sqrt(2)+3) In [6]: megasimp(foo) Out[6]: 2 Of course, this is a fairly dumb example, because just using sqrtdenest once is the right answer. In principle though we could have defined much more sophisticated function evaluation trees. For anyone still reading, here is the docstring to greedy Execute a strategic tree. Select alternatives greedily Trees - Nodes in a tree can be either function - a leaf list - a selection among operations tuple- a sequence of chained operations Textual examples Text: Run f, then run g, e.g. ``lambda x: g(f(x))`` Code: ``(f, g)`` Text: Run either f or g, whichever minimizes the objective Code: ``[f, g]`` Textx: Run either f or g, whichever is better, then run h Code: ``([f, g], h)`` Text: Either expand then simplify or try factor then foosimp. Finally print Code: ``([(expand, simplify), (factor, foosimp)], print)`` Objective - Better is determined by the objective keyword. This function makes choices to minimize the objective. It defaults to the identity. Example --- from sympy.strategies.tree import greedy inc= lambda x: x + 1 dec= lambda x: x - 1 double = lambda x: 2*x tree = [inc, (dec, double)] # either inc or dec-then-double fn = greedy(tree) fn(4) # lowest value comes from the inc 5 fn(1) # lowest value comes from dec then double 0 This funcion selects between options in a tuple. The result is chosen that minimizes the objective function. fn = greedy(tree, objective=lambda x: -x) # maximize fn(4) # highest value comes from the dec then double 6 fn(1) # highest value comes from the inc 2 Greediness -- This is a greedy algorithm. In the example: ([a, b], c) # do either a or b, then do c the choice between running ``a`` or ``b`` is made without foresight to c On Mon, May 19, 2014 at 8:13 PM, Aaron Meurer asmeu...@gmail.com wrote: In this case, there is a simplification function that will do it, sqrtdenest: In [3]: sqrtdenest(foo) Out[3]: 2 In general, there is no single algorithm for simplification (indeed, it's not even an easy concept to define), but simplify() tries to do its best. The more you know about the steps that are required to do the simplification you want, or the type of expression you have, the better you can apply individual simplification functions to get what you want. In this case, though, I would consider it a bug that simplify() did not try sqrtdenest. Aaron Meurer On Mon, May 19, 2014 at 3:54 PM, Mike Witt msg...@gmail.com wrote: Is it typical to have to fiddle around with different forms of an expression to get it to simplify? For example: In [7]: from sympy import sqrt In [8]: foo=-sqrt(-2*sqrt(2)+3)+sqrt(2*sqrt(2)+3) In [9]: print foo -sqrt(-2*sqrt(2) + 3) + sqrt(2*sqrt(2) + 3) In [10]: print foo.simplify() -sqrt(-2*sqrt(2) + 3) + sqrt(2*sqrt(2) + 3) In [11]: print (foo**2).expand() -2*sqrt(-2*sqrt(2) + 3)*sqrt(2*sqrt(2) + 3) + 6 In [12]: print (foo**2).expand().simplify() 4 Or is there some kind of general strategy that will always work (assuming there is clearly a simplification possible, like an integer as above)? -Mike -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/1400536494.2532.18%40Vector. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LKVAZ5OT-z%2B_asPcLB97wU2GmtqNRxT1ws2Ga9779XuQ%40mail.gmail.com . For more
Re: [sympy] Failing doctest for as_dict method
Hi Joachim,
Often times when people first send e-mails to the mailing list it takes a
while for it to get through. I wouldn't blame them for sending multiple
times. I've been guilty of this in the past.
Hi Abhishek,
You have a variable other, in your method definition that is never defined.
Maybe you meant this to refer to your input argument, args?
On Thu, May 15, 2014 at 1:33 PM, Joachim Durchholz j...@durchholz.org wrote:
1) One message to the list is enough, it won't be read faster if you send
it thrice within ten minutes. Actually most knowledgeable people on this
list scan their SymPy inbox once per day
Am 15.05.2014 20:15, schrieb Abhishek K Das:
wrote this function for FiniteSet
def as_dict(self,*args):
Rewrite a FiniteSet as a Dictionary.
Examples
from sympy import Symbol
from sympy.core import sets
A = FiniteSet((0, 0), (0, 2), (2, 0), (2, 2))
x = Symbol('x')
y = Symbol('y')
A.as_dict(x,y)
[{x: 0, y:0}, {x: 0, y:2}, {x:2, y:0}, {x:2, y:2}]
_list = []
for elem in self:
_list.append(dict(zip(list(other),list(elem
return _list
but when I do ./bin/doctest core it shows :
___ sympy.core.sets.FiniteSet.as_dict
___
File sympy/core/sets.py, line 1524, in sympy.core.sets.FiniteSet.as_
dict
Failed example:
A.as_dict(x,y)
Exception raised:
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest sympy.core.sets.FiniteSet.as_dict[5], line 1, in
module
A.as_dict(x,y)
File sympy/core/sets.py, line 1530, in as_dict
_list.append(dict(zip(list(other),list(elem
NameError: global name 'other' is not defined
= tests finished: 216 passed, 1 failed, in
2.51
seconds =
DO *NOT* COMMIT!
== rst doctests start
===
This is the first time , I have made some changes in any file in sympy . I
am a newbie , please tell me what are the issues with the doctest and how
can I edit this so as
to get the test passed ?
The bug is in your function. It is referencing the name other, but it is
neither a parameter nor available as a global Python variable.
The doctest merely triggers the problem.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/
msgid/sympy/53752494.7050506%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-ECNXzzNpqNyVBX3xn%2BSgF5PiW-e-7Put2JqzLNy7D56A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: ContinuousRV bug?
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. In [1]: from sympy.stats import * In [2]: X = ContinuousRV(x, exp(-x), Interval(0, oo)) In [3]: P(X log(2), evaluate=False) Out[3]: 0 ⌠ ⎮ -z ⎮ ℯ ⎮ ─── dz ⎮ 2 ⌡ -∞ On Wed, May 14, 2014 at 11:21 AM, Aaron Meurer asmeu...@gmail.com wrote: That looks like an issue in the integration module. There should be some way to get the integral that it computes, so that we can debug from there. Aaron Meurer On Wed, May 14, 2014 at 2:24 AM, F. B. franz.bona...@gmail.com wrote: 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)) Out[6]: oo I would expect 1/2 as Out[6] -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5024a59c-5ef1-480e-a1ce-e30b4c25d1f7%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BvrUtKCu1fU_78Hy7jYXLxWTE6V-YdOvrhBWtQ9T6_Cg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Gu0YPhVxUMVXfhqC3QXaAvUU7PDggp83M_CpmDnZ7VcA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[sympy] Policy on `is_foo` predicates
When making a predicate on a sympy class should we always use is_foo as in is_Real or should we use isfoo as in isinstance? What is the standard style for denoting that something is a predicate? This came up in https://github.com/sympy/sympy/pull/7346 for Set.issubset / Set.is_subset. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FMzz3%3DnKDRZEQ_dtMuGXGxAsUyONyb36erxg%2BEjtfG3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SymbolicC++
This seems to be going down the same path as previous conversations. I don't think that anyone will come away satisfied. I recommend that both sides resist the urge to fight. Alternatively Richard and Joachim, perhaps the two of you would enjoy continuing this conversation privately off list? On Mon, Apr 28, 2014 at 3:43 AM, Richard Fateman fate...@gmail.com wrote: On Monday, April 28, 2014 12:29:32 AM UTC-7, Joachim Durchholz wrote: Worse, it is reproducing the chain of errors in design that led to existing computer algebra systems. Which ones do you mean? managing assumptions. treating algebraic roots. fo 2 examples. That's areas. What are the design errors? What would be better designs? For the assumptions - do you mean the existing system, or the new system that's being implemented? The previous system apparently made the same mistakes as previous computer algebra systems. Perhaps because the programmers were not sufficiently aware of what was done before. I don't know what has been done for the new system, but if the programmers are STILL ignorant of the history of this problem, I wonder if it will be better. And in general, if you think this is all misguided - what are you doing here? trying to educate. the world does not need more crappy duplicative software. even in python. We have a saying in Germany: If you wish to give advice, pick the people up where they stand. We have a saying in this country that three months in the programming lab can save you half an hour in the library What I'm reading from you is theory, with no indication how to apply, or where to start, or anything. I'm sorry, but I'm not paid enough to direct you from day to day. Reading a book or some papers, maybe taking a course, would help. You do not seem to even have looked into the overall code structure, to identify the low-hanging fruit. I'm not interested in picking low-hanging fruit and reprogramming stuff in python. I'm interested in noticing the high-level bad design which will make the system no better, and probably worse, than what has been done before You don't even have a plan to identify which fruit are hanging at what altitude... and I'm not seeing how telling us you're doing it all wrong is going to help SymPy along if you stay silent on what's wrong, or in what ways it is wrong, or (most importantly) how it could be done better. If you think you are doing it all right, and that the only changes needed are incremental fixes to low hanging fruit, then feel free to continue exactly the way you are going. Maybe sympy II will be better. Or maybe some other post-python language will become popular and another group of people will write sympy (I) in that language and re-invent the same problematical designs. Not that I can't sympathize with your points, or your position. Being specific requires work, and I guess you don't have an unlimited time budget. It is not my job or interest to rewrite programs (some of which I have written) in python for the sake of python I can even sympathize with your Lisp preference (though I'd prefer Haskell since it's 90% of Lisp's capabilities but ten times the guarantees, plus performance aspects would be so different that it's an experiment worth actually doing). You are welcome to write in Haskell, but that doesn't improve the design, ordinarily. But... it's not going to lead anywhere at the level I'm seeing here. Just curious what thinking is motivating you. what motivates you? The realization that it was a repeated case of unhelpful feedback. I'm not going to read the python code and tell you how to diddle it. The wish to improve that situation. I observed the behavior and from that deduced the design errors. It is your job to study existing literature and systems if you want to do something at least as good. There are thousands of commands constituting numerous computational subsystems and interacting data structures in a system like Mathematica, Maple, Maxima. Re-programming in python is one possibility. Studying and improving them while programming in python is another, better idea. Re-inventing them from scratch is, with high probability, a worse idea. If you find this unhelpful, it is probably because you are re-inventing, and don't want to hear... ' -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit
Re: [sympy] vector expressions with unspecified dimension
I'd love to have someone implement matrix derivative. This shouldn't be hard for someone who understands them well. On Mon, Apr 28, 2014 at 7:37 PM, Aaron Meurer asmeu...@gmail.com wrote: These little issues with the transpose are the reason this isn't implemented yet. Aaron Meurer On Mon, Apr 28, 2014 at 2:18 PM, Tim Lahey tim.la...@gmail.com wrote: It's only 2*A*x is A is symmetric (A.T = A). Otherwise it's (A.T + A). That said, I don't think Matrix Expressions support derivatives at the moment. Cheers, Tim. On 2014-04-28, at 1:27 PM, Gustavo gustavo.goret...@gmail.com wrote: Can I have matrices and vectors A and x with compatible but unspecified dimensions. And get diff(x.T * A * x , x) return 2*A*x ? Thanks, Gustavo -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/340D188D-2402-47E1-829B-1E42297C89BD%40gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L4S-R2fdWrgo%2ByUO9QJKgpaj7icrpRgw08%3DjXTGXM8zQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Hfp90LqkHcdW5TzcrTqxvV4yCMj5ZOCkN64JKGSps1Kg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
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, every known trig identity). I'm assuming that this is what was meant by multi-pattern unification. It's essentially a search in a potentially infinite decision tree. I think that's already polynomial, possibly even undecidable. The large decision tree search problem comes after you determine which patterns might possibly match. That is also a fun problem. To be explicit, given an expression and a knowledgebase of patterns first see which patterns are valid, then choose which patterns to apply. Both of these operations are interesting. It's possible to store 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 sophisticated solutions. Can't we deal with commutativity by normalizing the tree? E.g. in polynoms, it's already commonplace to put the higher exponents to the left; set up a total order over expressions that includes this and similar conventions. Similar for associative operators; there, we turn A+(B+C) into plus(A,B,C) and don't have to worry about burdening the unification algorithm with semantic subtleties. For commutativity, yes, for associativity and commutativity no. Match x + B to A+B+C. This problem is typically solved for a single pattern by performing a bipartite matching. It's more complex when there exists several patterns and you don't want to check each of them linearly. For trig simplification, there is a paper that I think uses some systematic way to simplify it. So it might be that for that you don't need to check all the trig identities. Yeah, so this is actually in SymPy. Chris Smith already implemented this in fusimp. Note that this doesn't use pattern matching but it does search through a tree of small transformations. fu(sin(x)/cos(x)) # default objective function tan(x) fu(sin(x)/cos(x), measure=lambda x: -x.count_ops()) # maximize op count sin(x)/cos(x) 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/821fc389bcb728f6ec46c32afa38faceeab1/sympy/simplify/fu.py#L1597 I think that's the general approach. Do not exhaust the decision tree, follow a search strategy. Applies to trig, integrals, polynom simplification, and probably almost all areas of mathematics. Can this be captured as a simple priority value on each substitution rule? You can get pretty far with a simple priority value. Often times greedy solutions don't produce optimal results. My solution to this is to follow a greedy solution but then allow backtracking, allowing the user to ask for extra results. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GKTNEkdakDCJf-eSW70cRC4xPD_dnyCQjAuTrLtgEFKw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] MatrixSymbol and diff function
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 Matrix Expressions. I'm going to claim that Matrix
expressions are much simpler in design than the core. Part of this is the
use of new assumptions. Injecting a Symbol, a huge source of magic, right
in the center of matrix expressions makes my skin crawl a tiny bit. A good
compromise is to make a Symbol object that is only a Symbol object, and not
a scalar value with old assumptions info attached.
On Fri, Apr 25, 2014 at 3:37 AM, Clifford Wolf cliffordvie...@gmail.comwrote:
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 thing to fix is this: type(MatrixSymbol.args[0]) is str. It
is the name of the symbol. I think there is even a docstring somewhere that
states that all members of .args must be derived from Basic, and it
actually breaks a couple of functions if this is not the case. For example
the following code throws an AttributeError because str has no .match:
from sympy import *
from sympy.abc import n, m
X = MatrixSymbol('X', n, m)
X.find(n)
At the moment MatrixSymbol.is_Symbol=False, which kind of makes sense
because it has arguments (the dimensions) that can be arbitrary
expressions. But it also means that there is code that tries to clone it by
performing X.func(*X.args), so the symbol name must be contained in args
somehow.
I would recommend to sympify the symbol name, i.e. effectively turning
MatrixSymbol into an operator that turns an ordinary symbol into a matrix
symbol. This has the downside that mixing Symbol('X') and MatrixSymbol('X',
n, m) can have strange effects, but it is the best solution I can think of.
Any other ideas how to fix this problem?
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/138f058b-f8c3-4faa-89da-22f4c8774d51%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/138f058b-f8c3-4faa-89da-22f4c8774d51%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-F-kaJs4HQXrQ%3DM9JP7t4NsUOxwBoEj8OYCe_C_RB%3Dpew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
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 ondrej.cer...@gmail.comwrote: 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 sophisticated solutions. Can't we deal with commutativity by normalizing the tree? E.g. in polynoms, it's already commonplace to put the higher exponents to the left; set up a total order over expressions that includes this and similar conventions. Similar for associative operators; there, we turn A+(B+C) into plus(A,B,C) and don't have to worry about burdening the unification algorithm with semantic subtleties. For commutativity, yes, for associativity and commutativity no. Match x + B to A+B+C. This problem is typically solved for a single pattern by performing a bipartite matching. It's more complex when there exists several patterns and you don't want to check each of them linearly. For trig simplification, there is a paper that I think uses some systematic way to simplify it. So it might be that for that you don't need to check all the trig identities. Yeah, so this is actually in SymPy. Chris Smith already implemented this in fusimp. Note that this doesn't use pattern matching but it does search through a tree of small transformations. fu(sin(x)/cos(x)) # default objective function tan(x) fu(sin(x)/cos(x), measure=lambda x: -x.count_ops()) # maximize op count sin(x)/cos(x) This is impressive!! It can do stuff like this: In [3]: cos((x+y)/2) * sin((x-y)/2) Out[3]: sin(x/2 - y/2)*cos(x/2 + y/2) In [4]: fu(_) Out[4]: sin(x)/2 - sin(y)/2 In [7]: sec(x) / (2*sin(x)) Out[7]: sec(x)/(2*sin(x)) In [8]: fu(_) Out[8]: 1/sin(2*x) I had no idea that this was implemented. That's very exciting. Ondrej 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/821fc389bcb728f6ec46c32afa38faceeab1/sympy/simplify/fu.py#L1597 I think that's the general approach. Do not exhaust the decision tree, follow a search strategy. Applies to trig, integrals, polynom simplification, and probably almost all areas of mathematics. Can this be captured as a simple priority value on each substitution rule? You can get pretty far with a simple priority value. Often times greedy solutions don't produce optimal results. My solution to this is to follow a greedy solution but then allow backtracking, allowing the user to ask for extra results. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GKTNEkdakDCJf-eSW70cRC4xPD_dnyCQjAuTrLtgEFKw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVBhF5gtUfzr7iCXJQbix8ecfVdt%3DWCyykxFdFoiCpFzEw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HUrN_ac7nT8e86rsaiEPXmeTPAtwPqts059PJ6HJCCMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] MatrixSymbol and diff function
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-for-matrix-expressions 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) class or something similar. On Fri, Apr 25, 2014 at 9:18 AM, Clifford Wolf cliffordvie...@gmail.comwrote: 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 reading sympy code for a day or so now, but I have to agree with Aaron: I also don't like the ideas of non-basics in args.. Where I win though is with the claim that Symbol is way too magical and big to be used in Matrix Expressions. I'm going to claim that Matrix expressions are much simpler in design than the core. Part of this is the use of new assumptions. Injecting a Symbol, a huge source of magic, right in the center of matrix expressions makes my skin crawl a tiny bit. A good compromise is to make a Symbol object that is only a Symbol object, and not a scalar value with old assumptions info attached. You mean something like a MatrixSymbolName class with is_Symbol = True but otherwise just a container for the one string? Are there any plans or existing infrastructure for storing assumptions on matrices, such as is_positive_definite? When I suggested to store a Symbol in MatrixSymbol.args[0] I also thought about maybe using this Symbol to store assumptions regarding the matrix.. What are your thoughts on that? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b2a85eff-8e8c-4473-80c1-9fcda862cd49%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/b2a85eff-8e8c-4473-80c1-9fcda862cd49%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HOt3bxjw8v3yt6B3KOCvr5V__hCrLru6x7nX_3UwgJuw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] MatrixSymbol and diff function
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 huge headache when inter-operating with sympy. Essentially whenever I hook something else into sympy I tell it about type and .args. Then I go and special case every exception. I interoperate with sympy a fair amount from external projects so I tend to resist this this sort of solution pretty strongly. Matrix Expressions is currently pure in this sense. It serves as a nice example of a very easy-to-deal-with system. On Fri, Apr 25, 2014 at 10:34 AM, Clifford Wolf cliffordvie...@gmail.comwrote: 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) class or something similar. Just thinking out loud: What's about storing the name directly in MatrixSymbol.name and overloading MatrixSymbol.func to [return a closure that] inject[s] the name into a new instance. This would make sense because afaics the whole idea behind the .args interface is make it easy to implement generic transformations, and I don't see why such transformations should ever want to change the name of a MatrixSymbol. In this sense the dimensions are the only 'arguments' to a MatrixSymbol. (The symbol name is afaics not an 'argument' of Symbol objects either.) -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/26b50466-8966-49e0-94d1-075011a6a063%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/26b50466-8966-49e0-94d1-075011a6a063%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-G7Pze_Z9im%2BWX2Tho7ao7a%3DTwSBiCHxMrL-2QmB6OAZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] MatrixSymbol and diff function
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, Aaron Meurer asmeu...@gmail.com wrote: 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, which deals in the core of the design of SymPy, so fair warning. The next best solution I think was to create a non-Expr Symbol and use that, which would take care of Matthew's worries about assumptions and so on. That should not be that difficult to do, I think. Aaron Meurer On Fri, Apr 25, 2014 at 12:34 PM, Clifford Wolf cliffordvie...@gmail.com wrote: 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) class or something similar. Just thinking out loud: What's about storing the name directly in MatrixSymbol.name and overloading MatrixSymbol.func to [return a closure that] inject[s] the name into a new instance. This would make sense because afaics the whole idea behind the .args interface is make it easy to implement generic transformations, and I don't see why such transformations should ever want to change the name of a MatrixSymbol. In this sense the dimensions are the only 'arguments' to a MatrixSymbol. (The symbol name is afaics not an 'argument' of Symbol objects either.) -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/26b50466-8966-49e0-94d1-075011a6a063%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LB2TqN_uBxS9hxJ7Q6Yd2Ww-JN7EjebMWbH8fej4UFkA%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-H_cSZj-QBVKnNf3eTi8zeY-3dMRQG%3D6QsztuO03Az%2BDQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
By the way, is there any implementation of MiniKanren in C++? Maybe that in such a case one could try to write some algorithms in a rule-based format (as in MiniKanren), then either load these rules through SymPy and LogPy, or through CSymPy and some other parsing library (or maybe even by template metaprogramming). But I'm just speculating. Yeah, I've given thought to low-level approaches to tree transformation. That's the sort of algorithm that could interface with SymPy Trees pretty naturally. I think that the answer is to implement just a few parts in C++, SymPy really doesn't need a full logic programming system. We only need things like multi-pattern unification and AC unification. Note that there are mature efficient projects that do this (and lots of other things) already. Elan and Stratego/XT come to mind. They're heavy dependencies though. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FgGQR3ECRk62YcSfDwR%3D8g%2BOcb%2B91TVMfG_V6fy7%2Bkbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
We only need things like multi-pattern unification and AC unification. 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, every known trig identity). It's possible to store 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 sophisticated solutions. Note that there are mature efficient projects that do this (and lots of other things) already. Elan and Stratego/XT come to mind. They're heavy dependencies though. I'm not sure what the consensus on dependencies is, but I myself think that a dependency is okay if we can either make sure that a specific, tested version is used, or if we expect the APIs to be stable and the need to fork for bug fixes or extensions is nonexistent. When I say heavy I mean that these are straight research projects. They're very good but there is virtually no distribution support here. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-F%3D2aYDK1KF-%3D2PNwqnKXvUqiaoY88kQrWtD1h-PMhzZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] MatrixSymbol and diff function
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.
On Thu, Apr 24, 2014 at 4:16 PM, Aaron Meurer asmeu...@gmail.com wrote:
If we override _eval_derivative on MatrixElement can we make it do the
right thing?
Aaron Meurer
On Mon, Apr 21, 2014 at 6:50 AM, Clifford Wolf cliffordvie...@gmail.com
wrote:
Hello,
On Thursday, August 22, 2013 6:23:36 PM UTC+2, Matthew wrote:
Fortunately this issue does not descend from the larger issue and can be
solved independently. See https://github.com/sympy/sympy/pull/2402
I think setting MatrixElement._diff_wrt = True was a bad decision.
https://github.com/sympy/sympy/issues/7421
When running expr.diff(wrt), then the code in Derivative.__new__ that
handles _diff_wrt works under the assumption that the terms in expr are
either independent from wrt or contain an identical replica. Consider
code
like the following:
i,n = symbols('i,n')
w = MatrixSymbol('w', n, 1)
result = Sum(123*w[i, 0], (i, 0, n - 1)).diff(w[0,0])
Derivative.__new__ will replace w[0,0] with a dummy symbol and attempt to
also replace it in the expression. But in the expression we only have
w[i,0]
and Expr.subs does not understand how w[i,0] relates to w[0,0], yielding
something like:
result = Sum(123*w[i, 0], (i, 0, n - 1)).diff(_x1)
Therefore result is set to 0 instead of 123.
I can understand the need for supporting differentiation with respect to
MatrixElements, but I think it can't be done with a simple Expr._diff_wrt
property. Instead we would need something like
MatrixElement._diff_subs_wrt(self, expr) that returns a tuple of the new
expression and the dummy variable, or None if differentiation is not
possible. Such a method could then check for terms in expr that might or
might not overlap with wrt in a way that can not be handled correctly at
the
moment, or even rewrite the expression (for example unroll the case i==0
out
of the sum) to make differentiation possible.
regards,
- clifford
PS: I'm new to sympy (this is the first time I looked into the sympy
source
code), so I don't really have a much insight yet. If what I say makes no
sense, it might be because I have no idea what I am talking about.. ;)
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/b18af010-e570-4182-a5a4-389b159d5213%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6L_5tJLBDOcoLS_PrDD0XsA%3DtPoiWo1fZSoau7QcAqUkA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-FZYtJRUjEC7cRtwek_Mk3--anQ56AFJq8mgx3yFPBx%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
Just wanted to pop in and say that I really like this conversation. Question, how fast could sympy core be if we were to pull out some of the assumptions logic until a final step at the end. What stops core from reaching polys speed? On Apr 23, 2014 9:08 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Apr 23, 2014 at 10:02 AM, Aaron Meurer asmeu...@gmail.com wrote: Just use x = Poly(x**x). That's the dense representation. No idea how to do this with ring(). Mateusz will have to show us. But the polynomials you're creating in this benchmark are univariate and dense anyway. We should also be plotting the dependence on N, as different data structures have different behaviors, for example hash table (unordered_map, or dict in Python) vs. red-black trees (std::map). Ultimately though, and that's the main issue, instead of concentrating on these artificial benchmarks, I am concentrating on real world applications, thus PyDy. If PyDy could be done with sympy.polys, then that would be good, but I am afraid it can't, as it has stuff like sin, cos, unevaluated functions like f1(t), and so on. Ondrej -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVBUr%3DTGqE8OdfUQSnPqP-6Udb_98iuP2iXpCYyNwMMhKw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fj%3DVwotBZKNFb2shVD8Nn3-T-ZFumXjrzR25hWjgDD_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
Perhaps a good target workflow would be something like the following from sympy import * from csympy import * ... do work as usual ... In other words it would be nice for csympy to take over from sympy where it has functionality, but for sympy-proper to fill in all of the holes. Ondrej, is this on your roadmap at all? It gets weird of course when you have something like Expr(...) + CExpr(...) -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fh%3DFR5LM2Uehn%2BWTdFs%3D8QBys%2B2BoPXUdZKgdWeHaqbA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Questions about the goals of CSymPy
I generally agree with Aaron and Brian that I'd like to see CSymPy be as small as possible and focus more on SymPy-CSymPy integration. My opinion is that performant cores should be small. That being said I think that it's generally a good thing for Ondrej to go off and screw around with a C++ implementation in isolation. Attaching himself to the existing SymPy infrastructure would probably bog down development. Even O(n) performance gains are a good thing, and this is something about which Ondrej knows quite a lot. I also think that, if CSymPy can make a compelling case for integration (perhaps through a PyDy solution), then at least some of the integration effort should come from the SymPy side, changing itself to adhere to something more CSymPy friendly (e.g. changing how Function works). I think that working on interoperation is good for SymPy in the long run. Ondrej, I think that folks would generally be more comfortable if we better understood the strategy for eventual SymPy-CSymPy integration. Right now I don't have a good handle on this. From far away it's not apparent that this is a major design goal of CSymPy. On Wed, Apr 23, 2014 at 3:43 PM, Matthew Rocklin mrock...@gmail.com wrote: PyDy sounds like the perfect proof of concept test for CSymPy On Wed, Apr 23, 2014 at 3:42 PM, Jason Moore moorepa...@gmail.com wrote: Yeah, all I'm planning to do on that PR is to make a hack that inserts csympy data types into the core mechanics objects (Vectors, Dyadics, etc). The nice thing about the vector and mechanics module is that we only use symbols, functions, differentiation, addition, multiplication, basic trig functions, etc. Really a small subset of functionality that sympy offers. This will give a simpler test to see what it takes to have csympy work seamlessly. I'll try to spend some time this weekend to update that PR with Ondrej's latest features in csympy. Jason moorepants.info +01 530-601-9791 On Wed, Apr 23, 2014 at 6:36 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote: On Wed, Apr 23, 2014 at 4:31 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Apr 23, 2014 at 4:27 PM, Aaron Meurer asmeu...@gmail.com wrote: Well that would only affect what you do in your own workspace. Much better would be if sympy transparently imported and used csympy wherever relevant when it was available, so that sympy.Symbol would be csympy.Symbol, and so on. Then everywhere in sympy would use csympy. That's a good idea. There is of course the issue with assumptions, attached to the Symbols... But this requires full interoperability between sympy and csympy (which is one of the things I have not seen yet). I think the next task for csympy should be: - Patch sympy/core/symbol.py to use csympy.Symbol (so that from sympy.core.symbol import Symbol gives csympy.Symbol) - Run the tests - Fix whatever fails - Repeat with further csympy objects And always do this with every csympy object that is written. We perhaps need a more unified way to automatically replace anything in sympy with csympy (especially since Ondrej still hasn't provided a clear separation between what will and will not be in csympy, at least in my mind). Then we can stop making these artificial benchmarks and performance speculations, and just see what really is slow, and what really speeds things up, and, just as importantly, what doesn't speed things up enough to warrant the complexity cost. I would focus on this rather than PyDy specifically. It may be possible to use csympy in PyDy without doing this, but it will be a wasted effort if you eventually do this and then the PyDy specific implementation can be scrapped. The goal of using CSymPy in PyDy is precisely to do this switch (single line of code) in PyDy only, not the core of SymPy. Because that's a lot simpler (no need to worry about assumptions) and tons of tests. And doing a real application where speed matters. So that we are not just talking, here is the actual code: https://github.com/sympy/sympy/pull/7397 It's simple, and we are still trying to make it more simple (=more compatible with SymPy), until it is really just one line. There are some technical issue like our Function(f) would correspond to just raw class in C++, except that C++ doesn't support that, so I have a function called function_symbol(f, x), and so on. This could be abstracted in the Python wrappers and so on. This will all be fixed eventually. Aaron, I think you want to have full compatibility with SymPy immediately. But there could be significant speed/efficiency cost, and I need to make sure that the speed of the C++ core is optimal. The time frame is roughly this summer, when we implement enough features to be useful for PyDy and do some serious benchmarking on real world problems. After that it would be good time to review the Python API to make sure it works well
Re: [sympy] SymPy args and multiple dispatch
Performance? Somebody (you) said that MD does not come for free. I brought this up. I can't get a MD call to go below about a microsecond. This is a few times slower than a Python call. It's many times faster than your average SymPy operation. If anyone wanted to try to get it to go faster that'd be awesome. The code is, I think, pretty small and approachable. Python is likely to recognize tuple operations an apply better optimizations than on Tuple. Not if the call goes through multiple dispatch. This could change if MD becomes a widely recognized and adopted library, but it's not there today. I think that MD needs some major library to start using it. There is a lot of interest but I think that no project wants to be the first to invest. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GxmEyDpqsw4Yf3B5t-QjiU06zoMdBrgGA02Nc7dDA_Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SymPy args and multiple dispatch
I really like this idea (though perhaps that's to be expected :) ) -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Eh-vaCN1YKKZMBr7CoCEu7MiNU0qQc7FxPy_P85UxOfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Tensor refactory
Sets is a good play module for this purpose. Union and Intersection simplify pairwise much like Add and Mul would. I like the pairwise methods we have but the strategy to orchestrate them could use some cleaning up. Might be a good place to build intuition. See https://github.com/sympy/sympy/pull/2979 On Fri, Apr 11, 2014 at 8:27 AM, Aaron Meurer asmeu...@gmail.com wrote: This has always been the original motivation for multiple dispatch, at least in my mind. You can't make objects that do their own thing in Add or Mul or whatever. There are a dozen example of this throughout SymPy, and a dozen more in user code. There are many hacky ways around it, but none are satisfactory. The problem is, how do you dispatch Add(*args). Any argument of the Add might want to do anything with any other argument. You don't want to require that arguments be next to each other, because then something as simple as Add(yourobject, 0, yourobject) wouldn't do the right thing. You can do the n**2 passes, but does it remain efficient at that point? I think we should just start to play with this, especially now that we have a decent implementation of multiple dispatch. I'd personally rather play with this with a module that I can understand (so, e.g., matrix expressions rather than tensores), but anything is better than nothing. Aaron Meurer On Fri, Apr 11, 2014 at 5:17 AM, F. B. franz.bona...@gmail.com wrote: 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 the addition of an index management mechanism, as well as other features such as components data association. Of course some precautions should be taken, for example all indices have to be contracted if you take the exponential of a tensor expression (I am wondering, did anyone ever define a unique and consistent way to generalize the matrix exponential to tensors of any rank?). -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b7592a77-00ef-4c82-a94b-f0e904581c63%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L%2B0wx_h1YFT83swB90WwYq_fL3W6q-61frXxr-rUo0YQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fh-a3sJ9NFRG%3DNt1bxcbkqcTLzcOPTMjGU4Hy%2BxEmdAg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Tensor refactory
Well, sets *is* in the core. Interval, Union, and FiniteSet are all used in various parts. Fortunately though I think we refactor without changing functionality. So far I've just replaced a custom double dispatch system with multipledispatch. On Fri, Apr 11, 2014 at 8:46 AM, Aaron Meurer asmeu...@gmail.com wrote: Oh, that's even better. Then we don't have to touch the core, and we can merge even experimental things faster. Aaron Meurer On Fri, Apr 11, 2014 at 10:40 AM, Matthew Rocklin mrock...@gmail.com wrote: Sets is a good play module for this purpose. Union and Intersection simplify pairwise much like Add and Mul would. I like the pairwise methods we have but the strategy to orchestrate them could use some cleaning up. Might be a good place to build intuition. See https://github.com/sympy/sympy/pull/2979 On Fri, Apr 11, 2014 at 8:27 AM, Aaron Meurer asmeu...@gmail.com wrote: This has always been the original motivation for multiple dispatch, at least in my mind. You can't make objects that do their own thing in Add or Mul or whatever. There are a dozen example of this throughout SymPy, and a dozen more in user code. There are many hacky ways around it, but none are satisfactory. The problem is, how do you dispatch Add(*args). Any argument of the Add might want to do anything with any other argument. You don't want to require that arguments be next to each other, because then something as simple as Add(yourobject, 0, yourobject) wouldn't do the right thing. You can do the n**2 passes, but does it remain efficient at that point? I think we should just start to play with this, especially now that we have a decent implementation of multiple dispatch. I'd personally rather play with this with a module that I can understand (so, e.g., matrix expressions rather than tensores), but anything is better than nothing. Aaron Meurer On Fri, Apr 11, 2014 at 5:17 AM, F. B. franz.bona...@gmail.com wrote: 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 the addition of an index management mechanism, as well as other features such as components data association. Of course some precautions should be taken, for example all indices have to be contracted if you take the exponential of a tensor expression (I am wondering, did anyone ever define a unique and consistent way to generalize the matrix exponential to tensors of any rank?). -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b7592a77-00ef-4c82-a94b-f0e904581c63%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L%2B0wx_h1YFT83swB90WwYq_fL3W6q-61frXxr-rUo0YQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fh-a3sJ9NFRG%3DNt1bxcbkqcTLzcOPTMjGU4Hy%2BxEmdAg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BOOW5iHNsOCbFW26A6zh7j%3DnCm57pNTu8hTCv8m81i5Q%40mail.gmail.com . For more options, visit https
Re: [sympy] Re: Tensor refactory
The benefit of sets is that everyone can understand it but it still has enough complex elements (ProductSet, EmptySet) to capture the complexity of a lot of the more challenging systems (though probably not quite as challenging as tensors.) On Fri, Apr 11, 2014 at 9:05 AM, Matthew Rocklin mrock...@gmail.com wrote: Well, sets *is* in the core. Interval, Union, and FiniteSet are all used in various parts. Fortunately though I think we refactor without changing functionality. So far I've just replaced a custom double dispatch system with multipledispatch. On Fri, Apr 11, 2014 at 8:46 AM, Aaron Meurer asmeu...@gmail.com wrote: Oh, that's even better. Then we don't have to touch the core, and we can merge even experimental things faster. Aaron Meurer On Fri, Apr 11, 2014 at 10:40 AM, Matthew Rocklin mrock...@gmail.com wrote: Sets is a good play module for this purpose. Union and Intersection simplify pairwise much like Add and Mul would. I like the pairwise methods we have but the strategy to orchestrate them could use some cleaning up. Might be a good place to build intuition. See https://github.com/sympy/sympy/pull/2979 On Fri, Apr 11, 2014 at 8:27 AM, Aaron Meurer asmeu...@gmail.com wrote: This has always been the original motivation for multiple dispatch, at least in my mind. You can't make objects that do their own thing in Add or Mul or whatever. There are a dozen example of this throughout SymPy, and a dozen more in user code. There are many hacky ways around it, but none are satisfactory. The problem is, how do you dispatch Add(*args). Any argument of the Add might want to do anything with any other argument. You don't want to require that arguments be next to each other, because then something as simple as Add(yourobject, 0, yourobject) wouldn't do the right thing. You can do the n**2 passes, but does it remain efficient at that point? I think we should just start to play with this, especially now that we have a decent implementation of multiple dispatch. I'd personally rather play with this with a module that I can understand (so, e.g., matrix expressions rather than tensores), but anything is better than nothing. Aaron Meurer On Fri, Apr 11, 2014 at 5:17 AM, F. B. franz.bona...@gmail.com wrote: 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 the addition of an index management mechanism, as well as other features such as components data association. Of course some precautions should be taken, for example all indices have to be contracted if you take the exponential of a tensor expression (I am wondering, did anyone ever define a unique and consistent way to generalize the matrix exponential to tensors of any rank?). -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b7592a77-00ef-4c82-a94b-f0e904581c63%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L%2B0wx_h1YFT83swB90WwYq_fL3W6q-61frXxr-rUo0YQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Fh-a3sJ9NFRG%3DNt1bxcbkqcTLzcOPTMjGU4Hy%2BxEmdAg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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
Re: [sympy] Re: Tensor refactory
All I know is that Interval and Union were there before I got here. Maybe integrals? I've changed things in FiniteSet and had some core things break. But yes, Set is not Expr or Basic. On Fri, Apr 11, 2014 at 9:09 AM, Aaron Meurer asmeu...@gmail.com wrote: I don't mean the core as in sympy.core. I mean the core as in the base classes Basic, Expr, Add, Mul (and to some extend the numbers). Stuff that *everything* uses. Not everything uses the sets. Unless I'm missing some very core use of the sets. Aaron Meurer On Fri, Apr 11, 2014 at 11:05 AM, Matthew Rocklin mrock...@gmail.com wrote: Well, sets is in the core. Interval, Union, and FiniteSet are all used in various parts. Fortunately though I think we refactor without changing functionality. So far I've just replaced a custom double dispatch system with multipledispatch. On Fri, Apr 11, 2014 at 8:46 AM, Aaron Meurer asmeu...@gmail.com wrote: Oh, that's even better. Then we don't have to touch the core, and we can merge even experimental things faster. Aaron Meurer On Fri, Apr 11, 2014 at 10:40 AM, Matthew Rocklin mrock...@gmail.com wrote: Sets is a good play module for this purpose. Union and Intersection simplify pairwise much like Add and Mul would. I like the pairwise methods we have but the strategy to orchestrate them could use some cleaning up. Might be a good place to build intuition. See https://github.com/sympy/sympy/pull/2979 On Fri, Apr 11, 2014 at 8:27 AM, Aaron Meurer asmeu...@gmail.com wrote: This has always been the original motivation for multiple dispatch, at least in my mind. You can't make objects that do their own thing in Add or Mul or whatever. There are a dozen example of this throughout SymPy, and a dozen more in user code. There are many hacky ways around it, but none are satisfactory. The problem is, how do you dispatch Add(*args). Any argument of the Add might want to do anything with any other argument. You don't want to require that arguments be next to each other, because then something as simple as Add(yourobject, 0, yourobject) wouldn't do the right thing. You can do the n**2 passes, but does it remain efficient at that point? I think we should just start to play with this, especially now that we have a decent implementation of multiple dispatch. I'd personally rather play with this with a module that I can understand (so, e.g., matrix expressions rather than tensores), but anything is better than nothing. Aaron Meurer On Fri, Apr 11, 2014 at 5:17 AM, F. B. franz.bona...@gmail.com wrote: 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 the addition of an index management mechanism, as well as other features such as components data association. Of course some precautions should be taken, for example all indices have to be contracted if you take the exponential of a tensor expression (I am wondering, did anyone ever define a unique and consistent way to generalize the matrix exponential to tensors of any rank?). -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b7592a77-00ef-4c82-a94b-f0e904581c63%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L%2B0wx_h1YFT83swB90WwYq_fL3W6q-61frXxr-rUo0YQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy
Re: [sympy] zip() argument after * must be a sequence
Yeah, that's pretty fantastic. I'm curious to know how much work was involved. Is it possible to push your changes back to our codebase? We'd be happy to enable this. On Wed, Apr 9, 2014 at 3:38 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote: On Wed, Apr 9, 2014 at 3:43 AM, Groover aja...@gmail.com wrote: I now have sympy git-master working with IronPython 2.7.5b1 and this problem no longer occurs. I get the same result as Matthew. Nice! Ondrej -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVBCckDrpjir%3DHMNr%2Boe9wd3MW%3DPqkLXL%3DVDx8G8VVo8Hg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GhRcYSzX58nEEkq8OKAmTA8tyPAyjLECBU9JRyn%3D01dQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] zip() argument after * must be a sequence
Symbol should be upper case. Other than that everything is fine. You also
might want to update your sympy version at some point
In [1]: from sympy import *
In [2]: x = Symbol('x')
In [3]: d = diff(2 * pow(x, 2), x)
In [4]: d
Out[4]: 4*x
In [5]: length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
In [6]: length
Out[6]: -5*sqrt(401)/2 - asinh(20)/8 + asinh(40)/8 + 5*sqrt(1601)
On Sat, Apr 5, 2014 at 4:00 AM, Groover aja...@gmail.com wrote:
Hello,
It's been 20 years since I did any calculus, so please be gentle. :)
Using SymPy 0.7.2 and IronPython 2.7.4.
import sympy
from sympy import *
# calculate arc length
x = symbol('x')
d = diff(2 * pow(x, 2), x)
print d
length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
print length
This outputs '4*x' as expected then 'zip() argument after * must be a
sequence, not dictionary-itemiterator'.
I believe the integration is solvable to 75.173 [1], so I assume I have an
error in my Python and/or SymPy syntax. Can anyone please give me some
pointers? Thanks!
[1]
http://www.integral-calculator.com/#expr=sqrt%281%2B%284x%5E2%29%29ubound=10lbound=5
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-EFubCeaoaZOL3sfykJYHzn9S1TM3LneztWgd%3Dnoj8BZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] zip() argument after * must be a sequence
Also, feel free to use x**2 rather than pow(x, 2) . Your integrand here is
not the same as what you put in to the integral calculator.
On Sat, Apr 5, 2014 at 8:38 AM, Matthew Rocklin mrock...@gmail.com wrote:
Symbol should be upper case. Other than that everything is fine. You
also might want to update your sympy version at some point
In [1]: from sympy import *
In [2]: x = Symbol('x')
In [3]: d = diff(2 * pow(x, 2), x)
In [4]: d
Out[4]: 4*x
In [5]: length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
In [6]: length
Out[6]: -5*sqrt(401)/2 - asinh(20)/8 + asinh(40)/8 + 5*sqrt(1601)
On Sat, Apr 5, 2014 at 4:00 AM, Groover aja...@gmail.com wrote:
Hello,
It's been 20 years since I did any calculus, so please be gentle. :)
Using SymPy 0.7.2 and IronPython 2.7.4.
import sympy
from sympy import *
# calculate arc length
x = symbol('x')
d = diff(2 * pow(x, 2), x)
print d
length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
print length
This outputs '4*x' as expected then 'zip() argument after * must be a
sequence, not dictionary-itemiterator'.
I believe the integration is solvable to 75.173 [1], so I assume I have
an error in my Python and/or SymPy syntax. Can anyone please give me some
pointers? Thanks!
[1]
http://www.integral-calculator.com/#expr=sqrt%281%2B%284x%5E2%29%29ubound=10lbound=5
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-FRBBVxaC71UOpF9pbCeRW-qGWvo3t9YYMyJsvUCfg6ew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] zip() argument after * must be a sequence
Also, any feedback from using SymPy with IronPython? We don't get a lot of
feedback from that community, your thoughts/concerns here would be
appreciated.
On Sat, Apr 5, 2014 at 8:40 AM, Matthew Rocklin mrock...@gmail.com wrote:
Also, feel free to use x**2 rather than pow(x, 2) . Your integrand here
is not the same as what you put in to the integral calculator.
On Sat, Apr 5, 2014 at 8:38 AM, Matthew Rocklin mrock...@gmail.comwrote:
Symbol should be upper case. Other than that everything is fine. You
also might want to update your sympy version at some point
In [1]: from sympy import *
In [2]: x = Symbol('x')
In [3]: d = diff(2 * pow(x, 2), x)
In [4]: d
Out[4]: 4*x
In [5]: length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
In [6]: length
Out[6]: -5*sqrt(401)/2 - asinh(20)/8 + asinh(40)/8 + 5*sqrt(1601)
On Sat, Apr 5, 2014 at 4:00 AM, Groover aja...@gmail.com wrote:
Hello,
It's been 20 years since I did any calculus, so please be gentle. :)
Using SymPy 0.7.2 and IronPython 2.7.4.
import sympy
from sympy import *
# calculate arc length
x = symbol('x')
d = diff(2 * pow(x, 2), x)
print d
length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))
print length
This outputs '4*x' as expected then 'zip() argument after * must be a
sequence, not dictionary-itemiterator'.
I believe the integration is solvable to 75.173 [1], so I assume I have
an error in my Python and/or SymPy syntax. Can anyone please give me some
pointers? Thanks!
[1]
http://www.integral-calculator.com/#expr=sqrt%281%2B%284x%5E2%29%29ubound=10lbound=5
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-Gm8QvRS-%3DuPEb8Nzyt9cRGj5P9-W8Jnj_7_D_x%2BJ_3AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] zip() argument after * must be a sequence
They are the same. I was just suggesting x**y over pow(x, y). Mostly because that's my aesthetic preference. Feel free to ignore. By googling unicode_escape_decode() takes no arguments I run into a stackoverflow question that references using Python from F# so I'm going to guess that this is more of an IronPython than a SymPy problem. My guess is that your other issue boils down to this as well. It looks like IronPython doesn't naturally expand iterators (it mentions dictionary-itemgetter) when used with the * operator. Question to the community, should we endeavor to support IronPython in the same way that we support CPython 2, 3, and PyPy? Question to Andy, do you have a sense of how big the IronPython community that might use SymPy is? This is probably important information to answer the previous question. Regarding your integrand. d is 4x. In the SymPy code you square this giving 16x^2 within the integrand. In the link you posted you're only squaring x, not 4x, and so you get 4*x^2. -Matt On Sat, Apr 5, 2014 at 11:18 AM, Groover aja...@gmail.com wrote: I thought that x**y and the built-in pow(x, y) were the same? Can you please clarify for me how my python integrand is different, as I am a bit unsure. Thanks. Andy On Saturday, April 5, 2014 4:40:35 PM UTC+1, Matthew wrote: Also, feel free to use x**2 rather than pow(x, 2) . Your integrand here is not the same as what you put in to the integral calculator. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/7cc62e0c-898f-40aa-982b-97231b9f5140%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/7cc62e0c-898f-40aa-982b-97231b9f5140%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FLA5AT8_K7dOr97zATYMqJ9%2Bt0V7MoQWFBv3HBNWJzkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] zip() argument after * must be a sequence
One low tech way around this problem is for Andy to fix iron Python compatibility issues in sympy as he runs into them. Presumably he has a suitable environment. For example he could find where we call this zip and wrap the arguments in a list and submit that as a change to sympy. Alternatively (and perhaps better in general) is to alert the apparently active IronPython group about these issues. On Apr 5, 2014 12:15 PM, Groover aja...@gmail.com wrote: Latest stable release was seven months ago. Latest commit to github was two days ago. Andy On Saturday, April 5, 2014 8:05:35 PM UTC+1, Aaron Meurer wrote: I haven't heard much from people using IronPython. I had assumed that the project was somewhat dead. I'd be happy to work around bugs. The biggest issue for us is testing it. You have to have Windows (I tried using Mono a while back, but I didn't have much luck). There is this open issue https://github.com/sympy/sympy/issues/3159. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ad819f2d-758b-4fa9-940b-f3080718828a%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/ad819f2d-758b-4fa9-940b-f3080718828a%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HKe%3DkpQdPLmLVWK4yzGra8wAeC_1aBbt2eXpHvO-03zg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] error when taking mixture of inverse gamma distributions
Done. You should announce that tip to the list. There were indeed some
good questions on there. SO is a good way to keep our collective ear to
the ground.
On Fri, Apr 4, 2014 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
Yes, you can go to http://stackexchange.com/filters/ and set up a filter
for the SymPy tag, and it will email you new questions. Lately there are
new questions almost every single day, so it would definitely help if
others were answering there as well.
The questions on stackoverflow tend to be high quality and often have
rather interesting use-cases (there are doozies, of course, but the worst
questions are closed automatically).
Aaron Meurer
On Tue, Apr 1, 2014 at 9:48 AM, Matthew Rocklin mrock...@gmail.comwrote:
First, thanks for posting the question on stack overflow, I think that we
should use that more. Unfortunately, few of us (maybe only Aaron?)
actually checks SO, again, I think that we should use it more.
Sympy.stats is producing an integral that looks like the following:
In [1]: from sympy.stats import *
In [2]: a, b, c, d, = symbols('a b c d', real=True, positive=True)
In [3]: G1 = GammaInverse(G1, a, b)
In [4]: G2 = GammaInverse(G2, c, d)
In [5]: G3 = S(7)/10*G1 + S(3)/10*G2
In [7]: density(G3, evaluate=False)(x)
Out[7]:
∞
⌠
⎮ ∞
⎮ ⌠
⎮ ⎮ -b
⎮ ⎮ ───
⎮ -d ⎮ -a - 1 a G₁ ⎛7⋅G₁ 3⋅G₂⎞
⎮ ─── ⎮ G₁ ⋅b ⋅ℯ ⋅DiracDelta⎜ + - x⎟
⎮ -c - 1 c G₂ ⎮⎝ 10 10 ⎠
⎮ G₂ ⋅d ⋅ℯ ⋅⎮ d(G₁)
⎮ ⎮ Γ(a)
⎮ ⌡
⎮ 0
⎮ ─
d(G₂)
⎮ Γ(c)
⌡
0
So one could reduce your question into a question like, does anyone have
any thoughts on how SymPy could solve this integral?
On Tue, Apr 1, 2014 at 6:26 AM, John Griffiths
j.davidgriffi...@gmail.com wrote:
Does anyone have any thoughts on how to solve this problem:
When I try to take a weighted mixture of inverse gamma distributions
using sympy.stats I get the following error
%matplotlib inlinefrom matplotlib import pyplot as pltfrom sympy.stats
import GammaInverse, densityimport numpy as np
f1 = 0.7; f2 = 1-f1
G1 = GammaInverse(G1, 5, 120/(5.5*2.5E-7))
G2 = GammaInverse(G2, 4, 120/(5.5*1.5E-7))
G3 = f1*G1 + f2*G2
D1 = density(G1);
D2 = density(G2);
D3 = density(G3);
v1 = [D1(i).evalf() for i in u]
v2 = [D2(i).evalf() for i in u]
v3 = [D3(i).evalf() for i in u]
...which errors at D3 = density(G3). The error includes
PolynomialDivisionFailed: couldn't reduce degree in a polynomial
division algorithm when dividing
[231761.370742578/(0.0011381138741823*G2**2 -
0.007587425827882*G2*_z + 0.0126457097131367*_z**2), 0.0]
by [263.770831541635/263.770831541635, 0.0].
This can happen when it's not possible to detect zero in the coefficient
domain. The domain of computation is RR(G2,_t0,_z). Zero detection is
guaranteed in this
coefficient domain. This may indicate a bug in SymPy or the domain is user
definedand doesn't implement zero detection properly.
(also get this when I take mixture of inverse Gamma with Normal and
Uniform distributions)
Should this be possible?
Cheers.
(p.s. apologies for redundancy with recent SO post)
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HEDx4fraBRj4HARPaCEJKXKaTP3zjS_dbeqd3WoeAAWA%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-HEDx4fraBRj4HARPaCEJKXKaTP3zjS_dbeqd3WoeAAWA%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Re: [sympy] error when taking mixture of inverse gamma distributions
It's to anyone who reads a message with title about inverse gamma
distributions. Which I suspect is just John, because he asked the
question, myself, because I curate stats, and you, because you read
everything :)
On Fri, Apr 4, 2014 at 2:36 PM, Aaron Meurer asmeu...@gmail.com wrote:
This is the list...
Aaron Meurer
On Fri, Apr 4, 2014 at 4:17 PM, Matthew Rocklin mrock...@gmail.comwrote:
Done. You should announce that tip to the list. There were indeed some
good questions on there. SO is a good way to keep our collective ear to
the ground.
On Fri, Apr 4, 2014 at 1:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
Yes, you can go to http://stackexchange.com/filters/ and set up a
filter for the SymPy tag, and it will email you new questions. Lately there
are new questions almost every single day, so it would definitely help if
others were answering there as well.
The questions on stackoverflow tend to be high quality and often have
rather interesting use-cases (there are doozies, of course, but the worst
questions are closed automatically).
Aaron Meurer
On Tue, Apr 1, 2014 at 9:48 AM, Matthew Rocklin mrock...@gmail.comwrote:
First, thanks for posting the question on stack overflow, I think that
we should use that more. Unfortunately, few of us (maybe only Aaron?)
actually checks SO, again, I think that we should use it more.
Sympy.stats is producing an integral that looks like the following:
In [1]: from sympy.stats import *
In [2]: a, b, c, d, = symbols('a b c d', real=True, positive=True)
In [3]: G1 = GammaInverse(G1, a, b)
In [4]: G2 = GammaInverse(G2, c, d)
In [5]: G3 = S(7)/10*G1 + S(3)/10*G2
In [7]: density(G3, evaluate=False)(x)
Out[7]:
∞
⌠
⎮ ∞
⎮ ⌠
⎮ ⎮ -b
⎮ ⎮ ───
⎮ -d ⎮ -a - 1 a G₁ ⎛7⋅G₁ 3⋅G₂⎞
⎮ ─── ⎮ G₁ ⋅b ⋅ℯ ⋅DiracDelta⎜ + - x⎟
⎮ -c - 1 c G₂ ⎮⎝ 10 10 ⎠
⎮ G₂ ⋅d ⋅ℯ ⋅⎮ d(G₁)
⎮ ⎮ Γ(a)
⎮ ⌡
⎮ 0
⎮ ─
d(G₂)
⎮ Γ(c)
⌡
0
So one could reduce your question into a question like, does anyone
have any thoughts on how SymPy could solve this integral?
On Tue, Apr 1, 2014 at 6:26 AM, John Griffiths
j.davidgriffi...@gmail.com wrote:
Does anyone have any thoughts on how to solve this problem:
When I try to take a weighted mixture of inverse gamma distributions
using sympy.stats I get the following error
%matplotlib inlinefrom matplotlib import pyplot as pltfrom sympy.stats
import GammaInverse, densityimport numpy as np
f1 = 0.7; f2 = 1-f1
G1 = GammaInverse(G1, 5, 120/(5.5*2.5E-7))
G2 = GammaInverse(G2, 4, 120/(5.5*1.5E-7))
G3 = f1*G1 + f2*G2
D1 = density(G1);
D2 = density(G2);
D3 = density(G3);
v1 = [D1(i).evalf() for i in u]
v2 = [D2(i).evalf() for i in u]
v3 = [D3(i).evalf() for i in u]
...which errors at D3 = density(G3). The error includes
PolynomialDivisionFailed: couldn't reduce degree in a polynomial
division algorithm when dividing
[231761.370742578/(0.0011381138741823*G2**2 -
0.007587425827882*G2*_z + 0.0126457097131367*_z**2), 0.0]
by [263.770831541635/263.770831541635, 0.0].
This can happen when it's not possible to detect zero in the coefficient
domain. The domain of computation is RR(G2,_t0,_z). Zero detection is
guaranteed in this
coefficient domain. This may indicate a bug in SymPy or the domain is
user definedand doesn't implement zero detection properly.
(also get this when I take mixture of inverse Gamma with Normal and
Uniform distributions)
Should this be possible?
Cheers.
(p.s. apologies for redundancy with recent SO post)
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion
Re: [sympy] StackOverflow
I did this and was pleasantly surprised. I found a couple of good questions about modules that I work on. It's nice hearing how people use SymPy and provided me with ideas for future development (BTW, we should support solve for matrix expressions apparently). In short, it's good to get input from users. SO seems to be exactly that. Also, if you're into this sort of thing, it's really easy to get some serious SO karma. On Fri, Apr 4, 2014 at 4:45 PM, Aaron Meurer asmeu...@gmail.com wrote: In case people missed it in the other thread, I highly recommend people to help answer SymPy questions on StackOverflow. You can go to http://stackexchange.com/filters/ and set up a filter for the SymPy tag, and it will email you new questions. Lately there are new questions almost every single day, so it would definitely help if others were answering there as well. The questions on stackoverflow tend to be high quality and often have rather interesting use-cases (there are doozies, of course, but the worst questions are closed automatically). Also, don't forget to upvote good questions. This gives the question higher visibility on StackOverflow, which in turn, gives SymPy higher visibility. Aaron Meurer -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J2%2Bc-Hiq_zmF7COe9tpNYzzRhkJneUKuMNQWveRDutAQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6J2%2Bc-Hiq_zmF7COe9tpNYzzRhkJneUKuMNQWveRDutAQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GvCJM7OC5_-%3DcoDBocsJcZejH%2B51JWArLRHXS1fR9SCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
But again, the codebase is small. You're going to have a tough time convincing me to change back to using MRO over issubclass. You're also going to have a tough time convincing me to work to switch to runtime errors rather than import time errors. However it should be fairly easy for a decently skilled developer to implement these ideas, test them, and demonstrate that speed is not sacrificed and that important use cases are better handled using MRO and runtime errors. I'm not yet convinced but I'm not set against these ideas. I think that the next logical step is for someone who isn't me to do something concrete. This will also force someone else to go through and validate or raise issues on the codebase which is needed anyway (no project exists before two pairs of eyes has seen it.) Given that SymPy probably shouldn't accept any ambiguities I think that many of the issues here, while important, should not block progress. Something I am happy to do is to break out the ambiguity response code to a keyword argument. This is a fairly arbitrary choice and so it would be good to provide hooks. In this way it should be easy for SymPy to raise errors instead of warnings when ambiguities are detected. On Thu, Apr 3, 2014 at 7:36 AM, Matthew Rocklin mrock...@gmail.com wrote: Why was the MRO-using code so involved? No particular recollection on this. It could also be that it was just done before I understood the problem as well. I'd have thought that whatever order you're using, having a less-than comparison should be enough to code multidispatch. Does Python's MRO implementation not offer a less-than comparison? The less than comparison that I use is issubclass (actually less than or equal to). To me this seems like a more natural way to ask less than relations between types than MRO. On Thu, Apr 3, 2014 at 12:54 AM, Joachim Durchholz j...@durchholz.orgwrote: Am 02.04.2014 23:02, schrieb Matthew Rocklin: The first incarnation of multipledispatch used mro. It worked. The code to detect ambiguities and select between multiple implementations in the multiple input case was fairly involved. I'm pretty happy with the abstractions behind the current setup. As always though pull requests welcome. The fact that we don't support multiple inheritance well *is* a failing and a potential source of hair pulling down the line. MRO itself is a potential source of hair pulling down the line. (I'm not aware of any programming language that cleanly solves diamond inheritance.) The question is whether the trade-offs involved in the MRO algorithm match the purpose of multiple dispatch. I *think* the issues are orthogonal and MRO should be used, but I'm not 100% sure. Why was the MRO-using code so involved? I'd have thought that whatever order you're using, having a less-than comparison should be enough to code multidispatch. Does Python's MRO implementation not offer a less-than comparison? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/533D13C9.60207%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GWY1TGxgAf%2BAMfy2uoA%2BC1vpZj6d6OiZToSsFCxwm7HA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
I add an on_ambiguity callback in https://github.com/mrocklin/multipledispatch/pull/12 On Thu, Apr 3, 2014 at 7:53 AM, Matthew Rocklin mrock...@gmail.com wrote: But again, the codebase is small. You're going to have a tough time convincing me to change back to using MRO over issubclass. You're also going to have a tough time convincing me to work to switch to runtime errors rather than import time errors. However it should be fairly easy for a decently skilled developer to implement these ideas, test them, and demonstrate that speed is not sacrificed and that important use cases are better handled using MRO and runtime errors. I'm not yet convinced but I'm not set against these ideas. I think that the next logical step is for someone who isn't me to do something concrete. This will also force someone else to go through and validate or raise issues on the codebase which is needed anyway (no project exists before two pairs of eyes has seen it.) Given that SymPy probably shouldn't accept any ambiguities I think that many of the issues here, while important, should not block progress. Something I am happy to do is to break out the ambiguity response code to a keyword argument. This is a fairly arbitrary choice and so it would be good to provide hooks. In this way it should be easy for SymPy to raise errors instead of warnings when ambiguities are detected. On Thu, Apr 3, 2014 at 7:36 AM, Matthew Rocklin mrock...@gmail.comwrote: Why was the MRO-using code so involved? No particular recollection on this. It could also be that it was just done before I understood the problem as well. I'd have thought that whatever order you're using, having a less-than comparison should be enough to code multidispatch. Does Python's MRO implementation not offer a less-than comparison? The less than comparison that I use is issubclass (actually less than or equal to). To me this seems like a more natural way to ask less than relations between types than MRO. On Thu, Apr 3, 2014 at 12:54 AM, Joachim Durchholz j...@durchholz.orgwrote: Am 02.04.2014 23:02, schrieb Matthew Rocklin: The first incarnation of multipledispatch used mro. It worked. The code to detect ambiguities and select between multiple implementations in the multiple input case was fairly involved. I'm pretty happy with the abstractions behind the current setup. As always though pull requests welcome. The fact that we don't support multiple inheritance well *is* a failing and a potential source of hair pulling down the line. MRO itself is a potential source of hair pulling down the line. (I'm not aware of any programming language that cleanly solves diamond inheritance.) The question is whether the trade-offs involved in the MRO algorithm match the purpose of multiple dispatch. I *think* the issues are orthogonal and MRO should be used, but I'm not 100% sure. Why was the MRO-using code so involved? I'd have thought that whatever order you're using, having a less-than comparison should be enough to code multidispatch. Does Python's MRO implementation not offer a less-than comparison? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/533D13C9.60207%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-G5XYgYYqXWJ7mTh5n%2BO%3Dwd-hZ9Ds-uqAtSB0UxgwJPmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
What are your plans for multiple dispatch as a project? In terms of development I consider it mostly complete now. Plans for the future are mostly performance tweaks and support for Python3 type annotations (Jeremiah Lowin has done some good work on this) Why can't this just be included in SymPy? It could be but it would be a fork and so might cause fragmentation Do any other projects use multipledispatch, to your knowledge? I've used it in LogPy, my personal logic programming system. It's a complex enough project to generate issues. SymPy would be the first major project with actual users though. How stable is the API? Will we need to worry about compatibility breaks no version mismatches? I think that the API is pretty solid now but the project has really only had input from one developer. I encourage others to take a look at the design docs and make suggestions sooner rather than later http://multiple-dispatch.readthedocs.org/en/latest/design.html Ondrej raised the API stability question on the issue. I'll include my answer to that below Yup, that's a valid concern. On the flip side once multipledispatch has users it's much harder for me to experiment and change things. However, in this particular case there are a couple of things we can do. 1. Multipledispatch supports a few interfaces, one of which is the interface used by singledispatch in Python 3.4 functools. It's safe to say that this interface is pretty stable 2. Because I happen to develop both projects I can probably manage any changes simultaneously in the two codebases for the first few months Finally, multipledispatch has a very small scope. I consider it to be fairly complete now. I mostly expect only performance tweaks and some Python 3 sugar in the future. https://github.com/certik -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-E%2Bai_gLrnC9AMOor44%3Dp11SGiamcrzniaQV0M_oeCSPQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
It would probably be a good idea to get some good review done on multipledispatch though before SymPy starts to rely on it. I also strongly encourage this. Come on over to github.com/mrocklin/multipledispatch folks! Free beer! On Tue, Apr 1, 2014 at 9:41 PM, Brian Granger elliso...@gmail.com 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. It would probably be a good idea to get some good review done on multipledispatch though before SymPy starts to rely on it. On Tue, Apr 1, 2014 at 8:09 PM, Aaron Meurer asmeu...@gmail.com wrote: I think some questions should be answered first. I think we're all convinced of the technical merits, so I won't touch on those. What are your plans for multiple dispatch as a project? Why can't this just be included in SymPy? Do any other projects use multipledispatch, to your knowledge? How stable is the API? Will we need to worry about compatibility breaks no version mismatches? Aaron Meurer On Apr 1, 2014, at 9:10 PM, Matthew Rocklin mrock...@gmail.com wrote: Hi Everyone, i'd like to add the multipledispatch project as an external dependency to SymPy. As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . There are good reasons for and against external dependencies (I recommend checking out the header of the mentioned issue). I'm now specifically proposing that we depend on multipledispatch which might have other more specific benefits and drawbacks. Even if someone is for dependencies they might not be for this particular dependency. Any thoughts? Now would be a good time to voice concern. One example use of multipledispatch in SymPy is at #2979 . Best, -Matt -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Gi8uGcXF6i73tGFp71%2B02mfJW2d42MUvADkRvCsZHRRw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/-6231458978799167094%40unknownmsgid . For more options, visit https://groups.google.com/d/optout. -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAH4pYpScS99k9X0j6B2GHZW-WM%3DoUquwcp71dkBiX8w9DE3ZEg%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GDhFig73vpMwscmn_jQtbbB%2BNmMCESJdpRY5DdW_BZDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Add multiple dispatch as external dependency
By the way, what about using the test cases to tag the types of all of SymPy's methods by the @dispatch decorator? Beware that multiply dispatched functions *do* incur a microsecond of overhead. This does not come for free. In [1]: from multipledispatch import dispatch In [2]: def f(x): ...: pass ...: In [3]: @dispatch(int) ...: def g(x): ...: pass ...: In [4]: timeit f(1) 1000 loops, best of 3: 83.5 ns per loop In [5]: timeit g(1) 100 loops, best of 3: 1.04 µs per loop This is roughly on the order of creating a Basic In [6]: from sympy import Basic In [7]: timeit Basic() 100 loops, best of 3: 589 ns per loop On Wed, Apr 2, 2014 at 12:37 AM, F. B. franz.bona...@gmail.com wrote: 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 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/32d9fa46-eb9f-494e-bc04-dbaca317f2ad%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/32d9fa46-eb9f-494e-bc04-dbaca317f2ad%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GjtoE5x2od9V_mOmZbzOorPxN9X23s1XmS9AePvU7cSw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
1) On multidispatch itself: You can have either modularity or freeness from surprises (this has been discussed before - essentially, if you have modularity, adding a module with new MD definitions can change dispatch decisions for related combinations of types). This isn't a problem inside SymPy where we do not expect average users to develop subclasses of existing, multi-dispatching SymPy object classes. It might become a problem if multi-dispatch is made an independent module. Multipledispatch supports namespaces. If someone wants to extend the sympy namespace they need to do from sympy.dispatch import dispatch @dispatch(MyClass) def foo(x): ... So in general conflicts can happen but they're unlikely to happen by accident. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EqZKpCPdVS9HoFy9iao7n%3DBUM0YZ40DeEH-%3DdU8j_mZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
It is possible to do either of these things, I'm against the first though. Multiple dispatch is not a SymPy project. It's as usable by numpy or IPython as by SymPy. I'm happy to grant commit rights to anyone who actively develops the project. Ondrej has been futzing with it recently. On Wed, Apr 2, 2014 at 5:02 AM, Jason Moore moorepa...@gmail.com wrote: Is it possible to move the main repository for mutlipledispatch under the sympy github org and grant the core sympy devs commit rights? Jason moorepants.info +01 530-601-9791 On Wed, Apr 2, 2014 at 4:22 AM, Joachim Durchholz j...@durchholz.orgwrote: Am 02.04.2014 04:10, schrieb Matthew Rocklin: As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . There are good reasons for and against external dependencies (I recommend checking out the header of the mentioned issue). I'm now specifically proposing that we depend on multipledispatch which might have other more specific benefits and drawbacks. Even if someone is for dependencies they might not be for this particular dependency. 1) On multidispatch itself: You can have either modularity or freeness from surprises (this has been discussed before - essentially, if you have modularity, adding a module with new MD definitions can change dispatch decisions for related combinations of types). This isn't a problem inside SymPy where we do not expect average users to develop subclasses of existing, multi-dispatching SymPy object classes. It might become a problem if multi-dispatch is made an independent module. 2) On external dependencies: My recommendation is that an external dependency is okay if and only if those parts of the API that we use are stable. That means we need to evaluate how the project's culture handles breaking API changes. Some minor API changes might be tolerated, or if the project goes to great pains to make the current API detectable to SymPy so it can issue the right calls. For MD, I think we should base any decisions on the question what will happen if the project is abandoned (project maintainer lose interest, are hit by a bus, whatever). I'm leaning towards a model that SymPy can use that as an external dependency, but be prepared to fork it for its own use as soon as the MD project goes in a direction that's unsuitable for SymPy. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/533BC8B9.1080002%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AjF6snYpEx_Kc-JPG%2B_Jpan4j-kjCFuOvEJLf%3DQCUkkrg%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAP7f1AjF6snYpEx_Kc-JPG%2B_Jpan4j-kjCFuOvEJLf%3DQCUkkrg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-G%3DDHXZZr9wnvL3qLQhG6BgBmKRxybC4OwpFiQPnpaJUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
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 does dispatch at compile time, we do it at runtime. As implemented now this requires a dictionary lookup. I can imagine some preformance improvements here, for example we could store the last called method in a field on the assumption that people often call the same function many times repeatedly in a for loop. This is the sort of thing that could use an extra pair of eyes. In general though there will be an overhead, I don't think that this overhead is super-significant relevant to many of the operations that we'll dispatch. For example this relatively simple SymPy operation is 7000 times slower than a multipledispatch lookup. In [22]: timeit simplify(x + x + y) 100 loops, best of 3: 7.23 ms per loop -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FnMZX0sjdhQbbMSevWU%3DtJ_COKk5HdT-b5s1Oo-4jHcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
In general I'm happy to do so. I'd like to wait until people actually starts to gain a following/developers though. On Wed, Apr 2, 2014 at 8:15 AM, Ondřej Čertík ondrej.cer...@gmail.comwrote: On Wed, Apr 2, 2014 at 9:09 AM, Matthew Rocklin mrock...@gmail.com wrote: It is possible to do either of these things, I'm against the first though. Multiple dispatch is not a SymPy project. It's as usable by numpy or IPython as by SymPy. I'm happy to grant commit rights to anyone who actively develops the project. Ondrej has been futzing with it recently. One thing that sucks about github is that when you have the project under your name, when you push in a development branch, everybody who clones it will see it. Maybe you can create a new organization for it. I don't know. Ondrej -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVBEH9WsnY7jOLDE1DYGnMcNSGVG4gfgpFyHnMrxt88v5w%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Edp4qR-7DyyYqpwF%2BekHwEs7zcnMRNCs3DoXm7T8DhNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
There is a fair amount of logic in the call to ambiguities. Ordering also does a topological sort. Those are algorithmic but are both done at import time. One optimization would be to have an even faster cache of size one stored in a field on the dispatcher. This would avoid a dictionary lookup in the presumably common case of repeating the same function over lots of data. But really someone should profile this stuff line by line. I've done most of the optimization that seemed easy to me. I suspect that others have other ideas. On Wed, Apr 2, 2014 at 8:39 AM, Ondřej Čertík ondrej.cer...@gmail.comwrote: On Wed, Apr 2, 2014 at 9:18 AM, Matthew Rocklin mrock...@gmail.com 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 does dispatch at compile time, we do it at runtime. As implemented now this requires a dictionary lookup. I can imagine some preformance improvements here, for example we could store the last called method in a field on the assumption that people often call the same function many times repeatedly in a for loop. This is the sort of thing that could use an extra pair of eyes. In general though there will be an overhead, I don't think that this overhead is super-significant relevant to many of the operations that we'll dispatch. For example this relatively simple SymPy operation is 7000 times slower than a multipledispatch lookup. In [22]: timeit simplify(x + x + y) 100 loops, best of 3: 7.23 ms per loop Right. So the whole work is done here: https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/dispatcher.py#L77 def __call__(self, *args, **kwargs): types = tuple([type(arg) for arg in args]) try: func = self._cache[types] except KeyError: func = self.resolve(types) self._cache[types] = func return func(*args, **kwargs) Correct? This seems optimal to me, once it gets cached. We can hardly to better in Python. The resolve() function looks quite optimal to me as well: def resolve(self, types): if types in self.funcs: return self.funcs[types] n = len(types) for signature in self.ordering: if len(signature) == n and all(map(issubclass, types, signature)): result = self.funcs[signature] return result raise NotImplementedError() The only thing I can think of is that you are doing O(n) loop over self.ordering. This list can become big, right? Once it is resolved once, it is cached in __call__(), so it probably is not a big deal. Since you need to check subclasses, I think you have to loop over everything, unless one can somehow prepare some stuff ahead of time. The only slow part happens during the registration (i.e. import time), which happens in the add() method: def add(self, signature, func): self.funcs[signature] = func self.ordering = ordering(self.funcs) amb = ambiguities(self.funcs) if amb: warn(warning_text(self.name, amb), AmbiguityWarning) self._cache.clear() If it is ambiguous, shouldn't it possibly raise an exception? I think this is the meat of the algorithm, everything else is just bells and whistles? Ondrej -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVAcWAJ02iQwnaLA_VVzB9M%3DafmvGqOOr3A1nL50yMMSMw%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GQBM6PCbOtX1G9n94_nm745Sd48oKTB_ytjnVqMYHdhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
By cache of size one I mean store the last type/function pair as a tuple in a field directly on the dispatcher, not in a dictionary. The reasoning is that perhaps a field lookup is faster than inspecting a dictionary. On Wed, Apr 2, 2014 at 8:47 AM, Ondřej Čertík ondrej.cer...@gmail.comwrote: On Wed, Apr 2, 2014 at 9:43 AM, Matthew Rocklin mrock...@gmail.com wrote: There is a fair amount of logic in the call to ambiguities. Ordering also does a topological sort. Those are algorithmic but are both done at import time. One optimization would be to have an even faster cache of size one stored in a field on the dispatcher. This would avoid a dictionary lookup in the presumably common case of repeating the same function over lots of data. def __call__(self, *args, **kwargs): types = tuple([type(arg) for arg in args]) try: func = self._cache[types] except KeyError: func = self.resolve(types) self._cache[types] = func return func(*args, **kwargs) Isn't self._cache already stored in a dispatcher? I don't understand what you mean by even faster cache of size one stored in a field on the dispatcher. But really someone should profile this stuff line by line. I've done most of the optimization that seemed easy to me. I suspect that others have other ideas. Of course, it would have to be benchmarked. Ondrej On Wed, Apr 2, 2014 at 8:39 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Wed, Apr 2, 2014 at 9:18 AM, Matthew Rocklin mrock...@gmail.com 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 does dispatch at compile time, we do it at runtime. As implemented now this requires a dictionary lookup. I can imagine some preformance improvements here, for example we could store the last called method in a field on the assumption that people often call the same function many times repeatedly in a for loop. This is the sort of thing that could use an extra pair of eyes. In general though there will be an overhead, I don't think that this overhead is super-significant relevant to many of the operations that we'll dispatch. For example this relatively simple SymPy operation is 7000 times slower than a multipledispatch lookup. In [22]: timeit simplify(x + x + y) 100 loops, best of 3: 7.23 ms per loop Right. So the whole work is done here: https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/dispatcher.py#L77 def __call__(self, *args, **kwargs): types = tuple([type(arg) for arg in args]) try: func = self._cache[types] except KeyError: func = self.resolve(types) self._cache[types] = func return func(*args, **kwargs) Correct? This seems optimal to me, once it gets cached. We can hardly to better in Python. The resolve() function looks quite optimal to me as well: def resolve(self, types): if types in self.funcs: return self.funcs[types] n = len(types) for signature in self.ordering: if len(signature) == n and all(map(issubclass, types, signature)): result = self.funcs[signature] return result raise NotImplementedError() The only thing I can think of is that you are doing O(n) loop over self.ordering. This list can become big, right? Once it is resolved once, it is cached in __call__(), so it probably is not a big deal. Since you need to check subclasses, I think you have to loop over everything, unless one can somehow prepare some stuff ahead of time. The only slow part happens during the registration (i.e. import time), which happens in the add() method: def add(self, signature, func): self.funcs[signature] = func self.ordering = ordering(self.funcs) amb = ambiguities(self.funcs) if amb: warn(warning_text(self.name, amb), AmbiguityWarning) self._cache.clear() If it is ambiguous, shouldn't it possibly raise an exception? I think this is the meat of the algorithm, everything else is just bells and whistles? Ondrej -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVAcWAJ02iQwnaLA_VVzB9M%3DafmvGqOOr3A1nL50yMMSMw%40mail.gmail.com . For more options, visit https
Re: [sympy] Re: Tensor refactory
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] ? On Wed, Apr 2, 2014 at 9:41 AM, F. B. franz.bona...@gmail.com wrote: 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, because the object containing the tensor indices tries to access internal properties of the indices, which Wild does not possess, thus raising an error. I did a grep of the unify module, and it looks like .match and .replace are not used, so this should not be an urgent issue. I don't know whether it's worth to address this issue, but I envisioned an attempt to leave the current procedural programming style to approach a more functional style. There should also be a refactory in order to allow operators such as the partial derivative to act on tensor expressions, possible ideas: - create a DummyTensorIndex type, similar to TensorIndex, dummy indices would be stored into the arg-tree as instances of DummyTensorIndex instead of TensorIndex. - it makes no sense anymore to consider the index order until the operators are unevaluated, e.g. PartialDerivative(A(i)*B(j, k)*A(-k) + C(-k, j, i)*A(k), A(h)) has a (i, j, -h) index signature, but it makes no sense to consider the index order. Yet one could wish to multiply the unevaluated operator by a tensor and perform a contraction, e.g. D(-h)*PartialDerivative(A(i)*B(j, k)*A(-k) + C(-k, j, i)*A(k), A(h)) This should be a TensMul object, but it cannot possess positional info. Solving this issue would also pave the way to unexpanded tensor expressions. - Should DummyTensorIndex and TensorIndex have a wild=True/False parameter to solve the issue of matching contracted indices? In any case, introducing operators requires some refactory of the current index algorithms. Fortunately there is now a separate TIDS class used to stored all such algorithms. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/eb0fdec5-18e6-47c3-b631-e3a791ab2f6e%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/eb0fdec5-18e6-47c3-b631-e3a791ab2f6e%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GLsX9W_brk-W3Toh0notH6CswJAmmyv8X5otdoE0FcfQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
Sorry Joachim, It sounds like you're talking about name/signature pair conflicts, which is also what I think I was talking about. It's true that foreign code can change behavior of local code which as you correctly point out can lead to issues. It can also lead to really solid code organization if done well. Polymorphism in dynamic languages generally has this issue. But perhaps you could point to your previous message? It's not that you're talking to deaf ears, it's that you're talking to ears that have too many messages coming in and are connected to a head with a relatively short memory. On Wed, Apr 2, 2014 at 10:51 AM, Joachim Durchholz j...@durchholz.org wrote: Am 02.04.2014 17:05, schrieb Matthew Rocklin: 1) On multidispatch itself: You can have either modularity or freeness from surprises (this has been discussed before - essentially, if you have modularity, adding a module with new MD definitions can change dispatch decisions for related combinations of types). This isn't a problem inside SymPy where we do not expect average users to develop subclasses of existing, multi-dispatching SymPy object classes. It might become a problem if multi-dispatch is made an independent module. Multipledispatch supports namespaces. I'm not talking about name conflicts. I'm talking about this: adding a module with new MD definitions can change dispatch decisions for related combinations of types). I explained this months ago. Seems I was talking to deaf ears. Ah well. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/533C4E2F.2050804%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FXhKSaTMx9_2JU3tH8GchdDx4jLqdmNp7kspAA49EevQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Tensor refactory
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. Generally speaking though unification variables do need match consistently within a term. (a, a) does not match to (1, 2). Perhaps we could consider all tensor indices on one side to be wild? On Wed, Apr 2, 2014 at 12:50 PM, F. B. franz.bona...@gmail.com wrote: 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, that was a particular case because A(i, -i) is A(j, -j), and this is also equivalent to a scalar (j and -j are summed over). A(i, j) instead is equivalent to a matrix. If A has associated components data, A(i, j).data is the N x N ndarray, and A(i, -i) is the trace. Consider A(i, -i, j) and A(j, -i, i), these are not equal and should not unify, not even if both i and j are wild. Of course a tensor constructor would raise an exception if an index is repeated more than twice. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d7b6882e-d224-48b9-8261-bd5ff81cb84c%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/d7b6882e-d224-48b9-8261-bd5ff81cb84c%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HT3JZoytpCALYsB9p91FdjwYfzQ5HF8seM2KgY%3D2Pf-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. http://multiple-dispatch.readthedocs.org/en/latest/resolution.html#multiple-inputs If you're interested in the code that does this please see https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py Pull requests welcome. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
The multipledispatch project does not think hard about multiple inheritance in an intelligent way. It uses issubclass in order to support abstract classes like Iterator and Number. On Wed, Apr 2, 2014 at 1:35 PM, Aaron Meurer asmeu...@gmail.com wrote: Why does multipledispatch use issubclass instead of __mro__? What happens when you dispatch on a diamond inheritance? Aaron Meurer On Wed, Apr 2, 2014 at 3:32 PM, Matthew Rocklin mrock...@gmail.comwrote: The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. http://multiple-dispatch.readthedocs.org/en/latest/resolution.html#multiple-inputs If you're interested in the code that does this please see https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py Pull requests welcome. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
Sorry, I used pseudo-random loosely. We currently use hash by default although this could easily be changed. See the tie_breaker keyword argument to the edge function in conflict.py. https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py On Wed, Apr 2, 2014 at 1:56 PM, Joachim Durchholz j...@durchholz.org wrote: Am 02.04.2014 22:32, schrieb Matthew Rocklin: The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). Ah, that's good. If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. Hm. I'm not sure whether that's a good or a bad idea. It should be deterministic and depend only on parameter types. Or whatever needs to be done to make unit tests choose the same dispatch decisions as production code. So... a hash on parameter types would probably be okay, a PRNG that's seeded once definitely is not. But it's a corner case. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/ msgid/sympy/533C7975.5020409%40durchholz.org. For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-G%2BpUOCgProjgj1Am4LB2JXrb4mzNYaP%2BjiOvzX0wNa3g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
The first incarnation of multipledispatch used mro. It worked. The code to detect ambiguities and select between multiple implementations in the multiple input case was fairly involved. I'm pretty happy with the abstractions behind the current setup. As always though pull requests welcome. The fact that we don't support multiple inheritance well *is* a failing and a potential source of hair pulling down the line. On Wed, Apr 2, 2014 at 1:59 PM, Aaron Meurer asmeu...@gmail.com wrote: Also if you use __mro__, wouldn't you not have to build up some topological graph? Just pick the dispatched class that comes last in the mro. Aaron Meurer On Wed, Apr 2, 2014 at 3:58 PM, Matthew Rocklin mrock...@gmail.comwrote: The multipledispatch project does not think hard about multiple inheritance in an intelligent way. It uses issubclass in order to support abstract classes like Iterator and Number. On Wed, Apr 2, 2014 at 1:35 PM, Aaron Meurer asmeu...@gmail.com wrote: Why does multipledispatch use issubclass instead of __mro__? What happens when you dispatch on a diamond inheritance? Aaron Meurer On Wed, Apr 2, 2014 at 3:32 PM, Matthew Rocklin mrock...@gmail.comwrote: The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. http://multiple-dispatch.readthedocs.org/en/latest/resolution.html#multiple-inputs If you're interested in the code that does this please see https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py Pull requests welcome. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LQSuncEudUNVEp5L-55d_3y%2By7GA5fw7K2gHOdoZ9-GQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6LQSuncEudUNVEp5L-55d_3y%2By7GA5fw7K2gHOdoZ9-GQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Gkfd9
Re: [sympy] Add multiple dispatch as external dependency
Not all of the ties result from ambiguities. For example the signatures (int,) and (float,) tie. Which should come first in the toposort? Regarding API breaks I recommend that SymPy not inject any ambiguities. These can be avoided just by adding extra function definitions. E.g. @dispatch(object, float) def f(x, y): return 1 @dispatch(float, object) def f(x, y): return 2 f(1.0, 2.0) # oh no! which do we choose? In this case multipledispatch gives you a warning when you register the second implementation multipledispatch/core.py:52: AmbiguityWarning: Ambiguities exist in dispatched function f The following signatures may result in ambiguous behavior: [float, object], [object, float] Consider making the following additions: @dispatch(float, float) def f(...) My answer to this problem is that we just follow the instructions and define functions to cover all ambiguities. On Wed, Apr 2, 2014 at 2:04 PM, Aaron Meurer asmeu...@gmail.com wrote: And going back to my original comments, wouldn't changing tie breaking or mro schemes down the line be API breaks? Aaron Meurer On Wed, Apr 2, 2014 at 4:02 PM, Matthew Rocklin mrock...@gmail.comwrote: The first incarnation of multipledispatch used mro. It worked. The code to detect ambiguities and select between multiple implementations in the multiple input case was fairly involved. I'm pretty happy with the abstractions behind the current setup. As always though pull requests welcome. The fact that we don't support multiple inheritance well *is* a failing and a potential source of hair pulling down the line. On Wed, Apr 2, 2014 at 1:59 PM, Aaron Meurer asmeu...@gmail.com wrote: Also if you use __mro__, wouldn't you not have to build up some topological graph? Just pick the dispatched class that comes last in the mro. Aaron Meurer On Wed, Apr 2, 2014 at 3:58 PM, Matthew Rocklin mrock...@gmail.comwrote: The multipledispatch project does not think hard about multiple inheritance in an intelligent way. It uses issubclass in order to support abstract classes like Iterator and Number. On Wed, Apr 2, 2014 at 1:35 PM, Aaron Meurer asmeu...@gmail.comwrote: Why does multipledispatch use issubclass instead of __mro__? What happens when you dispatch on a diamond inheritance? Aaron Meurer On Wed, Apr 2, 2014 at 3:32 PM, Matthew Rocklin mrock...@gmail.comwrote: The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. http://multiple-dispatch.readthedocs.org/en/latest/resolution.html#multiple-inputs If you're interested in the code that does this please see https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py Pull requests welcome. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.com?utm_medium=emailutm_source=footer
Re: [sympy] Add multiple dispatch as external dependency
Not all of the ties result from ambiguities. For example the signatures (int,) and (float,) tie. Which should come first in the toposort? For what input? How MD operates now is that it forms a graph of signatures with an edge between two signatures if one is more specific than the other. It then topologically sorts this graph to form a linear ordering. When inputs come in we get their types and then compare those types against each of the type signatures in the linear ordering from most to least specific (by the topological sort). Once we find a match we return the function that was registered with the matching signature. In this way we get to use issubclass and are also assured that we aren't missing a more specific signature. So, in the float/int case our graph is just two disconnected nodes and our ordering might look like [(int,), (float,)] When an input comes in, like 1.0, we get it's types, (float,), and then ask issubclass(float, int), get no, and move on to ask if issubclass(float, float). This works so we return the function associated with (float,). (Although actually we first just check in a dict to see if we have the type signature exactly, which we do in this case, so we return in constant time) I would definitely raise an exception here. You can maybe play with ways for people to tell the dispatcher how they want it to break ties, but the default implementation shouldn't take sides. I can see the reasoning here but slightly disagree. Often both implementations are perfectly valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. Couldn't you resolve the ambiguity by adding additional dispatch against (float, float)? Yes, this is what is suggested automatically by MD. Perhaps I don't understand your comment. I don't think it's right to do this check at registry time. I'm not sure that I understand this either. When would you do the check? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EXLpUGxJXK5Zm8PT%2B27OC6O42pCYP2vvXWVPv_qM5E4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
If it is possible to catch warnings then we could catch an MD warning and raise an error in SymPy if we wanted. My PRs introducing MD into SymPy include a tiny sympy.dispatch module rather than using MD directly. There is little stopping us from tailoring some of the behavior to fit SymPy's priorities. On Wed, Apr 2, 2014 at 3:33 PM, Matthew Rocklin mrock...@gmail.com wrote: Not all of the ties result from ambiguities. For example the signatures (int,) and (float,) tie. Which should come first in the toposort? For what input? How MD operates now is that it forms a graph of signatures with an edge between two signatures if one is more specific than the other. It then topologically sorts this graph to form a linear ordering. When inputs come in we get their types and then compare those types against each of the type signatures in the linear ordering from most to least specific (by the topological sort). Once we find a match we return the function that was registered with the matching signature. In this way we get to use issubclass and are also assured that we aren't missing a more specific signature. So, in the float/int case our graph is just two disconnected nodes and our ordering might look like [(int,), (float,)] When an input comes in, like 1.0, we get it's types, (float,), and then ask issubclass(float, int), get no, and move on to ask if issubclass(float, float). This works so we return the function associated with (float,). (Although actually we first just check in a dict to see if we have the type signature exactly, which we do in this case, so we return in constant time) I would definitely raise an exception here. You can maybe play with ways for people to tell the dispatcher how they want it to break ties, but the default implementation shouldn't take sides. I can see the reasoning here but slightly disagree. Often both implementations are perfectly valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. Couldn't you resolve the ambiguity by adding additional dispatch against (float, float)? Yes, this is what is suggested automatically by MD. Perhaps I don't understand your comment. I don't think it's right to do this check at registry time. I'm not sure that I understand this either. When would you do the check? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Add multiple dispatch as external dependency
Ah, must have missed it, fortunately Aaron bright up the same point. My response: I can see the reasoning here but slightly disagree. Both implementations are presumably valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. Perhaps it would make sense to reach out to the Julia folks and ask about their experiences. And then I suggest that sympy could catch warnings and throw errors. In my PRs I use a small module sympy. dispatch rather than the raw dispatch in multipledispatch On Apr 2, 2014 4:34 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: I already asked this, but didn't get a reply: I really think it should raise an exception on ambiguity by default. You can allow the user to explicitly override this behavior if you know what you are doing. Sent from my mobile phone. On Apr 2, 2014 4:42 PM, Matthew Rocklin mrock...@gmail.com wrote: If it is possible to catch warnings then we could catch an MD warning and raise an error in SymPy if we wanted. My PRs introducing MD into SymPy include a tiny sympy.dispatch module rather than using MD directly. There is little stopping us from tailoring some of the behavior to fit SymPy's priorities. On Wed, Apr 2, 2014 at 3:33 PM, Matthew Rocklin mrock...@gmail.comwrote: Not all of the ties result from ambiguities. For example the signatures (int,) and (float,) tie. Which should come first in the toposort? For what input? How MD operates now is that it forms a graph of signatures with an edge between two signatures if one is more specific than the other. It then topologically sorts this graph to form a linear ordering. When inputs come in we get their types and then compare those types against each of the type signatures in the linear ordering from most to least specific (by the topological sort). Once we find a match we return the function that was registered with the matching signature. In this way we get to use issubclass and are also assured that we aren't missing a more specific signature. So, in the float/int case our graph is just two disconnected nodes and our ordering might look like [(int,), (float,)] When an input comes in, like 1.0, we get it's types, (float,), and then ask issubclass(float, int), get no, and move on to ask if issubclass(float, float). This works so we return the function associated with (float,). (Although actually we first just check in a dict to see if we have the type signature exactly, which we do in this case, so we return in constant time) I would definitely raise an exception here. You can maybe play with ways for people to tell the dispatcher how they want it to break ties, but the default implementation shouldn't take sides. I can see the reasoning here but slightly disagree. Often both implementations are perfectly valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. Couldn't you resolve the ambiguity by adding additional dispatch against (float, float)? Yes, this is what is suggested automatically by MD. Perhaps I don't understand your comment. I don't think it's right to do this check at registry time. I'm not sure that I understand this either. When would you do the check? -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVATGaBzjoOzw2CiuTjQrC1fkt%2B-M-hkiON8qO35J6uKcg%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CADDwiVATGaBzjoOzw2CiuTjQrC1fkt%2B-M-hkiON8qO35J6uKcg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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
Re: [sympy] Add multiple dispatch as external dependency
My point is, the order comes from the input itself, not from the registry. AKA, you should use MRO. MRO satisfied monotonicity, which I think for multiple dispatch basically says that if you subclass a class, it won't change which function it will dispatch to (see https://www.python.org/download/releases/2.2.3/descrintro). I think that the current system also satisfies this condition. Perhaps this discussion would be more concrete with an example test that multipledispatch fails? I would definitely raise an exception here. You can maybe play with ways for people to tell the dispatcher how they want it to break ties, but the default implementation shouldn't take sides. I can see the reasoning here but slightly disagree. Often both implementations are perfectly valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. I think Julia only has one use-case in mind, which is that a function is going to compute something, dispatched against some algorithm, and return the result. But I think there are other possibilities. I think that Julia and Python target very similar application spaces here. I don't see a distinction. I'll think about some concrete examples, but my gut tells me that there are going to be different ways that people might want to break or not break ties. Multipledispatch should allow that via subclassing the Dispatch class, and the default implementation should not do it. I also reiterate In the face of ambiguity, refuse the temptation to guess. That's a reasonable philosophy. In this case though we actually have two (or more) perfectly valid implementations. Question, what does Python do when ambiguities arise in the multiple inheritance case? I think that it chooses based on the order in which the classes appeared in the class definition. *This *is fairly arbitrary. We still do it though. I understand that you express a slight preference when stating the order but still, it's a pretty weak signal on which to decide things (IMO). Couldn't you resolve the ambiguity by adding additional dispatch against (float, float)? Yes, this is what is suggested automatically by MD. Perhaps I don't understand your comment. The point is, you are warning when the function is registered. If you have @dispatch(float, object) def add(a, b): ... @dispatch(object, float) def add(a, b): ... @dispatch(float, float) def add(a, b): ... it will raise a warning telling you to do something that you have already done. Since there's no way to finalize the dispatcher (nor should there be), it should just do this at run time. You can cache the state of the Dispatch object if performance is a concern. I think that it's valuable to get this information when you write your code. If you get no warnings when you load up your code then you know that there won't be an issue. I also suspect that runtime checking will be costly. I haven't yet actually read the code, only the documentation and what you wrote here, so if I wrote something stupid above, pardon it. Nothing stupid as far as I can see. These are all legitimate concerns. This is a challenging problem though and I don't think that it's possible to satisfy all concerns simultaneously. Also, I do recommend actually reading through the module. It's very short (~300 LOC most of which are comments) and I think that reading it might give you more insight into what happens now. If you walk back a bit in the git history you can come across an old version that did everything at runtime using mro. My personal release notes say that this happened before the 0.2.0 version bump. Here is a question: which of these issues block SymPy's use of multiple dispatch? From what I can see none of these strongly impact the API, particularly not if we enforce a don't let dispatch ambiguities slide policy. I think that the warnings are sufficiently loud to make enforcement of this policy trivial. I also don't think that it's going to be a big deal, but again, this is something to ask the Julia folks. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-GK0Weh6iuXUQ1wTB281B9nE5hTkdP_7FF3%3D1w_6U2vag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] error when taking mixture of inverse gamma distributions
First, thanks for posting the question on stack overflow, I think that we
should use that more. Unfortunately, few of us (maybe only Aaron?)
actually checks SO, again, I think that we should use it more.
Sympy.stats is producing an integral that looks like the following:
In [1]: from sympy.stats import *
In [2]: a, b, c, d, = symbols('a b c d', real=True, positive=True)
In [3]: G1 = GammaInverse(G1, a, b)
In [4]: G2 = GammaInverse(G2, c, d)
In [5]: G3 = S(7)/10*G1 + S(3)/10*G2
In [7]: density(G3, evaluate=False)(x)
Out[7]:
∞
⌠
⎮ ∞
⎮ ⌠
⎮ ⎮ -b
⎮ ⎮ ───
⎮ -d ⎮ -a - 1 a G₁ ⎛7⋅G₁ 3⋅G₂⎞
⎮ ─── ⎮ G₁ ⋅b ⋅ℯ ⋅DiracDelta⎜ + - x⎟
⎮ -c - 1 c G₂ ⎮⎝ 10 10 ⎠
⎮ G₂ ⋅d ⋅ℯ ⋅⎮ d(G₁)
⎮ ⎮ Γ(a)
⎮ ⌡
⎮ 0
⎮ ─
d(G₂)
⎮ Γ(c)
⌡
0
So one could reduce your question into a question like, does anyone have
any thoughts on how SymPy could solve this integral?
On Tue, Apr 1, 2014 at 6:26 AM, John Griffiths
j.davidgriffi...@gmail.comwrote:
Does anyone have any thoughts on how to solve this problem:
When I try to take a weighted mixture of inverse gamma distributions
using sympy.stats I get the following error
%matplotlib inlinefrom matplotlib import pyplot as pltfrom sympy.stats import
GammaInverse, densityimport numpy as np
f1 = 0.7; f2 = 1-f1
G1 = GammaInverse(G1, 5, 120/(5.5*2.5E-7))
G2 = GammaInverse(G2, 4, 120/(5.5*1.5E-7))
G3 = f1*G1 + f2*G2
D1 = density(G1);
D2 = density(G2);
D3 = density(G3);
v1 = [D1(i).evalf() for i in u]
v2 = [D2(i).evalf() for i in u]
v3 = [D3(i).evalf() for i in u]
...which errors at D3 = density(G3). The error includes
PolynomialDivisionFailed: couldn't reduce degree in a polynomial
division algorithm when dividing [231761.370742578/(0.0011381138741823*G2**2 -
0.007587425827882*G2*_z + 0.0126457097131367*_z**2), 0.0]
by [263.770831541635/263.770831541635, 0.0].
This can happen when it's not possible to detect zero in the coefficient
domain. The domain of computation is RR(G2,_t0,_z). Zero detection is
guaranteed in this
coefficient domain. This may indicate a bug in SymPy or the domain is user
definedand doesn't implement zero detection properly.
(also get this when I take mixture of inverse Gamma with Normal and
Uniform distributions)
Should this be possible?
Cheers.
(p.s. apologies for redundancy with recent SO post)
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.comhttps://groups.google.com/d/msgid/sympy/4cb36d1b-6827-4123-8efe-b1462d822e6b%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJ8oX-HEDx4fraBRj4HARPaCEJKXKaTP3zjS_dbeqd3WoeAAWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] assumptions and matrix algebra
This has been added to SymPy and merged.
In [1]: X = MatrixSymbol('X', n, n)
In [2]: with assuming(Q.orthogonal(X)):
...: print refine(X * X.T)
...:
I # identity matrix
On Tue, Mar 18, 2014 at 4:32 PM, Chris ckwid...@gmail.com wrote:
Hi Matt,
awesome, I'll take a look and see how far I get.
Thanks for your help!
Chris
On Monday, March 17, 2014 8:41:21 PM UTC-7, Matthew wrote:
I added a bunch more refine handlers.
Chris, if you wanted to play around with this branch and see if it does
what you need that'd be helpful. Even better, maybe after looking at the
diff in the PR you could add some logic yourself? The pattern of how to do
this should be pretty easy to pick out.
On Mon, Mar 17, 2014 at 7:37 PM, Matthew Rocklin mroc...@gmail.comwrote:
Well, on the simplify/refine side I think we only need to call ask. At
some stage this might be wired back into `is_foo`
I implemented this particular refinement in https://github.com/sympy/
sympy/pull/7296 just to see how it felt.
BTW, refine could totally use a better dispatching system. If only,
ahem, someone had built such a thing
On Mon, Mar 17, 2014 at 6:16 PM, Aaron Meurer asme...@gmail.com wrote:
I'm not clear what the plan should be regarding auto-evaluation and
refine and the new assumptions. I feel that it hasn't been heavily
thought out yet. We have to somehow balance the pain of having to call
all sorts of with assuming() and refine() just to get things to
simplify and the performance issues if they do it automatically (and
also the issues of potentially not wanting it to always happen
automatically).
Aaron Meurer
On Mon, Mar 17, 2014 at 7:12 PM, Matthew Rocklin mroc...@gmail.com
wrote:
Hi Chris,
Thanks for the kind words.
At the moment Matrix Expressions in the main branch do not use
assumptions
while simplifying. IIRC they actually used to but I removed it so
that I
could approach this more cleanly. One lofty reason for this was so
that
this could be used as a model for the rest of sympy when it
eventually jumps
over to the new assumptions system.
If other devs see this e-mail - what are your thoughts on `refine`,
the
simplify API suggested (but rarely used) by new assumptions? Should
we
start using this? Should we roll it into simplify? In general at
what
point should we appeal to new assumptions? At expression creation
time? At
simplify time? At another simplify-like api time (e.g. refine time)?
I
decided not to call upon new assumptions while creating expressions
(e.g.
X.T creates a Transpose(X) even if X is symmetric). I think that my
reasoning at the time was performance.
Chris, in general what you're asking for is easy for us to add. I
would
like to make sure that we add it correctly.
Also, it's been some time since this was all in my head. I may have
said
some untrue things.
Best,
-Matthew
On Mon, Mar 17, 2014 at 4:57 PM, Chris ckwi...@gmail.com wrote:
Hi all,
I stumbled upon the discussion on matrix assumptions and the bit of
history behind this sympy module:
http://scicomp.stackexchange.com/questions/74/symbolic-
software-packages-for-matrix-expressions
First off all, thank you Matt, this is incredibly cool stuff!
Now, I'm trying to do some matrix algebra while encoding knowledge
about
the matrices involved. For instance, say my matrix U is unitary,
i.e. U *
U.T = I. I've looked around in the documentation and source code, but
couldn't figure out, if the new assumption system can be used to
simplify
matrix expressions.
I was trying to exploit this using sympy as follows:
from sympy import Q, symbols, MatrixSymbol, ask, simplify
from sympy.assumptions.assume import global_assumptions
n = symbols('n', integer=True)
U = MatrixSymbol('U', n, n)
global_assumptions.add(Q.unitary(U))
UU = U * U.T
print UU
simpleUU = simplify(UU)
print simpleUU
I was hoping that the second print would output the Identity, but
somehow
this didn't work. Any suggestions, pointers, hints?
Cheers,
Chris
--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/31aaea36-675d-
40b0-8d77-aec8828f6c31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+un...@googlegroups.com.
To post to this group, send email to sy
[sympy] Add multiple dispatch as external dependency
Hi Everyone, i'd like to add the multipledispatchhttp://github.com/mrocklin/multipledispatch/ project as an external dependency to SymPy. As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . There are good reasons for and against external dependencies (I recommend checking out the header of the mentioned issue). I'm now specifically proposing that we depend on multipledispatch which might have other more specific benefits and drawbacks. Even if someone is for dependencies they might not be for this particular dependency. Any thoughts? Now would be a good time to voice concern. One example use of multipledispatch in SymPy is at #2979https://github.com/sympy/sympy/pull/2979 . Best, -Matt -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-Gi8uGcXF6i73tGFp71%2B02mfJW2d42MUvADkRvCsZHRRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SciPy talk
I like that you emphasized the utility for numerics, I think that this is likely to be a selling point for the SciPy crowd. I think that it's correct to inform the reader about what symbolics are but I think that the first couple of sentences (which do this) could be stronger/more direct. Right now they sound conversational. It's not clear to me how to fix this though. Maybe start with something like SymPy is a computer algebra system. It provides easy access to a wealth of automated mathematics that helps programmers to reason about their problem producing more clear and efficient numeric solutions. and then go into what symbolics are? I would cut the top bullet point, e.g. - Why you should care about symbolic mathematics, even if you are only interested in doing numerics. - How symbolic mathematics can help you solve problems more effectively I have a pretty cynical view about people when they're reading text though (perhaps this comes from teaching freshmen :)) As a result sentences that carry more than one idea seem dirty to me. Hope this helps, -Matt On Sat, Mar 29, 2014 at 6:01 PM, Aaron Meurer asmeu...@gmail.com wrote: Here is the detailed abstract I have so far for a talk for SciPy. Any suggestions are welcome. The deadline is April 1 (probably 5 PM central or thereabouts). I roughly based it on the matplotlib talk from last year http://conference.scipy.org/scipy2013/presentation_detail.php?id=211. Symbolic computation deals with manipulating mathematical expression symbolically (as opposed to numerically). For instance, representing sqrt(2) without evaluating it is symbolic: representing 1.41421 is numeric. Most software that deals with mathematical expressions symbolically are called computer algebra systems, or CASs for short. SymPy is a computer algebra system written entirely in Python. In this talk, we will look at - Why you should care about symbolic mathematics. Even if you are only interested in doing numerics, how can symbolic mathematics help you to solve your problems more efficiently and/or effectively? - Some of the design decisions that have guided SymPy, such as why we chose Python to write SymPy, and the importance of being able to use SymPy as a library. - How to solve some basic problems in SymPy. - How to interface SymPy with popular numeric libraries, like NumPy. Additionally, we will look at the most interesting recent developments of SymPy, and will also discuss some of our plans for the future. Finally, we will discuss some of what has made SymPy a success, both as a software product, and as a community. Aaron Meurer -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K3OmDsdApN%3DOEvFrRQ4ohEQ1npVfwgUsyxd-K-TLaLOA%40mail.gmail.comhttps://groups.google.com/d/msgid/sympy/CAKgW%3D6K3OmDsdApN%3DOEvFrRQ4ohEQ1npVfwgUsyxd-K-TLaLOA%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-EKtRvNmb8SnyAxUaV%3D3m3_%3D2kfe%3D%3DKRsPKj13_bUSBOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] SciPy talk
Last minute (this morning) I decided to submit a talk based around some of my more esoteric programming projects, multiple dispatch, pattern matching, strategies. I drew a lot of inspiration from SymPy when I was thinking about these things so if accepted then I'll probably use SymPy heavily for example use cases. Here is the description and abstract. I'll add a disclaimer to this talk that the ideas contained within it are my own and not necessarily adopted by the SymPy community. As I said, this is mostly about some of my more wacky projects. I'll probably call upon uses of multiple dispatch (if we include it), fu trig simplification with @smichr, and my matrix expressions work with pattern matching (not in master). DescriptionGood solutions to hard problems require both domain and algorithmic expertise. Domain experts know what to do and computer scientists know how to do it well. This talk discusses challenges and experiences trying to reconcile these two groups, particularly within SymPy. It proposes concrete approaches including multiple dispatch, pattern matching, and programmatic strategies. Abstract Good solutions to hard problems require both domain and algorithmic expertise. Domain experts know *what* to do and computer scientists know *how* to do it well. Coordination between the algorithmic and domain programmer is challenging to do well and difficult to scale. It is also arguably one of the most relevant blocks to scientific progress today. This talk draws from experience supporting mathematical programmers in the SymPy project. SymPy is a computer algebra system, a complex problem that requires the graph manipulation algorithms of a modern compiler alongside the mathematics of several PhD theses. SymPy draws from a broad developer base with experienced and novice developers alike and so struggles to maintain a cohesive organized codebase. We approach this development problem by separating software engineering into a collection of small functions, written by domain experts, alongside an abstract control system, written by algorithmic programmers. We facilitate this division with techniques taken from other languages and compiler technologies. Notably we motivate the use of a few general purpose libraries for multiple dispatch, pattern matching, and programmatic control. On Mon, Mar 31, 2014 at 9:32 AM, Matthew Rocklin mrock...@gmail.com wrote: I like that you emphasized the utility for numerics, I think that this is likely to be a selling point for the SciPy crowd. I think that it's correct to inform the reader about what symbolics are but I think that the first couple of sentences (which do this) could be stronger/more direct. Right now they sound conversational. It's not clear to me how to fix this though. Maybe start with something like SymPy is a computer algebra system. It provides easy access to a wealth of automated mathematics that helps programmers to reason about their problem producing more clear and efficient numeric solutions. and then go into what symbolics are? I would cut the top bullet point, e.g. - Why you should care about symbolic mathematics, even if you are only interested in doing numerics. - How symbolic mathematics can help you solve problems more effectively I have a pretty cynical view about people when they're reading text though (perhaps this comes from teaching freshmen :)) As a result sentences that carry more than one idea seem dirty to me. Hope this helps, -Matt On Sat, Mar 29, 2014 at 6:01 PM, Aaron Meurer asmeu...@gmail.com wrote: Here is the detailed abstract I have so far for a talk for SciPy. Any suggestions are welcome. The deadline is April 1 (probably 5 PM central or thereabouts). I roughly based it on the matplotlib talk from last year http://conference.scipy.org/scipy2013/presentation_detail.php?id=211. Symbolic computation deals with manipulating mathematical expression symbolically (as opposed to numerically). For instance, representing sqrt(2) without evaluating it is symbolic: representing 1.41421 is numeric. Most software that deals with mathematical expressions symbolically are called computer algebra systems, or CASs for short. SymPy is a computer algebra system written entirely in Python. In this talk, we will look at - Why you should care about symbolic mathematics. Even if you are only interested in doing numerics, how can symbolic mathematics help you to solve your problems more efficiently and/or effectively? - Some of the design decisions that have guided SymPy, such as why we chose Python to write SymPy, and the importance of being able to use SymPy as a library. - How to solve some basic problems in SymPy. - How to interface SymPy with popular numeric libraries, like NumPy. Additionally, we will look at the most interesting recent developments of SymPy, and will also discuss some of our plans for the future. Finally, we will discuss some of what has made SymPy
