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: dpb on 23 May 2010 13:54 Uno wrote: .... > But every implementation we talk about around here associates a greater > integer with increased width in the representation, right? > > It seems like low-hanging fruit for a good idea to make standard next > time around. .... For what purpose, pray??? --
From: Richard Maine on 23 May 2010 14:14 dpb <none(a)non.net> wrote: > Uno wrote: > > > But every implementation we talk about around here associates a greater > > integer with increased width in the representation, right? > > > > It seems like low-hanging fruit for a good idea to make standard next > > time around. > > For what purpose, pray??? > Indeed, I prefer exactly the opposite direction, though I'm afraid it is too late now. Kinds should not be identified numerically at all, which would avoid the whole matter. Any miniscule potential benefit from having kind identifiers be numeric is more than overwhelmed by the ubiquitous confusions about what the numbers mean. In addition to people who assume that kind numbers must somehow relate to a byte size, we have things like people using kind numbers from selected_real_kind on integers and thinking that somehow makes them reals. Basically, kind values mean nothing according to the standard. Just like unit numbers. They are simply identifiers. If one is going to have everything identified by integers, we might as well get rid of variable names, too. We could just have every variable be numbered instead of named. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: dpb on 23 May 2010 14:24 Richard Maine wrote: .... > If one is going to have everything identified by integers, we might as > well get rid of variable names, too. We could just have every variable > be numbered instead of named. Indeed...(chuckles) --
From: Ian on 23 May 2010 17:01 The following is a paper that I've found useful. http://delivery.acm.org/10.1145/1170000/1165766/p24-mashey.pdf?key1=1165766&key2=9318464721&coll=GUIDE&dl=GUIDE&CFID=91367362&CFTOKEN=13731300 The following is also worth a look. http://www.unix.org/version2/whatsnew/lp64_wp.html Hope these help. Ian Chivers 22, 7:09 am, Uno <merrilljen...(a)q.com> wrote: > 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- Hide quoted text - > > - Show quoted text -
From: Uno on 23 May 2010 17:27
Richard Maine wrote: > dpb <none(a)non.net> wrote: > >> Uno wrote: >> >>> But every implementation we talk about around here associates a greater >>> integer with increased width in the representation, right? >>> >>> It seems like low-hanging fruit for a good idea to make standard next >>> time around. >> For what purpose, pray??? I don't know. It sounded good until I said it. >> > Indeed, I prefer exactly the opposite direction, though I'm afraid it is > too late now. Kinds should not be identified numerically at all, which > would avoid the whole matter. Any miniscule potential benefit from > having kind identifiers be numeric is more than overwhelmed by the > ubiquitous confusions about what the numbers mean. What would serve as a way to indicate failure? > > In addition to people who assume that kind numbers must somehow relate > to a byte size, we have things like people using kind numbers from > selected_real_kind on integers and thinking that somehow makes them > reals. Basically, kind values mean nothing according to the standard. > Just like unit numbers. They are simply identifiers. > > If one is going to have everything identified by integers, we might as > well get rid of variable names, too. We could just have every variable > be numbered instead of named. > I wanted to ask this back in the thread with the hollerith constants, where the scheme was somewhat dependent on having a 4-byte integer. Is there a portable to ask for one with a call to selected_int_kind? I think with gfortran you ask for integer*4, but I thought these weren't portable. -- Uno |