[petsc-dev] Questions about MatMatTransposeMult/MatMatMultTranspose

[Dmitry Karpeev]

On Tue, Nov 1, 2011 at 12:23 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Nov 1, 2011 at 11:14, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
>> In fact, it could be done rather easily even in the most general case.
>>  For example, using a pair of variadic functions:
>> PetscMethodRegister(void (*f)(void), const char* name, const char*
>> arg1Type, const char* arg2Type, ...)
>> PetscMethodQuery(void (**f)(void), const char* name, const char*
>> arg1Type, const char* arg2Type, ...)
>>
>
> Do you really mean for this to be a variadic function? How would you know
> how many args to pick off?
>
Doesn't have to be a variadic function -- can work with an array of const
char[] instead, but it's a pain for the user.
Or I can stick with a variadic function and pass in the number of arguments:
PetscMethodRegister(void (*f)(void), PetscInt nArgs, const char* arg1Type,
...), etc.


>
>
>> The only wrinkle here is the need to cast f to the right function pointer
>> type.
>>
>
> It's a dynamic lookup anyway, so the caller chooses the type and
> everything underneath works with void(*)(void).
>
> Your suggestion to use a single PetscFList is okay, but any time it makes
> sense to list the available types, we want to resolve the first type before
> consulting the FList, because then -help can work. This is purely an
> end-user interface detail, so if you make the change above, we can adjust
> the internal data structure without touching the call sites.
>

Okay.


>
>
>> Under the hood it's a simple search through an FList on the name and the
>> arg types.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111101/90afbfd2/attachment.html>