From: dpb on
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
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
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
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

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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Programmer's Paradise
Next: Reading a .wav file