Re: [petsc-dev] fortran literals

[Barry Smith]

   I think the Fortran side is simple and have a branch I've been working on 
barry/use-fortran-kind-consistently that I will put in master once I have all 
the .F90 examples updated.

   Barry

C is ugly.

> On Sep 7, 2016, at 3:10 PM, Munson, Todd  wrote:
> 
> 
> Did we come to a conclusion on this?  Is it worthwhile adding macros for C 
> and 
> Fortran literals to make sure they match the PetscScalar type along with the 
> appropriate configure tests?
> 
> Todd.
> 
>> On Sep 3, 2016, at 3:18 PM, Lisandro Dalcin  wrote:
>> 
>> 
>> On 2 September 2016 at 00:46, Scott Kruger  wrote:
>> Lisandro's description is the most natural way for a modern fortran 
>> programmer.
>> 
>> But for completeness, this is equivalent:
>>   x=REAL(0.123456789123456789123456789,KIND=PETSC_REAL_KIND)
>> 
>> I think you are wrong. The literal gets demoted to single precision, so you 
>> loose digits.
>> 
>> $ cat tmp.f90
>> program main
>>  real(kind=8) x
>>  x = REAL(0.123456789123456789123456789,KIND=8)
>>  write (*,'(F18.16)') x
>>  x = 0.123456789123456789123456789_8
>>  write (*,'(F18.16)') x
>> end program main
>> 
>> $ gfortran tmp.f90
>> $ ./a.out 
>> 0.1234567910432816
>> 0.1234567891234568
>> 
>> 
>> -- 
>> Lisandro Dalcin
>> 
>> Research Scientist
>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>> 
>> 4700 King Abdullah University of Science and Technology
>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>> http://www.kaust.edu.sa
>> 
>> Office Phone: +966 12 808-0459
> 

Re: [petsc-dev] fortran literals

[Munson, Todd]

Did we come to a conclusion on this?  Is it worthwhile adding macros for C and 
Fortran literals to make sure they match the PetscScalar type along with the 
appropriate configure tests?

Todd.

> On Sep 3, 2016, at 3:18 PM, Lisandro Dalcin  wrote:
> 
> 
> On 2 September 2016 at 00:46, Scott Kruger  wrote:
> Lisandro's description is the most natural way for a modern fortran 
> programmer.
> 
> But for completeness, this is equivalent:
>x=REAL(0.123456789123456789123456789,KIND=PETSC_REAL_KIND)
> 
> I think you are wrong. The literal gets demoted to single precision, so you 
> loose digits.
> 
> $ cat tmp.f90
> program main
>   real(kind=8) x
>   x = REAL(0.123456789123456789123456789,KIND=8)
>   write (*,'(F18.16)') x
>   x = 0.123456789123456789123456789_8
>   write (*,'(F18.16)') x
> end program main
> 
> $ gfortran tmp.f90
> $ ./a.out 
> 0.1234567910432816
> 0.1234567891234568
> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 0109
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459

Re: [petsc-dev] fortran literals

[Lisandro Dalcin]

On 2 September 2016 at 00:46, Scott Kruger  wrote:

> Lisandro's description is the most natural way for a modern fortran
> programmer.
>
> But for completeness, this is equivalent:
>x=REAL(0.123456789123456789123456789,KIND=PETSC_REAL_KIND)
>

I think you are wrong. The literal gets demoted to single precision, so you
loose digits.

$ cat tmp.f90
program main
  real(kind=8) x
  x = REAL(0.123456789123456789123456789,KIND=8)
  write (*,'(F18.16)') x
  x = 0.123456789123456789123456789_8
  write (*,'(F18.16)') x
end program main

$ gfortran tmp.f90
$ ./a.out
0.1234567910432816
0.1234567891234568


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] fortran literals

[William Gropp]

Its my mistake - the kind values are not defined, but using the intrinsics to 
select a kind value based on precision and/or range is well define.  My 
apologies for the confusion.

Bill

William Gropp
Acting Director and Chief Scientist, NCSA
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign





On Sep 2, 2016, at 11:40 AM, Munson, Todd  wrote:

> 
> I am confused by Blaise's statement.  "selected_real_kind(5)" is well defined 
> across
> compilers; it returns an integer value that can be used in the kind 
> statements and
> selected real numbers with at least 5 digits of precision.
> 
> With the exception of -1, -2, and -3 (plus -4 and -5 in Fortran 2008) 
> indicating 
> no support.  The actual integer values returned are compiler specific.
> 
> If we wanted to have a better chance of getting ieee single, double, and 
> quad, 
> we should probably use something like:
> 
>   selected_real_kind(6,37)
>   selected_real_kind(15,307)
>   selected_real_kind(33,4931)
> 
> in PETSc.  You would still need to do some testing during configuration to 
> really ensure that
> 
>   real(kind=selected_real_kind(7,38))
>   real(kind=selected_real_kind(15,307))
>   real(kind=selected_real_kind(34,4931))
> 
> is the same as a C float, double, and __float128 respectively?  
> 
> =
> 
> Its not until Fortran 2008 that the standard has constants for REAL32, 
> REAL64, 
> and REAL128 defined in the ISO_FORTRAN_ENV module.  However, if we are using
> Fortran 2008 features, go all out and use the ISO_C_BINDING module with 
> the C_FLOAT and C_DOUBLE constants!  Some compilers, such as the gnu
> compilers. extend the constants and include C_FLOAT128.
> 
> I have attached a simple program to output the kinds.  Try it on your machine.
> On my machine with gfortran from gcc version 4.8.5 (MacPorts gcc48 4.8.5_0), I
> get the following:
> 
>  C_FLOAT   :4
>  C_DOUBLE  :8
>  C_FLOAT128:   16
>  REAL32:4
>  REAL64:8
>  REAL128   :   10
>  sel(6):4
>  sel(15)   :8
>  sel(16)   :   10
>  sel(33)   :   16
> 
> The integers provide the number of bytes on my machine.  Note REAL128 is 
> apparently an 80-bit long double and not a 128-bit __float128!!  The 
> type using selected_real_kind appears correct though.  The same 
> happens for REAL128 with gfortran from gcc 4.9.3, gcc 5.4.0, 
> and gcc 6.1.0 on my machine.
> 
> Todd.
> 
> 
> 
> > On Sep 2, 2016, at 12:51 AM, William Gropp  wrote:
> > 
> > This is true.  The meaning of integer values of kind is up to the 
> > implementation, and at least two choices are in use.
> > 
> > Bill
> > 
> > William Gropp
> > Acting Director and Chief Scientist, NCSA
> > Director, Parallel Computing Institute
> > Thomas M. Siebel Chair in Computer Science
> > University of Illinois Urbana-Champaign
> > 
> > 
> > 
> > 
> > 
> > On Sep 1, 2016, at 6:15 PM, Blaise A Bourdin  wrote:
> > 
> >> If I recall correctly, fortran does not mandate that 
> >> "selected_real_kind(5)" means the same across compilers, so that 
> >> hardcoding kind values may not be portable.
> > 
> 
> 

Re: [petsc-dev] fortran literals

[Munson, Todd]

I am confused by Blaise's statement.  "selected_real_kind(5)" is well defined 
across
compilers; it returns an integer value that can be used in the kind statements 
and
selected real numbers with at least 5 digits of precision.

With the exception of -1, -2, and -3 (plus -4 and -5 in Fortran 2008) indicating
no support.  The actual integer values returned are compiler specific.

If we wanted to have a better chance of getting ieee single, double, and quad,
we should probably use something like:

  selected_real_kind(6,37)
  selected_real_kind(15,307)
  selected_real_kind(33,4931)

in PETSc.  You would still need to do some testing during configuration to
really ensure that

  real(kind=selected_real_kind(7,38))
  real(kind=selected_real_kind(15,307))
  real(kind=selected_real_kind(34,4931))

is the same as a C float, double, and __float128 respectively?

=

Its not until Fortran 2008 that the standard has constants for REAL32, REAL64,
and REAL128 defined in the ISO_FORTRAN_ENV module.  However, if we are using
Fortran 2008 features, go all out and use the ISO_C_BINDING module with
the C_FLOAT and C_DOUBLE constants!  Some compilers, such as the gnu
compilers. extend the constants and include C_FLOAT128.

I have attached a simple program to output the kinds.  Try it on your machine.
On my machine with gfortran from gcc version 4.8.5 (MacPorts gcc48 4.8.5_0), I
get the following:

 C_FLOAT   :4
 C_DOUBLE  :8
 C_FLOAT128:   16
 REAL32:4
 REAL64:8
 REAL128   :   10
 sel(6):4
 sel(15)   :8
 sel(16)   :   10
 sel(33)   :   16

The integers provide the number of bytes on my machine.  Note REAL128 is
apparently an 80-bit long double and not a 128-bit __float128!!  The
type using selected_real_kind appears correct though.  The same
happens for REAL128 with gfortran from gcc 4.9.3, gcc 5.4.0,
and gcc 6.1.0 on my machine.

Todd.



> On Sep 2, 2016, at 12:51 AM, William Gropp  wrote:
>
> This is true.  The meaning of integer values of kind is up to the 
> implementation, and at least two choices are in use.
>
> Bill
>
> William Gropp
> Acting Director and Chief Scientist, NCSA
> Director, Parallel Computing Institute
> Thomas M. Siebel Chair in Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
>
> On Sep 1, 2016, at 6:15 PM, Blaise A Bourdin  wrote:
>
>> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
>> means the same across compilers, so that hardcoding kind values may not be 
>> portable.
>



mytest.f
Description: mytest.f

Re: [petsc-dev] fortran literals

[William Gropp]

The float implementations are the same - but the kind value is not specified in 
the standard, and the value of kind for single or double (or quad or half) is 
up to the implementation.  You can’t assume that the numeric kind value that 
you find on one implementation will mean the same thing (or even be valid at 
all) on another implementation.

Bill

William Gropp
Acting Director and Chief Scientist, NCSA
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign





On Sep 2, 2016, at 9:28 AM, Jeff Hammond  wrote:

> I'm not away of any difference in *float* values in implementations since 
> Cray stopped doing 64b float in the 1990s (I may have the details wrong - I 
> just remember code that calls SGEMM when DGEMM is used otherwise).
> 
> Jörg 
> 
> On Thursday, September 1, 2016, William Gropp  wrote:
> This is true.  The meaning of integer values of kind is up to the 
> implementation, and at least two choices are in use.
> 
> Bill
> 
> William Gropp
> Acting Director and Chief Scientist, NCSA
> Director, Parallel Computing Institute
> Thomas M. Siebel Chair in Computer Science
> University of Illinois Urbana-Champaign
> 
> 
> 
> 
> 
> On Sep 1, 2016, at 6:15 PM, Blaise A Bourdin  wrote:
> 
>> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
>> means the same across compilers, so that hardcoding kind values may not be 
>> portable.
> 
> 
> 
> -- 
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/

Re: [petsc-dev] fortran literals

[Jeff Hammond]

I'm not away of any difference in *float* values in implementations since
Cray stopped doing 64b float in the 1990s (I may have the details wrong - I
just remember code that calls SGEMM when DGEMM is used otherwise).

Jörg

On Thursday, September 1, 2016, William Gropp  wrote:

> This is true.  The meaning of integer values of kind is up to the
> implementation, and at least two choices are in use.
>
> Bill
>
> William Gropp
> Acting Director and Chief Scientist, NCSA
> Director, Parallel Computing Institute
> Thomas M. Siebel Chair in Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
>
> On Sep 1, 2016, at 6:15 PM, Blaise A Bourdin  > wrote:
>
> If I recall correctly, fortran does not mandate that
> "selected_real_kind(5)" means the same across compilers, so that hardcoding
> kind values may not be portable.
>
>
>

-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

Re: [petsc-dev] fortran literals

[William Gropp]

This is true.  The meaning of integer values of kind is up to the 
implementation, and at least two choices are in use.

Bill

William Gropp
Acting Director and Chief Scientist, NCSA
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign





On Sep 1, 2016, at 6:15 PM, Blaise A Bourdin  wrote:

> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
> means the same across compilers, so that hardcoding kind values may not be 
> portable.

Re: [petsc-dev] fortran literals

[Jed Brown]

Barry Smith  writes:
>   Horrible to have to uglify all the source code for all real numbers without 
> exact hexadecimal representation like this.
>
>I could live with having 
>
>PetscReal a = .7_Q; 
>
> say (which won't work) but asking me to accept PetscRealLiteral(0.7); doesn't 
> make me happy.
>
>PetscReal a = _R(.7)  as an unhappy compromise? With imperfect namespacing.

Oh, I figured the non-namespaced version would be used privately in
compilation units that make heavy use of it.  But #define'ing _R() in a
public header would be bad behavior even if it didn't violate the
standard.


signature.asc
Description: PGP signature

Re: [petsc-dev] fortran literals

[Barry Smith]

> On Sep 1, 2016, at 10:29 PM, Jed Brown  wrote:
> 
> "Munson, Todd"  writes:
>> Any idea how to do the same thing in C?
> 
> #define PetscRealLiteral(x) (x ## q)
> 
> PetscReal a = PetscRealLiteral(0.7);

  Horrible to have to uglify all the source code for all real numbers without 
exact hexadecimal representation like this.

   I could live with having 

   PetscReal a = .7_Q; 

say (which won't work) but asking me to accept PetscRealLiteral(0.7); doesn't 
make me happy.

   PetscReal a = _R(.7)  as an unhappy compromise? With imperfect namespacing.
 

>  
> 
> Seems like we should do that for the precomputed methods in TS.
> Actually, it would be better to do all the setup arithmetic in the most
> accurate supported type.  Unfortunately, those methods are often
> computed using tools that only support double precision or are taken
> From papers that only report that many digits.

Re: [petsc-dev] fortran literals

[Emil Constantinescu]

On 9/1/16 10:54 PM, Jed Brown wrote:

"Munson, Todd"  writes:


The TS constants are weird in the code.  Some of have enough digits for double,
some for quad, and some for quad double.  I suspect mathematica output some
of the constants.


Yeah, there are a lot of different techniques used for different
methods.  Some use a combination of BARON and MATLAB, for example.



Yups, and by the way, Todd, thanks for your help with BARON. Sorry for 
the mess ;)

Re: [petsc-dev] fortran literals

[Jed Brown]

"Munson, Todd"  writes:

> The TS constants are weird in the code.  Some of have enough digits for 
> double, 
> some for quad, and some for quad double.  I suspect mathematica output some 
> of the constants.

Yeah, there are a lot of different techniques used for different
methods.  Some use a combination of BARON and MATLAB, for example.


signature.asc
Description: PGP signature

Re: [petsc-dev] fortran literals

[Munson, Todd]

The TS constants are weird in the code.  Some of have enough digits for double, 
some for quad, and some for quad double.  I suspect mathematica output some 
of the constants.

Todd.

> On Sep 1, 2016, at 10:29 PM, Jed Brown  wrote:
> 
> "Munson, Todd"  writes:
>> Any idea how to do the same thing in C?
> 
> #define PetscRealLiteral(x) (x ## q)
> 
> PetscReal a = PetscRealLiteral(0.7);
> 
> 
> Seems like we should do that for the precomputed methods in TS.
> Actually, it would be better to do all the setup arithmetic in the most
> accurate supported type.  Unfortunately, those methods are often
> computed using tools that only support double precision or are taken
> From papers that only report that many digits.

Re: [petsc-dev] fortran literals

[Jed Brown]

"Munson, Todd"  writes:
> Any idea how to do the same thing in C?

#define PetscRealLiteral(x) (x ## q)

PetscReal a = PetscRealLiteral(0.7);


Seems like we should do that for the precomputed methods in TS.
Actually, it would be better to do all the setup arithmetic in the most
accurate supported type.  Unfortunately, those methods are often
computed using tools that only support double precision or are taken
From papers that only report that many digits.


signature.asc
Description: PGP signature

Re: [petsc-dev] fortran literals

[Jeff Hammond]

It's Fortran 2008 but I don't know any respectable compiler that doesn't
support it. It works with Intel, GCC and Cray. Probably IBM XLF too, but
I've not tested. Not sure about any others. I think it's possible to
emulate it if necessary.

Jeff

On Thursday, September 1, 2016, Blaise A Bourdin  wrote:

> Neat.
> I was not aware of this.
>
> Blaise
>
> > On Sep 1, 2016, at 9:26 PM, Jeff Hammond  > wrote:
> >
> > https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fFORTRAN_005fENV.htmlhas
> real{32,64,128} that does a nice job for this situation.
> >
> > Jeff
> >
> > Sent from my iPhone
> >
> >> On Sep 1, 2016, at 4:15 PM, Blaise A Bourdin  > wrote:
> >>
> >> Hi,
> >>
> >> If I recall correctly, fortran does not mandate that
> "selected_real_kind(5)" means the same across compilers, so that hardcoding
> kind values may not be portable.
> >>
> >>
> >> Instead, I would recommend the following (not my idea, it was proposed
> by Michael Metcalf in comp.lang.fortran a _long_ time ago) in a top-level
> module.
> >>
> >>  ! The following ensures that mef90 and PETSC real types are compatible:
> >>  ! thanks to Michael Metcalf in comp.lang.fortran
> >>  PetscReal,Parameter :: PReal = 1.0
> >>  Integer,Parameter,Public:: Kr =
> Selected_Real_Kind(Precision(PReal))
> >>
> >>  PetscInt,Parameter  :: PInt = 1
> >>  Integer,Parameter,Public:: Ki = Selected_Int_Kind(PInt)
> >>
> >>  PetscLogDouble,Parameter:: flop = 1.0
> >>  Integer,Parameter,Public:: PFlop =
> Selected_Real_Kind(Precision(flop))
> >>
> >> so that Real(Kind = Kr) is the same as PetscReal, and literals can be
> written 1.234_Kr or 23_flop.
> >>
> >> I guess PETSc could define them in the petsc module and inherited from
> "use petsc”.
> >>
> >> Blaise
> >>
> >>
> >>
> >>> On Sep 1, 2016, at 5:37 PM, Barry Smith  > wrote:
> >>>
> >>>
>  On Sep 1, 2016, at 5:28 PM, Munson, Todd  > wrote:
> 
> 
>  Which platforms do not define PETSC_USE_FORTRANKIND?
> >>>
> >>> It uses it everywhere the Fortran compiler supports it.
> >>>
> >>> # reverse of the above - but more standard thing to do for F90
> compilers
> >>> def checkFortranKind(self):
> >>>  '''Checks whether selected_int_kind etc work USE_FORTRANKIND'''
> >>>  self.pushLanguage('FC')
> >>>  body = '''
> >>>  integer(kind=selected_int_kind(10)) i
> >>>  real(kind=selected_real_kind(10)) d
> >>> '''
> >>>  if self.checkCompile('', body):
> >>>self.addDefine('USE_FORTRANKIND', 1)
> >>>  self.popLanguage()
> >>>  return
> >>>
> >>> Presumably any Fortran compiler that supports F90 supports it so it is
> not unreasonable for us to just require it and simplify PETSc in a few
> places.
> >>>
> >>>
> >>>
> >>>
>  Are they important
>  or can we drop support for them?
> 
>  I could probably hack the D or Q for the others, but it would probably
>  be ugly.
> 
>  Or I could just overrule my OCD today...
> 
>  Todd.
> 
> > On Sep 1, 2016, at 5:08 PM, Barry Smith  > wrote:
> >
> >
> >> On Sep 1, 2016, at 4:37 PM, Munson, Todd  > wrote:
> >>
> >>
> >> Cool!
> >>
> >> For what its worth, that only works when PETSC_USE_FORTRANKIND is
> true.
> >> I'm not sure how many of the Petsc builds have this flag set.
> >
> > in the other case could you try to tack on the D or Q business?
> >
> > Barry
> >
> >>
> >> Any idea how to do the same thing in C?
> >>
> >> Todd.
> >>
> >>> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  > wrote:
> >>>
> >>>
> >>> On 1 September 2016 at 23:05, Barry Smith  > wrote:
> >>> I didn't have a solution to this
> >>>
> >>> ! These lines should be added to $PETSC_DIR/include/petsc/
> finclude/petscsysdef.h
> >>> #if defined(PETSC_USE_REAL_SINGLE)
> >>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
> >>> #elif defined(PETSC_USE_REAL_DOUBLE)
> >>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
> >>> #elif defined(PETSC_USE_REAL___FLOAT128)
> >>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
> >>> #endif
> >>>
> >>> ! User code should write literals this way
> >>> PetscReal x
> >>> x = 0.123456789123456789123456789_PETSC_REAL_KIND
> >>>
> >>>
> >>>
> >>> --
> >>> Lisandro Dalcin
> >>> 
> >>> Research Scientist
> >>> Computer, Electrical and Mathematical Sciences & Engineering
> (CEMSE)
> >>> Extreme Computing Research Center (ECRC)
> >>> King Abdullah University of Science and Technology (KAUST)
> >>> 

Re: [petsc-dev] fortran literals

[Blaise A Bourdin]

Neat.
I was not aware of this.

Blaise

> On Sep 1, 2016, at 9:26 PM, Jeff Hammond  wrote:
> 
> https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fFORTRAN_005fENV.htmlhas 
> real{32,64,128} that does a nice job for this situation. 
> 
> Jeff
> 
> Sent from my iPhone
> 
>> On Sep 1, 2016, at 4:15 PM, Blaise A Bourdin  wrote:
>> 
>> Hi,
>> 
>> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
>> means the same across compilers, so that hardcoding kind values may not be 
>> portable.
>> 
>> 
>> Instead, I would recommend the following (not my idea, it was proposed by 
>> Michael Metcalf in comp.lang.fortran a _long_ time ago) in a top-level 
>> module.
>> 
>>  ! The following ensures that mef90 and PETSC real types are compatible:
>>  ! thanks to Michael Metcalf in comp.lang.fortran
>>  PetscReal,Parameter :: PReal = 1.0
>>  Integer,Parameter,Public:: Kr = 
>> Selected_Real_Kind(Precision(PReal))
>> 
>>  PetscInt,Parameter  :: PInt = 1
>>  Integer,Parameter,Public:: Ki = Selected_Int_Kind(PInt)
>> 
>>  PetscLogDouble,Parameter:: flop = 1.0
>>  Integer,Parameter,Public:: PFlop = 
>> Selected_Real_Kind(Precision(flop))
>> 
>> so that Real(Kind = Kr) is the same as PetscReal, and literals can be 
>> written 1.234_Kr or 23_flop.
>> 
>> I guess PETSc could define them in the petsc module and inherited from "use 
>> petsc”. 
>> 
>> Blaise
>> 
>> 
>> 
>>> On Sep 1, 2016, at 5:37 PM, Barry Smith  wrote:
>>> 
>>> 
 On Sep 1, 2016, at 5:28 PM, Munson, Todd  wrote:
 
 
 Which platforms do not define PETSC_USE_FORTRANKIND?
>>> 
>>> It uses it everywhere the Fortran compiler supports it. 
>>> 
>>> # reverse of the above - but more standard thing to do for F90 compilers
>>> def checkFortranKind(self):
>>>  '''Checks whether selected_int_kind etc work USE_FORTRANKIND'''
>>>  self.pushLanguage('FC')
>>>  body = '''
>>>  integer(kind=selected_int_kind(10)) i
>>>  real(kind=selected_real_kind(10)) d
>>> '''
>>>  if self.checkCompile('', body):
>>>self.addDefine('USE_FORTRANKIND', 1)
>>>  self.popLanguage()
>>>  return
>>> 
>>> Presumably any Fortran compiler that supports F90 supports it so it is not 
>>> unreasonable for us to just require it and simplify PETSc in a few places.
>>> 
>>> 
>>> 
>>> 
 Are they important
 or can we drop support for them?
 
 I could probably hack the D or Q for the others, but it would probably
 be ugly.
 
 Or I could just overrule my OCD today...
 
 Todd.
 
> On Sep 1, 2016, at 5:08 PM, Barry Smith  wrote:
> 
> 
>> On Sep 1, 2016, at 4:37 PM, Munson, Todd  wrote:
>> 
>> 
>> Cool!
>> 
>> For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
>> I'm not sure how many of the Petsc builds have this flag set.
> 
> in the other case could you try to tack on the D or Q business? 
> 
> Barry
> 
>> 
>> Any idea how to do the same thing in C?
>> 
>> Todd.
>> 
>>> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  wrote:
>>> 
>>> 
>>> On 1 September 2016 at 23:05, Barry Smith  wrote:
>>> I didn't have a solution to this
>>> 
>>> ! These lines should be added to 
>>> $PETSC_DIR/include/petsc/finclude/petscsysdef.h
>>> #if defined(PETSC_USE_REAL_SINGLE)
>>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
>>> #elif defined(PETSC_USE_REAL_DOUBLE)
>>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
>>> #elif defined(PETSC_USE_REAL___FLOAT128)
>>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
>>> #endif
>>> 
>>> ! User code should write literals this way
>>> PetscReal x
>>> x = 0.123456789123456789123456789_PETSC_REAL_KIND
>>> 
>>> 
>>> 
>>> -- 
>>> Lisandro Dalcin
>>> 
>>> Research Scientist
>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/
>>> 
>>> 4700 King Abdullah University of Science and Technology
>>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>>> http://www.kaust.edu.sa
>>> 
>>> Office Phone: +966 12 808-0459
>> 
>> -- 
>> Department of Mathematics and Center for Computation & Technology
>> Louisiana State University, Baton Rouge, LA 70803, USA
>> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
>> http://www.math.lsu.edu/~bourdin
>> 
>> 
>> 
>> 
>> 
>> 
>> 

-- 
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, 

Re: [petsc-dev] fortran literals

[Jeff Hammond]

https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fFORTRAN_005fENV.htmlhas 
real{32,64,128} that does a nice job for this situation. 

Jeff

Sent from my iPhone

> On Sep 1, 2016, at 4:15 PM, Blaise A Bourdin  wrote:
> 
> Hi,
> 
> If I recall correctly, fortran does not mandate that "selected_real_kind(5)" 
> means the same across compilers, so that hardcoding kind values may not be 
> portable.
> 
> 
> Instead, I would recommend the following (not my idea, it was proposed by 
> Michael Metcalf in comp.lang.fortran a _long_ time ago) in a top-level module.
> 
>   ! The following ensures that mef90 and PETSC real types are compatible:
>   ! thanks to Michael Metcalf in comp.lang.fortran
>   PetscReal,Parameter :: PReal = 1.0
>   Integer,Parameter,Public:: Kr = 
> Selected_Real_Kind(Precision(PReal))
> 
>   PetscInt,Parameter  :: PInt = 1
>   Integer,Parameter,Public:: Ki = Selected_Int_Kind(PInt)
> 
>   PetscLogDouble,Parameter:: flop = 1.0
>   Integer,Parameter,Public:: PFlop = 
> Selected_Real_Kind(Precision(flop))
> 
> so that Real(Kind = Kr) is the same as PetscReal, and literals can be written 
> 1.234_Kr or 23_flop.
> 
> I guess PETSc could define them in the petsc module and inherited from "use 
> petsc”. 
> 
> Blaise
> 
> 
> 
>> On Sep 1, 2016, at 5:37 PM, Barry Smith  wrote:
>> 
>> 
>>> On Sep 1, 2016, at 5:28 PM, Munson, Todd  wrote:
>>> 
>>> 
>>> Which platforms do not define PETSC_USE_FORTRANKIND?
>> 
>> It uses it everywhere the Fortran compiler supports it. 
>> 
>> # reverse of the above - but more standard thing to do for F90 compilers
>> def checkFortranKind(self):
>>   '''Checks whether selected_int_kind etc work USE_FORTRANKIND'''
>>   self.pushLanguage('FC')
>>   body = '''
>>   integer(kind=selected_int_kind(10)) i
>>   real(kind=selected_real_kind(10)) d
>> '''
>>   if self.checkCompile('', body):
>> self.addDefine('USE_FORTRANKIND', 1)
>>   self.popLanguage()
>>   return
>> 
>> Presumably any Fortran compiler that supports F90 supports it so it is not 
>> unreasonable for us to just require it and simplify PETSc in a few places.
>> 
>> 
>> 
>> 
>>> Are they important
>>> or can we drop support for them?
>>> 
>>> I could probably hack the D or Q for the others, but it would probably
>>> be ugly.
>>> 
>>> Or I could just overrule my OCD today...
>>> 
>>> Todd.
>>> 
 On Sep 1, 2016, at 5:08 PM, Barry Smith  wrote:
 
 
> On Sep 1, 2016, at 4:37 PM, Munson, Todd  wrote:
> 
> 
> Cool!
> 
> For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
> I'm not sure how many of the Petsc builds have this flag set.
 
 in the other case could you try to tack on the D or Q business? 
 
 Barry
 
> 
> Any idea how to do the same thing in C?
> 
> Todd.
> 
>> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  wrote:
>> 
>> 
>> On 1 September 2016 at 23:05, Barry Smith  wrote:
>> I didn't have a solution to this
>> 
>> ! These lines should be added to 
>> $PETSC_DIR/include/petsc/finclude/petscsysdef.h
>> #if defined(PETSC_USE_REAL_SINGLE)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
>> #elif defined(PETSC_USE_REAL_DOUBLE)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
>> #elif defined(PETSC_USE_REAL___FLOAT128)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
>> #endif
>> 
>> ! User code should write literals this way
>> PetscReal x
>> x = 0.123456789123456789123456789_PETSC_REAL_KIND
>> 
>> 
>> 
>> -- 
>> Lisandro Dalcin
>> 
>> Research Scientist
>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>> 
>> 4700 King Abdullah University of Science and Technology
>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>> http://www.kaust.edu.sa
>> 
>> Office Phone: +966 12 808-0459
> 
> -- 
> Department of Mathematics and Center for Computation & Technology
> Louisiana State University, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 
> http://www.math.lsu.edu/~bourdin
> 
> 
> 
> 
> 
> 
> 

Re: [petsc-dev] fortran literals

[Barry Smith]

> On Sep 1, 2016, at 5:28 PM, Munson, Todd  wrote:
> 
> 
> Which platforms do not define PETSC_USE_FORTRANKIND?

It uses it everywhere the Fortran compiler supports it. 

# reverse of the above - but more standard thing to do for F90 compilers
  def checkFortranKind(self):
'''Checks whether selected_int_kind etc work USE_FORTRANKIND'''
self.pushLanguage('FC')
body = '''
integer(kind=selected_int_kind(10)) i
real(kind=selected_real_kind(10)) d
'''
if self.checkCompile('', body):
  self.addDefine('USE_FORTRANKIND', 1)
self.popLanguage()
return

  Presumably any Fortran compiler that supports F90 supports it so it is not 
unreasonable for us to just require it and simplify PETSc in a few places.




>  Are they important
> or can we drop support for them?
> 
> I could probably hack the D or Q for the others, but it would probably
> be ugly.
> 
> Or I could just overrule my OCD today...
> 
> Todd.
> 
>> On Sep 1, 2016, at 5:08 PM, Barry Smith  wrote:
>> 
>> 
>>> On Sep 1, 2016, at 4:37 PM, Munson, Todd  wrote:
>>> 
>>> 
>>> Cool!
>>> 
>>> For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
>>> I'm not sure how many of the Petsc builds have this flag set.
>> 
>> in the other case could you try to tack on the D or Q business? 
>> 
>> Barry
>> 
>>> 
>>> Any idea how to do the same thing in C?
>>> 
>>> Todd.
>>> 
 On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  wrote:
 
 
 On 1 September 2016 at 23:05, Barry Smith  wrote:
 I didn't have a solution to this
 
 ! These lines should be added to 
 $PETSC_DIR/include/petsc/finclude/petscsysdef.h
 #if defined(PETSC_USE_REAL_SINGLE)
 integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
 #elif defined(PETSC_USE_REAL_DOUBLE)
 integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
 #elif defined(PETSC_USE_REAL___FLOAT128)
 integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
 #endif
 
 ! User code should write literals this way
 PetscReal x
 x = 0.123456789123456789123456789_PETSC_REAL_KIND
 
 
 
 -- 
 Lisandro Dalcin
 
 Research Scientist
 Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
 Extreme Computing Research Center (ECRC)
 King Abdullah University of Science and Technology (KAUST)
 http://ecrc.kaust.edu.sa/
 
 4700 King Abdullah University of Science and Technology
 al-Khawarizmi Bldg (Bldg 1), Office # 0109
 Thuwal 23955-6900, Kingdom of Saudi Arabia
 http://www.kaust.edu.sa
 
 Office Phone: +966 12 808-0459
>>> 
>> 
> 

Re: [petsc-dev] fortran literals

[Barry Smith]

> On Sep 1, 2016, at 4:37 PM, Munson, Todd  wrote:
> 
> 
> Cool!
> 
> For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
> I'm not sure how many of the Petsc builds have this flag set.

  in the other case could you try to tack on the D or Q business? 

 Barry

> 
> Any idea how to do the same thing in C?
> 
> Todd.
> 
>> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  wrote:
>> 
>> 
>> On 1 September 2016 at 23:05, Barry Smith  wrote:
>>   I didn't have a solution to this
>> 
>> ! These lines should be added to 
>> $PETSC_DIR/include/petsc/finclude/petscsysdef.h
>> #if defined(PETSC_USE_REAL_SINGLE)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
>> #elif defined(PETSC_USE_REAL_DOUBLE)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
>> #elif defined(PETSC_USE_REAL___FLOAT128)
>> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
>> #endif
>> 
>> ! User code should write literals this way
>> PetscReal x
>> x = 0.123456789123456789123456789_PETSC_REAL_KIND
>> 
>> 
>> 
>> -- 
>> Lisandro Dalcin
>> 
>> Research Scientist
>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/
>> 
>> 4700 King Abdullah University of Science and Technology
>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>> http://www.kaust.edu.sa
>> 
>> Office Phone: +966 12 808-0459
> 

Re: [petsc-dev] fortran literals

[Scott Kruger]

Lisandro's description is the most natural way for a modern fortran 
programmer.


But for completeness, this is equivalent:
   x=REAL(0.123456789123456789123456789,KIND=PETSC_REAL_KIND)

Similarly, for complex numbers we have:
  xc=(0.1_PETSC_REAL_KIND,0.2_PETSC_REAL_KIND)
or
  xc=CMPLX(0.1,0.2,KIND=PETSC_REAL_KIND)


If you do not want to use the selected_real_kind
as Lisandro shows, you can also use the intrinsics
which are generally compiler independent:
https://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Kind-Notation.html

That is,
  x=REAL(0.1,KIND=2)
or equivalently
  x=DBLE(0.1)
if you always want double precision regardless
of how PETSC_REAL_KIND is defined.

Scott


On 9/1/16 3:13 PM, Lisandro Dalcin wrote:


On 1 September 2016 at 23:05, Barry Smith > wrote:

   I didn't have a solution to this


! These lines should be added to
$PETSC_DIR/include/petsc/finclude/petscsysdef.h
#if defined(PETSC_USE_REAL_SINGLE)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
#elif defined(PETSC_USE_REAL_DOUBLE)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
#elif defined(PETSC_USE_REAL___FLOAT128)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
#endif

! User code should write literals this way
PetscReal x
x = 0.123456789123456789123456789_PETSC_REAL_KIND



--
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459


--
Tech-X Corporation   kru...@txcorp.com
5621 Arapahoe Ave, Suite A   Phone: (720) 974-1841
Boulder, CO 80303Fax:   (303) 448-7756

Re: [petsc-dev] fortran literals

[Munson, Todd]

Cool!

For what its worth, that only works when PETSC_USE_FORTRANKIND is true.
I'm not sure how many of the Petsc builds have this flag set.

Any idea how to do the same thing in C?

Todd.

> On Sep 1, 2016, at 4:13 PM, Lisandro Dalcin  wrote:
> 
> 
> On 1 September 2016 at 23:05, Barry Smith  wrote:
>I didn't have a solution to this
> 
> ! These lines should be added to 
> $PETSC_DIR/include/petsc/finclude/petscsysdef.h
> #if defined(PETSC_USE_REAL_SINGLE)
> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
> #elif defined(PETSC_USE_REAL_DOUBLE)
> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
> #elif defined(PETSC_USE_REAL___FLOAT128)
> integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
> #endif
> 
> ! User code should write literals this way
> PetscReal x
> x = 0.123456789123456789123456789_PETSC_REAL_KIND
> 
> 
> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 0109
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459

Re: [petsc-dev] fortran literals

[Lisandro Dalcin]

On 1 September 2016 at 23:05, Barry Smith  wrote:

>I didn't have a solution to this
>

! These lines should be added to
$PETSC_DIR/include/petsc/finclude/petscsysdef.h
#if defined(PETSC_USE_REAL_SINGLE)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(5)
#elif defined(PETSC_USE_REAL_DOUBLE)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(10)
#elif defined(PETSC_USE_REAL___FLOAT128)
integer, parameter :: PETSC_REAL_KIND = selected_real_kind(20)
#endif

! User code should write literals this way
PetscReal x
x = 0.123456789123456789123456789_PETSC_REAL_KIND



-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [petsc-dev] fortran literals

[Munson, Todd]

>> 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, this does work at least for assignment statements on my mac with gfortran
and for real scalars.  It likely does not work for data statements or other 
types of initialization.

For complex, it also works if you use

  c = complex(PetscRealCast(0.12D0), PetscRealCast(0.12D0))

but not if you use the cmplx() function for the assignment.  Looks like
cmplx() always truncates the arguments to single precision (at least on
my mac with gfortran).

I would keep the dble() in the macro and let the compiler sort it out 
though.  Keeping it means that you get the correct behavior in single, 
double, and quad precision when your complier lets you use 
PetscRealCast(0.12Q0).

Todd.

Re: [petsc-dev] fortran literals

[Barry Smith]

   I didn't have a solution to this

> On Sep 1, 2016, at 2:36 PM, Munson, Todd  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.
> 

[petsc-dev] fortran literals

[Munson, Todd]

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.

=

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.