[petsc-dev] MatMatMult double dispatch

[Dmitry Karpeev]

On Fri, Oct 28, 2011 at 4:08 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Oct 28, 2011 at 15:00, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
>> Why does the double dispatch for A*B only looks for the implementation in
>> B's FList?
>> Is there any deep reason for this?
>>
>
> This is exactly the same problem as discussed in this thread:
>
> http://lists.mcs.anl.gov/pipermail/petsc-dev/2011-October/006105.html
>
> I think we should define this static global dispatch table (my suggested
> implementation was especially simple because it reuses PetscFList, but there
> are alternatives) and add a function MatMatMultRegister().
>

I think it would, in fact, be useful to consider the triple-dispatch
problem: if in A*B = C we are reusing C,
its type might dictate a different implementation.  This can be sort of
hacked with the double-dispatched routine
internally examining the type of C, and dispatching again, if necessary.


>
> To my knowledge, Sean hasn't started implementing this yet.
>
>
>> If I implement a new Mat type, say MATFOO, and want to make it be able
>> pre- and post-multiply
>> an existing type MATBAR, it looks like I have to add
>> "MatMatMult_foo_bar_C" to MATBAR's FList,
>> which is annoying, since I don't want to have to touch MATBAR's
>> constructor code.
>> I acknowledge that there is a certain amount of ambiguity possible, if
>> both MATFOO and MATBAR
>> had "MatMatMult_foo_bar_C" on their FLists, but one or the other would
>> predictably take precedence.
>>
>
> Viewer also has the same problem. See the email thread from a couple years
> ago in which I was suggesting a symmetric dispatch mechanism.
>

Since it only takes about 3 lines of code, and is backward compatible, I'm
putting this in, until someone really complains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111028/ad697b7b/attachment.html>