Ah, must have missed it, fortunately Aaron bright up the same point. My response:
I can see the reasoning here but slightly disagree. Both implementations are presumably valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm stealing a good amount of inspiration. Perhaps it would make sense to reach out to the Julia folks and ask about their experiences. And then I suggest that sympy could catch warnings and throw errors. In my PRs I use a small module sympy. dispatch rather than the raw dispatch in multipledispatch On Apr 2, 2014 4:34 PM, "Ondřej Čertík" <ondrej.cer...@gmail.com> wrote: > I already asked this, but didn't get a reply: I really think it should > raise an exception on ambiguity by default. You can allow the user to > explicitly override this behavior if you know what you are doing. > > Sent from my mobile phone. > On Apr 2, 2014 4:42 PM, "Matthew Rocklin" <mrock...@gmail.com> wrote: > >> If it is possible to catch warnings then we could catch an MD warning and >> raise an error in SymPy if we wanted. My PRs introducing MD into SymPy >> include a tiny sympy.dispatch module rather than using MD directly. There >> is little stopping us from tailoring some of the behavior to fit SymPy's >> priorities. >> >> >> On Wed, Apr 2, 2014 at 3:33 PM, Matthew Rocklin <mrock...@gmail.com>wrote: >> >>> Not all of the ties result from ambiguities. For example the >>>>> signatures (int,) and (float,) tie. Which should come first in the >>>>> toposort? >>>>> >>>> >>>> For what input? >>>> >>> >>> How MD operates now is that it forms a graph of signatures with an edge >>> between two signatures if one is more specific than the other. It then >>> topologically sorts this graph to form a linear ordering. When inputs come >>> in we get their types and then compare those types against each of the type >>> signatures in the linear ordering from most to least specific (by the >>> topological sort). Once we find a match we return the function that was >>> registered with the matching signature. In this way we get to use >>> issubclass and are also assured that we aren't missing a more specific >>> signature. >>> >>> So, in the float/int case our graph is just two disconnected nodes and >>> our ordering might look like >>> >>> [(int,), (float,)] >>> >>> When an input comes in, like 1.0, we get it's types, (float,), and then >>> ask issubclass(float, int), get no, and move on to ask if issubclass(float, >>> float). This works so we return the function associated with (float,). >>> >>> (Although actually we first just check in a dict to see if we have the >>> type signature exactly, which we do in this case, so we return in constant >>> time) >>> >>> >>>> I would definitely raise an exception here. You can maybe play with >>>> ways for people to tell the dispatcher how they want it to break ties, but >>>> the default implementation shouldn't take sides. >>>> >>> >>> I can see the reasoning here but slightly disagree. Often both >>> implementations are perfectly valid and you should just pick one. This is >>> also consistent with the standard set out by the Julia Language, from which >>> I'm stealing a good amount of inspiration. >>> >>> Couldn't you resolve the ambiguity by adding additional dispatch against >>>> (float, float)? >>>> >>> >>> Yes, this is what is suggested automatically by MD. Perhaps I don't >>> understand your comment. >>> >>> >>>> I don't think it's right to do this check at registry time. >>>> >>> >>> I'm not sure that I understand this either. When would you do the check? >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sympy+unsubscr...@googlegroups.com. >> To post to this group, send email to sympy@googlegroups.com. >> Visit this group at http://groups.google.com/group/sympy. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.com<https://groups.google.com/d/msgid/sympy/CAJ8oX-FZ%3DPFqaiePYfu%3Db8MpNdYEAxeuXFfMwpCJawh0SXwzgQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CADDwiVATGaBzjoOzw2CiuTjQrC1fkt%2B-M-hkiON8qO35J6uKcg%40mail.gmail.com<https://groups.google.com/d/msgid/sympy/CADDwiVATGaBzjoOzw2CiuTjQrC1fkt%2B-M-hkiON8qO35J6uKcg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAJ8oX-ECk%2BzUkDpMG4V72PEUntTdZJ-%3DJp8mXq0NgizP92zGgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
