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. Aaron Meurer -- 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.
