|
now that you made me think of it, I realized of my habit of using "t" instead of "i" as my favorite looping variable. It's because I learned of FOR loops back in 1984 when typing BASIC programs on my Commodore VIC20. The user manual had several sound-effects example listings, mostly composed of a FOR T=something statement, where T stayed (I guess) for time. I typed many of them and eventually got the habit of the "t" variable.
Effects were something like this:
10 REM LUNAR LANDING EFFECT
15 POKE 36878,15
20 FOR T=200 TO 120 STEP -1
30 POKE 36876,T
40 FOR I=1 TO 100:NEXT I
50 NEXT T
(for the curious ones, 368678 was for volume "up" and 36876 for playing tone).
|
|
|
|
|
I use i because I was taught so in school, also every example in any book use i (j, k, etc.) as loop variables so I assume it seems natural to me. By the way I always thought i stood for index.
|
|
|
|
|
Yes, as others have said for many it was a carryover from FORTRAN. Nothing formal that I know of, just using i in FORTRAN and then out of habit using it in 'C' as programmers moved over to that and other newer languages.
|
|
|
|
|
When I first learned about mathematical functions f(x)(a dozen years before my first programming class) I was told mathematicians used "i" for the first incrementing variable, "j" for the next and so on.
When I started to learn programming languages, a FORTRAN professor (FORTRAN as in "FORmula TRANslation") who (of course) was a member of the Math department, said something along the lines of "This is not the theology department but using anything other that "I" for the first incremental etc is heresy. Those who want to use 'meaningful words' should consider being English or Philosophy majors and take Professor So-and-So's COBOL class."
So, 'I' as an index did not start with FORTRAN, it started before FORTRAN, but it fit nicely because those who used FORTRAN knew its meaning from math studies.
|
|
|
|
|
Yes, it is so: i, j and k are standard notation for mathematical arithmetic progressions and series.
From well before FORTRAN. But FORTRAN was designed by mathematicians, so we programmers are carrying over the notation.
a,b,c -> constants
x,y,z -> unknown terms (or real coordinates in cartesian plane)
k,j,i -> INTEGER indexes or vector coordinates.
I think Gauss was already using this conventions, more than 100 years ago.
Gauss wins. As always.
|
|
|
|
|
|
Fortran probably got it from math.
Now math... I don't know.
|
|
|
|
|
I've always used 'x'.
Why? Because a "Programming in C" book I started with used it.
So I just got used to it I guess.
|
|
|
|
|
It was also a feature of some early BASIC implementations. There were 26 variables available; A through H were floating point, I through P (??) were integers; R(??) through Z were also floating point. The only explicit type declarations were to suffix one of the single-letter variables with the $ symbol to indicate string. "I" was commonly used for loop control as being the first integer variable. It's a habit I learned in the 1960s and I still use it (very occasionally). Old habits die hard...
|
|
|
|
|
while(life!=death)
{
age++;
research++;
development++;
}
|
|
|
|
|
Hi,
Others have said this, but it deserves to be repeated:
This is classical math (handwritten, typed or printed), from a couple of centuries before the advent of computers. It's pretty natural that it was adopted by most mathematically-oriented computer languages (and, consequently, by later languages), and it also explains why it feels natural to most programmers (who have read any math - which should be a reasonable expectation) even today.
indices: i, j, k (don't remember how it goes on after that
quantities: n, m (then p, q if I remember correctly - o can be confusing).
dimensions: x, y, z, t, (xi), (eta), (theta).
I don't remember what happens when we run out of letters for indices and quantities, but if I remember correctly these sequences also continue with greek letters.
So:
for (i = 0; i < n; i++)
{
for (j = 0; j < m; i++)
{
for (k = 0; k < p; k++)
{
}
}
}
Pretty straightforward. And Newton would have understood it without thinking... 
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
I personally use x (and y and z for nested loops - if you nest more than two levels, you need to redesign), I make it unsigned (unless there's a specific reason to use signed) because that more accurately models the real world, and I use the prefix form of the increment operator because it's potentially more efficient. So my canonical form of that construct would be:
for (unsigned x = 0; x < size; ++x)
And yes, some of my co-workers make fun of me. The ones who spend twice as much time debugging their code as I do debugging mine.
|
|
|
|
|
I use
for (int r = 0; r < size; i++)
because
1) "r" is directly next to "t" when I type "int[spaceBar]r", typing flow is much nicer;
2) "r" is on my left-hand vs. the right-hand, so when I type "someArray[r]" I type faster as my fingers type in sync with one another; seriously, try it for a week and you'll see it flows much better;
3) "r" means "repeat" (or "record") in my brain
4) using i reminds me of when I flunked Spanish... example: iFlunked!
5) I got sick of iThisCrap, iThatCrap, iWTF;
.... - even though I actually originated using "i[SomeWord]" during my Apple dayz ... yes, iCreatedThisMess
... r u kidding me? no, i am not!
|
|
|
|
|
I was looking at one old SQL stored proc and found this strange behaviour.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Look at the if condition .. it does not have BEGIN..END... To make thing interesting weather if condition is true or false you will get the output for parameter @currDate
If I add PRINT @Scrap_Qty right after IF and run it again it will only print value for @Scrap_Qty if condition is true. Which leads to question why sql is not complaining about undeclared variable if @Scrap_Qty is less than @FilledQty ?
I would have assumed if condition without BEGIN .. END block will behave like a normal one line to execute if condition is true which in above block is declaration of @currDate variable.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
PRINT @Scrap_Qty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
declare is not an 'executable' statement.
This means thet the if in your code relates to the set @currdate.... statement only.
Personally, I always use BEGIN...END, even for one liners, but that's a matter of individual preference.
Anyway, thanks for sharing.
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: Personally, I always use BEGIN...END, even for one liners, but
that's a matter of individual preference.
This is exactly the reason for it not to be individual preference. Enhances readability and maintenance. Also, if the original developer used Pablo's notion, they would very likely have encapsulated this right.
|
|
|
|
|
Pablo Aliskevicius wrote: if in your code relates to the set @currdate.... statement only
In that Case if @ScrapQty<@FilledQty it should not Print Date( as i Understood... If i Understood wrong pls clarify ).... But it's Displaying Date  .... Can You Explain That... Pls... Any Explanation will be appreciated....
Thanks....
|
|
|
|
|
The set statement is conditional (first one after the if).
The print statement is another, different statement, and not conditional; it will be executed always.
The point is: always write begin and end.
Best wishes,
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: The set statement is conditional (first one after the if).
I Understood that but even though the cond'n is false... the variable @currDate is assigned to Current date...
That's the thing am unable to understand... Spare my Dumbness.... am trying to learn new things about if.....
|
|
|
|
|
I tried this, expecting the first 'print' would be skipped.
if 1 > 2
declare @a int
print 'print #1'
print 'print #2'
select @a = 3
print @a
go
if 2 > 1
declare @b int
print 'print #3'
print 'print #4'
go
To my surprise, the output was this:
print #1
print #2
3
print #3
print #4
The conclusion? ALWAYS write BEGIN and END. Keep code readable.
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: <layer>To my surprise, the output was this:
print #1
That's the thing am Asking.... am Unable to understand why the Print #1 is Printed....... I am trying to Find why it's printing Print #1 with no Luck......
If we Don't use Begin and End( But i always Use....) Then it will execute the first statement... But Here... That's not the case.... Trying to figure out the Mystery Behind it...
Raj.......
|
|
|
|
|
I'm trying out various command line option parser libraries, and those with verb or command options are few and far between. CLAP[^] is one that handles verbs, e.g. I don't need a separate Console application for each task, where the CLI library just parses the options for that command. I want a library where I can have one Console app, which accepts a command/verb and the options for that verb get parsed. So far I've found only CLAP and ManyConsole[^].
E.g. I don't want to have to have import.exe filename [-repeat] but I want console.exe import filename [-repeat].
So I built a console application called Clap, with this code:
using System;
using CLAP;
namespace Clap
{
class Program
{
static void Main(string[] args)
{
Parser.Run<Program>(args);
}
[Verb(Description = "Imports an Impro CSV report file.", Aliases = "import,imp")]
static void ImportCsv(
[Required]
[Description("Full path to the file to import.")] string filePath)
{
Console.WriteLine("Will import " + filePath);
}
}
}
When I run the application with clap /? or clap import xxx, I get the error message
Unhandled Exception: System.TypeLoadException: Could not load type 'CLAP.Parser' from assembly 'Clap, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
at Clap.Program.Main(String[] args)
Google provided zero leads, so the problem was not well known. Well, how well known is CLAP itself? The Version-=1.0.0.0 gave me the key clue. It looked like the app was trying to load CLAP.Parser from my Clap assembly, not the CLAP library assembly, which is version 4.3.
All it took was to change my assembly name and default namespace to ClapCli and the problem vanished, but just BTW, CLAP is very, very thin. It throws exceptions when verbs arguments are omitted, and expects you to decorate a method to do something with the exception. It also has no built in help provider, and requires you to decorate a method that is called when the user requests help. You must compose and format your own help text for every verb and option.
modified 25-Apr-13 5:32am.
|
|
|
|
|
If you look at one of the examples you'll find this:
using CLAP;
using CLAP.Validation;
class ClapApp
{
.
.
.
}
> "Well, how well known is CLAP itself? "
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
modified 25-Apr-13 5:27am.
|
|
|
|
|
I just changed my app name from 'Clap' to 'ClapCli' and it was fixed. See the last paragraph, that I've just added.
|
|
|
|
|
Your code is like a dose of clap. Errr no, Clap. No, CLAP!
--
Harvey
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
