[petsc-dev] Simultaneous use of different precisions

[Barry Smith]

On Nov 17, 2010, at 4:06 PM, Jed Brown wrote:

> On Wed, Nov 17, 2010 at 22:41, Barry Smith <bsmith at mcs.anl.gov> wrote:
> I hate beyond words the standard C++ template model
> 
> Me too.
>  
> This, I think, can be done using ONLY simple C++ function polymorphism (allowing VecSetValues(double*) and VecSetValues(single *) for example)
> 
> If I call VecGetArray(X,&singleptr) and X is "double", would this error or make a copy?

   In Model II it is an error (runtime) whenever you call an object of one precision with a function that exposes a different precision.

>  What about "local" callbacks (or any callback that passes scalars)?  And any composed function (that part is not type safe, so C++ name mangling won't save you)?

   Beats me.

> 
> An acceptable C solution might be to have a PetscShortScalar typedef, VecGetArrayShort(), and maybe also MatSetValuesShort() (integration for assembly can be time consuming, and float is twice as fast if you vectorize well) which would give you no-copy access to short storage.  You could still have C++ overloaded variants, but I usually want some explicit control over types matching.  To allow people to make their Shorts (likely float) into Longs (likely double), have them recompile with a macro defined that causes the Short names to be defined to the long ones.

  Yuck :-).  This doesn't really simplify things anyways because there are billions of places where calls are made where the calling function has a exposed precision in one of the arguments. Somehow you've got to get PETSc compiled with both precisions and in the same library.

> 
> But this does snowball if you want {Real,Complex}{Short,Long} in the same code.
> 
> Documentation for the Short variants could be organized so that it doesn't cause clutter, but hopefully there aren't a huge number that need this specialization.
> 
> 
> Thanks for the summary, I hope it works out.

   After a tiny bit of hard earned success I'm thinking redoing all of PETSc with proper code generation :-) What will I think tommorow :-(

   Barry

> 
> Jed