Updates:
Cc: ondrej.certik Vinzent.Steinberg asmeurer
Comment #1 on issue 1832 by smichr: wildfunction needs to be imported in
symbol
http://code.google.com/p/sympy/issues/detail?id=1832
this is out of 1766 again and needing review. Same commit number. It's a
couple-liner.
--
You
Updates:
Cc: Vinzent.Steinberg asmeurer ondrej.certik
Comment #1 on issue 1808 by smichr: facts change
http://code.google.com/p/sympy/issues/detail?id=1808
This is available for review. It's a short review.
--
You received this message because you are listed in the owner
or CC fields
Status: Accepted
Owner: smichr
Labels: Type-Defect Priority-Medium
New issue 1921 by smichr: failing doctest under windows
http://code.google.com/p/sympy/issues/detail?id=1921
I fixed a docttest that fails for me under windows. It was located in
polynomials.txt
--
You received this message
Updates:
Labels: NeedsReview
Comment #1 on issue 1921 by smichr: failing doctest under windows
http://code.google.com/p/sympy/issues/detail?id=1921
See commit 1921 in smichr's 1766 branch at github. Painless review
opportunity :-)
--
You received this message because you are listed
Comment #67 on issue 1766 by smichr: expand(power_base=True) is too
aggressive
http://code.google.com/p/sympy/issues/detail?id=1766
All tests now pass here. There are a couple of doctests to sort out,
however. But I'd
rather have the other commits that have been pulled out (and will be
Status: Accepted
Owner: smichr
Labels: Type-Defect Priority-Medium
New issue 1922 by smichr: derivative results in an illegal derivative
http://code.google.com/p/sympy/issues/detail?id=1922
I'm not sure if this is a bug or a feature. When you differentiate wrt y in
f(x/y) you end up with an
Comment #8 on issue 1660 by asmeurer: [PATCH] derivatives of composed
functions should not evaluate to a derivative in terms of a function
http://code.google.com/p/sympy/issues/detail?id=1660
Issue 1922 has been merged into this issue.
--
You received this message because you are listed in
Updates:
Status: Duplicate
Mergedinto: 1660
Comment #1 on issue 1922 by asmeurer: derivative results in an illegal
derivative
http://code.google.com/p/sympy/issues/detail?id=1922
This is a well-known bug. There's unfortunately a bit of a chain of
blocking issues to fix it,
Comment #2 on issue 1921 by asmeurer: failing doctest under windows
http://code.google.com/p/sympy/issues/detail?id=1921
See also
http://groups.google.com/group/sympy-patches/browse_thread/thread/f62c954c3fc948d8
--
You received this message because you are listed in the owner
or CC fields
Comment #3 on issue 1921 by smichr: failing doctest under windows
http://code.google.com/p/sympy/issues/detail?id=1921
ok...then I'll leave the commit there, but just ignore it.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred
Comment #8 on issue 1915 by ronan.l...@gmail.com: Unify make_list with
as_Add/as_Mul
http://code.google.com/p/sympy/issues/detail?id=1915
@Vinzent: A problem with your suggestion is that it would imply having a
class method
and an instance method with the same name in the same class.
Updates:
Cc: Vinzent.Steinberg
Comment #3 on issue 1795 by smichr: cartes(ian) product updated
http://code.google.com/p/sympy/issues/detail?id=1795
This commit in smichr's 1766 branch at github still needs review. As long
as we are
keeping 2.4 compatibility, these functions are worth
Comment #3 on issue 1919 by Vinzent.Steinberg: unify behavior of var() and
symbols()
http://code.google.com/p/sympy/issues/detail?id=1919
Sorry for the first sentence. :) It should read: 'See the corresponding
source code.'
The only thing that is different is indeed the default value of
Comment #4 on issue 1919 by asmeurer: unify behavior of var() and symbols()
http://code.google.com/p/sympy/issues/detail?id=1919
var() also injects symbols into the namespace.
I'm
not sure about merging both functions into one, it is convenient to have
both.
So what exactly are you
Comment #5 on issue 1919 by Vinzent.Steinberg: unify behavior of var() and
symbols()
http://code.google.com/p/sympy/issues/detail?id=1919
I propose to unify the behavior, setting the same default for each_char for
both.
--
You received this message because you are listed in the owner
or
Status: Accepted
Owner: smichr
CC: Vinzent.Steinberg, asmeurer, ondrej.certik
Labels: Type-Defect Priority-Medium NeedsReview
New issue 1923 by smichr: count_ops doesn't return a count (by default)
http://code.google.com/p/sympy/issues/detail?id=1923
This function has good utility for
Comment #1 on issue 1923 by smichr: count_ops doesn't return a count (by
default)
http://code.google.com/p/sympy/issues/detail?id=1923
(commit number 1923 in smichr's 1766 branch at github.)
--
You received this message because you are listed in the owner
or CC fields of this issue, or
Status: Accepted
Owner: smichr
CC: ondrej.certik, asmeurer, Vinzent.Steinberg
Labels: Type-Defect Priority-Medium NeedsReview
New issue 1924 by smichr: Eq() gets .as_basic() method
http://code.google.com/p/sympy/issues/detail?id=1924
A common idiom is to change an Eq back into a simple Basic
Comment #1 on issue 1924 by ronan.l...@gmail.com: Eq() gets .as_basic()
method
http://code.google.com/p/sympy/issues/detail?id=1924
Issue 1856 has been merged into this issue.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred
Updates:
Status: Duplicate
Labels: -NeedsReview
Mergedinto: 1924
Comment #1 on issue 1856 by ronan.l...@gmail.com: 1856: Eq gets as_basic
method
http://code.google.com/p/sympy/issues/detail?id=1856
#1924 duplicates this, but since there were no comments here, we might
Updates:
Labels: -NeedsReview NeedsBetterPatch
Comment #2 on issue 1924 by ronan.l...@gmail.com: Eq() gets .as_basic()
method
http://code.google.com/p/sympy/issues/detail?id=1924
I don't quite see the point of this. For me, eq.lhs - eq.rhs is easier to
write and
understand than
I'm currently exermining sympy's subs system and I want to share my
observations of the currently implemented algorithm and propose some -
hopefully favorable - changes.
Let's first look what currently happens if subs is called:
-- _subs_dict -
| |
subs
On 28 avr, 12:35, basti basti...@gmail.com wrote:
I believe this might be a big simplification and clarification of the
current sustitution/matching logic. It might also be adviseable to
factor part of the code out into some sort of find function which
does the recursive looking for some
On 28 avr, 02:59, Ronan Lamy ronan.l...@gmail.com wrote:
This issue has been raised many times and I think nobody likes the
current situation. However, the current behaviour is quite convenient
when it works, and much code depends on it. I think that the best
solution is to distinguish
Vinzent Steinberg wrote:
Alan implemented geometric algebra in sympy, maybe this is related.
Vinzent
On 27 avr, 16:41, archangel.associ...@gmail.com
archangel.associ...@gmail.com wrote:
I'm thinking of attempting to pick up where a poster left off if it
hasn't already been done. A poster
On Apr 28, 2:59 am, Ronan Lamy ronan.l...@gmail.com wrote:
* Refactor whole matching logic into a separate module, and use the
Basic.match function only as interface. This was also done for
printing and I think the pattern matching is complex enough to justify
this step.
I don't
These are probably good ideas, though I am not to familiar with the code.
Where does splitting subs into an algebraic subs and a strictly structural subs
fit into all of this?
Aaron Meurer
On Apr 28, 2010, at 4:35 AM, basti wrote:
I'm currently exermining sympy's subs system and I want to
On Apr 28, 5:09 pm, Aaron S. Meurer asmeu...@gmail.com wrote:
These are probably good ideas, though I am not to familiar with the code.
Where does splitting subs into an algebraic subs and a strictly structural
subs fit into all of this?
As I said above, it's my intend to replace the
I have a function of a few variables that is the result of some
symbolic manipulations like differentiation and matrix operations. I
would like to do some Monte Carlo work on this to get the distribution
of the function result as a function of the distributions of the
inputs. However, the subs
On 04/28/2010 07:21 PM, janwillem wrote:
I have a function of a few variables that is the result of some
symbolic manipulations like differentiation and matrix operations. I
would like to do some Monte Carlo work on this to get the distribution
of the function result as a function of the
Works great, thanks. As far as benchmarks go exactly as efficient as
the write and import method and so much more elegant. However,
cann't find documentation, is lambdify brand new?
This is what I tried:
flambdify = sympy.lambdify((X, F, B), Y)
and used as
y = flambdify(x, f, b)
On Apr 28, 7:27
It is not new. It looks like it has a docstring. You can see it if you type
help(lambdify).
Aaron Meurer
On Apr 28, 2010, at 12:10 PM, janwillem wrote:
Works great, thanks. As far as benchmarks go exactly as efficient as
the write and import method and so much more elegant. However,
cann't
Some interesting stuff in computer vision may be doable with geometric
algebra, which is one of the things I want to implement, but mostly I'm
looking at computations on smooth manifolds.
Mike
On Wed, Apr 28, 2010 at 6:46 AM, Alan Bromborsky abro...@verizon.netwrote:
Vinzent Steinberg wrote:
33 matches
Mail list logo
