[petsc-dev] more issues
Jed Brown
jed at 59A2.org
Fri Jun 3 07:37:21 CDT 2011
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110603/8c59b703/attachment.html>
More information about the petsc-dev
mailing list