Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium Logic
New issue 3105 by asmeu...@gmail.com: (a b) (c d) does not work
http://code.google.com/p/sympy/issues/detail?id=3105
from sympy import var, And
var('a b c d')
(a, b, c, d)
And(a b, c d)
And(a b, c d)
(a b) (c
Comment #1 on issue 3105 by asmeu...@gmail.com: (a b) (c d) does not
work
http://code.google.com/p/sympy/issues/detail?id=3105
This used to work in 0.6.7, but was broken in 0.7.0. I bisected it to this
commit:
commit 635d89c3c53fd84cc884e0ab62dc3f03480fe76a
Author: Ronan Lamy
Updates:
Labels: NeedsReview smichr
Comment #6 on issue 3099 by smi...@gmail.com: Expr.is_constant() is very
slow in some cases
http://code.google.com/p/sympy/issues/detail?id=3099
https://github.com/sympy/sympy/pull/1085
--
You received this message because you are subscribed to
Comment #4 on issue 3104 by someb...@bluewin.ch: Expectation value of
random variables raises maximum recursion depth exceeded
http://code.google.com/p/sympy/issues/detail?id=3104
While it should be possible to compute Y = f(X) for a wide range of
functions f:R-R
(just google for Function
Issue 1887: Separate boolean and symbolic relationals
http://code.google.com/p/sympy/issues/detail?id=1887
This issue is now blocking issue 3105.
See http://code.google.com/p/sympy/issues/detail?id=3105
--
You received this message because you are listed in the owner
or CC fields of this issue,
Comment #3 on issue 3101 by smi...@gmail.com: assertion error in Mul.flatten
http://code.google.com/p/sympy/issues/detail?id=3101
b,e=(-2*I),Rational(5,3);(b**e).n(2),(b.n()**e.n()).n(2, chop=1e-10)
(3.2*I, 3.2*I)
--
You received this message because you are subscribed to the Google Groups
Comment #2 on issue 3025 by ronan.l...@gmail.com: Piecewise evaluate=False
does not work when conditions are boolean
http://code.google.com/p/sympy/issues/detail?id=3025
Generally speaking, I think we should avoid evaluate=False (cf. issue 273),
and in any case I don't see any use for
Comment #3 on issue 3025 by ronan.l...@gmail.com: Piecewise evaluate=False
does not work when conditions are boolean
http://code.google.com/p/sympy/issues/detail?id=3025
Generally speaking, I think we should avoid evaluate=False (cf. issue 274),
and in any case I don't see any use for
Updates:
Labels: EasyToFix
Comment #1 on issue 3106 by asmeu...@gmail.com: zoo*zoo == nan
http://code.google.com/p/sympy/issues/detail?id=3106
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To
Comment #4 on issue 3025 by asmeu...@gmail.com: Piecewise evaluate=False
does not work when conditions are boolean
http://code.google.com/p/sympy/issues/detail?id=3025
As Sean was explaining in the pull request, multiple True conditions makes
sense if you want to be vague in the definition
Comment #8 on issue 3095 by ronan.l...@gmail.com: Set.contains should
behave symbolically
http://code.google.com/p/sympy/issues/detail?id=3095
OK, I guess that's the best we can do for now. I've sent
https://github.com/sympy/sympy/pull/1088 which should be enough to deal
with the
Updates:
Blockedon: 2832
Comment #3 on issue 3034 by asmeu...@gmail.com: None -oo?
http://code.google.com/p/sympy/issues/detail?id=3034
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post
Issue 2832: bool(Relational) should raise ValueError
http://code.google.com/p/sympy/issues/detail?id=2832
This issue is now blocking issue 3034.
See http://code.google.com/p/sympy/issues/detail?id=3034
--
You received this message because you are listed in the owner
or CC fields of this issue,
Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium Documentation
New issue 3107 by asmeu...@gmail.com: docscrape.py extension only allows a
set number of headers
http://code.google.com/p/sympy/issues/detail?id=3107
From doc/ext/docscrape.py:
self._parsed_data = {
Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium Geometry
New issue 3108 by ronan.l...@gmail.com: wrong code in
Polygon.arbitrary_point
http://code.google.com/p/sympy/issues/detail?id=3108
Line 592 in polygon.py is the following:
sides.append((pt,
Updates:
Labels: NeedsReview smichr
Comment #2 on issue 3100 by smi...@gmail.com: power rules misapplied
http://code.google.com/p/sympy/issues/detail?id=3100
This is also handled in https://github.com/sympy/sympy/pull/1087 ;
along with the error that Mul(I,I,I,2) gave 2*(-I) instead of
Comment #5 on issue 3025 by sean.v@gmail.com: Piecewise evaluate=False
does not work when conditions are boolean
http://code.google.com/p/sympy/issues/detail?id=3025
The primary benefit to evaluate=False is, like Aaron mentioned, delayed
evaluation when some conditions may be bools.
Comment #1 on issue 3108 by smi...@gmail.com: wrong code in
Polygon.arbitrary_point
http://code.google.com/p/sympy/issues/detail?id=3108
Can you elaborate? The following appears to work ok
.1 = .4 1
True
S(.1) = S(.4) S(1)
True
--
You received this message because you are
Comment #2 on issue 3108 by ronan.l...@gmail.com: wrong code in
Polygon.arbitrary_point
http://code.google.com/p/sympy/issues/detail?id=3108
It only works with built-in types (and sympy types that emulate them).
1 x 0
x 0
Roughly, Python interprets x y z as (x y) and (y z),
Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium
New issue 3110 by ronan.l...@gmail.com: Piecewise.as_leading_term is broken
http://code.google.com/p/sympy/issues/detail?id=3110
In [13]: Piecewise((1/x, x1), (0, True)).as_leading_term(x)
Updates:
Summary: Positive and negative imaginary assumptions
Status: Accepted
Labels: -Type-Defect -NeedsReview -smichr Type-Enhancement Assumptions
Comment #3 on issue 3007 by asmeu...@gmail.com: Positive and negative
imaginary assumptions
Comment #16 on issue 3090 by nathan.f...@gmail.com: Create
ContinuousDensity class
http://code.google.com/p/sympy/issues/detail?id=3090
Hmm... I see.
Maybe you can convert a dict to a Piecewise?
{1: 1/2, 0: 1/2} - Piecewise((1/2, Eq(x, 1)), (1/2, Eq(x, 0)), (0, True)).
But that is very
Comment #3 on issue 3101 by smi...@gmail.com: assertion error in Mul.flatten
http://code.google.com/p/sympy/issues/detail?id=3101
b,e=(-2*I),Rational(5,3);(b**e).n(2),(b.n()**e.n()).n(2, chop=1e-10)
(3.2*I, 3.2*I)
--
You received this message because you are subscribed to the Google Groups
Updates:
Labels: NeedsReview smichr
Comment #2 on issue 3100 by smi...@gmail.com: power rules misapplied
http://code.google.com/p/sympy/issues/detail?id=3100
This is also handled in https://github.com/sympy/sympy/pull/1087 ;
along with the error that Mul(I,I,I,2) gave 2*(-I) instead of
Am 25.02.2012 23:23, schrieb Aaron Meurer:
Yes, I believe it should. That's why I'm wondering why it gives nan.
Same here.
My intuition tells me that whatever path you take for
lim re,im-oo: re+i*im
you get zoo.
Wikipedia says that zoo*zoo is commonly defined as zoo.
--
You received this
I have this at a pretty workable state. It is available at
https://github.com/nathan-rice/symbolic.
Python's AST is not terribly fun to use, though I've done most of the
hard work. There were a lot of corner cases and little annoyances. I
still think the code transformation approach has
Am 13.02.2012 23:54, schrieb Aaron Meurer:
In other words,
something like x*(x += 1) would be allowed (e.g., if x starts as 2,
this would give 3).
You do not want to have or allow side effects in user-specified
expressions. You get a whole lot of restrictions on which AST
transformations are
On Sun, Feb 26, 2012 at 7:06 PM, Joachim Durchholz j...@durchholz.org wrote:
Am 13.02.2012 23:54, schrieb Aaron Meurer:
In other words,
something like x*(x += 1) would be allowed (e.g., if x starts as 2,
this would give 3).
Heck, I'd even make the mutating operations on all symbols throw an
I've created http://code.google.com/p/sympy/issues/detail?id=3106 for
this. It should be easy to fix.
Aaron Meurer
On Sun, Feb 26, 2012 at 6:11 AM, Joachim Durchholz j...@durchholz.org wrote:
Am 25.02.2012 23:23, schrieb Aaron Meurer:
Yes, I believe it should. That's why I'm wondering why
Am 26.02.2012 20:05, schrieb Sergiu Ivanov:
As a functional programming beginner and fan, I can't but agree. I
was actually quite happy when I heard for the first time that SymPy
had immutable core, because that allows for much clearer and better
structured code (at least I see it so).
Hm...
I would like to point out that the immutability of the core need not
change if we follow the propositions in this discussion.
In my opinion the important point here is the implementation of
abstract syntax trees for sympy. The minor (from mathematical point of
view) details about whether it
I think it's a quite ugly to see
2
x
I'd much rather have
x²
Subscripts for numerical powers would make a lot of simple expressions
prettier, I think. We'd still have the current syntax for more complicated
expressions.
--
You received this message because you are subscribed to the Google
32 matches
Mail list logo
