Re: [petsc-dev] fortran literals
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
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
> 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
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
"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
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
"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
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)
> >>> 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
> >>
> >> --
> >> Departme
Re: [petsc-dev] fortran literals
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, USA
Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
Re: [petsc-dev] fortran literals
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
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
> 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
> 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
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 mailto:bsm...@mcs.anl.gov>> 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
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
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
>> 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
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
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.
