On Wed, Apr 23, 2014 at 5:36 PM, Ondřej Čertík <[email protected]> wrote:
> On Wed, Apr 23, 2014 at 4:31 PM, Ondřej Čertík <[email protected]>
> wrote:
>> On Wed, Apr 23, 2014 at 4:27 PM, Aaron Meurer <[email protected]> wrote:
>>> Well that would only affect what you do in your own workspace. Much
>>> better would be if sympy transparently imported and used csympy
>>> wherever relevant when it was available, so that sympy.Symbol would be
>>> csympy.Symbol, and so on. Then everywhere in sympy would use csympy.
>>
>> That's a good idea. There is of course the issue with assumptions,
>> attached to the Symbols...
>>
>>>
>>> But this requires full interoperability between sympy and csympy
>>> (which is one of the things I have not seen yet). I think the next
>>> task for csympy should be:
>>>
>>> - Patch sympy/core/symbol.py to use csympy.Symbol (so that from
>>> sympy.core.symbol import Symbol gives csympy.Symbol)
>>> - Run the tests
>>> - Fix whatever fails
>>> - Repeat with further csympy objects
>>>
>>> And always do this with every csympy object that is written. We
>>> perhaps need a more unified way to automatically replace anything in
>>> sympy with csympy (especially since Ondrej still hasn't provided a
>>> clear separation between what will and will not be in csympy, at least
>>> in my mind).
>>>
>>> Then we can stop making these artificial benchmarks and performance
>>> speculations, and just see what really is slow, and what really speeds
>>> things up, and, just as importantly, what doesn't speed things up
>>> enough to warrant the complexity cost.
>>>
>>> I would focus on this rather than PyDy specifically. It may be
>>> possible to use csympy in PyDy without doing this, but it will be a
>>> wasted effort if you eventually do this and then the PyDy specific
>>> implementation can be scrapped.
>>
>> The goal of using CSymPy in PyDy is precisely to do this switch
>> (single line of code)
>> in PyDy only, not the core of SymPy. Because that's a lot simpler (no
>> need to worry
>> about assumptions) and tons of tests. And doing a real application
>> where speed matters.
>
> So that we are not just talking, here is the actual code:
>
> https://github.com/sympy/sympy/pull/7397
Good, now we are hitting real concrete issues.
>
> It's simple, and we are still trying to make it more simple (=more compatible
> with SymPy), until it is really just one line. There are some technical issue
> like our Function("f") would correspond to just raw class in C++, except that
> C++ doesn't support that, so I have a function called function_symbol("f", x),
> and so on. This could be abstracted in the Python wrappers and so on. This
> will all be fixed eventually.
This is something that should be fixed. See
https://github.com/sympy/sympy/issues/4787.
In fact, one of the reasons I suggested this is so that we could see
what the limitations are in the SymPy API (it's not perfect, and
shouldn't be assumed so). This is one of them. But it won't be good if
we "fix" the SymPy API and then much later try to integrate CSymPy and
discover that the real issues were not fixed at all.
In short, to succeed, CSymPy and SymPy should know about each other
sooner rather than later.
>
> Aaron, I think you want to have full compatibility with SymPy immediately. But
> there could be significant speed/efficiency cost, and I need to make
> sure that the
> speed of the C++ core is optimal.
Yes, because otherwise you are optimizing what you think should be
fast, rather than what you know should be fast from hard data.
>
> The time frame is roughly this summer, when we implement enough features
> to be useful for PyDy and do some serious benchmarking on real world problems.
> After that it would be good time to review the Python API to make sure
> it works well
> with SymPy and start integrating it more. For now I just keep things
> simple to get the job done.
But how do you know what should be fast and what isn't important
unless you have some kind of integration from the start? It doesn't
have to be perfect, but it should be enough to run the actual code
against CSymPy so that you can see if real things are getting faster,
and what real things are being slow.
Aaron Meurer
>
> Ondrej
>
>>
>> After that, do this in sympy.core --- that requires tackling
>> assumptions and maybe few
>> other things.
>>
>> Ondrej
>>
>>>
>>> Aaron Meurer
>>>
>>> On Wed, Apr 23, 2014 at 5:19 PM, Matthew Rocklin <[email protected]> wrote:
>>>> Perhaps a good target workflow would be something like the following
>>>>
>>>> from sympy import *
>>>> from csympy import *
>>>>
>>>> ... do work as usual ...
>>>>
>>>> In other words it would be nice for csympy to take over from sympy where it
>>>> has functionality, but for sympy-proper to fill in all of the holes.
>>>> Ondrej, is this on your roadmap at all?
>>>>
>>>> It gets weird of course when you have something like Expr(...) + CExpr(...)
>>>>
>>>> --
>>>> 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/CAJ8oX-Fh%3DFR5LM2Uehn%2BWTdFs%3D8QBys%2B2BoPXUdZKgdWeHaqbA%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%3D6Kn9fKNFN7uNya_pLaj0%2Bqy0d%3DisZ8_6SKdp8sGwwBMKQ%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/CADDwiVD_Knxf1%2B82-vmGOyPA%3DWfZgg1Np3PMyUDHoYaRzt4nqA%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%3D6%2BoctaCyM52VjYtsBud%2B305dEWJqtEEfwnFrW4z6jVcFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
