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 t
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 Kruge
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
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
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
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 e
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
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-Cham
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
> 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 hexadec
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 dif
"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 co
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
"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
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 wr
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, B
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_kin
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 ag
> 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 se
> 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 h
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
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 wro
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_
>> 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 "
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 res
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 default
26 matches
Mail list logo
