From: glen herrmannsfeldt on
jamesgiles(a)att.net wrote:
(I wrote)

>>But are we really at the point where affordable hardware will be
>>available for scientific programming? [...]

> Are we really to the point where the Fortran community can disregard
> scientific programming whether it's affordable or not? It is my
> perception that few programmers still bother with Fortran unless they
> work for or do business with large "linguistically inertial"
> institutions that still use it heavily. All *that* crowd still buys
> the big iron.
(snip on IBM and DEC REAL*16)

z/ machines with both hex and binary REAL*16 are available from IBM.

>>I don't believe that either ever had as much use as one
>>might expect.

> I didn't expect either to have much use. I thought those features
> were introduced to try to grab market share from CDC and later from
> Cray. But neither IBM nor DEC were ever really competitive in that
> market. A market that you now seem to imply should be disregarded.

I wasn't trying to disregard it, but wondering if we were at
the point where it would be available in mass market machines.
I believe there is a lot of science done on low or mid range
systems. It is nice to have the extra precision for intermediate
results, such as in matrix multiplication, even when it isn't
needed in the end.

> In any case, I don't buy your argument that 64-bit integer/float
> defaults can't happen until cheap hardware 128-bit float is common. I
> think the two things are completely separable. Cray didn't have
> hardware double, but I never really ran into people that wished the
> default precision was half-word.

Both Cray and CDC caused lots of problems for Fortran users.
Richard has more stories than I do, but basically you want
DOUBLE PRECISION on other machines, but single on CDC and Cray.
Also, the appropriate (E or D) exponents on constants.

I know a lot of programs with sections that should be uncommented
depending on the target machine.

> In any case, isn't this an argument to no real point? If you are
> programming on a platform that has 32-bit arithmetic still in hardware
> it's likely the compiler will have a switch that permits you to retain
> that size as your default if you wish. In the near-term the reverse
> is likely to be true: if you want REAL/INTEGER/LOGICAL to default to
> 64-bit you'll have to specify a compiler option for that. If you
> neighbor doesn't choose to do so, then (s)he won't have to. If you
> try to inter-operate your codes, the compiler will catch the mismatch
> (TKR checking).

It does get hard if you are trying to do both at the same time.
Otherwise, yes.

-- glen

From: John Harper on
In article <SMSdnbEAKat0GJLVnZ2dnUVZ_uidnZ2d(a)comcast.com>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
>I would say that there are still plenty of problems where 24 bits
>is enough, but yes, for larger problems, especially those that depend
>on matrix arithmetic, finite difference, or other precision losing
>operations, it isn't.
....
>Do business users need the extra precision?

Some do. I think I read somewhere that in the 19th century the London
Stock Exchange's annual turnover was of order 4e10 pounds and the
accounts had to balance to the uttermost penny (then 1/240 pound) so
the arithmetic had to be correct to 1 part in 10**13. Presumably the
clerks could cope, with their paper and quill pens.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper(a)vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
From: Dan Nagle on
Hello,

On 2008-04-23 14:59:53 -0400, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said:

> I would say that there are still plenty of problems where 24 bits
> is enough,

That I know of, the primary application of 32-bit reals
is signal processing. That includes a lot of seismic work
(oil exploration, among others).

A few years back, I was asked to survey a major supercomputer
center's users about precision requirements. The results
were 64-bit ~ 70%; 32-bit - 25%; 128-bit ~ 5%. (The 128-bit
users were solving very stiff DEs.)

--
Cheers!

Dan Nagle

From: Charles Coldwell on
andrej.panjkov(a)climatechange.qld.gov.au writes:

> Quite a few compilers support different representations for LOGICAL
> types: 1 byte, 2 byte 4 byte...and 8 byte?
>
> What applications are there for 8 byte LOGICAL types? (Or for 2 byte
> types?)
>
> I understand that the default size is often 4 bytes for likely
> performance reasons (register loads and stores, address alignment).
>
> Smaller sizes are useful for packing data, but if space is an issue,
> why pack logicals into two bytes and not one?
>
> Just curious...

My guess would be for alignment. Some hardware is just much happier
with 64-bit aligned loads and stores ... so if you don't mind
squandering the memory you'll get higher performance logicals?

Chip


--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
GPG Key ID: 852E052F
GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F
From: jamesgiles on
On Apr 23, 3:03 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> jamesgi...(a)att.net wrote:

> [...]  Cray didn't have
> > hardware double, but I never really ran into people that wished the
> > default precision was half-word.
>
> Both Cray and CDC caused lots of problems for Fortran users.
> Richard has more stories than I do, but basically you want
> DOUBLE PRECISION on other machines, but single on CDC and Cray.

But most of those problems had to do with the lack of KIND and KIND
inquiry in those days. It wasn't that the programmers objected to
large precision as the default. And, losing access to platforms that
had such defaults has caused more problems than switching to such
platforms ever did.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare