Comment #2 on issue 3323 by amake...@college.harvard.edu: perm_groups
alt_or_sym failure
http://code.google.com/p/sympy/issues/detail?id=3323
Hi all,
it's my fault for writing a bad docstring. The other way I see to cope with
this is the following: we add an attribute _is_alt_sym to the
Updates:
Status: Invalid
Comment #3 on issue 3303 by krastano...@gmail.com: fdiff uses unpythonic
indexing
http://code.google.com/p/sympy/issues/detail?id=3303
I do not know in what state of mind was I when filing this issue, however I
am wrong about it.
The indices are
Status: Valid
Owner:
Labels: Type-Defect Priority-Medium
New issue 3325 by smi...@gmail.com: test_functions.py should be renamed
test_function.py
http://code.google.com/p/sympy/issues/detail?id=3325
The test file for a file generally preppends `test_` but function.py's test
file is
Just some docs updates, inspired by #55. No need to re-upload to the app engine
after pushing this.
You can merge this Pull Request by running:
git pull https://github.com/asmeurer/sympy-live docs
Or you can view, comment on it, or merge it online at:
Since https://github.com/sympy/sympy-bot/pull/113 was merged I guess we need to
get rid from old code
https://github.com/sympy/sympy-bot/blob/master/web/app/main.py#L151
https://github.com/sympy/sympy-bot/blob/master/web/app/main.py#L198
Now there are *two* almost identical notebooks?
I'll make a PR to remove the one with less examples.
---
Reply to this email directly or view it on GitHub:
https://github.com/sympy/sympy/commit/387547b1595ba3aeb9f7f3c78ebd4697ef1d028e#commitcomment-1578761
--
You received this message because
I added build targets to compile SymPy document into an info file. However, it
does not work as is. I get the following error when tried to build (using
`make info`).
I need to use `makeinfo --force --no-split -o sympy.info sympy.texi` to force
compile. Probably this is a bug in texinfo
About the flags:
To be specific, I think that separating it to simplify and
group_constants will be useful, at least until the simplification of
constants becomes smarter.
group_constants - the constants simplification routine
simplify - the rest
However, this is a workaround for the problems
There is an old open PR:
http://github.com/sympy/sympy/pull/1026
which tries to make orthogonal polynomials work
for symbolic order 'n'. An open question is
when to apply simplifications like:
L_n(-x) --- (-1)**n * L_n(x)
L_{-n}(x) --- L_{n-1}(x)
Do we want to have this:
a) at
a) at construction time
b) only when calling expand_func
Would option b) provide for this:
simplify(Integral(L(n, x)*L(n+1, x), blah blah))
If yes I may vote for b).
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email
No, at the moment both options do not allow to
compute the orthogonality integrals :-/
@asmeurer: I remember we once tried
computing that:
In [2]: n = Symbol(n)
In [3]: m = Symbol(m)
In [4]: x = Symbol(x)
In [5]: dln = diff(legendre(n,x),x)
In [6]: dln
Out[6]: n*(x*legendre(n, x) - legendre(n -
Now that the results are out, I'd like to announce publicly that all
six of our GSoC students have passed their midterm evaluations.
Congratulations to all of you. I look forward to seeing your work for
the second half of the program.
Aaron Meurer
--
You received this message because you are
I personally would vote for option a as it would be consistent with
functions like sin and cos.
Some things to consider though:
- What if either argument is something like x - y or y - x? Would those
both be canonicalized to the same thing (with either choice)?
- If there ever could be a case
What if either argument is something like x - y or y - x? Would those
both be canonicalized to the same thing (with either choice)?
No.
a) We pull out some factors and get legendre objects of same argument:
In [6]: legendre(n, y-x)
Out[6]: (-1)**n*legendre(n, x - y)
In [7]: legendre(n, x-y)
On Jul 13, 2012, at 3:35 PM, rl someb...@bluewin.ch wrote:
What if either argument is something like x - y or y - x? Would those
both be canonicalized to the same thing (with either choice)?
I meant using expand_func with option b.
Aaron Meurer
No.
a) We pull out some factors and get
I personally would vote for option a as it would be consistent with
functions like sin and cos.
Me too. Most objects do some simpler transformation at this point. Option b)
is probably an overkill
in turning off automatic simplification features, compared to the rest of
sympy.
If it
Does anyone have an idea why, after setting the seed and hashseed, that I
can't reproduce the failure under 2.7.3 in cse shown in this report:
https://mail.google.com/mail/u/0/?shva=1#label/sympy/13882d26f36a1304
Is it just a 64 vs 32-bit things?
/c
--
You received this message because you
On Friday, July 13, 2012 10:27:16 PM UTC-5, smichr wrote:
Does anyone have an idea why, after setting the seed and hashseed, that I
can't reproduce the failure under 2.7.3 in cse shown in this report:
https://mail.google.com/mail/u/0/?shva=1#label/sympy/13882d26f36a1304
Is it just a 64
If you were using 64 or 32 bit and are trying to use the other, that
will make a difference for the hash seed. The hash seed is the seed +
the architecture (32 or 64 bits). This is because hash values are
numbers that are one word, so on 32-bit computers, hash values can be
up to 2**32 (or maybe
That test report says 64-bit, so you need to make sure you are using that
again.
OK...no 64 bit here. And I really don't know how that particular test
can be failing.
stymied-in-32-bit-ly,
/c
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post
I just checked it. It seems that that the order of the .args is
different for expr and Subs(f(_x, _y), (_x, _y), (0, x0)) + Subs(g(_x,
_y), (_x, _y), (0, x0)). The individual args are otherwise the same.
The only way I can see that happening is if expr is created by some
method that bypasses
I just changed the sorting of the hashable content in my rand branch.
Can you try to see if it works now?
--
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
Nope. Same test failure. Same reason.
Aaron Meurer
On Fri, Jul 13, 2012 at 10:54 PM, Chris Smith smi...@gmail.com wrote:
I just changed the sorting of the hashable content in my rand branch.
Can you try to see if it works now?
--
You received this message because you are subscribed to the
On Sat, Jul 14, 2012 at 12:04 AM, Aaron Meurer asmeu...@gmail.com wrote:
Nope. Same test failure. Same reason.
OK, I think I understand the problem: each Subs instance creates its
own dummies; those cause the hash-ed args to sort differently so the
two sides of the equality aren't the same. I
24 matches
Mail list logo