Re: [sympy] What is out there for SymPy code generation / optimizing compiler effort?

[Matthew Rocklin]

>
> 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 Rocklin]

>  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  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
>  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  >
> >> 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**2>1, evaluate=False)
> >>> Out[6]:
> >>> (-∞, -1) ∪ (1, ∞)
> >>> ⌠
> >>> ⎮2
> >>> ⎮-(z - μ)
> >>> ⎮──
> >>> ⎮  2
> >>> ⎮   ___ 2⋅σ
> >>> ⎮ ╲╱ 2 ⋅ℯ
> >>> ⎮ ─ dz
> >>> ⎮ ___
> >>> ⎮ 2⋅╲╱ π ⋅σ
> >>> ⌡
> >>>
> >>>
> >>> In [7]: srepr(P(N**2>1, 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

Re: [sympy] Integrate over Union of Interval's

[Matthew Rocklin]

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 
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**2>1, evaluate=False)
> Out[6]:
> (-∞, -1) ∪ (1, ∞)
> ⌠
> ⎮2
> ⎮-(z - μ)
> ⎮──
> ⎮  2
> ⎮   ___ 2⋅σ
> ⎮ ╲╱ 2 ⋅ℯ
> ⎮ ─ dz
> ⎮ ___
> ⎮ 2⋅╲╱ π ⋅σ
> ⌡
>
>
> In [7]: srepr(P(N**2>1, 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
> 
> .
>
> 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

[Matthew Rocklin]

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  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  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
> 
> .
>
> 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] Convolution of a size-one pulse with itself

[Matthew Rocklin]

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  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
> 
> .
> 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] Re: Wow. (was: Add pep8 config, use pep8 in travis (#8538))

[Matthew Rocklin]

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 
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
> 
> .
>
> 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] Writing a fast pattern matcher, updates and questions

[Matthew Rocklin]

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 , 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  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

[Matthew Rocklin]

Response in line

On Wed, Nov 26, 2014 at 3:19 PM, James Crist  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
> 

Re: [sympy] The slowest of the slow

[Matthew Rocklin]

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"  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 
> 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
> 
> .
> 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] stats module

[Matthew Rocklin]

Yeah, wow, that expression and plot does look horrible.

Looks like a bug to me.  Generally integration on piecewise functions
probably isn't as pretty as integration on normal distributions.

On Wed, Sep 24, 2014 at 8:29 AM, clemens novak  wrote:

> Hello,
>
> i'm using sympy 0.7.5. and ran into the following issue when using the
> stats module.
>
> from sympy.stats import Uniform, density
> from sympy.abc import x, y, z
> from sympy import *
> from sympy.plotting import plot
>
> # I define two rv's with uniform distribution
> X = Uniform('X', -1., 1.)
> Y = Uniform('Y', -1., 1.)
>
> fx = density(X)(x)
>
> # fx equals 0.5 in [-1,1] and is zero otherwise -> ok
> pprint(fx)
>
> # however, plotting the distribution throws an error (error message see
> below)
> #plot(fx)
>
> # defining a new rv as the sum of two uniform rv's
> Z = X + Y
>
> # the density looks horribly complicated; it should have triangle shape
> # starting at x=-2, reaching y=1/2 at x=0 and decreasing till x=2
> fz = density(Z)(z)
>
>
> pprint(fz)
>
> # the "funny" thing is that the density plot is negtaive
> # fz = -0.5 for -2 plot(fz)
>
>
>
> Performing the same exercise for normal distributions yields the correct
> results;
>
> X = Normal('X', 0, 1)
> Y = Normal('Y', 0, 1)
> Z = X + Y
> fz = density(Z)(z)
> pprint(simplify(fz))
>
>
> 2
>   -z
>   
>4
>  e
> 
> 
> 2*\/ pi
>
>
>
> Did I do something wrong or is this a bug?
>
> Thanks and regards - Clemens
>
>
>
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "C:\Python27\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py",
> line 523, in runfile
> execfile(filename, namespace)
>   File "C:\Users\novakc\Desktop\p\src\python\maths\sympy\stats_03.py",
> line 20, in 
> plot(fx)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 1216,
> in plot
> plots.show()
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 184,
> in show
> self._backend.show()
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 965,
> in show
> self.process_series()
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 849,
> in process_series
> collection = self.LineCollection(s.get_segments())
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 457,
> in get_segments
> sample([self.start, f_start], [self.end, f_end], 0)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 431,
> in sample
> sample(p, new_point, depth + 1)
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 449,
> in sample
> or not flat(p, new_point, q)):
>   File "C:\Python27\lib\site-packages\sympy\plotting\plot.py", line 1039,
> in flat
> vector_a_norm = np.linalg.norm(vector_a)
>   File "C:\Python27\lib\site-packages\numpy\linalg\linalg.py", line 1973,
> in norm
> return sqrt(add.reduce((x.conj() * x).ravel().real))
> AttributeError: sqrt
>
> --
> 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/64fc08e2-43e6-47b8-8ba8-4946c14a721d%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-Fw%3D32EPwJ2YxVtdq01qnPaW0K8tg6EvVZStM3Vt%3DYXxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] ufuncify now creates actual ufuncs

[Matthew Rocklin]

Cool


On Wed, Aug 27, 2014 at 8:07 PM, James Crist  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
> 
> .
> 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

[Matthew Rocklin]

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  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

[Matthew Rocklin]

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  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
> 
> .
> 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 Rocklin]

>
> @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

[Matthew Rocklin]

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  wrote:

>
>
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Mon, Aug 4, 2014 at 3:27 PM, James Crist  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)
>>  in ()
>> > 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

Re: [sympy] SymPy talk at PyData Berlin

[Matthew Rocklin]

https://www.youtube.com/watch?v=XSRr2HHedrY



On Tue, Jun 10, 2014 at 8:57 AM, Aaron Meurer  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 
> 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  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 
> 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...@goog

Re: [sympy] Draft for a new pattern matcher

[Matthew Rocklin]

> 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 
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
> 
> .
>
> 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] Re: Pattern matching

[Matthew Rocklin]

> 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

Re: [sympy] Re: Pattern matching

[Matthew Rocklin]

I should correct my previous e-mail and say that the popularity of *this
kind of rich pattern matching* has been dead since the 90s.


On Thu, Jul 17, 2014 at 7:07 PM, Matthew Rocklin  wrote:

> 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 
> wrote:
>
>> On Thu, Jul 17, 2014 at 7:27 PM, Richard Fateman 
>> 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 
>> 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, assum

Re: [sympy] Re: Pattern matching

[Matthew Rocklin]

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 .  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 
wrote:

> On Thu, Jul 17, 2014 at 7:27 PM, Richard Fateman 
> 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 
> 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 throwi

Re: [sympy] FOL Constants and Unification

[Matthew Rocklin]

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  wrote:

> On Thu, Jul 17, 2014 at 6:50 PM, Matthew Rocklin 
> 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 
> 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 becau

Re: [sympy] FOL Constants and Unification

[Matthew Rocklin]

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  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%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Moments of a normal distribution

[Matthew Rocklin]

Cool.  It's nice to see SymPy used in this way.


On Wed, Jul 16, 2014 at 5:04 PM, Justin Vincent  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: 
>>> 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 
>>> 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
 
 .
 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
> 
> .
>
> 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] Moments of a normal distribution

[Matthew Rocklin]

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: 
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  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+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/2babc41b-0ab4-443c-a75b-d5910ce16c21%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-FSMmCOVFn3%3Dm_aLFMYEEPa2GY1o_O8x0NkJ-Paf3Q%2BDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: Meeting sometime this week?

[Matthew Rocklin]

@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  wrote:

>
>
>
> On Wed, Jul 9, 2014 at 12:21 PM, Jason Moore  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
> 
> .
>
> 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

[Matthew Rocklin]

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.  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
> 
> .
>
> 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

[Matthew Rocklin]

> 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  wrote:

> When would it not indicate an error, though?
>
> Aaron Meurer
>
>
> On Thu, Jul 3, 2014 at 5:12 PM, F. B.  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

[Matthew Rocklin]

Sympy terms can be serialized/deserialized somewhat robustly with str and
sympify.
On Jun 20, 2014 11:53 AM, "Aaron Meurer"  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  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
>> 
>> .
>> 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
> 
> .
> 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

[Matthew Rocklin]

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  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

[Matthew Rocklin]

Done.
https://conference.scipy.org/scipy2014/proposals/202/


On Wed, Jun 11, 2014 at 12:37 PM, Kyle Mandli  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 
>> 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 
>> 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 
>> 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 
>> 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 Q&A type of session
>> or an
>> >>>> > open
>> >>>> > Q&A with perhaps audience guided list of topics.
>> >>>> >
>> >>>> > Thanks!
>>

Re: [sympy] SymPy talk at PyData Berlin

[Matthew Rocklin]

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  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  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.

Re: [sympy] Re: Help with Vector

[Matthew Rocklin]

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 
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 
> 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.  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=email&utm_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=email&utm

Re: [sympy] Re: Help with Vector

[Matthew Rocklin]

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.  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
> 
> .
>
> 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] Re: pattern replacement for complex numbers and manual factorization

[Matthew Rocklin]

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  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.  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: pattern replacement for complex numbers and manual factorization

[Matthew Rocklin]

> 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.  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] Proposal for StackExchange site for Sage and ALL its subcomponents

[Matthew Rocklin]

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  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 
> 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 
> >> 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, v

Re: [sympy] SciPy 2014 SymPy BoF

[Matthew Rocklin]

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  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  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  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 Q&A type of session or an
>>> open
>>> > Q&A 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
> 
> .
>
> 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] SymPy talk at PyData Berlin

[Matthew Rocklin]

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  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

[Matthew Rocklin]

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  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  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 Q&A type of session or an
> open
> > Q&A 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

[Matthew Rocklin]

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  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.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-HJGAntNGvgL7F3yWE5-Yq6OVvGSwU3yHou%2BKt00X-kGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] Planet SymPy

[Matthew Rocklin]

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

[Matthew Rocklin]

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  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  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.

Re: [sympy] Simplification question

[Matthew Rocklin]

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  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] Failing doctest for as_dict method

[Matthew Rocklin]

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  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 "", line 1, in
>> 
>>  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?

[Matthew Rocklin]

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  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.  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.

Re: [sympy] vector expressions with unspecified dimension

[Matthew Rocklin]

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  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  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  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] SymbolicC++

[Matthew Rocklin]

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  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
> ht

[sympy] Policy on `is_foo` predicates

[Matthew Rocklin]

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] MatrixSymbol and diff function

[Matthew Rocklin]

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  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
>  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] MatrixSymbol and diff function

[Matthew Rocklin]

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 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/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

[Matthew Rocklin]

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 wrote:

> 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.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-HOt3bxjw8v3yt6B3KOCvr5V__hCrLru6x7nX_3UwgJuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Questions about the goals of CSymPy

[Matthew Rocklin]

Yeah, it's a pretty swell algorithm.  Kudos to Chris Smith.

It's also a great usecase of the strategies / decision tree stuff.  I'm
happy to go over this with anyone if they're interested.


On Fri, Apr 25, 2014 at 9:01 AM, Ondřej Čertík wrote:

>  all of the patterns in a good data structure 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

[Matthew Rocklin]

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 wrote:

> 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.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-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

[Matthew Rocklin]

>
>
 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

[Matthew Rocklin]

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  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 
> 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

[Matthew Rocklin]

>
>
> > 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] Questions about the goals of CSymPy

[Matthew Rocklin]

>
>
> 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

[Matthew Rocklin]

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  wrote:

> PyDy sounds like the perfect proof of concept test for CSymPy
>
>
> On Wed, Apr 23, 2014 at 3:42 PM, Jason Moore  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 
>> wrote:
>>
>>> On Wed, Apr 23, 2014 at 4:31 PM, Ondřej Čertík 
>>> wrote:
>>> > On Wed, Apr 23, 2014 at 4:27 PM, Aaron Meurer 
>>> 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 w

Re: [sympy] Questions about the goals of CSymPy

[Matthew Rocklin]

New assumptions strikes again!

I hope that by trying to interface SymPy with another project we expose and
fix some of the warts in SymPy's current design.  Things like Function
threw me off when I melded SymPy with LogPy (my little logic programming
system) or with Theano.  It'll be nice for others to run into these.

My hope is that if/when we remove old assumptions that we'll be able to
simplify a lot of the core, removing metaclasses, and hopefully imposing a
few more strict invariants.

SymPy is pretty awesome but it'd be nice if the trees were simpler.  That
would make it more pleasurable to interoperate with other systems.


On Wed, Apr 23, 2014 at 3:36 PM, Ondřej Čertík wrote:

> On Wed, Apr 23, 2014 at 4:31 PM, Ondřej Čertík 
> wrote:
> > On Wed, Apr 23, 2014 at 4:27 PM, Aaron Meurer 
> 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
> with SymPy and start integrating it more. For now I just keep things
> simple to get the job done.
>
> Ondrej
>
> >
> > After that, do this in sympy.core --- that requires tackling
> > assumptions and maybe few
> > other things.
> >
> > Ondrej
> >
> >>
> >> Aaron Meurer
> >>
> >> On Wed, Apr 23, 2014 at 5:19 PM, Matthew Rocklin 
> wrote:
> >>> 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

Re: [sympy] Questions about the goals of CSymPy

[Matthew Rocklin]

PyDy sounds like the perfect proof of concept test for CSymPy


On Wed, Apr 23, 2014 at 3:42 PM, Jason Moore  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 wrote:
>
>> On Wed, Apr 23, 2014 at 4:31 PM, Ondřej Čertík 
>> wrote:
>> > On Wed, Apr 23, 2014 at 4:27 PM, Aaron Meurer 
>> 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
>> with SymPy and start integrating it more. For now I just keep things
>> simple to get the job done.
>>
>> Ondrej
>>
>> >
>> > After that, do this in sympy.core --- that requires tackling
>> > assumptions and maybe few
>> > other things.
>> >

Re: [sympy] Questions about the goals of CSymPy

[Matthew Rocklin]

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

[Matthew Rocklin]

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"  wrote:

> On Wed, Apr 23, 2014 at 10:02 AM, Aaron Meurer  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] SymPy args and multiple dispatch

[Matthew Rocklin]

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] SymPy args and multiple dispatch

[Matthew Rocklin]

>
>
> 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] Re: Tensor refactory

[Matthew Rocklin]

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  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 
> 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 
> 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 
> >> 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 
> >> > 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. 
> 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 

Re: [sympy] Re: Tensor refactory

[Matthew Rocklin]

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  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  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 
>> 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 
>> 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. 
>> 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.
>> >>
>

Re: [sympy] Re: Tensor refactory

[Matthew Rocklin]

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  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 
> 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 
> 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.  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.

Re: [sympy] Re: Tensor refactory

[Matthew Rocklin]

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  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.  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] zip() argument after * must be a sequence

[Matthew Rocklin]

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 wrote:

> On Wed, Apr 9, 2014 at 3:43 AM, Groover  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

[Matthew Rocklin]

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"  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.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-HKe%3DkpQdPLmLVWK4yzGra8wAeC_1aBbt2eXpHvO-03zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] zip() argument after * must be a sequence

[Matthew Rocklin]

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  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.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-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

[Matthew Rocklin]

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  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 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  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%29&ubound=10&lbound=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.com<https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com?utm_medium=email&utm_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

[Matthew Rocklin]

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  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  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%29&ubound=10&lbound=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.com<https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com?utm_medium=email&utm_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

[Matthew Rocklin]

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  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%29&ubound=10&lbound=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.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-EFubCeaoaZOL3sfykJYHzn9S1TM3LneztWgd%3Dnoj8BZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] StackOverflow

[Matthew Rocklin]

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  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.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-GvCJM7OC5_-%3DcoDBocsJcZejH%2B51JWArLRHXS1fR9SCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] error when taking mixture of inverse gamma distributions

[Matthew Rocklin]

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  wrote:

> This is the list...
>
> Aaron Meurer
>
>
> On Fri, Apr 4, 2014 at 4:17 PM, Matthew Rocklin wrote:
>
>> 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  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 wrote:
>>>
>>>> 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 
>>&g

Re: [sympy] error when taking mixture of inverse gamma distributions

[Matthew Rocklin]

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  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 wrote:
>
>> 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, s

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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  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 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 wrote:
>>
>>> 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

[Matthew Rocklin]

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  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 wrote:
>
>> 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

[Matthew Rocklin]

> 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  wrote:

> 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-HcCt%2B_TKbfHp2-9x8FHwBgiTBF6N%3DeN1KPuBUTMXCASw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

>
> 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] Add multiple dispatch as external dependency

[Matthew Rocklin]

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"  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"  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 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<https://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.com?utm_medium=em

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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  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

[Matthew Rocklin]

>
> 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

[Matthew Rocklin]

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  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 wrote:
>
>> 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  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 wrote:
>>>
>>>> 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 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 
>>>>> wrote:
>>>>>
>>>>>>  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<https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=email&utm_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 fr

Re: [sympy] Add multiple dispatch as external dependency

[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.


On Wed, Apr 2, 2014 at 1:59 PM, Aaron Meurer  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 wrote:
>
>> 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  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 wrote:
>>>
>>>>  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<https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=email&utm_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.com<https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.com?utm_medium=email&utm_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<https://groups.google.com/d/msgid/sympy/CAJ8oX-GcPt3YDJbBX4x1EUzpOM048_cKFpGqSeaTK2BpVShJUQ%40mail.gmail.com?utm_medium=email&utm_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...

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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  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

[Matthew Rocklin]

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  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 wrote:
>
>> 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<https://groups.google.com/d/msgid/sympy/CAJ8oX-HUeYyeA%2BDEj7YwmftmrkFOQ1L5yReDNHOXZ59tEDKAmQ%40mail.gmail.com?utm_medium=email&utm_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.com<https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2pwZC7xnXee7mQdiH_xDHKKWSCxfmjnNFf3rv7BZ47g%40mail.gmail.com?utm_medium=email&utm_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

[Matthew Rocklin]

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] Re: Tensor refactory

[Matthew Rocklin]

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.  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.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-HT3JZoytpCALYsB9p91FdjwYfzQ5HF8seM2KgY%3D2Pf-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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  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

[Matthew Rocklin]

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.  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.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-GLsX9W_brk-W3Toh0notH6CswJAmmyv8X5otdoE0FcfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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 wrote:

> On Wed, Apr 2, 2014 at 9:43 AM, Matthew Rocklin 
> 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 
> > wrote:
> >>
> >> On Wed, Apr 2, 2014 at 9:18 AM, Matthew Rocklin 
> >> 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 a

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

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 wrote:

> On Wed, Apr 2, 2014 at 9:18 AM, Matthew Rocklin 
> 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

[Matthew Rocklin]

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 wrote:

> On Wed, Apr 2, 2014 at 9:09 AM, Matthew Rocklin 
> 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

[Matthew Rocklin]

>
>
> 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

[Matthew Rocklin]

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  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 wrote:
>
>> 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.com<https://groups.google.com/d/msgid/sympy/CAP7f1AjF6snYpEx_Kc-JPG%2B_Jpan4j-kjCFuOvEJLf%3DQCUkkrg%40mail.gmail.com?utm_medium=email&utm_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

[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.  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] Re: Add multiple dispatch as external dependency

[Matthew Rocklin]

> 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.  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.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-GjtoE5x2od9V_mOmZbzOorPxN9X23s1XmS9AePvU7cSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Add multiple dispatch as external dependency

[Matthew Rocklin]

> 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  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  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  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.