reasons for failure
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Uno on 20 May 2010 03:56 On 5/19/2010 11:33 AM, mecej4 wrote: >> q2) What are other methods to determine aspects of 64-bit processing? > > Look at MyComputer->Properties. If it does not say 64 somewhere there, > you are running a 32-bit version of Windows and you cannot run a version > of gfortran (or any other program) targeted to an X64 CPU. Indeed. Sometimes I use fortran to figure out the OS I'm on. Looks like they really pimped out paint on windows7. http://i46.tinypic.com/imj6oi.png -- Uno
From: robin on 20 May 2010 08:59 "Uno" <merrilljensen(a)q.com> wrote in message news:85h41mFsjhU1(a)mid.individual.net... | I've been trying to develop a 64-bit gfortran capability and was hopeful | that techniques I had been using would work on a friend's laptop, but I | think I failed. | | Am I correct to think that if I had 64-bit processing, then qp_preferred | would be positive: | | E:\fortran_stuff>type test1.f90 | implicit none | | integer, parameter :: sp = selected_real_kind(1,3) | integer, parameter :: dp = selected_real_kind(15,300) | integer, parameter :: qp_preferred = selected_real_kind(30,1000) | integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & | (1-sign(1,qp_preferred))/2*dp | | real (kind=sp) w | real (kind=dp) y | real (kind=qp) z | | w = 4.0*atan(1.0) | y = 4.0*atan(1.0) | z = 4.0*atan(1.0) Even if qp and qp_proferred were positive values, the values stored for y and for z are of single precision only. To obtain double precision value for y, you need to specify the constant as double precision, namely, atan(1.0_dp), and similarly for z, as atan(1.0_qp). | print *, sp,dp,qp_preferred,qp | print *, w,y,z | endprogram
From: Uno on 21 May 2010 02:49 steve wrote: Why is "64-bit processing" vague? -- Uno
From: Louis Krupp on 21 May 2010 08:20 On 5/21/2010 12:49 AM, Uno wrote: > steve wrote: > > Why is "64-bit processing" vague? Are you stating that "'64-bit processing' is vague" and asking why this is the case, or are you why "64-bit processing" is perceived to be vague? Louis
From: Tobias Burnus on 21 May 2010 08:44
On 05/21/2010 08:49 AM, Uno wrote: > Why is "64-bit processing" vague? First, because it does not tell about what part is 64bit; is is the pointer size? The size of a floating point number [REAL, REAL(8), DOUBLE PRECSION, REAL(selected_real_kind(...)]? The register size? ...? Secondly, because PowerPC 64 bit is different from Itanium (ia64), from SPARC64/PA-SPARC, from s960, from MIPS - and on x86-64 (= AMD64, Intel64, em64t, ...) the 64 bit mode is different again. For instance, PowerPC supports 128bit floating point operation in hardware while x86-64 does not. (Thus, on x86-64 using "REAL(16)"* either maps to 80bit (e.g. NAG w/ -kind=byte) or is implemented in software (e.g. Intel) or is not supported (e.g. gfortran); some compilers support the 80bit version via REAL(10) (e.g. gfortran) - others "only" REAL(4) and REAL(8).) Tobias (* For the moment I assume that kind number = variable size in bytes, which is a common choice but by far not universal. Use selected_real_kind, precision, and kind to choose the type/kind-number you want [assuming it exists].) PS: If I want to use double precision or - if present - the next higher precsion, I use: integer, parameter :: qp = & max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) |