Prev: Programmer's Paradise
Next: Reading a .wav file
From: dpb on 9 Aug 2010 17:35 James Van Buskirk wrote: > "dpb" <none(a)non.net> wrote in message > news:i3pp5t$91p$1(a)news.eternal-september.org... > >> James Van Buskirk wrote: > >>> Note how different compilers may have different kinds of real >>> numbers represented and how this technique makes the different >>> kinds available to the program programatically. > >> Surely, but... > >> That's not precisely what I was driving at -- it's possible one (or more) >> of those is a software emulation, not a native hardware implementation. I >> was simply stating one can find out what floating point models are >> supported by any given compiler on any given platform; I'm not sure you >> can always presume they're all native even though REAL_SELECTED_KIND() >> returns a valid KIND number. Odds are pretty good, granted, just not >> guaranteed (unless I'm mistaken about what the Standard actually says >> which is always possible). > > I must have read the OP's intent differently from you. If you use an > inquiry intrinsic to obtain a kind number for a kind that doesn't > exist and attempt to use it as a kind number, the compiler just > rejects the code. This seems to me to be the circumstance that the OP > was hoping to guard against. Whether the hardware directly supports > a more precise kind of real is a different question entirely and not > the way I would have read the OP's inquiry. For example, x86 directly > supports 10-byte extended precision reals, but ifort doesn't support > them on hardware that does, preferring instead 16-byte quadruple > precision in emulation. gfortran does support 10-byte extended > precision on x86-64, but the support as it comes with the compiler is > only partial and you have to perform a further song and dance to get > even that partial support to work. Perhaps...it was his second queries that led me to think he was approaching the question from the standpoint of trying to interrogate the hardware in which he asked about OS utilities to query a particular computer as opposed to the compiler doing so of the platform and the one about the highest precision available for compatibility. I was just trying to recouch thinking in terms of "what does the application require to run successfully?" instead of a "what would the maximum precision available at runtime be?" approach that seemed (at least to me) the mindset behind the way the question was posed. As always, I may have missed the mark (I didn't see if the crystal ball had anything to say on this one... :) ) --
From: glen herrmannsfeldt on 9 Aug 2010 17:45 dpb <none(a)non.net> wrote: (snip) > That's not precisely what I was driving at -- it's possible one (or > more) of those is a software emulation, not a native hardware > implementation. I was simply stating one can find out what floating > point models are supported by any given compiler on any given platform; > I'm not sure you can always presume they're all native even though > REAL_SELECTED_KIND() returns a valid KIND number. Odds are pretty good, > granted, just not guaranteed (unless I'm mistaken about what the > Standard actually says which is always possible). The standard doesn't say much at all about how fast anything should be expected to get done. There is compiler/library software emulation, system emulation on unimplemented opcodes, millicode (on some IBM systems), microcode (even if some operations are done without it), microcode for everything, nanocode (two levels of control store), and random logic hardware. Then again, the whole system could be software emulation of the entire processor. -- glen
From: steve on 9 Aug 2010 18:07 On Aug 9, 2:26 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > gfortran does support 10-byte extended > precision on x86-64, but the support as it comes with the compiler is > only partial and you have to perform a further song and dance to get > even that partial support to work. Can you elaborate on what your song and dance are? gfortran has supported REAL(10) for a very long time. There, of course, could be a few bugs lurking, but unreported bugs have little chance in being fixed. -- steve
From: dpb on 9 Aug 2010 18:34 glen herrmannsfeldt wrote: > dpb <none(a)non.net> wrote: > (snip) > >> That's not precisely what I was driving at -- it's possible one (or >> more) of those is a software emulation, not a native hardware >> implementation. I was simply stating one can find out what floating >> point models are supported by any given compiler on any given platform; >> I'm not sure you can always presume they're all native even though >> REAL_SELECTED_KIND() returns a valid KIND number. Odds are pretty good, >> granted, just not guaranteed (unless I'm mistaken about what the >> Standard actually says which is always possible). > > The standard doesn't say much at all about how fast anything > should be expected to get done. > > There is compiler/library software emulation, system emulation > on unimplemented opcodes, millicode (on some IBM systems), > microcode (even if some operations are done without it), microcode > for everything, nanocode (two levels of control store), and > random logic hardware. > > Then again, the whole system could be software emulation of > the entire processor. Indeed...as explained above in response to James, it seemed to me OP was fishing for a hardware-related answer and I was trying w/o getting too involved to say "it ain't necessarily so"... Also as noted, maybe I didn't interpret the question as intended to have been. --
From: Giorgio Pastore on 9 Aug 2010 18:42
monir wrote: .... > 1) How does one determine if a PC has a kind type that supports a > "triple-precision" or "quadruple-precision" or even higher ?? Others have answered to this question. Let me stress only that "kind" is an attribute of Fortran data types. It is not an attribute of the PC the compiler is running on. > 2) Can one type a simple DOS command to determine the highest > precision available on a particular m/c (Win XP) ?? Having understood the previous point, it is clear that you cannot ask the underlying OS (DOS or whatever you have) about something known only to the Fortran compiler (and, again already stated, you may have more than one compiler on the same PC, providing different maximum precisions). > 3) Is it possible to use an F90 intrinsic function (if available) to > automatically assign reals to the highest precision (for > portability) ?? I am quite puzzled by your referring to portability. You might use one of the suggested methods to be sure your program is always using the highest available precision (even though it may make an important difference if that precision is implemented in hardware or in software). But I have hard time understanding how a program of this kind could be called portable. Maybe the code could be portable. Almost certainly numerical results won't be. My point of view is that either double precision is enough for your calculations (you can exploit higher precision just to check this point) or it is not enough and maybe you need higher precision (although at this point it could be better to check possible restructuring of formulae or alternative algorithms). But in the case you really need higher precision, your chances of portability may be strongly reduced. Take into account that the same compiler may provide higher precision on some HW but not on others. And it is not necessary to go to exotic combinations of HW and SW. On the powerPC mac I am using right now to reply, I have a g95 compiler which does not provide real with more than 64 bits. The same compiler on a x86 architecture provides extended precision with 80 bits. Giorgio |