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