Re: Issue 642 in sympy: collect is not nc-aware (was: wrong answer from simplifying non-commutative symbols)
Updates: Summary: collect is not nc-aware (was: wrong answer from simplifying non-commutative symbols) Comment #11 on issue 642 by smi...@gmail.com: collect is not nc-aware (was: wrong answer from simplifying non-commutative symbols) http://code.google.com/p/sympy/issues/detail?id=642 factor is now nc-aware; collect has not been fixed: e=(A*B-B*A) factor(e) A*B - B*A simplify(e) A*B - B*A radsimp(e) A*B - B*A collect(e, A) 0 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2033 in sympy: solve should be able to handle rational function systems
Updates: Status: Fixed Comment #15 on issue 2033 by smi...@gmail.com: solve should be able to handle rational function systems http://code.google.com/p/sympy/issues/detail?id=2033 I'm closing this issue since the rational systems are now handled; the only issue remaining appears to be whether the solver should return RootOf instances (and I believe we already have an issue open for that: issue 1579 and issue 472). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3053 in sympy: setup.py egg-info fails on Python3
Comment #4 on issue 3053 by asmeu...@gmail.com: setup.py egg-info fails on Python3 http://code.google.com/p/sympy/issues/detail?id=3053 Yeah, I think we should just run use2to3, and run setup.py dist in the py3k-sympy directory the same as normal, and distribute the Python 3 sources. I've seen many other projects do this, so it should work. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2856 in sympy: lim x^8/(x^8+1)
Comment #1 on issue 2856 by amake...@college.harvard.edu: lim x^8/(x^8+1) http://code.google.com/p/sympy/issues/detail?id=2856 This seems to work now (0.7.1) with 8, and also with numbers up to but not including 16. All larger numbers seem to lead to the same prompt as above. I'll try to track down the error. However, this is my first post here and I've been dealing with Sympy for just a couple of days now, so do you think this bug is a good place to start from? -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2856 in sympy: limit(x**16/(x**16 + 1), x, oo) fails
Updates: Summary: limit(x**16/(x**16 + 1), x, oo) fails Status: Accepted Labels: Series Comment #2 on issue 2856 by asmeu...@gmail.com: limit(x**16/(x**16 + 1), x, oo) fails http://code.google.com/p/sympy/issues/detail?id=2856 Apparently there's a hard-coded limit for the number of terms of a series somewhere in the Gruntz limit algorithm, and it was recently bumped from 8 to 16. It depends on how easy you want to start. There are easier bugs to work on (search for EasyToFix in the tracker), but this one should be doable. To solve this one, I guess we need some way to dynamically compute the number of terms in a series. Also, we could probably implement a really simple heuristic for computing the limit of a rational function at infinity. If you're interested, look at the comments in gruntz.py, and look at Gruntz's thesis. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2328 in sympy: expand() doesn't parse bad hints correctly
Comment #1 on issue 2328 by gaurav.s...@gmail.com: expand() doesn't parse bad hints correctly http://code.google.com/p/sympy/issues/detail?id=2328 Hi Aaron, I tried to fix this bug and have sent a pull request https://github.com/sympy/sympy/pull/1117 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Issue 3142 in sympy: recursion error in sqrtdenest
Status: Accepted Owner: Labels: Type-Defect Priority-Medium New issue 3142 by mario.pe...@gmail.com: recursion error in sqrtdenest http://code.google.com/p/sympy/issues/detail?id=3142 ``` from sympy import * sqrtdenest(sqrt( -320 + 32*sqrt(5) + 64*sqrt(15))) ... RuntimeError: maximum recursion depth exceeded while calling a Python object ``` -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3142 in sympy: recursion error in sqrtdenest
Comment #1 on issue 3142 by mario.pe...@gmail.com: recursion error in sqrtdenest http://code.google.com/p/sympy/issues/detail?id=3142 Fixed in https://github.com/sympy/sympy/pull/1118 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3142 in sympy: recursion error in sqrtdenest
Comment #2 on issue 3142 by mario.pe...@gmail.com: recursion error in sqrtdenest http://code.google.com/p/sympy/issues/detail?id=3142 Fixed in https://github.com/sympy/sympy/pull/1119 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3142 in sympy: recursion error in sqrtdenest
Updates: Labels: NeedsReview Simplify Comment #3 on issue 3142 by asmeu...@gmail.com: recursion error in sqrtdenest http://code.google.com/p/sympy/issues/detail?id=3142 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Issue 3143 in sympy: Multiplication of immutable matrices gives wrong results on specific input
Status: Accepted Owner: CC: mrock...@gmail.com Labels: Type-Defect Priority-Medium WrongResult Matrices New issue 3143 by krastano...@gmail.com: Multiplication of immutable matrices gives wrong results on specific input http://code.google.com/p/sympy/issues/detail?id=3143 In [112]: ImmutableMatrix([[1,0,0,0]])*ImmutableMatrix(eye(4)) Out[112]: I In [113]: _.as_explicit() Out[113]: [1] In [114]: Matrix([[1,0,0,0]])*Matrix(eye(4)) Out[114]: [1 0 0 0] -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3143 in sympy: Multiplication of immutable matrices gives wrong results on specific input
Updates: Status: Started Owner: mrock...@gmail.com Comment #1 on issue 3143 by mrock...@gmail.com: Multiplication of immutable matrices gives wrong results on specific input http://code.google.com/p/sympy/issues/detail?id=3143 See https://github.com/sympy/sympy/pull/1120 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3143 in sympy: Multiplication of immutable matrices gives wrong results on specific input
Updates: Labels: NeedsReview Comment #2 on issue 3143 by asmeu...@gmail.com: Multiplication of immutable matrices gives wrong results on specific input http://code.google.com/p/sympy/issues/detail?id=3143 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 1113 in sympy: rewrite sign(x) (and possibly abs()) using Piecewise
Comment #8 on issue 1113 by asmeu...@gmail.com: rewrite sign(x) (and possibly abs()) using Piecewise http://code.google.com/p/sympy/issues/detail?id=1113 In master both remain unevaluated: In [1]: integrate(abs(x), x)Out[1]: ⌠ ⎮ │x│ dx ⌡ In [2]: integrate(abs(x), (x, -1, 2))Out[2]: 2 ⌠ ⎮ │x│ dx ⌡ -1 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3060 in sympy: use of evalf() needs review
Comment #1 on issue 3060 by asmeu...@gmail.com: use of evalf() needs review http://code.google.com/p/sympy/issues/detail?id=3060 Wouldn't it be easier to just check if free_symbols is empty in that case? -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3044 in sympy: qapply does not work for c_part*TensorProduct
Updates: Labels: NeedsReview Comment #3 on issue 3044 by asmeu...@gmail.com: qapply does not work for c_part*TensorProduct http://code.google.com/p/sympy/issues/detail?id=3044 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3073 in sympy: Ordering args in Adds when printing to move negative signs
Comment #6 on issue 3073 by asmeu...@gmail.com: Ordering args in Adds when printing to move negative signs http://code.google.com/p/sympy/issues/detail?id=3073 Maple just keeps things in the order you enter them, and output from functions is customized (e.g., the series function returns expressions in rev-lex order, and I think most other things use something similar to what we do with lex). The TI89 does something along the lines of what is suggested here. We could probably figure out what it's algorithm is. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3073 in sympy: Ordering args in Adds when printing to move negative signs
Comment #7 on issue 3073 by asmeu...@gmail.com: Ordering args in Adds when printing to move negative signs http://code.google.com/p/sympy/issues/detail?id=3073 I just checked, and the TI89 is not as smart as I remember it. I think we can improve upon it. It does turn -x + y into y - x, and -x**2 + y**2 into y**2 - x**2. But -x**2 + x + y**2 - y is left alone. So I guess they just favor lex ordering when the simple heuristic doesn't come into play. One thing that it does a little of and that we can do is rewrite fractions so that there are minimal minus signs, so e.g., (-x**2 + x + 1)/(-x + y) is turned into (x**2 - x - 1)/(x - y). But it turns (-x**2 + x + 1)/(-y + x) into -(x**2 - x - 1)/(x - y). So it seems that the algorithm favors an ordering of x first then y over minimizing minus signs. Of course, then we get into the question of if we really want to canonicalize (x - y)/(a - b) and (y - x)/(b - a) into the same thing. I've yet to use a CAS that writes things the way I would automatically (or even after calling simplify()). Maple comes the closest by just leaving things exactly the way I entered them, but after an operation of some function, this doesn't matter any more, and it's just as bad (or good) as the rest. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3129 in sympy: Drastic change to sympy.stats: Adding concept of Probability Distributions on surface level
Comment #10 on issue 3129 by nathan.f...@gmail.com: Drastic change to
sympy.stats: Adding concept of Probability Distributions on surface level
http://code.google.com/p/sympy/issues/detail?id=3129
Okay then... why do PSpaces need a symbol bound to them? Printing out
pspace(X) gives us a domain and a density function (or map for discrete
rvs). This can be accomplished by using sets to represent the domain and
Lambdas for the density. I think there are some cool things we can do with
making PSpaces (soon to be distributions?) static, like capture the fact
that
X = Normal(2, 3).new('X')
Z = (X-2)/3
pspace(Z)
Normal(0, 1)
Basically, capturing relationships of transformations of variables. You're
right that this can cause complications with lots of compound variables,
but it's too useful of a feature to disregard...
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to this group, send email to sympy-issues@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3129 in sympy: Drastic change to sympy.stats: Adding concept of Probability Distributions on surface level
Comment #12 on issue 3129 by asmeu...@gmail.com: Drastic change to
sympy.stats: Adding concept of Probability Distributions on surface level
http://code.google.com/p/sympy/issues/detail?id=3129
In [1]: from sympy.stats import *
In [2]: T = Normal(30, 3, symbol=Symbol('T')) # temperature is 30C with std
dev 3C.
In [3]: T_posterior = Given(T, T29) # We know that T is greater than 29
In [4]: P(TT_posterior)
ValueError
My probability is a little rusty. Why does this raise ValueError?
In [6]: T.symbol is Symbol('T')
Out[6]: True
is comparison of Symbols (or indeed anything other than Singletons) only
works because of the cache and should not be relied upon.
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to this group, send email to sympy-issues@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 3129 in sympy: Drastic change to sympy.stats: Adding concept of Probability Distributions on surface level
Comment #13 on issue 3129 by mrock...@gmail.com: Drastic change to sympy.stats: Adding concept of Probability Distributions on surface level http://code.google.com/p/sympy/issues/detail?id=3129 T and T_posterior represent the same variable in different contexts. It doesn't make sense to compare them. T_posterior is under an assumption that T isn't. Regarding 'is' yes, I probably should have used '==' in this example. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2033 in sympy: solve should be able to handle rational function systems
Updates: Status: Fixed Comment #15 on issue 2033 by smi...@gmail.com: solve should be able to handle rational function systems http://code.google.com/p/sympy/issues/detail?id=2033 I'm closing this issue since the rational systems are now handled; the only issue remaining appears to be whether the solver should return RootOf instances (and I believe we already have an issue open for that: issue 1579 and issue 472). -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 3142 in sympy: recursion error in sqrtdenest
Updates: Labels: NeedsReview Simplify Comment #3 on issue 3142 by asmeu...@gmail.com: recursion error in sqrtdenest http://code.google.com/p/sympy/issues/detail?id=3142 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 3044 in sympy: qapply does not work for c_part*TensorProduct
Updates: Labels: NeedsReview Comment #3 on issue 3044 by asmeu...@gmail.com: qapply does not work for c_part*TensorProduct http://code.google.com/p/sympy/issues/detail?id=3044 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: [sympy] 64-bit test request
Running tests now. By the way, make sure you do a git pull on sympy-bot. I recently pushed a fix where it would mis-report the architecture. Otherwise, make sure to look in the test report itself for the architecture, not the summary for any tests run before that. Aaron Meurer On Mon, Mar 12, 2012 at 11:26 PM, smichr smi...@gmail.com wrote: Could somebody run 64-bit tests on https://github.com/sympy/sympy/pull/1116 ? There was a failure in doctests (mechanics) under py 3.2 in 64-bit but it wouldn't hurt to run all the 64-bit tests. (I didn't get the py 3.2 failure in 32-bit, so I think it's just a 32 vs 64 bit issue.) -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] 64-bit test request
Sean just ran the test. There were doctest failures in exprtools and gotchas, so if you could just run the doctests on those to files with the most recent push, that should suffice. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Refactoring the old assumptions
On Mon, Mar 12, 2012 at 6:54 PM, Ronan Lamy ronan.l...@gmail.com wrote: Le lundi 12 mars 2012 à 14:13 -0600, Aaron Meurer a écrit : Great. I came to the same conclusion when working on that issue. Regarding the last commit, Don't allow classes to set assumptions, except for Symbol. does that mean that Function should not be allowed to set assumptions. I noticed that Function(f, real=True) does not actually work, either in master or your branch? But it should, right? well, Function is special because it returns a class, not a Basic object. I didn't change its behaviour. It's not that clear what Function(f, real=True) should do. In most cases, what you actually want is a function that returns a real when its argument is real, but that can't be expressed clearly with that kind of notation. I would expect it to just satisfy f(whatever).is_real == True. More advanced stuff (like dependence on the argument) would either have to rely on some unimplemented feature of the (new) assumptions, or simply subclassing Function. By the way, in the long run, I think we should change how Function works to not generate a class. http://code.google.com/p/sympy/issues/detail?id=1198 is one big reason. Regarding the rest, I have no idea what happens in the logic code, so I can't say much about that. The changes in sympy/core/facts.py aren't that relevant to this refactoring. They follow a different strand of thought which is to get the old assumptions to rely on sympy.logic.boolalg instead of using its own logic system in sympy.core.logic. I see. Well, if you are unsure about what you've done there, you could probably ping Christian to review the changes. I'm sure they are fine, though (especially if you can get the tests to pass :-) Aaron Meurer Aaron Meurer On Mon, Mar 12, 2012 at 11:34 AM, Ronan Lamy ronan.l...@gmail.com wrote: I've been working on a refactoring of the old assumptions. The first part was to replace the ._assumptions dict with a dedicated class (subclassing dict). This brings interesting conceptual clarifications and code simplifications. In particular, it's now clear to me that assumptions are used in two rather different ways. For Symbols, assumptions do actually represent assumptions that are part of the object's definition. For all other objects, assumptions are a smart property cache, that allows some properties to be computed lazily and efficiently, and these assumptions should therefore never be explicitly set, not even in the constructors. I guess that the next steps are to make the split more explicit and to stop pickling property caches (which would solve http://code.google.com/p/sympy/issues/detail?id=2587 ). My branch is here: https://github.com/rlamy/sympy/tree/new-core and I'd be happy to have some feedback. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Refactoring the old assumptions
On Mon, Mar 12, 2012 at 6:27 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Le lundi 12 mars 2012 à 14:18 -0600, Aaron Meurer a écrit :
On Mon, Mar 12, 2012 at 1:42 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Le lundi 12 mars 2012 à 20:13 +0100, krastanov.ste...@gmail.com a
écrit :
I thought that the old module is deprecated and it is to be removed.
In the new module all assumptions are property cashes as you put it
if I am not mistaken.
The old assumptions are a fundamental part of the core, so they can't
just be removed, or deprecated in any meaningful way.
So what do you think should be done, in the long run? I agree that we
should (and pretty much will have to) keep the old API around, but
internally, we should just use the new assumptions, so that we don't
have code duplication.
In the long run, I think the systems should be merged, by breaking up
the old system and connecting its low-level parts to the new one.
I also think this is the way to go, at least in the sense that we want
to keep the fundamental aspects of the old system, namely, the global
assumptions implemented as attribute access calls. To me, saying we
should unhook the old assumptions and hook them into the new one and
saying that we should implement global assumptions in the new
assumptions with the same API as the old assumptions are just saying
the same thing from two opposite directions.
Of course, that's a pretty broad description of the plan. As far as
the actual implementation details go, and the new APIs go, we will
have to discuss things to figure out the best way to do it.
In the new assumptions, there's no cache: things like ask(Q.prime(7))
are recomputed every time, contrarily to Integer(7).is_prime.
Should this be changed? It seems like this would make things
inefficient if we used the new assumptions everywhere.
Yes, it would be rather inefficient, but this isn't the worst problem
IIRC. The real pain point is that actual assumptions (i.e. Q.prime(n) as
opposed to Q.prime(7)) are stored in a big set that must be inspected in
full every time ask() is called.
By in full do you mean as in a linear time search? Is this solved
by just storing the (global) assumptions in the objects themselves (or
at least caching them there)?
And if so, should the cache be stored in a global dict, or inside the
objects themselves? Anyway, I guess this is a (probably) trivial
implementation detail that can be worked out once we start replacing
the old assumptions.
A global cache would keep objects alive indefinitely, which might be a
problem, even though the cache currently tends to do that anyway.
Well, on the one hand, Integer(7) is likely to not be the same object
every time (unless we assume that we are using the regular cache). So
if we store it in the object itself, that won't help.
On the other hand, it makes perfect sense to store it inside
Symbol('n', integer=True). We have to at least store the given
assumption, by definition (unless we want to make Symbol('n',
integer=True) automatically assume that Symbol('n').is_integer is
True, which is a bad idea).
But I do think this is a real issue that we should try to think about,
even for our normal cache, because people use SymPy for very large
expressions all the time, as we've seen here on the mailing list. And
the worst part is, when you operate on such large expressions, that's
when you need the speed of the cache the most. And I really think
that we're stress testing SymPy far too little. But I'm digressing...
Aaron Meurer
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Assumptions
You would need to know that sin(th) 0. Otherwise, sqrt(sin(th)**2) could be -sin(th). And there isn't a way to do this yet. Aaron Meurer On Mon, Mar 12, 2012 at 8:25 AM, Alan Bromborsky abro...@verizon.net wrote: Can assumptions handle the following case - I have the expression sin(th)**2 and know that sin(th)**2 0 and I want sqrt( sin(th)**2) = sin(th). -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Assumptions
I have the expression sin(th)**2 and know that sin(th)**2 0 and I want
sqrt( sin(th)**2) = sin(th).
What you can do to get some simplification is to replace `th` with a real
symbol:
var('th', real=1)
th
sqrt(sin(th)**2)
Abs(sin(th))
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] alternatives to subclassing Expr
Am 11.03.2012 23:04, schrieb Ronan Lamy: 'Monoid' is a kind of structure, 'integer' is a kind of number. They aren't on the same level. Ah, agreed. But I agree that the name of a class should be the (uppercase version of the) name designating an arbitrary instance of the class, so the parallels are Integer/MonoidElement and Ring/Monoid. Yes, except MonoidElement is a somewhat unwieldy name for a class. Besides, the class defines Monoid axioms, so one could still argue that Monoid, if a category error, is still describing the purpose of the class well (but not the elements). Things get even unclearer if you consider that Monoid may be used for a symbolic math system (not SymPy, Python cannot fully handle diamond inheritance anyway). In such a situation, Monoid would probably also have functions that operate on the monoid itself, in which case one could argue that Monoid is really the better name. Not that I'm actually arguing for any of these possibilities; it's pretty unclear to me what the best naming policy would be. Fortunately, the essay is about multiple inheritance, not about setting up a type hierarchy for math, so the whole issue isn't too important. Not in that context anyway :-) However, there's another fundamental cause of confusion here. Mathematically, a set and an algebraic structure over that set aren't the same thing. If you call the set of integers ZZ, the ring of integers is (ZZ, +, *), which contains 2 monoids: (ZZ, +) and (ZZ, *). So, integers should be instances of the class Integer and we should, separately, have an integer_ring object which is an instance of the class Ring(). Yes, that construction would work. On the monoid side, things are a bit different because MonoidElement is presumably a generic class that should work for any monoid. Ring would be generic, too, and just in the same way as Monoid. The difference is that we don't need that genericity inside the current example, but we'd have a RingInteger,+,*, a RingVector?,+,* (I'm being awfully sloppy here), etc. So, MonoidElement instances need a reference to the instance of Monoid they belong to. To have integers fit with this generic framework, we need a similar RingElement class, with signature RingElement(ring, *params) and Integer should subclass it, so that Integer(n) is Liskov-substitutable for RingElement(integer_ring, n). Should work, too. Not in Python, though. You still don't have the ability to inherit the Monoid operator twice into Ring and name it + for the additive monoid and * for the multiplicative monoid. Of course you could say that Ring is just a container for two Monoids, but it would become a bit cumbersome: when writing code that deals with a Monoid variable m, you'd be forced to write m.additive.op and m.multiplicative.op instead of m.plus and m.times. If you define m.plus as a new function that does m.multiplicative.op, you'll be unable to use a group polymorphically instead of a monoid. Hmm. Okay. You can use the m.plus function where you know you're dealing with a Group, and m.additive to pass it to code that expects a Monoid. I'm not 100% sure that this will hold up in all situations, but it covers the most important cases anyway. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 11.03.2012 21:40, schrieb Sergiu Ivanov: I've never had any serious experience with operator precedence parsing, but I have the intuition that this technique is going to be quite unwieldy if we would like to go beyond simple expressions like the ones you have shown. It's a trade-off. The decision should be driven by the project goals, since no parsing technique can cover all. Here's a run-down of available techniques: Operator-precedence: Somewhat limited (but not as badly as many people think). Extending the grammar requires the ability to grasp the concepts of precedence and associativity. The parser can easily generate useful error messages. Extremely easy to implement. LL(k): Surprisingly limited, it cannot parse any input that starts with k or more left parentheses; without parentheses, it cannot parse any grammar that has more than k precedence levels with infix or postfix operators. Extending the grammar requires the ability to compute the sets of prefixes, which is moderately difficult and mostly doable in one's head. The parser has a hard time generating useful error messages. Implementation is quite complex. SLR: Only marginally less limited than operator-precedence. Otherwise, the same advantages and disadvantages as LR(k) hold. LALR(k): Almost as powerful as LR(k+1). Generating error messages is somewhat more difficult than with LR(k). Otherwise, the same advantages and disadvantages as LR(k) hold. LR(k): This is the most powerful widely-known algorithm for which ambiguities can be detected by inspecting the grammar. Extending the grammar requires intimate knowledge of the parsing algorithm; otherwise, you'll be unable to interpret the shift-reduce and reduce-reduce conflict error messages. Generating useful error messages is moderately difficult. Implementation is complex. Earley: Can handle arbitrary context-free grammars. The downside is that there is no way to check whether a grammar is ambiguous. However, the algorithm will detect if a given input is ambiguous. Extending the grammar is trivial, checking it for ambiguity requires an arsenal of techniques (in practice, most teams just hope that there is no problem there and tweak the grammar until practical usage does not throw ambiguity errors anymore). I don't know how hard generating useful error messages is. I suspect it's hard or impossible, but I'd have to ask a search engine to verify that. Implementation complexity is almost as complex as LR(k) (the parsing algorithm is more complex but you do not need to preprocess the grammar). The algorithm is worst-case polynomial in input length: quadratic if the input is unambiguous, cubic if it is ambiguous. This is not a serious issue for small inputs. There are variants that have better worst-case complexities, but these are more complex. However, I'd recommend using a parser generator instead of writing a parser from scratch yourself. It will introduce some slowdown, but will instead make the whole thing a lot easier to write, maintain and, more importantly, to extend. A parser generator is required for LL and LR variants. The problem with these is that they usually come with their own syntax, so using them requires learning new skills. I'm not sure about the state of parser generators for Python, but this page http://wiki.python.org/moin/LanguageParsing may provide some information. A parser that's embedded into Python as a DSL would be an option. I can see a different problem here though: choosing a parsing method and producing the grammar of the language (or what information the parser would require) may not be enough to get the desired functionality. What we are trying to get at should incorporate something similar to natural language processing. Therefore, before actually starting the parsing process, I think the input should be brought to some kind of canonical form. I am strongly inclined to believe that Wolfram|Alpha takes exactly this way of doing things (but obviously with a lot more details). The first step to transformation would be a parse, so I'm not really sure what point you're making here. One simple thing I can think of is detecting synonyms. For example, roots x**2 == 1 and solutions x**2 == 1 and solve x**2 == 1 are one and the same thing. Therefore, it may be useful to start with substituting each of these synonyms with some canonical word (solve, for example). This is stuff that is easiest to do *after* a parse. It is possible to argue that this can be solved by introducing additional rules into the grammar. It's easier to build alternate definitions into the semantic processing that happens after the parse. However, I am inclined to believe that this will make the grammar unnecessarily large and, even worse, slow down the parser. The parsing algorithms enumerated above do not care much about whether each function and operator name is done in a separate grammar rule, or if there is one rule
Re: [sympy] alternatives to subclassing Expr
Am 11.03.2012 22:48, schrieb Aaron Meurer: IOW fully general double dispatch means you have to think about and fill out ALL cells in the matrix. Which means that the matrix cannot be extended in more than one direction independently. Right, we have to accept that there will be certain combinations that are undefined with this, because of conflicting rules. That's actually an important consideration, and one of the reasons that I wanted to make that wiki page that lists everything. FWIW, I think that undefined combinations should remain just that, undefined, i.e., they can return anything within the constructs of either definition. In that case you'd have to check that both constructs Do The Right Thing. Otherwise, changes somewhere up the hierarchy might make any unit test that uses subclasses fail. I'd suggest making the undefined matrix cells truly undefined, i.e. calling them throws an error. That forces whoever integrates two type hierarchies to make sure that the combinations are correct (probably by contacting the authors of the extensions and work the combination out). Counter-question: Do we actually do code coverage analysis? Yes. See the bin/coverage_report.py script. Thanks to the work of people like Chris, and many of our GCI students, we actually have pretty good coverage right now. Ah, sweet. I wasn't aware of that. - Code can be much simpler if the rules follow some kind of pattern, because you can then just code the pattern. You might say that that's also possible with data, but then you are just doing things in code anyway, but in a more circuitous way. Patterns can be factored out in code just as in data. No, I meant that patterns can be factored out only in code, not in data. Because you have the full power of programmability when you do things in code, whereas data will be limited to whatever level of power you give it More power also means more potential for unexpected side effects. I still stand by my words. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Refactoring the old assumptions
Am 13.03.2012 01:27, schrieb Ronan Lamy: A global cache would keep objects alive indefinitely, which might be a problem, even though the cache currently tends to do that anyway. How about using weak references? See http://docs.python.org/library/weakref.html . There seem to be a few caveats and gotchas there. I don't know whether they'd affect SymPy's caches though. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Thanks for the helpful advice. So which method would you recommend using for this? Expression size isn't an issue for SymPy Gamma, by the way, as we are limited by what the App Engine can handle anyway (You'll find that WolframAlpha can't handle very large or even moderately expressions either). On Tue, Mar 13, 2012 at 1:42 AM, Joachim Durchholz j...@durchholz.org wrote: Am 11.03.2012 21:40, schrieb Sergiu Ivanov: I've never had any serious experience with operator precedence parsing, but I have the intuition that this technique is going to be quite unwieldy if we would like to go beyond simple expressions like the ones you have shown. It's a trade-off. The decision should be driven by the project goals, since no parsing technique can cover all. Here's a run-down of available techniques: Operator-precedence: Somewhat limited (but not as badly as many people think). Extending the grammar requires the ability to grasp the concepts of precedence and associativity. The parser can easily generate useful error messages. Extremely easy to implement. LL(k): Surprisingly limited, it cannot parse any input that starts with k or more left parentheses; without parentheses, it cannot parse any grammar that has more than k precedence levels with infix or postfix operators. Extending the grammar requires the ability to compute the sets of prefixes, which is moderately difficult and mostly doable in one's head. The parser has a hard time generating useful error messages. Implementation is quite complex. SLR: Only marginally less limited than operator-precedence. Otherwise, the same advantages and disadvantages as LR(k) hold. LALR(k): Almost as powerful as LR(k+1). Generating error messages is somewhat more difficult than with LR(k). Otherwise, the same advantages and disadvantages as LR(k) hold. LR(k): This is the most powerful widely-known algorithm for which ambiguities can be detected by inspecting the grammar. Extending the grammar requires intimate knowledge of the parsing algorithm; otherwise, you'll be unable to interpret the shift-reduce and reduce-reduce conflict error messages. Generating useful error messages is moderately difficult. Implementation is complex. Earley: Can handle arbitrary context-free grammars. The downside is that there is no way to check whether a grammar is ambiguous. However, the algorithm will detect if a given input is ambiguous. Extending the grammar is trivial, checking it for ambiguity requires an arsenal of techniques (in practice, most teams just hope that there is no problem there and tweak the grammar until practical usage does not throw ambiguity errors anymore). I don't know how hard generating useful error messages is. I suspect it's hard or impossible, but I'd have to ask a search engine to verify that. Implementation complexity is almost as complex as LR(k) (the parsing algorithm is more complex but you do not need to preprocess the grammar). The algorithm is worst-case polynomial in input length: quadratic if the input is unambiguous, cubic if it is ambiguous. This is not a serious issue for small inputs. There are variants that have better worst-case complexities, but these are more complex. However, I'd recommend using a parser generator instead of writing a parser from scratch yourself. It will introduce some slowdown, but will instead make the whole thing a lot easier to write, maintain and, more importantly, to extend. A parser generator is required for LL and LR variants. The problem with these is that they usually come with their own syntax, so using them requires learning new skills. I'm not sure about the state of parser generators for Python, but this page http://wiki.python.org/moin/LanguageParsing may provide some information. A parser that's embedded into Python as a DSL would be an option. I can see a different problem here though: choosing a parsing method and producing the grammar of the language (or what information the parser would require) may not be enough to get the desired functionality. What we are trying to get at should incorporate something similar to natural language processing. Therefore, before actually starting the parsing process, I think the input should be brought to some kind of canonical form. I am strongly inclined to believe that Wolfram|Alpha takes exactly this way of doing things (but obviously with a lot more details). The first step to transformation would be a parse, so I'm not really sure what point you're making here. One simple thing I can think of is detecting synonyms. For example, roots x**2 == 1 and solutions x**2 == 1 and solve x**2 == 1 are one and the same thing. Therefore, it may be useful to start with substituting each of these synonyms with some canonical word (solve, for example). This is stuff that is easiest to do *after* a parse. It is possible to argue that this can be solved by introducing
Re: [sympy] alternatives to subclassing Expr
On Tue, Mar 13, 2012 at 1:43 AM, Joachim Durchholz j...@durchholz.org wrote: Am 11.03.2012 22:48, schrieb Aaron Meurer: IOW fully general double dispatch means you have to think about and fill out ALL cells in the matrix. Which means that the matrix cannot be extended in more than one direction independently. Right, we have to accept that there will be certain combinations that are undefined with this, because of conflicting rules. That's actually an important consideration, and one of the reasons that I wanted to make that wiki page that lists everything. FWIW, I think that undefined combinations should remain just that, undefined, i.e., they can return anything within the constructs of either definition. In that case you'd have to check that both constructs Do The Right Thing. Otherwise, changes somewhere up the hierarchy might make any unit test that uses subclasses fail. I'd suggest making the undefined matrix cells truly undefined, i.e. calling them throws an error. That forces whoever integrates two type hierarchies to make sure that the combinations are correct (probably by contacting the authors of the extensions and work the combination out). One problem is that it's not really a Matrix. Classes like Mul and Add are container objects that can hold any number of items. If we want to assert commutativity and associativity (the latter is actually implied by the n-ary-ness of the container), we must define operations on any combination. In practice, this isn't an issue because rules can be generalized. oo combines with any finite real number in an Add, no matter how many there are, for example. Aaron Meurer Counter-question: Do we actually do code coverage analysis? Yes. See the bin/coverage_report.py script. Thanks to the work of people like Chris, and many of our GCI students, we actually have pretty good coverage right now. Ah, sweet. I wasn't aware of that. - Code can be much simpler if the rules follow some kind of pattern, because you can then just code the pattern. You might say that that's also possible with data, but then you are just doing things in code anyway, but in a more circuitous way. Patterns can be factored out in code just as in data. No, I meant that patterns can be factored out only in code, not in data. Because you have the full power of programmability when you do things in code, whereas data will be limited to whatever level of power you give it More power also means more potential for unexpected side effects. I still stand by my words. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Multiplication of noncommutative expressions
First a question on noncommutative multiplication. The following code -
from sympy import *
(a1,a2,b1,b2) = symbols('a1 a2 b1 b2')
(e1,e2) = symbols('e1 e2',commutative=False)
x = expand(a1*(e1+e2)*a2*b1*(e1+e2)*b2)
print x
gives -
a1*a2*b1*b2*e1*e2 + a1*a2*b1*b2*e1**2 + a1*a2*b1*b2*e2*e1 +
a1*a2*b1*b2*e2**2
Are the products of the noncommutative symbols always grouped together?
This is important so that if one defines a multiplication table for the
noncommutative symbols a complex product could be evaluated with a simple
x = x.subs(mul_table)
where the keys of the mul_table dictionary are e1**2, e1*e2, e2*e1,
e2**2. Would e1*e1 work as a key as well as e1**2?
The second question is if one uses a function rather than a table to
calculate the product of noncommuting symbols what class should be
subclassed in order to overload the __mul__() operator? Should it be
the Basic class?
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Sympy quick guide
On Mar 13, 4:33 am, Aaron Meurer asmeu...@gmail.com wrote: Is this part of one of the ideas on the ideas list, or a new one that you came up with? Aaron Meurer On Mon, Mar 12, 2012 at 8:36 AM, Abhiram Ampabathina abhiram.ampabath...@gmail.com wrote: On Mar 11, 12:33 am, Sergiu Ivanov unlimitedscol...@gmail.com wrote: On Sat, Mar 10, 2012 at 6:46 AM, Abhiram Ampabathina abhiram.ampabath...@gmail.com wrote: I think our both ideas should be mixed. I was thinking the same way. Why not we give the Sympy console and input area also. User may use any one of them, right? User shall be free to use any of the testing mechanisms, the Sympy console and the input area. If they do not like the input area they are gonna use Sympy Console where it is right there. In that way we could use the existing Sympy console and also add the things of Practical guide. Ok, lets put it in this way(i mean summarize this) Well, OK, trying this can't hurt :-) However, I'd like to ask Aaron to voice his final opinion on this matter. We shall allow users to create a account on Sympy. And give them access to the Sympy Practical Guide first. They shall use it any time they want.(since it is available online) They shall go through the practical guide in the manner we thought of 1. Starting from code conventions to different complex modules Not sure about this point: this would be useful for people who want to do some hacking, but not that useful for those who are just interested in learning how to use SymPy. Perhaps this step could be made optional or moved nearer to the end of the sequence. 2. The guide consists of lessons like as we thought of with narration and explanation. 3. Few exercises too(may skip if they are strong on concepts). 4. Can try testing the code using the Sympy console (or) input area(if they feel comfortable) , which is provided right there at guide. Fantastic, the users could understand , try the code and get the code at the same time, same place. 5. Can also render the code which is relevant to that module(so that they understand what is happening). Sounds not bad. Finally also providing a back-end to insert new modules(If you like this only, Sergiu). Well, I *think* it might be useful :-) Again, I'd ask the principal developers to provide their opinion on this matter. How is this? Shall we proceed in this way. Mention any changes you would like. I'll mail the screen shots accordingly like i mentioned above. May be you will feel good by actually looking at them, rather than just talking. Yes, sure, looking forward to seeing the updated design :-) Sergiu Hello Sergiu, I am now making some series of screen shots, how is the guide gonna look(just a sample, the actual guide shall be a good one after many reviews). However, i am glad that you guys are considering to think about practical guide like thing is useful. I would like to know whether this project can be a part of Sympys Gsoc 2012. Please, let me know the feedback. Inform whatever is needed from my side. Take a look at the screen shots which i will provide in a while. Regards, Abhiram -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/sympy?hl=en. Hello Aaron, The idea of Sympy practical guide is not from the ideas list. I thought it would nicer if we have documentation of the code, test the code and also render the code (if user wants to) at the same time and same place, so that it would be very quick to learn Sympy. Please, let me know your opinion on this idea. I have attached the screen shots. please, take a look at this. First: https://docs.google.com/file/d/0B8pXy4LH0sF0dmRuTy1rX01SWkc1Y1NUalBvS2RWZw/edit Second: https://docs.google.com/file/d/0B8pXy4LH0sF0VlhPeENDVXVUd2VDck9Kc2VBYWVEZw/edit Third: https://docs.google.com/file/d/0B8pXy4LH0sF0REliUXozeUlUQUswQnNfUU5UUE5uZw/edit ... ... And the remaining practical guide features are already discussed. Let me know whether it is useful to Sympy or not. Regards, Abhiram -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 6:16 AM, Bharath M R catchmrbhar...@gmail.com wrote: Yeah I think I should use some parser generators. But doesn't it introduce a dependency on the parser generator. Is it ok to have this dependency? Usually, you only use the parser generator to produce the code of the parser. This resulting code is technically independent of the parser generator. I'd think such (not that firm) dependency should be OK. Sergiu -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Hi-Introduction
Hello Mr. Sergiu, Thanks for the help.This sequence is very good. I have visited the issues list and it also helped me get started with SymPy. Some of those ideas caught my attention.And a few of them were really encouraging and motivational. The idea of Implementing All known Analytical Solutions to Quantum Mechanical Systems is really interesting because of its diverse use and benefits to the community. This can be used in most of the universities and colleges to help students learn Quantum Mechanics effectively. Freshers and sophomores are generally taught simple Quantum systems like 1-D(finite, infinite well,Oscillator), Simple harmonic Oscillator , Dirac functions , 3-D oscillator, hydrogen atoms,Rigid rotors and similar things.So i think it is good idea and i want to pursue this idea for my GSoC project this summer. However i would like to get your inputs about the idea? Is this project big enough for a whole summer ? Is it prioritized among other ideas? Thanks, Rhythm Gupta. On Tue, Mar 13, 2012 at 2:21 AM, Sergiu Ivanov unlimitedscol...@gmail.comwrote: Hello, On Mon, Mar 12, 2012 at 1:50 PM, Rhythm Gupta rhythm.gupt...@gmail.com wrote: I love coding and i have good background in Maths and Science. Hence, Sympy looks like the perfect organisation for me. :-) Would like to apply for Sympy in GSoC. Could you help me get started with Sympy.? To get started with SymPy, I would recommend reading the tutorial (and doing some of the things described there): http://docs.sympy.org/0.7.1/tutorial.html . Then I would recommend reading the User's Guide: http://docs.sympy.org/0.7.1/guide.html#guide . This sequence worked for me :-) I hope it would be useful to you as well :-) Then you should decide which part of SymPy you would like to work on. This is an important decision and you should consider it very carefully so that you don't feel the desire to switch to a different domain later on. In the meantime, throw a look at http://code.google.com/p/sympy/issues/list , choose one (or more of them) and fix them. https://github.com/sympy/sympy/wiki/Development-workflow this will help you with setting up your environment. Each of these issues has a cherry on it: http://code.google.com/p/sympy/issues/list?can=2q=label%3AEasyToFix+colspec=ID+Type+Status+Priority+Milestone+Owner+Summary+Starscells=tiles :-) Good luck and feel free to report your progress to the list, Sergiu -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 9:42 AM, Joachim Durchholz j...@durchholz.org wrote: Am 11.03.2012 21:40, schrieb Sergiu Ivanov: Here's a run-down of available techniques: Operator-precedence: Somewhat limited (but not as badly as many people think). Extending the grammar requires the ability to grasp the concepts of precedence and associativity. The parser can easily generate useful error messages. Extremely easy to implement. LL(k): Surprisingly limited, it cannot parse any input that starts with k or more left parentheses; without parentheses, it cannot parse any grammar that has more than k precedence levels with infix or postfix operators. Extending the grammar requires the ability to compute the sets of prefixes, which is moderately difficult and mostly doable in one's head. The parser has a hard time generating useful error messages. Implementation is quite complex. SLR: Only marginally less limited than operator-precedence. Otherwise, the same advantages and disadvantages as LR(k) hold. LALR(k): Almost as powerful as LR(k+1). Generating error messages is somewhat more difficult than with LR(k). Otherwise, the same advantages and disadvantages as LR(k) hold. LR(k): This is the most powerful widely-known algorithm for which ambiguities can be detected by inspecting the grammar. Extending the grammar requires intimate knowledge of the parsing algorithm; otherwise, you'll be unable to interpret the shift-reduce and reduce-reduce conflict error messages. Generating useful error messages is moderately difficult. Implementation is complex. Earley: Can handle arbitrary context-free grammars. The downside is that there is no way to check whether a grammar is ambiguous. However, the algorithm will detect if a given input is ambiguous. Extending the grammar is trivial, checking it for ambiguity requires an arsenal of techniques (in practice, most teams just hope that there is no problem there and tweak the grammar until practical usage does not throw ambiguity errors anymore). I don't know how hard generating useful error messages is. I suspect it's hard or impossible, but I'd have to ask a search engine to verify that. Implementation complexity is almost as complex as LR(k) (the parsing algorithm is more complex but you do not need to preprocess the grammar). The algorithm is worst-case polynomial in input length: quadratic if the input is unambiguous, cubic if it is ambiguous. This is not a serious issue for small inputs. There are variants that have better worst-case complexities, but these are more complex. Thank you for the very good overview; I wish I had been given something like this in my course on compilers. A parser generator is required for LL and LR variants. The problem with these is that they usually come with their own syntax, so using them requires learning new skills. I think the effort required to acquire these new skills is still less than that of mastering a certain parsing technique and then implementing it. (Just for reference, I think I can remember I once learnt the basics of JavaCC in a day.) On the other hand, you can switch the parsing techniques much easier if you are using parser generators. I'm not sure about the state of parser generators for Python, but this page http://wiki.python.org/moin/LanguageParsing may provide some information. A parser that's embedded into Python as a DSL would be an option. I'm not sure I can properly understand your idea; why do we need to *embed* the DSL into Python? I've checked the link I provided one more time; it lists a number of implementations that look quite appealing, including http://www.acooke.org/lepl/ and http://pypi.python.org/pypi/modgrammar . I can see a different problem here though: choosing a parsing method and producing the grammar of the language (or what information the parser would require) may not be enough to get the desired functionality. What we are trying to get at should incorporate something similar to natural language processing. Therefore, before actually starting the parsing process, I think the input should be brought to some kind of canonical form. I am strongly inclined to believe that Wolfram|Alpha takes exactly this way of doing things (but obviously with a lot more details). The first step to transformation would be a parse, so I'm not really sure what point you're making here. Hm, well, in my imagination the transformations I listed were to be solved by doing find-and-replace, so no, the first step in the transformations I suggested would not be parsing. Maybe lexing, but not parsing. One simple thing I can think of is detecting synonyms. For example, roots x**2 == 1 and solutions x**2 == 1 and solve x**2 == 1 are one and the same thing. Therefore, it may be useful to start with substituting each of these synonyms with some canonical word (solve, for example). This is stuff that is easiest to do *after* a parse.
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 10:22 AM, Aaron Meurer asmeu...@gmail.com wrote: Thanks for the helpful advice. So which method would you recommend using for this? Expression size isn't an issue for SymPy Gamma, by the way, as we are limited by what the App Engine can handle anyway (You'll find that WolframAlpha can't handle very large or even moderately expressions either). Apparently, operator precedence parsing together with some additional processing of the string may be enough. This may be a good start. For more complicated expressions (like limit sin(x)/x when x goes to 0), I think that operator precedence will not be enough. In that case I'd go for a generator of one of the more powerful parsers (LR for example). Sergiu -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Sympy quick guide
On Tue, Mar 13, 2012 at 3:05 PM, Abhiram Ampabathina abhiram.ampabath...@gmail.com wrote: First: https://docs.google.com/file/d/0B8pXy4LH0sF0dmRuTy1rX01SWkc1Y1NUalBvS2RWZw/edit Second: https://docs.google.com/file/d/0B8pXy4LH0sF0VlhPeENDVXVUd2VDck9Kc2VBYWVEZw/edit Third: https://docs.google.com/file/d/0B8pXy4LH0sF0REliUXozeUlUQUswQnNfUU5UUE5uZw/edit I'd rather keep all of these on a single page. In this case the user will not have to click Next two times to get to the list of features. Also, what does Leave this page as flag do? Sergiu -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Multiplication of noncommutative expressions
On 03/13/2012 09:02 AM, Alan Bromborsky wrote:
First a question on noncommutative multiplication. The following code -
from sympy import *
(a1,a2,b1,b2) = symbols('a1 a2 b1 b2')
(e1,e2) = symbols('e1 e2',commutative=False)
x = expand(a1*(e1+e2)*a2*b1*(e1+e2)*b2)
print x
gives -
a1*a2*b1*b2*e1*e2 + a1*a2*b1*b2*e1**2 + a1*a2*b1*b2*e2*e1 +
a1*a2*b1*b2*e2**2
Are the products of the noncommutative symbols always grouped together?
This is important so that if one defines a multiplication table for
the noncommutative symbols a complex product could be evaluated with a
simple
x = x.subs(mul_table)
where the keys of the mul_table dictionary are e1**2, e1*e2, e2*e1,
e2**2. Would e1*e1 work as a key as well as e1**2?
The second question is if one uses a function rather than a table to
calculate the product of noncommuting symbols what class should be
subclassed in order to overload the __mul__() operator? Should it be
the Basic class?
Would this be a good way of implementing a noncommutative product -
from sympy import *
Expr_mul = Expr.__mul__
def mymul(a,b):
if not a.is_commutative and not b.is_commutative:
if isinstance(a,Symbol) and isinstance(b,Symbol):
print 'a =',a,'b =',b
return(Expr_mul(a,b))
else:
return(Expr_mul(a,b))
else:
return(Expr_mul(a,b))
Expr.__mul__ = mymul
(a1,a2,b1,b2) = symbols('a1 a2 b1 b2')
(e1,e2) = symbols('e1 e2',commutative=False)
print expand(a1*(e1+e2)*a2*b1*(e1+e2)*b2)
the output is -
a = e2 b = e2
a = e2 b = e1
a = e1 b = e2
a = e1 b = e1
a1*a2*b1*b2*e1*e2 + a1*a2*b1*b2*e1**2 + a1*a2*b1*b2*e2*e1 +
a1*a2*b1*b2*e2**2
In the real implementation there would be no print statments a and b and
the first instance of Expr_mul(a,b) would be replaced by the actual
function for multiplying noncommutative symbols.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] alternatives to subclassing Expr
09.03.2012 03:05, krastanov.ste...@gmail.com пишет: It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941 Current situation with the flatten, how I imagine it. Correct me If I am mistaken. 1. `flatten` is the method for associative operations `AssocOp`. (a op b) op c == a op (b op c) == a op b op c. `Add` and `Mul` are inherited from AssocOp, which in its turns is inherited from Expr. See picture https://github.com/sympy/sympy/wiki/UD-Core-Docs 2. The original aim for this method was the flatting of the associative operation trees (the 'name-token' about it.): Add( x, Add(y, z)) -- Add(x, y, z) This logic is implemented in AssocOp.flatten 3. Then the commutative and non-commutative symbols was introduced, so the `flatten` return a few lists: commutative, non commutative. (Additionally the `order_symbols` is resulted.) 4. Then the problem was raised how to check an equality of two `Expr` quickly. x + y = y + z This problem was solved with the help of the hashes. Hash of the `Add` is basically hash of the tuple of argument's hashes. hash(Add(x, y)) == hash(Add.args). 5. The problem of the equality 'x + y' and 'y + x' (commutative case), was solved with the aim of so-called `canonical ordering` of arguments. Note, that this sorting is something random and unexpected, because it is simply based on the sorting of python's hashes (and therefore it depends on the machine and bits) Also, there is this comment in code of Add.flatten # order args canonically # Currently we sort things using hashes, as it is quite fast. A better # solution is not to sort things at all - but this needs some more # fixing. NOTE: this is used in primitive, too, so if it changes # here it should be changed there. In PR 722 I successfully remove this sorting. 6. Note, that ordering of the arguments is implemented and for printing system also, independently. (display the objects in a standard sort) Also sorting of terms is used in classes such as polynomials by them own internally. So, the `Canonicalization` is used in a few places and have variouse aims, (And the aim `help with campare objects` of canonicalization encapsulated in flatten, not in the hash calculation, is falsly I think) 7. Also, in the constructors of `Add` and `Mul` (in `flatten` now), there is the so called `simplification-on-the-fly` algorithms. In particular: a) Add.flatten: collect similar terms in (x + 2y + 3x -- 4x + 2y) b) Mul.flatten: convert 1/(x*y) -- x**(-1)*y**(-1) Conclusion: We should document and *split* tasks, aims and implementation for: - flatten - hashing for comparison - canonical sorting (for printing, or polytools) - simplification-on-the-fly - commutative, non-commutative cases problems. If we can split the flatten, then (I think) there are no problems with **It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941** Just polymorph those methods for other objects. Commutativity also means that the order of the final expression can (and should) be canonicalized, so that it's easy to assert that x*y == y*x I think no, we shouldn't. The comparison algorithm must be separated from `flatten` method. It can be implemented with the help of hash calculation function, so it is sufficient to encapsulate the sorting function to the `_hashable_content`. -- Alexey U. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 13.03.2012 15:51, schrieb Sergiu Ivanov: On Tue, Mar 13, 2012 at 6:16 AM, Bharath M Rcatchmrbhar...@gmail.com wrote: Yeah I think I should use some parser generators. But doesn't it introduce a dependency on the parser generator. Is it ok to have this dependency? Usually, you only use the parser generator to produce the code of the parser. This resulting code is technically independent of the parser generator. I'd think such (not that firm) dependency should be OK. Hm... let me phrase it differently: Those parsing methods that are so complicated that you need a parser generator require a different skill set. Which means that we're raising the entry barrier for contributors. Hence, -1. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Maybe this will be useful for the project: http://www.nltk.org/ On Tue, Mar 13, 2012 at 2:55 PM, Joachim Durchholz j...@durchholz.org wrote: Am 13.03.2012 15:51, schrieb Sergiu Ivanov: On Tue, Mar 13, 2012 at 6:16 AM, Bharath M Rcatchmrbhar...@gmail.com wrote: Yeah I think I should use some parser generators. But doesn't it introduce a dependency on the parser generator. Is it ok to have this dependency? Usually, you only use the parser generator to produce the code of the parser. This resulting code is technically independent of the parser generator. I'd think such (not that firm) dependency should be OK. Hm... let me phrase it differently: Those parsing methods that are so complicated that you need a parser generator require a different skill set. Which means that we're raising the entry barrier for contributors. Hence, -1. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- Jorge Eduardo Cardona jorgeecard...@gmail.com jorgeecardona.blogspot.com github.com/jorgeecardona Linux registered user #391186 Registered machine #291871 -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 13.03.2012 17:24, schrieb Sergiu Ivanov: Apparently, operator precedence parsing together with some additional processing of the string may be enough. This may be a good start. For the umteenth time, NO string processing. You'll be going straight to ambiguity hell if you do that - you'll end with a parser that misparses strings just because you weren't careful with the string substitutions. If you want to substitute, do it on the AST. For more complicated expressions (like limit sin(x)/x when x goes to 0), I think that operator precedence will not be enough. In fact this kind of stuff is easy. Just make limit, when, and goes to bind less tightly than operators. What's hard is unary minus. Or anything where you want the same symbol on different precedence levels depending on syntactic context. In that case I'd go for a generator of one of the more powerful parsers (LR for example). Did you ever write a nontrivial LR grammar? Fixing the inevitable shift-reduce conflicts is hard. Really hard. Fixing the conflicts also means changing the grammar. Which means that the grammar will produce parse trees that do not reflect the original grammar anymore. Adding another rule to an LR grammar tends to break it. All over the place. Basically, you need to restart the conflict-fixing process. We'd need an LR grammar expert, or live with the suffering. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] very strange behavior in ImmutableMatrix
This seems very strange. It took much time to debug this problem in a script that I am writing: In [112]: ImmutableMatrix([[1,0,0,0]])*ImmutableMatrix(eye(4)) Out[112]: I In [113]: _.as_explicit() Out[113]: [1] In [114]: Matrix([[1,0,0,0]])*Matrix(eye(4)) Out[114]: [1 0 0 0] -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 13.03.2012 09:22, schrieb Aaron Meurer: Thanks for the helpful advice. So which method would you recommend using for this? Hard to tell right now. We need to see what grammars we want to support. So the first step would probably be to draw up all the grammar rules for features present (and future, as far as we can fathom them). Make that as complete as possible - it's sometimes the innocent rule that will make or break a parsing technique. Unless we're extremely lucky, that initial grammar will not work (except for Earley, which will accept anything). The next round will then be to see what modifications to the grammar are needed to make it acceptable for the various parsing techniques. For the ambiguity checking, any parser generator that uses a specific parsing technique will do. Prefer one with a record of good error messages, we'll need them. Then it's time for the judgement call: Which techniques require what adaptations of the grammar, and which of the adaptations are acceptable and which aren't. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 9:16 PM, Joachim Durchholz j...@durchholz.org wrote: Am 13.03.2012 17:24, schrieb Sergiu Ivanov: Apparently, operator precedence parsing together with some additional processing of the string may be enough. This may be a good start. For the umteenth time, NO string processing. You'll be going straight to ambiguity hell if you do that - you'll end with a parser that misparses strings just because you weren't careful with the string substitutions. If you want to substitute, do it on the AST. Yes, sure. Sorry, didn't think before hitting Send :-( For more complicated expressions (like limit sin(x)/x when x goes to 0), I think that operator precedence will not be enough. In fact this kind of stuff is easy. Just make limit, when, and goes to bind less tightly than operators. What's hard is unary minus. Or anything where you want the same symbol on different precedence levels depending on syntactic context. I see; I did a really poor job thinking over the previous message, sorry. In that case I'd go for a generator of one of the more powerful parsers (LR for example). Did you ever write a nontrivial LR grammar? Fixing the inevitable shift-reduce conflicts is hard. Really hard. Fixing the conflicts also means changing the grammar. Which means that the grammar will produce parse trees that do not reflect the original grammar anymore. Adding another rule to an LR grammar tends to break it. All over the place. Basically, you need to restart the conflict-fixing process. We'd need an LR grammar expert, or live with the suffering. I see. My course on compilers was seriously biased to simple explanations of simple algorithms; my practical experience is the weakest part of my knowledge in this area. Whenever I know that conflicts can be fixed, I rarely bother to see how hard it can to fix them practically. Sergiu -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] very strange behavior in ImmutableMatrix
This is definitely wrong. Can you open an issue for it? Aaron Meurer On Tue, Mar 13, 2012 at 1:16 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: This seems very strange. It took much time to debug this problem in a script that I am writing: In [112]: ImmutableMatrix([[1,0,0,0]])*ImmutableMatrix(eye(4)) Out[112]: I In [113]: _.as_explicit() Out[113]: [1] In [114]: Matrix([[1,0,0,0]])*Matrix(eye(4)) Out[114]: [1 0 0 0] -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 1:46 PM, Joachim Durchholz j...@durchholz.org wrote: Am 13.03.2012 09:22, schrieb Aaron Meurer: Thanks for the helpful advice. So which method would you recommend using for this? Hard to tell right now. We need to see what grammars we want to support. So the first step would probably be to draw up all the grammar rules for features present (and future, as far as we can fathom them). Make that as complete as possible - it's sometimes the innocent rule that will make or break a parsing technique. So would it help to start a wiki page where we list all the things we want to support, in the order of importance? Here's a beginning of that list (in order): - SymPy syntax: This is probably obvious, but correct SymPy/Python syntax should always be parsed exactly as it is given. If the heuristic parser has ambiguities problems that would prevent this, we can just preparse with a call to sympify(), and only use heuristics if that fails. - Mathematica, Maple, Maxima, etc. syntax. Where they conflict, we should pick the more popular variant, or if that's nontrivial, we can just let it decide as a side-effect of the implementation (i.e., leave the behavior undefined in that case). - LaTeX. The ability to parse LaTeX math into something that can be computed would be very useful. WolframAlpha has support for this. - Text based math. What I mean here is, it should support parsing things as you would type them in plain text without trying to follow any kind of set grammar. Stuff like 3x^2 + 2, d/dx x^2. - Special symbols: Support stuff like √x or ∫x^2 dx. Allow, to some degree, pasting in stuff from the SymPy pretty printer (in particular, things that are not printed on more than one line, like 3⋅x₃). - Text based functions: Stuff like integrate x^2 dx, limit x^2 with respect to x as x approaches infinity. - Natural language processing: There is a vagary between this and the last bullet point. What I mean here is that it tries to guess what is meant from a plain text description without using a set grammar. This could even support stuff like the integral of x squared with respect to x. I think we should support at least the first three bullet points. Supporting the last one or two bullet points will be the most difficult, and can be left out, at least in the initial implementation. We should also consider if a scheme will be extendable to such things in the long term. Shall I start a wiki page? I know there have been other things discussed here, like unary minus and bra-ket, that can be problems that are important to consider. Aaron Meurer Unless we're extremely lucky, that initial grammar will not work (except for Earley, which will accept anything). The next round will then be to see what modifications to the grammar are needed to make it acceptable for the various parsing techniques. For the ambiguity checking, any parser generator that uses a specific parsing technique will do. Prefer one with a record of good error messages, we'll need them. Then it's time for the judgement call: Which techniques require what adaptations of the grammar, and which of the adaptations are acceptable and which aren't. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 13.03.2012 17:07, schrieb Sergiu Ivanov: Thank you for the very good overview; I wish I had been given something like this in my course on compilers. You're welcome :-) Some of that knowledge came with bruises. A parser generator is required for LL and LR variants. The problem with these is that they usually come with their own syntax, so using them requires learning new skills. I think the effort required to acquire these new skills is still less than that of mastering a certain parsing technique and then implementing it. (Just for reference, I think I can remember I once learnt the basics of JavaCC in a day.) You learnt the syntax of the tool. The hard part is dealing with conflicts. And to deal with conflicts, you need to have mastered the parsing technique. In the sense of what does it actually do internally. At which point you're already fully equipped to roll your own parser. Of course, writing a parser engine is still more work than using a prewritten one. But it's not THAT much; 500-1000 lines of code could be enough. Besides, there are tons of recipes in the internet - the real challenge would be to decide which one is best for our purposes. On the other hand, you can switch the parsing techniques much easier if you are using parser generators. No, not at all. All parser generators have a different input syntax, different mechanisms to attach semantic actions, etc. That's a decision that cannot be reversed easily. I'm not sure about the state of parser generators for Python, but this page http://wiki.python.org/moin/LanguageParsing may provide some information. A parser that's embedded into Python as a DSL would be an option. I'm not sure I can properly understand your idea; why do we need to *embed* the DSL into Python? Wikipedia: embedded (or internal) domain-specific languages, implemented as libraries which exploit the syntax of their host general purpose language or a subset thereof, while adding domain-specific language elements (data types, routines, methods, macros etc.). That is, have a few functions, and the grammar becomes a set of function calls that will contain the grammar, or generate the data to drive the parser engine. I've checked the link I provided one more time; it lists a number of implementations that look quite appealing, including http://www.acooke.org/lepl/ - Recursive descent cannot (usually) handle infix operators. + Parsers are Python code, defined in Python itself. (i.e. it is an embedded DSL.) and http://pypi.python.org/pypi/modgrammar - Cannot handle left recursion (BLOCKER) Right-associative operators need left recursion. How so? I can't see how it is hard to replace (roots or solutions) with solve before parsing. Oh. So you'd replace rootset with solveet. It's easier to build alternate definitions into the semantic processing that happens after the parse. Hm, I think I can see your point now. It is indeed more correct to process alternate definitions into the after-parse semantic processing. However, I'm not sure the resulting code is going to be simpler. If you parse things, you need a place to link up a subtree with some semantics. Providing alternate syntaxes for the same semantics just means you have to assign the same semantics to some different kinds of subtrees. You just reuse the existing semantic object (callable, class, whatever). Maybe with a small adapter if the semantic object assumes a specific structure in the tree (most parser toolkits abstract away even from that). Having a larger grammar isn't so much a maintenance problem either if each rule follows a pattern from a small set of standard patterns. I think I don't understand this. Could you please give more details? It's no problem if you have a+b, a-b, a*b, a^b, ab, etc. etc. It *is* a problem if you have a-b, a*b, and -a, and want -a to bind tighter than a*b. It is not a problem to have a gazillion of control structures like while...end, switch, etc. It *is* a problem if you have if...then...else... (without a closing endif). Google for dangling else. Spell checking, again, is something that is easily done on the parse tree after it has been created. I'm not sure I agree. Consider the (supposedly valid) sentences integrate sin(x) by x and limit sin(x) when x goes to zero. I don't think I'd recommend parsing these two sentences with one (general) rule, which means that the words integrate and limit actually determine which of the rules to use. If spell checking doesn't happen before lexing, the necessary difference between integrate and limit may not be detected. Where does spell checking factor in here? The preprocessor could also drop incomprehensible (and thus supposedly meaningless) words, like in find the integral of x^2. Experience with this kind of approach was that it tends to reduce predictability. In this case, the user might consider a word meaningless but the program has some
Re: [sympy] alternatives to subclassing Expr
Am 13.03.2012 09:57, schrieb Aaron Meurer: One problem is that it's not really a Matrix. Classes like Mul and Add are container objects that can hold any number of items. Heh. That would be an infinitely-dimensional hypercube. I hadn't expected to see that in my career :-) If we want to assert commutativity and associativity (the latter is actually implied by the n-ary-ness of the container), we must define operations on any combination. Urk. In practice, this isn't an issue because rules can be generalized. Exactly - that's conversion, not multiple dispatch. I know of three techniques to deal with varying parameter values: - Multiple dispatch. Most general, not independently extensible. - Conversion to the most general common type, along a hierarchy. Independently extensible. Less flexible than MD: you cannot (easily) special-case a specific type combination. - Overloading. Requires explicit definition of each combination. Restricted to static types (i.e. useless for dynamic languages which don't have static types anyway). -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] alternatives to subclassing Expr
On Tue, Mar 13, 2012 at 11:01 AM, Alexey U. Gudchenko pr...@goodok.ru wrote: 09.03.2012 03:05, krastanov.ste...@gmail.com пишет: It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941 Current situation with the flatten, how I imagine it. Correct me If I am mistaken. 1. `flatten` is the method for associative operations `AssocOp`. (a op b) op c == a op (b op c) == a op b op c. `Add` and `Mul` are inherited from AssocOp, which in its turns is inherited from Expr. See picture https://github.com/sympy/sympy/wiki/UD-Core-Docs 2. The original aim for this method was the flatting of the associative operation trees (the 'name-token' about it.): Add( x, Add(y, z)) -- Add(x, y, z) This logic is implemented in AssocOp.flatten 3. Then the commutative and non-commutative symbols was introduced, so the `flatten` return a few lists: commutative, non commutative. (Additionally the `order_symbols` is resulted.) 4. Then the problem was raised how to check an equality of two `Expr` quickly. x + y = y + z This problem was solved with the help of the hashes. Hash of the `Add` is basically hash of the tuple of argument's hashes. hash(Add(x, y)) == hash(Add.args). 5. The problem of the equality 'x + y' and 'y + x' (commutative case), was solved with the aim of so-called `canonical ordering` of arguments. Note, that this sorting is something random and unexpected, because it is simply based on the sorting of python's hashes (and therefore it depends on the machine and bits) Also, there is this comment in code of Add.flatten # order args canonically # Currently we sort things using hashes, as it is quite fast. A better # solution is not to sort things at all - but this needs some more # fixing. NOTE: this is used in primitive, too, so if it changes # here it should be changed there. In PR 722 I successfully remove this sorting. 6. Note, that ordering of the arguments is implemented and for printing system also, independently. (display the objects in a standard sort) Also sorting of terms is used in classes such as polynomials by them own internally. So, the `Canonicalization` is used in a few places and have variouse aims, (And the aim `help with campare objects` of canonicalization encapsulated in flatten, not in the hash calculation, is falsly I think) 7. Also, in the constructors of `Add` and `Mul` (in `flatten` now), there is the so called `simplification-on-the-fly` algorithms. In particular: a) Add.flatten: collect similar terms in (x + 2y + 3x -- 4x + 2y) b) Mul.flatten: convert 1/(x*y) -- x**(-1)*y**(-1) Conclusion: We should document and *split* tasks, aims and implementation for: - flatten - hashing for comparison - canonical sorting (for printing, or polytools) - simplification-on-the-fly - commutative, non-commutative cases problems. If we can split the flatten, then (I think) there are no problems with **It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941** Just polymorph those methods for other objects. Commutativity also means that the order of the final expression can (and should) be canonicalized, so that it's easy to assert that x*y == y*x I think no, we shouldn't. The comparison algorithm must be separated from `flatten` method. I think maybe a problem is that some code assumes that a == b implies that a.args == b.args. We'd have to try it and run the tests to see how ingrained this is (but I seem to remember removing the ordering from Add, and a *ton* of tests failed, but that may have just been because I failed to correctly redefine __eq__). But it would be interesting if we could do something like x*y and y*x and keep the order, but still have them compare equal. Then, we could make the printer give things in exactly the order they were entered, for example. Aaron Meurer It can be implemented with the help of hash calculation function, so it is sufficient to encapsulate the sorting function to the `_hashable_content`. -- Alexey U. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] very strange behavior in ImmutableMatrix
http://code.google.com/p/sympy/issues/detail?id=3143 cc-ed to Mat Rocklin just in case, as he has most knowledge of this particular code-path. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] alternatives to subclassing Expr
How interdependent are __eq__ and __hash__ in sympy? On 13 March 2012 21:27, Aaron Meurer asmeu...@gmail.com wrote: On Tue, Mar 13, 2012 at 11:01 AM, Alexey U. Gudchenko pr...@goodok.ru wrote: 09.03.2012 03:05, krastanov.ste...@gmail.com пишет: It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941 Current situation with the flatten, how I imagine it. Correct me If I am mistaken. 1. `flatten` is the method for associative operations `AssocOp`. (a op b) op c == a op (b op c) == a op b op c. `Add` and `Mul` are inherited from AssocOp, which in its turns is inherited from Expr. See picture https://github.com/sympy/sympy/wiki/UD-Core-Docs 2. The original aim for this method was the flatting of the associative operation trees (the 'name-token' about it.): Add( x, Add(y, z)) -- Add(x, y, z) This logic is implemented in AssocOp.flatten 3. Then the commutative and non-commutative symbols was introduced, so the `flatten` return a few lists: commutative, non commutative. (Additionally the `order_symbols` is resulted.) 4. Then the problem was raised how to check an equality of two `Expr` quickly. x + y = y + z This problem was solved with the help of the hashes. Hash of the `Add` is basically hash of the tuple of argument's hashes. hash(Add(x, y)) == hash(Add.args). 5. The problem of the equality 'x + y' and 'y + x' (commutative case), was solved with the aim of so-called `canonical ordering` of arguments. Note, that this sorting is something random and unexpected, because it is simply based on the sorting of python's hashes (and therefore it depends on the machine and bits) Also, there is this comment in code of Add.flatten # order args canonically # Currently we sort things using hashes, as it is quite fast. A better # solution is not to sort things at all - but this needs some more # fixing. NOTE: this is used in primitive, too, so if it changes # here it should be changed there. In PR 722 I successfully remove this sorting. 6. Note, that ordering of the arguments is implemented and for printing system also, independently. (display the objects in a standard sort) Also sorting of terms is used in classes such as polynomials by them own internally. So, the `Canonicalization` is used in a few places and have variouse aims, (And the aim `help with campare objects` of canonicalization encapsulated in flatten, not in the hash calculation, is falsly I think) 7. Also, in the constructors of `Add` and `Mul` (in `flatten` now), there is the so called `simplification-on-the-fly` algorithms. In particular: a) Add.flatten: collect similar terms in (x + 2y + 3x -- 4x + 2y) b) Mul.flatten: convert 1/(x*y) -- x**(-1)*y**(-1) Conclusion: We should document and *split* tasks, aims and implementation for: - flatten - hashing for comparison - canonical sorting (for printing, or polytools) - simplification-on-the-fly - commutative, non-commutative cases problems. If we can split the flatten, then (I think) there are no problems with **It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941** Just polymorph those methods for other objects. Commutativity also means that the order of the final expression can (and should) be canonicalized, so that it's easy to assert that x*y == y*x I think no, we shouldn't. The comparison algorithm must be separated from `flatten` method. I think maybe a problem is that some code assumes that a == b implies that a.args == b.args. We'd have to try it and run the tests to see how ingrained this is (but I seem to remember removing the ordering from Add, and a *ton* of tests failed, but that may have just been because I failed to correctly redefine __eq__). But it would be interesting if we could do something like x*y and y*x and keep the order, but still have them compare equal. Then, we could make the printer give things in exactly the order they were entered, for example. Aaron Meurer It can be implemented with the help of hash calculation function, so it is sufficient to encapsulate the sorting function to the `_hashable_content`. -- Alexey U. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at
Re: [sympy] alternatives to subclassing Expr
14.03.2012 00:27, Aaron Meurer пишет: On Tue, Mar 13, 2012 at 11:01 AM, Alexey U. Gudchenko pr...@goodok.ru wrote: 09.03.2012 03:05, krastanov.ste...@gmail.com пишет: It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941 Current situation with the flatten, how I imagine it. Correct me If I am mistaken. 1. `flatten` is the method for associative operations `AssocOp`. (a op b) op c == a op (b op c) == a op b op c. `Add` and `Mul` are inherited from AssocOp, which in its turns is inherited from Expr. See picture https://github.com/sympy/sympy/wiki/UD-Core-Docs 2. The original aim for this method was the flatting of the associative operation trees (the 'name-token' about it.): Add( x, Add(y, z)) -- Add(x, y, z) This logic is implemented in AssocOp.flatten 3. Then the commutative and non-commutative symbols was introduced, so the `flatten` return a few lists: commutative, non commutative. (Additionally the `order_symbols` is resulted.) 4. Then the problem was raised how to check an equality of two `Expr` quickly. x + y = y + z This problem was solved with the help of the hashes. Hash of the `Add` is basically hash of the tuple of argument's hashes. hash(Add(x, y)) == hash(Add.args). 5. The problem of the equality 'x + y' and 'y + x' (commutative case), was solved with the aim of so-called `canonical ordering` of arguments. Note, that this sorting is something random and unexpected, because it is simply based on the sorting of python's hashes (and therefore it depends on the machine and bits) Also, there is this comment in code of Add.flatten # order args canonically # Currently we sort things using hashes, as it is quite fast. A better # solution is not to sort things at all - but this needs some more # fixing. NOTE: this is used in primitive, too, so if it changes # here it should be changed there. In PR 722 I successfully remove this sorting. 6. Note, that ordering of the arguments is implemented and for printing system also, independently. (display the objects in a standard sort) Also sorting of terms is used in classes such as polynomials by them own internally. So, the `Canonicalization` is used in a few places and have variouse aims, (And the aim `help with campare objects` of canonicalization encapsulated in flatten, not in the hash calculation, is falsly I think) 7. Also, in the constructors of `Add` and `Mul` (in `flatten` now), there is the so called `simplification-on-the-fly` algorithms. In particular: a) Add.flatten: collect similar terms in (x + 2y + 3x -- 4x + 2y) b) Mul.flatten: convert 1/(x*y) -- x**(-1)*y**(-1) Conclusion: We should document and *split* tasks, aims and implementation for: - flatten - hashing for comparison - canonical sorting (for printing, or polytools) - simplification-on-the-fly - commutative, non-commutative cases problems. If we can split the flatten, then (I think) there are no problems with **It seems that this is not sustainable because 1. Adding too much stuff to Mul and Add https://code.google.com/p/sympy/issues/detail?id=1941** Just polymorph those methods for other objects. Commutativity also means that the order of the final expression can (and should) be canonicalized, so that it's easy to assert that x*y == y*x I think no, we shouldn't. The comparison algorithm must be separated from `flatten` method. I think maybe a problem is that some code assumes that a == b implies that a.args == b.args. We'd have to try it and run the tests to see how ingrained this is (but I seem to remember removing the ordering from Add, and a *ton* of tests failed, but that may have just been because I failed to correctly redefine __eq__). I tried to remove the ordering in PR 722 (rebased it today) Without redefining __eq__, but with changes in hashable_content, and remove some another random reordering. Change some tests to be valid. For 64-bit (python 2.7.2, 2.5.5, 3.2.2 they all ok. http://reviews.sympy.org/pullrequest/722 but on 32-bit I meet two fails, which I investigate now. -- Alexey U. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Interested In Implementing Integration Algorithm so that sympy can Integrate anything that is Integrable
How can you do anything useful with it if you don't have a detailed idea about how the Risch algorithm works? What you should do next is find out something (on your own or use the issues page) that is broken, fix it and send a patch. The community will then review the patch and provide you feedback that you can then act upon. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
Am 13.03.2012 21:17, schrieb Aaron Meurer: So would it help to start a wiki page where we list all the things we want to support, in the order of importance? Here's a beginning of that list (in order): - SymPy syntax: This is probably obvious, but correct SymPy/Python syntax should always be parsed exactly as it is given. If the heuristic parser has ambiguities problems that would prevent this, we can just preparse with a call to sympify(), and only use heuristics if that fails. - Mathematica, Maple, Maxima, etc. syntax. Where they conflict, we should pick the more popular variant, or if that's nontrivial, we can just let it decide as a side-effect of the implementation (i.e., leave the behavior undefined in that case). - LaTeX. The ability to parse LaTeX math into something that can be computed would be very useful. WolframAlpha has support for this. It's almost guaranteed that combining syntaxes from different sources gives an ambiguous grammar. The only technique that can deal with that would those in the succession of the Earley parser. I see that http://en.wikipedia.org/wiki/Earley_parser lists four different Python implementations, one of them just 150 lines. - Text based math. What I mean here is, it should support parsing things as you would type them in plain text without trying to follow any kind of set grammar. Stuff like 3x^2 + 2, d/dx x^2. That's really hard to do well. Most of the time, the users's guess of the parser's guess will be quite different than the actuall guess of the parser. - Special symbols: Support stuff like √x or ∫x^2 dx. Allow, to some degree, pasting in stuff from the SymPy pretty printer (in particular, things that are not printed on more than one line, like 3⋅x₃). That's simple. Just plop in the appropriate grammar rules. Make √ a prefix operator, ∫...dx a circumfix one. ₃ would probably have to be lexed as sub3endsub, where sub and endsub are synthetic lexer symbols. - Text based functions: Stuff like integrate x^2 dx, limit x^2 with respect to x as x approaches infinity. - Natural language processing: There is a vagary between this and the last bullet point. What I mean here is that it tries to guess what is meant from a plain text description without using a set grammar. This could even support stuff like the integral of x squared with respect to x. The same caveat as with text-based math apply. Shall I start a wiki page? I know there have been other things discussed here, like unary minus and bra-ket, that can be problems that are important to consider. I see two things that need a decision: 1) Whether supporting such a wide array of syntaxes is such an important goal. If yes, Earley parsing it is. If no, it would be defining our own syntax, possibly similar to existing symbolic math languages, but still a separate syntax. From user's perspective, the consequence of an Earley parser would be that an additional error mode: the input text might have multiple valid parses. (How to best present that to the user might be one or more GSoC projects.) The consequence of a non-Earley parser, regardless of technology, would be that we'd have to drastically cut down on the allowed syntax. Essentially, we'd have to resolve all potential syntactic ambiguities when writing the grammar. I think this decision does not benefit from a Wiki. 2) Which grammar rules to support. This is a bit tedious: look up what the various syntaxes have, write it down. A wiki page would be useful for that. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Sympy.physics.Quantum: GSoC 2012
Hello, While going through Ideas List. Some of those ideas caught my attention.And a few of them were really encouraging and motivational. The idea of Implementing All known Analytical Solutions to Quantum Mechanical Systems is really interesting because of its diverse use and benefits to the community. This can be used in most of the universities and colleges to help students learn Quantum Mechanics effectively. Freshers and sophomores are generally taught simple Quantum systems like 1-D(finite, infinite well,Oscillator), Simple harmonic Oscillator , Dirac functions , 3-D oscillator, hydrogen atoms,Rigid rotors and similar things.So i think it is good idea and i want to pursue this idea for my GSoC project this summer. However i would like to get your inputs about the idea? Is this project big enough for a whole summer ? Is it prioritized among other ideas? Whom to contact to discuss more about this topic and submitting a patch about it? Thanks, Rhythm Gupta. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] very strange behavior in ImmutableMatrix
Issued a pull request to resolve this. https://github.com/sympy/sympy/pull/1120 The matrix [[1,0,0,0]] was falsely being identified as an Identity matrix. On Tue, Mar 13, 2012 at 1:29 PM, krastanov.ste...@gmail.com krastanov.ste...@gmail.com wrote: http://code.google.com/p/sympy/issues/detail?id=3143 cc-ed to Mat Rocklin just in case, as he has most knowledge of this particular code-path. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] feedback for GSOC 2012 idea
On Tue, Mar 13, 2012 at 2:58 PM, Joachim Durchholz j...@durchholz.org wrote: Am 13.03.2012 21:17, schrieb Aaron Meurer: So would it help to start a wiki page where we list all the things we want to support, in the order of importance? Here's a beginning of that list (in order): - SymPy syntax: This is probably obvious, but correct SymPy/Python syntax should always be parsed exactly as it is given. If the heuristic parser has ambiguities problems that would prevent this, we can just preparse with a call to sympify(), and only use heuristics if that fails. - Mathematica, Maple, Maxima, etc. syntax. Where they conflict, we should pick the more popular variant, or if that's nontrivial, we can just let it decide as a side-effect of the implementation (i.e., leave the behavior undefined in that case). - LaTeX. The ability to parse LaTeX math into something that can be computed would be very useful. WolframAlpha has support for this. It's almost guaranteed that combining syntaxes from different sources gives an ambiguous grammar. The only technique that can deal with that would those in the succession of the Earley parser. I see that http://en.wikipedia.org/wiki/Earley_parser lists four different Python implementations, one of them just 150 lines. Just about all of them are relatively short. I suppose it wouldn't be hard, then, to just implement this from scratch. - Text based math. What I mean here is, it should support parsing things as you would type them in plain text without trying to follow any kind of set grammar. Stuff like 3x^2 + 2, d/dx x^2. That's really hard to do well. Most of the time, the users's guess of the parser's guess will be quite different than the actuall guess of the parser. - Special symbols: Support stuff like √x or ∫x^2 dx. Allow, to some degree, pasting in stuff from the SymPy pretty printer (in particular, things that are not printed on more than one line, like 3⋅x₃). That's simple. Just plop in the appropriate grammar rules. Make √ a prefix operator, ∫...dx a circumfix one. ₃ would probably have to be lexed as sub3endsub, where sub and endsub are synthetic lexer symbols. Or preparse and replace ∫ with integrate and so on. Subscripts have no syntactical meaning, so those should actually just be considered part of the Symbol name (maybe translated from ₃ to _3). - Text based functions: Stuff like integrate x^2 dx, limit x^2 with respect to x as x approaches infinity. - Natural language processing: There is a vagary between this and the last bullet point. What I mean here is that it tries to guess what is meant from a plain text description without using a set grammar. This could even support stuff like the integral of x squared with respect to x. The same caveat as with text-based math apply. Shall I start a wiki page? I know there have been other things discussed here, like unary minus and bra-ket, that can be problems that are important to consider. I see two things that need a decision: 1) Whether supporting such a wide array of syntaxes is such an important goal. If yes, Earley parsing it is. If no, it would be defining our own syntax, possibly similar to existing symbolic math languages, but still a separate syntax. From user's perspective, the consequence of an Earley parser would be that an additional error mode: the input text might have multiple valid parses. (How to best present that to the user might be one or more GSoC projects.) The consequence of a non-Earley parser, regardless of technology, would be that we'd have to drastically cut down on the allowed syntax. Essentially, we'd have to resolve all potential syntactic ambiguities when writing the grammar. I think this decision does not benefit from a Wiki. If you put the information you put in the earlier post together on a wiki, and format it so it's nice and readable, it can make things easier to go through than trying to read through this thread again. 2) Which grammar rules to support. This is a bit tedious: look up what the various syntaxes have, write it down. A wiki page would be useful for that. OK, I started https://github.com/sympy/sympy/wiki/parsing. I included what I said above, and also your bit about the different parsers. Feel free to edit that page however you want. Aaron Meurer -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Newbie question
Hello,
I'm new to sympy so please excuse me if this question is obvious to
the experienced.
In multibody kinematics there is a classic relationship between a
rotating body's angular velocity and the rotation matrices
representing the configuration at a given point in time. Basically, if
I am using a roll/pitch/yaw representation of the rotation then I have
three rotation matrices that comprise the full instantaneous rotation,
R = rotx(gamma) * roty(beta) * rotz(alpha)
Meaning, if I rotate the body by 'alpha' about a body fixed 'Z' axis,
followed by a rotation 'beta' about the once rotated body fixed 'Y'
axis, followed by a rotation 'gamma' about the twice rotated body
fixed 'X' axis... I now have a complete instantaneous rotation matrix
R.
The relationship of the angular velocity of the body is,
skew(w) = Rdot * R.transpose
so, a new skew symmetric matrix is created from the matrix product
between the time derivative of R and the transpose of R. (Since alpha,
beta, and gamma are all functions of time then R is a function of
time.)
Completing the above described equations in Mathematica does in fact
give me a skew-symmetric matrix. However, my first attempt in SYMPY
did not produce a skew-symmetric matrix. So, I'm including the code
below and asking the group if there is a simple newbie user error I
may have performed causing the problem. Or, is this simply a
limitation of SYMPY? By the way, TRIGSIMP() did not help...
snip
from sympy import *
t = Symbol('t')
a = Symbol('a')
b = Symbol('b')
g = Symbol('g')
rotX = Matrix([ [1, 0, 0],
[0, cos(g(t)), sin(g(t))],
[0, -sin(g(t)), cos(g(t))] ])
rotY = Matrix([ [cos(b(t)), 0, -sin(b(t))],
[0, 1, 0],
[sin(b(t)), 0, cos(b(t))] ])
rotZ = Matrix([ [cos(a(t)), sin(a(t)), 0],
[-sin(a(t)), cos(a(t)), 0],
[0, 0, 1] ])
R = rotX * rotY * rotZ
Rdot = R.diff(t)
skew = Rdot * R.T
print ''
print 'skew = '
print skew
# 'skew' should result in a skew-symmetic matrix.
# or, of the form,
# [[ 0, -w_z, w_y ],
# [ w_z, 0,-w_x],
# [-w_y, w_x, 0] ]
#
# where w = [w_x, w_y, w_z]^T
#
# looks like SYMPY fails to produce this results, yet, this same code
in
# Mathematica works as expected...
#
# is this a result of a newbie mistake? Or, a limitation of sympy?
print ''
print 'trigsimp(skew[0,0]) = '
print trigsimp(skew[0,0])
/snip
Thanks in advance!
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Newbie question
Unfortunately, this is a limitation in SymPy right now, which is that
our trigonometric simplification is not very good.
For now, you can use a work-around suggested in another thread:
def mytrigsimp(expr):
expr = expr.rewrite(exp)
expr = expr.expand()
expr = expr.rewrite(cos)
expr = expr.expand()
return expr
and do skew.applyfunc(mytrigsimp). This works by rewriting the trig
functions in terms of complex exponentials, expanding, rewriting them
back as trig functions, and expanding again. In your case, it
simplifies nicely:
In [32]: def mytrigsimp(expr):
: expr = expr.rewrite(exp)
: expr = expr.expand()
: expr = expr.rewrite(cos)
: expr = expr.expand()
: return expr
:
In [33]: print skew.applyfunc(mytrigsimp)
[
0, -sin(g(t))*Derivative(b(t), t) +
cos(b(t))*cos(g(t))*Derivative(a(t), t),
-sin(g(t))*cos(b(t))*Derivative(a(t), t) - cos(g(t))*Derivative(b(t),
t)]
[sin(g(t))*Derivative(b(t), t) - cos(b(t))*cos(g(t))*Derivative(a(t),
t),
0, -sin(b(t))*Derivative(a(t), t) +
Derivative(g(t), t)]
[sin(g(t))*cos(b(t))*Derivative(a(t), t) + cos(g(t))*Derivative(b(t),
t), sin(b(t))*Derivative(a(t), t) -
Derivative(g(t), t),
0]
Aaron Meurer
On Tue, Mar 13, 2012 at 8:13 PM, Southern.Cross hays@gmail.com wrote:
Hello,
I'm new to sympy so please excuse me if this question is obvious to
the experienced.
In multibody kinematics there is a classic relationship between a
rotating body's angular velocity and the rotation matrices
representing the configuration at a given point in time. Basically, if
I am using a roll/pitch/yaw representation of the rotation then I have
three rotation matrices that comprise the full instantaneous rotation,
R = rotx(gamma) * roty(beta) * rotz(alpha)
Meaning, if I rotate the body by 'alpha' about a body fixed 'Z' axis,
followed by a rotation 'beta' about the once rotated body fixed 'Y'
axis, followed by a rotation 'gamma' about the twice rotated body
fixed 'X' axis... I now have a complete instantaneous rotation matrix
R.
The relationship of the angular velocity of the body is,
skew(w) = Rdot * R.transpose
so, a new skew symmetric matrix is created from the matrix product
between the time derivative of R and the transpose of R. (Since alpha,
beta, and gamma are all functions of time then R is a function of
time.)
Completing the above described equations in Mathematica does in fact
give me a skew-symmetric matrix. However, my first attempt in SYMPY
did not produce a skew-symmetric matrix. So, I'm including the code
below and asking the group if there is a simple newbie user error I
may have performed causing the problem. Or, is this simply a
limitation of SYMPY? By the way, TRIGSIMP() did not help...
snip
from sympy import *
t = Symbol('t')
a = Symbol('a')
b = Symbol('b')
g = Symbol('g')
rotX = Matrix([ [1, 0, 0],
[0, cos(g(t)), sin(g(t))],
[0, -sin(g(t)), cos(g(t))] ])
rotY = Matrix([ [cos(b(t)), 0, -sin(b(t))],
[0, 1, 0],
[sin(b(t)), 0, cos(b(t))] ])
rotZ = Matrix([ [cos(a(t)), sin(a(t)), 0],
[-sin(a(t)), cos(a(t)), 0],
[0, 0, 1] ])
R = rotX * rotY * rotZ
Rdot = R.diff(t)
skew = Rdot * R.T
print ''
print 'skew = '
print skew
# 'skew' should result in a skew-symmetic matrix.
# or, of the form,
# [[ 0, -w_z, w_y ],
# [ w_z, 0, -w_x],
# [-w_y, w_x, 0] ]
#
# where w = [w_x, w_y, w_z]^T
#
# looks like SYMPY fails to produce this results, yet, this same code
in
# Mathematica works as expected...
#
# is this a result of a newbie mistake? Or, a limitation of sympy?
print ''
print 'trigsimp(skew[0,0]) = '
print trigsimp(skew[0,0])
/snip
Thanks in advance!
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Newbie question
Great! I'll try this out. Thanks for the work around.
Joe
On Mar 13, 10:31 pm, Aaron Meurer asmeu...@gmail.com wrote:
Unfortunately, this is a limitation in SymPy right now, which is that
our trigonometric simplification is not very good.
For now, you can use a work-around suggested in another thread:
def mytrigsimp(expr):
expr = expr.rewrite(exp)
expr = expr.expand()
expr = expr.rewrite(cos)
expr = expr.expand()
return expr
and do skew.applyfunc(mytrigsimp). This works by rewriting the trig
functions in terms of complex exponentials, expanding, rewriting them
back as trig functions, and expanding again. In your case, it
simplifies nicely:
In [32]: def mytrigsimp(expr):
: expr = expr.rewrite(exp)
: expr = expr.expand()
: expr = expr.rewrite(cos)
: expr = expr.expand()
: return expr
:
In [33]: print skew.applyfunc(mytrigsimp)
[
0, -sin(g(t))*Derivative(b(t), t) +
cos(b(t))*cos(g(t))*Derivative(a(t), t),
-sin(g(t))*cos(b(t))*Derivative(a(t), t) - cos(g(t))*Derivative(b(t),
t)]
[sin(g(t))*Derivative(b(t), t) - cos(b(t))*cos(g(t))*Derivative(a(t),
t),
0, -sin(b(t))*Derivative(a(t), t) +
Derivative(g(t), t)]
[sin(g(t))*cos(b(t))*Derivative(a(t), t) + cos(g(t))*Derivative(b(t),
t), sin(b(t))*Derivative(a(t), t) -
Derivative(g(t), t),
0]
Aaron Meurer
On Tue, Mar 13, 2012 at 8:13 PM, Southern.Cross hays@gmail.com wrote:
Hello,
I'm new to sympy so please excuse me if this question is obvious to
the experienced.
In multibody kinematics there is a classic relationship between a
rotating body's angular velocity and the rotation matrices
representing the configuration at a given point in time. Basically, if
I am using a roll/pitch/yaw representation of the rotation then I have
three rotation matrices that comprise the full instantaneous rotation,
R = rotx(gamma) * roty(beta) * rotz(alpha)
Meaning, if I rotate the body by 'alpha' about a body fixed 'Z' axis,
followed by a rotation 'beta' about the once rotated body fixed 'Y'
axis, followed by a rotation 'gamma' about the twice rotated body
fixed 'X' axis... I now have a complete instantaneous rotation matrix
R.
The relationship of the angular velocity of the body is,
skew(w) = Rdot * R.transpose
so, a new skew symmetric matrix is created from the matrix product
between the time derivative of R and the transpose of R. (Since alpha,
beta, and gamma are all functions of time then R is a function of
time.)
Completing the above described equations in Mathematica does in fact
give me a skew-symmetric matrix. However, my first attempt in SYMPY
did not produce a skew-symmetric matrix. So, I'm including the code
below and asking the group if there is a simple newbie user error I
may have performed causing the problem. Or, is this simply a
limitation of SYMPY? By the way, TRIGSIMP() did not help...
snip
from sympy import *
t = Symbol('t')
a = Symbol('a')
b = Symbol('b')
g = Symbol('g')
rotX = Matrix([ [1, 0, 0],
[0, cos(g(t)), sin(g(t))],
[0, -sin(g(t)), cos(g(t))] ])
rotY = Matrix([ [cos(b(t)), 0, -sin(b(t))],
[0, 1, 0],
[sin(b(t)), 0, cos(b(t))] ])
rotZ = Matrix([ [cos(a(t)), sin(a(t)), 0],
[-sin(a(t)), cos(a(t)), 0],
[0, 0, 1] ])
R = rotX * rotY * rotZ
Rdot = R.diff(t)
skew = Rdot * R.T
print ''
print 'skew = '
print skew
# 'skew' should result in a skew-symmetic matrix.
# or, of the form,
# [[ 0, -w_z, w_y ],
# [ w_z, 0, -w_x],
# [-w_y, w_x, 0] ]
#
# where w = [w_x, w_y, w_z]^T
#
# looks like SYMPY fails to produce this results, yet, this same code
in
# Mathematica works as expected...
#
# is this a result of a newbie mistake? Or, a limitation of sympy?
print ''
print 'trigsimp(skew[0,0]) = '
print trigsimp(skew[0,0])
/snip
Thanks in advance!
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Sympy.physics.Quantum: GSoC 2012
Hi Rhythm, It is great that you're interested in doing a project in the quantum module. For the project you mentioned, there is definitely a summers worth of systems to be implemented, especially if there are systems which would require some new quantum machinery. To see what I mean by that, note the difference between physics.hydrogen and physics.quantum.piab, where the particle in a box wavefunctions utilize some of the tools built into the quantum module (tho I think more could still be done using Wavefunctions, as defined in physics.quantum.state). To get enough systems to fill out a GSoC, you will probably need to have quantum mechanics proficiency at least at an upper division level, out of a text comparable to Griffiths, but that mainly comes down to if you can come up with a rough set of systems to implement and what new tools, if any, you'd need to complete the task. For fleshing out a project, this email list is probably your best resource for questions. I could give you some pointers on navigating the quantum module and help you find the things you should be looking at when drafting a project, but there are other developers with more experience both with framing GSoC projects and with the quantum module. Sean On Tue, Mar 13, 2012 at 16:12, Rhythm Gupta rhythm.gupt...@gmail.comwrote: Hello, While going through Ideas List. Some of those ideas caught my attention.And a few of them were really encouraging and motivational. The idea of Implementing All known Analytical Solutions to Quantum Mechanical Systems is really interesting because of its diverse use and benefits to the community. This can be used in most of the universities and colleges to help students learn Quantum Mechanics effectively. Freshers and sophomores are generally taught simple Quantum systems like 1-D(finite, infinite well,Oscillator), Simple harmonic Oscillator , Dirac functions , 3-D oscillator, hydrogen atoms,Rigid rotors and similar things.So i think it is good idea and i want to pursue this idea for my GSoC project this summer. However i would like to get your inputs about the idea? Is this project big enough for a whole summer ? Is it prioritized among other ideas? Whom to contact to discuss more about this topic and submitting a patch about it? Thanks, Rhythm Gupta. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
