<br><br><div class="gmail_quote">On Fri, Oct 28, 2011 at 4:08 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">On Fri, Oct 28, 2011 at 15:00, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>Why does the double dispatch for A*B only looks for the implementation in B's FList?
<div>Is there any deep reason for this?</div></div></blockquote><div><br></div></div><div>This is exactly the same problem as discussed in this thread:</div><div><br></div><div><a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/2011-October/006105.html" target="_blank">http://lists.mcs.anl.gov/pipermail/petsc-dev/2011-October/006105.html</a></div>


<div><br></div><div>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().</div>

</div></blockquote><div><br></div><div>I think it would, in fact, be useful to consider the triple-dispatch problem: if in A*B = C we are reusing C,</div><div>its type might dictate a different implementation.  This can be sort of hacked with the double-dispatched routine</div>

<div>internally examining the type of C, and dispatching again, if necessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">


<div><br></div><div>To my knowledge, Sean hasn't started implementing this yet.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
<div><br></div><div>If I implement a new Mat type, say MATFOO, and want to make it be able pre- and post-multiply </div><div>an existing type MATBAR, it looks like I have to add "MatMatMult_foo_bar_C" to MATBAR's FList, </div>




<div>which is annoying, since I don't want to have to touch MATBAR's constructor code.</div><div>I acknowledge that there is a certain amount of ambiguity possible, if both MATFOO and MATBAR</div><div>had "MatMatMult_foo_bar_C" on their FLists, but one or the other would predictably take precedence.</div>


</div></blockquote><div><br></div></div><div>Viewer also has the same problem. See the email thread from a couple years ago in which I was suggesting a symmetric dispatch mechanism.</div></div></blockquote><div><br></div>

<div>Since it only takes about 3 lines of code, and is backward compatible, I'm putting this in, until someone really complains. </div></div><br>