I didn't have a solution to this > On Sep 1, 2016, at 2:36 PM, Munson, Todd <tmun...@mcs.anl.gov> wrote: > > > Dear petsc developers, > > Please do not get too mad at me... > > I have a C and Fortran test example that should be exactly the same > problem. The numerical methods, however, produce different results. > I traced this back to the literals used to define constants in the > test Fortran problem. C defaults to double, while Fortran defaults > to single for literals. > > What is the correct PETSc way to define literals in Fortran that works > across single and double installations (as well as complex and real) > so that I get the same behavior? PETSc does not appear to define a > macro for this. > > I'd like to be able to do something like the following in Fortran: > > PetscReal c > > c = PetscRealCast(5.78D0) > > where PetscRealCast is real() for single precision and dble() > for double precision. Without the cast, you would get all > kinds of warnings of the form "change of value in > conversion" for a single precision installation. > > This macro should work for real numbers (not sure about complex as > real() is overloaded as the real part of a complex number), avoids > generating warnings for single and double installs, and produces > the same output for the C and Fortran code.
Does your proposed PetscRealCast() work? Note that for double you shouldn't even need the dble() If it does then I can live with it. Yes, quad is a pain but I can live with it as an outlier for now. > > ===== > > The followup question is then, how do I make this work correctly for > __float128? In C, I would need to declare the literals using the Q > (e.g. 5.78Q) and then cast to the actual PetscReal type. Without > the Q, the __float128 constant would be initialized to the double > version of 5.78 and only correct to 16 digits. > > But is the Q suffix portable? If not, is there portable macro magic > to get full precision constants for single, double, and > quad installs? > > Or is the support for __float128 just going to be flakey? > > Other than the examples, the biggest place I can see where __float128 may not > be > supported correctly is the ts methods where, ts/impls/rosw/rosw.c for > example, > defines a ton of constants, many with a very large number of digits, but all > of them are truncated to double precision and the extra digits are thrown > away because of the lack of a Q at the end of the constant, even when > assigned to __float128 variables. > > Most others are okay because they are exactly representable, but you can > find constants like 0.7 in few other places. > > ===== > > Note: I already get warnings about using 5.78Q0 in gfortran when declaring > real(16), as its an "extension". > > Things get more complicated if you allow people to muck with compiler options > like the gfortran -fdefault-real-8, but maybe we should just call that a > user problem. > > Thanks, Todd. >
