aryeh@cash.uucp (the over worked C something or another) (09/30/90)
Since I going to be doing my first team effort I want to know if this is bad style: for(x=0;x!=100;x++) ... -- Aryeh Friedman aryeh@cash.ucsc.edu or "ain't bug hunts the funnest" tsource@watnxt2.ucr.edu
henry@zoo.toronto.edu (Henry Spencer) (09/30/90)
In article <7341@darkstar.ucsc.edu> aryeh@cash.uucp (the over worked C something or another) writes: >Since I going to be doing my first team effort I want to know if this is bad >style: > for(x=0;x!=100;x++) ... Most people find it more readable with a bit of space and the statement on the next line: for (x = 0; x != 100; x++) ... The cautious would also recommend `x <= 100', but in this situation that is arguable. I assume `x' is an integer variable, not floating-point. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
kanamori@Neon.Stanford.EDU (Atsushi Kanamori) (10/01/90)
In article <1990Sep30.050655.13212@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <7341@darkstar.ucsc.edu> aryeh@cash.uucp (the over worked C something or another) writes: >>Since I going to be doing my first team effort I want to know if this is bad >>style: >> for(x=0;x!=100;x++) ... > >Most people find it more readable with a bit of space and the statement >on the next line: > > for (x = 0; x != 100; x++) > ... > >The cautious would also recommend `x <= 100', but in this situation that >is arguable. I would say "x <= 100" is arguably bad. "x < 100" is more like it. More usefully, "<" seems to be a more common idiom than "!=" in upward counting loops. So using "<" will probably shave a few microseconds off the human reader's processing time.
steve@groucho.ucar.edu (Steve Emmerson) (10/01/90)
In comp.lang.c you write: >Since I going to be doing my first team effort I want to know if this is bad >style: > for(x=0;x!=100;x++) ... It's OK, though some improvements could be made. Old-timers would ususally write "x < 100" rather than "x != 100" as it expresses the sense of direction (incrementation) slightly better, and they're more used to seeing it that way. A slightly more important improvement would be to use a symbolic variable or constant for the, otherwise, non-obvious "100" value. Something like # define NUM_ELEMENTS 100 for (x = 0; x < NUM_ELEMENTS; x++) ... Note also the use of additional whitespace. Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve
manning@nntp-server.caltech.edu (Evan Marshall Manning) (10/01/90)
steve@groucho.ucar.edu (Steve Emmerson) writes: >>Since I going to be doing my first team effort I want to know if this is bad >>style: >> for(x=0;x!=100;x++) ... >It's OK, though some improvements could be made. Old-timers would >ususally write "x < 100" rather than "x != 100" as it expresses the >sense of direction (incrementation) slightly better, and they're more >used to seeing it that way. >A slightly more important improvement would be to use a symbolic >variable or constant for the, otherwise, non-obvious "100" value. >Something like > # define NUM_ELEMENTS 100 > for (x = 0; x < NUM_ELEMENTS; x++) ... >Note also the use of additional whitespace. Well, if the issue really is style... Don't ever use single-character variable names. I use 'ix' for loop index variables for which I can come up with no better name, but this happens rarely. If you're looping ove 'x' then 'x' means something more to you than just 'x' when you're writing the code. But it may not be immediately obvious later. There's bound to be a more useful name for NUM_ELEMENTS too. *************************************************************************** Your eyes are weary from staring at the CRT for so | Evan M. Manning long. You feel sleepy. Notice how restful it is | is to watch the cursor blink. Close your eyes. The |manning@gap.cco.caltech.edu opinions stated above are yours. You cannot | manning@mars.jpl.nasa.gov imagine why you ever felt otherwise. | gleeper@tybalt.caltech.edu
steve@taumet.com (Stephen Clamage) (10/01/90)
aryeh@cash.uucp (the over worked C something or another) writes: >Since I going to be doing my first team effort I want to know if this is bad >style: > for(x=0;x!=100;x++) ... In his book "C Traps and Pitfalls", Andy Koenig recommends using asymmetric bounds. In this particular example, there are 101 iterations, while the casual reader might read it as 100. If you write instead for(x=0; x < 101; x++) ... where the lower bound is INclusive and the upper bound is EXclusive, it makes it very obvious what is going on. Furthermore, such loops are often used to address arrays. Writing the bounds this way nicely parallels the array declaration T ray[101]; where ray has 101 elements from 0 up to but not including 101. The result tends to be fewer off-by-one errors, and code which is easier to understand. Finally, a test like x!=100 implies that x==101 means continue; it requires careful study of the code to see whether x could ever be 101 or greater. When you write x<101 it is perfectly plain that x is always intended to to less than 101. -- Steve Clamage, TauMetric Corp, steve@taumet.com
john@IASTATE.EDU (Hascall John Paul) (10/01/90)
In article <8660@ncar.ucar.edu>, steve@groucho.ucar.edu (Steve Emmerson) writes: > > >Since I going to be doing my first team effort I want to know if this is bad > >style: > > for(x=0;x!=100;x++) ... > > It's OK, though some improvements could be made. ... > > for (x = 0; x < NUM_ELEMENTS; x++) ... This is really pointless, but I don't see that stopping anyone else... What is the generally preferred usage? Or does it matter at all? ++x; or x++; I find myself using ++x (which in my mind I attribute to some long gone, brain-damaged optimizer from my past -- but I still persist). My `favorite' is: --x; and x++; (pre-decrement, post-increment!!!) > Note also the use of additional whitespace. Please! -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50010 (515) 294-9551
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/01/90)
steve@taumet.com (Stephen Clamage) writes: > aryeh@cash.uucp (the over worked C something or another) writes: > >>Since I going to be doing my first team effort I want to know if this is >> bad style: >> for(x=0;x!=100;x++) ... > > In his book "C Traps and Pitfalls", Andy Koenig recommends using > asymmetric bounds. In this particular example, there are 101 > iterations, while the casual reader might read it as 100. If you write > instead In this case, the "casual reader" would be correct. There ARE 100 iterations: x==0 to x==99. > for(x=0; x < 101; x++) ... NO! That would add the iteration for x==100, which is clearly NOT what is wanted if he wrote x!=100. You mean for(x=0; x < 100; x++) ... which would cause the same number of iterations as the original loop. > where the lower bound is INclusive and the upper bound is > EXclusive, it makes it very obvious what is going on. Furthermore, > such loops are often used to address arrays. Writing the bounds this > way nicely parallels the array declaration > T ray[101]; > where ray has 101 elements from 0 up to but not including 101. The > result tends to be fewer off-by-one errors, and code which is easier to > understand. Agreed, but again, you mean T ray[100]; which has 100 elements from 0 to 99. > > Finally, a test like x!=100 implies that x==101 means continue; it > requires careful study of the code to see whether x could ever be 101 > or greater. This is correct. Good point. > When you write x<101 it is perfectly plain that x is always > intended to to less than 101. Change to "x<100" and "less than 100", which is what was originally meant. > -- > > Steve Clamage, TauMetric Corp, steve@taumet.com I hope this didn't sound too much like a flame, but I wanted to make sure the record was kept straight. ----------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu >> Apple // Forever!!! <<
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/01/90)
In article <8660@ncar.ucar.edu> steve@groucho.ucar.edu (Steve Emmerson) writes: > # define NUM_ELEMENTS 100 > for (x = 0; x < NUM_ELEMENTS; x++) ... Hmmm. I'll automatically write x = NUM_ELEMENTS; while (x--) ... for this kind of loop. On many computers it'll run noticeably faster, and I can safely replace NUM_ELEMENTS by a function call. ---Dan
davis@pacific.mps.ohio-state.edu ("John E. Davis") (10/01/90)
In article <1990Sep30.172917.2951@Neon.Stanford.EDU> kanamori@Neon.Stanford.EDU (Atsushi Kanamori) writes: >In article <1990Sep30.050655.13212@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >>In article <7341@darkstar.ucsc.edu> aryeh@cash.uucp (the over worked C something or another) writes: >>>Since I going to be doing my first team effort I want to know if this is bad >>>style: >>> for(x=0;x!=100;x++) ... >> >>Most people find it more readable with a bit of space and the statement >>on the next line: >> >> for (x = 0; x != 100; x++) >> ... >> >>The cautious would also recommend `x <= 100', but in this situation that >>is arguable. >I would say "x <= 100" is arguably bad. > "x < 100" is more like it. >More usefully, "<" seems to be a more common idiom than "!=" in upward counting >loops. So using "<" will probably shave a few microseconds off >the human reader's processing time. Which generates faster code? It seems to me that it is easier to tell if two values are unequal than to tell if one is greater than the other. I'd rather save the machine a few micro-seconds than myself since I only do the comparison once whereas the machine must do it many times. -- John bitnet: davis@ohstpy internet: davis@pacific.mps.ohio-state.edu
chris@mimsy.umd.edu (Chris Torek) (10/01/90)
[on the test `x < 100' vs `x != 100' in a for loop] In article <DAVIS.90Oct1025438@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu ("John E. Davis") writes: >Which generates faster code? It seems to me that it is easier to tell if >two values are unequal than to tell if one is greater than the other. Not really. The easy comparisons are against 0; the others are generally a bit harder. (A comparison for `x == y' can be done in more ways than one for `x < y', but this is not much of a recommendation.) Look at the test instructions on the current crop of fast CPUs for a demonstration. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
rh@smds.UUCP (Richard Harter) (10/01/90)
In article <1990Sep30.050655.13212@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > In article <7341@darkstar.ucsc.edu> aryeh@cash.uucp (the over worked C something or another) writes: > >Since I going to be doing my first team effort I want to know if this is bad > >style: > > for(x=0;x!=100;x++) ... > Most people find it more readable with a bit of space and the statement > on the next line: > for (x = 0; x != 100; x++) > ... > The cautious would also recommend `x <= 100', but in this situation that > is arguable. > I assume `x' is an integer variable, not floating-point. The original construction is bad style unless the value of x is being altered within the loop so that x==100 is the termination condition. If this is the typical loop structure <perform loop body for x = 0 ... 99> the normal idiom is for (x=0;x<100;x++) {...} There is a good reason for using this idiom if you think about it. In C an array of size N has valid indices from 0 through N-1. Since many loops reference arrays it is normal for an N times loop to use the same indexing pattern so that the termination condition for a loop with increasing indices is index >=N or index<N. There is a general rule of code writing that the termination conditions used in loops should match the actual termination condition. If the actual condition is x<100 that is what you should use rather than the weaker condition x!=100. Note that the proposed text fails if the body of the loop ever alters the value of x to be greater than 100. As a further point. If Henry Spencer, who is an expert, can mistranslate this construction, you can take it as pragmatic evidence that it is dubious. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") (10/01/90)
john@IASTATE.EDU (Hascall John Paul) writes: > What is the generally preferred usage? Or does it matter at all? > ++x; or x++; > I find myself using ++x (which in my mind I attribute to some long gone, > brain-damaged optimizer from my past -- but I still persist). My `favorite' > is: > --x; and x++; (pre-decrement, post-increment!!!) I prefer using ++x (or --x) to represent the fact that I'm _operating_ on 'x'. And it makes sense to have unary operators lead their operands. N'est pas? Tom. -- I can be reached at... zougas@me.utoronto.ca || zougas@me.toronto.edu || ...!utai!me!zougas
zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") (10/01/90)
davis@pacific.mps.ohio-state.edu ("John E. Davis") writes: >In article <1990Sep30.172917.2951@Neon.Stanford.EDU> kanamori@Neon.Stanford.EDU (Atsushi Kanamori) writes: > >More usefully, "<" seems to be a more common idiom than "!=" in upward counting > >loops. So using "<" will probably shave a few microseconds off > >the human reader's processing time. >Which generates faster code? It seems to me that it is easier to tell if two >values are unequal than to tell if one is greater than the other. I'd rather >save the machine a few micro-seconds than myself since I only do the >comparison once whereas the machine must do it many times. You know what they say: "Computers are very good at doing things over and over and over again":-) Shaving microseconds does not make better code. Better algorithms do. (Definition of 'better' left to the reader as an exercise :-) Tom. -- I can be reached at... zougas@me.utoronto.ca || zougas@me.toronto.edu || ...!utai!me!zougas
henry@zoo.toronto.edu (Henry Spencer) (10/02/90)
In article <1990Sep30.172917.2951@Neon.Stanford.EDU> kanamori@Neon.Stanford.EDU (Atsushi Kanamori) writes: >I would say "x <= 100" is arguably bad. > >"x < 100" is more like it. Oops. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (10/02/90)
In article <1990Sep30.220839.20183@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >Don't ever use single-character variable names. I use 'ix' for >loop index variables for which I can come up with no better name... In what way is "ix" superior to "i"? Both are meaningless names in this context. If the name is not going to be meaningful -- and in the context of a short loop, it's not clear that making it meaningful is either possible or particularly important -- then at least keep it short. There is an old prejudice against using "I" or "O" for a variable name, arising from confusion with "1" and "0", but the lowercase letters don't have that problem. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (10/02/90)
In article <DAVIS.90Oct1025438@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > [ `<' vs `!=' in comparisons ] >Which generates faster code? It seems to me that it is easier to tell if two >values are unequal than to tell if one is greater than the other... Most machines do all comparisons in the same length of time. When it does make a difference, the nature of the difference is highly machine- specific. What *can* make a difference is to run the loop backwards, algorithm permitting: for (x = 99; x >= 0; x--) ... so that the termination test is a comparison against zero. That very often *is* faster than comparison to an arbitrary constant. When the algorithm requires an up-counter, it can even be faster to run a down- counter in parallel and use it for the termination test: for (i = 99, x = 0; i >= 0; i--, x++) /* code using x */ Obviously this depends somewhat on the availability of registers and other machine-specific details. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
jd@iccdev.indcomp.com (J.D. Laub) (10/02/90)
john@IASTATE.EDU (Hascall John Paul) writes: > What is the generally preferred usage? Or does it matter at all? > ++x; or x++; I beleive one HP optimizer manual recommened pre inc/dec, but I cannot find the manual to confirm. Anyone know why they made this recommendation? -- J.D. Laub (...!gatech!iccdev!jd)
steve@groucho.ucar.edu (Steve Emmerson) (10/02/90)
In <12683:Oct102:57:1590@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <8660@ncar.ucar.edu> steve@groucho.ucar.edu (Steve Emmerson) writes: >> # define NUM_ELEMENTS 100 >> for (x = 0; x < NUM_ELEMENTS; x++) ... >Hmmm. I'll automatically write x = NUM_ELEMENTS; while (x--) ... for >this kind of loop. On many computers it'll run noticeably faster, and I >can safely replace NUM_ELEMENTS by a function call. If the loop-body doesn't care, then I don't either. My point was the use of a symbolic name rather than a hard-coded magic cookie (i.e. NUM_ELEMENTS rather than "100"). Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve
jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) (10/02/90)
In article <1990Sep30.220839.20183@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: > >Well, if the issue really is style... > >Don't ever use single-character variable names. I use 'ix' for >loop index variables for which I can come up with no better name, Using single letter variable names was somethiing I used to do for simple loops and character at a time reading. e.g: c = getchar() for(i=1; i<10; ++i) (i, j, k & l for small loops) While I have been "cured" of this, I'm still not convinced. As long as the use of single chararacter variables are used in limited ways, there really isn't any loss. Still, I now code like this: e.g: inpchar = getchar() for (loopinx=1; loopinx < 10; ++loopinx) It keeps me from getting flamed for unreadable code ?!? -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak If something is worth doing, it's worth doing correctly.
karl@haddock.ima.isc.com (Karl Heuer) (10/02/90)
In article <DAVIS.90Oct1025438@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >Which generates faster code? It seems to me that it is easier to tell if two >values are unequal than to tell if one is greater than the other. On vaxlike machines, both forms of comparison will generate a compare instruction (which sets condition codes) followed by a conditional branch, the only difference being whether the "can't happen" case is included or excluded from the conditions that cause a branch. I wouldn't expect any timing difference. On a segmented machine where pointers are being compared, relational compares are *faster*, since the compiler is allowed to assume that they are members of the same array, and hence the same segment. Equality compares have to check the segment part as well. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
karl@haddock.ima.isc.com (Karl Heuer) (10/02/90)
In article <1990Sep30.194448@IASTATE.EDU> john@IASTATE.EDU (Hascall John Paul) writes: >[Re ++x vs x++] I find myself using ++x (which in my mind I attribute to some >long gone, brain-damaged optimizer from my past -- but I still persist). I also prefer ++x, not because it's more efficient but because it's the conceptually simpler of the two: ++x is by definition x=x+1, while x++ is defined as (temp=x, x=x+1, temp). (Of course the arguments are the same: the reason for suspecting it *might* be less efficient is because it has the more complex semantics in the general case.) So ++x wins under the rule of "use the least powerful tool that does the job". (Btw, this is the same rule that makes GOTO a bad idea in most circumstances.) >My `favorite' is: --x; and x++; (pre-decrement, post-increment!!!) That's the other side of the coin. Many algorithms turn out to be simpler when described in terms of half-open intervals like [0,N). Stepping through such an interval is best done with post-decrement (*p++ or a[i++]) and pre-decrement (*--p or a[--i]), and it's reasonable to use this convention even when the value isn't being used (e.g. "if (*p == '-') p++", where the "p++" is conceptually "(void)*p++"). The important point: it's not worth fighting over. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
karl@haddock.ima.isc.com (Karl Heuer) (10/02/90)
In article <1990Oct1.174941.22195@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >What *can* make a difference is to run the loop backwards, algorithm >permitting: > for (x = 99; x >= 0; x--) In keeping with the idea that x is ranging through the half-open interval [0,100) rather than the closed interval [0,99], I often write this as for (x = 100; --x >= 0;) instead. (Possibly more efficient, too, since the decrement and the test are not separated by a basic-block-boundary, and hence the test instruction can be omitted on vaxlike architectures.) Note that with either Henry's example or mine you will lose big if x is an unsigned integer (and if you don't use lint to catch it). I usually use for (x = 100; x != 0; --x) on unsigned countdown loops where the index doesn't matter (i.e. just "do 100 times"); if you actually need the interval [0,100), for (x = 100; x-- != 0;) does the job (though probably less efficiently). Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
pmontgom@euphemia.math.ucla.edu (Peter Montgomery) (10/02/90)
In article <1990Oct1.174625.22061@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >There is an old prejudice against using "I" or "O" for a variable name, >arising from confusion with "1" and "0", but the lowercase letters don't >have that problem. The lowercase "l" should similarly be avoided. -- Peter L. Montgomery pmontgom@MATH.UCLA.EDU Department of Mathematics, UCLA, Los Angeles, CA 90024-1555 If I spent as much time on my dissertation as I do reading news, I'd graduate.
lerman@stpstn.UUCP (Ken Lerman) (10/02/90)
In article <1990Oct1.174625.22061@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: ->In article <1990Sep30.220839.20183@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: ->>Don't ever use single-character variable names. I use 'ix' for ->>loop index variables for which I can come up with no better name... -> ->In what way is "ix" superior to "i"? Both are meaningless names in ->this context. If the name is not going to be meaningful -- and in the ->context of a short loop, it's not clear that making it meaningful is ->either possible or particularly important -- then at least keep it short. -> ->There is an old prejudice against using "I" or "O" for a variable name, ->arising from confusion with "1" and "0", but the lowercase letters don't ->have that problem. ->-- ->Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology ->operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry I think I first saw this in one of Jerry Weinberg's books. Don't use two variable names which differ in only a single character. That way a one key typo won't hurt you. If you use a lot of single character variable names, one miskey and you have a syntactically valid program which does the wrong thing. Of course, using ix and iy has the same problem. Are "row" and "column" better variable names? Probably, but x and y are more convenient. :-) Do what I say, not what I do. :-) Ken
roy@phri.nyu.edu (Roy Smith) (10/02/90)
davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to > me that it is easier to tell if two values are unequal than to tell if > one is greater than the other. I'd rather save the machine a few > micro-seconds than myself since I only do the comparison once whereas the > machine must do it many times. Are there actually any machines in which a compare-and-branch for inequality is any faster or slower than a compare-and-branch for less-than? It seems to me that either should take one pass through the ALU to do the comparison and set some flags, so they should both take the same amount of time. I'm basing my assumption on experience with pdp-11 type machines, but I find it hard to imagine any other machine being significantly different. Maybe if you had an asynchronous ALU? The only scenario I could think of would be a RISC machine which has only two branches; branch-on-equal, and branch-on-less-than. The compiler could generate an appropriate stream of instructions to simulate any possible branch condition from just those two, and some streams might end up being longer than others, but that sounds pretty strange, and very un-orthogonal. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
manning@nntp-server.caltech.edu (Evan Marshall Manning) (10/02/90)
I wrote: >Don't ever use single-character variable names. I use 'ix' for >loop index variables for which I can come up with no better name... henry@zoo.toronto.edu (Henry Spencer) writes: >In what way is "ix" superior to "i"? Both are meaningless names in >this context. If the name is not going to be meaningful -- and in the >context of a short loop, it's not clear that making it meaningful is >either possible or particularly important -- then at least keep it short. If Henry asks it must not be as self evident as I thought. Hasn't this ever happened to you: You're thinking that you could apply what you just learned on the net and speed up this time-critical bit of code by changing the original cout-up loop to a count-down loop. "But wait," you say, "What if some later code depends on the value of 'i' after exiting the loop? I'll just search for the letter 'i' through 100 lines of source." You find that a lower case 'i' appears an average of about four times per comment line. 'ix' appears in the comments only when the comments are about variable 'ix'. Or, similarly, you 'grep' 'i'. What's actually happened to me more often is that lint tells me that a variable is not used in a procedure but I want to check that it is not used in any #ifdef'd code before removing the declaration. Doesn't this happen to anybody else? (I know Henry gets it all right the first time, but even he must inherit code, and inherited code always has declarations like "int i,j,k,l,ii,jj,kk,ll,m;" and no comments :-) *************************************************************************** Your eyes are weary from staring at the CRT for so | Evan M. Manning long. You feel sleepy. Notice how restful it is | is to watch the cursor blink. Close your eyes. The |manning@gap.cco.caltech.edu opinions stated above are yours. You cannot | manning@mars.jpl.nasa.gov imagine why you ever felt otherwise. | gleeper@tybalt.caltech.edu
jmann@angmar.sw.stratus.com (Jim Mann) (10/03/90)
In article <1990Oct2.163853.17004@nntp-server.caltech.edu>, manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: |>henry@zoo.toronto.edu (Henry Spencer) writes: |> |>If Henry asks it must not be as self evident as I thought. Hasn't this |>ever happened to you: You're thinking that you could apply what you |>just learned on the net and speed up this time-critical bit of code by |>changing the original cout-up loop to a count-down loop. "But wait," you |>say, "What if some later code depends on the value of 'i' after exiting |>the loop? I'll just search for the letter 'i' through 100 lines of |>source." You find that a lower case 'i' appears an average of about |>four times per comment line. 'ix' appears in the comments only when |>the comments are about variable 'ix'. Or, similarly, you 'grep' 'i'. |> If you are using the variable for something other than just a loop counter, you probably want to give it a better name than i or ix anyway. Yes, ix is easier to grep for or search for, but it is no easier than i to figure out when reading through the code. (In fact, it is probably less easy. If I see i, I generally assume that it is probably some sort of simple counter. If I see ix, I'll probably spend some time wondering why the programmer called it ix, what x stands for, etc.) Jim Mann Stratus Computer jmann@es.stratus.com
mutchler@zule.EBay.Sun.COM (Dan Mutchler) (10/03/90)
In article <1990Oct2.151644.1581@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to > me that it is easier to tell if two values are unequal than to tell if > one is greater than the other. I'd rather save the machine a few > micro-seconds than myself since I only do the comparison once whereas the > machine must do it many times. Are there actually any machines in which a compare-and-branch for inequality is any faster or slower than a compare-and-branch for less-than? It seems to me that either should take one pass through the ALU to do the comparison and set some flags, so they should both take the same amount of time. I'm basing my assumption on experience with pdp-11 type machines, but I find it hard to imagine any other machine being significantly different. Maybe if you had an asynchronous ALU? The only scenario I could think of would be a RISC machine which has only two branches; branch-on-equal, and branch-on-less-than. The compiler could generate an appropriate stream of instructions to simulate any possible branch condition from just those two, and some streams might end up being longer than others, but that sounds pretty strange, and very un-orthogonal. My experiece has been that compares are essentially a subtract (some early machines didn't actually have a compare) that sets the appropriate condition flags. So X!=100 is subtract 100 from X and branch not zero and X < 100 is subtract 100 from X and branch negative. If I remember correctly the cmp and sub instructions use the same number of clock cycles on the 8086. -- Dan Mutchler | ARPA/Internet: mutchler@zule.EBay.Sun.COM Sun Federal System Engineer | UUCP: ...!sun!mutchler -------------------------------------------------------------------------- Flying back from Lubbock, I saw Jesus on the plane Or maybe it was Elvis, You know they kind of look the same. -- Don Henley
poser@csli.Stanford.EDU (Bill Poser) (10/03/90)
If I were to see "ix", I would guess that it is really an integer "x" (e.g. an x coordinate) and that an ex-Fortran programmer is following his old naming conventions. I have some old code of mine containing stuff translated from Fortran that has variables named this way.
meissner@osf.org (Michael Meissner) (10/03/90)
In article <1990Oct2.151644.1581@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: | Are there actually any machines in which a compare-and-branch for | inequality is any faster or slower than a compare-and-branch for less-than? | It seems to me that either should take one pass through the ALU to do the | comparison and set some flags, so they should both take the same amount of | time. I'm basing my assumption on experience with pdp-11 type machines, | but I find it hard to imagine any other machine being significantly | different. Maybe if you had an asynchronous ALU? Yes, any computer based on the MIPS chipset (MIPS, DECstation, SGI) is faster to do a branch on both equality and inquality, than for the other comparison operators. | The only scenario I could think of would be a RISC machine which | has only two branches; branch-on-equal, and branch-on-less-than. The | compiler could generate an appropriate stream of instructions to simulate | any possible branch condition from just those two, and some streams might | end up being longer than others, but that sounds pretty strange, and very | un-orthogonal. Mips does not have a branch on a < b (unless b is 0). It has a set register to 1 if a < b instruction (& 0 otherwise). Thus to do the branch, you set the scratch register to be the value of a < b, and then do a branch on that register being zero. It does have a direct instruction to branch if two registers are equal or not equal. For example, consider the following program: int i, j, k, l, m, n; void foo(){ if (i < j) k++; if (l == m) n++; } It produces the following code after running it through the compiler and assembler: foo: File 'test-branch.c': 0: int i, j, k, l, m, n; 1: 2: void foo(){ 3: if (i < j) [test-branch.c: 4] 0x0: 8f8e0000 lw r14,0(gp) [test-branch.c: 4] 0x4: 8f8f0000 lw r15,0(gp) [test-branch.c: 4] 0x8: 00000000 nop [test-branch.c: 4] 0xc: 01cf082a slt r1,r14,r15 [test-branch.c: 4] 0x10: 10200005 beq r1,r0,0x28 [test-branch.c: 4] 0x14: 00000000 nop 4: k++; [test-branch.c: 5] 0x18: 8f980000 lw r24,0(gp) [test-branch.c: 5] 0x1c: 00000000 nop [test-branch.c: 5] 0x20: 27190001 addiu r25,r24,1 [test-branch.c: 5] 0x24: af990000 sw r25,0(gp) 5: 6: if (l == m) [test-branch.c: 7] 0x28: 8f880000 lw r8,0(gp) [test-branch.c: 7] 0x2c: 8f890000 lw r9,0(gp) [test-branch.c: 7] 0x30: 00000000 nop [test-branch.c: 7] 0x34: 15090005 bne r8,r9,0x4c [test-branch.c: 7] 0x38: 00000000 nop 7: n++; [test-branch.c: 8] 0x3c: 8f8a0000 lw r10,0(gp) [test-branch.c: 8] 0x40: 00000000 nop [test-branch.c: 8] 0x44: 254b0001 addiu r11,r10,1 [test-branch.c: 8] 0x48: af8b0000 sw r11,0(gp) 8: } [test-branch.c: 9] 0x4c: 03e00008 jr r31 [test-branch.c: 9] 0x50: 00000000 nop 0x54: 00000000 nop 0x58: 00000000 nop 0x5c: 00000000 nop From looking at the way the bits are set down, the blez (branch on less than or equal zero) and bgtz (branch on greater than zero) instructions could have been defined as ble and bgt, since the second register field is required to be 0 (and register $0 is hardwired to 0). I suspect the decision may have been due to chip real estate, and the fact that equality comparisons happen more frequently in real programs. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
donp@na.excelan.com (don provan) (10/03/90)
In article <1990Oct1.174625.22061@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Sep30.220839.20183@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >>Don't ever use single-character variable names. I use 'ix' for >>loop index variables for which I can come up with no better name... > >In what way is "ix" superior to "i"? Both are meaningless names in >this context. If the name is not going to be meaningful -- and in the >context of a short loop, it's not clear that making it meaningful is >either possible or particularly important -- then at least keep it short. The reason both are meaningless is because there *is* no context: this is just a code fragment. In practice, i've never encountered a loop that wasn't counting *something*, so why not name it? I agree that "ix" is nearly as bad as "i", and "loopindex" is worse than either. The fact that this variable is an index is its *least* interesting attribute. An index into *what*? *That's* the important point. My attitude is just the opposite of yours: to me, the shorter the loop is, the less excuse there is to choose a name because of it's length. If you're only going to be typing the name three or four times, what's the advantage keeping it a single character? Readability? don provan donp@novell.com
asylvain@felix.UUCP (Alvin E. Sylvain) (10/03/90)
In article <7341@darkstar.ucsc.edu> aryeh@cash.uucp (the over worked C something or another) writes: >Since I going to be doing my first team effort I want to know if this is bad >style: > for(x=0;x!=100;x++) ... > >-- >Aryeh Friedman aryeh@cash.ucsc.edu or >"ain't bug hunts the funnest" tsource@watnxt2.ucr.edu YES, is bad style. First off, *never* compare *exactly* against the end-value, *always* use <, or <=, as the case may be. This is due to the fact that occaisionally x may change within the loop (either deliberately, or accidentally). So, it advances to 97, 99, 101, 103, (oops, we passed 100!), ad infinitum. Secondly,putinmorespacesforreadability: for (x = 0; x < 100; x++) ... although I don't beef at people who prefer a bit less space: for (x=0; x<100; x++) ... and to REALLY get your style down to something maintainable, get rid of those so-called "magic numbers", e.g.: #define MAX_DOODLES 100 ... for (x = 0; x < MAX_DOODLES; x++) ... This can open an entire can of worms. You might as well get out your pen and paper and write down all your style questions, put them in a single posting, and request E-mail responses. Give it a week or so, then post a summary of your results. We'll be interested in seeing the opinions on this very, very personal subject! -- -=--=--=--"BANDWIDTH?? WE DON'T NEED NO STINKING BANDWIDTH!!"--=--=--=- "If you come in at 10am and leave at 7pm one day, then come in at 6am and leave at 3pm the next day, people will deduce that you are coming in at 10am and leaving at 3pm every day." --- me
mash@mips.COM (John Mashey) (10/03/90)
In article <MEISSNER.90Oct2140411@osf.osf.org> meissner@osf.org (Michael Meissner) writes: >In article <1990Oct2.151644.1581@phri.nyu.edu> roy@phri.nyu.edu (Roy >Smith) writes: > >| Are there actually any machines in which a compare-and-branch for >| inequality is any faster or slower than a compare-and-branch for less-than? >| It seems to me that either should take one pass through the ALU to do the >| comparison and set some flags, so they should both take the same amount of >| time. I'm basing my assumption on experience with pdp-11 type machines, >| but I find it hard to imagine any other machine being significantly >| different...... Well, they are different.... >Yes, any computer based on the MIPS chipset (MIPS, DECstation, SGI) is >faster to do a branch on both equality and inquality, than for the >other comparison operators. >Mips does not have a branch on a < b (unless b is 0). It has a set >register to 1 if a < b instruction (& 0 otherwise). Thus to do the >branch, you set the scratch register to be the value of a < b, and >then do a branch on that register being zero. It does have a direct >instruction to branch if two registers are equal or not equal. ....example.... >From looking at the way the bits are set down, the blez (branch on >less than or equal zero) and bgtz (branch on greater than zero) >instructions could have been defined as ble and bgt, since the second >register field is required to be 0 (and register $0 is hardwired to >0). I suspect the decision may have been due to chip real estate, and >the fact that equality comparisons happen more frequently in real >programs. OK, now the real reason is the cycle time tradeoff, which may or may not be relevant to other chips, because it depends on other decisions you have made. The R3000 worked pretty hard to get 1-cycle compare-and-branch for everything that it could, including such things as a micro-tlb because it couldn't do a lookup in the main tlb quite fast enough. SO, WHY does it have: 1. branch on a == b 2 registers 2. branch on a != b "" 3. branch on a <= 0 register & 0 4. branch on a > 0 "" 5. branch on a < 0 "" 6. branch on a >= 0 "" But not 7,8. branch on a < b, or a <= b ANS: 7-8 require a 32-bit subtract. 1-6 do not require any subtract, and can be implemented with logic that is faster than subtract, in less space. Note that 1 & 2 can be implemented by xoring a & b, and seeing if the resulting bits are all zero (1), or not all zero (2). Cases 5 & 6 need only test the sign bit. Cases 3 and 4 test the sign bit plus whether or not all other bits are 0. The timing was tight enough, for us, that a subtract as part of a compare-and-branch would have lengthened the cycle time, or would have added another branch delay cycle, losing more than the compensation gained by having the extra instruction. Deciding this took simulation, including noting that the most frequent (>50%) test is a == 0 or a != 0 (1 or 2), and that smart compilers can often turn some loop termninations from a <= N into a == N. Note that one must still include a compare instruction (in our case Set Less Than), that is essentially a subtract, but delivers the 0/1 indication to another register, and easily fits in the same timing as a normal subtract, but does not have to obtain the result quite as quickly as the compare-branch instructions must. See pages 106-107 in Hennessy & Patterson for further discussion. Again, note that this reasoning may or may not be valid for everybody, as it depends on the other architectural predecessors & expected implementation technologies. For example, I think HP PA chose the other direction. However, such choices are hardly random events, or people leaving things out for no particular reason. I recall this one got studied a lot, because conditional branches are important, and they tend not to go away, even with good optimizers. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
aglew@crhc.uiuc.edu (Andy Glew) (10/03/90)
..> Q: Are there machines where test for equality is faster than test for <, etc.? ..> A: yes. John Mashey explains, wrt. the MIPS R3000: > >1. branch on a == b 2 registers >2. branch on a != b "" >3. branch on a <= 0 register & 0 >4. branch on a > 0 "" >5. branch on a < 0 "" >6. branch on a >= 0 "" > >But not >7,8. branch on a < b, or a <= b > >... > > The timing was tight enough, for us, that a subtract as part of > a compare-and-branch would have lengthened the cycle time, > or would have added another branch delay cycle, losing > more than the compensation gained by having the extra instruction. Letting me harp on one of my favorite harping points: carry propagation is evil, and gets more evil as we move towards 64 bit machines. Besides carry, there is some small potential for making 1z. branch on a == 0 1 register 2z. branch on a != 0 "" as well as 3-6 above, faster than the class of 1 and 2, as well as faster than 7 and 8. 1z, 2z, and 3-6 can be precomputed, either at the time the value is created, or in a bit of slack time a little bit thereafter[*], and the result encoded in only a few bits - 6 if you want to be really slack, and only have to select a single bit at test time, fewer if you are willing to do a bit of encoding (more if you worry about signed/unsigned distinctions). These precomputed branch conditions can be stored as a few bits associated with the register. A logic function which is a function of only a few bits is usually faster than a function of many bits (as is required at branch time when comparing two variables for (in)equality). Moreover, these few bits can be associated with the branch logic, rather than with the rest of the register next to the ALU. Needless to say, you wouldn't do this unless you really had to. It can shave a bit off your cycle time for branches, but you don't really need to do that unless that is your critical time. As usual, simulate the tradeoffs. (Hint: scientific code does okay, pattern matching code tends to have tests for equality more often). [*] you wouldn't want to increase the latency of the results in order to do this precomputation. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
Don_A_Corbitt@cup.portal.com (10/03/90)
roy@phri.nyu.edu writes: > davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > > Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to > > me that it is easier to tell if two values are unequal than to tell if > > one is greater than the other. I'd rather save the machine a few > > micro-seconds than myself since I only do the comparison once whereas the > > machine must do it many times. > > Are there actually any machines in which a compare-and-branch for > inequality is any faster or slower than a compare-and-branch for less-than? > It seems to me that either should take one pass through the ALU to do the > comparison and set some flags, so they should both take the same amount of > time. I'm basing my assumption on experience with pdp-11 type machines, > but I find it hard to imagine any other machine being significantly > different. Maybe if you had an asynchronous ALU? [goes on to theorize about RISC machine with limited branch types] Actually, the i860 is faster when comparing for equality than greater-than. For example: xor r16, r17, r0 bc somewhere takes two clocks, plus one annulled after the branch if taken. The sequence subu r16, r17, r0 bc somewhere takes three clocks, since there is a freeze before the conditional branch while the condition code is updated. On this chip, adds/addu and subs/subu followed by a conditional branch costs an extra cycle. I haven't seen this in print, but I assume it is because there is extra delay waiting for carry propagation to set the condition code. XOR can test all the bits in parallel. --- Don_A_Corbitt@cup.portal.com Not a spokesperson for CrystalGraphics, Inc. Mail flames, post apologies. Support short .signatures, three lines max. (Soon leaving this account - flame me now, while you have the chance!)
john@IASTATE.EDU (Hascall John Paul) (10/03/90)
In article <18370@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > Note that with either Henry's example or mine you will lose big if x is an > unsigned integer (and if you don't use lint to catch it). I usually use > for (x = 100; x != 0; --x) > on unsigned countdown loops where the index doesn't matter (i.e. just "do 100 > times"); if you actually need the interval [0,100), > for (x = 100; x-- != 0;) > does the job (though probably less efficiently). I suppose this is so hideous that I shall be cursed forever for it... ;-) unsigned int x; for (x = 100; (int)--x > 0; ) -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50010 (515) 294-9551
karl@haddock.ima.isc.com (Karl Heuer) (10/03/90)
In <1990Oct2.192727@IASTATE.EDU> john@IASTATE.EDU (Hascall John Paul) writes: >In <18370@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: >>[Problems if it's unsigned; suggested ways to fix] > >I suppose this is so hideous that I shall be cursed forever for it... ;-) > unsigned int x; > for (x = 100; (int)--x > 0; ) Um, the "100" in this discussion is really just a placeholder for whatever the iteration count happens to be--and it would be nice if the algorithm would also work when the count is in the high range of an unsigned int. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
karl@haddock.ima.isc.com (Karl Heuer) (10/03/90)
In article <1990Oct2.163853.17004@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >henry@zoo.toronto.edu (Henry Spencer) writes: >>In what way is "ix" superior to "i"? Both are meaningless names ... > >If Henry asks it must not be as self evident as I thought. Hasn't this >ever happened to you: [You want to search for the variable "i" to see where >it's being used.] You find that a lower case 'i' appears an average of about >four times per comment line. Ah yes, that's a different problem. I solved it by improving my toolbox. >'ix' appears in the comments only when the comments are about variable 'ix'. Or when it mentions "Unix". Solution: Use searching tools that know about word boundaries. Both vi and emacs have such support. Some versions of grep can do it too. If yours doesn't, then write a filter that flags the beginning and end of each word with a special string, and use "wordflag | grep | wordunflag". (The last one can be a one-line sed script.) The next annoying problem is when you want to find the variable "n" or "s", and even in word-search mode you get false hits on strings like "%s\n". Write another tool that filters a C source and keeps track of the lexical state at all times. Mine distinguishes 8 states: {program text, character literal, string literal, comment} x {preprocessor line, real line}; the user selects which states are of interest. Exercise: By writing a word-flagging tool that can be used in a pipeline, rather than adding word-boundary recognition to grep, we have a more general tool that may have other applications. In keeping with this spirit, what should be the semantics of the C-lexing tool? Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
kreidler@motcid.UUCP (Joe Kreidler) (10/03/90)
zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") writes: >You know what they say: "Computers are very good at doing things >over and over and over again":-) >Shaving microseconds does not make better code. Better algorithms do. Tom brings up a very important point that people are missing. Stop and think for a second, "Why do I code in C instead of assembler?" I hope your answer is because C code is more portable, easier to develop, and easier to maintain. I do not know of anyone who uses C because it produces code that runs faster than assembler. As software systems keep getting larger and more complex, it is important to develop code that is easy to understand and can be ported to new applications. This comes at the cost of less efficeint code (when compared to assembler). If several microseconds are more important than portabability and maintainabliity, than use assembler. Otherwise, don't make such a fuss about which type of comparision generates faster code. Besides, a comparison that runs faster on one machine may be slower on a different machine. I am not saying that efficiency is not important for a C program. C programs should be written to run as fast as they can but this is accomplished through the design of efficient algorithms and data structures, not the choice of operators. ------------------------------------------------------------ Joe Kreidler 1501 W Shure Drive Motorola Cellular Arlington Heights, IL 60004 ...!uunet!motcid!kreidler 708-632-4664 ------------------------------------------------------------
richard@aiai.ed.ac.uk (Richard Tobin) (10/04/90)
In article <557@iccdev.indcomp.com> jd@iccdev.indcomp.com (J.D. Laub) writes: >john@IASTATE.EDU (Hascall John Paul) writes: >I beleive one HP optimizer manual recommened pre inc/dec, but I cannot >find the manual to confirm. Anyone know why they made this recommendation? Some processors have auto-increment/decrement addressing modes, and some of them do not have both pre- and post- forms. For example, (if I recall correctly) the PDP-11 had post-increment and pre-decrement, but not the other two. The asymmetry makes sense for implementing stacks. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
henry@zoo.toronto.edu (Henry Spencer) (10/04/90)
In article <1990Oct2.163853.17004@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >>In what way is "ix" superior to "i"? Both are meaningless names in >>this context. If the name is not going to be meaningful -- and in the >>context of a short loop, it's not clear that making it meaningful is >>either possible or particularly important -- then at least keep it short. > >... speed up this time-critical bit of code by >changing the original cout-up loop to a count-down loop. "But wait," you >say, "What if some later code depends on the value of 'i' after exiting >the loop? ... Two observations: 1. There is much to be said for search primitives that know about word or token boundaries. 2. Variables used over wide sections of code need more attention to clear naming than variables used only in a short loop. >Doesn't this happen to anybody else? (I know Henry gets it all right >the first time, but even he must inherit code, and inherited code >always has declarations like "int i,j,k,l,ii,jj,kk,ll,m;" and no >comments :-) Coding rules are no substitute for competence. Incompetently-written code is a pain to maintain whether or not its author followed some well-meant set of rules. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
peter@ficc.ferranti.com (Peter da Silva) (10/04/90)
In article <2039@excelan.COM> donp@novell.com (don provan) writes: > If you're only going to be typing the name three or four times, what's > the advantage keeping it a single character? Readability? Readability, to some extent. People are used to this notation from mathematics, and this provides the necessary context. If you give it a "real" name then you start to wonder what it might be used for outside the loop. I, myself, tend to use "i", "j", and so on for indices in loops, and named variables for anything that has a scope outside the loop. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (10/04/90)
In <1990Oct1.174625.22061@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In what way is "ix" superior to "i"? Not only is "ix" not superior to "i", but it is in fact much inferior. Anybody with a mathematical (or FORTAN ;-) background, upon seeing "i", will immediately and subconsciously react, "Ah! We're acting on the i-th element in a series!". But when I see "ix", I say to myself, "ix?? What's ix??". -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
bumby@math.rutgers.edu (Richard Bumby) (10/04/90)
In article <A066MF5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > In article <2039@excelan.COM> donp@novell.com (don provan) writes: > > If you're only going to be typing the name three or four times, what's > > the advantage keeping it a single character? Readability? > > Readability, to some extent. People are used to this notation from > mathematics, and this provides the necessary context. If you give it a > "real" name then you start to wonder what it might be used for outside > the loop. . . . Two comments: (1) Isn't it about time that we all got together and insisted that the mathematical convention is WRONG. Most mathematical exposition would benefit from free use of words, rather than letters, as primitive symbols. (2) I found some programs that did a job for which I intended to write my own utilities, and found that they contained a device that I had not seen elsewhere; and, in spite of my admiration for the programmer, I'm not sure I like. The program contained many short loops. Each loop used a mathematics-style index like 'i'. The curious feature was that the loop and local declaration of i were made into a block. This had the advantages of emphasizing the limited scope of the index variable and putting the declaration in the most natural (?) place, but the disadvantage of introducing an extra level of structure into the program. It would seem that this increases clarity when the loops are very short, and has very much the opposite effect otherwise. -- --R. T. Bumby ** Math ** Rutgers ** New Brunswick ** NJ08903 ** USA -- above postal address abbreviated by internet to bumby@math.rutgers.edu voice communication unreliable -- telephone ignored -- please use Email
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/04/90)
In article <Oct.3.22.06.40.1990.21194@math.rutgers.edu> bumby@math.rutgers.edu (Richard Bumby) writes: > Most mathematical > exposition would benefit from free use of words, rather than letters, > as primitive symbols. You're free to use short names, like sin, cos, or foo, without confusing anybody. But Peter's point is correct: using more than one letter for a local index hurts readability, just as it's hard to read a book in 48-point type. > The curious feature was that the loop and local declaration > of i were made into a block. This had the advantages of emphasizing > the limited scope of the index variable and putting the declaration in > the most natural (?) place, but the disadvantage of introducing an > extra level of structure into the program. I use this ``curious'' technique when I see a very strong procedural orientation within the main body of a program, but not enough to warrant separate procedures. Wtf is the disadvantage of introducing structure into a program? ---Dan
browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) (10/04/90)
davis@pacific.mps.ohio-state.edu (John E. Davis) writes: > Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to > me that it is easier to tell if two values are unequal than to tell if > one is greater than the other. I'd rather save the machine a few > micro-seconds than myself since I only do the comparison once whereas the > machine must do it many times. I'm distressed by the emphasis on this question in quite a number of recent postings. The question, though answerable for each specific machine, seems to me to be quite beside the point. The _right_ question, IMAO, is not which takes fewer machine cycles but which is better understood. If program A runs a millisecond faster than program B but does the wrong thing, A is not the better program. If programs A and B are both correct, A runs a millisecond faster, but A is harder to understand, B is still the better program IMO. When hesitating between two styles, I believe that _in general_ these questions are the ones to ask, in descending order of priority: 1. Which is correct? Assuming they both are, then-- 2. Which is clearer? (If I have to convince somebody else that this code does what I think, which one will make the job easier? If somebody else has to change the code six months from now, which version will be less likely to be changed wrongly? If I or someone else must look at the code a year from now and try to figure out what it does, which version will more readily yield its secrets? N.B. Comments can help, but good comments do not redeem needlessly obscure code, because the comments may not match what the code actually does!) If neither version is clearly clearer than the other, then-- 3. Which is faster? Note that I said _in general_ above. There are some qualifications. First, in some few systems it may actually be essential to squeeze the last microsecond out of the application. Second, though I think 2. is much more important than 3. in most applications, if a small increase in complexity means a large decrease in run time I may accept the former to get the latter. In _The Elements of Style_, Kernighan and Plauger talked a lot about misguided attempts by prrogrammers to write "efficient" code. K & P's response, shown over and over by actual benchmarks, was that clean, readily understandable code is frequently faster than code hand "optimized" by the programmer. With the example we have in hand, the question is trivial because the chance of misunderstanding either version is pretty slim. But in more realistic situations, I go for clarity over "efficiency" almost every time. To paraphrase (or twist) Franklin, "Those who give up a little clarity to gain a little efficiency generally lose both clarity and efficiency." So answering John Davis's question, which I think was not originally his, I don't care which is faster but I'll pick x<100 rather than x!=100 because that's the way most C programmers write, therefore it's more likely to be understood at a glance. The above is my own opinion and not attributable to any other person or organization. email: browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A. (216) 371-0043
browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) (10/04/90)
In article <1990Oct2.163853.17004@nntp-server.caltech.edu>, manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: > I wrote: >>Don't ever use single-character variable names. I use 'ix' for >>loop index variables for which I can come up with no better name... > > henry@zoo.toronto.edu (Henry Spencer) writes: >>In what way is "ix" superior to "i"? Both are meaningless names in >>this context. If the name is not going to be meaningful -- and in the >>context of a short loop, it's not clear that making it meaningful is >>either possible or particularly important -- then at least keep it short. > > If Henry asks it must not be as self evident as I thought. Hasn't this > ever happened to you: You're thinking that you could apply what you > just learned on the net and speed up this time-critical bit of code by > changing the original cout-up loop to a count-down loop. "But wait," you > say, "What if some later code depends on the value of 'i' after exiting > the loop? I'll just search for the letter 'i' through 100 lines of > source." You find that a lower case 'i' appears an average of about > four times per comment line. 'ix' appears in the comments only when > the comments are about variable 'ix'. Or, similarly, you 'grep' 'i'. I think the question here is not, "Should one-letter loop variable names be allowed?" The question, IMO, is "Should variable names (including names of loop variables) be meaningful?" If the counter is used only within the context of the loop, _especially_ as an array subscript, then I think "i" is a _good_ choice, not just an acceptable one. Why? Because since Algebra I we've all been used to "i" as a subscript for things like summation, where the result is some property of the array. But if the counter is used outside the loop, then I think "i" is a _bad_ choice. Examples I would approve: 1. for (total=0,i=0; i<array_size; ++i) total += array[i]; (I think something like "array_index" instead of "i" would be worse.) 2. for (location=0; location<array_size; ++location) if (array[location] == value_searched_for) break; if (location >= array_size) printf(... error message (In a real context, I'd use something more meaningful than "location". But you get the idea) BTW, I know 2 could be coded shorter in a one-line "for" followed by a null statement, like this: for (location=0; location<array_size && array[location]!=value_searched_for; ++location) ; But it obscures the marching through the array, it won't all fit on an 80-column line, and it requires me to test for the negation of the condition I'm actually interested in. And it's no more efficient since it generates the same code as what I typed above. So to my mind it's inferior to what I typed in 2. above. The above is my own opinion and not attributable to any other person or organization. email: browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A. (216) 371-0043
manning@nntp-server.caltech.edu (Evan Marshall Manning) (10/04/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >>In what way is "ix" superior to "i"? dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >Not only is "ix" not superior to "i", but it is in fact much >inferior. Anybody with a mathematical (or FORTAN ;-) background, upon >seeing "i", will immediately and subconsciously react, "Ah! We're >acting on the i-th element in a series!". But when I see "ix", I say >to myself, "ix?? What's ix??". And this is where the combination of a background in FORTRA[N|SH] and variables named "i" will bite you. In C it's the (i+1)th element in the series. Perhaps semi-reformed FORTRAN programmers need to avoid "i" more than anyone else. :-) *************************************************************************** Your eyes are weary from staring at the CRT for so | Evan M. Manning long. You feel sleepy. Notice how restful it is | is to watch the cursor blink. Close your eyes. The |manning@gap.cco.caltech.edu opinions stated above are yours. You cannot | manning@mars.jpl.nasa.gov imagine why you ever felt otherwise. | gleeper@tybalt.caltech.edu
peter@ficc.ferranti.com (Peter da Silva) (10/04/90)
In article <Oct.3.22.06.40.1990.21194@math.rutgers.edu> bumby@math.rutgers.edu (Richard Bumby) writes: > In article <A066MF5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > > Readability, to some extent. People are used to this notation from > > mathematics, ... > Two comments: (1) Isn't it about time that we all got together and > insisted that the mathematical convention is WRONG. Given the some-hundred-years head start mathematics has on CS, I'm not sure this is a valid point. In fact, Mathematics started off using names and phrases for what we would call variables. The term rebus comes from the latin "rebus"... "the thing"... that being the typical start to what we would now call "word problems". "The thing" does this, "the thing" does that. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (10/05/90)
In <1990Oct4.152246.438@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >And this is where the combination of a background in FORTRA[N|SH] and >variables named "i" will bite you. In C it's the (i+1)th element in >the series. Er, no. Some series start with a zero-eth element. They do, they really do. Not in Fortran, perhaps, but in mathematics, yes. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
friedl@mtndew.Tustin.CA.US (Steve Friedl) (10/05/90)
In article <4762@navy8.UUCP>, kreidler@motcid.UUCP (Joe Kreidler) writes: > > As software systems keep getting larger and more complex, it is > important to develop code that is easy to understand and can be ported > to new applications. This comes at the cost of less efficient code > (when compared to assembler). This is seductive but true only superficially. Q: Given two equally-talented teams of programmers, one using C and one using assembler, which team will produce the system with best execution time for a non-trivial program? A: The team writing in C. While the assembler folks are busy optimizing that inner loop, the C people are testing three different algorithms to see which one is *really* faster. Steve -- Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "There are no technical problems that marketing can't overcome" - Gary W. Keefe
dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) (10/05/90)
In article <29106:Oct404:03:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <Oct.3.22.06.40.1990.21194@math.rutgers.edu> bumby@math.rutgers.edu (Richard Bumby) writes: >> The curious feature was that the loop and local declaration >> of i were made into a block. This had the advantages of emphasizing >> the limited scope of the index variable and putting the declaration in >> the most natural (?) place, but the disadvantage of introducing an >> extra level of structure into the program. > >separate procedures. Wtf is the disadvantage of introducing structure >into a program? > None. Structure is great. Unfortunately, some debuggers don't understand declarations that are not at the start of functions. Bummer. -- Dave Eisen Home: (415) 323-9757 dkeisen@Gang-of-Four.Stanford.EDU Office: (415) 967-5644 1447 N. Shoreline Blvd. Mountain View, CA 94043
dik@cwi.nl (Dik T. Winter) (10/05/90)
In article <2544@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > In <1990Oct4.152246.438@nntp-server.caltech.edu> > manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: > >And this is where the combination of a background in FORTRA[N|SH] and > >variables named "i" will bite you. In C it's the (i+1)th element in > >the series. > Er, no. Some series start with a zero-eth element. They do, they > really do. Not in Fortran, perhaps, but in mathematics, yes. Er, no. Two points actually. The first is, also fortran knows about arrays starting with index 0 (since 1978 at least). The zero-th point is, what do you mean with i-th element? Element with index i or the i-th element counting from the start with the first element, both are equally valid? -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
meissner@osf.org (Michael Meissner) (10/06/90)
In article <537@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve Friedl) writes: | In article <4762@navy8.UUCP>, kreidler@motcid.UUCP (Joe Kreidler) writes: | > | > As software systems keep getting larger and more complex, it is | > important to develop code that is easy to understand and can be ported | > to new applications. This comes at the cost of less efficient code | > (when compared to assembler). | | This is seductive but true only superficially. | | Q: Given two equally-talented teams of programmers, one using C and | one using assembler, which team will produce the system with best | execution time for a non-trivial program? | | A: The team writing in C. While the assembler folks are busy optimizing | that inner loop, the C people are testing three different algorithms | to see which one is *really* faster. Or even: A: The team writing in C has already produced two or three revisions, changing the code so that it gives the customer what s/he wants, instead of what s/he asked for. Also a possibility: A: The team writing in C, since the team writing in C has switched to a new hardware platform that is not upwards compatible with the previous platform, but it twice as fast.... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
jrv@sdimax2.mitre.org (VanZandt) (10/06/90)
In article <1990Oct2.163853.17004@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: >Don't ever use single-character variable names. I use 'ix' for >loop index variables for which I can come up with no better name... [if you do a text search for 'i'...] >you find that a lower case 'i' appears an average of about >four times per comment line. 'ix' appears in the comments only when >the comments are about variable 'ix'. Or, similarly, you 'grep' 'i'. What you need is a "whole word mode" for the search command in your text editor. I came to the same conclusion, bought the source code for my editor, and implemented it myself. Very helpful. BTW, if you have regular expression search, you can fake it by searching for <non alphanumeric character>i<non alphanumeric character>. - Jim Van Zandt
jlg@lanl.gov (Jim Giles) (10/06/90)
From article <2544@cirrusl.UUCP>, by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi): > In <1990Oct4.152246.438@nntp-server.caltech.edu> > manning@nntp-server.caltech.edu (Evan Marshall Manning) writes: > >>And this is where the combination of a background in FORTRA[N|SH] and >>variables named "i" will bite you. In C it's the (i+1)th element in >>the series. > > Er, no. Some series start with a zero-eth element. They do, they > really do. Not in Fortran, perhaps, but in mathematics, yes. Some series begin with zero in Fortran as well. It is only C in the family of commonly available languages which doesn't allow the user to decide for himself what the subscript range of an array should be. Fortran, Pascal, Modula, Ada, etc., all allow the subscript range to have independent lower and upper bounds set for each rank of an array. Most of these languages require both bounds to be explicitly specified in the declaration. Fortran allows the extent to be given alone - in which case the lower bound of 0ne (1) is selected as a default. J. Giles
jlg@lanl.gov (Jim Giles) (10/06/90)
From article <MEISSNER.90Oct5151114@osf.osf.org>, by meissner@osf.org (Michael Meissner): > In article <537@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve > Friedl) writes: > [...] | | This is seductive but true only superficially. | | | | Q: Given two equally-talented teams of programmers, one using C and | | one using assembler, which team will produce the system with best | | execution time for a non-trivial program? | | | | A: The team writing in C. While the assembler folks are busy optimizing | | that inner loop, the C people are testing three different algorithms | | to see which one is *really* faster. | | Or even: | | A: The team writing in C has already produced two or three revisions, | changing the code so that it gives the customer what s/he wants, | instead of what s/he asked for. | | Also a possibility: | | A: The team writing in C, since the team writing in C has switched to | a new hardware platform that is not upwards compatible with the | previous platform, but it twice as fast.... But the answer generally found by experience is that the assembly is faster. The C language is so full of pitfalls that it usually takes as long to get a working version of _any_ algorithm written in C as it does to write it in assembly. There is a popular word processor which was originally written in assembly. They decided to invest a lot of money to produce a C version (to which end, they hired a lot of C 'gurus' so as not to be handicapped by lack of experience with the language). They confidently predicted the C version would be ready before the next release of the assembly version and would be nearly as fast. The C version actually took longer to write than the next _two_ major assembly version upgrades. The C version is considerably slower as well (like doing a global search and having to wait 10 seconds instead of instant response - the kind of thing that wastes considerable time for anyone unfortunate enough to be forced to use it). It is true that the C version has been ported to other machines - but what is the good of that? All they have is a slow word processor on more than one platform - it doesn't compete well with the native products on any machine. Meanwhile, their assembly version still sells well. As far as I can tell, this is a typical experience. J. Giles
poser@csli.Stanford.EDU (Bill Poser) (10/06/90)
Jim Giles says that "Fortran" allows specification of array bounds. That depends on what you mean by "Fortran". That is definitely not true of the classic Fortran that we know and hate. Fortran 77 adopted many features of more advanced languages, and Fortran 90 is going farther still. Fortran is a moving target because each standardization introduces what in other contexts would be considered a new language. Compare the relatively small differences between Pascal and Modula-2 to the huge changes that have been made in "Fortran".
sarima@tdatirv.UUCP (Stanley Friesen) (10/06/90)
In article <1275.270afcdb@iccgcc.decnet.ab.com> browns@iccgcc.decnet.ab.com (Stan Brown, Oak Road Systems) writes: >davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >> Which ['x != 100' or 'x < 100' RHS] generates faster code? >When hesitating between two styles, I believe that _in general_ these >questions are the ones to ask, in descending order of priority: > > 1. Which is correct? ... > 2. Which is clearer? ... > 3. Which is faster? I think you missed an important question: 1.5 Which is more robust? - that is which form is less likely to lead to a bug being introduced later? This is *not* the same as question #1, since both can be correct *now* and still differ as to roubustness. In this particular case this is the situation. 'x != 100' used in a loop (as the original question asked) is *dangerous*. If the loop should happen to increment x somehere other than the loop control, the resulting loop will likely be infinite! The 'x < 100' form guarentees that no matter how the loop is modified later it will terminate correctly, rather than hang the program (or worse). Have pity on the maintainer and use the robust form! -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
jlg@lanl.gov (Jim Giles) (10/06/90)
From article <15689@csli.Stanford.EDU>, by poser@csli.Stanford.EDU (Bill Poser): > Jim Giles says that "Fortran" allows specification of array bounds. > [...] > Fortran is a moving target > because each standardization introduces what in other contexts > would be considered a new language. [...] Yes, Fortran is a moving target. But, if you aren't up to where it was 12 years ago, you need to do some work on your tracking and target acquisition. When I complain that C doesn't have features that I consider important, one of the usual responses I get is that ANSI C does and it unfair of me to condemn C because of what _used_ to be its failings. Well, ANSI C only came into existence this January! Turn- about is fair play. If a 12 year old feature is to be regarded as still missing from Fortran, then 12 year old C implementations should be regarded as representative of that language. J. Giles
poser@csli.Stanford.EDU (Bill Poser) (10/06/90)
In article <65030@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >Yes, Fortran is a moving target. But, if you aren't up to where it >was 12 years ago, you need to do some work on your tracking and target >acquisition. When I complain that C doesn't have features that I >consider important, one of the usual responses I get is that ANSI C >does and it unfair of me to condemn C because of what _used_ to be its >failings. Well, ANSI C only came into existence this January! Turn- >about is fair play. If a 12 year old feature is to be regarded as >still missing from Fortran, then 12 year old C implementations should >be regarded as representative of that language. Well, my comment was mainly about what people mean when they refer to "Fortran". Rightly or wrongly, to a lot, perhaps most, of the people outside of the Fortran community, Fortran means Fortran IV or maybe Fortran 77. But I'm curious as to which features these are that are not in Classic C and are in ANSI C that you are always referred to. The only one that comes to mind from the discussion I have followed is noalias. Although ANSI C has some nice improvements, I don't find it terribly different from Classic C. Offhand, I would say that function prototypes are the most important innovation. Some of the other changes that are formalized in the standard occurred in practice much earlier. For example, I don't think that I have EVER used a compiler that didn't provide the void type, even though it is technically an innovation. Indeed, although the standard only came into existence in January, implementations conforming to it in most respects, containing most of the innovations, have been around for some years. Is that true of Fortran-88/90 or whatever it will be called when it is done?
henry@zoo.toronto.edu (Henry Spencer) (10/07/90)
In article <65019@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >... The C language is so full of pitfalls that it usually takes >as long to get a working version of _any_ algorithm written in C as it >does to write it in assembly. Only for people who think in Fortran. In case you didn't notice, Jim, portability was a fortuitous afterthought in C. Its original motive was easier programming than assembler. It succeeded at that; it wiped out assembler within Unix not due to concerns about portability -- that was still far in the future -- but simply because it was easier to work with. This is with experienced programmers, mind you; it is not an easy language for novices (even those with plenty of experience programming in other languages). Your claims are contrary to observed fact. C succeeded by being superior, not by being portable or by official decree; in many shops it had an uphill battle to displace languages which were supposedly more efficient, more portable, or more standard. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (10/07/90)
Q: Given two equally-talented teams of programmers, one using C and
one using assembler...
A seriously flawed question.
(a) Either compare "compiler" with "assembler", or compare "C" with
"assembly language". (This is admittedly a small point, but it's a
point.)
(b) When speed and programming efficiency are both a concern, it's
silly to program only in C or only in assembly language. One writes
in a high-level language and then optimizes inner loops with assembly
code as appropriate. The old controversy became moot when people
realized this.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesiaglew@crhc.uiuc.edu (Andy Glew) (10/08/90)
>> Which ['x != 100' or 'x < 100' RHS] generates faster code? It seems to >> me that it is easier to tell if two values are unequal than to tell if >> one is greater than the other. I'd rather save the machine a few >> micro-seconds than myself since I only do the comparison once whereas the >> machine must do it many times. > >I'm distressed by the emphasis on this question in quite a number of >recent postings. The question, though answerable for each specific >machine, seems to me to be quite beside the point. The emphasis on shaving nanoseconds comes mainly from readers of the comp.arch group, to which the article was cross-posted. Comp.arch readers are concerned with how to build the fastest possible hardware, and how to write compilers to produce the fastest possible code on that hardware. Ideally, of course, your compiler will generate a=b tests (if they are faster) even though you write a<=b tests (assuming that the compiler can prove equivalence). -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) (10/08/90)
In article <1990Oct6.231143.28186@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > > but simply because (C) >it was easier to work with. This is with experienced programmers, mind you; >it is not an easy language for novices (even those with plenty of experience >programming in other languages). Amen to that! I came to C with strong skills in five other languages, including Pascal and Fortran. Initially I said: "one computer language is much the same as another, C should be easy to learn". Well, its two and a half years since I started with C and about one year of using it for applications. In that time I've only been able to make an intermediate grade. It really is amazing how versital the language is - and how complex. I am curious about two thing here. For those people who have used C for *at least* one year: First: what skill level did you have with the language after one, two, three, four and five years? Second: what was you skill level with the Unix O/S? (Yes, I know there are DO/S and VMS'ers out there. But, I'm mainly intrested in Unix). -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak If something is worth doing, it's worth doing correctly.
jlg@lanl.gov (Jim Giles) (10/10/90)
From article <1990Oct6.231143.28186@zoo.toronto.edu>, by henry@zoo.toronto.edu (Henry Spencer): > In article <65019@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>... The C language is so full of pitfalls that it usually takes >>as long to get a working version of _any_ algorithm written in C as it >>does to write it in assembly. > [...] Your claims are contrary to observed fact. > [...] No, actually not. The _only_ cases I'm aware of in which C was actually used in a direct comparison with other languages, C has been less easy to use. It is _your_ claims that don't seem to have any empirical evidence behind them. In the _very_ early days of C, it may have compared well to the PDP-8 assembler - mostly because it way practically an upward compatible extension of that assembler. But, I don't know of any attempts that religious C fanatics have made to show any advantage to the language since then. As I say, I'm aware of several extensive commercial codes which have done _worse_ under C (after an expensive switch). I don't know of any such experiments which went in _favor_ of C. > [...] > C succeeded by being superior, not by being portable or by official decree; > in many shops it had an uphill battle to displace languages which were > supposedly more efficient, more portable, or more standard. I will assume you're speaking the truth (from some personal experience). I don't know of any shops in which C fought an 'uphill battle'. I know of lots of places where it was mandated from above (by managers who didn't know the problems and wouldn't have to do the coding anyway). In most of these cases, C was less efficient and less portable than what it replaced. It was also much harder to use. In any case, this is not a technical discussion - just a religious battle - so I'll just bow out of any further discussion on this subject. J. Giles
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (10/11/90)
HEY!!! This subject line, "Re: a style question", has split itself off into at least two completely different threads! One talks about FORTRAN (sorry to curse on the net, but it hadda be said), and another compares efficiency of C versus assembly language (sorry again). What's this got to do with "for(x=0;x!=100;x++)", the original question? Nothing! C'mon folks, I'm sure you're aware that you can *edit* the *Subject* line?! -- =======================Standard Disclaimers Apply======================= "We're sorry, but the reality you have dialed is no | Alvin longer in service. Please check the value of pi, | "the Chipmunk" or pray to your local diety for assistance." | Sylvain = = = = = =I haven't the smoggiest notion what my address is!= = = = = =
peter@ficc.ferranti.com (Peter da Silva) (10/12/90)
In article <65263@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > In the _very_ early days of C, it may have compared well to the PDP-8 > assembler - mostly because it way practically an upward compatible > extension of that assembler. Talking of contrary to observed fact: the PDP-8 had no part in the development of the C programming language. Perhaps you're thinking of the PDP-11. > I will assume you're speaking the truth (from some personal experience). > I don't know of any shops in which C fought an 'uphill battle'. C is fighting an uphill battle against PL/M right here, right now. Ever used PL/M? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
robert@isgtec.UUCP (Robert A. Osborne) (10/12/90)
In article <4132@sactoh0.SAC.CA.US> jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) writes: >First: what skill level did you have with the language after one, two, >three, four and five years? On a scale of tyro to Henry? :-) I found that increases in my C skills were not so much a matter of time as of events; ie. all of the following resulted in a large increase: initial exposure (3 years ago) changing companies (2.5 years ago) net access (1+ year ago) subscribing to comp.lang.c (1 year ago) Indian Hill Style Guide (1- year ago) even though there was little time between the last three events. Also, it's incrediable how much you can learn by debugging a project written by several people or by modifing stuff off the net. Rob. -- Robert A. Osborne ...uunet!utai!lsuc!isgtec!robert or robert@isgtec.uucp
meissner@osf.org (Michael Meissner) (10/12/90)
In article <EYC66N8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: | Path: paperboy!snorkelwacker!usc!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!nuchat!sugar!ficc!peter | From: peter@ficc.ferranti.com (Peter da Silva) | Newsgroups: comp.lang.c | Date: 12 Oct 90 03:11:50 GMT | References: <1990Oct6.231143.28186@zoo.toronto.edu> <65263@lanl.gov> | Reply-To: peter@ficc.ferranti.com (Peter da Silva) | Organization: Xenix Support, FICC | Lines: 15 | | In article <65263@lanl.gov> jlg@lanl.gov (Jim Giles) writes: | > In the _very_ early days of C, it may have compared well to the PDP-8 | > assembler - mostly because it way practically an upward compatible | > extension of that assembler. | | Talking of contrary to observed fact: the PDP-8 had no part in the | development of the C programming language. Perhaps you're thinking | of the PDP-11. Or if you know your UNIX pre-history, the PDP-7. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
lfd@cbnewsm.att.com (leland.f.derbenwick) (10/13/90)
In article <MEISSNER.90Oct12120812@osf.osf.org>, meissner@osf.org (Michael Meissner) writes: > In article <EYC66N8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > > [ ... ] > | In article <65263@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > | > In the _very_ early days of C, it may have compared well to the PDP-8 > | > assembler - mostly because it way practically an upward compatible > | > extension of that assembler. > | > | Talking of contrary to observed fact: the PDP-8 had no part in the > | development of the C programming language. Perhaps you're thinking > | of the PDP-11. > > Or if you know your UNIX pre-history, the PDP-7. Bzzzt. Thank you for playing. To quote Ritchie, Johnson, Lesk, and Kernighan ("The C Programming Language", _Bell System Technical Journal_ Vol. 57, No. 6, July- August 1978, p. 1991): C was originally written for the PDP-11 under UNIX... and to quote Ritchie ("The Evolution of the UNIX Time-sharing System", _AT&T Bell Laboratories Technical Journal_ Vol. 63, No. 8 Part 2, p. 1591-2): Every program for the original PDP-7 UNIX was written in assembly language...[description of Thompson creating B on the PDP-7 omitted] When the PDP-11 arrived, B was moved to it almost immediately. ...Thus, in 1971, work began on what was to become the C language... (BTW, the PDP-11 purchase was justified for use as a word-processing system for the legal department: for all that people complain about how "obscure" and "difficult" the Unix system is, it was being used routinely by a group of secretaries in 1971.) One of the main heritages of the PDP-11 is that most people use the constructs "*p++" and "*--p" more often than "*++p" and "*p--"; for char or int arguments, the first two could be compiled into a single PDP-11 instruction, while the other two required an extra instruction. (Of course, if C were really intended only as a structured assembler, the two forms that didn't conform to the instruction set would never have been included.) -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
peter@ficc.ferranti.com (Peter da Silva) (10/13/90)
In article <EYC66N8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > Talking of contrary to observed fact: the PDP-8 had no part in the > development of the C programming language. Perhaps you're thinking > of the PDP-11. In article <MEISSNER.90Oct12120812@osf.osf.org> meissner@osf.org (Michael Meissner) writes: > Or if you know your UNIX pre-history, the PDP-7. Hold on, wasn't the PDP-7 version entirely assembly? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) (10/13/90)
In article <MMD65CB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: }In article <EYC66N8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: }> Talking of contrary to observed fact: the PDP-8 had no part in the }> development of the C programming language. Perhaps you're thinking }> of the PDP-11. } }In article <MEISSNER.90Oct12120812@osf.osf.org> meissner@osf.org (Michael Meissner) writes: }> Or if you know your UNIX pre-history, the PDP-7. } }Hold on, wasn't the PDP-7 version entirely assembly? }-- }Peter da Silva. `-_-' }+1 713 274 5180. 'U` }peter@ferranti.com All you have to do is read page 1 of K&R 2nd ed. (page 2 in 1st ed.): "The influence of BCPL on C proceeded indirectly through the language B, which was written by Ken Thompson in 1970 for the first UNIX system on the DEC PDP-7." And in the preface, "C was originally designed for and implemented on the UNIX operating system on the DEC PDP-11..."
bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) (10/13/90)
In article <1990Oct12.225501.15701@cbnewsm.att.com> lfd@cbnewsm.att.com (leland.f.derbenwick) writes: }[various writers' theories about the origins of C] } }Bzzzt. Thank you for playing. } }[correct pedigree presented] } }(BTW, the PDP-11 purchase was justified for use as a word-processing }system for the legal department: for all that people complain about }how "obscure" and "difficult" the Unix system is, it was being used }routinely by a group of secretaries in 1971.) Bzzzt. Thank you for playing. Running a word processor (if that's what they called it back then) and use of basic file manipulation commands can hardly be described as "using" an operating system in any meaningful sense of the word. In any case, I take exception to your implication that secretaries are incapable of dealing with anything that is "obscure" or "difficult." The fact that they did it says much more about the secretaries than it does about Unix.
byron@archone.tamu.edu (Byron Rakitzis) (10/15/90)
In article <1990Oct12.225501.15701@cbnewsm.att.com> lfd@cbnewsm.att.com (leland.f.derbenwick) writes: > >One of the main heritages of the PDP-11 is that most people use >the constructs "*p++" and "*--p" more often than "*++p" and "*p--"; >for char or int arguments, the first two could be compiled into a >single PDP-11 instruction, while the other two required an extra >instruction. (Of course, if C were really intended only as a >structured assembler, the two forms that didn't conform to the >instruction set would never have been included.) > > -- Speaking strictly for myself, > -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ This is not true for the PDP-11 alone. Don't several architectures (notably the VAX) support predecrement and postincrement register addressing modes? Correct me if I'm wrong, but I thought the m68k was the same way. Of course, on a RISC, the post- form will fill the delay slot with the increment/decrement. This is equally true for incrementing and decrementing though. So perhaps we will be seeing more of "*p++" and "*p--"... --- Byron Rakitzis.
karl@haddock.ima.isc.com (Karl Heuer) (10/18/90)
In article <1990Oct12.225501.15701@cbnewsm.att.com> lfd@cbnewsm.att.com (leland.f.derbenwick) writes: >One of the main heritages of the PDP-11 is that most people use >the constructs "*p++" and "*--p" more often than "*++p" and "*p--"; I disagree. My perception is that using half-open intervals (closed on the left) simplifies many algorithms, and the logical way to step through such an object is with *p++ or a[i++] (forward) or *--p or a[--i] (backward). The antisymmetric nature of the PDP-11 addressing modes is the result, not the cause. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
mat@mole-end.UUCP (Mark A Terribile) (10/20/90)
> >>Don't ever use single-character variable names. I use 'ix' for > >>loop index variables for which I can come up with no better name... > >In what way is "ix" superior to "i"? Both are meaningless names ... > >If the name is not going to be meaningful ... then at least keep it short. > My attitude is just the opposite of yours: to me, the shorter the loop > is, the less excuse there is to choose a name because of it's length. > If you're only going to be typing the name three or four times, what's > the advantage keeping it a single character? Readability? This is a tough case to argue, but I'll take it up. Put simply, data in a program allow long-range communication between one part of the program and a (potentially) textually unrelated part. In this respect it differs from structured flow-of-control operations, which define relationships between textually related parts (all cases except ``invokes,'' e.g. function call) or tightly limit the effect of remote code (``invokes,'' which must return). In reading a variable name, you have to mentally relate the operation being performed (read, write, compute a value for or with ...) with the defined meaning of the variable and the likely interpretation of the variable. It's work and it slows you down. For a variable used in a small context (like a loop) there are two other ways of achieving the understanding you need when you read the name of the variable in code. First, a variable whose name is excruciatingly short forces you to look to the other uses of the variable for its interpretation. If the entire scope of the variable fits on a screen or a page (and I *LIKE* blocks whose only purpose is to limit such variables) and involves not many other variables, this may actually be faster and easier than the ``guessing'' process by which you interpret a variable name. The rapid interpretation of a variable from its context in a very small scope depends heavily on there not being more than one or two such variables in that scope. For a short variable that is used as the iteration variable of a loop (integer progression, list walking, etc.,) the strength of the common idiom may also help to make the variable's use and meaning clear. Again, this generally only works if the code fits on a screen or a page. This latter effect is strong enough that in a somewhat larger loop, it may actually be clearer to use a variable like ``i_record'' instead of ``record_num''. -- (This man's opinions are his own.) From mole-end Mark Terribile
tada@athena.mit.edu (Michael J Zehr) (10/23/90)
In article <443@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes: >> >>Don't ever use single-character variable names. I use 'ix' for >> >>loop index variables for which I can come up with no better name... > >> >In what way is "ix" superior to "i"? Both are meaningless names ... >> >If the name is not going to be meaningful ... then at least keep it short. Okay, I'll bite on this one. First, a disclaimer that I usually use "i" as a loop variable anyway. "ix" is superior because "i" can sometimes be confused with "1", depending on your printer. This happened to a friend once: int a[height][width]; for(i=0; i<height; i++) for(j=0; j<width; j++) v = (a[i-1][j-1] + a[i][j-1] + a[i-1][j+i] + a[i-1][j] + a[i][j] + a[i-1][j+1] + a[i-1][j+1] + a[i][j-1] + a[i-1][j+1])/9; y'all see the mistake at the end of line the 4th line immediately, right? using a 2-character loop variable makes this much less likely to happen. -michael j zehr
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/24/90)
In article <1990Oct23.160116.10299@athena.mit.edu> tada@athena.mit.edu (Michael J Zehr) writes: > v = (a[i-1][j-1] + a[i][j-1] + a[i-1][j+i] + > a[i-1][j] + a[i][j] + a[i-1][j+1] + > a[i-1][j+1] + a[i][j-1] + a[i-1][j+1])/9; At a minimum I'd format this as v = (a[i-1][j-1] + a[i][j-1] + a[i-1][j+i] + a[i-1][j ] + a[i][j ] + a[i-1][j+1] + a[i-1][j+1] + a[i][j-1] + a[i-1][j+1])/9 which makes the j + i pretty obvious. Or a macro: #define A(b,c) a[i+(b)][j+(c)] v = ( A(-1,-1) + A(0,-1) + A(-1,+i) + A(-1, 0) + A(0, 0) + A(-1,+1) + A(-1,+1) + A(0,-1) + A(-1,+1) ) / 9 #undef A ---Dan
rtm@christmas.UUCP (Richard Minner) (10/25/90)
In article <1990Oct23.160116.10299@athena.mit.edu> tada@athena.mit.edu (Michael J Zehr) writes: >[stuff about printer makes i's and 1's look similar] >This happened to a friend once: >int a[height][width]; >for(i=0; i<height; i++) > for(j=0; j<width; j++) > v = (a[i-1][j-1] + a[i][j-1] + a[i-1][j+i] + > a[i-1][j] + a[i][j] + a[i-1][j+1] + > a[i-1][j+1] + a[i][j-1] + a[i-1][j+1])/9; > >y'all see the mistake at the end of line the 4th line immediately, >right? This brings up something that still amazes me. I'd have written the broken portion above as: v = (a[i-1][j-1] + a[i][j-1] + a[i-1][j+i] + a[i-1][j ] + a[i][j ] + a[i-1][j+1] + a[i-1][j+1] + a[i][j-1] + a[i-1][j+1])/9; in which case I would indeed immediately see all that is wrong with it. (Lot's, it appears, even ignoring that a[i-1] doesn't exists for i == 0, etc. BTW, actually I would have written it right the first time.) (As to printers that make i's and 1's look alike, all I can say is stop using them ;-) Who prints code anyway? >-) Hmmm, I've seen code that starts its indices at `j' instead of `i'. Maybe that's why... but I digress.) My question is why is so little of the code I've seen `neat' in appearance? I have this anal tendency to line things up as much as possible, and otherwise neaten the code. To me, it makes similarities and differences stand out so much better. Sometimes I'll even try a few different layouts and pick the one that seems clearest (sick, I know). I've even spotted errors in foreign code after realigning it to get a better look. I really am just curious why this seems to be so uncommon. First, is it really uncommon, or have I just missed this big pool of neat code out there? Or do I just have a lower `complexity/tangle threshold' than most people? Is it just not worth the trouble? Is vi too hard to use?-) Is it because `indent' and the like just mess it all up anyway? Do others actually find aligned code *harder* to read? (I suppose it's possible.) What could it be? I remember a story/joke about an APL programmer who said that the reason he liked APL was that with most other languages his (non-technical) manager could make some sense of the code, and so didn't appreciate it as much, but with APL it was totally incomprehensible and so the manager was in awe, and of course paid more. Maybe that's it. Enough already. -- Richard Minner || {uunet,sun,well}!island!rtm (916) 736-1323 || || Island Graphics Corporation Sacramento, CA ||
gwyn@smoke.brl.mil (Doug Gwyn) (11/07/90)
In article <13@christmas.UUCP> rtm@island.uu.net (Richard Minner) writes: >My question is why is so little of the code I've seen `neat' in appearance? Often, because it was written by amateurs, or at any rate hackers who have not learned the magnitude of the maintenance problem for production software. >I really am just curious why this seems to be so uncommon. I don't know; where do you obtain the code? Several programmers around here have gravitated into similar styles, wherein visual alignment of related things is carefully maintained. While this seems like too much work to a novice, it pays off since, once you're accustomed to it, several categories of coding error stand out like sore thumbs. Generally these are noticed before the code ever reaches production, or even the first attempt at compilation. >Is vi too hard to use? Yes, but that has nothing to do with it. We're happy "sam" users; you should be too. >Is it because `indent' and the like just mess it all up anyway? If you have an urge to run the code through "indent", it ALREADY has a problem.