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>
>
