[petsc-dev] multiple dispatch code currently in PETSc

[Dmitry Karpeev]

On Tue, Jan 15, 2013 at 2:55 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Jan 15, 2013 at 2:51 PM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>
>> 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.
>>>
>> Some of the arguments aren't PetscObjects (e.g., PODs).
>> Each dispatcher (e.g., MatMultMult) can have static integer typeids for
>> all of its arguments that are registered
>> or retrieved only on the first invocation and reused from then on.
>>
>
> Are you talking hypothetically? Because what's in there now is just
> dispatch based on the types of PetscObjects.
>
Right.  I guess the non-PetscObject arguments don't vary between
implementations, so we can stick to PetscObjects.

>
> Note that generic PetscObject routines would have to ensure that type ids
> never collided, even if the objects were of different classes. If we pass
> the object, that's easy to verify. The current PetscOpFListFind() will fail
> at distinguishing an AOBASIC from a SNESLINESEARCHBASIC or a PETSCSFBASIC.
> Passing PetscObject is safer in this regard.
>
Right.  Typeids would have to be assigned to (classid,type_name) pairs,
since type_names are only unique within a class. I'm on board with passing
PetscObjects for argument matching (and squeezing out the non-PetscObject
args).

There is, by the way, the 'type' field in the header, which the docs say
should no longer be used, and which is typically set to 0 or -1 in calls to
PetscHeaderCreate.  So, barring some subtle backward-compatibility issue
this can be reused to hold the typeid, which is computed or looked up on
each PetscObjectChangeTypeName()?

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130115/d372f427/attachment.html>