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