Hi,
On 23 April 2014 17:37, Mateusz Paprocki <[email protected]> wrote:
> Hi,
>
> On 23 April 2014 17:33, Aaron Meurer <[email protected]> wrote:
>> Does it make a difference if you start out with c = 1 (rather than c =
>> Integer(1) or c = ZZ(1))?
>
OK, so one could use EX domain to make ring() work with Integer, but
note that every operation will require a call to cancel() in this
scenario, e.g.:
In [1]: R, x = ring("x", EX)
In [2]: N, a, c = 10**5, x, Integer(1)
In [3]: %time for i in range(N): a += c*i*x; c *= -1
CPU times: user 6.6 s, sys: 56.3 ms, total: 6.65 s
Wall time: 6.54 s
Removing cancel() saves about 2 s.
Mateusz
> ring() won't work with Integer, because there is no more sympy ground
> types. At most we can compare mpz with int.
>
> Mateusz
>
>> Aaron Meurer
>>
>> On Wed, Apr 23, 2014 at 10:21 AM, Mateusz Paprocki <[email protected]> wrote:
>>> Hi,
>>>
>>> On 23 April 2014 07:36, Ondřej Čertík <[email protected]> wrote:
>>>> On Tue, Apr 22, 2014 at 9:52 PM, Aaron Meurer <[email protected]> wrote:
>>>>> On Tue, Apr 22, 2014 at 10:21 PM, Ondřej Čertík <[email protected]>
>>>>> wrote:
>>>>>> On Tue, Apr 22, 2014 at 6:06 PM, Aaron Meurer <[email protected]> wrote:
>>>>>>> On Tue, Apr 22, 2014 at 12:05 PM, Ondřej Čertík
>>>>>>> <[email protected]> wrote:
>>>>>>>> Hi Aaron,
>>>>>>>>
>>>>>>>> Those are good questions. Here are the answers:
>>>>>>>>
>>>>>>>> On Tue, Apr 22, 2014 at 10:13 AM, Aaron Meurer <[email protected]>
>>>>>>>> wrote:
>>>>>>>>> I have some high level questions about CSymPy.
>>>>>>>>>
>>>>>>>>> - What are the goals of the project?
>>>>>>>>
>>>>>>>> The goals of the project are:
>>>>>>>>
>>>>>>>> * Fastest symbolic manipulation library, compared to other codes,
>>>>>>>> commercial or opensource
>>>>>>>> (Sage, GiNaC, Mathematica, ...).
>>>>>>>>
>>>>>>>> * Extension/complement to SymPy
>>>>>>>>
>>>>>>>> * If the above two goals allow, be able to also call it from other
>>>>>>>> languages easily and efficiently (Julia, Ruby, Mathematica, ...)
>>>>>>>>
>>>>>>>> As to technical solution: the core should be a C++ library, which can
>>>>>>>> depend on other compiled libraries if needed.
>>>>>>>> The core should not depend on Python or Ruby or Julia, but rather be
>>>>>>>> just one language, C++. That lowers the barrier
>>>>>>>> of entry significantly, compared to a big mix of C++, Cython and
>>>>>>>> Python, makes it easier to make things fast
>>>>>>>> (you don't need to worry about Python at all). The Python (and other
>>>>>>>> languages) wrappers should be just a thin
>>>>>>>> wrappers around the C++ core (=just better syntax).
>>>>>>>>
>>>>>>>> There might be other technical solutions to this, but I know that I
>>>>>>>> can deliver the above goals with this solution
>>>>>>>> (and I failed to deliver with other solutions, like writing the core
>>>>>>>> in Cython). So that's why we do it this way.
>>>>>>>>
>>>>>>>> Also, by being "just a C++ library", other people can use it in their
>>>>>>>> projects. I hope to get interest of much broader
>>>>>>>> community that way, who can contribute back (somebody will need fast
>>>>>>>> symbolic manipulation in Julia, so they
>>>>>>>> can just use CSymPy with Julia wrappers, and contribute improvements
>>>>>>>> back).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - What are the things that should definitely go in CSymPy?
>>>>>>>>
>>>>>>>> At the moment: all things to make specific applications fast, in
>>>>>>>> particular PyDy. For that, it needs basic
>>>>>>>> manipulation, differentiation, series expansion (I think) and
>>>>>>>> matrices. That's all roughly either done, or
>>>>>>>> on the way. Of course, lots of polishing is needed.
>>>>>>>
>>>>>>> I think that's already too much. Why is the series expansion slow in
>>>>>>> SymPy? Is it because the algorithms are slow? If so, then implementing
>>>>>>> the same inefficient algorithms in CSymPy won't help. They will be
>>>>>>> faster, but for large enough expressions they will still slow down. Is
>>>>>>> it because the expression manipulation is slow? In that case, if
>>>>>>> CSymPy has faster expression manipulation, then just use those
>>>>>>> expressions, but use the SymPy series algorithms.
>>>>>>
>>>>>> My experience is that it will actually help to implement the same
>>>>>> algorithm,
>>>>>> because there is a little overhead with any Python operation.
>>>>>
>>>>> Exactly. There is a "little" overhead. Not a huge overhead. It matters
>>>>> for the stuff that is in the inner loops, like addition and
>>>>> multiplication of terms, but for whole algorithms, which might be
>>>>> called only a few times (as opposed to a few hundred thousand times),
>>>>> it doesn't make a difference.
>>>>>
>>>>> This is all hypothetical without numbers (and btw, it would be awesome
>>>>> if you could provide real numbers here), but suppose these imaginary
>>>>> numbers were true:
>>>>>
>>>>> SymPy: 1x
>>>>> CSymPy with Python wrappers: 4x
>>>>> Raw CSymPy: 5x
>>>>>
>>>>> Then using CSymPy with Python would already be 4x faster than SymPy.
>>>>> Now doing everything in SymPy would only be 1.25 faster than that.
>>>>>
>>>>> Now, if CSymPy integrates flawlessly, so that it just works (at least
>>>>> as far as the user is concerned), there is little complexity cost of
>>>>> CSymPy + Python. Definitely little enough to warrant the 4x speedup.
>>>>> But as soon as you take that away, i.e., you implement more and more
>>>>> in C++, or CSymPy differs enough from SymPy that the user needs to
>>>>> care about it (which the more that is in CSymPy, the more likely this
>>>>> is to happen), then the complexity cost sky rockets. Maybe 4x would
>>>>> still be worth it here. But not 1.25x.
>>>>>
>>>>>>So if you do
>>>>>> a lot of them (like in series expansion, where you create intermediate
>>>>>> expressions
>>>>>> and so on --- and even if we use CSymPy, there is overhead in the
>>>>>> Python wrappers,
>>>>>> so essentially you don't want to be calling them too often, if you
>>>>>> *really* care
>>>>>> about performance), they will add up.
>>>>>
>>>>> Sure, you could just implement a whole CAS in C++. That's what some
>>>>> people have done already. But you have to factor in the costs of
>>>>> everything, not just the speed. The costs of:
>>>>>
>>>>> - How much more complicated the code is
>>>>> - Code duplication (and all the associated issues that come with it)
>>>>> - The additional overhead needed for CSymPy to interop with SymPy. The
>>>>> more CSymPy does, the harder this is.
>>>>>
>>>>> Is series expansion slow? Is it an inner loop (i.e., will it matter to
>>>>> people if it is slow)? Is it simple to implement ('simple' being a
>>>>> relative term of course; obviously no part of a CAS is completely
>>>>> simple)? If the answer to any of those is "no", I think you should
>>>>> seriously consider whether it's worth implementing.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> My points are:
>>>>>>>
>>>>>>> - I think CSymPy should focus on making expression manipulation fast
>>>>>>> (i.e., the things that are the inner loop of any symbolic algorithm).
>>>>>>> It should not reimplement the symbolic algorithms themselves. Those
>>>>>>> are implemented in SymPy. If they use the CSymPy objects instead of
>>>>>>> the SymPy objects, they will be faster.
>>>>>>>
>>>>>>> - I would focus more on making CSymPy interoperate with SymPy and less
>>>>>>> on reimplementing things that are in SymPy in CSymPy. Once there is
>>>>>>> interoperation, we can see what is still slow, and then (and only
>>>>>>> then) implement it in C++.
>>>>>>
>>>>>> The interoperability is important and that is mostly the job of the
>>>>>> Python wrappers.
>>>>>> The C++ API underneath can change a lot, i.e. if we figure out a
>>>>>> faster way to represent
>>>>>> things, we'll switch. I will spend lots of time making the
>>>>>> interoperability work.
>>>>>> This summer though, I want to think hard about raw speed and making it
>>>>>> work
>>>>>> for PyDy.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - What are the things that should definitely not go in CSymPy?
>>>>>>>>
>>>>>>>> Things that don't need to be fast. Things like limits. Also things
>>>>>>>> that are in SymPy, where CSymPy can
>>>>>>>> be used as a drop in replacement for the engine: PyDy, some stuff in
>>>>>>>> physics, and so on. There is no need
>>>>>>>> to rewrite PyDy in C++. Also most user's code would stay in Python.
>>>>>>>> They can just optionally change
>>>>>>>> to CSymPy for some intensive calculation, then finish the thing with
>>>>>>>> SymPy.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - How will CSymPy be architectured to allow things to happen in CSymPy
>>>>>>>>> when they can but fallback to SymPy when they cannot.
>>>>>>>>
>>>>>>>> Currently you can simply mix and match SymPy and CSymPy expressions.
>>>>>>>> So you simply
>>>>>>>> convert an expression to SymPy to do some advanced manipulation, and
>>>>>>>> convert to CSymPy
>>>>>>>> to do some fast manipulation. I am open to suggestions how to improve
>>>>>>>> this.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> My main concern here is that CSymPy has not clear separation from
>>>>>>>>> SymPy, and as a result it will end up growing larger and larger, until
>>>>>>>>> it becomes an independent CAS (which is fine if that's the goal, but
>>>>>>>>> my understanding was that it was supposed to be just a small fast
>>>>>>>>> core).
>>>>>>>>
>>>>>>>> The goals are written above. I am myself concentrating on speed,
>>>>>>>> that's what I really
>>>>>>>> want to nail down. And then enough features so that it's useful for
>>>>>>>> all the people who
>>>>>>>> found SymPy slow. However, let's say somebody comes and reimplements
>>>>>>>> the Gruntz
>>>>>>>> algorithm in CSymPy. Should we reject such a PR? My answer is that if
>>>>>>>> the code is nice,
>>>>>>>> maintainable, much faster than SymPy and has the same or similar
>>>>>>>> features, I am ok
>>>>>>>> with merging it. If the code is a mess, then not. But as I said, I am
>>>>>>>> spending my own
>>>>>>>> time on things which people need, and faster limits don't seem to be
>>>>>>>> it.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> In particular, if there is some feature of SymPy functions, how will
>>>>>>>>> CSymPy be architectured so that it can take advantage of it without
>>>>>>>>> having to completely reimplement that function in C++?
>>>>>>>>
>>>>>>>> You can convert any expression back and forth, so you keep it in SymPy
>>>>>>>> if you want to have some particular feature. See also the conversation
>>>>>>>> and specific examples here:
>>>>>>>>
>>>>>>>> https://github.com/sympy/csympy/issues/153
>>>>>>>>
>>>>>>>>>
>>>>>>>>> For instance, a current goal of CSymPy is to implement trig functions.
>>>>>>>>> But this can be quite complicated if you consider all the different
>>>>>>>>> things you can do with trig functions. Without even thinking about
>>>>>>>>> trig simplification, there are complicated evaluation issues (e.g.,
>>>>>>>>> consider sin(pi/7).rewrite(sqrt) in SymPy). It would be a shame to
>>>>>>>>> reimplement all this logic twice, especially it is not needed for
>>>>>>>>> performance.
>>>>>>>>
>>>>>>>> Agreed. On the other hand, we really need very fast trig functions.
>>>>>>>> The functionality
>>>>>>>> that we need is simplifications like sin(2*pi) -> 0, differentiation
>>>>>>>> and series expansion.
>>>>>>>
>>>>>>> Why do you need to implement those in C++? If the expression
>>>>>>> manipulation is fast, then won't it be fine to have the actual
>>>>>>> formulas/algorithms in SymPy?
>>>>>>
>>>>>> Maybe, that depends on this issue:
>>>>>>
>>>>>> https://github.com/sympy/csympy/issues/153
>>>>>>
>>>>>> The problem is that once you start thinking about Python+C++ at once
>>>>>> and performance, things get complex quickly. It's much easier
>>>>>> to think in terms of C++ only and how to write the fastest possible
>>>>>> algorithm
>>>>>> (that is hard enough!). This sets the bar. Then one should try to see
>>>>>> if it is possible to match this with Python. Not the other way round,
>>>>>> because you need to set the bar first.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 22, 2014 at 6:16 PM, Aaron Meurer <[email protected]> wrote:
>>>>>>> On Tue, Apr 22, 2014 at 4:58 PM, Joachim Durchholz <[email protected]>
>>>>>>> wrote:
>>>>>>>> Hm.
>>>>>>>>
>>>>>>>> One:
>>>>>>>>> * Extension/complement to SymPy
>>>>>>>>
>>>>>>>> Two:
>>>>>>>>
>>>>>>>>
>>>>>>>>> That lowers the barrier
>>>>>>>>> of entry significantly, compared to a big mix of C++, Cython and
>>>>>>>>> Python, makes it easier to make things fast
>>>>>>>>> (you don't need to worry about Python at all).
>>>>>>>>
>>>>>>>>
>>>>>>>> That's not an extension nor a complement, it's a replacement.
>>>>>>>>
>>>>>>>>
>>>>>>>>> The Python (and other
>>>>>>>>>
>>>>>>>>> languages) wrappers should be just a thin
>>>>>>>>> wrappers around the C++ core (=just better syntax).
>>>>>>>>
>>>>>>>>
>>>>>>>> I.e. replace the engine if not the API.
>>>>>>>>
>>>>>>>> Not that I'm judging. I'm just pointing out perceived inconsistencies.
>>>>>>>>
>>>>>>>> The more SymPy itself turns into a set of simplification rulese, the
>>>>>>>> less
>>>>>>>> significance this will have in the end.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> - How will CSymPy be architectured to allow things to happen in
>>>>>>>>>> CSymPy
>>>>>>>>>> when they can but fallback to SymPy when they cannot.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Currently you can simply mix and match SymPy and CSymPy expressions.
>>>>>>>>> So you simply
>>>>>>>>> convert an expression to SymPy to do some advanced manipulation, and
>>>>>>>>> convert to CSymPy
>>>>>>>>> to do some fast manipulation. I am open to suggestions how to improve
>>>>>>>>> this.
>>>>>>>>
>>>>>>>>
>>>>>>>> The alternative would be to have a data structure that can be
>>>>>>>> manipulated
>>>>>>>> from both the C++ and the Python side, but that's going to be
>>>>>>>> unnatural for
>>>>>>>> at least one of the sides.
>>>>>>>>
>>>>>>>> Note that the data structures can become large-ish, and if the
>>>>>>>> simplification becomes complicated there may be a lot of
>>>>>>>> back-and-forth.
>>>>>>>> It's possible that mixed execution will be slow for some algorithms or
>>>>>>>> use
>>>>>>>> cases for that reason.
>>>>>>>>
>>>>>>>> I do not think that this can be determined in advance, it's something
>>>>>>>> to
>>>>>>>> keep an eye out for during benchmarks.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> My main concern here is that CSymPy has not clear separation from
>>>>>>>>>> SymPy, and as a result it will end up growing larger and larger,
>>>>>>>>>> until
>>>>>>>>>> it becomes an independent CAS (which is fine if that's the goal, but
>>>>>>>>>> my understanding was that it was supposed to be just a small fast
>>>>>>>>>> core).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The goals are written above. I am myself concentrating on speed,
>>>>>>>>> that's what I really
>>>>>>>>> want to nail down.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm somewhat sceptical about this.
>>>>>>>> A conversion to C++ will give a linear improvement.
>>>>>>>> Better algorithms can improve the big-Oh class.
>>>>>>>> Unless algorithmic improvements have been exhausted, this would be
>>>>>>>> premature
>>>>>>>> optimization. (Are algorithmic improvements exhausted yet?)
>>>>>>>
>>>>>>> That is true. I usually prefer to use faster algorithms.
>>>>>>>
>>>>>>> But to be the devil's advocate, there are two issues with this line of
>>>>>>> thinking:
>>>>>>>
>>>>>>> - Big O is basically useless. Consider the extreme effectiveness of
>>>>>>> SAT solvers (which solve an NP-complete problem), or the difference
>>>>>>> between the simplex and Khachiyan's algorithm, or AKS vs. more
>>>>>>> efficient deterministic primality testing algorithms. Asymptotic
>>>>>>> complexity is all fine, but at the end of the day, you don't care how
>>>>>>> fast your algorithm is for increasingly large inputs, you care how
>>>>>>> fast it is for *your* input.
>>>>>>>
>>>>>>> - Faster algorithms have a complexity cost. You can get closer to the
>>>>>>> metal in Python by being very careful about your use of data
>>>>>>> structures, and avoiding things that are slow in Python (like function
>>>>>>> calls), but the cost is high because you end up with code that is not
>>>>>>> only harder to read and maintain, but harder to keep in its fast
>>>>>>> state, because someone else who doesn't know all the little tricks
>>>>>>> might come along and change things in a way that seems equivalent but
>>>>>>> makes things slower.
>>>>>>
>>>>>> Precisely. That's why it's good to stick to just one language, C++, and
>>>>>> nail
>>>>>> the speed. That sets the bar. Then one can try to match the speed with
>>>>>> Python,
>>>>>> which sometimes is possible.
>>>>>>
>>>>>>>
>>>>>>> With that being said, C++ is itself enough of a complexity cost that
>>>>>>> doing this outweighs using it in many (most?) cases. (That's not just
>>>>>>> a knock on C++; using any second language to Python brings a cost,
>>>>>>> both because there are now two languages to think about, and because
>>>>>>> of interoperability questions)
>>>>>>
>>>>>> Yes, again the reason why to stick to just one language and only do thin
>>>>>> wrappers that allow to use it as a blackbox.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 22, 2014 at 6:23 PM, Brian Granger <[email protected]>
>>>>>> wrote:
>>>>>>> I too feel that csympy should implement the absolute minimum possible
>>>>>>> for it to be fast. All actual mathematical algorithms should remain in
>>>>>>> sympy. Trying to pull lots of algorithms into csympy will fail - not
>>>>>>> that many people want to write complex mathematical algorithms in C++.
>>>>>>
>>>>>>
>>>>>> I understand your worries. Both yours and Aaron's and other people in
>>>>>> the SymPy community.
>>>>>> Let's be frank about this, here they are:
>>>>>
>>>>> Thanks for your frankness. So I think you do understand the issues.
>>>>>
>>>>>>
>>>>>> * keep things simple, maintainable, in Python, not introducing other
>>>>>> languages
>>>>>>
>>>>>> * especially not C++, which is notorious for being hilariously
>>>>>> complex. That's why we use Python, because it's better.
>>>>>
>>>>> Well, there are also languages that are fast and not C++, but we can
>>>>> have that discussion separately.
>>>>>
>>>>>>
>>>>>> * danger of splitting a community by introducing a separate CAS
>>>>>> (=wasting our resources, attention, developers, and so on), and we've
>>>>>> been on this path before, e.g. with with sympycore, or even Sage ---
>>>>>> any improvement to those codes does not benefit SymPy. That does not
>>>>>> mean that there is anything bad with those, but one has to try to
>>>>>> focus, in our case SymPy, and just get things done, make it a useful
>>>>>> library so that people can use it and benefit from it.
>>>>>>
>>>>>> * that we should concentrate on features, and sacrifice some
>>>>>> reasonable speed (maybe 100x or so).
>>>>>>
>>>>>> * We should not be reimplementing SymPy in C++, that would be a big
>>>>>> waste.
>>>>>
>>>>> One of my worries is not listed here, which is that you are doing
>>>>> things completely backwards from good software design with CSymPy,
>>>>> which is getting speed first, and something that works later.
>>>>
>>>> The goal is to get something that works first, polished API later.
>>>> By "work" I mean fast and working for PyDy (at first).
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> I thought about all these very deeply. And I can promise that I will
>>>>>> do my absolute best to make this work, with the SymPy community. I
>>>>>> might not have the best answer to all the worries, but I know that we
>>>>>> need to set the bar:
>>>>>>
>>>>>> * So implement trig functions in C++
>>>>>> * Benchmark against Mathematica, Sage, GiNaC
>>>>>> * Make sure it is as fast or faster
>>>>>> * See if we can match it with Python
>>>>>> * If so, great! If not, what is the penalty? 2x? 10x? 100x?
>>>>>
>>>>> That is exactly what I want to know.
>>>>>
>>>>>>
>>>>>> If we don't have this bar, then we miss on speed. And if we miss on
>>>>>> speed then there will always be reason why people would use other
>>>>>> software, because of speed. If, on the other hand, csympy is as fast
>>>>>> as state of the art, then it fixes the problem. And it will be
>>>>>> integrated with SymPy well, people can keep using SymPy.
>>>>>>
>>>>>> Ondrej
>>>>>
>>>>> I feel like without real numbers, we aren't going to get anywhere, so
>>>>> maybe you could provide some benchmarks. I'm not convinced about
>>>>> expand, because that relies pretty heavily on other things like
>>>>> multinomial coefficient generation. I'd rather see a benchmark that
>>>>> does the exact same expression manipulations everywhere.
>>>>>
>>>>> Feel free to suggest a better one. I'm just coming up with this from
>>>>> the seat of my pants, but something like
>>>>>
>>>>> a = x
>>>>> c = 1
>>>>> for i in range(1000): # Replace with larger numbers if necessary
>>>>> a += c*i*x # If CSymPy expressions are mutable modify this accordingly
>>>>> c *= -1
>>>>
>>>> Sure. Here is the code:
>>>>
>>>> from csympy import var, Integer
>>>> #from sympy import var, Integer
>>>> var("x")
>>>> a = x
>>>> c = Integer(1)
>>>> N = 10**5
>>>> for i in range(N):
>>>> a += c*i*x
>>>> c *= -1
>>>> print a
>>>>
>>>>
>>>> SymPy:
>>>>
>>>> $ time python a.py
>>>> -49999*x
>>>>
>>>> real 0m35.262s
>>>> user 0m34.870s
>>>> sys 0m0.300s
>>>>
>>>> CSymPy:
>>>>
>>>> $ time python a.py
>>>> -49999x
>>>>
>>>> real 0m0.860s
>>>> user 0m0.852s
>>>> sys 0m0.004s
>>>>
>>>
>>> Comparing sympy.polys and sympy.core:
>>>
>>> In [1]: R, x = ring("x", ZZ)
>>>
>>> In [2]: y = Symbol("y")
>>>
>>> In [3]: N, a, c = 10**5, x, ZZ(1)
>>>
>>> In [4]: %time for i in range(N): a += c*i*x; c *= -1
>>> CPU times: user 564 ms, sys: 4.85 ms, total: 569 ms
>>> Wall time: 555 ms
>>>
>>> In [5]: N, a, c = 10**5, y, Integer(1)
>>>
>>> In [6]: %time for i in range(N): a += c*i*y; c *= -1
>>> CPU times: user 20 s, sys: 133 ms, total: 20.1 s
>>> Wall time: 20 s
>>>
>>>>
>>>> So this particular one is 41x faster in CSymPy. You can modify this to
>>>> generate some long expressions, e.g.:
>>>>
>>>> from csympy import var, Integer
>>>> #from sympy import var, Integer
>>>> var("x")
>>>> a = x
>>>> c = Integer(1)
>>>> N = 3000
>>>> for i in range(N):
>>>> a += c*x**i
>>>> c *= -1
>>>>
>>>> SymPy:
>>>>
>>>> $ time python a.py
>>>>
>>>> real 0m37.890s
>>>> user 0m37.626s
>>>> sys 0m0.152s
>>>>
>>>> CSymPy:
>>>>
>>>> $ time python a.py
>>>>
>>>> real 0m1.032s
>>>> user 0m1.020s
>>>> sys 0m0.012s
>>>>
>>>
>>> Comparing sympy.polys and sympy.core:
>>>
>>> In [1]: R, x = ring("x", ZZ)
>>>
>>> In [2]: y = Symbol("y")
>>>
>>> In [3]: N, a, c = 3000, x, ZZ(1)
>>>
>>> In [4]: %time for i in range(N): a += c*x**i; c *= -1
>>> CPU times: user 148 ms, sys: 4.3 ms, total: 152 ms
>>> Wall time: 147 ms
>>>
>>> In [5]: N, a, c = 3000, y, Integer(1)
>>>
>>> In [6]: %time for i in range(N): a += c*y**i; c *= -1
>>> CPU times: user 20.6 s, sys: 42.6 ms, total: 20.6 s
>>> Wall time: 20.6 s
>>>
>>> So, what's the difference between CSymPy's +=, *=, *, **, etc.
>>> operators and SymPy's ones? Are they in-place? What are the underlying
>>> data structures? Do they use the same set of rewrite rules? Do they
>>> take assumptions into account? When comparing sympy.polys and
>>> sympy.core, it's obvious that sympy.polys will be faster because it
>>> simply does a lot less compared to sympy.core.
>>>
>>>>
>>>> This one is 37x faster. Sage takes about 3s on this benchmark. And so on.
>>>>
>>>> We need to also benchmark Mathematica and GiNaC.
>>>>
>>>>>
>>>>> This is a very basic test of how well terms are combined with
>>>>> addition. It also creates a lot of terms, which might penalize a
>>>>> system with too much caching (maybe it should be modified to not do
>>>>> that; I don't know).
>>>>>
>>>>> 1000 should really be replaced with a much larger number, say
>>>>> 10000000. Basically, if a benchmark runs in under a second, I'm weary
>>>>> of it. That means you're benchmarking things that might be irrelevant
>>>>> for larger expressions, when the speed really matters. I suppose
>>>>> really you should benchmark 10**N for some range of N and plot the
>>>>> results.
>>>>
>>>> Exactly, plot depending on N is the best.
>>>>
>>>> Ondrej
>>>>
>>>>>
>>>>> That's just one benchmark, that tests one thing. We need to benchmark
>>>>> all the major aspects of the core. A few others that come to mind:
>>>>>
>>>>> - x1*...*xn + x2*...*xn*x1 + ... (basically, test that large
>>>>> multiplications in different orders are efficiently canonicalized to
>>>>> the same thing)
>>>>> - (some large addition) - (the same addition, in a different order)
>>>>> - x**x**x**x**...**x (do some stuff with it; basically test that
>>>>> highly nested expressions don't kill things. You could also test
>>>>> sin(sin(sin(sin(...(x)...) or something)
>>>>> - (Huge complicated expression in x).subs(x, y) (CSymPy implements
>>>>> some kind of subs or xreplace natively, right?)
>>>>>
>>>>> It actually would be nice to have some kind of benchmarking site for
>>>>> SymPy, similar to http://speed.pypy.org/.
>>>>>
>>>>> Aaron Meurer
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "sympy" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>>> email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at http://groups.google.com/group/sympy.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6KX8h7FRnKWa%2BjFihSfiu-9rrexYZmjXymOimLsUQ7BeQ%40mail.gmail.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "sympy" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/sympy.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/sympy/CADDwiVCEo1q-UvKv_bpsDn%3DT3d8suxNqdVnvN8dBeEV7j3CQ4w%40mail.gmail.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> Mateusz
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sympy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/sympy.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sympy/CAGBZUCYOdhOWdBHkkYQmpPqv3Aic9d3p%2BZO4NfBNh0z%2BkV75vg%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/sympy.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6J1C%2BDixoDwVfxZZj5nCfQ9oN5wH%3DUQwhWmJ76mr%2BCmfA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAGBZUCaD82F3nFm8QUtviX%3DVqor%2BW904v5hfH658DWCS%2BppAfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
