On Tue, Jan 15, 2013 at 2:31 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
  So who wrote the PetscOpFList() code and who will refactor it?  Is this a high priority or just something to be listed on that website and then ignored for years?<br></blockquote><div> </div><div>I wrote it when I was planning to implement extra MatMatMult_XXX_YYY methods, and I found it awkward</div>

<div>to preferentially attach them to MATXXX or MATYYY.  Since then the need has gone away or got put on the back burner, so at the moment it's mostly an experiment :-)</div><div><br></div><div>To get rid of endless string-based argument type matching, typenames have to be supplemented with something like integer typeids, making each PetscHeader carry one of those things.  These typeids can be registered </div>

<div>dynamically during individual package initialization (including for PODs) and assigned (to PetscObjects) on PetscObjectChangeTypeName().  There was some discussion of that a few months ago, but, clearly, there wasn't sufficient interest at the time.</div>

<div><br></div><div>Dmitry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Jan 15, 2013, at 2:14 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> On Tue, Jan 15, 2013 at 1:50 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   Do we really want mallocs for EVERY single multiple-dispatch function call in PETSc? I suggest not having MatQueryOp() but calling directly PetscOpFListFind() (with the MatOpFList argument) and changing PetscOpFListAdd/Find() to use variable args directly.<br>


><br>
>    Finally do we really want string comparisons at all here? Or do we want XXXRegister() (for example, MatRegister()) to compute an integer type id to go with each char *type_name and do the search off the integer type id instead of strings? Thus making PetscOpFListFind() super light weight?<br>


><br>
> static struct {<br>
>   PetscMultiDispatch ptap;<br>
>   ...<br>
> } MatMultiDispatch;<br>
><br>
> I would have PetscMultiDispatchRegister("MatPtAP",2,&MatMultiDispatch.ptap), then<br>
><br>
> PetscMultiDispatchFind(MatMultiDispatch.ptap,(PetscObject)A,(PetscObject)P,&ptapfunc);<br>
><br>
> I think passing PetscObject is natural here, in which case using obj->type_id instead of obj->type_name can be done later. But on that front, yes, I think making integers for all registered type_names would be good. Among other things, it would make the PetscObjectTypeCompares fast, although I think those places should eventually be refactored.<br>


><br>
><br>
>    Barry<br>
><br>
><br>
> PetscErrorCode  MatQueryOp(MPI_Comm comm, PetscVoidFunction* function, const char op[], PetscInt numArgs, ...)<br>
> {<br>
>   PetscErrorCode ierr;<br>
>   va_list        ap;<br>
>   PetscInt       i;<br>
>   const char     *argType;<br>
>   char           **argTypes = PETSC_NULL;<br>
><br>
>   PetscFunctionBegin;<br>
>   va_start(ap,numArgs);<br>
>   if (numArgs) {<br>
>     ierr = PetscMalloc(sizeof(char*)*numArgs, &argTypes);CHKERRQ(ierr);<br>
>   }<br>
>   for (i = 0; i < numArgs; ++i) {<br>
>     argType = va_arg(ap,const char*);<br>
>     ierr = PetscStrallocpy(argType, argTypes+i);CHKERRQ(ierr);<br>
>   }<br>
>   va_end(ap);<br>
>   ierr = PetscOpFListFind(comm, MatOpList, function, op, numArgs, argTypes);CHKERRQ(ierr);<br>
>   for (i = 0; i < numArgs; ++i) {<br>
>     ierr = PetscFree(argTypes[i]);CHKERRQ(ierr);<br>
>   }<br>
>   ierr = PetscFree(argTypes);CHKERRQ(ierr);<br>
>   PetscFunctionReturn(0);<br>
> }<br>
><br>
></div></div></blockquote></div>