Hi everyone.
I just merged pull request https://github.com/sympy/sympy/pull/1379,
which enables hash randomization by default in the test runner. What
this means is that if you are running Python 2.6.8, 2.7.3, 3.2.3, or
3.3, then you are going to start seeing a lot of test failures. Hash
randomi
Hello,
On Sun, Jun 24, 2012 at 8:32 AM, Aaron Meurer wrote:
>
> And lastly, if anyone has any thoughts on how we could canonically
> order the arguments of Add and Mul independent of hash values, but is
> still just as fast as hash values, I would love to hear it. If we
> could do that, it would
On Sat, Jun 23, 2012 at 10:32 PM, Aaron Meurer wrote:
> Hi everyone.
>
> I just merged pull request https://github.com/sympy/sympy/pull/1379,
> which enables hash randomization by default in the test runner. What
> this means is that if you are running Python 2.6.8, 2.7.3, 3.2.3, or
> 3.3, then y
On Jun 24, 2012, at 1:11 PM, "Ondřej Čertík" wrote:
> On Sat, Jun 23, 2012 at 10:32 PM, Aaron Meurer wrote:
>> Hi everyone.
>>
>> I just merged pull request https://github.com/sympy/sympy/pull/1379,
>> which enables hash randomization by default in the test runner. What
>> this means is that if
On Sun, Jun 24, 2012 at 10:41 AM, Sergiu Ivanov
wrote:
>
> On Sun, Jun 24, 2012 at 8:32 AM, Aaron Meurer wrote:
>>
>> And lastly, if anyone has any thoughts on how we could canonically
>> order the arguments of Add and Mul independent of hash values, but is
>> still just as fast as hash values, I
On Fri, Jun 29, 2012 at 1:06 PM, Sergiu Ivanov
wrote:
> On Sun, Jun 24, 2012 at 10:41 AM, Sergiu Ivanov
> wrote:
>>
>> On Sun, Jun 24, 2012 at 8:32 AM, Aaron Meurer wrote:
>>>
>>> And lastly, if anyone has any thoughts on how we could canonically
>>> order the arguments of Add and Mul independen
On Sat, Jun 30, 2012 at 12:24 AM, Ondřej Čertík wrote:
> On Fri, Jun 29, 2012 at 1:06 PM, Sergiu Ivanov
> wrote:
>> On Sun, Jun 24, 2012 at 10:41 AM, Sergiu Ivanov
>> wrote:
>>>
>>> On Sun, Jun 24, 2012 at 8:32 AM, Aaron Meurer wrote:
And lastly, if anyone has any thoughts on how we c
Am 29.06.2012 23:24, schrieb Ondřej Čertík:
I think that there is a huge speed penalty for sorting the actual arguments.
Why do you think so?
--
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
Since I did take a bit of a look at doctest failures recently, I
thought I would make my conclusions public, although a lot of this is
going to be self-evident.
Apparently, the reasons for doctest failures now belong to two groups:
1. instances of Basic are output, and some .args get output in
Am 30.06.2012 13:13, schrieb Sergiu Ivanov:
However, I'll try once again to push through the idea of defining
sympy.utilities.sympysort in the following way:
sympysort(x) = sorted(x, key=default_sort_key)
This will make the doctests which output non-Basic objects uglier, but
not less clearer wi
On Sat, Jun 30, 2012 at 2:36 PM, Joachim Durchholz wrote:
> Am 30.06.2012 13:13, schrieb Sergiu Ivanov:
>
>> However, I'll try once again to push through the idea of defining
>> sympy.utilities.sympysort in the following way:
>>
>> sympysort(x) = sorted(x, key=default_sort_key)
>>
>> This will mak
> Each failure of type (2) would require a more specific approach.
> However, I'll try once again to push through the idea of defining
> sympy.utilities.sympysort in the following way:
>
> sympysort(x) = sorted(x, key=default_sort_key)
Using this in the codebase still requires that something be im
As I noted on your pull request, I think a better way is to just wrap
the output in an unordered type (set or dict), and let either the
pretty printer or the doctest printer sort the output (both will do
so). That way, we don't have to add any extra boilerplate to the
doctests, which, as was noted,
After pull request 1375 gets processed I can take a look at the cse
(unless someone else wants to handle it).
/c
--
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 grou
Thanks. The differences can be strange. For example, sometimes you
will get (x8, I*x5), and sometimes you will get (x2, -I), (x8, -x5)
(in this case, x2 is also used in some, but not all, other places
where I appears).
So I think the algorithm needs to be modified to give the best
substitution,
On Sat, Jun 30, 2012 at 12:29 PM, Aaron Meurer wrote:
> As I noted on your pull request, I think a better way is to just wrap
> the output in an unordered type (set or dict), and let either the
> pretty printer or the doctest printer sort the output (both will do
> so). That way, we don't have to
On Sat, Jun 30, 2012 at 12:14 AM, Joachim Durchholz wrote:
> Am 29.06.2012 23:24, schrieb Ondřej Čertík:
>
>> I think that there is a huge speed penalty for sorting the actual
>> arguments.
>
>
> Why do you think so?
Because I tried it. We tried a lot of things when trying to make the core fast.
Am 01.07.2012 09:07, schrieb Ondřej Čertík:
Maybe you can figure out some way which is hash() independent and
still fast. At least I didn't figure it out.
I'd try something like this:
a) Yes, use native dicts as much as possible. Trying to improve over a
core data structure that's getting unl
On Sun, Jul 1, 2012 at 1:14 AM, Joachim Durchholz wrote:
> Am 01.07.2012 09:07, schrieb Ondřej Čertík:
>
>> Maybe you can figure out some way which is hash() independent and
>> still fast. At least I didn't figure it out.
>
>
> I'd try something like this:
>
> a) Yes, use native dicts as much as p
>> a) Yes, use native dicts as much as possible. Trying to improve over a core
>> data structure that's getting unlimited love from the language team doesn't
>> sound like a winning idea to me :-)
>
> Yes, this is the main point in Python.
>
>> b) Keep the sorted list of keys in a separate member v
On Sun, Jul 1, 2012 at 10:56 PM, Chris Smith wrote:
>>> a) Yes, use native dicts as much as possible. Trying to improve over a core
>>> data structure that's getting unlimited love from the language team doesn't
>>> sound like a winning idea to me :-)
>>
>> Yes, this is the main point in Python.
>
>> Are you aware that there is now an ordered dictionary in python? It
>> was backported to 2.7.3, I believe.
>
> This looks fine, but do you some data as to the speed? [0] says that
> it keeps the items in the order in which they were inserted. That
> smells of sequential storage and thus doesn'
> Some details at http://tinyurl.com/8y4h9ad
On the same topic, here is a future optional dependency for sympy:
http://anthon.home.xs4all.nl/Python/ordereddict/
An ordered dict module in C. (sorry, don't derail the discussion over
this, I am just leaving it for future reference)
--
You received t
Am 01.07.2012 21:56, schrieb Chris Smith:
a) Yes, use native dicts as much as possible. Trying to improve over a core
data structure that's getting unlimited love from the language team doesn't
sound like a winning idea to me :-)
Yes, this is the main point in Python.
b) Keep the sorted list
On Mon, Jul 2, 2012 at 12:38 AM, Joachim Durchholz wrote:
> Am 01.07.2012 21:56, schrieb Chris Smith:
>
a) Yes, use native dicts as much as possible. Trying to improve over a
core
data structure that's getting unlimited love from the language team
doesn't
sound like a winn
Am 01.07.2012 20:13, schrieb Ondřej Čertík:
This is at least my experience, but if you have time, please do try it out
in the sympyx code and compare the speed.
I'm a bit short on free time right now, so I may not be able to do
anything in the next few days.
That said, I'll try to find a few
Am 01.07.2012 20:13, schrieb Ondřej Čertík:
On Sun, Jul 1, 2012 at 1:14 AM, Joachim Durchholz wrote:
b) Keep the sorted list of keys in a separate member variable.
c) Create the sorted key list lazily (i.e. only when it's actually needed).
I am afraid it is needed pretty much all the time in
Anyone interested in randomization corrections...#1375 is ready to go.
And the fix for solve's issues is to either 1) for the tests, use
set=True or 2) make solve return sets and change the usages which
don't want this, changing solution[0] with solution.pop() or
`solution=solve(...)` with `solutio
I vote for the first option. If we are going to break compatibility
for solve(), I'd rather just do it once, when we have a real solution
that supports things like infinite solutions.
Aaron Meurer
On Jul 2, 2012, at 1:09 PM, Chris Smith wrote:
> Anyone interested in randomization corrections..
On Sun, Jul 1, 2012 at 2:46 PM, Joachim Durchholz wrote:
> Am 01.07.2012 20:13, schrieb Ondřej Čertík:
>
>> This is at least my experience, but if you have time, please do try it out
>> in the sympyx code and compare the speed.
>
>
> I'm a bit short on free time right now, so I may not be able to
On Sun, Jul 1, 2012 at 11:36 PM, Chris Smith wrote:
>>> Are you aware that there is now an ordered dictionary in python? It
>>> was backported to 2.7.3, I believe.
>>
>> This looks fine, but do you some data as to the speed? [0] says that
>> it keeps the items in the order in which they were inse
Am 01.07.2012 22:36, schrieb Chris Smith:
Are you aware that there is now an ordered dictionary in python? It
was backported to 2.7.3, I believe.
This looks fine, but do you some data as to the speed? [0] says that
it keeps the items in the order in which they were inserted. That
smells of se
Am 01.07.2012 22:48, schrieb Sergiu Ivanov:
[0] http://pypi.python.org/pypi/ordereddict
We want key order.
OrderedDict remembers insertion order, so it's close but doesn't match.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group,
On Tue, Jul 3, 2012 at 8:16 PM, Joachim Durchholz wrote:
> Am 01.07.2012 22:48, schrieb Sergiu Ivanov:
>>
>> [0] http://pypi.python.org/pypi/ordereddict
>
>
> We want key order.
> OrderedDict remembers insertion order, so it's close but doesn't match.
I was under the impression that any order wou
Am Dienstag, 3. Juli 2012 19:16:37 UTC+2 schrieb Joachim Durchholz:
> Am 01.07.2012 22:48, schrieb Sergiu Ivanov:
> > [0] http://pypi.python.org/pypi/ordereddict
>
> We want key order.
> OrderedDict remembers insertion order, so it's close but doesn't match.
>
There is a pure Python implement
Am 03.07.2012 20:34, schrieb Sergiu Ivanov:
On Tue, Jul 3, 2012 at 8:16 PM, Joachim Durchholz wrote:
Am 01.07.2012 22:48, schrieb Sergiu Ivanov:
[0] http://pypi.python.org/pypi/ordereddict
We want key order.
OrderedDict remembers insertion order, so it's close but doesn't match.
I was un
36 matches
Mail list logo
