[petsc-dev] [PATCH] Custom use of complex when not configured for complex

[Barry Smith]

On Sep 10, 2012, at 5:43 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> ScalarComplex was just a typo that I noticed shortly after sending.
> 
> As for LogScalar versus ScalarLog, I can change it, but it's kind of intrusive to users and

    What do you mean intrusive? How is PetscScalarLog any more intrusive than PetscLogScalar? It is the same number of letters, same concepts; but one is right and one is wrong.

> and I'm not convinced it matters.

    What do you mean? Consistent use of notation doesn't matter?   Why not have KSPGMRESSetRestart() and  KSPSetHaptolGMRES() and CGSetUseComplexSymmetric() all in the same library?  Why bother having consistent notation anywhere?

    Barry



> 
> On Sep 10, 2012 6:37 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> 
>    Are these names correct?
> 
> 
>   #define PetscPowScalarComplex(a,b)   complexlib::pow(a,b)
> +#define PetscExpScalarComplex(a)     complexlib::exp(a)
> +#define PetscLogScalarComplex(a)     complexlib::log(a)
> 
>     Generally in PETSc when we have a function specific to a subclass (say GMRES subclass of KSP) we use for example KSPGMRESSetRestart() NOT KSPSetRestartGMRES().
> 
>     And why is there a Scalar AND a Complex in the name?
> 
>      Why not have
> 
>         PetscRealLog( PetscReal x, …
>         PetscComplexLog( PetscComplex x,…
>         PetscScalarLog( PetscScalar x,….                     is always one of the two above depending on the PetscScalar type at ./configure time
> 
>     Barry
> 
> 
> 
> On Sep 10, 2012, at 11:19 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
> > I would like to use complex arithmetic in some code that does polynomial optimization in the complex plane (for adaptive smoothers), even when PetscScalar is real. I'd like to push something like the attached, but since this is potentially fragile, I'm posting here before pushing. Any objections to my pushing?
> >
> > This works with my C and C++ real builds as well as C and C++ complex. I also tried a real build that disabled PETSC_HAVE_C99_COMPLEX (because all my compilers support it), but of course that's not much of a check.
> >
> > One thing that I think we could support (because C99 and C++ complex is binary compatible) is choosing the complex implementation based on the current language rather than PETSC_CLANGUAGE.
> > <complex.diff>
>