On Sun, May 22, 2011 at 8:34 AM, Andy Ray Terrel <andy.ter...@gmail.com> 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.
How does pymbolic handle this issue? Ondrej -- 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.
