specifying type of constant in floating-point initialization expression

In article <1kia0ah.ipbc0b1k58gvaN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> > > After people get past that, they can usually tell you whether
> > > they want 32-bit or 64-bit precision.
> >
> > Are there still any compilers with types with the same number of bits
> > but differently split between mantissa and exponent (like on the VAX)?
>
> Not to my knowledge. I am aware of the VAX case, but I can't cite any
> others quite like that.

Since there never was Fortran 90 for the VAX (at least not from DEC;
there was a company which had a Fortran90-to-VAXFortran translator, but
I don't think it was ever a mature product), this was always an
extension. It was a useful feature; in many (most?) cases, the reason
to have more bits is greater precision, not greater range. This
provided an option for more precision than DOUBLE PRECISION without
having to go to REAL*16.

In article <jlu6hb$r8v$1@online.de>,
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
reply) wrote:

> I understand the issues involved and perhaps Richard has convinced me to
> use KIND. However, since the whole point is flexibility, calling them
> "sp" and "dp" seems rather lame. Maybe one changes the definition, so
> that "sp" now corresponds to DOUBLE PRECISION. Yes, easier to change in
> one place, but anyone reading the code will associate a precision with
> this name, which is what one is trying to avoid. So if going this route
> I would suggest better names.

Yes, and you are not the first programmer to take this into account.
One of the common conventions is to use "wp" as the kind parameter
for working precision, and then assign or map that value as
appropriate. In cases where I might want to do mixed-precision
work, I use "wp", "ep", and "eep". Sometimes those all have the
same value, sometimes they have two values, and sometimes they have
three values, depending on what "wp" is at the time and what I'm
trying to do. In most of my work (on intel cpus), "wp" is 64-bit,
"ep" is 80-bit, and "eep" is 128-bit floating point, but sometimes
they map to 32-bit, 64-bit, and 80-bit.

It does take some effort to write code that works correctly with
these kinds of parameterized precisions. Things like root searches
and other iterative procedures need to have different tolerances and
convergence criteria. Modern fortran provides a nice set of
intrinsics that give you the floating point characteristics
(epsilon(), spacing(), nearest(), huge(), tiny(), and so on). I
cannot overstate how much better this situation is now than it was
in the 70's and 80's when this kind of portable programming was
almost impossible. This is why it seems so regressive to me to see
someone programming with old fashioned REAL and DOUBLE PRECISION and
with hardwired constants with D exponents. I certainly understand
why that is still in the language for back compatibility and legacy
code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT
WAY.

$.02 -Ron Shepard

In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes:

> This is why it seems so regressive to me to see
> someone programming with old fashioned REAL and DOUBLE PRECISION and
> with hardwired constants with D exponents. I certainly understand
> why that is still in the language for back compatibility and legacy
> code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT
> WAY.

What about an initiative to make them OBSOLESCENT?

Richard Maine <nospam@see.signature> wrote:

(previous snip on iso_fortran_environment)
>> > I was lukewarm when this was proposed in J3, but it has become
>> > one of the most-used features for me. It's a set-and-forget feature.

> I was really hot for it, just because it is so much simpler to explain
> to a new user than selected_real_kind. It makes the entry barrier lower
> for those new users. Most users can tell you pretty quickly whether they
> want a 32-bit or 64-bit real - a lot more quickly than they can tell you
> how many decimal digits of precision they need. Yes, I know that, in
> theory, one ought to have a detailed numerical analysis of the
> requirements. But that ain't what happens in practice in 99% of the
> cases. (That number being invented out of thin air, like 99% of the
> statistics people cite. :-)).

I might have come up with the same number, in about the same way.

If you write a program to solve just one instance of one specific
problem, then you might know the exact precision requirements.
If you want one to be generally useful for a wide variety of
problems, then usually not.

> There are plenty who haven't thought about the matter of
> precision at all, even needing it explained that precision
> is finite. After people get past that, they can usually tell
> you whether they want 32-bit or 64-bit precision.

Reminds me of all the PL/I programs with FLOAT BIN(21) and
FLOAT BIN(53), the numbers that match the IBM hardware.

Some fraction of those cases where you might do the analysis
on the needed precision, it can't actually be determined
until run-time, when the input data is available.

Reminds me of an interesting book I found not so long ago:

"Introduction to Precise Numerical Methods, Second Edition"
by Oliver Aberth

It includes discussion on the problems and methods of doing
calculations to a known precision, C++ routines to do such
calculations, and sample programs to use those routines.

This is for the case when you know (at compile or run time) the
precision you need in the result, and then need to propagate
that back through the calculation.

Available reasonably priced from the usual used book web sites.

>> Thanks for letting me know. Not sure if it's feasible to
>> upgrade the compiler, though.

> Note that, for the user sophisticated enough to specify a kind using
> either selected_real_kind, or even just a hard-wired, compiler-specific
> kind number (which ought to inclde any of the users in this discusion),
> it is easy enough to cope with lack of compiler support. Write your own
> module of just a few lines, like many of us do today. USE that module
> instead of iso_fortran_environment.

If a compiler doesn't support the intrinsic module, is it likely
to complain if you write one with the same name? Still, probably
better to give it your own name.

> Provided you are sufficiently consistent about the form of the
> USE statement, you could make it a simple sed (or comparable tool)
> operation to change all the USEs.

(snip)

-- glen

On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <1kia0ah.ipbc0b1k58gvaN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:
>
>> > > After people get past that, they can usually tell you whether
>> > > they want 32-bit or 64-bit precision.
>> >
>> > Are there still any compilers with types with the same number of bits
>> > but differently split between mantissa and exponent (like on the VAX)?
>>
>> Not to my knowledge. I am aware of the VAX case, but I can't cite any
>> others quite like that.
>
> Since there never was Fortran 90 for the VAX (at least not from DEC;
> there was a company which had a Fortran90-to-VAXFortran translator, but
> I don't think it was ever a mature product), this was always an
> extension.

FWIW, there has been some recent work to make GFortran (and the rest
of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
the CPU architecture is IA-64 rather than VAX, though.

--
JB

Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:

(snip on precision specification, someone wrote)

>> After people get past that, they can usually tell you whether
>> they want 32-bit or 64-bit precision.

> Are there still any compilers with types with the same number of bits
> but differently split between mantissa and exponent (like on the VAX)?

You ask about compilers, not about the underlying hardware.

For VAX, it was usual that the hardware supported one, but on
some it might be optional to support both.

The current IBM z/ systems support hex (S/360 form), binary (IEEE),
and decimal (new IEEE) all on one machine. The bits are divided
up differently among all three formats. (For the decimal form,
the division is finer than bits.)

I don't know if there are compilers that support more than one
in the same compilation, though.

-- glen

JB <foo@bar.invalid> wrote:
(snip)

>>> > Are there still any compilers with types with the same number of bits
>>> > but differently split between mantissa and exponent (like on the VAX)?

(snip)

>> Since there never was Fortran 90 for the VAX (at least not from DEC;
>> there was a company which had a Fortran90-to-VAXFortran translator,
>> but I don't think it was ever a mature product), this was always an
>> extension.

> FWIW, there has been some recent work to make GFortran (and the rest
> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
> the CPU architecture is IA-64 rather than VAX, though.

For Alpha, the VAX formats were supported by converting to/from
IEEE format. That is, the memory formats were supported, but when
loaded into registers they became IEEE format. (I have the manuals,
though I never did assembly programming on Alpha.) In that case,
the extra bits were silently lost.

I have an actual RX2600 running (well, currently turned off)
IA-64/VMS under a hobbyist license. It does have the HP Fortran
compiler. It would be interesting to run gfortran on it.
(Some time ago, RX-2600's were available on eBay for $100,
dual processor and 10GB RAM.)

I also have a MicroVAX 3100 which I should get running again.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:

> > Note that, for the user sophisticated enough to specify a kind using
> > either selected_real_kind, or even just a hard-wired, compiler-specific
> > kind number (which ought to inclde any of the users in this discusion),
> > it is easy enough to cope with lack of compiler support. Write your own
> > module of just a few lines, like many of us do today. USE that module
> > instead of iso_fortran_environment.
>
> If a compiler doesn't support the intrinsic module, is it likely
> to complain if you write one with the same name? Still, probably
> better to give it your own name.

Yes, using your own module name is what I had in mind. That also avoids
the problem of the compiler having the iso_fortran_environment module,
which was introduced in f2003, but not having those particular
parameters in it, as those weren't introduced until f2008. (I swear I
recall arguing for them in f2003, but obviously either I lost that
argument then or I misrecall the date and it was actually about f2008).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

In article <slrnjo63oj.lts.foo@hugo.hut.fi>, JB <foo@bar.invalid>
writes:

> FWIW, there has been some recent work to make GFortran (and the rest
> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
> the CPU architecture is IA-64 rather than VAX, though.

That would be interesting. At home, I have ALPHAs (and VAXes, though
none of these in use at the moment) and the Fortran95 compiler. AFAIK
there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
didn't make even Fortran90. (At work, we have only IA64 now, but no
Fortran on the machines I use.) Does anyone know if there is anything
later than Fortran95 for ALPHA? For IA64?

Does GFortran translate to C and compile that? If so, it probably
wouldn't be as efficient as a native compiler. (The VAX and ALPHA
compilers don't even go through intermediate assembly; they produce
object files directly.) Would still be interesting though.

In article <jlv2um$9au$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes:

> Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
>
> (snip on precision specification, someone wrote)
>
> >> After people get past that, they can usually tell you whether
> >> they want 32-bit or 64-bit precision.
>
> > Are there still any compilers with types with the same number of bits
> > but differently split between mantissa and exponent (like on the VAX)?
>
> You ask about compilers, not about the underlying hardware.
>
> For VAX, it was usual that the hardware supported one, but on
> some it might be optional to support both.

I don't know about the VAX hardware details; the Fortran compiler
offered two different 8-byte floating-point data types...

> The current IBM z/ systems support hex (S/360 form), binary (IEEE),
> and decimal (new IEEE) all on one machine. The bits are divided
> up differently among all three formats. (For the decimal form,
> the division is finer than bits.)
>
> I don't know if there are compilers that support more than one
> in the same compilation, though.

....and this was also possible if I remember correctly. (There was also
a compiler option to change the default.)

In article <jlv3hp$av0$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes:

> For Alpha, the VAX formats were supported by converting to/from
> IEEE format. That is, the memory formats were supported, but when
> loaded into registers they became IEEE format. (I have the manuals,
> though I never did assembly programming on Alpha.) In that case,
> the extra bits were silently lost.

Right. This was basically just for compatibility with programs reading
or writing binary data in the non-standard VAX format.

> I have an actual RX2600 running (well, currently turned off)
> IA-64/VMS under a hobbyist license. It does have the HP Fortran
> compiler.

What is the latest standard supported?

In article <1kia38p.j5oq78do7a5iN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> I swear I
> recall arguing for them in f2003, but obviously either I lost that
> argument then or I misrecall the date and it was actually about f2008).

Or maybe it was an optional argument and you assumed it was
present. :-)

On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <slrnjo63oj.lts.foo@hugo.hut.fi>, JB <foo@bar.invalid>
> writes:
>
>> FWIW, there has been some recent work to make GFortran (and the rest
>> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
>> the CPU architecture is IA-64 rather than VAX, though.
>
> That would be interesting. At home, I have ALPHAs (and VAXes, though
> none of these in use at the moment) and the Fortran95 compiler. AFAIK
> there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
> didn't make even Fortran90. (At work, we have only IA64 now, but no
> Fortran on the machines I use.) Does anyone know if there is anything
> later than Fortran95 for ALPHA? For IA64?

GCC supports both. For alpha, at least the alpha*-dec-osf* target was
somewhat regularly tested up to the 4.7 release, at some point
alpha-linux-gnu was also supported by GCC, though I don't know of the
current status nor if gfortran ever worked on it. For IA-64,
hppa2.0w-hp-hpux11.11 is still supported and AFAIK gfortran works,
also at least some ia64-unknown-linux-gnu target was supported at some
point though I don't know if gfortran worked there.

At least Intel used to provide Linux/IA-64 compilers, but IIRC the
latest version doesn't support it anymore.

> Does GFortran translate to C and compile that?

No. All the GCC frontends (C, C++, Objc, ObjC++, Fortran, Ada, Go,
Java) generate a common intermediate representation which is then
successively lowered until assembler for the target is eventually spit
out.

> (The VAX and ALPHA
> compilers don't even go through intermediate assembly; they produce
> object files directly.)

For GCC, see the -pipe option; it doesn't really affect CPU time used
by the compiler, but it might reduce wallclock time by avoiding the
(relatively slow) disk for temp files.


--
JB

In article <slrnjo6fds.qaq.foo@hugo.hut.fi>, JB <foo@bar.invalid>
writes:

> > That would be interesting. At home, I have ALPHAs (and VAXes, though
> > none of these in use at the moment) and the Fortran95 compiler. AFAIK
> > there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
> > didn't make even Fortran90. (At work, we have only IA64 now, but no
> > Fortran on the machines I use.) Does anyone know if there is anything
> > later than Fortran95 for ALPHA? For IA64?
>
> GCC supports both. For alpha, at least the alpha*-dec-osf* target was
> somewhat regularly tested up to the 4.7 release, at some point
> alpha-linux-gnu was also supported by GCC, though I don't know of the
> current status nor if gfortran ever worked on it.

Isn't Linux on Alpha dead? I'm pretty sure RedHat no longer supports
it.

Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:

(snip, I wrote)
>> For Alpha, the VAX formats were supported by converting to/from
>> IEEE format. That is, the memory formats were supported, but when
>> loaded into registers they became IEEE format. (I have the manuals,
>> though I never did assembly programming on Alpha.) In that case,
>> the extra bits were silently lost.

> Right. This was basically just for compatibility with
> programs reading or writing binary data in the non-standard
> VAX format.

Note that though the VAX format is slightly different, they byte
order is very different. It seems that it was inherited from
some hardware used with the PDP-11, and has little-endian 16 bit
words, in big endian order. I used to have some VAX Fortran
programs initializing arrays with hex constants, which are,
as usual, in the appropriate order for 32 bit integers.

>> I have an actual RX2600 running (well, currently turned off)
>> IA-64/VMS under a hobbyist license. It does have the HP Fortran
>> compiler.

> What is the latest standard supported?

http://h71000.www7.hp.com/doc/82final/6443/6443pro.html

Says "Fortran 90/95". I don't know why that, instead of Fortran 95.

-- glen