Remove _op_priority before the release?
Ronan Lamy
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/810e127bc41a44e5/5a7d92372b3a05cf?hl=en_US&lnk=gst&q=_op_priority#5a7d92372b3a05cf)
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.
Vinzent Steinberg
> _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
>
> 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.
Vinzent
Aaron Meurer
http://code.google.com/p/sympy/issues/detail?id=1941, but that would
require a bit of rewriting of the core that I wouldn't even attempt
before the assumptions are removed.
Brian, how do you feel about this?
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
Ronan Lamy
Brian Granger
+1
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu and elli...@gmail.com
Andy Ray Terrel
> On Sat, May 14, 2011 at 1:49 PM, Vinzent Steinberg
> <vinzent....@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.
In fact I was just about to mail the list about getting rid of all the
hard coded Mul and Add in the core.
-- Andy
Ronan Lamy
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?
Andy Ray Terrel
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]
-- Andy
[0] https://github.com/aterrel/ignition/tree/master/ignition/flame/tensors
[1] http://code.google.com/p/sympy/issues/detail?id=2411
>> In fact I was just about to mail the list about getting rid of all the
>> hard coded Mul and Add in the core.
>
>
>
Ondrej Certik
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.
Ondrej
Andy Ray Terrel
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
Aaron S. Meurer
>> 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
Ronan Lamy
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.
Ondrej Certik
How does pymbolic handle this issue?
Ondrej
Andy Ray Terrel
Andreas told me Pymbolic works on a graph and you register visitor classes.
Unfortunately reading his code [0] doesn't actually handle this. =(
Maybe that is why he was so easily convinced to move to SymPy.
[0] http://git.tiker.net/pymbolic.git/blob/HEAD:/pymbolic/primitives.py
Ronan Lamy
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...
Ronan Lamy
It seems quite doable, actually. I'll be able to send a pull request in
a day or two, I think.
Andy Ray Terrel
I look forward to your code.
FWIW, there has been some discussion of this issue on the other thread:
-- Andy
Ondrej Certik
If the better code can't be merged in, I vote for reverting the
"remove" patch, so that Andy can release together with sympy.
Ondrej