On Tue, Mar 13, 2012 at 1:43 AM, Joachim Durchholz <[email protected]> wrote: > Am 11.03.2012 22:48, schrieb Aaron Meurer: > >>> IOW fully general double dispatch means you have to think about and fill >>> out >>> ALL cells in the matrix. >>> Which means that the matrix cannot be extended in more than one direction >>> independently. >> >> >> Right, we have to accept that there will be certain combinations that >> are undefined with this, because of conflicting rules. That's >> actually an important consideration, and one of the reasons that I >> wanted to make that wiki page that lists everything. FWIW, I think >> that undefined combinations should remain just that, undefined, i.e., >> they can return anything within the constructs of either definition. > > > In that case you'd have to check that both constructs Do The Right Thing. > Otherwise, changes somewhere up the hierarchy might make any unit test that > uses subclasses fail. > > I'd suggest making the undefined matrix cells truly undefined, i.e. calling > them throws an error. That forces whoever integrates two type hierarchies to > make sure that the combinations are correct (probably by contacting the > authors of the extensions and work the combination out).
One problem is that it's not really a Matrix. Classes like Mul and Add are container objects that can hold any number of items. If we want to assert commutativity and associativity (the latter is actually implied by the n-ary-ness of the container), we must define operations on any combination. In practice, this isn't an issue because rules can be generalized. oo combines with any finite real number in an Add, no matter how many there are, for example. Aaron Meurer > > >>> Counter-question: Do we actually do code coverage analysis? >> >> >> Yes. See the bin/coverage_report.py script. Thanks to the work of >> people like Chris, and many of our GCI students, we actually have >> pretty good coverage right now. > > > Ah, sweet. I wasn't aware of that. > > >>>> - Code can be much simpler if the rules follow some kind of pattern, >>>> because you can then just code the pattern. You might say that that's >>>> also possible with data, but then you are just doing things in code >>>> anyway, but in a more circuitous way. >>> >>> >>> Patterns can be factored out in code just as in data. >> >> >> No, I meant that patterns can be factored out only in code, not in >> data. Because you have the full power of programmability when you do >> things in code, whereas data will be limited to whatever level of >> power you give it > > > More power also means more potential for unexpected side effects. > I still stand by my words. > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
