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 I'm not convinced it matters. 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> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120910/750c33cd/attachment.html>
