[petsc-users] one compilation error in PETSc-dev with enabling GPU and complex number

Jack Poulson jack.poulson at gmail.com
Tue Feb 7 16:12:54 CST 2012


On Tue, Feb 7, 2012 at 3:46 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Wed, Feb 8, 2012 at 00:43, Jack Poulson <jack.poulson at gmail.com> wrote:
>
>> Good to know; I didn't know libquadmath provided that. The catch is that
>> it does not allow one to easily extend templates that previously handled
>> 32-bit and 64-bit base types. On the other hand, a custom complex class
>> could easily just call the built-in functions for __complex128 when
>> instantiated with a base type of __float128.
>
>
> It'll work fine with PETSc's typedef of PetscReal and PetscScalar. I never
> like that C++ crap anyway. ;-D
>
> (You could template over the real and complex types separately, but I
> guess you are assuming a certain syntax for converting between reals and
> complex.)
>

Yes, one could argue that PetscScalar can behave like a custom complex
class, but with only a single instantiation choice through the preprocessor
where each implementation was completely separate. If this type of logic
was pulled into the language instead of lying at the preprocessor stage,
then it would result in a custom complex class like I am arguing for.
Either way std::complex is not being used for quads.

Any way, it sounds like the current approach will work just fine for PETSc,
so I will shut up. The only other argument would be if someone wanted to
compute using some exotic datatype like the Gaussian integers, but that
would require a subset of the functionality of standard complex class that
only assumed a ring instead of a field.

Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120207/70346855/attachment.htm>


More information about the petsc-users mailing list