Comment #2 on issue 1913 by smi...@gmail.com: pseudo integralof x
http://code.google.com/p/sympy/issues/detail?id=1913
pokya needs to use free_symbols so this doesn't fail:
Poly(x+Integral(x**x, (x, 1, y)) ,x)
Traceback (most recent call last):
File stdin, line 1, in module
Updates:
Status: Fixed
Comment #3 on issue 2061 by smi...@gmail.com: sqrt(-1.0*x) gives infinite
recursion
http://code.google.com/p/sympy/issues/detail?id=2061
sqrt(-1.*x)
1.0*I*x**(1/2)
--
You received this message because you are subscribed to the Google Groups
Updates:
Status: Fixed
Comment #3 on issue 2053 by smi...@gmail.com: 2053 geometry upgrade
http://code.google.com/p/sympy/issues/detail?id=2053
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To
Comment #1 on issue 2038 by smi...@gmail.com: powsimp breaks power rules
http://code.google.com/p/sympy/issues/detail?id=2038
This is automatic now:
(x**(2*y))**3
x**(6*y)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to
Updates:
Status: Fixed
Comment #2 on issue 2038 by smi...@gmail.com: powsimp breaks power rules
http://code.google.com/p/sympy/issues/detail?id=2038
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues
Updates:
Status: WontFix
Comment #1 on issue 1962 by smi...@gmail.com: pprint form of geometric
objects mimics regular python objects
http://code.google.com/p/sympy/issues/detail?id=1962
(No comment was entered for this change.)
--
You received this message because you are
Comment #3 on issue 1913 by smi...@gmail.com: pseudo integralof x
http://code.google.com/p/sympy/issues/detail?id=1913
polys (not pokya)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to this group, send email to
Comment #6 on issue 1835 by smi...@gmail.com: 1835: coeff changes
http://code.google.com/p/sympy/issues/detail?id=1835
This is in without the exact keyword functionality. A pull removing this
keyword is forthcoming.
--
You received this message because you are subscribed to the Google
Updates:
Status: Fixed
Comment #7 on issue 1835 by smi...@gmail.com: 1835: coeff changes
http://code.google.com/p/sympy/issues/detail?id=1835
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To
Updates:
Status: Fixed
Comment #2 on issue 1821 by smi...@gmail.com: more simplification could be
done on rationals raised to rationals
http://code.google.com/p/sympy/issues/detail?id=1821
powers are now more canonical
S('8**(1/3)')
2
--
You received this message because
Comment #6 on issue 1818 by smi...@gmail.com: coeff and collect failures on
x**(1+x)
http://code.google.com/p/sympy/issues/detail?id=1818
I'm leaving this open since as long as the 2-arg mul behavior exists we may
want to make things like coeff work a little harder to find the add like
Updates:
Cc: ronan.l...@gmail.com
Comment #9 on issue 1233 by asmeurer: fix the rest of jython bugs
http://code.google.com/p/sympy/issues/detail?id=1233
Nowadays, if you try to import sympy in Jython, you get:
Traceback (most recent call last):
File ./bin/test, line 17, in module
Updates:
Cc: smi...@gmail.com
Comment #6 on issue 2360 by asmeurer: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
The problem is in Segment.__contains__ at the very bottom of line.py, which
is copied below:
def __contains__(self, o):
Updates:
Labels: -Priority-Medium Priority-High Milestone-Release0.7.0
Comment #7 on issue 2360 by asmeurer: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
By the way, this is kind of important, since it's blocking issue 2203.
--
You received this
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 2372 by tlora...@gmail.com: Wiki page on running/writing tests
http://code.google.com/p/sympy/issues/detail?id=2372
I didn't find any documentation on running and writing tests for sympy. It
would be nice to have a wiki
Comment #8 on issue 2360 by smi...@gmail.com: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
I guess it worked fine because it assumed that if the point was collinear
but had symbols that it was contained in the raywhich is not true so a
better test is
Comment #1 on issue 2372 by asmeurer: Wiki page on running/writing tests
http://code.google.com/p/sympy/issues/detail?id=2372
Basically. Although the test runner might not be compatible with py.test
due to some bugs.
--
You received this message because you are subscribed to the Google
Updates:
Status: Accepted
Labels: Printing WrongResult NeedsReview asmeurer
Comment #1 on issue 2373 by asmeurer: typo in printing/latex.py
http://code.google.com/p/sympy/issues/detail?id=2373
Thanks for the report.
I have fixed it. See https://github.com/sympy/sympy/pull/309.
Updates:
Status: Started
Comment #2 on issue 2373 by asmeurer: typo in printing/latex.py
http://code.google.com/p/sympy/issues/detail?id=2373
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To
Updates:
Blockedon: 1884
Comment #1 on issue 1941 by asmeurer: Objects that know how to combine
themselves
http://code.google.com/p/sympy/issues/detail?id=1941
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
Issue 1884: remove old assumptions
http://code.google.com/p/sympy/issues/detail?id=1884
This issue is now blocking issue 1941.
See http://code.google.com/p/sympy/issues/detail?id=1941
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you
Updates:
Status: Fixed
Comment #56 on issue 821 by asmeurer: multiple arguments for max and other
improvements
http://code.google.com/p/sympy/issues/detail?id=821
I pushed this in. Was there anything left to do from what was in that pull
request? If so, please reopen.
--
You
Comment #9 on issue 2360 by smi...@gmail.com: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
It has been robustified and tested in
https://github.com/sympy/sympy/pull/292
--
You received this message because you are subscribed to the Google Groups
Updates:
Labels: NeedsReview smichr
Comment #10 on issue 2360 by asmeurer: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
Status: Accepted
Owner: smi...@gmail.com
Labels: Type-Defect Priority-Medium
New issue 2374 by smi...@gmail.com: the 'exact' keyword should be removed
from coeff
http://code.google.com/p/sympy/issues/detail?id=2374
All matching is exact.
--
You received this message because you are
Comment #9 on issue 2307 by smi...@gmail.com: Duplicate methods:
as_coeff_mul and as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
What happens to the time of as_coeff_mul for the test in comment 2 after
making the changes of the pull request?
--
You received this
Comment #10 on issue 2307 by asmeurer: Duplicate methods: as_coeff_mul and
as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
I'm not entirely sure how comparable this is with my previous timings, but
here it is:
in as_coeff_mul-remove:
In [2]: %timeit a.as_coeff_mul()
Comment #11 on issue 2307 by asmeurer: Duplicate methods: as_coeff_mul and
as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
The answer is, it isn't comparable. I just reran it in master and got:
In [1]: a = 3*Mul(*[Symbol('x%d' % i) for i in range(100)])
In [2]: %timeit
Status: Accepted
Owner: smi...@gmail.com
Labels: Type-Defect Priority-Medium
New issue 2375 by smi...@gmail.com: should symbols with the same name be
able to have different assumptions?
http://code.google.com/p/sympy/issues/detail?id=2375
This just seems strange to have symbols with the same
Updates:
Status: Fixed
Labels: -NeedsReview PassedReview
Comment #5 on issue 2346 by asmeurer: Symbols should only be equal if they
have the same assumptions
http://code.google.com/p/sympy/issues/detail?id=2346
This was pushed in.
--
You received this message because you are
Updates:
Status: Fixed
Comment #5 on issue 710 by asmeurer: Sum2 vs Sum
http://code.google.com/p/sympy/issues/detail?id=710
Sum2 has been removed. See the branch from issue 2346.
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post
Updates:
Status: Fixed
Labels: -NeedsReview PassedReview
Comment #5 on issue 2352 by asmeurer: Remove Ellipse.distance_to_center()
http://code.google.com/p/sympy/issues/detail?id=2352
This was removed. See the branch from issue 2346.
--
You received this message because you
Status: Accepted
Owner: smi...@gmail.com
Labels: Type-Defect Priority-Medium
New issue 2376 by smi...@gmail.com: should subs use strict=True when
sympifying?
http://code.google.com/p/sympy/issues/detail?id=2376
sympify can be used to change strings into expressions, but if a routine is
Comment #6 on issue 1835 by smi...@gmail.com: 1835: coeff changes
http://code.google.com/p/sympy/issues/detail?id=1835
This is in without the exact keyword functionality. A pull removing this
keyword is forthcoming.
--
You received this message because you are subscribed to the Google
Updates:
Status: Fixed
Comment #7 on issue 1835 by smi...@gmail.com: 1835: coeff changes
http://code.google.com/p/sympy/issues/detail?id=1835
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-patches group.
To
Updates:
Status: Fixed
Comment #2 on issue 1821 by smi...@gmail.com: more simplification could be
done on rationals raised to rationals
http://code.google.com/p/sympy/issues/detail?id=1821
powers are now more canonical
S('8**(1/3)')
2
--
You received this message because
Comment #6 on issue 1818 by smi...@gmail.com: coeff and collect failures on
x**(1+x)
http://code.google.com/p/sympy/issues/detail?id=1818
I'm leaving this open since as long as the 2-arg mul behavior exists we may
want to make things like coeff work a little harder to find the add like
Updates:
Status: Fixed
Comment #5 on issue 2306 by ness...@googlemail.com: Duplicate
implementation of factorial in sympy/core/numbers.py
http://code.google.com/p/sympy/issues/detail?id=2306
This has been merged:
Updates:
Status: Accepted
Labels: Printing WrongResult NeedsReview asmeurer
Comment #1 on issue 2373 by asmeurer: typo in printing/latex.py
http://code.google.com/p/sympy/issues/detail?id=2373
Thanks for the report.
I have fixed it. See https://github.com/sympy/sympy/pull/309.
Updates:
Status: Fixed
Comment #56 on issue 821 by asmeurer: multiple arguments for max and other
improvements
http://code.google.com/p/sympy/issues/detail?id=821
I pushed this in. Was there anything left to do from what was in that pull
request? If so, please reopen.
--
You
Updates:
Labels: NeedsReview smichr
Comment #10 on issue 2360 by asmeurer: Bug in geometry intersection
http://code.google.com/p/sympy/issues/detail?id=2360
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
Comment #9 on issue 2307 by smi...@gmail.com: Duplicate methods:
as_coeff_mul and as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
What happens to the time of as_coeff_mul for the test in comment 2 after
making the changes of the pull request?
--
You received this
Comment #10 on issue 2307 by asmeurer: Duplicate methods: as_coeff_mul and
as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
I'm not entirely sure how comparable this is with my previous timings, but
here it is:
in as_coeff_mul-remove:
In [2]: %timeit a.as_coeff_mul()
Comment #11 on issue 2307 by asmeurer: Duplicate methods: as_coeff_mul and
as_coeff_Mul
http://code.google.com/p/sympy/issues/detail?id=2307
The answer is, it isn't comparable. I just reran it in master and got:
In [1]: a = 3*Mul(*[Symbol('x%d' % i) for i in range(100)])
In [2]: %timeit
Updates:
Status: Fixed
Labels: -NeedsReview PassedReview
Comment #5 on issue 2346 by asmeurer: Symbols should only be equal if they
have the same assumptions
http://code.google.com/p/sympy/issues/detail?id=2346
This was pushed in.
--
You received this message because you are
Updates:
Status: Fixed
Labels: -NeedsReview PassedReview
Comment #5 on issue 2352 by asmeurer: Remove Ellipse.distance_to_center()
http://code.google.com/p/sympy/issues/detail?id=2352
This was removed. See the branch from issue 2346.
--
You received this message because you
On 13 Mai, 01:54, SherjilOzair sherjiloz...@gmail.com wrote:
Did I leave anything Vinzent ?
I think we should also talk about the future of the matrix module (and
a possible refactoring), so that we have a clear vision of the design
when the official coding starts. For example, I'm not really
_op_priority was designed to help with implementing arithmetic
operations, particularly for things that aren't calculus expressions
yet have meaningful __add__, __mul__, __pow__, etc. such as vectors and
operators of various kinds. But it turns out that it doesn't really help
Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a écrit :
On 13 Mai, 01:54, SherjilOzair sherjiloz...@gmail.com wrote:
Did I leave anything Vinzent ?
I think we should also talk about the future of the matrix module (and
a possible refactoring), so that we have a clear vision of the
On Sun, May 15, 2011 at 12:26 AM, Ronan Lamy ronan.l...@gmail.com wrote:
Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a écrit :
On 13 Mai, 01:54, SherjilOzair sherjiloz...@gmail.com wrote:
Did I leave anything Vinzent ?
I think we should also talk about the future of the
On Sat, May 14, 2011 at 1:15 PM, Saptarshi Mandal
sapta.iit...@gmail.com wrote:
I have fleshed out the structure of a permutation. It inherits from
the Basic class and will attempt to be completely symbolic a bit later
(this part is easy).
The algorithms to generate various permutations itself
On 14 Mai, 20:56, Ronan Lamy ronan.l...@gmail.com wrote:
I'm not sure what you mean about routines that cannot be abstract, but
if you're saying that it doesn't really make sense for a subclass of
Matrix to have, for instance, dict manipulation methods, I tend to
agree. The data structures
On 14 Mai, 18:31, Ronan Lamy ronan.l...@gmail.com wrote:
_op_priority was designed to help with implementing arithmetic
operations, particularly for things that aren't calculus expressions
yet have meaningful __add__, __mul__, __pow__, etc. such as vectors and
operators of various kinds. But
Le dimanche 15 mai 2011 à 01:18 +0530, Sherjil Ozair a écrit :
On Sun, May 15, 2011 at 12:26 AM, Ronan Lamy ronan.l...@gmail.com
wrote:
Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a
écrit :
On 13 Mai, 01:54, SherjilOzair sherjiloz...@gmail.com
The better fix is
http://code.google.com/p/sympy/issues/detail?id=1941, but that would
require a bit of rewriting of the core that I wouldn't even attempt
before the assumptions are removed.
Brian, how do you feel about this?
Aaron Meurer
On Sat, May 14, 2011 at 2:49 PM, Vinzent Steinberg
On Sat, May 14, 2011 at 9:43 AM, Vinzent Steinberg
vinzent.steinb...@googlemail.com wrote:
On 13 Mai, 01:54, SherjilOzair sherjiloz...@gmail.com wrote:
Did I leave anything Vinzent ?
I think we should also talk about the future of the matrix module (and
a possible refactoring), so that we
On Sat, May 14, 2011 at 3:17 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Le dimanche 15 mai 2011 à 01:18 +0530, Sherjil Ozair a écrit :
On Sun, May 15, 2011 at 12:26 AM, Ronan Lamy ronan.l...@gmail.com
wrote:
Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a
écrit :
Gilbert,
I prefer this notation:
B = ReferenceFrame('B')
and then to access the basic vectors of that frame, to use one of the
following approaches:
B.x, B.y, B.z or, B.i, B.j, B.k
You could view the ReferenceFrame class as a container object for the
basis vectors and implement the
This is for anyone not getting the updates via the pull request who
might be interested: there are just three commits waiting for review
2374: remove exact keyword from coeff
Curve arbitrary_point defaults to t
2360: robustify Geometry.segment contains test
--
You received this message because
59 matches
Mail list logo
