X = DBLE(Y)

[Phillip Helbig---undress to reply]

I have some code in DOUBLE PRECISION which, however, has real input and
output values. The input values are converted to internal variables via
DBLE and the results are converted to the output values via REAL.

Suppose an input value X is some number which has no exact
floating-point represenation, e.g. 2.63. What should I expect the value
DBLE(X) to be, tested by PRINT* during the code? Should I expect
2.63000000000000000 or 2.63<"random" digits>?

I will read some responses first then post more information.

[dpb]

Functions that cause conversion of one data type to another type
have the same effect as the implied conversion in assignment
statements.

So, you shouldn't expect some magic zero (decimal) extension just
because of the explicit cast.

0 (binary digits) extension doesn't translate to zero in decimal in
floating point representation.

So, the answer is the later (but they're not "random" (altho I presume
that the quotes mean you understand that, maybe, I'm not sure???).

--

[Phillip Helbig---undress to reply]

In article <juh1p3$pf7$1...@speranza.aioe.org>, dpb <no...@non.net> writes:

> > I have some code in DOUBLE PRECISION which, however, has real input and
> > output values. The input values are converted to internal variables via
> > DBLE and the results are converted to the output values via REAL.
> >
> > Suppose an input value X is some number which has no exact
> > floating-point represenation, e.g. 2.63. What should I expect the value
> > DBLE(X) to be, tested by PRINT* during the code? Should I expect
> > 2.63000000000000000 or 2.63<"random" digits>?
>

> Functions that cause conversion of one data type to another type
> have the same effect as the implied conversion in assignment
> statements.

Right. Considering this, is there any reason to use them, except to
force the conversion to be done just once rather than many times if they
are used in more than one expression which needs conversion? (Now, I'm
discussing only the values, not the difference between DBLE(X)/DBLE(Y)
and DBLE(X/Y).)

> So, you shouldn't expect some magic zero (decimal) extension just
> because of the explicit cast.

OK.

> 0 (binary digits) extension doesn't translate to zero in decimal in
> floating point representation.

OK.

> So, the answer is the later (but they're not "random" (altho I presume
> that the quotes mean you understand that, maybe, I'm not sure???).

Right, that's what the quotes mean!

Presumably, once the value is stored in a REAL variable, the information
regarding it's "real" value is lost, due to the finite precision.

Suppose I have something like 2.63 as a character string. Is there a
way to get this into a DOUBLE PRECISION variable with value
2.6300000000? (Yes, there's probably a better solution to my problem;
I'm just asking this out of curiosity.)

[dpb]

On 7/22/2012 9:21 AM, Phillip Helbig---undress to reply wrote:
> In article<juh1p3$pf7$1...@speranza.aioe.org>, dpb<no...@non.net> writes:

...

>> Functions that cause conversion of one data type to another type
>> have the same effect as the implied conversion in assignment
>> statements.
>
> Right. Considering this, is there any reason to use them, except to
> force the conversion to be done just once rather than many times if they
> are used in more than one expression which needs conversion? (Now, I'm
> discussing only the values, not the difference between DBLE(X)/DBLE(Y)
> and DBLE(X/Y).)

I see no advantage, no. One may as well write

Y=X ! where Y is the DP; X the SP variable

as

Y=DBLE(X)

and just use Y from then on.

Altho it probably can't be be assured, I'd expect compilers to be pretty
smart in not doing unnecessary conversions in localized areas of code
even if written explicitly during optimization.

...

> Suppose I have something like 2.63 as a character string. Is there a
> way to get this into a DOUBLE PRECISION variable with value
> 2.6300000000? (Yes, there's probably a better solution to my problem;
> I'm just asking this out of curiosity.)

Sure...internal READ into a DP variable will do the conversion just as
it would from external i/o

The better solution would probably be to go ahead and do the
above--convert the input variables to DP and let the i/o rtl take care
of it for you transparently.

I'd say today any concern about the extra memory required of DP over
single that may have prompted such when the code was written has pretty
much vanished unless it's either a huge set of data or a very restricted
environment either of which probably deserves other considerations anyway.

--

[dpb]

On 7/22/2012 9:21 AM, Phillip Helbig---undress to reply wrote:
...

> Presumably, once the value is stored in a REAL variable, the information
> regarding it's "real" value is lost, due to the finite precision.

...

Precisely.

Once converted to SP as closely as it can be represented by that number
of bits the DBLE simply preserves _that_ value as nearly as it can with
its (larger) number of bits.

As noted in other response if you want to produce closest representation
to 2.630000... in DP, then the simplest way is to use DP for the i/o to
begin with.

You can do things like write to internal w/ an appropriate FORMAT to
force rounding and then use internal READ into a DP but I'd think it
better use of time and effort to do the overall conversion instead.

--

[Gordon Sande]

On 2012-07-22 10:51:35 -0300, Phillip Helbig---undress to reply said:

> I have some code in DOUBLE PRECISION which, however, has real input and
> output values. The input values are converted to internal variables via
> DBLE and the results are converted to the output values via REAL.

I am unclear what is meant at a very low mechanical level. The charaters
"2.63" intended as input do not have a type of REAL or DOUBLE PRECISION.
That is a matter of whatever reads the characters. Likewise for output
as the output characters no longer have a type.

If you read it as a REAL and then assign the result to a DOUBLE PRECISION
the result will be different than just reading it as a DOUBLE PRECISION.

> Suppose an input value X is some number which has no exact
> floating-point represenation, e.g. 2.63. What should I expect the value
> DBLE(X) to be, tested by PRINT* during the code? Should I expect
> 2.63000000000000000 or 2.63<"random" digits>?

If "2.63" is read into a REAL and then printed out to 30 decimal places
(with a functioning output) I would expect 2.63000?????? and if it were
read into a DOUBLE PRECISION I would expect 2.63000000000000????????.
That is garbage past the precision of the type. If it was REAL and then
assigned to a DOUBLE PRECISION the output would be as for the REAL case.
Likewise if read as DOUBLE PRECISION and then assigned to REAL and output.
Widening gains no precision and narrowing looses precision for this read
and print example.

I am not clear what role the DBLE() function is expected to play as its role
is to make conversions explicit. It is sometimes required when the context
is clear but not the intended result like inside parentheses or in arguments.
The usual examples of I/J becoming 0 when DBLE(I)/DBLE(J) was intended or
when N is passed to a DOUBLE PRECISION X but should have been DBLE(N). The
conversions could have been done by assignemnt at a cost of additional
statements, identifiers and general bother. The issue of whther implicit
conversion on assignment is good or bad is a separate issue of good
programming style.

[Phillip Helbig---undress to reply]

In article <juhb5e$845$1...@dont-email.me>, Gordon Sande

<Gordon...@gmail.com> writes:

> On 2012-07-22 10:51:35 -0300, Phillip Helbig---undress to reply said:
>
> > I have some code in DOUBLE PRECISION which, however, has real input and
> > output values. The input values are converted to internal variables via
> > DBLE and the results are converted to the output values via REAL.
>
> I am unclear what is meant at a very low mechanical level. The charaters
> "2.63" intended as input do not have a type of REAL or DOUBLE PRECISION.
> That is a matter of whatever reads the characters. Likewise for output
> as the output characters no longer have a type.

By "input" and "output", I was referring to the arguments of a
subroutine.

[dpb]

On 7/22/2012 12:00 PM, Phillip Helbig---undress to reply wrote:
...

> By "input" and "output", I was referring to the arguments of a
> subroutine.

Oh, I was assuming that had to do w/ the external input/output, not
subroutine arguments.

Either way, the precision/conversion to/from single-double is limited by
the initial storage precision however that was generated.

--

[Gordon Sande]

Where is the conversion on input or output being done? Otherwise
you are just talking about the results of type mismatch on a
subroutine call. If you play those sorts of games you deserve
any and all bad results!!! That is why F90 has better debugging
and why there are tools like FTNCHECK (however it is spelt) and
the various debugging compilers that were in use with F77. FTN77
from Silverfrost is both highly reputed and free. There is also
FTN90 which does F90 and even has undefined variable checking.
With FTN90 you do not even have the excuse that it is a big bother
to make everything into modules to get the F90 checking.

Yes it is a bloody great bother to use the tools but it is your foot
that is getting all the bullet holes and maybe it is your results that
are not going to be reproducible. If I sound unsympathetic it is because
I am. It is the old story that we do not have the time to do it right but
will find the time to do it over when trouble finally hits.

About the only place where deliberate type mismatch is in any
sense tolerable is when you are playing the old F77 do-it-yourself
dynamic allocation. Even then you should equivalence the various types
to lower your level of living in mortal sin. In those cases there is no
notion that the contents are being transferred or have any meaning.

[dpb]

On 7/22/2012 1:12 PM, Gordon Sande wrote:
> On 2012-07-22 14:00:20 -0300, Phillip Helbig---undress to reply said:

...

>> By "input" and "output", I was referring to the arguments of a
>> subroutine.
>
> Where is the conversion on input or output being done? Otherwise
> you are just talking about the results of type mismatch on a
> subroutine call. If you play those sorts of games you deserve

> any and all bad results!!!...

Yeah, but I think he's talking of something like

real :: argX

call foo(argX)
...

subroutine foo(argx)
real :: argx
double precision :: y, z

...

y=dble(argx)

....
!work done on y or as in

z=some_functional_form * dble(argx)

...

argx= real(z)
end subroutine

It's DP "all the way down" as far as the computations are concerned but
the input and output parameters are passed as singles.

I was presuming something very similar except that the variables were
being read from an external source as SP before something like the above
was being done internally then converted back before external output...

Either way, there's nothing illegal going on just that his decimal value
that looks on paper something like 2.63 isn't as close a representation
as it could be in DP owing to the cast and he'd like a way to address that.

Now, maybe I've presumed too much and am all wet, but I _think_ the
crystal ball got this one right... :)

--

[Ron Shepard]

In article <juhbj3$pd$1...@online.de>,
hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to

Alright, with this in mind, let's go back to the original post:

> I have some code in DOUBLE PRECISION which, however, has real input and
> output values. The input values are converted to internal variables via
> DBLE and the results are converted to the output values via REAL.

Ok, here you are talking about subroutine arguments. Presumably the
actual and dummy arguments match and are both declared REAL.

> Suppose an input value X is some number which has no exact
> floating-point represenation, e.g. 2.63.

This simply is not possible. Every real value of the actual
subroutine arguments has a floating point representation. That real
value is associated (by address, or by copying its value, or
whatever) with the dummy argument of the subroutine. This then
means that every value for that dummy argument has an exact floating
point representation.

> What should I expect the value
> DBLE(X) to be, tested by PRINT* during the code? Should I expect
> 2.63000000000000000 or 2.63<"random" digits>?

First, I would say that DBLE() is an intrinsic function that should
never (well, almost never) be used in new code. If you are trying
to understand how some existing code works, then you certainly need
to understand it. But for new code, you should almost certainly be
using the REAL() intrinsic to do these kinds of precision
conversions between different KINDs of REAL values. It might take a
few more keystrokes, but it makes it clear what kind of conversion
is expected by the programmer.

Now, having said that, the conversion from a short precision to a
longer precision is done by appending binary zero digits to the
short precision number. This means that the arithmetic value of the
floating point number does not change. However, when printed, you
may see different numbers printed; this is sometimes due to errors
in the binary to decimal conversion routines (the standard C library
was a common cause for these errors for many years in the 80's), and
in other cases it is a question of how the values are rounded as the
decimal digits are computed. But the important thing is that the
floating point value is not changed, at all, not even in the last
bit.

Going the other way, from longer precision to shorter precision, is
a different matter of course. Here there are issues related to
rounding and truncation of nonzero bits.

Finally, you mention "random" digits. There should be some nonzero
decimal digits printed out in most cases due simply to the binary to
decimal conversion. But they are not an infinite number, they
always terminate at some number of decimal digits. You can see this
just by computing the decimal values for the binary digits.

.1 .5
.01 .25
.001 .125
.0001 .0625

As you can see, there are as many decimal digits as there are binary
digits, but no more. The allowed floating point values are just
sums of some subset of those values, so each floating point value
has an exact decimal value, and the number of digits required to
represent that value is no more than the last nonzero binary digit.
That means that 24 decimal digits are required to represent any
single precision binary mantissa and 53 decimal digits are required
to represent any double precision binary mantissa (note that most
modern floating point representations include a hidden bit, if you
are wondering where the extra bit comes from).

You almost never see that many decimal digits printed out. Why not?
It is because in order to reproduce a given floating point number,
only enough decimal digits are required so that the ***rounded***
value is correct. For single precision that requires 9 decimal
digits for single precision and 17 decimal digits for double
precision.

However, when working on old codes (usually f77 and older), you can
also see "random" digits for another reason. These old codes often
involved aliasing of variables, or reusing some memory location to
store the bits for variables of various types. This aliasing can be
done with EQUIVALENCE, within common blocks, or through actual/dummy
argument association, and with various compiler extensions, also
through pointer association or direct bit manipulation. So if you
have a double precision variable, that resides in a memory location
that at some other location in the program is used for another
purpose, then some or all of the bits in that variable might be
modified in some nonobvious way. In this case, the low-order bits
might have been changed in some way, and later when printed this
also results in "random" decimal digits.

I remember one example of this with a 60-bit CDC code. A sparse
array was being stored. Only the nonzero elements were stored, and
the lowest 6 bits were used to store, not the bits of the floating
point value, but rather a skip-count for the index of the next
stored value. In some cases, those low-order bits were masked out
before any floating point operations were done on those values or
before they were printed, but in other cases they were just left
there because the programmer "knew" that they would not make any
significant difference in the final result. That masking operation
was done by equivalencing the 60-bit word to a hollerith string, and
using some character operations on the 10th character in the string
(CDCs had a 6-bit character set). These 60-bit numbers were single
precision, so this is only tangentially related to the main subject
of this thread, but it is an example of "random" decimal digits that
I remember.

$.02 -Ron Shepard

[dpb]

On 7/22/2012 1:37 PM, Ron Shepard wrote:
> In article<juhbj3$pd$1...@online.de>,
> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
> reply) wrote:

...

>> By "input" and "output", I was referring to the arguments of a
>> subroutine.
>
> Alright, with this in mind, let's go back to the original post:
>
>> I have some code in DOUBLE PRECISION which, however, has real input and
>> output values. The input values are converted to internal variables via
>> DBLE and the results are converted to the output values via REAL.
>
> Ok, here you are talking about subroutine arguments. Presumably the
> actual and dummy arguments match and are both declared REAL.
>
>> Suppose an input value X is some number which has no exact
>> floating-point represenation, e.g. 2.63.
>
> This simply is not possible. Every real value of the actual
> subroutine arguments has a floating point representation. That real
> value is associated (by address, or by copying its value, or
> whatever) with the dummy argument of the subroutine. This then
> means that every value for that dummy argument has an exact floating
> point representation.

...

That's true at that level but that's not what Philip is referring to (my
crystal ball says).

He's talking about "2.63" as the decimal representation of a value as
being the exact value and comparing the result of having passed a
representation of that value in SP to a routine in which it has then
been converted to DP. In that routine he then sees the additional
"noise" that arises when the binary zero bits are added to those in SP
and that internal representation is converted back to decimal.

He's trying to find a way to have the DP representation also print
"2.63000000000000" instead of " 2.63000011444092" or somesuch...

Again, crystal ball talking here, but I'll venture it's right in this
instance. :)

--

[Phillip Helbig---undress to reply]

In article <juhfr6$3j9$1...@dont-email.me>, Gordon Sande

<Gordon...@gmail.com> writes:

> > By "input" and "output", I was referring to the arguments of a
> > subroutine.
>
> Where is the conversion on input or output being done? Otherwise
> you are just talking about the results of type mismatch on a
> subroutine call.

No, no type mismatch, neither intentional nor unintentional. The
routine is called with REAL values (read in from a keyboard, read in
from a file, generated from a program---doesn't matter) and these are
converted inside the routine.

[Phillip Helbig---undress to reply]

In article <juhh3v$uj9$1...@speranza.aioe.org>, dpb <no...@non.net> writes:

> On 7/22/2012 1:12 PM, Gordon Sande wrote:
> > On 2012-07-22 14:00:20 -0300, Phillip Helbig---undress to reply said:

> ....

>
> >> By "input" and "output", I was referring to the arguments of a
> >> subroutine.
> >
> > Where is the conversion on input or output being done? Otherwise
> > you are just talking about the results of type mismatch on a
> > subroutine call. If you play those sorts of games you deserve
> > any and all bad results!!!...
>
> Yeah, but I think he's talking of something like

Right.

> It's DP "all the way down" as far as the computations are concerned but
> the input and output parameters are passed as singles.

Right.

[Phillip Helbig---undress to reply]

In article <ron-shepard-356B...@news60.forteinc.com>, Ron

Shepard <ron-s...@NOSPAM.comcast.net> writes:

> > Suppose an input value X is some number which has no exact
> > floating-point represenation, e.g. 2.63.
>
> This simply is not possible. Every real value of the actual
> subroutine arguments has a floating point representation.

Yes.

> That real
> value is associated (by address, or by copying its value, or
> whatever) with the dummy argument of the subroutine.

Yes.

> This then
> means that every value for that dummy argument has an exact floating
> point representation.

OK, but the point is that 2.63 does not have an EXACT FP representation.

[Gordon Sande]

So we are playing twenty questions!

As I understand it you type "2.63". It is read into a REAL to get
"2.63000". It is passed to through a subroutine call to another real.
That real is assigned to a DOUBLE PRECISION to get "2.63000######".
If you had read it as a DOUBLE PRECISION you would have gotten
"2.63000000000" and could have passed it along but that is not the
program you have.

The things marked "######" above will not in general be zero because
"2.63" does not have the same approximation in REAL and DOUBLE PRECISION.
It may be that truncating the DOUBLE PRECISION will yield the REAL but it
is not the case that extending the REAL will get you the DOUBLE PRECISION
(except on days you should not be wasting your time programming but instead
be buying lottery tickets to benefit from your good luck).

You then do a computation entirely in DP on "2.63000######" and the final
result is assigned to a REAL variable. The question whther that result will
be different from the same calculation on "2.63000000000".

Of course it will! Not by much (or maybe so little you do not notice) if your
computation is of low condition or by a whole lot if it is of high condition.
You have to understand you calculation to know which.

The original Lorentz attractor of chaos theory was investigated because the
intermediate values were stored in SP for a DP calculation. With the large
sensitivity to initial conditions the small perturbation for the store a DP
as SP and restore it to SP and then to DP was enough to upset things. The
stopped and restarted runs gave different results than the uninterrupted runs.
Or at least that is how I recall the story. I am sure others with fill in and
correct the details.

[Gordon Sande]

To follow up on myself this is starting to sound like nothing to do
with Fortran
and everything to do with numerical analysis. At some point the citation of

"What Every Computer Scientist Should Know About Floating-Point Arithmetic"
by David Goldberg in the March 1991 Computing Surveys

should be given. Ask Google and you will get several sources. SUN, now Oracle,
was the usual source. Read it carefully. First quickly and then again slowly.

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:

(snip)

> Now, having said that, the conversion from a short precision to a
> longer precision is done by appending binary zero digits to the
> short precision number.

That is usual, though as far as I know not required by the standard.
(Note that the standard doesn't require binary, so wouldn't
require binary zeros.)

Appending zeros (in whatever base) is usual, though.

I believe that the IBM Stretch had a way to select whether binary
zeros or ones were used to fill such. (It did, at least, for post
normalization. This is a little different, but not so different.)

(snip)

> You almost never see that many decimal digits printed out. Why not?
> It is because in order to reproduce a given floating point number,
> only enough decimal digits are required so that the ***rounded***
> value is correct. For single precision that requires 9 decimal
> digits for single precision and 17 decimal digits for double
> precision.

Well, also because it is rare to need that many digits.

The need for DOUBLE PRECISION isn't that one needs that much
in the result, but that it is needed in intermediate values.
Especially in matrix computations, it is easy to lose precision
when two very close values are subtracted. (Also, when computing
numeric derivatives.)

Even so, it is usual to keep values in double precision through
much of the calculation. When the storage cost isn't so high
(scaler and small arrays), for example.

(snip)

> I remember one example of this with a 60-bit CDC code. A sparse
> array was being stored. Only the nonzero elements were stored, and
> the lowest 6 bits were used to store, not the bits of the floating
> point value, but rather a skip-count for the index of the next
> stored value. In some cases, those low-order bits were masked out
> before any floating point operations were done on those values or
> before they were printed, but in other cases they were just left
> there because the programmer "knew" that they would not make any
> significant difference in the final result.

You might look up "dithering," commonly used in digital
signal processing. Dithering adds random bits (or sometimes
analog noise) before truncating values. Used in digital audio
it can result in much less noise than without dithering.
(Strange, adding noise for less noise in the end.)

> That masking operation
> was done by equivalencing the 60-bit word to a hollerith string, and
> using some character operations on the 10th character in the string
> (CDCs had a 6-bit character set). These 60-bit numbers were single
> precision, so this is only tangentially related to the main subject
> of this thread, but it is an example of "random" decimal digits that
> I remember.

Many machines designed by Cray gave approximate answers to
many floating point operations. One favorite example was a
multiply that was not commutative. That is, X*Y-Y*X wasn't
zero, but 'close enough' for scientific computing.

-- glen

[glen herrmannsfeldt]

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

> I have some code in DOUBLE PRECISION which, however, has real input and
> output values. The input values are converted to internal variables via
> DBLE and the results are converted to the output values via REAL.

It is common to do calculations in double precision, though the
input data has much less precision. That makes up for likely
precision loss in intermediate calculations.

> Suppose an input value X is some number which has no exact
> floating-point represenation, e.g. 2.63. What should I expect the value
> DBLE(X) to be, tested by PRINT* during the code? Should I expect
> 2.63000000000000000 or 2.63<"random" digits>?

The default format used by list directed output likely prints
many more digits than for single precision, though usually few
enough to allow some rounding.

If you want less, print SNGL(Y) instead. (I presume this is for
debugging. Otherwise, use a format descriptor specifying a more
reasonable number of digits.)

(The default conversions in Java generate enough decimal digits
to recreate the internal binary value. In that case, even with a
double precision version of 2.63, you might see 2.63000000000001
or 2.62999999999999. Distressing to some users.)

The usual %g and %f conversions in C, (equivalent to list directed)
give a small enough number of digits that usually single precision
rounds as expected.

> I will read some responses first then post more information.

-- glen

[robin....@gmail.com]

On Monday, 23 July 2012 00:21:47 UTC+10, Phillip Helbig---undress to reply wrote:

> Suppose I have something like 2.63 as a character string. Is there a
> way to get this into a DOUBLE PRECISION variable with value
> 2.6300000000?

Use an internal READ.

[robin....@gmail.com]

On Monday, 23 July 2012 03:00:20 UTC+10, Phillip Helbig---undress to reply wrote:

> By "input" and "output", I was referring to the arguments of a
> subroutine.

Those terms refer to input from some external device,
and output to some external device (or their equivalent
via an internal read or write).

Arguments are passed to a subroutine ; dummy arguments are
the variables to receive those arguments from a calling routine.

[Nasser M. Abbasi]

On 7/22/2012 8:03 PM, robin....@gmail.com wrote:

>
> Arguments are passed to a subroutine ; dummy arguments are
> the variables to receive those arguments from a calling routine.
>

Isn't the more standard names for these things:

- formal parameter is the variable that receives the argument
on the callee end.

- actual parameter is the value of the variable send by the caller
which 'binds' to the formal parameter (how it binds depends on
the mechanism of the call, as in in/out/inout)

Fortran seems to call a 'formal parameter' as a 'dummy' argument
or 'dummy parameter'? which is not the standard way to refer to
these things. Must be a tradition in Fortran as it does not
seem to be a common term used in other languages.

--Nasser

[glen herrmannsfeldt]

Nasser M. Abbasi <n...@12000.org> wrote:

> On 7/22/2012 8:03 PM, robin....@gmail.com wrote:

>> Arguments are passed to a subroutine ; dummy arguments are
>> the variables to receive those arguments from a calling routine.

> Isn't the more standard names for these things:

> - formal parameter is the variable that receives the argument
> on the callee end.

> - actual parameter is the value of the variable send by the caller
> which 'binds' to the formal parameter (how it binds depends on
> the mechanism of the call, as in in/out/inout)

It is "dummy argument" and "actual argument" at least back
to Fortran 66. SUBROUTINE, FUNCTION, and CALL came in with
Fortran II, but I don't have a reference nearby to look.

> Fortran seems to call a 'formal parameter' as a 'dummy' argument
> or 'dummy parameter'? which is not the standard way to refer to
> these things. Must be a tradition in Fortran as it does not
> seem to be a common term used in other languages.

Argument and parameter are used in many languages.

The "dummy" idea isn't so obvious in the call by value case,
where there is an actual variable in the called routine.

With call by reference, there is only one variable, referenced
indirectly (however it is implemented) through the dummy.
With call by value result, there is an actual local
(copy) variable.

-- glen

[Ron Shepard]

In article <jui8or$hlh$1...@speranza.aioe.org>,

"Nasser M. Abbasi" <n...@12000.org> wrote:

> Fortran seems to call a 'formal parameter' as a 'dummy' argument
> or 'dummy parameter'? which is not the standard way to refer to
> these things. Must be a tradition in Fortran as it does not
> seem to be a common term used in other languages.

A "parameter" in fortran is the symbolic name of a constant, so it
would be confusing indeed to use the terminology "formal parameter"
or "dummy parameter".

$.02 -Ron Shepard

[Nasser M. Abbasi]

On 7/23/2012 1:41 AM, Ron Shepard wrote:

> A "parameter" in fortran is the symbolic name of a constant, so it
> would be confusing indeed to use the terminology "formal parameter"
> or "dummy parameter".

yes, I think that is a good reason why. Ofcourse the best solution
would have been to use 'constant' instead of 'parameter' to mean
constant, then they could have been able to use 'formal parameter'
to mean 'dummy argument', and everything would just fit right.

But I guess it is about 50 years too late now to fix this.

--Nasser

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:
> In article <jui8or$hlh$1...@speranza.aioe.org>,
> "Nasser M. Abbasi" <n...@12000.org> wrote:

>> Fortran seems to call a 'formal parameter' as a 'dummy' argument
>> or 'dummy parameter'? which is not the standard way to refer to
>> these things.

(snip)

> A "parameter" in fortran is the symbolic name of a constant, so it
> would be confusing indeed to use the terminology "formal parameter"
> or "dummy parameter".

Yes, but that didn't happen until later, as far as I know.

I do remember PARAMETER in the DEC Fortran IV compilers.

Do you know if it was in any compilers before Fortran 66?

-- glen

[Richard Maine]

Nasser M. Abbasi <n...@12000.org> wrote:

> On 7/22/2012 8:03 PM, robin....@gmail.com wrote:
> >
> > Arguments are passed to a subroutine ; dummy arguments are
> > the variables to receive those arguments from a calling routine.
> >
> Isn't the more standard names for these things:
>
> - formal parameter is the variable that receives the argument
> on the callee end.
>
> - actual parameter is the value of the variable send by the caller
> which 'binds' to the formal parameter (how it binds depends on
> the mechanism of the call, as in in/out/inout)

I'd say "no", those aren't the more "standard" names. They are the C
names, but I don't think of "standard" as a synonym for "C".

Not that I particularly like what "parameter" means in Fortran. The
English meaning of that term is way to vague to evoke what the term mean
sin Fortran. Heck, the Fortran standard itself doesn't even use the term
"parameter" to describe the things declared with the PARAMETER
attribute. The attribute is spelled "parameter", but the things declared
with those attributes are called "named constants" in the standard. I
find this a bit strange, but I'm afraid it is prety spilt milk by now.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Richard Maine]

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

> Ron Shepard <ron-s...@nospam.comcast.net> wrote:
>
> (snip)
> > Now, having said that, the conversion from a short precision to a
> > longer precision is done by appending binary zero digits to the
> > short precision number.
>
> That is usual, though as far as I know not required by the standard.
> (Note that the standard doesn't require binary, so wouldn't
> require binary zeros.)
>
> Appending zeros (in whatever base) is usual, though.

I was going to make the same comment, but I see Glen beat me to it. So
I'll just add the confirmation that, no, the standard does not require
that the conversion be done by appending binary zeros. As I think Glen
noted, the standard doesn't require that internal representations even
be in binary; although all (I think) current implementations do use
binary internal representation, it is quite plausible that you might see
ones with decimal for at least some kinds.

Note that the standard also does not require that a single precision
value even have an exact conversion to double precsion, base questions
aside.

I'd also second the advice maide elsewhere in reply to the question
about whether there was ever a good reason to use DBLE. I'd say "no",
that one should use an appropriate invocation of the REAL intrinsic
instead in new code. There are certainly cases where that is reasonably
appropriate, though I would not try to enumerate them, and some are
debatable points of style. Others are more concrete.

[Paul van Delst]

On 07/22/12 09:51, Phillip Helbig---undress to reply wrote:
> I have some code in DOUBLE PRECISION which, however, has real input and
> output values. The input values are converted to internal variables via
> DBLE and the results are converted to the output values via REAL.
>

> Suppose an input value X is some number which has no exact
> floating-point represenation, e.g. 2.63. What should I expect the value
> DBLE(X) to be, tested by PRINT* during the code? Should I expect
> 2.63000000000000000 or 2.63<"random" digits>?

I would expect something more like
2.6300000<"random" digits>
or maybe
2.6299999<"random" digits>
etc.

E.g in IDL (quicker than writing+compiling a Fortran program :o)

IDL> x=2.63
IDL> help, x
X FLOAT = 2.63000

IDL> y = double(x)
IDL> help, y
Y DOUBLE = 2.6300001

IDL> print, y, format='(f18.15)'
2.630000114440918
IDL> print, y+2.0d-09, format='(f18.15)'
2.630000116440918

IDL> print, x, format='(f18.15)'
2.630000114440918
IDL> print, x+2.0e-09, format='(f18.15)'
2.630000114440918


Ah, what the hell, the fortran version:

program testfp
integer, parameter :: dp = selected_real_kind(15)
real :: x
real(dp) :: y

x = 2.63
y = dble(x)
write(*,'(/,"y = ",f18.15)') y
write(*,'("y+2.0e-09_dp = ",f18.15)') y+2.0e-09_dp

write(*,'(/,"x = ",f18.15)') x
write(*,'("x+2.0e-09 = ",f18.15)') x+2.0e-09
end program testfp

$ gfortran testfp.f90
$ a.out

y = 2.630000114440918
y+2.0e-09_dp = 2.630000116440918

x = 2.630000114440918
x+2.0e-09 = 2.630000114440918


Huh. Even got the same "random" digits.

cheers,

paulv

[Ron Shepard]

In article <juj2aj$3u5$1...@speranza.aioe.org>,

Yes, this is correct; perhaps I should have elaborated a little
more. Fortran was originally a high-level language to compute
mathematical expressions (FORmula TRANslation), and in mathematics
in an expression like f(x), f() is the function and "x" is the
argument. When you learned algebra and trig in school, that is
almost certainly the terminology you used. In a mathematical
definition such as

f(x) = a x^2 + b x + c

the quantity "x" is usually called the variable and the quantities
"a", "b", and "c" are the parameters that define the function. It
is clear how this terminology has been incorporated into fortran.
In other fields in science, the above might be written

f(x;a,b,c)

where the "x" variable is on the left of the semicolon and the
parameters are on the right.

$.02 -Ron Shepard

[Ron Shepard]

In article <1knojyv.19upadm2pk634N%nos...@see.signature>,

nos...@see.signature (Richard Maine) wrote:

> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > Ron Shepard <ron-s...@nospam.comcast.net> wrote:
> >
> > (snip)
> > > Now, having said that, the conversion from a short precision to a
> > > longer precision is done by appending binary zero digits to the
> > > short precision number.
> >
> > That is usual, though as far as I know not required by the standard.
> > (Note that the standard doesn't require binary, so wouldn't
> > require binary zeros.)
> >
> > Appending zeros (in whatever base) is usual, though.
>
> I was going to make the same comment, but I see Glen beat me to it. So
> I'll just add the confirmation that, no, the standard does not require
> that the conversion be done by appending binary zeros. As I think Glen
> noted, the standard doesn't require that internal representations even
> be in binary; although all (I think) current implementations do use
> binary internal representation, it is quite plausible that you might see
> ones with decimal for at least some kinds.
>
> Note that the standard also does not require that a single precision
> value even have an exact conversion to double precsion, base questions
> aside.

Yes, I agree with these comments. I should have stated more clearly
in my post what was and wasn't required by the standard. I was
describing how floating point works in practice in fortran,
particularly the modern floating point formats such as IEEE (32-bit
single precision and 64-bit double precision).

> I'd also second the advice maide elsewhere in reply to the question
> about whether there was ever a good reason to use DBLE. I'd say "no",
> that one should use an appropriate invocation of the REAL intrinsic
> instead in new code. There are certainly cases where that is reasonably
> appropriate, though I would not try to enumerate them, and some are
> debatable points of style. Others are more concrete.

$.02 -Ron Shepard

[Phillip Helbig---undress to reply]

In article <ron-shepard-C49D...@news60.forteinc.com>, Ron

Shepard <ron-s...@NOSPAM.comcast.net> writes:

> Yes, this is correct; perhaps I should have elaborated a little
> more. Fortran was originally a high-level language to compute
> mathematical expressions (FORmula TRANslation), and in mathematics
> in an expression like f(x), f() is the function and "x" is the
> argument.

Reminds me of "If Klingons wrote software" which I found somewhere on
the intertubes. "Our software isn't released; it escapes!" and other
such statements. One was: "Our routines do not have parameters, they
have arguments---and they always win them!"

[David W Noon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 23 Jul 2012 11:46:20 -0500, Ron Shepard wrote about Re: X =
DBLE(Y):

[snip]

>almost certainly the terminology you used. In a mathematical
>definition such as
>
> f(x) = a x^2 + b x + c
>
>the quantity "x" is usually called the variable and the quantities
>"a", "b", and "c" are the parameters that define the function.

No they're not. They are the *coefficients* of the formula.

If anything, the argument x is the parameter.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply by e-mail.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlANns0ACgkQ9MqaUJQw2MlAnQCgkLYXj9dEjnPfJYEHy8+3LDVy
t5kAninltSNKLgYiDSQUnpbeMQ1oIfJp
=cA9L
-----END PGP SIGNATURE-----

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:

(snip)

> Yes, I agree with these comments. I should have stated more clearly
> in my post what was and wasn't required by the standard. I was
> describing how floating point works in practice in fortran,
> particularly the modern floating point formats such as IEEE (32-bit
> single precision and 64-bit double precision).

To finish my previous comment, the Stretch feature was designed
such that one could run a program both ways. That is, once with
zeros for post normalization, and once with ones. (I don't know
if DBLE counts as post normalization or not.)

Then you compare the difference in the results. Large differences
show that a program probably lost too much precision along the way,
and one should be careful in using the results.

Now, there is one problem with this. If two quantities with
such lost precision are subtracted, the zeros and ones might
cancel, such that you don't see a large difference. A possible
fix is to randomly supply zeros and ones, and run the program
a sufficient number of times to get the probability of such
cancelation low enough. That also saves the need for a switch.

I don't know how much it was ever used on Stretch, and haven't
heard about any interest since.

There was discussion not so many years ago about interval
arithmetic, explicitely keeping track of the precision that
values still have.

-- glen

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:

(snip, someone wrote)

>> > A "parameter" in fortran is the symbolic name of a constant, so it
>> > would be confusing indeed to use the terminology "formal parameter"
>> > or "dummy parameter".

(then I wrote)

>> Yes, but that didn't happen until later, as far as I know.

>> I do remember PARAMETER in the DEC Fortran IV compilers.

>> Do you know if it was in any compilers before Fortran 66?

> Yes, this is correct; perhaps I should have elaborated a little
> more. Fortran was originally a high-level language to compute
> mathematical expressions (FORmula TRANslation), and in mathematics
> in an expression like f(x), f() is the function and "x" is the
> argument. When you learned algebra and trig in school, that is
> almost certainly the terminology you used. In a mathematical
> definition such as

> f(x) = a x^2 + b x + c

> the quantity "x" is usually called the variable and the quantities
> "a", "b", and "c" are the parameters that define the function.

Yes, and, for example, "a", "b", and "c" are inputs to a quadratic
equation solver. That is, the parameters of the solution to
a quadratic.

But also called coefficients in the desciption of polynomials.

> It is clear how this terminology has been incorporated into fortran.

> In other fields in science, the above might be written

> f(x;a,b,c)

> where the "x" variable is on the left of the semicolon and the
> parameters are on the right.

-- glen

[glen herrmannsfeldt]

David W Noon <dwn...@spamtrap.ntlworld.com> wrote:
[snip]
>>almost certainly the terminology you used. In a mathematical
>>definition such as

>> f(x) = a x^2 + b x + c

>>the quantity "x" is usually called the variable and the quantities
>>"a", "b", and "c" are the parameters that define the function.

> No they're not. They are the *coefficients* of the formula.^M

Yes, they are coefficients of the polynomial, but parameters
in the solution to the quadratic equation.

> If anything, the argument x is the parameter.

In a polynomial, as usually used, x is the variable and the "a" ...
are the coefficients. Now, I want the solution to the quadratic
using the quadratic formula. In the quadratic formula, it
is "a", "b" and "c" that are the inputs, but we don't want to
call them "variables", as "x" is already the variable that we
are solving for.

What is variable and what is constant depends on the question
being asked. If you graph a polynomial, y= a x^2 + b x + c,
Then x and y are the (independent and dependent) variables,
and "a", "b", and "c" are parameters to the graph,
(but coefficents to the polynomial).

Still, I blame DEC for the Fortran PARAMETER statement.

-- glen

[David W Noon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 23 Jul 2012 21:01:35 +0000 (UTC), glen herrmannsfeldt wrote

about Re: X = DBLE(Y):

>David W Noon <dwn...@spamtrap.ntlworld.com> wrote:
>[snip]
>>>almost certainly the terminology you used. In a mathematical
>>>definition such as
>
>>> f(x) = a x^2 + b x + c
>
>>>the quantity "x" is usually called the variable and the quantities
>>>"a", "b", and "c" are the parameters that define the function.
>
>> No they're not. They are the *coefficients* of the formula.^M
>
>Yes, they are coefficients of the polynomial, but parameters
>in the solution to the quadratic equation.
>
>> If anything, the argument x is the parameter.
>
>In a polynomial, as usually used, x is the variable and the "a" ...
>are the coefficients. Now, I want the solution to the quadratic
>using the quadratic formula. In the quadratic formula, it
>is "a", "b" and "c" that are the inputs, but we don't want to
>call them "variables", as "x" is already the variable that we
>are solving for.

As written, the formula is for evaluating the polynomial for any given
x, not solving for f(x) = 0. Hence, a, b and c are coefficients of the
polynomial when it is written that way.

>What is variable and what is constant depends on the question
>being asked. If you graph a polynomial, y= a x^2 + b x + c,
>Then x and y are the (independent and dependent) variables,
>and "a", "b", and "c" are parameters to the graph,
>(but coefficents to the polynomial).

Well, if you're graphing the polynomial then a, b and c need to be
fixed coefficients, otherwise you'll have a very smudged graph.

>Still, I blame DEC for the Fortran PARAMETER statement.

Agreed. I could never fathom how that made it to F77.

- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply by e-mail.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlANxjUACgkQ9MqaUJQw2MlMOgCgieP73D5O4OLRZzzaUzSNdIok
fmcAn2FKENCQ20Xy7bKntVM/5+nPmRYe
=vXdu
-----END PGP SIGNATURE-----

[Ron Shepard]

In article <20120723224...@dwnoon.ntlworld.com>,

David W Noon <dwn...@spamtrap.ntlworld.com> wrote:

> >>>almost certainly the terminology you used. In a mathematical
> >>>definition such as
> >
> >>> f(x) = a x^2 + b x + c
> >
> >>>the quantity "x" is usually called the variable and the quantities
> >>>"a", "b", and "c" are the parameters that define the function.
> >
> >> No they're not.

Yes, they are, and I've explained why. You have not explained your
point of view.

f(x) is a quadratic equation. Depending on the values of the
parameters (a,b,c), it could be a constant, a linear equation, or a
parabola.

> They are the *coefficients* of the formula.^M

In this particular case, yes, the parameters are the coefficients in
the polynomial expression. However, in other functions

f(t) = cos(a*t)

f(T) = exp(-E/(k*T))

then "a", "E", and "k" are parameters that are not coefficients of
the polynomial, but they play the same parametric role in the
functions.

> >Yes, they are coefficients of the polynomial, but parameters
> >in the solution to the quadratic equation.
> >
> >> If anything, the argument x is the parameter.

No, the argument "x" is the argument, just as you said in that very
sentence. :-)

Look at the meaning of the Greek words "para" and "metron" from
which the word "parameter" is derived.

$.02 -Ron Shepard

[John Harper]

PARAMETER statements are not in the f66 standard; they were then presumably
a DEC extension.

Algol 60 had formal and actual parameters of procedures, and Wikipedia says
its first compiler was in 1960. The following year, McCracken's "A guide to
FORTRAN programming" (Wiley, 1961) referred to arguments of functions and
subroutines. Dummies were mentioned, but I failed to find the word "actual"
used of arguments. Parameters in the modern Fortran sense are not mentioned
in that book. It gives details of one interpreter (IBM 1620 GOTRAN) and
various compilers: IBM 1620 FORTRAN, IBM 650 FORTRAN and FOR TRANSIT, IBM
705, 7070 and 704/709/7090 FORTRAN (3 different dialects), Honeywell
Algebraic Compiler, Philco 2000 Altac, and Control Data 1604 FORTRAN.

--
John Harper

[robin....@gmail.com]

On Monday, 23 July 2012 11:18:18 UTC+10, Nasser M. Abbasi wrote:

> On 7/22/2012 8:03 PM, rrrrrrr...@gmail.com wrote:
>
>
> > Arguments are passed to a subroutine ; dummy arguments are
> > the variables to receive those arguments from a calling routine.
>
> Isn't the more standard names for these things:
>
> - formal parameter is the variable that receives the argument
> on the callee end.
>
> - actual parameter is the value of the variable send by the caller

> which &#39;binds&#39; to the formal parameter (how it binds depends on

> the mechanism of the call, as in in/out/inout)
>
> Fortran seems to call a "formal parameter" as a "dummy" argument
> or "dummy parameter"?

Fortran uses "dummy argument".

> which is not the standard way to refer to
> these things. Must be a tradition in Fortran as it does not
> seem to be a common term used in other languages.

The terms vary.
PL/I uses "argument" (the more usual term) in the calling program,
and "parameter" for the corresponding name in the subroutine.

[William Clodius]

DEC's initial implementaton of PARAMETER was explained by them as an
implementation of a proposal for what became the Fortran 77 standard,
i.e., well after the first Fortran standard. The fixed form lexical
problems for their initial implementation, quickly became obvious, which
is why the F77 version is different form their version.

[Robin Vowels]

On Jul 23, 11:35 am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> Nasser M. Abbasi <n...@12000.org> wrote:
>

> > On 7/22/2012 8:03 PM, robin.vow...@gmail.com wrote:
> >> Arguments are passed to a subroutine ; dummy arguments are
> >> the variables to receive those arguments from a calling routine.
> > Isn't the more standard names for these things:
> > - formal parameter is the variable that receives the argument
> > on the callee end.
> > - actual parameter is the value of the variable send by the caller
> > which 'binds' to the formal parameter (how it binds depends on
> > the mechanism of the call, as in in/out/inout)
>
> It is "dummy argument" and "actual argument"

Strictly speaking, yes, this is correct. I think that in common
parlance, "actual argument" gets abbreviated to "argument".

D. D. McCracken uses only "argument" in his book
"A Guide to Fortran IV programming", 2/e of 1972.

[Robin Vowels]

On Jul 23, 12:31 am, dpb <n...@non.net> wrote:
> On 7/22/2012 9:21 AM, Phillip Helbig---undress to reply wrote:> In article<juh1p3$pf...@speranza.aioe.org>, dpb<n...@non.net>  writes:
>
> ...
>
> >> Functions that cause conversion of one data type to another type
> >> have the same effect as the implied conversion in assignment
> >> statements.
>
> > Right.  Considering this, is there any reason to use them, except to
> > force the conversion to be done just once rather than many times if they
> > are used in more than one expression which needs conversion?  (Now, I'm
> > discussing only the values, not the difference between DBLE(X)/DBLE(Y)
> > and DBLE(X/Y).)
>
> I see no advantage, no.  One may as well write
>
> Y=X  ! where Y is the DP; X the SP variable
>
> as
>
> Y=DBLE(X)
>
> and just use Y from then on.

Indeed. There are few reasons for using DBLE : one would be
to transform an argument to double precision when passing it
to a procedure. Another could be to transform a REAL variable
to double precision, again in an expression. Usually, however,
some operand in an expression is already double precision,
in which case, DBLE may not be needed.

[Robin Vowels]

On Jul 24, 1:27 pm, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
wrote:
> In article <20120723224624.2e20d...@dwnoon.ntlworld.com>,

>  David W Noon <dwn...@spamtrap.ntlworld.com> wrote:
>
> > >>>almost certainly the terminology you used. In a mathematical
> > >>>definition such as
>
> > >>>   f(x) = a x^2 + b x + c
>
> > >>>the quantity "x" is usually called the variable and the quantities
> > >>>"a", "b", and "c" are the parameters that define the function.
>
> > >> No they're not.
>
> Yes, they are, and I've explained why.  You have not explained your
> point of view.
>
> f(x) is a quadratic equation.

No it isn't. f(x) = 0 is an equation;
a*x**2 + b*x + c = 0 is a quadratic equation.

But "f(x)" is just f(x).

[Steve Lionel]

On 7/24/2012 10:01 PM, William Clodius wrote:
> DEC's initial implementaton of PARAMETER was explained by them as an
> implementation of a proposal for what became the Fortran 77 standard,
> i.e., well after the first Fortran standard. The fixed form lexical
> problems for their initial implementation, quickly became obvious, which
> is why the F77 version is different form their version.

Just to clarify - the initial implementation by DEC of PARAMETER without
the parentheses (and without typing) was taken directly from a late
draft of what eventually became FORTRAN 77. As William notes, the form
changed in the approved standard, so DEC had to support both forms (as
did compilers derived from it, including today's Intel Fortran.)

It was not "their (DEC's) version". And, lastly, this is a cautionary
tale about implementing language features from a draft standard.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[glen herrmannsfeldt]

Steve Lionel <steve....@intel.invalid> wrote:
> On 7/24/2012 10:01 PM, William Clodius wrote:
>> DEC's initial implementaton of PARAMETER was explained by them as an
>> implementation of a proposal for what became the Fortran 77 standard,
>> i.e., well after the first Fortran standard. The fixed form lexical
>> problems for their initial implementation, quickly became obvious, which
>> is why the F77 version is different form their version.

> Just to clarify - the initial implementation by DEC of PARAMETER without
> the parentheses (and without typing) was taken directly from a late
> draft of what eventually became FORTRAN 77. As William notes, the form
> changed in the approved standard, so DEC had to support both forms (as
> did compilers derived from it, including today's Intel Fortran.)

I started using the IBM OS/360 compilers in 1972, and the DEC
compilers (TOPS-10) in 1976. I had remembered PARAMETER from the
DEC compilers, and no others. This was before I knew much about
an actual standard, and when they were still usually called
Fortran IV. (And, more specifically, didn't know at all about
draft standards.)

I used WATFIV from 1973, which also had many Fortran 77 features,
presumably from draft standards. I remember CHARACTER variables
and expressions in I/O lists, for two. I don't remember PARAMETER
from WATFIV, but then I might not have looked for it.

> It was not "their (DEC's) version". And, lastly, this is a cautionary
> tale about implementing language features from a draft standard.

I never heard this until now. I had always thought that DEC did
PARAMETER first, and that the standard committe adopted it, with
changes, from the DEC version.

On the other hand, I have thought, starting after I knew about
Fortran 77, that WATFIV adopted CHARACTER (even though I didn't
know about draft standards) from the future Fortran 77.
Well, I might have thought it was added to WATFIV and to the
standard by the same person, and so no cause and effect
between the standard and the compiler.

-- glen

[Richard Maine]

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

> Steve Lionel <steve....@intel.invalid> wrote:

> > Just to clarify - the initial implementation by DEC of PARAMETER without
> > the parentheses (and without typing) was taken directly from a late
> > draft of what eventually became FORTRAN 77. As William notes, the form
> > changed in the approved standard, so DEC had to support both forms (as
> > did compilers derived from it, including today's Intel Fortran.)

...

> > It was not "their (DEC's) version". And, lastly, this is a cautionary
> > tale about implementing language features from a draft standard.
>
> I never heard this until now. I had always thought that DEC did
> PARAMETER first, and that the standard committe adopted it, with
> changes, from the DEC version.

Odd. I've heard it many times, including quite a few in this forum. In
fact, it tends to come up a fair fraction of the times that the "DEC
form" is mentioned.

That form seems to be the source of a lot of misinformation. For
example, some users obviously did not understand the way it interacted
with type declaration, thinking that it was just a different syntax for
the exact same functionality as the standard form. I've run into that
misconception regularly. In particular, I recall having a user complain
that some other vendor's compiler was not VAX compatible because his
code, which he claimed would compile on a VAX, would not compile on the
compiler of some other vendor that claimed VAX Fortran compatibility. I
"bounced" the user's bug report, refusing to forward it to the vendor
because it was a user misunderstanding instead of a compiler bug. The
user in question wouldn't believe my explanation that it wouldn't run on
a VAX either until I took the code to a VAX and demonstrated it.

That episode was quite simillar to things that happen here regularly
with people trying to explain their code instead of showing it. The user
thought the two forms were just different syntax for the same thing, so
it never occurred to him that what he probably recalled as working on a
VAX wasn't actually the same thing as he was then trying.

[glen herrmannsfeldt]

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

>> Steve Lionel <steve....@intel.invalid> wrote:

>> > Just to clarify - the initial implementation by DEC of PARAMETER without
>> > the parentheses (and without typing) was taken directly from a late
>> > draft of what eventually became FORTRAN 77. As William notes, the form
>> > changed in the approved standard, so DEC had to support both forms (as
>> > did compilers derived from it, including today's Intel Fortran.)

>> > It was not "their (DEC's) version". And, lastly, this is a cautionary
>> > tale about implementing language features from a draft standard.

(snip, then I wrote)

>> I never heard this until now. I had always thought that DEC did
>> PARAMETER first, and that the standard committe adopted it, with
>> changes, from the DEC version.

> Odd. I've heard it many times, including quite a few in this forum. In
> fact, it tends to come up a fair fraction of the times that the "DEC
> form" is mentioned.

I suppose to really answer this, one should track down who added
it to the draft standard, and who added it to DEC compilers.

As well as I remember it, PARAMETER and INCLUDE (DEC form) were
used with COMMON to make it easier to get consistent declarations
in different routines. PARAMETER allowed one to dimension
multiple arrays with one value, simplifying editing.

(I used to know of arrays dimensioned with numbers like 30001
to reduce the problems of doing a global replace.)

I have suspected, but really don't know, that CHARACTER was added
to WATFIV and Fortran 77 by the same person (group), but maybe not.

> That form seems to be the source of a lot of misinformation. For
> example, some users obviously did not understand the way it interacted
> with type declaration, thinking that it was just a different syntax for
> the exact same functionality as the standard form.

-- glen

[Tim Prince]

On 7/25/2012 9:27 AM, Steve Lionel wrote:
> On 7/24/2012 10:01 PM, William Clodius wrote:
>> DEC's initial implementaton of PARAMETER was explained by them as an
>> implementation of a proposal for what became the Fortran 77 standard,
>> i.e., well after the first Fortran standard. The fixed form lexical
>> problems for their initial implementation, quickly became obvious, which
>> is why the F77 version is different form their version.
>
> Just to clarify - the initial implementation by DEC of PARAMETER without
> the parentheses (and without typing) was taken directly from a late
> draft of what eventually became FORTRAN 77. As William notes, the form
> changed in the approved standard, so DEC had to support both forms (as
> did compilers derived from it, including today's Intel Fortran.)
>
> It was not "their (DEC's) version". And, lastly, this is a cautionary
> tale about implementing language features from a draft standard.
>

Several pre-f77 compilers we used had variations on the PARAMETER
without parentheses, where the data typing (if any) was taken from the
expression on the right hand side. Maybe the draft standard to which
Steve refers was the impetus for a clumsy change Sun made in their
version about that time. Maybe someone was demonstrating a deficiency
in the draft. After that thrash there wasn't as much resistance to the
workable f77 version as there has been to most standard changes.

--
Tim Prince

[Terence]

Robin said (about the use of 'parameter'):-

>The terms vary.
>PL/I uses "argument" (the more usual term) in the calling program,
>and "parameter" for the corresponding name in the subroutine.

The same definition of 'parameter' as a name for arguments is use in my
Burroughs Fortran Compiler programming reference manual, referring to the
ANSI X3.9 -1978 standard.
And no, I don't remember PARAMETER as being in the MS or HP F77 manuals. at
least at the evel to which all of them conformed. I used PL/1 a lot about
that time.

[Richard Maine]

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

> Richard Maine <nos...@see.signature> wrote:
>
> >> Steve Lionel <steve....@intel.invalid> wrote:
>
> >> > Just to clarify - the initial implementation by DEC of PARAMETER without
> >> > the parentheses (and without typing) was taken directly from a late
> >> > draft of what eventually became FORTRAN 77. As William notes, the form
> >> > changed in the approved standard, so DEC had to support both forms (as
> >> > did compilers derived from it, including today's Intel Fortran.)
>
> >> > It was not "their (DEC's) version". And, lastly, this is a cautionary
> >> > tale about implementing language features from a draft standard.
>
> (snip, then I wrote)
> >> I never heard this until now. I had always thought that DEC did
> >> PARAMETER first, and that the standard committe adopted it, with
> >> changes, from the DEC version.
>
> > Odd. I've heard it many times, including quite a few in this forum. In
> > fact, it tends to come up a fair fraction of the times that the "DEC
> > form" is mentioned.
>
> I suppose to really answer this, one should track down who added
> it to the draft standard, and who added it to DEC compilers.

Well, Steve has worked on the DEC compilers pretty much forever, though
I don't know whether he specifically worked on that particular feature.
He has explicitly said (many times) that DEC got it from a draft of the
standard. Seems to me that he is about as good a source as you will
find. If you choose to just not believe him, I don't know why, but I
guess not much I can do about that. I believe him. I've heard the same
tale from the person who was the committee representative from DEC (and
several subsequent inheritors).

[glen herrmannsfeldt]

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

(snip regarding PARAMETER)

>> I suppose to really answer this, one should track down who added
>> it to the draft standard, and who added it to DEC compilers.

> Well, Steve has worked on the DEC compilers pretty much forever, though
> I don't know whether he specifically worked on that particular feature.
> He has explicitly said (many times) that DEC got it from a draft of the
> standard. Seems to me that he is about as good a source as you will
> find. If you choose to just not believe him, I don't know why, but I
> guess not much I can do about that. I believe him. I've heard the same
> tale from the person who was the committee representative from DEC (and
> several subsequent inheritors).

It isn't that I don't believe him, but still wonder about the
exact path of the idea from the person who originated it,
though to the standard and then to DEC.

Yes, it doesn't matter much, but I still might wonder.

-- glen

[Thomas Koenig]

On 2012-07-23, Richard Maine <nos...@see.signature> wrote:
> The
> English meaning of that term is way to vague to evoke what the term mean
> sin Fortran.

Arithmetic or geometric mean sin?

:-)

[\"Vladimír Fuka <"name.surnameat]

Interestingly, the Crays's new HPC language Chapel returns to Fortran's
parameter and uses both param and const. First for compile time constants,
the other for constants evaluated at the start of the program.

Dne Mon, 23 Jul 2012 11:11:24 +0200 Richard Maine <nos...@see.signature>
napsal(a):

> Nasser M. Abbasi <n...@12000.org> wrote:
>

>> On 7/22/2012 8:03 PM, robin....@gmail.com wrote:
>> >
>> > Arguments are passed to a subroutine ; dummy arguments are
>> > the variables to receive those arguments from a calling routine.
>> >
>> Isn't the more standard names for these things:
>>
>> - formal parameter is the variable that receives the argument
>> on the callee end.
>>
>> - actual parameter is the value of the variable send by the caller
>> which 'binds' to the formal parameter (how it binds depends on
>> the mechanism of the call, as in in/out/inout)
>

> I'd say "no", those aren't the more "standard" names. They are the C
> names, but I don't think of "standard" as a synonym for "C".
>
> Not that I particularly like what "parameter" means in Fortran. The

> English meaning of that term is way to vague to evoke what the term mean

> sin Fortran. Heck, the Fortran standard itself doesn't even use the term
> "parameter" to describe the things declared with the PARAMETER
> attribute. The attribute is spelled "parameter", but the things declared
> with those attributes are called "named constants" in the standard. I
> find this a bit strange, but I'm afraid it is prety spilt milk by now.
>


--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/