Prev: Programmer's Paradise
Next: Reading a .wav file
From: dpb on 10 Aug 2010 13:49 monir wrote: .... > My dilemma was that on one hand the compiler must support the > requested > (high) precision, and on the other, the requested precision must be > available in the hardware. > > The question then becomes how to (automatically) determine the highest > precision > available on a particular computer (processor, h/w) and use such info > to > (automatically) declare real variables in F90 code (s/w), and in the > process avoid possible conflict with the compiler (s/w). .... > My objective is to be sure that I'm using the highest precision > available on a particular m/c regardless of the end results. .... The net result of which (lack of) logic is pure nonsense... :( --
From: mecej4 on 10 Aug 2010 14:18 monir wrote: >.... > My objective is to be sure that I'm using the highest precision > available on a particular m/c > regardless of the end results. >.... This seems to be a tactic to avoid responsibility rather than an objective. This provides yet another proof of the adage: "To every complicated question there is an answer that is simple and direct -- and wrong". -- mecej4
From: e p chandler on 10 Aug 2010 14:23 On Aug 10, 12:50 pm, monir <mon...(a)rogers.com> wrote: > Hello; > > Thank you all for your thoughtful replies. > > 1) I must admit that I intentionally omitted the mention of h/w or s/w > in my OP. > The reason is rather simple ... I wasn't sure! > My dilemma was that on one hand the compiler must support the > requested > (high) precision, and on the other, the requested precision must be > available in > the hardware. Except that if you look at g95, it supports "qp" with a kind number of 16 and 33 digits in software. Software support at this precision is still being developed, so you will find some intrinsics missing. I'm no expert in numerical analysis but I do find it hard to believe that 33 decimal digits are not enough to solve your problem. I do know of some problems where you need very high precision integer arithmetic, but I don't think you are doing number theory or cryptography. There are other software packages that support much higher precisions than 33 digits, but these come at the expense of speed, just as "qp" on g95 does. For example, you can (essentially) have as many decimal digits as you want in the REXX language, but that is an interpreted langauge and while I HAVE used it for high precision integer calculations, it is slow. > As some of you have already stated, some sensitive calculations need > precision higher > than DP. Developing another procedure is not an option at this time. > As a matter of fact, some other academia are currently trying 80 > decimal digits precision > on a similar problem (with completely different boundary conditions; > so it is > not really similar!). I wish you and them the best of luck. I find it quite hard to believe that there is some soft of problem that has some basis in reality in the physical world where you really do need 80 digits.
From: Ron Shepard on 10 Aug 2010 16:08 In article <i3s54q$jfo$1(a)news.eternal-september.org>, mecej4 <mecej4.nyetspam(a)opFeramail.com> wrote: > monir wrote: > >.... > > My objective is to be sure that I'm using the highest precision > > available on a particular m/c > > regardless of the end results. > >.... > This seems to be a tactic to avoid responsibility rather than an objective. > > This provides yet another proof of the adage: "To every complicated question > there is an answer that is simple and direct -- and wrong". Here is a short program (which probably is simple, direct, and wrong :-) that displays all precisions that are supported by a particular machine and compiler. This tests for up to 1000 digits, but that can be changed if necessary. program print_precison implicit none integer :: kind, ip, last_kind integer, parameter :: MINDIGIT=1, MAXDIGIT=1000 last_kind = -99 do ip = MINDIGIT, MAXDIGIT kind = selected_real_kind(ip) if ( kind .ne. last_kind ) then write(*,*) 'kind=', kind, ' ip=', ip last_kind = kind endif if ( kind < 0 ) exit enddo if ( kind > 0 ) then write(*,*) 'higher precision is supported' write(*,*) 'MAXDIGIT should be increased' endif end program print_precison Here are some outputs using various compilers on an intel Mac. macrls [511]$ gfortran print_precision.f90; a.out kind= 4 ip= 1 kind= 8 ip= 7 kind= 10 ip= 16 kind= -1 ip= 19 macrls [512]$ f95 print_precision.f90; a.out kind= 4 ip= 1 kind= 8 ip= 7 kind= 16 ip= 16 kind= -1 ip= 32 macrls [513]$ ifort print_precision.f90; a.out kind= 4 ip= 1 kind= 8 ip= 7 kind= 16 ip= 16 kind= -1 ip= 34 Note however that this does not necessarily display all possible KIND values that are supported. That is a little more tedious to determine. The difficulty, as others have noted in this thread, is that there may be multiple KIND values for a given precision request, and selected_real_kind() only returns one of them. Also, given a potential KIND value, there is no way to test if it is valid or to determine its precision other than to use it in a declaration and see if the compiler supports it. The PRECISION() intrinsic could be modified to give this information (e.g. by adding a KIND= argument), but in its present form it cannot be used that way. $.02 -Ron Shepard
From: monir on 10 Aug 2010 22:33
A) In my previous posting I wrote: >2) Some of you have raised some concerns and possible conflict between >requesting higher precision, portability, numerical results, slow-down, >etc. >My objective is to be sure that I'm using the highest precision >available on a particular m/c regardless of the end results. I obviously misspoke! The part: " ... regardless of the end results." should read: " ... regardless of any ramification that might arise from the use of higher precision." B) I'm inclined to try the kind number 16 and 33 decimals with g95 compiler and see what happens. C) E.P. Chandler advised: >" ... if you look at g95, it supports 'qp' ... Software support at this >precision is still being developed, so you will find some intrinsics >missing." I looked at the G95 Manual (2007-1-1), and couldn't find any ref to "qp". Also, under "Key G95 Features" on page 2, it reads: .... REAL(KIND=10) for x86-compatible systems. 19 digits of precision, value range 10±4931 But as I showed in my previous reply, kind=10 is associated with 18 (not 19) decimal digits w g95. Will re-examine more thoroughly in the morning. Regards. Monir |