Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)
| Author |
Message |
|
beliav..
#1 / 14
|
 Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Roy Smith wrote (in comp.lang.python):
Quote: >Believe it or not, in some early versions of fortran, numbers were not >immutable! I forget the exact scenario, but if you did something like: > subroutine munge (i) > i = 3 > return >and then in your main program did: > j = 7 > call munge (7) > write (6, 11) j > 11 format ('j = ', i6) >it would print 3! The problem is that numerical constants were interned >(i.e. in the main program, there was only a single 7 stored in memory, >and both uses of 7 referred to the same memory location), and the value >passed to the subroutine was call by reference. It was almost as if the >compiler let you say "7 = 3" as an assignment statement. >Needless to say, people did indeed complain massively.
Fortran, or a particular Fortran compilers?
|
| Fri, 06 Jul 2007 10:14:44 GMT |
|
 |
|
James Gile
#2 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Quote:
> Roy Smith wrote (in comp.lang.python): >> Believe it or not, in some early versions of Fortran, numbers were not
>> immutable! I forget the exact scenario, but if you did something like:
>> subroutine munge (i)
>> i = 3
>> return
>> and then in your main program did:
>> j = 7
>> call munge (7)
>> write (6, 11) j
>> 11 format ('j = ', i6)
>> it would print 3! The problem is that numerical constants were interned
>> (i.e. in the main program, there was only a single 7 stored in memory,
...
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?
This was always illegal. In the FORTRAN 66 standard document
it says (8.3.2):
If an actual argument corresponds to a dummy argument that is
defined or redefined in the referenced subprogram, the actual
argument must be a variable name, an array element name, or
an array name. [...]
All Fortran standards have required that actual arguments be
definable if they are associated with dummy arguments that
change during the execution of the procedure. It is not, however,
a violation that's required to be detected or reported by compliant
implementations. So, programs that violate the requirement are
subject to arbitrary treatment by the implementation - including
starting WWIII, but more often , the above mentioned strange
behavior.
I've long advocated that if the actual argument is a not definable,
an anonymous copy should be created that is associated with
the dummy argument. The procedure could then change it as
desired. The anonymous copy is then ignored upon return.
This is the behavior required for dummy arguments that have
the VALUE attribute in the F2003 standard. But the rule I just
stated would give the control to the caller of the procedure.
--
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
|
| Fri, 06 Jul 2007 11:01:04 GMT |
|
|
|
Another Jak
#3 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) When I was debugging programs about 1970 (IBM360), this was one of the
first things to look for. And, then insist that the student change the
argument from a number to a variable. This was a very popular error
back then. I am guessing it was Fortran IV.
-- AJ, FD
Quote: > Roy Smith wrote (in comp.lang.python): > >Believe it or not, in some early versions of Fortran, numbers were
not
> >immutable! I forget the exact scenario, but if you did something
like:
> > subroutine munge (i)
> > i = 3
> > return
> >and then in your main program did:
> > j = 7
> > call munge (7)
> > write (6, 11) j
> > 11 format ('j = ', i6)
> >it would print 3! The problem is that numerical constants were
> interned
> >(i.e. in the main program, there was only a single 7 stored in
memory,
> >and both uses of 7 referred to the same memory location), and the
> value
> >passed to the subroutine was call by reference. It was almost as if
> the
> >compiler let you say "7 = 3" as an assignment statement.
> >Needless to say, people did indeed complain massively.
> Was this (the ability to redefine the value of '7') ever really true
of
> Fortran, or a particular Fortran compilers?
|
| Fri, 06 Jul 2007 11:33:01 GMT |
|
|
|
#4 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Richard Main
#5 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Quote:
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?
It was never true of Fortran the language. It was common behavior for
many Fortran compilers in the presense of a oparticular style of
nonstandard code.
In those days, people often didn't distinguish between the language
and a particular compiler. Many people didn't even know that there
was such a thing as a standard; they just considered the language
to be defined by whatever compiler they were using at the time.
(Of course, some still work in that mode, but in those days it was
almost everyone).
In training new Fortran programers, I used to "lead" them into making
the error of changing a constant so that I could point it out. I
figured it was better for them to encounter the strange symptoms while
"under supervision" as it were.
In a way, it was almost a disappointment when this error started
generating error messages about things like trying to modify
read-only memory or something of the sort. That made the debugging
so much simpler that my help was scarcely needed. :-)
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
|
| Fri, 06 Jul 2007 14:47:48 GMT |
|
|
|
glen herrmannsfeld
#6 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Quote:
>>Was this (the ability to redefine the value of '7') ever really true of
>>Fortran, or a particular Fortran compilers?
> It was never true of Fortran the language. It was common behavior for
> many Fortran compilers in the presense of a oparticular style of
> nonstandard code.
There was, however, a legal way to modify constants. Read into
a hollerith FORMAT specifier. That always seemed strange to me,
partly because it was modifying constants, and partly because
there is no way to add a carriage control character.
READ(5,1)
1 FORMAT(10H1234567890)
WRITE(6,1)
Quote: > In those days, people often didn't distinguish between the language
> and a particular compiler. Many people didn't even know that there
> was such a thing as a standard; they just considered the language
> to be defined by whatever compiler they were using at the time.
> (Of course, some still work in that mode, but in those days it was
> almost everyone).
Well, there wasn't a standard until 1966. Before that, the
language was, more or less, what each compiler defined it as.
Well, as I understand it there was Fortran, and then Fortran II,
and I believe IBM had more than one implementation of Fortran II.
Fortran IV was, more or less depending on the vendor, Fortran 66.
I don't know where Fortran III went.
Quote: > In training new Fortran programers, I used to "lead" them into making
> the error of changing a constant so that I could point it out. I
> figured it was better for them to encounter the strange symptoms while
> "under supervision" as it were.
Most likely this is the reason PL/I always passes a copy
of a constant, as this was well known at the time.
Quote: > In a way, it was almost a disappointment when this error started
> generating error messages about things like trying to modify
> read-only memory or something of the sort. That made the debugging
> so much simpler that my help was scarcely needed. :-)
The most common one I remember from beginning Fortran programmers
is not dimensioning arrays in subroutines. (Often the variable
has the same name, so why isn't one enough?) The result,
though, is no compiler messages (from most compilers), and
rarely a good runtime error as the system tries to execute
the data in the passed array. (Assuming the called routine
doesn't try to store into the array.)
I don't remember ever actually modifying a constant, but I
did accidentally modify a DO variable in a subroutine, resulting in
hundreds of pages out output. (The system stopped it at 5000 lines.)
-- glen
|
| Fri, 06 Jul 2007 17:04:38 GMT |
|
|
|
Michael Metcal
#7 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)
Quote: > I don't know where Fortran III went.
It was an IBM-internal version, and never released.
Regards,
Mike Metcalf
|
| Fri, 06 Jul 2007 17:57:10 GMT |
|
|
|
#8 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Gordon Sand
#9 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Quote:
> Roy Smith wrote (in comp.lang.python): >>Believe it or not, in some early versions of Fortran, numbers were not
>>immutable! I forget the exact scenario, but if you did something like:
>> subroutine munge (i)
>> i = 3
>> return
>>and then in your main program did:
>> j = 7
>> call munge (7)
>> write (6, 11) j
>>11 format ('j = ', i6)
>>it would print 3! The problem is that numerical constants were
> interned
>>(i.e. in the main program, there was only a single 7 stored in memory,
>>and both uses of 7 referred to the same memory location), and the
> value
>>passed to the subroutine was call by reference. It was almost as if
> the
>>compiler let you say "7 = 3" as an assignment statement.
>>Needless to say, people did indeed complain massively.
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?
The storing of numerical constants in "ordinary" storage locations
was true of many implementations. A reflection of this is the repeated
discussions of the effects of putting numerical constants into read only
segments and the resulting protection violations, sometimes from the
actions of copy-in/copy-out on arguments that were not changed but
supplied with literal values (in read only memory!). When the literals
are not protected there is an ability to change them. Some current
implementations have an option to always copy literals to protect them
before subroutine calls. I expect some do it without further comment.
When I first used Fortran II (long before I started to need bifocals)
I was rather sporting and used a leading dimension of 19 which I
"changed" in order to simulate adjustable dimensions. Not everyone was
impressed by such a clever trick. I expect my current reaction would
not be quite are restrained as some that I met at that time. Such
sporting usage was not intended by the compiler developers, or as
we now say "the program was not standard conforming".
|
| Fri, 06 Jul 2007 21:53:11 GMT |
|
|
|
Jim
#10 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)
Quote: > Roy Smith wrote (in comp.lang.python): > >Believe it or not, in some early versions of Fortran, numbers were not
> >immutable! I forget the exact scenario, but if you did something like:
> > subroutine munge (i)
> > i = 3
> > return
> >and then in your main program did:
> > j = 7
> > call munge (7)
> > write (6, 11) j
> > 11 format ('j = ', i6)
> >it would print 3! The problem is that numerical constants were
> interned
> >(i.e. in the main program, there was only a single 7 stored in memory,
> >and both uses of 7 referred to the same memory location), and the
> value
> >passed to the subroutine was call by reference. It was almost as if
> the
> >compiler let you say "7 = 3" as an assignment statement.
> >Needless to say, people did indeed complain massively.
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?
NOS or NOS/BE and this problem. The exact details escape me now..
Jim
|
| Sat, 07 Jul 2007 06:36:42 GMT |
|
|
|
James Parsl
#11 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) My favorite example of this occurred on one of the IBM mainframe compilers
back in
the 1970's:
call sub(0.0)
x = 0.0
i = 0
write(*,*) x,i
.
.
.
subroutine sub(x)
x = x - int(x/360.)*360
return
end
The result of the write statement: x = 0.0
i = very large number
It turned out in this case that the compiler writers were very "clever", and
had used the
same location for both real and integer 0. The actual hex "00 00 00 00"
was the
usual form for integer 0, but was an unnormalized form for real zero. When
the subroutine
was called, the formula involving X didn't change its value, but it did
normalize the
result so that it was, if I recall correctly, now "40 00 00 00".
After the return, x gets set to 0 (normalized) and i gets set to 2**30.
Quote: > Roy Smith wrote (in comp.lang.python): > >Believe it or not, in some early versions of Fortran, numbers were not
> >immutable! I forget the exact scenario, but if you did something like:
> > subroutine munge (i)
> > i = 3
> > return
> >and then in your main program did:
> > j = 7
> > call munge (7)
> > write (6, 11) j
> > 11 format ('j = ', i6)
> >it would print 3! The problem is that numerical constants were
> interned
> >(i.e. in the main program, there was only a single 7 stored in memory,
> >and both uses of 7 referred to the same memory location), and the
> value
> >passed to the subroutine was call by reference. It was almost as if
> the
> >compiler let you say "7 = 3" as an assignment statement.
> >Needless to say, people did indeed complain massively.
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?
|
| Sun, 08 Jul 2007 04:24:41 GMT |
|
|
|
glen herrmannsfeld
#12 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Quote:
> My favorite example of this occurred on one of the IBM mainframe
> compilers back in the 1970's:
Quote: > call sub(0.0)
> x = 0.0
> i = 0
> write(*,*) x,i
> subroutine sub(x)
> x = x - int(x/360.)*360
> return
> end
> The result of the write statement: x = 0.0
> i = very large number
> It turned out in this case that the compiler writers were very
> "clever", and had used the same location for both real and
> integer 0. The actual hex "00 00 00 00" was the usual form
> for integer 0, but was an unnormalized form for real zero.
> When the subroutine was called, the formula involving X didn't
> change its value, but it did normalize the result so that it
> was, if I recall correctly, now "40 00 00 00".
Quote: > After the return, x gets set to 0 (normalized) and i gets set to 2**30.
If this is S/360 or a related system, then a zero result should
be X'00000000', though a negative zero X'80000000' could also be
the result. Unnormalized zeros should not result from normal
arithmetic operations, as they don't have the properties of true
zeros. The Fortran AINT function, truncate the fractional part
of a REAL number, but keep it in floating point, is implemented
by adding X'47000000' that is, 0*16**7. In prenormalization
fractional bits will be shifted out, zero is added, and then
post-normalization shifts back if needed.
Addition and subtraction should not produce a negative zero, but
the unary - operator applied to a positive zero will. I am not
sure if Fortran compiles will generate a negative zero constant.
(Even though Fortran specifies positive constants and a unary
negation operator, I believe compilers will normally generate
signed constants where applicable.)
If the result wasn't exactly zero it could easily be near
X'40000000'.
-- glen
|
| Sun, 08 Jul 2007 05:13:32 GMT |
|
|
|
James Parsl
#13 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Could have been '80 00 00 00', I suppose. Hard to remember things that
happened
almost 30 years ago.
Quote:
> > My favorite example of this occurred on one of the IBM mainframe
> > compilers back in the 1970's:
> > call sub(0.0)
> > x = 0.0
> > i = 0
> > write(*,*) x,i
> > subroutine sub(x)
> > x = x - int(x/360.)*360
> > return
> > end
> > The result of the write statement: x = 0.0
> > i = very large number
> > It turned out in this case that the compiler writers were very
> > "clever", and had used the same location for both real and
> > integer 0. The actual hex "00 00 00 00" was the usual form
> > for integer 0, but was an unnormalized form for real zero.
> > When the subroutine was called, the formula involving X didn't
> > change its value, but it did normalize the result so that it
> > was, if I recall correctly, now "40 00 00 00".
> > After the return, x gets set to 0 (normalized) and i gets set to 2**30.
> If this is S/360 or a related system, then a zero result should
> be X'00000000', though a negative zero X'80000000' could also be
> the result. Unnormalized zeros should not result from normal
> arithmetic operations, as they don't have the properties of true
> zeros. The Fortran AINT function, truncate the fractional part
> of a REAL number, but keep it in floating point, is implemented
> by adding X'47000000' that is, 0*16**7. In prenormalization
> fractional bits will be shifted out, zero is added, and then
> post-normalization shifts back if needed.
> Addition and subtraction should not produce a negative zero, but
> the unary - operator applied to a positive zero will. I am not
> sure if Fortran compiles will generate a negative zero constant.
> (Even though Fortran specifies positive constants and a unary
> negation operator, I believe compilers will normally generate
> signed constants where applicable.)
> If the result wasn't exactly zero it could easily be near
> X'40000000'.
> -- glen
|
| Sun, 08 Jul 2007 05:25:26 GMT |
|
|
|
James Parsl
#14 / 14
|
Redefining a numeric constant in Fortran (Was Re: why are some types immutable?) Although I remember thinking at the time that '40 00 00 00' would have been
sensible because of the "excess 64" notation used for the exponent.
Quote: > Could have been '80 00 00 00', I suppose. Hard to remember things that > happened > almost 30 years ago.
> > > My favorite example of this occurred on one of the IBM mainframe
> > > compilers back in the 1970's:
> > > call sub(0.0)
> > > x = 0.0
> > > i = 0
> > > write(*,*) x,i
> > > subroutine sub(x)
> > > x = x - int(x/360.)*360
> > > return
> > > end
> > > The result of the write statement: x = 0.0
> > > i = very large number
> > > It turned out in this case that the compiler writers were very
> > > "clever", and had used the same location for both real and
> > > integer 0. The actual hex "00 00 00 00" was the usual form
> > > for integer 0, but was an unnormalized form for real zero.
> > > When the subroutine was called, the formula involving X didn't
> > > change its value, but it did normalize the result so that it
> > > was, if I recall correctly, now "40 00 00 00".
> > > After the return, x gets set to 0 (normalized) and i gets set to
2**30.
> > If this is S/360 or a related system, then a zero result should
> > be X'00000000', though a negative zero X'80000000' could also be
> > the result. Unnormalized zeros should not result from normal
> > arithmetic operations, as they don't have the properties of true
> > zeros. The Fortran AINT function, truncate the fractional part
> > of a REAL number, but keep it in floating point, is implemented
> > by adding X'47000000' that is, 0*16**7. In prenormalization
> > fractional bits will be shifted out, zero is added, and then
> > post-normalization shifts back if needed.
> > Addition and subtraction should not produce a negative zero, but
> > the unary - operator applied to a positive zero will. I am not
> > sure if Fortran compiles will generate a negative zero constant.
> > (Even though Fortran specifies positive constants and a unary
> > negation operator, I believe compilers will normally generate
> > signed constants where applicable.)
> > If the result wasn't exactly zero it could easily be near
> > X'40000000'.
> > -- glen
|
| Sun, 08 Jul 2007 05:36:32 GMT |
|
| |
|
