I thought there was a way to attach a file, but that must be in the
other groups. Here is a small patch that deals only with docstrings.
>From 77c8cb719ea5d9231867873ceef512826a182f73 Mon Sep 17 00:00:00 2001
From: Chris Smith <>
Date: Tue, 30 Jun 2009 02:00:47 +0545
Subject: [PATCH 1/1] typo and
On Jul 3, 9:58 pm, Vinzent Steinberg
wrote:
> 2009/7/3 Andy Ray Terrel
>
>
>
> > -1
>
> > There are already 4 examples, one more is not necessary.
>
> I do not agree, there is no example about definite integration, so I'm +1
> for adding one.
>
That's why I added that extra one. There are also
On Jul 6, 9:45 pm, Andy Ray Terrel wrote:
> Okay I'm +1 with the changes and arguments for the example. Update
> the patch and I will push it.
>
I know what updating is in general (:-)) but in this context I don't
know what I should be changing. Can you elaborate on what about the
patch needs
The following two patches address in one patch several issues that
I've raised in various issues. I've tried to keep the patch to items
that are absolutely essential to change to lighten the reviewer's
burden. Addressed are:
the quartic (and cubic) root finding routines and changes to roots to
be
>
> This looks good. Where is it in the issue tracker ?
>
> can we pull from some branch ?
>
It's a compilation of several issues. I condensed them all together to
try help in the review process.
When you tried to "copy and paste" it might not have worked because
there were two patches in the te
Everything used to work...now nothing gets run under windows XP:
C:\DOCUME~2\chris\sympy\sympy>\python26\python.exe ..\bin\test core
= test process starts
==
executable: C:\python26\python.exe (2.6.1-final-0)
=== tests
Yes, there are more here. These are the distillation of issues
presented elsewhere. The quartics changes are still pending, for
example.
/c
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To po
I see in the document that using set() is proposed as being a
solution. However, this was the first thing that I tried in issue 1729
and that failed, too.
sympy.polys.rootfinding.roots_quartic
_
File "C:\documents and settings\chris\sympy\sympy\polys
\root
And here's a strange and perhaps related result. A tests that gave a
False at one point gives a True later:
C:\Documents and Settings\chris>\python26\python.exe
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" fo
smichr's gfactor branch at github has a (hopefully) more robust method
for factoring. It relies on the standard factor that is part of polys
but it does pre-processing of an expression with a gcdfactor routine.
The gcdfactor pulls out terms that can be removed multiplicatively
from all terms in an
> Chris's test runner has highest priority (tests not working on Windows
> is no option), assumptions and polys are postponed for 0.7.
>
I've learned (thanks to Vinzent, I think) how to work on Windows with
the test runner and don't have the same problems anymore...I would
have gone crazy by now i
> Is gcdfactor() any different from the following?
>
> In [1]: f = x**2*exp(x)+exp(x+y)*x/y
>
> In [2]: f
> Out[2]:
> x + y
> 2 x x⋅ℯ
> x ⋅ℯ +
> y
>
> In [3]: factor(f)
> Out[3]:
> ⎛ y⎞
> ⎜ ℯ ⎟ x
> x⋅⎜x + ──⎟⋅ℯ
> ⎝ y ⎠
>
In this case
On Dec 4, 11:35 am, "Aaron S. Meurer" wrote:
> There are also failures that will not show up until Chris's runtest branch is
> merged in if you do:
>
> bin/doctest sympy/polys/galoistools.py
> bin/doctest sympy/polys/factortools.py
> bin/doctest sympy/polys/monomialtools.py
> bin/doctest sympy/
This thread is being hijacked ;-) Please keep the new polys module
discussions with Issue 1598.
Mateusz, I looked at the polys branch but don't see where terms_gcd is
being used. Are we looking at the same branch? I'm looking at the
polys version 6b6bc5b.
Here is the test case that I am working w
This thread is being hijacked ;-) Please keep the new polys module
discussions with Issue 1598.
Mateusz, I looked at the polys branch but don't see where terms_gcd is
being used. Are we looking at the same branch? I'm looking at the
polys version 6b6bc5b.
Here is the test case that I am working w
This patch looks ok but it's for a different issue maybe? I think that
changing the order is the right thing to do...I just didn't want to
break anything. But sometimes that's the right thing, especially when
the release number is 0.x :)
--
You received this message because you are subscribed to
On Dec 13, 2:08 am, "Aaron S. Meurer" wrote:
> The patch didn't even break any tests because they already used the keyword
> argument (they had to with it at the end). separatevars() was added since
> the last release with my ODE code, so this doesn't really "break" anything
> yet.
>
> (By t
Overall it looks good. Please consider the following edited version as
another iteration of the edit cycle...hmmm, I can't attach. I will
push to smichr's hashdoc branch at github.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this
On Dec 17, 5:42 am, Vinzent Steinberg
wrote:
> > This affects sorting of sympy expressions, meaning that you will get SymPy
> objects
> > printed in different order.
>
> I'd change the wording to "for instance you will get..." or something like
> this.
>
> Otherwise +1, thank you!
Happy to edit
Could we get the plural fixed so we can see
1 exception
2 exceptions
I think all the others read fine. Alternatively it could read
# raised an exception
/c
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email t
OK, let's try again...it's repushed and no failures show here. I am,
however, trying to track down something that showed up in the
polynomial decomposition question that I posed recently.
###
t = -sqrt(2)*(1-sqrt(2))
print sqrt(t).is_real == sqrt(t.expand()).is_real
###
This is False for reasons
> This is False for reasons I am trying to track down. The problem
> doesn't exist in master
Correction: the problem exists in master. (The original raising-
expression wasn't causing a problem in master but was in 1766, but the
underlying problem which has been distilled to the issue shown in the
On Mar 5, 12:04 pm, smichr wrote:
> > This is False for reasons I am trying to track down. The problem
> > doesn't exist in master
>
> Correction: the problem exists in master. (The original raising-
> expression wasn't causing a problem in master but was in 176
ok, all issues have been resolved (except perhaps for an error that
showed up for asmeurer but not for me which I tried to fix but it will
take someone else to test it--a test in test_ode triggered it).
All doctests and tests of the current 1766 branch pass for me.
--
You received this message b
> why did you remove the following tests (sympy/core/tests/test_arit.py):
>
> - assert list((I*pi).atoms(NumberSymbol)) == [pi]
> - assert sorted((I*pi).atoms(NumberSymbol, I)) == \
> - sorted((I*pi).atoms(I,NumberSymbol)) == [pi, I]
There must be a better way to find this...sorry
On Mar 2, 1:11 pm, Ondrej Certik wrote:
> On Tue, Mar 2, 2010 at 12:08 AM, Ondrej Certik wrote:
> > Hi,
>
> > notes for myself:
>
> > why did you remove the following tests (sympy/core/tests/test_arit.py):
>
> > - assert list((I*pi).atoms(NumberSymbol)) == [pi]
> > - assert sorted((I*pi)
I'll reply to the initial questions in a bit.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-patches+unsubscr...@googlegr
OK, the expansion doctest works after correcting my chnages to the
_eval_exponential routine.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, s
OK, although *as a whole* all the work to date passes the tests,
individual commits amongst those of the 1766_s branch don't. It's
going to take some time to get each of the commits to pass.
Part of the problem is that I may make a commit A that passes tests,
but then after commits B, C, D somethi
I'm not sure why it is hanging up there. I get no failures in tests or
doctests here. I've tried to squash things together a bit more in
branch 1766_s (note the trailing _s). Could you check that one? And
remember that everything past the quartz line is much more
experimental and in pro
On Mar 26, 8:38 pm, Vinzent Steinberg
wrote:
> I just tried to review the commits before the 'quartz' commit, I hope this
> is to be reviewed, if not, please create a new branch with only the commits
> to be reviewed. The 1766s and the 1766_s branch need to be rebased on
> master.
Yes, many are
Please reconfirm (and perhaps show the commit number so we know we are
talking about the same version).
It all works for me:
sympy\solvers\tests
\test_solvers.py[18] .. [OK]
== tests finished: 18 passed, in 7.59 seconds
==
--
Y
Hello,
There are 17 commits that are waiting for review in my 1766 branch.
They are listed below. When I got feedback in a review, I made changes
and added another commit so, for example, 1778 has 3 parts. Those will
be squashed together when the review process is complete.
b13efb7 1772: integral
Only the commits before 1766 are really ready for pushing. I am still
pulling apart 1766.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, send email to sympy-patc...@googlegroups.com.
To unsubscribe from this group, send
> > As I already said, it would be much easier if you could create another
> > branch for review (1766-for-review) which contains only "stable" changes.
> > This would help to get it in faster.
The commits before "1766--" are stable. I am not
changing those. I am only, as revie
>
> Do all tests (including the code quality) work for you? If so, we need
> to improve this.
You said "without the first commit". Do you mean without the latest
commit? In any case, all solvers.py tests pass in all commits. The
equal() can be used too make these pass on 32 or 64 bit systems if
n
>
> I hope I am not adding confusion here, but I think Vincent just asked
> for something like
>
> ]$ git branch 1766-for-review ff50ca5221a22e9b80d1
>
> Øyvind
That's a helpful hint Øyvind. I see that that creates a branch with
the indicated commit as the HEAD. I'm willing to do what is most
help
In the meanwhile, I've used Øyvind's hint to create branches numbered
as to commit number for all the commits in review and pushed them to
github. In cases where there are additions (like 1725a 1725b 1725c,
those are all in branch 1725).
ff50ca5 1936: Integral and Sum edits
c2a77c6 1919: unify var
On May 11, 4:43 pm, smichr wrote:
> In the meanwhile, I've used Øyvind's hint to create branches numbered
> as to commit number for all the commits in review and pushed them to
> github. In cases where there are additions (like 1725a 1725b 1725c,
> those are all in branch
OBJECTIVE: get variables in returned equation to synch with local
variables.
EXAMPLE OF PROBLEM
Let's say I want to find where a parabola intersects with a line.
I create variables and a parabola equation
>>> var('x y')
(x, y)
>>> p=2*x**2-3*x+4
I create a line that I know passes through two p
> > patch for issue 1694 needs review.
> > It enhances solver capabilities and fix issues concerning fractions :
I would like a chance to review this...I can do so in about 8 hours.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to th
I have 2 commits in branch 1923 at github.smichr that are in review.
sift is a utility function that I have found very useful for getting
expressions sifted into lists. This is a common idiom that occurs in
sympy and sift could be used to streamline code a bit (but I didn't
make those changes with
I've asked about factoring before but am just jotting down some
observations that I've made in the last few days. I was talking with
Aaron the other day about a routine and suggested he should use
factoring. He says, "that's gong to be expensive." I got to thinking.
There are really 3 (at least) t
> I'm not sure what you mean here. factor() uses variety of algorithms,
> heuristics, theorems and irreducibility criteria to improve speed of
> factoring polynomials, e.g.:
I'm only saying (and without understanding at all about how EEZ works)
that based on the behavior of factor one can tell it
On Aug 10, 1:23 am, Mateusz Paprocki wrote:
> Hi,
>
>
>
> On Sat, Aug 07, 2010 at 04:57:18AM -0700, smichr wrote:
> > I've asked about factoring before but am just jotting down some
> > observations that I've made in the last few days. I was talking with
&g
On Aug 11, 12:01 pm, smichr wrote:
> On Aug 10, 1:23 am, Mateusz Paprocki wrote:
This factoring business is so easy to get wrong. The routine at gist
handles pure symbolic factors well (at least the current version I
have here) but it fails for stragglers:
a + b + x*a + x*b
and does
Mateusz has made changes in polys11 to make symbols behave like var; I
have submitted a patch 1919 on Vinzent's suggestion in the same issue
to make var behave like symbols. Which way should it go?
var('abc') -> injects abc or a, b, c?
I personally like to be able to quickly make a few variables
On Aug 17, 6:32 pm, Vinzent Steinberg
wrote:
> 2010/8/17 Aaron S. Meurer :
>
> > Well, here's the problem with the spaceless option:
>
> var('ab cd ef')
> > (ab, cd, ef)
> var('ab cd')
> > (ab, cd)
> var('ab')
> > (a, b)
>
> You could still do
>
> >>> var('ab ')
>
> ab
>
I don't
Would it be possible to have it recognize numbers as in
symbols('a1:10') -> a1, a2, a3, ..., a10? One could also have the
parser only recognize the number(s) or single characters on either
side of the : so that symbols('aa:z') would give aa, ab, ac, ..., az.
--
You received this message because y
om the subs as
possible unless the user says otherwise. Using the 'exact' flag will
always result in a unique substitution.
If you want to take a look (it's documented and there are tests) see
"subs-wild, atoms, exact, static" commit in t2 at github/smichr.
--
You receive
On Nov 19, 8:08 am, sy...@googlecode.com wrote:
> Comment #10 on issue 1915 by ronan.l...@gmail.com: Unify make_list with
> as_Add/as_Mulhttp://code.google.com/p/sympy/issues/detail?id=1915
>
> I think I've found a better name: "make_args". "Add.make_args(expr)" seems
> reasonably clear to me
On Nov 20, 6:13 am, Ronan Lamy wrote:
> Le vendredi 19 novembre 2010 à 01:28 -0800, smichr a écrit :
>
> > On Nov 19, 8:08 am, sy...@googlecode.com wrote:
> > > Comment #10 on issue 1915 by ronan.l...@gmail.com: Unify make_list with
> > > as_Add/as_Mulhttp://
> .count_ops() is rather quirky and not really generic.
> To get the number of nodes in the expression tree, you can do:
When 1923 gets pushed you will find it to be less quirky, I believe.
Also, when 2003 gets pushed, Aaron, there is a capture function that
will capture any output into a string.
There are a bunch of commits that are being nicely managed by github
in https://github.com/sympy/sympy/pull/61 that are mainly related to
series work (which Alexey has been commenting on) but there are some
other there, too, that need review.
On the page are a few regions where commits are listed.
OK, this might help:
I have a TODO comment that you can search for on the page that lists
the commits that are not series related. I can edit that as the review
takes place. When that TODO comment is empty and the series work is
finished, these 31 commits will be ready.
--
You received this mess
new_rawargs should watch for [] args
The most anticipated case (len(args) > 1) is now put first
in _new_rawargs. In addition, the case of no args is now
handled. Tests were added.
https://github.com/sympy/sympy/pull/114
--
You received this message because you are subscr
see [ http://code.google.com/p/sympy/issues/detail?id=2201 ]
https://github.com/sympy/sympy/pull/117
--
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
The current instantiation of dummies using the workaround fix for anticipated
polys12 behavior doesn't work properly:
h[1] >>> x=symbols('x', cls=Dummy)
h[1] >>> type(x)
h[2] >>> x
[_x]
This commit fixes this and tests are added. Should we also allow other classes
beside Du
https://github.com/sympy/sympy/pull/120
--
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
The commutivity of integrals is None right now. This will cause a problem with
polys12 later and would be ok to fix now. This commit sets the commutivity
based on the commutivity of the free_symbols of the Integral.
https://github.com/sympy/sympy/pull/121
--
You received this message because y
'evaluate' is not really an assumption and shouldn't be passed around as such
since assumptions are used to generate hashes for objects.
_new_rawargs should be careful about making sure the commutivity of the
returned object is correct. Some modifications toward this end were made.
[these are i
When unicode is not being used, tests with an unqualified pretty test may fail.
The two failing tests now pass with the changes of this commit.
https://github.com/sympy/sympy/pull/123
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to
Can someone (Brian?) review the [ https://github.com/sympy/sympy/pull/125
] and [ https://github.com/sympy/sympy/pull/128 ]? These have had no
comments in 2 weeks. I'm happy to commit them but am not the best one
to review them.
--
You received this message because you are subscribed to the Googl
63 matches
Mail list logo
