On Tue, Jan 15, 2013 at 2:31 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> 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?
>
I wrote it when I was planning to implement extra MatMatMult_XXX_YYY
methods, and I found it awkward
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 :-)
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
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.
Dmitry.
>
> Barry
>
>
>
> On Jan 15, 2013, at 2:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> > On Tue, Jan 15, 2013 at 1:50 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > 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.
> >
> > 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?
> >
> > static struct {
> > PetscMultiDispatch ptap;
> > ...
> > } MatMultiDispatch;
> >
> > I would have
> PetscMultiDispatchRegister("MatPtAP",2,&MatMultiDispatch.ptap), then
> >
> >
> PetscMultiDispatchFind(MatMultiDispatch.ptap,(PetscObject)A,(PetscObject)P,&ptapfunc);
> >
> > 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.
> >
> >
> > Barry
> >
> >
> > PetscErrorCode MatQueryOp(MPI_Comm comm, PetscVoidFunction* function,
> const char op[], PetscInt numArgs, ...)
> > {
> > PetscErrorCode ierr;
> > va_list ap;
> > PetscInt i;
> > const char *argType;
> > char **argTypes = PETSC_NULL;
> >
> > PetscFunctionBegin;
> > va_start(ap,numArgs);
> > if (numArgs) {
> > ierr = PetscMalloc(sizeof(char*)*numArgs, &argTypes);CHKERRQ(ierr);
> > }
> > for (i = 0; i < numArgs; ++i) {
> > argType = va_arg(ap,const char*);
> > ierr = PetscStrallocpy(argType, argTypes+i);CHKERRQ(ierr);
> > }
> > va_end(ap);
> > ierr = PetscOpFListFind(comm, MatOpList, function, op, numArgs,
> argTypes);CHKERRQ(ierr);
> > for (i = 0; i < numArgs; ++i) {
> > ierr = PetscFree(argTypes[i]);CHKERRQ(ierr);
> > }
> > ierr = PetscFree(argTypes);CHKERRQ(ierr);
> > PetscFunctionReturn(0);
> > }
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130115/a6fb94a8/attachment.html>
