Why these original FORTRAN quirks?
Ancient_Hacker
(1) three-way arithmetic IF
(2) Column-6 as a continuation marker
(3) Non-significant spaces.
(4) Do loops fall though at least once.
(5) Numeric labels
(6) relatively short limit on identifier length.
All those seem like particulary restrictive, arbitrary, or hard to
parse design choices.
Sarr J. Blumson
: Anybody have any idea why good old FORTRAN had these quirks:
Some of them are "nobody new better yet," issues, but:
: (1) three-way arithmetic IF
IIRC the IBM 704 had an instruction that did this.
: (2) Column-6 as a continuation marker
So you could find it without scanning the line.
: (5) Numeric labels
: (6) relatively short limit on identifier length.
Saves space and make building a symbol table much simpler.
Remember, FORTRAN was built for a machine that was less powerful
than your watch.
--
--------
Sarr Blumson sarr.b...@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/
Larry__Weiss
Of all of these
(3) Non-significant spaces.
seems the hardest to justify at this late date.
It seems so strange that these two statements should parse identically
DO 10 I = 1.10
DO10I = 1.10
- Larry
Andrew Swallow
> Anybody have any idea why good old FORTRAN had these quirks:
>
>
> (1) three-way arithmetic IF
One of the big advantages of complex instruction sets was that
they contain Compare instructions. On a lot of computers the
assembler programmer had to write Subtraction followed by
jump if zero, jump if positive and jump if negative. The
arithmetic IF simply compressed the 4 instructions into a single
line.
>
> (2) Column-6 as a continuation marker
This was easy to use on card punches. The tab fields are fully
definable by the typist. A 'C' in column one meant a comment
and a digit meant a label so they used the first column after
the label.
>
> (3) Non-significant spaces.
This could have been an attempt to make variables more readable
since the underscore character '_' was not part of the character
set. Also the same filter can removed the spaces in variables and
between names and operators.
>
> (4) Do loops fall though at least once.
Useful when handling arrays. It is only when symbols are processed
than doing something zero times makes sense.
>
> (5) Numeric labels
Makes it easy to distinguish between labels and variables.
Algol 60 compliers could not.
>
> (6) relatively short limit on identifier length.
Shortage of room for symbol tables and an early machine could
hold 6 characters in its register, simplifying table searches.
>
> All those seem like particulary restrictive, arbitrary, or hard to
> parse design choices.
>
Andrew Swallow
wclo...@lanl.gov
Ancient_Hacker wrote:
> Anybody have any idea why good old FORTRAN had these quirks:
>
>
> (1) three-way arithmetic IF
logical flow. A three way case statement would have been easier to read
and follow, but that requires a more complicated syntax, at a time when
syntax was barely understood.
>
> (2) Column-6 as a continuation marker
Continuation markers are easier for novices to follow than statement
termination. Placement in the sixth column probably partly resulted
from
1. a limited character set so it was difficult to reserve a special
character for continuations
2. an overall approach to making position significant
3. wanting to put labels in the leftmost columns
4. a decision that five columns for labels was sufficient
5. a recognition that one character (column) was sufficient for a
continuation marker
>
> (3) Non-significant spaces.
Backus has discussed this in some detail. The primary reasoning, was
that data entry into cards was slow, error prone, and difficult to
correct, so they wanted to be forgiving of some mistakes.
>
> (4) Do loops fall though at least once.
Never a defined behavior, but was used in most pre-F77 implementations
as it puts the test at the end of the loop, resulting in one fewer test
=> (slightly) more efficient code for the common case of a fixed number
of loop. But of course was error prone for cases with arbitrary number
of loops.
>
> (5) Numeric labels
Allowed people to identify relative positions of the labeled
statements, making it easier to follow gotos etc/
>
> (6) relatively short limit on identifier length.
Partly memory limits, larger names would have required more
sophisticated linkers, partly lack of experience (Fortran (I) had
single character names the longer names in Fortran II were almost a
luxury after that.
>
> All those seem like particularly restrictive, arbitrary, or hard to
> parse design choices.
Parsing and lexing theory only became well understood in the mid-60s
after Fortran was designed. Surprisingly, while the lexical analysis of
early Fortran is harder than most languages, due to the use of
non-significant spaces and the lake of reserved keywords, it is not
much harder, and parsing Fortran is comparable in difficulty to other
commonly used languages.
Larry__Weiss
> Anybody have any idea why good old FORTRAN had these quirks:
>
I do like the way that FORTRAN IV marked line continuation.
You mark the line that is the continuation.
Using column 6 places the continuation marker next to
the left-most character of the statement. You notice
it right away.
Languages like VB where you mark the line above the
line that is the continuation are error prone, IMO.
- Larry
Larry__Weiss
> Anybody have any idea why good old FORTRAN had these quirks:
>
Since labels had to be five characters or less, you would have
been restricted to simple alphanumeric labels had they been allowed.
Using assignment of labels to identifiers you could add some spice to
your GO TO statements.
For example:
http://www.dunnington.u-net.com/public/startrek/spacwr.for
- Larry
David Wade
news:1160658445.7...@h48g2000cwc.googlegroups.com...
I think the oddest thing is the lack of reserved variable names is the
oddest issue. For example it was perfectly legal to have an array called
FORMAT, READ, WRITE or even IF. This does result in some odd error messages
when the line can't be parsed properly as the compiler can't always tell if
it is missing an array declaration, or it has a malformed statement..
Scott Lurndal
>Anybody have any idea why good old FORTRAN had these quirks:
>
>
>(1) three-way arithmetic IF
Simple translation to a "compare" machine instruction. two
branches to the < > case and fall through to the = case.
>
>(2) Column-6 as a continuation marker
Ease of parsing, given 5 column sequence numbers.
>
>(3) Non-significant spaces.
>
>(4) Do loops fall though at least once.
>
>(5) Numeric labels
Storage efficiency.
>
>(6) relatively short limit on identifier length.
Storage efficiency.
>
>All those seem like particulary restrictive, arbitrary, or hard to
>parse design choices.
You try to write a compiler that runs in 8k of core.
scott
Adam Funk
> "Ancient_Hacker" <gr...@comcast.net> writes:
>>Anybody have any idea why good old FORTRAN had these quirks:
>>
>>
>>(1) three-way arithmetic IF
>
> Simple translation to a "compare" machine instruction. two
> branches to the < > case and fall through to the = case.
Perl's sort and Java's comparators (and no doubt other languages'
analogous features) use three-way comparisons and are extremely useful
that way.
Richard E Maine
> Anybody have any idea why good old FORTRAN had these quirks:
I won't bother with most of these. Others have answered them fine.
> (4) Do loops fall though at least once.
Please note that this is *NOT* a property of Fortran. It was a property
of some, but not all, particular compilers - not the language spec.
Well, in days before 1966, there wasn't a standard language spec, so the
distinction becomes more murky. As of the Fortran 66 standard, the
matter is not at all murky. The code in question is non-standard
conforming. This has not prevented many people from getting it wrong and
incorrectly claiming that the f66 standard specified this behavior.
> All those seem like particulary restrictive, arbitrary, or hard to
> parse design choices.
You obviously aren't quite as ancient as your choice of posting name
implies. :-) If you didn't program in the era, it might be hard for you
to imagine just how limited some resources were. This had huge effects
on just about everything in programming. The world really is different
today.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Michael J Kingston
Ancient_Hacker <gr...@comcast.net> writes
FORTRAN language were related to the abilities of the IBM 704 (I think
it was that one ....). Can't be more specific.
--
Michael J Kingston
Larry__Weiss
From http://en.wikipedia.org/wiki/Fortran
* "Consistently separating words by spaces became a general custom
about the tenth century A. D., and lasted until about 1957,
when FORTRAN abandoned the practice."
—Sun FORTRAN Reference Manual
* "People are very flexible and learn to adjust to strange
surroundings — they can become accustomed to read Lisp and
Fortran programs, for example."
—Art of PROLOG, Leon Sterling and Ehud Shapiro, MIT Press
* "Warning: Go directly to Jail. Do not pass GO. Do not collect
$200." - Easter egg in the SDS/Xerox Sigma 7 FORTRAN compiler,
when the statement GO TO JAIL was encountered.
* "GOD is REAL unless declared INTEGER."
* A good FORTRAN programmer can write FORTRAN code in any language.
* circa 1980 (following the standardization of FORTRAN 77):
"Q: What will the scientific programming language of the year
2000 look like? ...
A: Nobody knows, but its name will be FORTRAN."
Joachim Pense
> Ancient_Hacker wrote:
>> Anybody have any idea why good old FORTRAN had these quirks:
>>
>>
>> (3) Non-significant spaces.
>
> This could have been an attempt to make variables more readable
> since the underscore character '_' was not part of the character
> set. Also the same filter can removed the spaces in variables and
> between names and operators.
>
I wonder who introduced the idea of identifiers being whole words. The
tradition of mathematical FORmulas (which FORTRAN wanted to TRANslate)
suggests single letter identifiers, indexed by numbers. The whole idea
of having whole words and even non-significant spaces looks more like
something coming from "the other side", the ...MATIC languages of
Grace Hopper, which became predecessors of COBOL.
Joachim
Tim Shoppa
> Anybody have any idea why good old FORTRAN had these quirks:
>
>
> (1) three-way arithmetic IF
Part of the IBM 704 instruction set. Makes some sense for
textbook-simple math programs.
> (2) Column-6 as a continuation marker
Assemblers in the 70's and 80's were frequently fixed-format.
> (3) Non-significant spaces.
Parsing on whitespace came much later (C). Certainly a decade later
some liked "GO TO" others liked "GOTO"!
> (4) Do loops fall though at least once.
Don't see the problem there, makes perfect sense to me! If it doesn't
fall through then each CONTINUE at the end of a loop becomes a COME
FROM target.
> (5) Numeric labels
Makes assigned GOTO look more like a simple math assignment (really it
goes deeper). Over the decades hiding/revealing the nature of pointers
has come and gone. This is a hiding of nature.
> (6) relatively short limit on identifier length.
Fixed limits on identifier lengths are commonly associated with
fixed-format input (again assembler legacy). The legacy lives on today
in lots and lots of things.
> All those seem like particulary restrictive, arbitrary, or hard to
> parse design choices.
General purpose lexical parsers were pie-in-the-sky back then. They
still for much of today's computing/DP industry! I see veterans
continually surprised at what is easily achievable with hash tables
etc.
Tim.
Tim Shoppa
> Anybody have any idea why good old FORTRAN had these quirks:
>
Slowly coming to me is an insight I had a couple of decades ago:
A statement beginning with a number certainly has a label.
Doesn't help a whole lot for traditional fixed-format fortran decks,
but for later compilers that took "free format" it probably helped
things.
In such free-format Fortran, with no keywords and no spaces, it would
be very hard to tell an assignment (also a declaration!) from a dozen
equally-valid parsings where the statement began with a label of 1, 2,
3, etc. characters.
Tim.
Peter Flass
> Anybody have any idea why good old FORTRAN had these quirks:
>
>
Here are my guesses:
> (1) three-way arithmetic IF
Hardware supported 3-way branch on -, 0, +.
>
> (2) Column-6 as a continuation marker
5-digit statement numbers?
>
> (3) Non-significant spaces.
Syntax didn't require spaces.
>
> (4) Do loops fall though at least once.
>
> (5) Numeric labels
>
> (6) relatively short limit on identifier length.
Limited memory for symbol-table.
>
> All those seem like particulary restrictive, arbitrary, or hard to
> parse design choices.
>
Remember the time-frame.
Peter Flass
This isn't odd at all, PL/I hase it also, where it's m ore important due
to the larger number of keywords. Languages with reserved words are odd.
Peter Flass
> Ancient_Hacker wrote:
>
>> Anybody have any idea why good old FORTRAN had these quirks:
>> (1) three-way arithmetic IF
>> (2) Column-6 as a continuation marker
>> (3) Non-significant spaces.
>> (4) Do loops fall though at least once.
>> (5) Numeric labels
>> (6) relatively short limit on identifier length.
>> All those seem like particulary restrictive, arbitrary, or hard to
>> parse design choices.
>>
>
> From http://en.wikipedia.org/wiki/Fortran
>
> * "Consistently separating words by spaces became a general custom
> about the tenth century A. D., and lasted until about 1957,
> when FORTRAN abandoned the practice."
> —Sun FORTRAN Reference Manual
Note that nothing *stopped* programmers fron inserting spaces (even
where they didn't improve readability.) There's a difference between
allowing spaces to be eliminated and forcing them to be.
Tim Shoppa
> Larry__Weiss wrote:
>
> > Ancient_Hacker wrote:
> >
> >> Anybody have any idea why good old FORTRAN had these quirks:
> >> (1) three-way arithmetic IF
> >> (2) Column-6 as a continuation marker
> >> (3) Non-significant spaces.
> >> (4) Do loops fall though at least once.
> >> (5) Numeric labels
> >> (6) relatively short limit on identifier length.
> >> All those seem like particulary restrictive, arbitrary, or hard to
> >> parse design choices.
> >>
> >
> > From http://en.wikipedia.org/wiki/Fortran
> >
> > * "Consistently separating words by spaces became a general custom
> > about the tenth century A. D., and lasted until about 1957,
> > when FORTRAN abandoned the practice."
>
> Note that nothing *stopped* programmers fron inserting spaces (even
> where they didn't improve readability.) There's a difference between
> allowing spaces to be eliminated and forcing them to be.
I knew a British programmer who began every program with the statement:
PROGRAMME
Tim.
Larry__Weiss
> I knew a British programmer who began every program with the statement:
> PROGRAMME
>
Brilliant!
- Larry
Richard Maine
> I knew a British programmer who began every program with the statement:
>
> PROGRAMME
I used to do that on occasion. However, my current British friends tell
me that this isn't actually the right spelling for a computer program,
even there.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Richard Steiner
"Ancient_Hacker" <gr...@comcast.net> spake unto us, saying:
>Anybody have any idea why good old FORTRAN had these quirks:
>
>(1) three-way arithmetic IF
Quite useful for binary searches. :-)
>(4) Do loops fall though at least once.
This behavior depends completely on the compiler implementation.
>(5) Numeric labels
Why not? They work well. We always standardized on 1000 as the normal
RETURN from subroutines and 9000-series labels for error conditions.
>(6) relatively short limit on identifier length.
The compilers that I'm used to (UNIVAC/unisys compilers) chose six
character variable names because six FIELDATA characters fit very
nicely in a single 36-bit word.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night.
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
Andrew Swallow
[snip]
>
> I knew a British programmer who began every program with the statement:
>
> PROGRAMME
A programme is a list of actors you buy at the theatre, fun but
nothing to do with computing.
Andrew Swallow
Brian Inglis
...or summat on the telly, or at a conference, ... everything but code
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Larry__Weiss
> Anybody have any idea why good old FORTRAN had these quirks:
>
Non-significant only outside of so-called Hollerith strings, of course.
- Larry
Larry__Weiss
> On Fri, 13 Oct 2006 04:03:54 +0100 in alt.folklore.computers, Andrew
> Swallow <am.sw...@btopenworld.com> wrote:
>>Tim Shoppa wrote:
>>[snip]
>>>
>>> I knew a British programmer who began every program with the statement:
>>>
>>> PROGRAMME
>>
>>A programme is a list of actors you buy at the theatre, fun but
>>nothing to do with computing.
>
> ...or summat on the telly, or at a conference, ... everything but code
>
Has anyone informed the BBC's editors? witness:
http://news.bbc.co.uk/1/hi/world/europe/3187560.stm
- Larry
Dennis Ritchie
"Peter Flass" <Peter...@Yahoo.com> wrote in message news:ZyzXg.6401$0L1....@twister.nyroc.rr.com...
....
> Here are my guesses:
>
> > (1) three-way arithmetic IF
>
> Hardware supported 3-way branch on -, 0, +.
....
Interestingly, although the IBM 704 and successors had a CAS
instruction that sort of did a 3-way branch (compare AC with
the addressed location; don't skip, skip 1 or skip 2 instructions according
to whether AC was >, =, < location) this wasn't used. The reason
was that +0 on a sign-magnitude machine was for purposes of CAS
greater than -0 (not equal), and this didn't work out for the 3-way IF.
So I guess that the 3-way IF was mentally suggested by the hardware, not
taken advantage of.
> >
> > (4) Do loops fall though at least once.
Presumably an artifact of the TIX instruction and the desire to do
all the testing at the bottom. As has been pointed out, it was never in the standard.
....
Dennis
Joe Pfeiffer
On this side of the Atlantic, that is spelled "program". Or sometimes
"playbill."
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Brian Inglis
They probably also consider it unEnglish to use American spellings
such as disk, but they're used in the industry, possibly not far
outside it, or it could just be their spellchecker.
Adam Funk
>> From http://en.wikipedia.org/wiki/Fortran
>>
>> * "Consistently separating words by spaces became a general custom
>> about the tenth century A. D., and lasted until about 1957,
>> when FORTRAN abandoned the practice."
>> Sun FORTRAN Reference Manual
That's hilarious!
> Note that nothing *stopped* programmers fron inserting spaces (even
> where they didn't improve readability.) There's a difference between
> allowing spaces to be eliminated and forcing them to be.
But when a long formula just runs past column 72, it's so much easier
to delete some decorative spaces than to break it logically onto a
continuation line.
jmfb...@aol.com
Did you ever program using only absolute addresses? Even
a small program could have a couple hundred identifiers.
People who write code either had to keep their notes in
the comments, or be really efficient and keep their "notes"
in the name of the variable. Consider subroutines calls.
/BAH
jmfb...@aol.com
wclo...@lanl.gov wrote:
>
>Ancient_Hacker wrote:
>> Anybody have any idea why good old FORTRAN had these quirks:
>>
>>
>Partly matched a hardware feature, partly matched a moderately common
>logical flow. A three way case statement would have been easier to read
>and follow, but that requires a more complicated syntax, at a time when
>syntax was barely understood.
>>
>> (2) Column-6 as a continuation marker
>
>termination. Placement in the sixth column probably partly resulted
>from
>1. a limited character set so it was difficult to reserve a special
>character for continuations
>2. an overall approach to making position significant
>3. wanting to put labels in the leftmost columns
>4. a decision that five columns for labels was sufficient
>5. a recognition that one character (column) was sufficient for a
>continuation marker
And you could sort them out.
<snip>
/BAH
Philipp Hachtmann
> Interestingly, although the IBM 704 and successors had a CAS
> instruction that sort of did a 3-way branch (compare AC with
> the addressed location; don't skip, skip 1 or skip 2 instructions according
> to whether AC was >, =, < location) this wasn't used. The reason
> was that +0 on a sign-magnitude machine was for purposes of CAS
> greater than -0 (not equal), and this didn't work out for the 3-way IF.
>
> So I guess that the 3-way IF was mentally suggested by the hardware, not
> taken advantage of.
Hm, but aren't there a lot of two's complement machines around?
The Honeywell X16 for example have such an operation - and no +0 an -0...
Philipp
Larry__Weiss
> On 2006-10-12, Peter Flass <Peter...@Yahoo.com> wrote:
>>> From http://en.wikipedia.org/wiki/Fortran
>>> * "Consistently separating words by spaces became a general custom
>>> about the tenth century A. D., and lasted until about 1957,
>>> when FORTRAN abandoned the practice."
>>> Sun FORTRAN Reference Manual
>
> That's hilarious!
>
>> allowing spaces to be eliminated and forcing them to be.
>
> But when a long formula just runs past column 72, it's so much easier
> to delete some decorative spaces than to break it logically onto a
> continuation line.
>
Which brings up another curiosity. That FORTRAN parsing ignored all
characters past the 72th on each line.
That was justified because characters past the 72nd (73 through 80
on a card format) were available to use to hold card sequence numbers
to help maintain punch card deck integrity. The usual scenario was to
place numbers in those columns that would assist you in reordering
the card deck if it was misordered (perhaps by accidentally dropping
it on the floor).
Those of us who programmed using punch cards know what it's like to
actually hold the source to a program in one's hands ... something
analogous to having voted using punched cards before the touchscreen
voting machines took their place.
- Larry
Joe Morris
>"Peter Flass" <Peter...@Yahoo.com> wrote:
>> Here are my guesses:
>>
>> > (1) three-way arithmetic IF
>>
>> Hardware supported 3-way branch on -, 0, +.
> ....
>Interestingly, although the IBM 704 and successors had a CAS
>instruction that sort of did a 3-way branch (compare AC with
>the addressed location; don't skip, skip 1 or skip 2 instructions according
>to whether AC was >, =, < location) this wasn't used. The reason
>was that +0 on a sign-magnitude machine was for purposes of CAS
>greater than -0 (not equal), and this didn't work out for the 3-way IF.
Agreed. The 704x/709x hardware used sign-magnitude for both integer
and (the mantissa of) real numbers. I never worked with a 704,
but the 704x and 709x FORTRAN compilers (under both FMS and IBSYS)
the arithmetic IF was implemented by the code (using target symbols
as generated by IBFTC):
* IF (A-B) 10, 20, 30
CLA A (load A to the accumulator)
FSB B (Floating subtract B from the AC)
TZE 20S (Branch if AC is zero without regard to sign)
TMI 10S (Branch if AC negative)
TRA 30S (Unconditional branch)
...although there are reports of some brain-dead implementations of
FORTRAN in which an overflow during evaluation of the expression would
result in control falling through into the following statement if
the user told the system to ignore overflow conditions.
Joe Morris
Joe Morris
>On 2006-10-12, Peter Flass <Peter...@Yahoo.com> wrote:
>>> From http://en.wikipedia.org/wiki/Fortran
>>>
>>> * "Consistently separating words by spaces became a general custom
>>> about the tenth century A. D., and lasted until about 1957,
>>> when FORTRAN abandoned the practice."
>>> Sun FORTRAN Reference Manual
>That's hilarious!
Speaking of FORTRAN features, my Linux box this morning tossed up the
following fortune cookie (and I swear that it's randomly selected!):
#######
The primary purpose of the DATA statement is to give names to constants;
instead of referring to pi as 3.141592653589793 at every appearance, the
variable PI can be given that value with a DATA statement and used instead
of the longer form of the constant. This also simplifies modifying the
program, should the value of pi change.
-- FORTRAN manual for Xerox Computers
#######
Joe Morris
Joe Morris
>Ancient_Hacker wrote:
>> Anybody have any idea why good old FORTRAN had these quirks:
>> (6) relatively short limit on identifier length.
>Fixed limits on identifier lengths are commonly associated with
>fixed-format input (again assembler legacy). The legacy lives on today
>in lots and lots of things.
Um...I think a more likely explanation was that the original implementaion
was to be on the IBM 704, which used 6-bit BCD characters, and which
had a word size of 36 bits. 36 divided by 6 yields six characters
per word, which makes for efficient use of (very limited) memory.
And before someone asks, I've never seen the source for the original
FORTRAN compiler based on the first version of the language specs.
Does anyone know if it's available?
Joe Morris
Larry__Weiss
>
> Speaking of FORTRAN features, my Linux box this morning tossed up the
> following fortune cookie (and I swear that it's randomly selected!):
>
> #######
> The primary purpose of the DATA statement is to give names to constants;
> instead of referring to pi as 3.141592653589793 at every appearance, the
> variable PI can be given that value with a DATA statement and used instead
> of the longer form of the constant. This also simplifies modifying the
> program, should the value of pi change.
> -- FORTRAN manual for Xerox Computers
> #######
>
You and I probably know what that technical writer was trying to say!
In fact the explicit imperfect value of pi used in programs was one of
my earliest worries about whether these programming languages were to be
trusted to encode mission critical computations!
That was before I learned about the limitations on floating point
computation in general (still gives me an upset stomach to think
about the presumptions of accuracy that are sure to pervade some
programs that probably went into designing the next airplane I'll
depend upon to get me somewhere).
Of course, the age of some of the aircraft still in service means
that they were probably designed with sliderules...
- Larry
Jean-Marc Bourguet
> And before someone asks, I've never seen the source for the original
> FORTRAN compiler based on the first version of the language specs.
> Does anyone know if it's available?
There are some sources for FORTRAN II here:
http://community.computerhistory.org/scc/projects/FORTRAN
(I didn't look at them).
--
Jean-Marc
Adam Funk
> Which brings up another curiosity. That FORTRAN parsing ignored all
> characters past the 72th on each line.
>
> That was justified because characters past the 72nd (73 through 80
> on a card format) were available to use to hold card sequence numbers
> to help maintain punch card deck integrity. The usual scenario was to
> place numbers in those columns that would assist you in reordering
> the card deck if it was misordered (perhaps by accidentally dropping
> it on the floor).
*Curiosity* isn't the word I used to use when I was writing Fortran
with a crude text editor that did *not* highlight test running past
column 72 (as Emacs for example does) and got syntax errors because a
")" had gone into the margin.
Nick Spalding
on Fri, 13 Oct 2006 08:53:02 -0500:
>Joe Morris wrote:
>>
>> Speaking of FORTRAN features, my Linux box this morning tossed up the
>> following fortune cookie (and I swear that it's randomly selected!):
>>
>> #######
>> The primary purpose of the DATA statement is to give names to constants;
>> instead of referring to pi as 3.141592653589793 at every appearance, the
>> variable PI can be given that value with a DATA statement and used instead
>> of the longer form of the constant. This also simplifies modifying the
>> program, should the value of pi change.
>> -- FORTRAN manual for Xerox Computers
>> #######
>>
>
>You and I probably know what that technical writer was trying to say!
You don't think he was making a tiny little joke?
--
Nick Spalding
Adam Funk
>> The primary purpose of the DATA statement is to give names to constants;
>> instead of referring to pi as 3.141592653589793 at every appearance, the
>> variable PI can be given that value with a DATA statement and used instead
>> of the longer form of the constant. This also simplifies modifying the
>> program, should the value of pi change.
>> -- FORTRAN manual for Xerox Computers
> You and I probably know what that technical writer was trying to say!
I've always thought that passage was meant to be funny.
Larry__Weiss
Actually, no I don't think so, but how would one know?
I just take it to mean that perhaps someone might wish to use a
different approximation, but then perhaps it was just too sly a joke
for me.
I wonder what Xerox document that quotation was taken from.
Does anyone have a copy of that document? The quotation appears in many
many webpages, but none to my knowledge refer to the specific manual.
- Larry
Charlie Gibbs
(Larry__Weiss) writes:
> * "Consistently separating words by spaces became a general custom
> about the tenth century A. D., and lasted until about 1957,
> when FORTRAN abandoned the practice."
> 祐un FORTRAN Reference Manual
This practice spread from programming into general use in the 1980s,
when marketroids polluted the language with BiCapitalization.
The way things are going, English will eventually look like German,
full of tremendously long compound words. Such words will then be
replaced by even more cryptic acronyms.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Nick Spalding
on Fri, 13 Oct 2006 15:37:01 +0100:
I'm glad I'm not the only one.
--
Nick Spalding
Stan Barr
>
>The way things are going, English will eventually look like German,
>full of tremendously long compound words.
Such as Antidisestablishmentarianism?? :-)
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
CBFalconer
No, it should be perfectly serious. The so-called fixed constants
of the universe were determined at the time of the big-bang,
setting G, C, PI, e, Avogadros number, etc. Other universes could
easily have slightly differing values, and it may be quite
determinant whether or not it will expand forever. For all you
know in that universe those could all be rational values. Xerox
was simply trying to cater to a larger market.
--
"The mere formulation of a problem is far more often essential
than its solution, which may be merely a matter of mathematical
or experimental skill. To raise new questions, new possibilities,
to regard old problems from a new angle requires creative
imagination and and marks real advances in science."
-- Albert Einstein
AZ Nomad
>Anybody have any idea why good old FORTRAN had these quirks:
>(1) three-way arithmetic IF
>(2) Column-6 as a continuation marker
The first 4 (5?) colums were for a card sequence number so you could recover
from dropping a card stack on the floor. THe first available column after
the sequence number was for the continuation marker.
>(3) Non-significant spaces.
Why should spaces ever be significant? Modern languages are the same.
Stick a space anywhere but inside an identifier and it won't make one bit of
difference.
>(4) Do loops fall though at least once.
Better than not having loops at all.
>(5) Numeric labels
The first attempt at something is going to be simpler than the Nth attempt.
>(6) relatively short limit on identifier length.
Keep in mind where FORTRAN original ran. Choice 1) limited identifier
length. Choice 2) compiler unable to run on any current hardware or whose
system requirements were a hundred thousand times greater than any expected
programmer labor savings. Take your pick.
>All those seem like particulary restrictive, arbitrary, or hard to
>parse design choices.
Oh, you poor baby!
Keep in mind that when FORTRAN was created it had to be done in hand
assembled machine code and that there was no body of experience. It's
primary function was for automated math. You don't need twenty character
identifiers to program "E=I*R".
Adam Funk
>>>> The primary purpose of the DATA statement is to give names to
>>>> constants; instead of referring to pi as 3.141592653589793 at
>>>> every appearance, the variable PI can be given that value with
>>>> a DATA statement and used instead of the longer form of the
>>>> constant. This also simplifies modifying the program, should
>>>> the value of pi change.
>>>> -- FORTRAN manual for Xerox Computers
>>
>>> You and I probably know what that technical writer was trying to
>>> say!
>>
>> I've always thought that passage was meant to be funny.
>
> No, it should be perfectly serious. The so-called fixed constants
> of the universe were determined at the time of the big-bang,
> setting G, C, PI, e, Avogadros number, etc. Other universes could
> easily have slightly differing values, and it may be quite
> determinant whether or not it will expand forever. For all you
> know in that universe those could all be rational values. Xerox
> was simply trying to cater to a larger market.
What foresight!
Joe Pfeiffer
Not nearly as bad as when I had +0.5 all land past column 72. Syntax
errors aren't nearly as hard to figure out as more-or-less correct
rounding that just... doesn't...
Rich Alderson
> Dennis Ritchie wrote:
Irrelevant: The original language was designed by an IBM employee for an IBM
system which *was* 1's-complement. Everything after that is stuck with the
compatibility issue.
--
Rich Alderson | /"\ ASCII ribbon |
ne...@alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
Rich Alderson
> On 13 Oct 06 07:39:03 -0800, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>> The way things are going, English will eventually look like German,
>> full of tremendously long compound words.
> Such as Antidisestablishmentarianism?? :-)
That is not a compound, which would rather be something like "blackbird". It's
a simple word made up of a single root and a number of derivational affixes,
each creating a new stem from the predecessor word.
wclo...@lanl.gov
Joe Morris wrote:
> Adam Funk <a24...@yahoo.com> writes:
> <snip>
> Speaking of FORTRAN features, my Linux box this morning tossed up the
> following fortune cookie (and I swear that it's randomly selected!):
>
> #######
> The primary purpose of the DATA statement is to give names to constants;
> instead of referring to pi as 3.141592653589793 at every appearance, the
> variable PI can be given that value with a DATA statement and used instead
> of the longer form of the constant. This also simplifies modifying the
> program, should the value of pi change.
> -- FORTRAN manual for Xerox Computers
> #######
>
> Joe Morris
have been an indirect reference to the runtime modification of
"constants", a not unknown problem with Fortran 66 &77 programs?
David Wade
"Larry__Weiss" <l...@airmail.net> wrote in message
news:12iu1pv...@corp.supernews.com...
> Brian Inglis wrote:
> > On Fri, 13 Oct 2006 04:03:54 +0100 in alt.folklore.computers, Andrew
> > Swallow <am.sw...@btopenworld.com> wrote:
> >>Tim Shoppa wrote:
> >>[snip]
> >>>
> >>> I knew a British programmer who began every program with the
statement:
> >>>
> >>> PROGRAMME
> >>
> >>A programme is a list of actors you buy at the theatre, fun but
> >>nothing to do with computing.
> >
> > ...or summat on the telly, or at a conference, ... everything but code
> >
>
> Has anyone informed the BBC's editors? witness:
>
> http://news.bbc.co.uk/1/hi/world/europe/3187560.stm
>
This is the Channel Islands where special language rules apply. I remember
many years ago being told by a director who read a report of mine that
"program" should be "programme". I can't remember how or where I checked but
I did manage to find a note from either the British Computing Society or the
British Standards Institute that said that for computer programs we would
use the US spelling... Don't think he was best pleased...
David Wade
"Jean-Marc Bourguet" <j...@bourguet.org> wrote in message
news:87zmc0z...@news.bourguet.org...
> Joe Morris <jcmo...@mitre.org> writes:
>
> > And before someone asks, I've never seen the source for the original
> > FORTRAN compiler based on the first version of the language specs.
> > Does anyone know if it's available?
>
I don't know if its available. I started with Fortran II so not quit the
start. I think there is a 1620 emulator but not sure if there is the Fortran
II compiler. I remember that it did arrays slightly differently than modern
fortran. Also no implicit conversion between real and int so:-
F=3*A
would not compile (unless you had declared F and A to be integer. The manula
is here :-
http://www.bitsavers.org/pdf/ibm/1620/
Roland Hutchinson
> In fact the explicit imperfect value of pi used in programs was one of
> my earliest worries about whether these programming languages were to be
> trusted to encode mission critical computations!
>
> That was before I learned about the limitations on floating point
> computation in general (still gives me an upset stomach to think
> about the presumptions of accuracy that are sure to pervade some
> programs that probably went into designing the next airplane I'll
> depend upon to get me somewhere).
>
> Of course, the age of some of the aircraft still in service means
> that they were probably designed with sliderules...
If the margin of safety of the aircraft design isn't greater than the error
of "slide rule accuracy" by more than a couple orders of magnitude, I don't
want to be on the flight so much, myself.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Dave Pitts
>On 12 Oct 2006 06:07:25 -0700, Ancient_Hacker <gr...@comcast.net> wrote:
>
>
>
>
>>Anybody have any idea why good old FORTRAN had these quirks:
>>
>>
>
>
>
>
>>(1) three-way arithmetic IF
>>
>>
>
>
>
The IBM 704/709/7090... had a instructions that worked this way. The LAS
(Compare logical
accumulator with storage) or CAS (Compare accumulator with storage). If
the result of the
compare is positive the next instruction is executed, if equal zero the
instruction counter is
incremented by one and that instruction is executed and if the result is
less than zero the
instruction counter is incremented by two and that instruction is executed.
>>(2) Column-6 as a continuation marker
>>
>>
>The first 4 (5?) colums were for a card sequence number so you could recover
>from dropping a card stack on the floor. THe first available column after
>the sequence number was for the continuation marker.
>
>
Nope. The first 5 characters are labels for GO TO, IF, DO, etc. Columns
73-80 are used for the
statement sequence numbers (see below). When you packed the characters 6
per 36 bit word it was
an easy check to see if the least significant character in the first
word was blank.
>
>
>>(3) Non-significant spaces.
>>
>>
>Why should spaces ever be significant? Modern languages are the same.
>Stick a space anywhere but inside an identifier and it won't make one bit of
>difference.
>
>
>
>>(4) Do loops fall though at least once.
>>
>>
>Better than not having loops at all.
>
>
>
>>(5) Numeric labels
>>
>>
>The first attempt at something is going to be simpler than the Nth attempt.
>
>
>
>
>>(6) relatively short limit on identifier length.
>>
>>
>Keep in mind where FORTRAN original ran. Choice 1) limited identifier
>length. Choice 2) compiler unable to run on any current hardware or whose
>system requirements were a hundred thousand times greater than any expected
>programmer labor savings. Take your pick.
>
>
>
Nope. The original implementation machines were 36 bit machines using 6
bit characters. You'd
pack 6 characters per word. There are no character instructions for
these machines; so, you'd use
the integer compare instructions for symbol compares.
>>All those seem like particulary restrictive, arbitrary, or hard to
>>parse design choices.
>>
>>
>Oh, you poor baby!
>
>Keep in mind that when FORTRAN was created it had to be done in hand
>assembled machine code and that there was no body of experience. It's
>primary function was for automated math. You don't need twenty character
>identifiers to program "E=I*R".
>
>
Nope. It was written in an assembler language called SAP (Symbolic
Assembler Program).
The later Fortran II was written in FAP (Fortran Assembler Program) and
Fortran IV was
written in MAP (Macro Assembly Program). Yes, the IBM 709/7090 computers
had three
assemblers through their lifetime.
Another thing about the sequence number field (cols 73-80): These
machines being 36 bit,
6 characters/per word systems did I/O in words. So, if reading directly
from cards (80 cols
are not divisable by 6) only 72 columns were read (12 words). When
reading from tape,
80 cols were supported, but the read/write was 14 words (84 characters)
per record.
All language processors on these systems processed only the first 72
characters of a record.
If you did drop a deck of cards and you did put sequence numbers in the
field you can reorder
them by using the 088 Sorter, a stand alone machine that would do the
work.
--
Dave Pitts PULLMAN: Travel and sleep in safety and comfort.
dpi...@cozx.com My other RV IS a Pullman (Colorado Pine).
http://www.cozx.com/~dpitts
Roland Hutchinson
I think you'll find that the values of pi and e are independent of the
contingent events of cosmological history (though not of legislative
history, as is well known).
But having G and c and other physical constants be user-installable options
makes a certain amout of sense, if you want your range of universes to suit
all tastes.
Roland Hutchinson
> On 13 Oct 06 07:39:03 -0800, Charlie Gibbs <cgi...@kltpzyxm.invalid>
> wrote:
>>
>>The way things are going, English will eventually look like German,
>>full of tremendously long compound words.
>
> Such as Antidisestablishmentarianism?? :-)
Zum Beispiel.
Tim Shoppa
> "Tim Shoppa" <sho...@trailing-edge.com> writes:
>
> >Ancient_Hacker wrote:
> >> Anybody have any idea why good old FORTRAN had these quirks:
>
> >> (6) relatively short limit on identifier length.
>
> >Fixed limits on identifier lengths are commonly associated with
> >fixed-format input (again assembler legacy). The legacy lives on today
> >in lots and lots of things.
>
> Um...I think a more likely explanation was that the original implementaion
> was to be on the IBM 704, which used 6-bit BCD characters, and which
> had a word size of 36 bits. 36 divided by 6 yields six characters
> per word, which makes for efficient use of (very limited) memory.
Alternatively, in a backronymic sort of a way, the largest 5-digit
decimal number will comfortably sit in a signed 18 bit word (36 bit
halfword).
In fact some later 16-bit
maybe-not-quite-standard-but-still-widely-used FORTRAN implementations
allowed only line numbers up to 32767 or 65535.
And even more in fact, I don't believe it's related to 6-bit BCD
packing at all, although I can't prove it :-). I do know other
language-like systems where only the first 4 characters were
signifigant (e.g. 32-bits with 8 bits per character) though for such
reasons.
If it was related to 6-bit BCD packing and 36-bit words, I'd expect
other 6-character limits to show up, like keywords limited to only 6
characters (broken by DIMENSION, CONTINUE, SUBROUTINE, FUNCTION).
Although over the years I have met some broken FORTRAN compilers that
allowed some pretty funky things to be misidentified as keywords!
> And before someone asks, I've never seen the source for the original
> FORTRAN compiler based on the first version of the language specs.
> Does anyone know if it's available?
Paul McJones and Paul Pierce and some others have been doing some
remarkable work along these lines. They don't visit Usenet very often
these days but it would be impossible to discuss the history of FORTRAN
in terms of original sources without mentioning these guys.
See http://www.mcjones.org/dustydecks for a good start at what's out
there, including listings of "near original" versions and attempts to
run it under emulators etc. (and eventually real hardware again!)
Tim.
David DeLaney
>>> No, it should be perfectly serious. The so-called fixed constants
>>> of the universe were determined at the time of the big-bang,
>>> setting G, C, PI, e, Avogadros number, etc. Other universes could
>>> easily have slightly differing values, and it may be quite
>>> determinant whether or not it will expand forever. For all you
>>> know in that universe those could all be rational values. Xerox
>>> was simply trying to cater to a larger market.
>>
>> What foresight!
>
>I think you'll find that the values of pi and e are independent of the
>contingent events of cosmological history (though not of legislative
>history, as is well known).
Heh. You might think so, but pi's definitely curvature-dependent. e they
can't change (unless of course exponential inflation goes horribly wrong)...
>But having G and c and other physical constants be user-installable options
>makes a certain amout of sense, if you want your range of universes to suit
>all tastes.
I can see the calls to G_\mu\nu Tech Support's lines now:
"...it's spelled out VERY clearly in the manual, ma'am! Did you even TRY to
run the constant-selection wizard before setting it off?"
Dave
--
\/David DeLaney posting from d...@vic.com "It's not the pot that grows the flower
It's not the clock that slows the hour The definition's plain for anyone to see
Love is all it takes to make a family" - R&P. VISUALIZE HAPPYNET VRbeable<BLINK>
http://www.vic.com/~dbd/ - net.legends FAQ & Magic / I WUV you in all CAPS! --K.
TMG
> I can see the calls to G_\mu\nu Tech Support's lines now:
RECORDING:
Thank you for calling our support center, your call is important to us.
This call may be monitored for quality assurance. Please stand by for
the next available technician.
ON HOLD MUSIC:
http://interrobang.jwgh.org/songs/hammond.mp3
RECORDING:
Thank you for calling out support center, your call is important to us.
This call may be monitored for..
<thrashing sounds as the headset is put on>
CONFUSED VOICE:
WHAT!? OK,..YEA...
HELL0, I'M THE FAMOUS [HAMMOND] AND I'LL BEE YOUR TECH FOR THIS CALL!!1!
OBVIOUSLY, YOU'RE INCOMPETENT TO TALK TO ME. CITE YOUR CV OR YOU GO INTO
MY KILLFILE!!!1
<screaming heard at someone/thing unknown>
[HAMMOND]
BUT THEY KEEP CALLING AND ASKING QUESTIONS!!!1!!
NO!! I DON'T WANT TO TAKE THOSE MEDS - GET AWAY FROM ME!!
I'LL KILL YOU ALL WHEN I'M POPE!
<sound of blowgun and dart hitting home>
[HAMMOND]
DAMN! THAT STINGS,..
KILL THEM,..kill them all....zzzzz
Roland Hutchinson
> pi's definitely curvature-dependent.
I suppose so, for sufficiently unreasonable definitions of pi.
Andrew Swallow
> On 12 Oct 2006 06:07:25 -0700, Ancient_Hacker <gr...@comcast.net> wrote:
>
>
>> Anybody have any idea why good old FORTRAN had these quirks:
>
>
>> (1) three-way arithmetic IF
>
>> (2) Column-6 as a continuation marker
> The first 4 (5?) colums were for a card sequence number so you could recover
> from dropping a card stack on the floor. THe first available column after
> the sequence number was for the continuation marker.
Columns 73 to 80 were for card sorting. BASIC is the language with
the label on every line. Putting a label on every line in Fortran
uses up the symbol table and switches the optimiser off.
Andrew Swallow
David DeLaney
>David DeLaney wrote:
>> pi's definitely curvature-dependent.
>
>I suppose so, for sufficiently unreasonable definitions of pi.
Well, if you only use REASONABLE definitions, you can't deal with the, er,
corner cases.
Dave 'as it were' DeLaney
sqrfolkdnc
wrote it in machine language (octal?) before the first assembler was
written.
Joe Morris wrote:
>...
Roland Hutchinson
>>(3) Non-significant spaces.
> Why should spaces ever be significant? Modern languages are the same.
> Stick a space anywhere but inside an identifier and it won't make one bit
> of difference.
Fortran let you stick them inside identifiers, too.
Joe Pfeiffer
>
> Heh. You might think so, but pi's definitely curvature-dependent. e they
> can't change (unless of course exponential inflation goes horribly wrong)...
It depends on what pi is. The ratio of the diameter of a circle to
its circumference is curvature-dependant; the sum of a series, and the
value that sort of drops out of integrations every time you turn
around isn't.
Andrew Swallow
> d...@gatekeeper.vic.com (David DeLaney) writes:
>> Heh. You might think so, but pi's definitely curvature-dependent. e they
>> can't change (unless of course exponential inflation goes horribly wrong)...
>
> It depends on what pi is. The ratio of the diameter of a circle to
> its circumference is curvature-dependant; the sum of a series, and the
> value that sort of drops out of integrations every time you turn
> around isn't.
You get more Pi on a 36 bit computer than a 24 bit one. ;
Andrew Swallow
AZ Nomad
>AZ Nomad wrote:
>>>(3) Non-significant spaces.
>> Why should spaces ever be significant? Modern languages are the same.
>> Stick a space anywhere but inside an identifier and it won't make one bit
>> of difference.
>Fortran let you stick them inside identifiers, too.
So?
Roland Hutchinson
> d...@gatekeeper.vic.com (David DeLaney) writes:
>>
>> Heh. You might think so, but pi's definitely curvature-dependent. e they
>> can't change (unless of course exponential inflation goes horribly
>> wrong)...
>
> It depends on what pi is. The ratio of the diameter of a circle to
> its circumference is curvature-dependant; the sum of a series, and the
> value that sort of drops out of integrations every time you turn
> around isn't.
But which is it to be?
Can we decide for our selves, or must we wait indefinitely in hopes that a
Higher Power will send us a sine?
Roland Hutchinson
So Fortran was not the same as modern languages in this respect. That's
all.
It was a source of interesting, or at least legendary bugs.
Rostyslaw J. Lewyckyj
Really?
Rostyslaw J. Lewyckyj
> Joe Morris wrote:
>
>>...
>>
>>And before someone asks, I've never seen the source for the original
>>FORTRAN compiler based on the first version of the language specs.
>>Does anyone know if it's available?
>
> Nobody has ever seen the source, not even the author. Denise Hopper
> wrote it in machine language (octal?) before the first assembler was
> written.
>
Really?
before the first assembler? Wow! :)
Brooks Moses
> Andrew Swallow wrote:
>>Columns 73 to 80 were for card sorting. BASIC is the language with
>>the label on every line. Putting a label on every line in Fortran
>>uses up the symbol table and switches the optimiser off.
>
Somewhere online is a scanned version of the October 15, 1956 IBM manual
entitled "Fortran Automatic Coding System for the IBM 704", which was
pretty much the original public document describing the language.
On page 44 [1], there is a list of the various symbol tables that the
Fortran compiler uses -- there are quite a lot, so "symbol table" is
misleading -- and the first entry is "(TEIFNO Table). The number of
Fortran statements which have statement numbers must not exceed 1500."
As for switching off the optimiser, that presumably was a later version,
as this one is before the compiler was fancy enough that one could
switch it on. :)
- Brooks
[1] Which in the scan is unfortunately repeated in place of page 42.
--
The "bmoses-nospam" address is valid; no unmunging needed.
glen herrmannsfeldt
On 12 Oct 2006 06:07:25 -0700, Ancient_Hacker <gr...@comcast.net> wrote:
> Anybody have any idea why good old FORTRAN had these quirks:
>>>> (1) three-way arithmetic IF
As I understand it, a three way branch instruction on the 704.
> (2) Column-6 as a continuation marker
Statement numbers were up to 32767, so five columns.
The 704 did 16 bit sign magnitude integers or 36 bit floating
point, both in 36 bit words.
(someone else wrote)
>> Columns 73 to 80 were for card sorting. BASIC is the language with
>> the label on every line. Putting a label on every line in Fortran
>> uses up the symbol table and switches the optimiser off.
The 704 read each card row into two 36 bit words, ignoring the last
eight columns. (I would hate to write the code that converted that
into columnwise data.)
Stories are that the first Fortran compiler had a good optimizer.
It was considered necessary to compete with assembler programmers
in code speed. Optimizers I know of know which labels are used and
which aren't, but it might be that not all do that.
October 15th, 1956, 50 years minus one day.
-- glen
David Wade
"Roland Hutchinson" <my.sp...@verizon.net> wrote in message
news:Ee%Xg.6296$cH6.882@trnddc07...
> AZ Nomad wrote:
>
> > On Sat, 14 Oct 2006 05:00:29 GMT, Roland Hutchinson
> > <my.sp...@verizon.net> wrote:
> >
> >
> >>AZ Nomad wrote:
> >
> >>>>(3) Non-significant spaces.
> >>> Why should spaces ever be significant? Modern languages are the same.
> >>> Stick a space anywhere but inside an identifier and it won't make one
> >>> bit of difference.
> >
> >>Fortran let you stick them inside identifiers, too.
> > So?
>
> So Fortran was not the same as modern languages in this respect. That's
> all.
>
> It was a source of interesting, or at least legendary bugs.
>
I don't know of any legendary "bugs". There a lot of things that don't work
as expected, but bugs? I remember being told a long time ago about a local
goverment outfit that bought a 1620 with a plotter. On of the job they used
it for was road re-alignment. I guess that at the time the 1620 was current,
certainly in the UK a lot of the really sharp twists and turns were being
taken out of the roads. (You don't have this so much in the US. One road
near where I was brought up still has four 90 degree twists with runs of 300
to 400 yards between them).
Any way before the 1620 when the wanted to take a kink out the road they put
pins in a map "around" gap they wanted to straighten. They then used a piece
of stiff piano wire to get a nice smooth line across the gap, and thats
where they built the new road. Of course when the 1620 came it used maths to
calculate a cubic spline, and the plotter drew the plan for the road.
Of course, as no doubt you have guessed, because you could not trust these
new fangled computers, they then stuck pins in the output, and stuck a piece
of piano wire on teh map to "check" the computer....
ly...@garlic.com
programming course some 40 yrs ago ... card decks and compiled/run on
709.
however, person involved in doing the 370/145 apl/cms microcode assist
at the palo alto science center was also responsible for the internal
"fortran q" enhancements ... eventually released in the product as
fortran hx.
misc. past references:
http://www.garlic.com/~lynn/2001g.html#20 Golden Era of Compilers
http://www.garlic.com/~lynn/2002g.html#1 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities.
Was Re: Yamhill
http://www.garlic.com/~lynn/2004m.html#6 a history question
when we were doing ecps microcode assist originally for 148 (follow-on
to 145) ... we had modified the kernel to time-stamp a lot of
entry/exits ... which resulted in narrowing initial candidates for
kernel machine code migration to microcode
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
he did a psw/instruction-address sampler microcode modification on the
370/145 ... i.e. microcode routine that would wake up periodically and
use the current instruction address to index a storage use frequency
counter (i.e. divide address by 64, multiple by four, add to base table
address to index a full word counter ... and increment the value at
that location).
later he also did some work on pli optimization.
max
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:z6ydncvxQJD7Oa3Y...@comcast.com...
First exposure to Fortran was FORTRAN V on a CDC 7600, having previously
used PET BASIC. The course notes weren't clear on statement labels, so for
some (smallish) program I put a label on every line, like BASIC, and the
compiler choked. CDC 7600 was early-mid 1970s technology, but I was using it
early 1980s.
William J. Leary Jr.
news:1160801789.6...@k70g2000cwa.googlegroups.com...
> Nobody has ever seen the source, not even the author. Denise Hopper
> wrote it in machine language (octal?) before the first assembler was
> written.
:)
Perhaps Grace Hopper (USN R.Adm., 09-DEC-1906 - 01-JAN-1992)?
Anyway, FORTRAN* was proposed in late 1953 by John Backus at IBM as a more
efficient alternative to assembly language for the 704.
- Bill
____________________
* Initially called "The IBM Mathematical Formula Translating System." Little
wonder they came up with the name "FORTRAN."
Roland Hutchinson
> On Sat, 14 Oct 2006 05:00:29 GMT in alt.folklore.computers, Roland
> Hutchinson <my.sp...@verizon.net> wrote:
>
>>AZ Nomad wrote:
>>
>>>>(3) Non-significant spaces.
>>> Why should spaces ever be significant? Modern languages are the same.
>>> Stick a space anywhere but inside an identifier and it won't make one
>>> bit of difference.
>>
>>Fortran let you stick them inside identifiers, too.
>
> Insignificant anywhere, except inside Hollerith constant counted
> character strings, including inside labels, keywords, and numbers:
> 1 0 0 CO NT IN UE
> DIM ENS ION A( 10 000 )
> 9 9 9 FOR MAT ( 6H Total, 99 F18 .6 )
> C = 299 792 458.
> PI = 3.141 592 653 589 793 238 46
No wth at' swha tIca llco de!
jsa...@ecn.ab.ca
> Anybody have any idea why good old FORTRAN had these quirks:
> (1) three-way arithmetic IF
As noted, the IBM 704 computer had an instruction with a similar
pattern.
> (2) Column-6 as a continuation marker
Indicating continuation at the beginning of the line made the language
partially "fixed-format", making it easier to parse.
> (3) Non-significant spaces.
Clearly, multiple spaces should be equivalent to one space. Somebody
figured that just throwing all the spaces away right at the start would
solve that problem.
> (4) Do loops fall though at least once.
How index instructions worked on the IBM 704, most likely.
> (5) Numeric labels
Given (3), it simplified decoding some statements.
> (6) relatively short limit on identifier length.
6 characters, at 6 bits each, equals one 36-bit IBM 704 word.
John Savard
jsa...@ecn.ab.ca
> Which brings up another curiosity. That FORTRAN parsing ignored all
> characters past the 72th on each line.
> That was justified because characters past the 72nd (73 through 80
> on a card format) were available to use to hold card sequence numbers
> to help maintain punch card deck integrity. The usual scenario was to
> place numbers in those columns that would assist you in reordering
> the card deck if it was misordered (perhaps by accidentally dropping
> it on the floor).
But the reason why those characters *were* available was due to the IBM
704 reading cards in row binary format. So it was easier to just read
each row of cards as 72 holes in two 36-bit words, and just ignore the
last eight characters - which could then be used for this useful
purpose.
John Savard
jsa...@ecn.ab.ca
> Adam Funk wrote:
> > On 2006-10-13, Larry__Weiss <l...@airmail.net> wrote:
> >
> >>> The primary purpose of the DATA statement is to give names to
> >>> constants; instead of referring to pi as 3.141592653589793 at
> >>> every appearance, the variable PI can be given that value with
> >>> a DATA statement and used instead of the longer form of the
> >>> constant. This also simplifies modifying the program, should
> >>> the value of pi change.
> >>> -- FORTRAN manual for Xerox Computers
> >
> >> You and I probably know what that technical writer was trying to
> >> say!
> >
> > I've always thought that passage was meant to be funny.
>
> No, it should be perfectly serious. The so-called fixed constants
> of the universe were determined at the time of the big-bang,
> setting G, C, PI, e, Avogadros number, etc. Other universes could
> easily have slightly differing values, and it may be quite
> determinant whether or not it will expand forever. For all you
> know in that universe those could all be rational values. Xerox
> was simply trying to cater to a larger market.
G, c, and the fine-structure constant (alpha) may well be different in
other universes where the laws of physics are different.
Avogadro's number is simply how many hydrogen atoms weigh one gram, and
thus it is different in countries that don't use the metric system.
Pi (the circle ratio), e (the base of the natural logarithms), and
gamma (Euler's constant), however, are mathematical constants. Their
values are derived from the basic rules of logic, and are the same
everywhere.
This doesn't exclude the possibility of circles existing whose
circumference is less than pi times their diameter, in Riemannian
space, but then the physical ratio is size-dependent, and our
mathematical constant of pi would still be important as the limiting
ratio for infinitesimally small circles.
Also, it doesn't exclude the possiblity of another culture considering
"gnorpl" to be the fundamental mathematical constant, where gnorpl is
either 2 times pi, or pi over 2, instead of using pi.
Thus, we don't have to worry about the value of pi changing - unless,
of course, we port our FORTRAN program to a different machine, and wish
to use a constant that approximates pi to a different number of digits
(as has already been noted as a possibility in this thread).
John Savard
jsa...@ecn.ab.ca
Nick Spalding wrote:
> Adam Funk wrote, in <dtk404-...@news.ducksburg.com>
> on Fri, 13 Oct 2006 15:37:01 +0100:
>
> >On 2006-10-13, Larry__Weiss <l...@airmail.net> wrote:
> >
> >>> The primary purpose of the DATA statement is to give names to constants;
> >>> instead of referring to pi as 3.141592653589793 at every appearance, the
> >>> variable PI can be given that value with a DATA statement and used instead
> >>> of the longer form of the constant. This also simplifies modifying the
> >>> program, should the value of pi change.
> >>> -- FORTRAN manual for Xerox Computers
> >
> >> You and I probably know what that technical writer was trying to say!
> >
> >I've always thought that passage was meant to be funny.
>
No, you certainly are not. Even *if*, as someone noted, one might well
add a digit or two to the representation of pi if one ported the
program to a computer with 72-bit double precision or something like
that, I absolutely agree that this was an attempt at somewhat dry
humor.
John Savard
jsa...@ecn.ab.ca
> Interestingly, although the IBM 704 and successors had a CAS
> instruction that sort of did a 3-way branch (compare AC with
> the addressed location; don't skip, skip 1 or skip 2 instructions according
> to whether AC was >, =, < location) this wasn't used. The reason
> was that +0 on a sign-magnitude machine was for purposes of CAS
> greater than -0 (not equal), and this didn't work out for the 3-way IF.
>
> So I guess that the 3-way IF was mentally suggested by the hardware, not
> taken advantage of.
Interesting.
There *was* another reason for a three-way branch, though, besides
having a CAS instruction.
If one assumes the programmer will ensure the expression in the IF
statement doesn't overflow, a three way branch covers all the cases
with one form of statement. There is no need to define a family of
operators - .EQ. .LT. .NE. .GT. .LE. and .GE. - to cover six different
comparison tests.
John Savard
Rostyslaw J. Lewyckyj
> On Sat, 14 Oct 2006 05:00:29 GMT in alt.folklore.computers, Roland
> Hutchinson <my.sp...@verizon.net> wrote:
>
>
>>
>>
>>>>(3) Non-significant spaces.
>>>
>>>Why should spaces ever be significant? Modern languages are the same.
>>>Stick a space anywhere but inside an identifier and it won't make one bit
>>>of difference.
>>
>>Fortran let you stick them inside identifiers, too.
>
>
> character strings, including inside labels, keywords, and numbers:
> 1 0 0 CO NT IN UE
> DIM ENS ION A( 10 000 )
> 9 9 9 FOR MAT ( 6H Total, 99 F18 .6 )
> C = 299 792 458.
> PI = 3.141 592 653 589 793 238 46
>
Usually the installation options (of the library ?)
were set to convert/interpret unpunched columns
(within data fields) to/as zeroes.
So READ(5,100)IAX
1 0 0 FORMAT(I3)
would read a card punched 11b i.e. one one blank
in cols. 1-3 , as 110, and 1b1 as 101 etc.
Rostyslaw J. Lewyckyj
Replace "pi" by a different (neutral) variable name and the specific
numeric value by some other number, and then reread!
I believe that the misdirection of the readers attention is the
embedded slyness of the humor.
--
Rostyk
pete
>
> d...@gatekeeper.vic.com (David DeLaney) writes:
> >
> > Heh. You might think so,
> > but pi's definitely curvature-dependent. e they
> > can't change (unless of course exponential
> > inflation goes horribly wrong)...
>
> It depends on what pi is. The ratio of the diameter of a circle to
> its circumference is curvature-dependant; the sum of a series, and the
> value that sort of drops out of integrations every time you turn
> around isn't.
#include <float.h>
double fs_pi(void)
{
unsigned n;
double p, a, b;
p = 0;
n = 1;
a = 3;
do {
a /= 9;
b = a / n;
n += 2;
a /= 9;
b -= a / n;
n += 2;
p += b;
} while (b > DBL_EPSILON / 4);
n = 1;
a = 2;
do {
a /= 4;
b = a / n;
n += 2;
a /= 4;
b -= a / n;
n += 2;
p += b;
} while (b > DBL_EPSILON / 2);
return 4 * p;
}
--
pete
Charlie Gibbs
(Roland Hutchinson) writes:
> Joe Pfeiffer wrote:
>
>> d...@gatekeeper.vic.com (David DeLaney) writes:
>>
>>> Heh. You might think so, but pi's definitely curvature-dependent.
>>> e they can't change (unless of course exponential inflation goes
>>> horribly wrong)...
>>
>> It depends on what pi is. The ratio of the diameter of a circle to
>> its circumference is curvature-dependant; the sum of a series, and
>> the value that sort of drops out of integrations every time you turn
>> around isn't.
>
> But which is it to be?
>
> Can we decide for our selves, or must we wait indefinitely in hopes
> that a Higher Power will send us a sine?
This thread is going off on a tangent.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
CBFalconer
> AZ Nomad wrote:
>>
>>> Anybody have any idea why good old FORTRAN had these quirks:
>>
>>> (1) three-way arithmetic IF
>>>
>>
>> could recover from dropping a card stack on the floor. THe first
>> available column after the sequence number was for the
>> continuation marker.
>
> with the label on every line. Putting a label on every line in
> Fortran uses up the symbol table and switches the optimiser off.
Actually other uses were possible, and not only with cards.
PascalP had a configurable line length limit, and anything past
that was treated as comment. Very handy for keeping version
revision information. Of course that bloated the source files,
because it meant lines needed to be padded out to the line limit
with blanks.
--
"I don't know where bin Laden is. I have no idea and really
don't care. It's not that important." - G.W. Bush, 2002-03-13
"No, we've had no evidence that Saddam Hussein was involved
with September the 11th." - George Walker Bush 2003-09-17
CBFalconer
> d...@gatekeeper.vic.com (David DeLaney) writes:
>
>> Heh. You might think so, but pi's definitely curvature-dependent.
>> e they can't change (unless of course exponential inflation goes
>> horribly wrong)...
>
> It depends on what pi is. The ratio of the diameter of a circle
> to its circumference is curvature-dependant; the sum of a series,
> and the value that sort of drops out of integrations every time
> you turn around isn't.
Now lets get to the values of the various alephs and their
relationships to pi and e.
Roland Hutchinson
> Joe Pfeiffer wrote:
>> d...@gatekeeper.vic.com (David DeLaney) writes:
>>
>>> Heh. You might think so, but pi's definitely curvature-dependent.
>>> e they can't change (unless of course exponential inflation goes
>>> horribly wrong)...
>>
>> It depends on what pi is. The ratio of the diameter of a circle
>> to its circumference is curvature-dependant; the sum of a series,
>> and the value that sort of drops out of integrations every time
>> you turn around isn't.
>
> Now lets get to the values of the various alephs and their
> relationships to pi and e.
They're a good deal larger, and won't even fit in a doubleword.
jsa...@ecn.ab.ca
> CBFalconer wrote:
> > Now lets get to the values of the various alephs and their
> > relationships to pi and e.
> They're a good deal larger, and won't even fit in a doubleword.
Quite true. Only aleph-null is sometimes dignified with a NaN code that
can represent it.
While there is no particular connection between the alephs and pi and
e...
of course there are aleph-null digits in pi, and thus the number of
possible real numbers is 2^(aleph-null). This number may be aleph-one,
but that it is constitutes the unproven "continuum hypothesis".
http://www.quadibloc.com/math/infint.htm
John Savard
Roland Hutchinson
> Roland Hutchinson wrote:
>> CBFalconer wrote:
>> > Now lets get to the values of the various alephs and their
>> > relationships to pi and e.
>
>> They're a good deal larger, and won't even fit in a doubleword.
>
> Quite true. Only aleph-null is sometimes dignified with a NaN code that
> can represent it.
>
> While there is no particular connection between the alephs and pi and
> e...
'Course there is:
aleph[-e^pi*i] = c
is the continuum hypothesis.
jsa...@ecn.ab.ca
> Has anyone informed the BBC's editors? witness:
>
> http://news.bbc.co.uk/1/hi/world/europe/3187560.stm
Here's another example:
http://us.imdb.com/title/tt0070289/
The "Final Programme" of the movie, based (apparently loosely) on one
of Michael Moorcock's Jerry Cornelius novels, *was* a computer program.
John Savard
Gene Wirchenko
[snip]
>Stories are that the first Fortran compiler had a good optimizer.
>It was considered necessary to compete with assembler programmers
>in code speed. Optimizers I know of know which labels are used and
So I understand.
>which aren't, but it might be that not all do that.
I assume that it was this (or something similar):
Limited storage was an issue. There could be backwards
references, so the compiler could not know that a label would not be
used until it had read the whole source or at least a whole module.
Either that, or another pass would be needed. Due to the limited
storage, that might not have been possible either.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Richard Steiner
CBFalconer <cbfal...@yahoo.com> spake unto us, saying:
>Andrew Swallow wrote:
>
>> Columns 73 to 80 were for card sorting. BASIC is the language
>> with the label on every line. Putting a label on every line in
>> Fortran uses up the symbol table and switches the optimiser off.
>
>Actually other uses were possible, and not only with cards.
Absolutely. The Unisys OS2200 mainframe world tends to use those
columns to store Change Number information, usually the actual CCF
number associated with a change image (the OS2200 rough equivalant
of a UNIX "diff" file).
I also tend to flag informal changes (things not formally submitted to
change control yet) with my initals and the date, and I've altered my
text editor of choice on that platform to automatically insert such a
string when I change anything in a file.
Very nice when I need to find out when a change was made and if I was
the one who did it, or when I simply need to quickly locate where I was
in a large program I've not worked on for a few days.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night.
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
Roland Hutchinson
> Roland Hutchinson wrote:
>> CBFalconer wrote:
>> > Now lets get to the values of the various alephs and their
>> > relationships to pi and e.
>
>> They're a good deal larger, and won't even fit in a doubleword.
>
> Quite true. Only aleph-null is sometimes dignified with a NaN code that
> can represent it.
A IEEE 754-style NaN (or, better, Inf, which isn't considered a NaN properly
speaking) doesn't represent aleph-null very well at all, inasmuch as
2 ^ NaN = NaN
and
2 ^ Inf = Inf
but
2 ^ Aleph-null > Aleph-null
It is important not to conflate the notion of transfinite cardinal with the
"ordinary" sort of infininity -- sometimes called "potential infinity" --
used in analysis (informally at first, and then replaced with a rigorous
definition in terms of limits in the 19th century) and related notions in
geometry and (as above) numerical analysis.