How to Determine Highest Precision Available on a PC ??
in [Fortran]
|
Prev: Programmer's Paradise
Next: Reading a .wav file
From: Richard Maine on 9 Aug 2010 16:04 monir <monirg(a)rogers.com> wrote: > On Aug 9, 2:00 pm, dpb <n...(a)non.net> wrote: > > Those are the uses of SELECTED_REAL_KIND() and PRECISION() > > > > There have been posted modules on clf previously for suggestions of > > generic usage/determinations... > > > 1) So to specify a desired precision one may use something like: > ...INTEGER, PARAMETER :: EP = SELECTED_REAL_KIND(35) > ...REAL (KIND = EP) :: X, Y > to declare the variables X and Y to be REAL floating-point variables > with 35 decimal digits accuracy. > But such desired precision may not be available on a particular m/c. > Would such declaration result in a compiler error ?? > Or would the compiler (g95) simply ignore it and assign whatever > (lower) precision available ?? Have you even tried to read any of the documentation of this intrinsic? I'm guessing not because most of the above is answered pretty explicitly and clearly even in the standard, which is not generally known for being easy reading. Any other reference ought to do at least as well. Most of the description of the intrinsic is about what happens when the specified range or accuracy requirements can not be met. I could understand being a little confused about the subsequent implications of what happens when you get a negative result from the intrinsic, but I can't see how one could even skim the description and still ask some of the above questions. Or for that matter, if you want to know what g95 in particular would do with the above code, I'd have thought it quicker to just try it than to ask on the net. You had to type those 2 lines into your post anyway, so it wouldn't have taken any more work to type them into a text editor. Three more characters (END), four characters if you count the line end, and you would have a compilable program; that's a lot fewer than the number of characters it took to type the post. Admitedly, that might not explain the why of what results, but it sure ought to answer the question of what g95 would do pretty definitively. (I just did it to make sure, and it gave the result I expected). Following the principle of teaching someone to fish instead of giving them a fish, I think I'll defer answering until after seeing some evidence of having at least skimmed some form of documentation. If there is then question about the subsequent implications, which I realize might not be evident from a quck skim, that part I'd answer. I'm not really trying to be obnoxious here (though I could see it misinterpreted that way). I'm just trying to push in the direction of suggesting that it is better to do at least token research/thought before asking. Think of it as using up wishes, where the wishes are answers to questions. If you use up all your quota of wishes asking questions that you could have answered yourself in less time than it takes to type in a post, people are likely to have tired of answering when you get to the harder ones where outside help would really be more productive. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: James Van Buskirk on 9 Aug 2010 16:06 "dpb" <none(a)non.net> wrote in message news:i3plg5$otv$1(a)news.eternal-september.org... > It isn't the design to probe the hardware for the highest possible > supported native type which seemed to be the way the question was worded > in your posting. Actually it's possible because the kind type parameters are numeric. I and others have posted examples of this many times on this forum. Here is a program that probes at compile time for two kinds of real with more precision than double precision has: C:\gfortran\clf\kinds>type kinds.f90 program kinds implicit none integer, parameter :: sp = kind(1.0) integer, parameter :: dp = kind(1.0d0) integer, parameter :: ep_preferred = & selected_real_kind(precision(0.0_dp)+1) integer, parameter :: ep = (1+sign(1,ep_preferred))/2*ep_preferred+ & (1-sign(1,ep_preferred))/2*dp integer, parameter :: qp_preferred = & selected_real_kind(precision(0.0_ep)+1) integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & (1-sign(1,qp_preferred))/2*ep write(*,10) 'sp = ', sp, ', precision(sp) = ', precision(1.0_sp) write(*,10) 'dp = ', dp, ', precision(dp) = ', precision(1.0_dp) write(*,10) 'ep = ', ep, ', precision(ep) = ', precision(1.0_ep) write(*,10) 'qp = ', qp, ', precision(qp) = ', precision(1.0_qp) 10 format(3(a,i0)) end program kinds C:\gfortran\clf\kinds>gfortran kinds.f90 -okinds C:\gfortran\clf\kinds>kinds sp = 4, precision(sp) = 6 dp = 8, precision(dp) = 15 ep = 10, precision(ep) = 18 qp = 10, precision(qp) = 18 C:\gfortran\clf\kinds>ifort kinds.f90 Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1 Build 20061104 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 8.00.40310.39 Copyright (C) Microsoft Corporation. All rights reserved. -out:kinds.exe -subsystem:console kinds.obj C:\gfortran\clf\kinds>kinds sp = 4, precision(sp) = 6 dp = 8, precision(dp) = 15 ep = 16, precision(ep) = 33 qp = 16, precision(qp) = 33 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. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: dpb on 9 Aug 2010 16:38 James Van Buskirk wrote: > "dpb" <none(a)non.net> wrote in message > news:i3plg5$otv$1(a)news.eternal-september.org... > >> It isn't the design to probe the hardware for the highest possible >> supported native type which seemed to be the way the question was worded >> in your posting. > > Actually it's possible because the kind type parameters are numeric. > I and others have posted examples of this many times on this forum. > Here is a program that probes at compile time for two kinds of real > with more precision than double precision has: .... > 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). --
From: glen herrmannsfeldt on 9 Aug 2010 16:43 monir <monirg(a)rogers.com> wrote: (snip) > Suppose one needs to use a higher precision than > "double-precision" reals. > 1) How does one determine if a PC has a kind type that supports a > "triple-precision" or "quadruple-precision" or even higher ?? I by support, do you mean in hardware? The Intel IA32 x87 instructions use a stack of 80 bit (64 bit significand) floating point values. That is a little more than the 53 significant bits for IEEE double, but not quite triple or even quadruple. As for actual quadruple precision, The IBM 360/85, and all S/370 and later models support quadruple precision in hardware, except for divide. More recently DXR (quad divide) was added. Even later IBM machines support quad precision in binary and decimal, though possibly in millicode. The DEC VAX instruction set includes H-float, quadruple precision, but it is implemented through software emulation on most VAX processors. The VAX 11/730 had it in microcode, but that was almost the bottom end of the VAX line. Still, it was probably faster than the software emulation on other VAX processors. It might be that some SPARC processors implement it, I haven't confirmed that. It is in the instruction set, but again might be implemented through software emulation. Even longer ago, the CDC machines with 60 bit single precision implemented (possibly in software emulation) 120 bit double precision. The Fortran standard requires double precision, no matter how many or few bits are available in single precision. > 2) Can one type a simple DOS command to determine the highest > precision available on a particular m/c (Win XP) ?? All intel processors from the 80486 on implement the x87 instructions. None implement in hardware anything more than that. A DOS program that prints 80 is pretty easy to write. It could verify that it wasn't running on an 8086 without the 8087 before printing that, though. > 3) Is it possible to use an F90 intrinsic function (if available) to > automatically assign reals to the highest precision (for > portability) ?? > (something similar to using TINY() or EPSILON() in a numerical model) Others have explained that. Despite what that, if you want hardware to implement it you are fairly restricted. Otherwise, the traditional way was to use a software multiple precision package that allows any precision you want, usually in multiples of 32 bit words. That is done through subroutine calls, and not directly through Fortran expressions. -- glen
From: James Van Buskirk on 9 Aug 2010 17:26
"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. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end |