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: James Van Buskirk on 21 May 2010 11:25 "Tobias Burnus" <burnus(a)net-b.de> wrote in message news:4BF6802F.3060907(a)net-b.de... > 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)) Where in the standard does it say that the higher precision kind has to have a larger kind type parameter? The kind number for quadruple precision could be zero, at least in my understanding. That's why I came up with that strange dance with SIGN. In f2003, MERGE would be lots more readable. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Richard Maine on 21 May 2010 12:50 Uno <merrilljensen(a)q.com> wrote: > steve wrote: > > Why is "64-bit processing" vague? I can't find where Steve wrote any such thing, which makes that post sort of vague to me. :-) I'll guess that the "steve wrote" part is an incomplete reference to Steve's comment that "64-bit processing" is vague. I can find where Steve said that, although not in the post that Uno was directly following up to. I further guess that it is Uno asking why this is so. "64-bit processing" is vague for the same reason that anything is vague. Namely, it does not have a well-defined meaning. That's what "vague" means. In large part, "64-bit processing" has come to be a term used by marketting folk. As is typical with much marketting, you can't count on any particular meaning. It sounds like a good thing, so vendors will claim their product has it, warping the meaning in whatever way they need to in order to rationalize the claim. Marketting is like that. For an example from a while ago, Intel used to say that the 8088 was an 8-bit processor; I had Intel documentation using that description. Somewhat later, Intel started describing the same chip as being a 16-bit one. Nothing changed about the chip. All that changed was Intel's marketting definitions. More to the current point, did you not read Glen's reply to your original post? As Glen said >> 64 bit processing means that the address space is greater >> than 4GB. I might modify Glen's "means" with something like "most commonly". It is evident from your original question > Am I correct to think that if I had 64-bit processing, then > qp_preferred would be positive: That you were thinking of "64-bit" as being something almost completely unrelated. There are also other people who assume this is what it means, even though that's not usually the case when you read the term today. That is a quite common source of misunderstanding. When different people, or even the same people at different times, have different notions of what "64-bit processing" means, then that indeed makes it vague. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Uno on 22 May 2010 02:09 On 5/21/2010 5:44 AM, Tobias Burnus wrote: > 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).) Alright, let me see if I understand. We have at least three different categories to think of: 1) Pointer size 2) size of floating point entities 3) register width 4) Presumably other things that I won't understand. I'm not sure what you mean with your second paragraph, but is it that A) PowerPc B) Itanium (ia64) C) SPARC64/PA-SPARC, from s960, from MIPS D) x86-64 (= AMD64, Intel64, em64t, ...) have differing values for 1-4? -- uno
From: Uno on 22 May 2010 02:22 On 5/21/2010 5:20 AM, Louis Krupp wrote: > 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? I guess I wonder other people would call this: http://i46.tinypic.com/imj6oi.png Process. Many meanings. I process by writing. -- Uno
From: Uno on 22 May 2010 02:56
On 5/21/2010 5:44 AM, Tobias Burnus wrote: > 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)) I missed this. E:\gcc_eq32>out 4 8 10 3.1415927 3.1415927410125732 3.1415927410125732422 E:\gcc_eq32>type tobias1.f90 implicit none integer, parameter :: sp = selected_real_kind(1,3) integer, parameter :: dp = selected_real_kind(15,300) integer, parameter :: qp = & max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) real (kind=sp) w real (kind=dp) y real (kind=qp) z w = 4.0_sp*atan(1.0) y = 4.0_dp*atan(1.0) z = 4.0_qp*atan(1.0) print *, sp,dp,qp print *, w,y,z endprogram ! gfortran -Wall -Wextra tobias1.f90 -o out.exe E:\gcc_eq32> Looks like I got 3 sig figs for having asked for qp. VielenDank, Tobias. Gruss, -- Uno |