Le lundi 23 mai 2011 à 01:38 +0100, Ronan Lamy a écrit : > Le dimanche 22 mai 2011 à 17:25 +0100, Ronan Lamy a écrit : > > Le dimanche 22 mai 2011 à 09:51 -0600, Aaron S. Meurer a écrit : > > > On May 22, 2011, at 9:34 AM, Andy Ray Terrel wrote: > > > > > > > On Sat, May 21, 2011 at 10:51 PM, Ondrej Certik <ond...@certik.cz> > > > > wrote: > > > >> On Sat, May 21, 2011 at 8:21 PM, Andy Ray Terrel > > > >> <andy.ter...@gmail.com> wrote: > > > >>> On Sat, May 21, 2011 at 10:10 PM, Ronan Lamy <ronan.l...@gmail.com> > > > >>> wrote: > > > >>>> Le samedi 21 mai 2011 à 21:50 -0500, Andy Ray Terrel a écrit : > > > >>>>> On Sun, May 15, 2011 at 6:54 PM, Brian Granger > > > >>>>> <elliso...@gmail.com> wrote: > > > >>>>>> On Sat, May 14, 2011 at 1:49 PM, Vinzent Steinberg > > > >>>>>> <vinzent.steinb...@googlemail.com> wrote: > > > >>>>>>> On 14 Mai, 18:31, Ronan Lamy <ronan.l...@gmail.com> wrote: > > > >>>>>>>> _op_priority was designed to help with implementing arithmetic > > > >>>>>>>> operations, particularly for things that aren't "calculus > > > >>>>>>>> expressions" > > > >>>>>>>> yet have meaningful __add__, __mul__, __pow__, etc. such as > > > >>>>>>>> vectors and > > > >>>>>>>> operators of various kinds. But it turns out that it doesn't > > > >>>>>>>> really help > > > >>>>>>>> (http://groups.google.com/group/sympy/browse_thread/thread/810e127bc41...) > > > >>>>>>>> and it isn't used anywhere currently. > > > >>>>>>>> > > > >>>>>>>> It also has fundamental flaws that prevent it from ever evolving > > > >>>>>>>> into a > > > >>>>>>>> complete solution to the problem: it assumes that the priority > > > >>>>>>>> order is > > > >>>>>>>> the same for all operations and turns this order into a total > > > >>>>>>>> order, > > > >>>>>>>> introducing couplings between objects that would otherwise have > > > >>>>>>>> no > > > >>>>>>>> knowledge of each other. > > > >>>>>>>> > > > >>>>>>>> So, I think that there's little benefit in including into 0.7.0, > > > >>>>>>>> but it > > > >>>>>>>> would have the significant drawback of committing us to support > > > >>>>>>>> this > > > >>>>>>>> feature for who knows how long, and therefore of making much more > > > >>>>>>>> difficult to refactor this critical mechanism. And if > > > >>>>>>>> _op_priority does > > > >>>>>>>> turn out to be useful, it can easily be added back in after the > > > >>>>>>>> release > > > >>>>>>>> by reverting the removal. > > > >>>>>>> > > > >>>>>>> If it is not used, I think we can remove it. > > > >>>>>> > > > >>>>>> +1 > > > >>>>>> > > > >>>>> > > > >>>>> Please don't do this. I use op_priority all the time. Its the one > > > >>>>> reason I haven't release my code because I depend on this > > > >>>>> functionality. > > > >>>> > > > >>>> You're a bit late: it's been removed already, in > > > >>>> 041995d37563f1e0743c75a311035b553f66741e. But we could revert that > > > >>>> commit. Can you open an issue and link to code that uses > > > >>>> _op_priority? > > > >>>> > > > >>> > > > >>> Hmm the last three weeks have been a blur for me. > > > >>> > > > >>> My whole tensor library [0] depends on it, and I thought it was a > > > >>> great > > > >>> idea even if it seems incomplete because core code will just call Mul, > > > >>> Add, ... never giving the custom call a callback. > > > >>> > > > >>> issue opened at [1] > > > >> > > > >> Does anyone know a better solution to fix this problem? > > > >> > > > >> If not, then I am +1 to push it back in, and improve upon it later. > > > >> > > > >> Andy -- is sympy missing some tests, that your library depends on? If > > > >> so, we should add it into sympy, so that we make sure things don't get > > > >> broken. Once somebody implements a better solution, we'll simply > > > >> provide an upgrade path. > > > > > > > > test_priority from that commit was what I was using. But roughly I > > > > need multiple dispatch so I can override the dispatch of the algebraic > > > > operators. If SymPy doesn't want to support this I can move to the > > > > pymoblics system. > > > > > > > > -- Andy > > > > > > > >> > > > >> Ondřej > > > > > > _op_priority is kind of a bad way to do this, in my opinion, but I > > > don't know of another way to do it that would be as easy to implement. > > > Does anyone have any ideas? Otherwise, I suggest we use and support it > > > until we come up with a better system. > > > > The right way is to implement double-dispatch the way it's supposed to > > be implemented: > > http://docs.python.org/library/numbers.html#implementing-the-arithmetic-operations > > > > This might not be that hard, if we don't simultaneously have to support > > _op_priority. Having Expr.__add__ return NotImplemented would already go > > a long way. I'll give it a try. > > > > That doesn't work so well, because of the tangled dependencies between > Add, Mul, Pow and the Number subclasses operators. I'm now trying to > straighten this out. Hopefully that rabbit hole isn't as deep as it > seems... >
It seems quite doable, actually. I'll be able to send a pull request in a day or two, I think. -- 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 email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
