Home > Archive > Fortran > September 2005 > Why is Fortran not case-sensitive?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why is Fortran not case-sensitive?
|
|
| SC Huang 2005-09-20, 7:02 pm |
| Hi,
I am wondering if there is a good reason why Fortran is not
case-sensitive.
I have to admit that I personally cannot think of strong enough
reasons to justify why Fortran should be case-sensitive
either. Although I am happy with the current Fortran standard, it
seems to me (sometimes) that being case-sensitive (like C) makes the
language more "strict" to avoid potential errors/bugs.
I appreciate any comments on this. Thanks.
SC
| |
| Michael Metcalf 2005-09-20, 7:02 pm |
|
"SC Huang" <schuang21@yahoo.com> wrote in message
news:dgpg87$6b9$1@daisy.noc.ucla.edu...
> Hi,
>
> I am wondering if there is a good reason why Fortran is not
> case-sensitive.
>
You have to think historically when posing such questions. Back in 1957
there was no such thing as case in programming languages. In the era of
punched cards everything was upper case. Lower-case letters were added to
the Fortran character set only in Fortran 90 (1991), and then only with the
same interpretation as upper case, except in character constants, because
some compilers had already started with that convention. Note that devices
such as key punches and early printers had no concept of lower case. In
fact, the first text processing system I ever saw (but didn't use) was BARB
and it had only upper case. BARB ASCII was a great breakthrough (see
http://goossens.home.cern.ch/goosse...istcnl2001.html).
Hope that helps,
Mike Metcalf
| |
| Richard E Maine 2005-09-20, 7:02 pm |
| In article <dgpg87$6b9$1@daisy.noc.ucla.edu>,
SC Huang <schuang21@yahoo.com> wrote:
> I am wondering if there is a good reason why Fortran is not
> case-sensitive.
Yes. :-)
> seems to me (sometimes) that being case-sensitive (like C) makes the
> language more "strict" to avoid potential errors/bugs.
This is a highly controversial and oft-debated subject. I do *NOT*
intend to make any further replies to this thread after this one posting
because the subject is flame-prone and I see no benefit to be gained
from an extensive rediscussion of it. I will briefly mention my opinion,
but I will not attempt to defend it.
In my opinion, you have it exactly backwards in that I think it is
highly error-prone to depend on case alone to distinguish identifiers.
It fails the "telephone test" to have 2 different variables named N and
n. The telephone test is being able to correctly read code to someone
over the telephone without resorting to spelling it out. I think that
failing the that test is an indication of bug-proneness. It is also a
very practical matter in terms of actually trying to help people debug
code over the phone, as I have done more than once. By phone is never a
nice way to do that, but some languages exacerbate the problem.
Now if the language required case consistency, that I could see. That
is, I could see it as reasonable that if you spelled the variable name
as N in one place, you better not spell it as n in another. But a
requirement for case consistency is *NOT AT ALL* what C has. C has case
sensitivity, which is very, very different in terms of error potential
in my opinion. C allows you to have N and n as different variables. You
will never convince me that this helps avoid bugs. You won't even
convince me that it is neutral. It is just plain bug-prone in my rather
strong opinion.
If you think that, well, case consistency is sort of like the way C does
it and that's what you were thinking of, then I'll claim you haven't
thought through the error potential issues very thoroughly because I
claim the distinction is pretty fundamental and that the two schemes are
not even close in terms of error potential.
As a historical note, realize that early versions of Fortran often ran
on machines that didn't have 2 cases. Admittedly, that doesn't
necessarily answer the question because the language could have been
compatibly extended in any of several ways in regard to case. But the
historical issues can't be entirely neglected.
--
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
| |
| Gordon Sande 2005-09-20, 7:02 pm |
| On 2005-09-20 14:17:59 -0300, SC Huang <schuang21@yahoo.com> said:
> Hi,
>
> I am wondering if there is a good reason why Fortran is not
> case-sensitive.
> I have to admit that I personally cannot think of strong enough
> reasons to justify why Fortran should be case-sensitive
> either. Although I am happy with the current Fortran standard, it
> seems to me (sometimes) that being case-sensitive (like C) makes the
> language more "strict" to avoid potential errors/bugs.
>
> I appreciate any comments on this. Thanks.
>
> SC
Rather than preventing bugs, case sensitivity allows for a new creative
class of bugs. When was the last time you tried to debug a program from
a listing over the phone and had to separate time, TIME and Time? You
do not even need a telephone in the middle as even trying to discuss
the program with another person will be made much more difficult if
case is important in identifiers. Think about someone trying to read
documentation to you either over the phone or just over a cubicle
partition. Good luck!
History also says that in the beginning there was upper case and there
was no discussion of anything else. Permitting mixed case is a "new"
innovation for Fortran. Figure out why old programs are called dusty
decks and you will uunderstand some of the history. As a hint, they
are called punch cards and the O26 keypunch only had upper case back
when BCD characters were represented in 6 bits.
| |
| beliavsky@aol.com 2005-09-20, 7:02 pm |
| Richard E Maine wrote:
> Now if the language required case consistency, that I could see. That
> is, I could see it as reasonable that if you spelled the variable name
> as N in one place, you better not spell it as n in another.
I think that F (a Fortran 95 subset) requires case consistency. I
wonder if g95 enforces this restriction in F mode. (My Fortran 95 code
would flunk the F mode for other reasons.)
It's  that in comp.lang.fortran that there are people who remember
the days when lower case letters were a computing "luxury", that there
are people who are experts on Fortran 2003, and that the sets overlap
:).
| |
| SC Huang 2005-09-20, 7:02 pm |
| Thanks for the comments. I want to make it very clear that I had no
intension to start any flame war (or some "Fortran vs C debate") for
this. Seriously! (I will search deeper into previous posts before
posting next time.)
Actually, the case insensitivity of Fortran does not really bother
me. (Even if it bothers me, other goods things of Fortran make it
impossible to convince me to switch to another language. :-)) The
_only_ "problem" I had occasionally is that I may miss a variable in
somewhere in the code when launching a case-sensitive search (e.g. n
is written as N in other places), or forget to put "-i" when using the
"grep" command. In those moments, I had the half-second thought that
if each variable is written strickly only in one way (such as "Nproc")
then it may be easier to be found. Of course, things like "implicit
none" or good programming approach may reduce/avoid what I called
"potential errors". Maybe the way I called it in the previous post is
misleading? :-P
Anyway, thanks for your comments. All points taken. :-)
SC
On 2005-09-20, Richard E Maine <nospam@see.signature> wrote:
> In article <dgpg87$6b9$1@daisy.noc.ucla.edu>,
> SC Huang <schuang21@yahoo.com> wrote:
>
>
> Yes. :-)
>
>
> This is a highly controversial and oft-debated subject. I do *NOT*
> intend to make any further replies to this thread after this one posting
> because the subject is flame-prone and I see no benefit to be gained
> from an extensive rediscussion of it. I will briefly mention my opinion,
> but I will not attempt to defend it.
>
> In my opinion, you have it exactly backwards in that I think it is
> highly error-prone to depend on case alone to distinguish identifiers.
>
> It fails the "telephone test" to have 2 different variables named N and
> n. The telephone test is being able to correctly read code to someone
> over the telephone without resorting to spelling it out. I think that
> failing the that test is an indication of bug-proneness. It is also a
> very practical matter in terms of actually trying to help people debug
> code over the phone, as I have done more than once. By phone is never a
> nice way to do that, but some languages exacerbate the problem.
>
> Now if the language required case consistency, that I could see. That
> is, I could see it as reasonable that if you spelled the variable name
> as N in one place, you better not spell it as n in another. But a
> requirement for case consistency is *NOT AT ALL* what C has. C has case
> sensitivity, which is very, very different in terms of error potential
> in my opinion. C allows you to have N and n as different variables. You
> will never convince me that this helps avoid bugs. You won't even
> convince me that it is neutral. It is just plain bug-prone in my rather
> strong opinion.
>
> If you think that, well, case consistency is sort of like the way C does
> it and that's what you were thinking of, then I'll claim you haven't
> thought through the error potential issues very thoroughly because I
> claim the distinction is pretty fundamental and that the two schemes are
> not even close in terms of error potential.
>
> As a historical note, realize that early versions of Fortran often ran
> on machines that didn't have 2 cases. Admittedly, that doesn't
> necessarily answer the question because the language could have been
> compatibly extended in any of several ways in regard to case. But the
> historical issues can't be entirely neglected.
>
LocalWords: rediscussion
| |
| Richard E Maine 2005-09-20, 7:02 pm |
| In article <dgpl93$9qe$1@daisy.noc.ucla.edu>,
SC Huang <schuang21@yahoo.com> wrote:
> The
> _only_ "problem" I had occasionally is that I may miss a variable in
> somewhere in the code when launching a case-sensitive search
Sounds to me like case consistency would answer that need as well as
case sensitivity.
In case the distinction wasn't made clear (and in retrospect I'm not
sure I stated it well), case consistency would require that your nProc
must always be written the same way, so your grep would work without the
-i. But it would not allow you to also have a different variable named,
for example, NProc. Case sensitivity would allow both variables to exist
and be different. Case insensitivity allows both spellings of the same
variable.
--
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
| |
| Gordon Sande 2005-09-20, 7:02 pm |
| On 2005-09-20 15:43:47 -0300, SC Huang <schuang21@yahoo.com> said:
> The
> _only_ "problem" I had occasionally is that I may miss a variable in
> somewhere in the code when launching a case-sensitive search (e.g. n
> is written as N in other places), or forget to put "-i" when using the
> "grep" command.
Ask your local Unix guru how to set up an alias so that the -i is there
by default. Then your grep would work like most programmers editors
where you select whether case matters and the selection sticks.
| |
|
|
| glen herrmannsfeldt 2005-09-20, 7:02 pm |
| Gordon Sande wrote:
>(snip regarding case sensitivity, or lack thereof)
> History also says that in the beginning there was upper case and there
> was no discussion of anything else. Permitting mixed case is a "new"
> innovation for Fortran. Figure out why old programs are called dusty
> decks and you will uunderstand some of the history. As a hint, they
> are called punch cards and the O26 keypunch only had upper case back
> when BCD characters were represented in 6 bits.
The 026 didn't even have many useful characters, if I remember ( and )
had to be multipunched. Or maybe it was < and >. Places I used to know
with 026 had a big chart on the wall with multipunch combinations.
The 029 doesn't have lower case, but it could easily be multipunched
if one wanted it.
I believe the 129 does, but I didn't use one very many times.
In the days of 1403 printers, and probably others, it was usual to map
lower case to upper case on the printer. Older compilers wouldn't
recognize lower case at all, causing strange error messages for what
looked like correct code. JCL also requires upper case, as far as
I know that is still true.
-- glen
| |
| Gordon Sande 2005-09-20, 7:02 pm |
| On 2005-09-20 17:26:10 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
> The 026 didn't even have many useful characters, if I remember ( and )
> had to be multipunched. Or maybe it was < and >. Places I used to know
> with 026 had a big chart on the wall with multipunch combinations.
O26s and Fortran II were a good match. Think BCD. If ( and ) had to
be multipunched then every one I saw must have been a custom unit
as I have never seen that happen.
The O29 had more characters like & (ampersand) and more brackets,
braces and such. Good for PL/I. Think EBCDIC.
PL/I on an O26 would probably be a big nuisance.
| |
| Duane Bozarth 2005-09-20, 7:02 pm |
| Gordon Sande wrote:
>
> On 2005-09-20 17:26:10 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
> O26s and Fortran II were a good match. Think BCD. If ( and ) had to
> be multipunched then every one I saw must have been a custom unit
> as I have never seen that happen.
>
> The O29 had more characters like & (ampersand) and more brackets,
> braces and such. Good for PL/I. Think EBCDIC.
>
> PL/I on an O26 would probably be a big nuisance.
http://www.columbia.edu/acis/history/026.html
"... As you can see, the symbols are designed primarily for accounting
and statistics, and are not sufficient for programming languages such as
Fortran. BCDIC includes the 26 uppercase Roman letters, the 10 digits
0-9, and 11 special characters: Ampersand (&), Period (.), Lozenge (?),
Minus sign (-), Dollar sign ($), Asterisk (*), Slash (/), Comma (,),
Percent sign (%), Number sign (#), and Commercial At Sign (@). Later
versions of BCDIC (and 026 key punch models, interpreters, etc) allowed
for programming by replacing some of the special characters by Plus
Sign, Parentheses, and so on."
I gather all I ever saw were specialized units as well from this
(assuming it's correct, of course)...
| |
| glen herrmannsfeldt 2005-09-20, 7:02 pm |
| Gordon Sande wrote:
(snip)
> The O29 had more characters like & (ampersand) and more brackets,
> braces and such. Good for PL/I. Think EBCDIC.
> PL/I on an O26 would probably be a big nuisance.
My first programs were in ALGOL on a B5500 when I was about 9,
and punched on an 026. Mulitpunch for special characters was
just one of the things you get used to doing.
-- glen
| |
| Clive Page 2005-09-20, 7:02 pm |
| In message <1127241068.380303.245390@f14g2000cwb.googlegroups.com>,
beliavsky@aol.com writes
>It's that in comp.lang.fortran that there are people who remember
>the days when lower case letters were a computing "luxury", that there
>are people who are experts on Fortran 2003, and that the sets overlap
Upper-case letters! Sheer luxury. In my day we only had digits (and
not all of them mind, just 0 and 1). :-)
(with apologies to Monty Python).
--
Clive Page
| |
| Walt Brainerd 2005-09-20, 7:03 pm |
| beliavsky@aol.com wrote:
> Richard E Maine wrote:
>
>
>
>
> I think that F (a Fortran 95 subset) requires case consistency. I
> wonder if g95 enforces this restriction in F mode. (My Fortran 95 code
> would flunk the F mode for other reasons.)
Interesting point. The rules of F do require case
consistency. Now that F is based on the NAG compiler,
I have found it almost impossible to enforce the rule
(so it is not enforced with the current implementations).
The reason is that one of the very first things the
NAG compiler does is transform everything to uppercase
(except in character context, of course).
I have kept the rule in the hope that some day
it could be enforced. I haven't asked Andy how hard
that would be to do with -std=F in g95, but I will.
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com
| |
| mcalhoun@ksu.edu 2005-09-21, 3:56 am |
| >>I am wondering if there is a good reason why Fortran is not case-sensitive.
[color=darkred]
>History also says that .... As a hint, they are called punch cards and
>the O26 keypunch only had upper case....
And don't forget that the 024 (the non-printing keypunch) didn't even show
those characters!
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
| |
| mcalhoun@ksu.edu 2005-09-21, 3:56 am |
| >>The _only_ "problem" I had occasionally is that I may miss a variable in
[color=darkred]
>Ask your local Unix guru how to set up an alias so that the -i is there
>by default....
While you are at it, set your editor for default case INsensitivity, too.
I use VI or VIM (VI IMproved), and the command is ":set ignorecase" (or
":set ic", for those who like abbreviations), either of which can be typed
while "in" the editor or placed in an initialization file.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
| |
| Leif Harcke 2005-09-21, 3:56 am |
| On Tue, 20 Sep 2005 22:38:43 +0100, Clive Page wrote:
> In message <1127241068.380303.245390@f14g2000cwb.googlegroups.com>,
> beliavsky@aol.com writes
>
> Upper-case letters! Sheer luxury. In my day we only had digits (and
> not all of them mind, just 0 and 1). :-)
You were lucky to have 1's! We used to dream of having 1's. We had
it tough -- we had to code using all 0's. But you try and tell the young
people of today that... and they won't believe you.
-Leif
| |
|
| Clive Page wrote in message <9VZ9+WOjFIMDJwom@page.demon.co.uk>...
>In message <1127241068.380303.245390@f14g2000cwb.googlegroups.com>,
>beliavsky@aol.com writes
>
>Upper-case letters! Sheer luxury. In my day we only had digits (and
>not all of them mind, just 0 and 1). :-)
Just 0 and 1 ? Sheer luxury! In my day we had only voltages
(present or not).
>(with apologies to Monty Python).
>--
>Clive Page
| |
|
| Gordon Sande wrote in message < 2005092015163716807%gsande@worldnetattne
t>...
>On 2005-09-20 14:17:59 -0300, SC Huang <schuang21@yahoo.com> said:
>
>Rather than preventing bugs, case sensitivity allows for a new creative
>class of bugs. When was the last time you tried to debug a program from
>a listing over the phone and had to separate time, TIME and Time? You
>do not even need a telephone in the middle as even trying to discuss
>the program with another person will be made much more difficult if
>case is important in identifiers. Think about someone trying to read
>documentation to you either over the phone or just over a cubicle
>partition.
This is no big deal. It's done all the time in the typesetting
industry, during proof reading. The original text is read out aloud
by one person, while a second person reads the typeset material.
At no time is the original text seen by the proof reader. It would be
exactly the same over a telephone.
| |
|
| Gordon Sande wrote in message < 2005092017405016807%gsande@worldnetattne
t>...
>On 2005-09-20 17:26:10 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
>O26s and Fortran II were a good match. Think BCD. If ( and ) had to
>be multipunched then every one I saw must have been a custom unit
>as I have never seen that happen.
>
>The O29 had more characters like & (ampersand) and more brackets,
>braces and such. Good for PL/I. Think EBCDIC.
>
>PL/I on an O26 would probably be a big nuisance.
Actually no, because PL/I permitted a 48-character set
(a la 026) as well as a 60 character set having all the special
character such as > < ; | # @ ^ etc.
The S/360 line printer (1966) had several print trains,
one of which handled upper and lower case, and we used
upper and lower case in some PL/I programs.
| |
|
| From: Michael Metcalf <michaelmetcalf@compuserve.com>
Date: Wednesday, 21 September 2005 3:47
>You have to think historically when posing such questions. Back in 1957
>there was no such thing as case in programming languages. In the era of
>punched cards everything was upper case. Lower-case letters were added to
>the Fortran character set only in Fortran 90 (1991), and then only with the
>same interpretation as upper case, except in character constants, because
>some compilers had already started with that convention.
Isn't there more to it than that?
Fortran being developed in America by IBM on and for its punch card equipment,
the character set was restricted to what was available on the
(026 or earlier) card punch and tabulator equipment.
In Europe, Algol came along in 1958 and 1960, and
provided upper and lower case, and special characters.
Implementations of the language used teleprinter equipment
which had extra characters. Some Algol compilers used upper case
only (limited by some line printers of the time which were geared
for commercial use).
> Note that devices
>such as key punches and early printers had no concept of lower case.
Lower case printers were certainly around in the 1970s and probably
the 1960s. I have an idea that the 1960s Friden flexowriter (often used for
Algol) had upper and lower case.
> In fact, the first text processing system I ever saw (but didn't use) was BARB
>and it had only upper case. BARB ASCII was a great breakthrough (see
>http://goossens.home.cern.ch/goosse...istcnl2001.html).
>
>Hope that helps,
>
>Mike Metcalf
| |
| J.F. Cornwall 2005-09-21, 7:00 pm |
| robin wrote:
> Gordon Sande wrote in message < 2005092015163716807%gsande@worldnetattne
t>...
>
>
>
> This is no big deal. It's done all the time in the typesetting
> industry, during proof reading. The original text is read out aloud
> by one person, while a second person reads the typeset material.
> At no time is the original text seen by the proof reader. It would be
> exactly the same over a telephone.
>
>
That works so long as every time an uppercase letter is encountered the
person reading it out says it is uppercase... If the case is not
specified, voila you have a potential bug.
Jim
| |
| Gordon Sande 2005-09-21, 7:00 pm |
| On 2005-09-21 11:48:55 -0300, "robin" <robin_v@bigpond.com> said:
> Gordon Sande wrote in message < 2005092015163716807%gsande@worldnetattne
t>...
>
> This is no big deal. It's done all the time in the typesetting
> industry, during proof reading. The original text is read out aloud
> by one person, while a second person reads the typeset material.
> At no time is the original text seen by the proof reader. It would be
> exactly the same over a telephone.
Thank you for making the point. This is exactly a circumstance where
time, TIME and Time
are to be considered the same. In a case sensitive programming language
they are THREE DISTINCT identifiers. I often use the text to speech
capability of my Mac to follow up in the spill chucker. I have seen
the power of hearing text as I once had an office next to a group of
translators who routinely read their product to each other.
The original poster was advocating case sensitive languages as "stricter"
and wondered why Fortran did not follow that model. It appears that the
OP had not been able to set the case insensitve defaults on several Unix
tools and was hoping to change the language standard rather than his
utility defaults. Or at least that is the way it ended up sounding. ;-)
| |
| SC Huang 2005-09-21, 7:00 pm |
| On 2005-09-21, Gordon Sande <g.sande@worldnet.att.net> wrote:
> The original poster was advocating case sensitive languages as "stricter"
> and wondered why Fortran did not follow that model. It appears that the
> OP had not been able to set the case insensitve defaults on several Unix
> tools and was hoping to change the language standard rather than his
> utility defaults. Or at least that is the way it ended up sounding. ;-)
No!! I was not advocating anything in the original post. (Sorry to
give this impression if any.) I just wanted to know what others think
about case sensitivity/consistency in Fortran (I mean f90/95).
In old Fortran (maybe 66?) a variable name cannot exceed 6
letters. This restriction is now "lifted". In theory I don't think one
needs more than 6 letters (a total of 26^6 variables can be created,
or more if underscore is also counted) to define all variables in a
subroutine. So removing the 6-letter restriction mainly contributes to
readability of new codes. Along this line I was thinking that
readability may be improved by mixed-case variables. For example, a
variable called "NumberOfAtoms" looks better than "numberofatoms", at
least for me. But typing "NumberOfAtoms" and "NumberofAtoms" in
different places creates some inconsistency, as have been discussed. I
understand that these can be detected by utilities (grep, vi, emacs,
etc.), but my main point is: "what's good/bad about doing the
case-consistency check at the compiler level?"
Is it correct to say that the general consensus is that both
case-sensitivity and case-consistency are not necessary in Fortran?
I am not in a position to advocate changing the standard. I am trying
to understand the reasonings behind the standard and then live
with/follow the standard. :-)
Thanks.
SC
| |
| beliavsky@aol.com 2005-09-21, 7:00 pm |
|
SC Huang wrote:
<snip>
> In old Fortran (maybe 66?) a variable name cannot exceed 6
> letters.
Also true in Fortran 77, although many F77 compilers allowed longer
names.
| |
| Duane Bozarth 2005-09-21, 7:00 pm |
| SC Huang wrote:
>
>
> OK, after reading all suggestions and comments, I realize that what I
> really need/want is "case consistency", not case sensitivity.
>
> What follows may be a dumb question but is there a way to enforce
> "case consistency" at the compiler level? I ask because "case
> consistency" is mentioned several times in the discussions but I
> cannot find such an option in my Intel (ifort) and PGI (pgf90)
> compilers. Does it exist in other compilers? Or am I missing
> something?
I'm unaware of any Fortran compilers that enforce or emit a warning for
case sensitivity. That would be an extension to the Standard,
obviously. That it <could> be implemented is an issue for the compiler
vendors.
> If the compiler can give a warning (or even error) when a variable
> called "Nproc" is spelled "nProc" somewhere else in the code, then the
> programmer can spot it easily.
> For me, having mixed-case variable names is merely for readability (or
> some cosmetic purposes). I can live without it, since (I guess) the
> machine code generated by the compiler is probably the same with or
> without mixed-case, so there is no difference in terms of
> functionality/speed.
That's correct--in Fortran, except in character data lowercase and
uppercase are mapped to uppercase.
Back to the earlier question, I think I noted that the F dialect
specifies case consistency but the compiler on which it is based does
the "translate to uppercase" early on so it isn't enforcable there, even
when it is an identified extension/restriction.
| |
| Duane Bozarth 2005-09-21, 7:00 pm |
| SC Huang wrote:
>
....
> Is it correct to say that the general consensus is that both
> case-sensitivity and case-consistency are not necessary in Fortran?
Yes, pretty much by definition since the Standard says specifically it
isn't either! :)
> I am not in a position to advocate changing the standard. I am trying
> to understand the reasonings behind the standard and then live
> with/follow the standard. :-)
You can now (w/ F90) use both and "decorate" names as you wish and be
within the standard (and most F77 compilers would also accept the
code). What you can't do is expect the compiler to enforce/warn on
nonconformance.
As others have noted, I think case sensitivity would be a bad thing
(TM), case consistency possibly a positive although w/o the former it
is, as you note, simply a case of "prettiness" in the source code as the
compiler will treat it as a single variable irregardless (even as it
must for standard-compliance even if it is consistent).
| |
| Gordon Sande 2005-09-21, 7:00 pm |
| On 2005-09-21 14:31:07 -0300, SC Huang <schuang21@yahoo.com> said:
> On 2005-09-21, Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> No!! I was not advocating anything in the original post. (Sorry to
> give this impression if any.) I just wanted to know what others think
> about case sensitivity/consistency in Fortran (I mean f90/95).
You did a good imitation of liking case sensitivity. As others have
noted this is high quality flame bait. On UseNet misquotes out
of context do not even need that much excuse. Newbies may be chided
a bit. Watch for smilies.
> In old Fortran (maybe 66?) a variable name cannot exceed 6
> letters. This restriction is now "lifted". In theory I don't think one
> needs more than 6 letters (a total of 26^6 variables can be created,
> or more if underscore is also counted) to define all variables in a
> subroutine. So removing the 6-letter restriction mainly contributes to
> readability of new codes. Along this line I was thinking that
> readability may be improved by mixed-case variables. For example, a
> variable called "NumberOfAtoms" looks better than "numberofatoms", at
> least for me. But typing "NumberOfAtoms" and "NumberofAtoms" in
> different places creates some inconsistency, as have been discussed. I
> understand that these can be detected by utilities (grep, vi, emacs,
> etc.), but my main point is: "what's good/bad about doing the
> case-consistency check at the compiler level?"
>
> Is it correct to say that the general consensus is that both
> case-sensitivity and case-consistency are not necessary in Fortran?
Many folks would consider case sensitivty to be a wide highway to
a large set of bugs. Add in the history of only upper case in
Fortran with its strong and highly valued history of continuity
and the result is what is politely called a nonstarter.
There is a notion of case retentive applied to file systems that says
if you call it MyFile then that is what the file system will say back at
you but you can not also have myfile or any other case sensitive variation
as other files as all variations get to the same place. Case retentive is
a nice way of breaking up file names. Embedded underscores or blanks do
the same but suffer under the telephone test. The style police issues
of NumberofAtoms vrs NumberOfAtoms is what you get with case consistency
or sensitivity. If there were good and obvious rules of thumb for doing
this you would not have gotten into your problem. Rather than showing
that case insensitivy is a problem it would seem to show why it is
a good policy for programming language identifiers.
There is a distinction between convenience for a single programmer
over a time span of w s and maintainability of a large code supported
by many varying programmers over many years. Case sensitivity may look
good for the first case but it causes too many problems for the second.
> I am not in a position to advocate changing the standard. I am trying
> to understand the reasonings behind the standard and then live
> with/follow the standard. :-)
>
> Thanks.
>
> SC
| |
| glen herrmannsfeldt 2005-09-21, 7:00 pm |
| Duane Bozarth wrote:
(snip)
> I'm unaware of any Fortran compilers that enforce or emit a warning for
> case sensitivity. That would be an extension to the Standard,
> obviously. That it <could> be implemented is an issue for the compiler
> vendors.
The C tradition was to have a separate program, called lint, to
help find constructs that are legal, but less desirable.
Many of those are now going into compilers as warnings, which
can sometimes be distracting while debugging. (Only sometimes.)
There is a related issue, which is case sensitive file systems.
Unix file systems are traditionally case sensitive, while DOS
and Windows traditionally are not. Things get interesting when
using NFS, or other shared file system protocols, between such
machines. Also, when files should be named after the subroutine
that they contain.
The only time I remember specifically using both cases in C
was through the preprocessor, something like
#define X (*x)
so that I could reference subroutine arguments passed through
pointers without putting *x all over the program. Good or not,
it made sense at the time.
-- glen
| |
| John Harper 2005-09-21, 7:00 pm |
| In article <dgs5cr$4v3$1@zinnia.noc.ucla.edu>,
SC Huang <schuang21@yahoo.com> wrote:
>On 2005-09-21, Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
>No!! I was not advocating anything in the original post. (Sorry to
>give this impression if any.) I just wanted to know what others think
>about case sensitivity/consistency in Fortran (I mean f90/95).
>
>In old Fortran (maybe 66?) a variable name cannot exceed 6
>letters. This restriction is now "lifted". In theory I don't think one
>needs more than 6 letters (a total of 26^6 variables can be created,
>or more if underscore is also counted)
That theory ignores the desirability of mnemonic names. Also, in old
Fortran (66 and 77) variable names had to begin with a letter, and the
remaining characters if any were chosen from the 36 letters and digits.
The maximum number of variable names was thus 26*(36**6-1)/35, which is
approx. 1.61E9 or 5.23*26**6. Of course few of us used O0000O, OO000O
and O000OO in the same program :-)
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| glen herrmannsfeldt 2005-09-21, 7:00 pm |
| John Harper wrote:
(snip)
> That theory ignores the desirability of mnemonic names. Also, in old
> Fortran (66 and 77) variable names had to begin with a letter, and the
> remaining characters if any were chosen from the 36 letters and digits.
> The maximum number of variable names was thus 26*(36**6-1)/35, which is
> approx. 1.61E9 or 5.23*26**6. Of course few of us used O0000O, OO000O
> and O000OO in the same program :-)
I need a new news reader, those three look the same from here.
I did once know a compiler that kept the symbol table in balanced
binary trees, one for each variable length from one to six.
The manual suggested that for faster compilation you should distribute
variable names lengths equally between one and six characters.
Your examples remind me of the note that I got from a math TA once,
using O for a variable in a calculus problem.
-- glen
| |
| James Giles 2005-09-21, 7:00 pm |
| J.F. Cornwall wrote:
> robin wrote:
> That works so long as every time an uppercase letter is encountered
> the person reading it out says it is uppercase... If the case is
> not specified, voila you have a potential bug.
On the contrary, outside of programming the conventions of
case are well defined and the proof reader(s) need help only
with respect to some words and phrases that are *sometimes*
proper names. Things like "the big apple" (which to me usually
refers to some fruit on the table) vs. "The Big Apple" which
means "New York City" as written. Both proof readers in
the above would be well aware of these things (or should be).
--
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
| |
| Kevin G. Rhoads 2005-09-21, 7:00 pm |
| >approx. 1.61E9 or 5.23*26**6. Of course few of us used O0000O, OO000O
>and O000OO in the same program :-)
Well, obviously, O00000 is 0, while O0000O is 1, and O000O0 is 2, and O000OO is 3.
This is the classic case of what one does when one has run out of "1"s.
| |
| mcalhoun@ksu.edu 2005-09-21, 7:00 pm |
|
>....[snip]....
>Lower case printers were certainly around in the 1970s and probably
>the 1960s. I have an idea that the 1960s Friden flexowriter ...
>had upper and lower case.
Yes, they did, and my wife of 40+ years will back me up on that, because
she typed my PhD dissertation on one, producing in the process something
like 120 rolls of paper tape!
And you should have heard her complain when I asked her to change just
one word in the middle of a page.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
| |
| Greg Lindahl 2005-09-21, 7:00 pm |
| In article <1127339713.613527@bats.mcs.vuw.ac.nz>,
John Harper <harper@mcs.vuw.ac.nz> wrote:
> Of course few of us used O0000O, OO000O and O000OO in the same
> program :-)
Doesn't that represent an alarming lack of inventiveness? I mean, my
friends are crazy enough to use that in code, especially if they had
to hand it off to someone else to modify or fix...
-- g
| |
|
| J.F. Cornwall wrote in message ...
>robin wrote:
>That works so long as every time an uppercase letter is encountered the
>person reading it out says it is uppercase...
Proofreading is proofreading. Capitalization is always checked.
> If the case is not
>specified, voila you have a potential bug.
>
>Jim
| |
|
| John Harper wrote in message <1127339713.613527@bats.mcs.vuw.ac.nz>...
>That theory ignores the desirability of mnemonic names. Also, in old
>Fortran (66 and 77) variable names had to begin with a letter, and the
>remaining characters if any were chosen from the 36 letters and digits.
>The maximum number of variable names was thus 26*(36**6-1)/35, which is
>approx. 1.61E9 or 5.23*26**6. Of course few of us used O0000O, OO000O
>and O000OO in the same program :-)
Only by accident, perhaps :^)
>John Harper, School of Mathematics, Statistics and Computer Science,
| |
|
| SC Huang wrote in message ...
>No!! I was not advocating anything in the original post. (Sorry to
>give this impression if any.) I just wanted to know what others think
>about case sensitivity/consistency in Fortran (I mean f90/95).
>
>In old Fortran (maybe 66?) a variable name cannot exceed 6
>letters. This restriction is now "lifted". In theory I don't think one
>needs more than 6 letters (a total of 26^6 variables can be created,
>or more if underscore is also counted)
No underscore, but what about the digits?
~26*36**5
> to define all variables in a
>subroutine. So removing the 6-letter restriction mainly contributes to
>readability of new codes. Along this line I was thinking that
>readability may be improved by mixed-case variables. For example, a
>variable called "NumberOfAtoms" looks better than "numberofatoms", at
>least for me. But typing "NumberOfAtoms" and "NumberofAtoms"
Some of us prefer Number_of_atoms.
> in different places creates some inconsistency, as have been discussed. I
>understand that these can be detected by utilities (grep, vi, emacs,
>etc.), but my main point is: "what's good/bad about doing the
>case-consistency check at the compiler level?"
>
>Is it correct to say that the general consensus is that both
>case-sensitivity and case-consistency are not necessary in Fortran?
>
>I am not in a position to advocate changing the standard. I am trying
>to understand the reasonings behind the standard and then live
>with/follow the standard. :-)
>
>Thanks.
>
>SC
| |
| Carlie J. Coats 2005-09-22, 7:57 am |
| John Harper wrote:
[big snip...]>
> ... Of course few of us used O0000O, OO000O
> and O000OO in the same program :-)
There is a river-flow forecast program used by a major US government
agency, where one has to distinguish the variables with names
CO==<letter-C lettter-o> and C0==<letter-C digit-zero>.
--all in upper-case, of course, to defeat any optical distinction.
--and would you be surprised that the program mixes pre-77 and post-90
constructs promiscuously?
--
Carlie J. Coats, Jr. carlie.coats@baronams.com
Environmental Modeling Center carlie_coats@ncsu.edu
Baron Advanced Meteorological Systems, LLC
| |
| Arjen Markus 2005-09-22, 7:57 am |
|
Carlie J. Coats schreef:
> John Harper wrote:
> [big snip...]>
>
> There is a river-flow forecast program used by a major US government
> agency, where one has to distinguish the variables with names
> CO==<letter-C lettter-o> and C0==<letter-C digit-zero>.
>
> --all in upper-case, of course, to defeat any optical distinction.
>
> --and would you be surprised that the program mixes pre-77 and post-90
> constructs promiscuously?
>
Oh, I like that! You can improve on the confusion with variable names
containing O1, 01, 0l and Ol (where 1 is "one" and l is "ell")
It so happens that we are revising our programming standards, I think I
will go and add a rule that forces everyone to have a pair of such
variables in every routine they write.
Regards,
Arjen
| |
| J. F. Cornwall 2005-09-22, 7:57 am |
| James Giles wrote:
> J.F. Cornwall wrote:
>
>
>
> On the contrary, outside of programming the conventions of
> case are well defined and the proof reader(s) need help only
> with respect to some words and phrases that are *sometimes*
> proper names. Things like "the big apple" (which to me usually
> refers to some fruit on the table) vs. "The Big Apple" which
> means "New York City" as written. Both proof readers in
> the above would be well aware of these things (or should be).
Right, but I don't think you could assume that the same conventions
transfer to the reading of code.
Jim
| |
| J. F. Cornwall 2005-09-22, 7:57 am |
| robin wrote:
> J.F. Cornwall wrote in message ...
>
>
>
> Proofreading is proofreading. Capitalization is always checked.
OK. Will programmers reading code aloud *always* follow these same
rules? If yes, then using "proofreading rules" on code might work. If
not, bugs will appear if the reader forgets to mention the case of a
letter in a case-sensitive language...
>
>
>
| |
| James Parsly 2005-09-22, 6:58 pm |
| I seem to remember some dialect of basic where the limit was 2 characters...
In any case, 6 characters was the limit for the early versions of Fortran
that I used, but
having to punch programs onto cards provided a great incentive to use the
shortest
possible variable names.
Every extra character you had to punch was an extra opportunity to screw up,
and
screwing up generally meant starting over. (Those who know what I'm talking
about
are thinking, what about DUP? The keypunches in question were in the
undergraduate
bullpen area, so DUP was often broken.)
"John Harper" <harper@mcs.vuw.ac.nz> wrote in message
news:1127339713.613527@bats.mcs.vuw.ac.nz...
> In article <dgs5cr$4v3$1@zinnia.noc.ucla.edu>,
> SC Huang <schuang21@yahoo.com> wrote:
>
> That theory ignores the desirability of mnemonic names. Also, in old
> Fortran (66 and 77) variable names had to begin with a letter, and the
> remaining characters if any were chosen from the 36 letters and digits.
> The maximum number of variable names was thus 26*(36**6-1)/35, which is
> approx. 1.61E9 or 5.23*26**6. Of course few of us used O0000O, OO000O
> and O000OO in the same program :-)
>
> John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| Walter Spector 2005-09-22, 6:58 pm |
| James Parsly wrote:
>
> I seem to remember some dialect of basic where the limit was 2 characters...
In BASIC for many years, variable names were a single (case insensitive)
alphabetic character, optionally followed by a digit. So there were 276
possibilities. And since subroutines were a joke, the namespace problems
could get unmanageable in large programs. ("Large" being anything over about
200 LOC.)
> In any case, 6 characters was the limit for the early versions of Fortran
> that I used, but
> having to punch programs onto cards provided a great incentive to use the
> shortest
> possible variable names.
There was a minimal variant of Fortran-66 described in the Standard. One of
the restrictions was that 5 characters was the limit on names.
I actually had the pleasure of using a compiler with 5-character name limit
on a Data General minicomputer. We had to keep two copies of the code around,
one with the 'real' names, the other with shortened names where needed.
We were *so* happy when DG finally released a compiler which accepted longer
names! (IIRC they raised the limit to 8 characters.)
> Every extra character you had to punch was an extra opportunity to screw up,
> and
> screwing up generally meant starting over. (Those who know what I'm talking
> about
> are thinking, what about DUP? The keypunches in question were in the
> undergraduate
> bullpen area, so DUP was often broken.)
In some way I miss the satisfying clicks, swishing/sliding, and punching
sounds of the 029 card punch. Especially when using a custom drum card to do
tabbing to column 7, etc. Kids of today just don't...
Walt
-...-
Walt Spector
(w6ws att earthlinkk dott nett)
| |
| Walter Spector 2005-09-22, 6:58 pm |
| Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 44
Date: Thu, 22 Sep 2005 16:09:12 GMT
NNTP-Posting-Host: 68.126.223.141
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread2.news.pas.earthlink.net 1127405352 68.126.223.141 (Thu, 22 Sep 2005 09:09:12 PDT)
NNTP-Posting-Date: Thu, 22 Sep 2005 09:09:12 PDT
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:137374
Walter Spector wrote:
>
> James Parsly wrote:
>
> In BASIC for many years, variable names were a single (case insensitive)
> alphabetic character, optionally followed by a digit. So there were 276
^8
> possibilities. And since subroutines were a joke, the namespace problems
> could get unmanageable in large programs. ("Large" being anything over about
> 200 LOC.)
>
>
> There was a minimal variant of Fortran-66 described in the Standard. One of
> the restrictions was that 5 characters was the limit on names.
>
> I actually had the pleasure of using a compiler with 5-character name limit
> on a Data General minicomputer. We had to keep two copies of the code around,
> one with the 'real' names, the other with shortened names where needed.
> We were *so* happy when DG finally released a compiler which accepted longer
> names! (IIRC they raised the limit to 8 characters.)
>
>
> In some way I miss the satisfying clicks, swishing/sliding, and punching
> sounds of the 029 card punch. Especially when using a custom drum card to do
> tabbing to column 7, etc. Kids of today just don't...
>
> Walt
> -...-
> Walt Spector
> (w6ws att earthlinkk dott nett)
| |
| glen herrmannsfeldt 2005-09-22, 6:58 pm |
| Carlie J. Coats wrote:
> John Harper wrote:
> [big snip...]>
>
>
>
> There is a river-flow forecast program used by a major US government
> agency, where one has to distinguish the variables with names
> CO==<letter-C lettter-o> and C0==<letter-C digit-zero>.
A printer that Xerox used to use with some of their computers had
a little loop at the top of the oh, sort of like a cursive letter.
It might have been upper case only, I don't remember anything for
the letter l.
The IBM printers, such as the 1403, have a more square oh, and
more elliptical zero, not so hard to tell apart, but you have to
look a little bit close.
-- glen
| |
| James Giles 2005-09-22, 6:58 pm |
| J. F. Cornwall wrote:
> James Giles wrote:
....
>
> Right, but I don't think you could assume that the same conventions
> transfer to the reading of code.
All the more reason for programming languages not to be
case sensitive.
--
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
| |
| Gordon Sande 2005-09-22, 6:58 pm |
| On 2005-09-22 16:07:04 -0300, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
> Carlie J. Coats wrote:
>
>
> A printer that Xerox used to use with some of their computers had
> a little loop at the top of the oh, sort of like a cursive letter.
> It might have been upper case only, I don't remember anything for
> the letter l.
Once upon a time there was a convention that if you were a
computer user you slashed the oh's. But if you were in communications
you put the slash through the zero (more like a phi with a vertical
stroke). Then the two traditions converged. Confusion reigned.
So the brave ANSI folks struck a committee to set a standard
for handwritten characters. It as clear that neither tradition
was going to be kept and neither side much cared so they made
a decision. Ohs and Zeros would be circles or thetas when handwriten
and the oh was the theta, if I have it right. I once saw the
hard copy of this standard and the theta was as described above.
My guess is that the same standard had an answer to the ell and
one problem and my hazy guess is that handwriten ells are vertical
loops and ones are just a stroke if they are standard conforming.
But then most computer output is not handwriten so it is not clear
what relevance this has. As they says, standards are nice because
there are many to chose between.
> The IBM printers, such as the 1403, have a more square oh, and
> more elliptical zero, not so hard to tell apart, but you have to
> look a little bit close.
>
> -- glen
| |
| J. F. Cornwall 2005-09-22, 6:58 pm |
| James Giles wrote:
> J. F. Cornwall wrote:
>
>
> ...
>
>
>
> All the more reason for programming languages not to be
> case sensitive.
>
Precisely...
Jim
| |
| Richard E Maine 2005-09-22, 6:58 pm |
| In article < 2005092216510816807%gsande@worldnetattne
t>,
Gordon Sande <g.sande@worldnet.att.net> wrote:
> Once upon a time there was a convention that if you were a
> computer user you slashed the oh's. But if you were in communications
> you put the slash through the zero (more like a phi with a vertical
> stroke).
Darn. I'm not a communications person. Honest. Just because I took more
communications courses (one) than computer ones (zero) in grad school
isn't enough to count. :-) But I write my zeros with a slash - just
like it shows on my screen in the font I'm looking at while writing
this. (Just typed and deleted one to make sure).
--
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
| |
| Clive Page 2005-09-22, 6:58 pm |
| In message <dgpg87$6b9$1@daisy.noc.ucla.edu>, SC Huang
<schuang21@yahoo.com> writes
>I am wondering if there is a good reason why Fortran is not
>case-sensitive.
As so often on Usenet, this thread has developed into an entertaining
nostalgia-fest, but has veered just a bit off topic.
I seem to remember seeing, in some journal like "Software Practice and
Experience" maybe 15 years ago, an article examining the question of
whether a language should be case sensitive or not by actually running a
trial. The numbers weren't huge, and they had to invent a pair of
artificial languages for the purpose (one to cover each case, if you see
what I mean). The results, as far as I remember them, were that the
case-insensitive language enabled beginners to write programs containing
not quite as many errors. But I don't have the reference - does anyone
else remember this?
--
Clive Page
| |
| James Giles 2005-09-22, 6:58 pm |
| Clive Page wrote:
....
> I seem to remember seeing, in some journal like "Software Practice
> and Experience" maybe 15 years ago, an article examining the
> question of whether a language should be case sensitive or not by
> actually running a trial. The numbers weren't huge, and they had
> to invent a pair of artificial languages for the purpose (one to
> cover each case, if you see what I mean). The results, as far as I
> remember them, were that the case-insensitive language enabled
> beginners to write programs containing not quite as many errors.
> But I don't have the reference - does anyone else remember this?
I positive that I've seen a paper of exactly that kind somewhere,
but I always refrain from mentioning it since I no longer have
a copy and don't remember where or when the paper was
published (I've had people insist that I post references when
I mention such studies).
--
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
| |
| James Giles 2005-09-22, 6:58 pm |
| Richard E Maine wrote:
> In article < 2005092216510816807%gsande@worldnetattne
t>,
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> Darn. I'm not a communications person. Honest. Just because I took
> more communications courses (one) than computer ones (zero) in grad
> school isn't enough to count. :-) But I write my zeros with a
> slash - just like it shows on my screen in the font I'm looking at
> while writing this. (Just typed and deleted one to make sure).
There's actually an old (1970s) standard for writing (by hand)
on coding forms that specifies the use of a grave accent over-
printing the letter O and no distinguishing mark for zero (ANSI
X3.45-1974). I tend not to care for the convention you mention
since there is a latin-1 character (Ø) that looks similar, but hasn't
that meaning. In any context where it might be mistaken for
a digit, I always us a lower-case o.
--
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
| |
|
| Carlie J. Coats wrote in message <9PwYe.18991$zG1.16817@trnddc05>...
>John Harper wrote:
>[big snip...]>
>
>There is a river-flow forecast program used by a major US government
>agency, where one has to distinguish the variables with names
>CO==<letter-C lettter-o> and C0==<letter-C digit-zero>.
>
>--all in upper-case, of course, to defeat any optical distinction.
Nothing wrong with that if their equipment puts a slash thru
one or the other, or provides some other means of
distinguishment.
>Carlie J. Coats, Jr. carlie.coats@baronams.com
| |
| Dan Nagle 2005-09-23, 7:58 am |
| Hello,
robin wrote:
> Carlie J. Coats wrote in message <9PwYe.18991$zG1.16817@trnddc05>...
<snip>
>
>
> Nothing wrong with that if their equipment puts a slash thru
> one or the other, or provides some other means of
> distinguishment.
Actually, what's wrong with it is the minimization
of easy visual distinction. The point being that
distinction should be made as easy as possible, and
not left to the least means resolvable by concentrated
study. Besides, what "other means of distinguishment"
are you claiming is available to the human eye?
There's a whole literature on this subject, for example,
in the design of displays for aircraft pilots, where
rapid and reliable reading is valuable. See, e.g.,
_Human Factors Reference Guide for Electronics and
Computer Professionals_, in the McGraw-Hill Engineering
Reference Guide Series.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Ben Hetland 2005-09-23, 7:00 pm |
| Gordon Sande wrote:
> Once upon a time there was a convention that if you were a
> computer user you slashed the oh's. But if you were in communications
> you put the slash through the zero (more like a phi with a vertical
> stroke). Then the two traditions converged. Confusion reigned.
Remembering back not so very long ago, still while 7-bit character sets
where most common, and we had several national variations of the ASCII
set (or should I say "derived from") to accomodate different national
characters needed. In those days, at least in Danish and Norwegian, the
character Ø (from Latin-1 or iso-8859-1, looks like a "slashed oh" for
those of you who can't see it here) was frequently needed but often
lacking support on various equipment. But since the zero often looked
like this letter (in fact more so than the Gr letter phi), we tended
to use the zero as a substitute for the missing character. If all were
in capital letters anyway, it usually was very readable.
I think many of us in Scandinavia thought the habit of "slashing the
zero" looked kind of strange, but it came in handy anyway. Perhaps some
even used a 'o' or 'O', the letter, in stead of the zero digit too,
because the '0' (zero) didn't look like a zero too us -- it looked like
a letter!
BTW, I still occationally see problems with just that specific national
character, as it seemed to have been "forgotten" in some of the
"extended ASCII" character sets of printers. (Two other letters of the
N. and D. alphabets aren't missing, and are rarely so problematic.)
Usually (from the IBM-PC?) the characters turn up as the 'yen' character
(for capital Ø) and the 'cent' (for small letter ø). Everytime I stuble
upon such a printout, it makes me smile a bit, remember "back in those
days", and maybe utter a comment like "we still haven't managed to solve
that silly problem in 2005".
> My guess is that the same standard had an answer to the ell and
> one problem and my hazy guess is that handwriten ells are vertical
> loops and ones are just a stroke if they are standard conforming.
You could add capital letter 'I' to that set too, as all three can look
very similar in many fonts as well as in hand-writing. Similar are the
capital letter G and the digit 6.
-+-Ben-+-
| |
| Ben Hetland 2005-09-23, 7:00 pm |
| Richard E Maine wrote:
> :-) But I write my zeros with a slash - just
> like it shows on my screen in the font I'm looking at while writing
> this. (Just typed and deleted one to make sure).
But I have a Norwegian keyboard, and I wonder how you would see the
difference between Ø0, 0Ø, 00 and the ØØ combinations when I type them
in a message to you? (They can be in a web address too now, you know!)
-+-Ben-+-
| |
|
| Prachtig ! (Splendid in Dutch)
I had to copy the text into Notepad to see the differences.
Fixed type in my newsreader has no difference between O (oh) and 0
(zero)
or l (ell) and 1 (one)
If I must use an ell, I take the capital L .
[JvO]
| |
| Richard E Maine 2005-09-23, 7:00 pm |
| In article <4333FEAB.7090809@sintef.no>,
Ben Hetland <ben.a.hetland@sintef.no> wrote:
> Richard E Maine wrote:
>
> But I have a Norwegian keyboard, and I wonder how you would see the
> difference between Ø0, 0Ø, 00 and the ØØ combinations when I type them
> in a message to you?
They are distinguishable, but of course easy to confuse. In this font,
the slash in the digit zero stops at the boundary, while the other slash
goes well through.
Fortunately for me, I've never once had occasion to need to handwrite
that other character (which I don't offhand know the proper name for). I
do often enough handwrite the Gr phi, but I make its bar more
vertical.
I'm not, I should add, saying that there is any particular merit to the
way I do it. Just pointing out the habit I've adopted.
--
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
| |
| Jan Vorbrüggen 2005-09-26, 8:02 am |
| > There's a whole literature on this subject, for example,
> in the design of displays for aircraft pilots, where
> rapid and reliable reading is valuable. See, e.g.,
> _Human Factors Reference Guide for Electronics and
> Computer Professionals_, in the McGraw-Hill Engineering
> Reference Guide Series.
Indeed so. As a side note, recall that the Straßburg crash of an Airbus
was caused, to a large degree, by the visual interface of the autopilot
disregarding this principle: the difference between the correct (intended)
mode of descent and the incorrect, actual one was the difference between
"3" and "3." on a single-digit display.
Jan
| |
|
| Dan Nagle wrote:
>
> There's a whole literature on this subject, for example,
> in the design of displays for aircraft pilots, where
> rapid and reliable reading is valuable. See, e.g.,
> _Human Factors Reference Guide for Electronics and
> Computer Professionals_, in the McGraw-Hill Engineering
> Reference Guide Series.
You're on (for a change) - GUI outfitters could benefit from a few
"fresh" ideas:
Ref to an oft cited textbook:
http://www.blackburnpress.com/digavsys2nde.html
Ref to an FAA std:
http://hf.tc.faa.gov/hfds/default.htm
Ref to an DOD std:
http://hfetag.dtic.mil/docs-hfs/mil-std-1472f.pdf
fyi, we had some of those principles "sewn" in, but the GUI pros
claim it feels broken, otoh, F15 pilots feel the same way when
they're *word*ding their FRs...
| |
| Jim Klein 2005-09-30, 3:57 am |
| It was written by Engineers for Engineers and we cannnttt sppeell.
Jim Klein
SC Huang <schuang21@yahoo.com> wrote:
>Hi,
>
>I am wondering if there is a good reason why Fortran is not
>case-sensitive.
>
>I have to admit that I personally cannot think of strong enough
>reasons to justify why Fortran should be case-sensitive
>either. Although I am happy with the current Fortran standard, it
>seems to me (sometimes) that being case-sensitive (like C) makes the
>language more "strict" to avoid potential errors/bugs.
>
>I appreciate any comments on this. Thanks.
>
>SC
>
|
|
|
|
|