madbodger: While reading a book on Perl, I realized

Spam (

madbodger) wrote,
@ 2008-02-08 15:32:00

Current location:	Herndon
Current mood:	geeky
Current music:	office chatter
Entry tags:	fortran, programming

While reading a book on Perl, I realized something about ForTran. Of course, I may be wrong, but I think I'm right. In ForTran, a statement like this is valid:

4 = 3

After executing that statement if you use 4 for something, it has the value of 3. People explained this to me, with much giggling, saying ForTran would let you change the value of 4. I now suspect this isn't strictly true (for one thing, 41 still has the expected value). I think this is just an instance of ForTran's habit of creating variables whenever something is referenced as a variable. If you call COLOR(MAGENT) by mistake when trying to set the color to magenta, and your program doesn't have a variable named MAGENT, ForTran will helpfully create a variable by that name, and initialize it to zero for you. A variant of that happened to me once while programming a Silicon Graphics machine, due to the fact that some of the code had been compiled on a version of ForTran that truncated variable names to six characters. As zero equated to black, my lovely double-buffered rotating 3-D Gouraud shaded figures were completely invisible.

But I digress.

What's really happening in the 4 = 3 statement is that ForTran sees me using the symbol 4 as a variable. It obediently creates a variable named "4" and assigns it a value of 3. Then, when you refer to 4, you get that variable, which shadows the original integer 4.

When I was little, my mom (who was a math teacher) instilled in me the differences between numbers, digits, and chalk dust. These differences are subtle but real, and occasionally come up and bite the unwary. When I got into typography, and added concepts of letters, characters, and glyphs, they fit right into the pantheon.

(Post a new comment)

	whc 2008-02-08 08:44 pm UTC (link)
	I remember hearing about this feature a long time ago. I think it may have been that way in FORTRAN 2, but was fixed for FORTRAN 4. (Reply to this)(Thread)

heptadecagram
2008-02-08 09:44 pm UTC (link)

When I was merrily programming in FORTRAN77, this sort of chicanery was not possible.

(Reply to this)(Parent)

	n5red 2008-02-08 08:49 pm UTC (link)
	Actually, I don't think it is legal to start a variable name with a digit in Fortran. The way the usual "4 = 3" situation happened was when a subroutine was called with a constant and it modified the argument. This also required doing a call by reference, which not all compilers did. (Reply to this)

	dcseain 2008-02-08 09:00 pm UTC (link)
	Numbers are indeed digits not, and chalk dust is other yet. Letters, characters, glyphs, phonemes, digraphs, diphthongs... (Reply to this)

	red_lynx 2008-02-08 09:43 pm UTC (link)
	Yes, Perl is so strange. I haven't had to use it of late. So, why were you reading a book on it? I thought you had a Perl allergy. (Reply to this)

	deguspice 2008-02-08 10:09 pm UTC (link)
	I remember a program a friend wrote in Pascal that began with Temp = TRUE; TRUE = FALSE; FALSE= Temp; It got worse from there. ---------- "ForTran will helpfully create a variable by that name, and initialize it to zero for you." While taking Fortran as a class, I learned the importance of asking the compiler to generate a list variables to catch my typos. (Reply to this)

	quietann 2008-02-08 10:42 pm UTC (link)
	You may know that SAS is Fortran based. One of the reasons I am reasonably competent as a SAS programmer (as opposed to anything else) is that I took to Fortran readily in high school, when I had a Fortran class. I've never seen this sort of weird shit before; I'll have to try it out sometime! It takes a lot to break SAS, but this might do it... /evil laugh (Reply to this)(Thread)

	scruffycritter 2008-02-09 04:16 am UTC (link)
	I've done this in fortran, but via a parameter pass. See example below. Edited at 2008-02-09 04:17 am UTC (Reply to this)(Parent)

	beaq 2008-02-08 10:59 pm UTC (link)
	That puts an interesting spin on the line "Back when Fortran was not even Three-tran" in the song "When I Was a Boy". (Reply to this)

scruffycritter
2008-02-09 04:15 am UTC (link)

I thought you had to do that by reference pass because you couldn't declare a variable name that began with a digit.

You'd pass a constant into a method (say, 3). If you would increment the variable you got passed in, afterward you would find that all instances of the constant 3 would be equal to 4.

The better FORTRAN story is the one where someone said (and excuse my bad fortran syntax, it's been a while)

The attempt was to say:

DO 10 I=1,5
:code:
10 :something:

This is a simple do loop that executes 5 times. Alas, what the poor programmer typed was:

DO 10 I=1.5
:code:
10 :something:

Which believe it or not was still pefectly legal FORTRAN syntax.

By default, variable names beginning with the range included with the letter D are implicitly defined as floating points.

So the first line got parsed as the simple assignment statement of:

DO10I = 1.5

The story my Comp Sci professor told me was this mistake resulted in a NASA range safety officer having to destroy a launch vehicle downrange.

After that, they started using the compiler directive option to require all variable names to be explicitly declared.

(Reply to this)

	smashingstars 2008-02-09 04:32 am UTC (link)
	I have no idea what you're talking about here. Math is hard. Anyhow, ages ago you asked me for a link to eBay's page about their changes, and finally I found it here. You probably found it first, but I've been a bit incapacitated. (Reply to this)

Mini Sitemap:

Username:		Create an Account Forgot your login? Login w/ OpenID
Password:
	Remember Me
	English • Español • Deutsch • Русский…