I agree, even though the castes are ugly, I think we have to live with them.
Barry On Jun 3, 2011, at 7:37 AM, Jed Brown wrote: > On Fri, Jun 3, 2011 at 13:20, Lisandro Dalcin <dalcinl at gmail.com> wrote: > Can any of you try to reproduce (using single precision + complex > scalars) ? I'm using system GCC 4.5.5 from Fedora 13. > > This issue is present with both gcc-4.6 and clang-2.9. > > As an example, consider PetscIsInfOrNanScalar(PetscScalar a) > > return ((a - a) != 0.0); > > In this expression, (a-a) has type std::complex<float>, but 0.0 has type > double. The 0.0 could be converted to std::complex<double>, but won't be > implicitly converted to std::complex<float>. The defined operator!= are > (complex<float>,complex<float>), (complex<float>,float), and > (float,complex<float>). There is no comparison to double. This is easily > fixed using an explicit cast of zero: (PetscScalar)0. > > For rand48.c, we take the real part of a complex<float> which is multiplied > by double. That expression thus has type double and the line is evaluated to > the right promoting the floats to double at each stage. Then the double is > multiplied by PETSC_i which has type complex<float>. Again, this does not > exist because operator* is only defined for (complex<float>,complex<float>), > (complex<float>,float), and (float,complex<float>). > > Lisandro's proposed patch causes the double returned by drand48() to be > converted to float. C++ allows this conversion for C compatibility (or > because it's a pain to live without), but compilers warn when you run with > -Wconversion: > > warning: implicit conversion loses floating-point precision: 'double' to > 'float' [-Wconversion] > > An explicit cast: > > re = (PetscReal)drand48(); > > will make that warning go away. > > > There are a lot of places where there is an assumption that unsuffixed > floating point literals (as in 0.0 instead of 0.0f) can be converted to > PetscScalar. It is ugly, but all of these need an explicit cast. I started > the job > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/71e5798007d3 > > We can revert this if you really want something different, but I think that > having constants like PETSC_ONE is more confusing when you see it in the > source.
