Hi there, i'm a newbie in c. I'm using Turbo C 2.0 compiler. Here is my question: main(){ int a=1, b=2; float c; c=a/b; printf("%f", c); /* why i get "0.0000"? */ c = (float)(a/b); printf("%f", c); /* why i get "0.0000" again? */ c = (float) a/b; printf("%f", c); /* then i get "0.5000" this time */ } so, 1/2=? thanks!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 wrote: > Hi there, i'm a newbie in c. > I'm using Turbo C 2.0 compiler. > Here is my question: > > > main(){ > int a=1, b=2; > float c; > > c=a/b; > printf("%f", c); /* why i get "0.0000"? */ Since a and b are int, division is done in the int domain 1 goes into 2 zero times with 1 remainder so, the result is 0 Since c is a float, the results of the int division are converted to float 0 becomes 0.0 > > c = (float)(a/b); > printf("%f", c); /* why i get "0.0000" again? */ Since a and b are int, division is done in the int domain 1 goes into 2 zero times with 1 remainder so, the result is 0 The result is then cast to float 0 becomes 0.0 Since c is a float and the results of the computation are in float, no conversion is performed 0.0 remains 0.0 > c = (float) a/b; > printf("%f", c); /* then i get "0.5000" this time */ a and b are int (float) a converts a into a float, so 1 becomes 1.0 Now the division is between a float and an int, and so the computation and the results are float 1.0 / 2 becomes 1.0 / 2.0 which becomes 0.5 Since c is a float and the results of the computation are in float, no conversion is performed 0.5 remains 0.5 > } > > > so, 1/2=? > > thanks! > - -- Lew Pitcher Master Codewright & JOAT-in-training | GPG public key available on request Registered Linux User #112576 (http://counter.li.org/) Slackware - Because I know what I'm doing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCu22eagVFX4UWr64RAuE9AJ9VegjhFu3qzvZexaRRtscNmPNiQwCg0r37 wm1fKvBgiVrhhrkSo+PyKOw= =85zE -----END PGP SIGNATURE-----

wrote: > Hi there, i'm a newbie in c. > I'm using Turbo C 2.0 compiler. > Here is my question: > > > main(){ > int a=1, b=2; > float c; > > c=a/b; > printf("%f", c); /* why i get "0.0000"? */ Integer division. The expression `1/2' yields 0, which is then assigned to the float `c'. > > c = (float)(a/b); > printf("%f", c); /* why i get "0.0000" again? */ Same thing. `1/2' yields 0 which is then cast to a float and ultimately assigned to `c'. > > c = (float) a/b; > printf("%f", c); /* then i get "0.5000" this time */ > > } > Ah, *this* time, because `a' (the `1') has been cast to float, it's *not* integer division that takes place -- so you get the answer you were expecting. > > so, 1/2=? Well, 0, of course! HTH, --ag -- Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays

wrote: >Hi there, i'm a newbie in c. >I'm using Turbo C 2.0 compiler. >Here is my question: > > >main(){ >int a=1, b=2; >float c; > >c=a/b; >printf("%f", c); /* why i get "0.0000"? */ Integer division of 1 by 2 yields 0. Zero converted to a float is 0.0. >c = (float)(a/b); >printf("%f", c); /* why i get "0.0000" again? */ Integer division of 1 by 2 yields 0. Zero converted to a float is 0.0. >c = (float) a/b; >printf("%f", c); /* then i get "0.5000" this time */ Integer 'a' explicitly converted to a float (1.0) divided by 'b' implicitly converted to a float (2.0) reasonably yields 0.5. >so, 1/2=? In the expression 1/2, both operands are integers, so the answer is 0. See above. -- Dan Henry

Lew Pitcher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > wrote: > > Hi there, i'm a newbie in c. > > I'm using Turbo C 2.0 compiler. > > Here is my question: > > > > > > main(){ > > int a=1, b=2; > > float c; > > > > c=a/b; > > printf("%f", c); /* why i get "0.0000"? */ > > Since a and b are int, division is done in the int domain > > 1 goes into 2 zero times with 1 remainder > so, the result is 0 2 goes into 1 zero times with 1 remainder. Robert Gamble

wrote: > > main(){ > int a=1, b=2; > float c; > > c=a/b; a/b is 0 with a remainder of 1 > printf("%f", c); /* why i get "0.0000"? */ > > c = (float)(a/b); when you convert 0 to a float you hope to get 0. Of course the cast is unnecessary, since the system will do the conversion on the assignment. All casts are suspect. > printf("%f", c); /* why i get "0.0000" again? */ > > c = (float) a/b; Now you used a meaningful cast. (float)a is a float with the value 1.0. Division by an integer, such as 2, requires that the integer be promoted to a real, in this case 2.0. Now you are computing 1.0/2.0 and in place of a remainder you have more significant digits. > printf("%f", c); /* then i get "0.5000" this time */ -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson

Hi The thing is that when you have two int the result will be like this int a,b ; so a/b will always be int value the result takes the largest data type of the two thats why a/b = int in the second case when you do a type cast it does not have any effect. Since the result is already generated and then if you type cast it has no meaning In the third case you are type casting the variable a from int to float so when you divide the two variables after type casting it will take the largest data type in the sence ( float) and you will get the desired result. if you dont want to type cast you can just multiply any of the int varialbe with 1.00 and you will get the expected result float C = (a*1.00)/ b = (float)a / b = a / (flaot)b = a/(b*1.00) Mayur

wrote: > Hi there, i'm a newbie in c. > I'm using Turbo C 2.0 compiler. > Here is my question: > > > main(){ > int a=1, b=2; > float c; > > c=a/b; > printf("%f", c); /* why i get "0.0000"? */ > > c = (float)(a/b); > printf("%f", c); /* why i get "0.0000" again? */ > > c = (float) a/b; > printf("%f", c); /* then i get "0.5000" this time */ > > } > > > so, 1/2=? Here we go again. See the thread "pow(2, 1/2) != pow(2, 0.5)" started by Michel Rouzic 2005-06-15. No, it's not at all a stupid question, it's one of the C obscurities.

> > main(){ > int a=1, b=2; > float c; > > c=a/b; > printf("%f", c); /* why i get "0.0000"? */ Since a and b are int, a/b should be int too,and the result is 0. then,the result is to be assigned to a float variable,the result "0" is converted to "0.0000" > > c = (float)(a/b); > printf("%f", c); /* why i get "0.0000" again? */ > (float) convert the result of (a/b) to float. so the result is the same as above. > c = (float) a/b; > printf("%f", c); /* then i get "0.5000" this time */ > > } > first, "(float)" convert a to a float value,so the division is done in the float domain,the result is certain should be 0.5000. > > so, 1/2=? > ^_^

> From: (your third case > c = (float) a/b; That's bad style of coding. You have a/b really close together with no spaces, but you have (float) spaced away from it, so it looks visually like a/b happens first then the quotient is cast to float. The correct way to punctuate your third case, to make it clear, is : c = (float)a / b; Rather than memorizing operator precedence and often making mistakes, I suggest always using an extra level of parens whenever you're not sure: c = (float)(a/b); /* Your second case, as you had it */ c = ((float)a)/b; /* Your third case, made more clear here */ If you have enough parens, you don't need any spaces, but to use spaces also: c = (float) (a/b); c = ((float)a) / b; If you use parens, but also use spaces, but the spaces are in the wrong places for visual effect consistent with parens, you'll get this clash: c = (float)(a / b); c = ((float) a)/b; Just one glance at that last one shows you something is screwed! The same problem happens with poorly punctuated: c = a+b / a-b; which really means: c = a + (b/a) + b; but what was really intended was probably this: c = (a+b) / (a-b); where parens are needed to make it work as intended. The whole mess with operator precedence sucks. If you dislike it as much as I do, use Lisp instead. By the way, for a C-like language, I wonder why nobody thought of the idea of having the number of spaces determine the precedence? Operations with no spacing would be performed first, then operations with one space, then two etc. Then the following would be correct per their visual appearance: c = a+b / a-b; v = a * x**2 + b * x + c; Meanwhile, back in C, it would be nice if the compiler would warn about spacing that is inconsistent with operator precedence.

Robert Maas, see http://tinyurl.com/uh3t wrote: >>From: > > (your third case > >>c = (float) a/b; > > > That's bad style of coding. You have a/b really close together with no > spaces, but you have (float) spaced away from it, so it looks visually > like a/b happens first then the quotient is cast to float. > The correct way to punctuate your third case, to make it clear, is : > c = (float)a / b; I agree, but at least in Java I think the general coding style recommendation is to insert a space after the cast operator (to make it look more like a declaration). > Rather than memorizing operator precedence and often making mistakes, I > suggest always using an extra level of parens whenever you're not sure: > c = (float)(a/b); /* Your second case, as you had it */ > c = ((float)a)/b; /* Your third case, made more clear here */ > If you have enough parens, you don't need any spaces, but to use spaces also: > c = (float) (a/b); > c = ((float)a) / b; > If you use parens, but also use spaces, but the spaces are in the wrong > places for visual effect consistent with parens, you'll get this clash: > c = (float)(a / b); > c = ((float) a)/b; > Just one glance at that last one shows you something is screwed! > > The same problem happens with poorly punctuated: > c = a+b / a-b; > which really means: > c = a + (b/a) + b; > but what was really intended was probably this: > c = (a+b) / (a-b); > where parens are needed to make it work as intended. > > The whole mess with operator precedence sucks. > If you dislike it as much as I do, use Lisp instead. Or Oberon-2. It has only four (!) precedence levels: logical not, multiplicative operators, additive operators and relational operators. > By the way, for a C-like language, I wonder why nobody thought of > the idea of having the number of spaces determine the precedence? > Operations with no spacing would be performed first, then operations > with one space, then two etc. Then the following would be correct per > their visual appearance: > c = a+b / a-b; > v = a * x**2 + b * x + c; > > Meanwhile, back in C, it would be nice if the compiler would warn about > spacing that is inconsistent with operator precedence. This is exactly the reason I don't like Python. It's all too easy to inadvertently delete some whitespace and mess things up. -- akarl

On Tue, 28 Jun 2005 14:02:36 -0700, Robert Maas, see http://tinyurl.com/uh3t <> wrote: > That's bad style of coding. You have a/b really close together with no > spaces, but you have (float) spaced away from it, so it looks visually > like a/b happens first then the quotient is cast to float. > The correct way to punctuate your third case, to make it clear, is : > c = (float)a / b; Or better c = (float)a / (float)b; rather than depend on the implicit conversions. For instance: c = (float)a / (b/c); forgetting to convert either b or c to float as well. > The same problem happens with poorly punctuated: > c = a+b / a-b; > which really means: > c = a + (b/a) + b; > but what was really intended was probably this: > c = (a+b) / (a-b); > where parens are needed to make it work as intended. Yes, that's standard algebra. > The whole mess with operator precedence sucks. > If you dislike it as much as I do, use Lisp instead. Where it won't be readable at all. > By the way, for a C-like language, I wonder why nobody thought of > the idea of having the number of spaces determine the precedence? > Operations with no spacing would be performed first, then operations > with one space, then two etc. Then the following would be correct per > their visual appearance: > c = a+b / a-b; > v = a * x**2 + b * x + c; And what would happen if you edited it to: v = a * x**2 +b * x + c; The compiler would have fits. It may work with simple names like a, b, c etc., but with more complex ones it would quickly get unwieldy. And its far easier to get wrong than having a fixed precedence which follows the normal rules of algebra (apart from things which aren't in normal algebra at all like bit operators). > Meanwhile, back in C, it would be nice if the compiler would warn about > spacing that is inconsistent with operator precedence. There may be a version of lint which would do it. Every programmer I know would kill such a warning with extreme prejudice... Chris C

In article <>, Robert Maas, see http://tinyurl.com/uh3t <> wrote: >By the way, for a C-like language, I wonder why nobody thought of >the idea of having the number of spaces determine the precedence? >Operations with no spacing would be performed first, then operations >with one space, then two etc. The rules for macro expansion would have to change, as would the rules for comments. For example, if in the below, _ represents a space (just for readability, as trailing spaces are not normally visible) #define__Add3__3_+___ then at current, leading and trailing spaces on the expansion are trimmed, making this equivilent to #define_Add3_3_+ However, in your proposed revision, the number of leading or trailing spaces would become important. Similarily, the current rule is that a comment is replaces by exactly one space. Consider "abc"/*some random comment*/-3 under current rules this is "abc" -3 and that space would become important. But if the rule were changed so that comments were replaced with no space, then Add3/*comment*/Add3 would become Add3Add3 (likely an undefined value) instead of 3 + 3 + -- Look out, there are llamas!

Walter Roberson wrote: > .... snip ... > > Similarily, the current rule is that a comment is replaces by > exactly one space. Consider > > "abc"/*some random comment*/-3 > > under current rules this is "abc" -3 > and that space would become important. But if the rule were > changed so that comments were replaced with no space, then > > Add3/*comment*/Add3 > > would become Add3Add3 (likely an undefined value) > instead of 3 + 3 + That is the way some pre-ansi K&R style compilers worked, and some took advantage to make a poor mans non-portable ## operator. Luckily pretty well stamped out. -- Chuck F () () Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

> From: akarl <> > Or Oberon-2. It has only four (!) precedence levels: logical not, > multiplicative operators, additive operators and relational operators. No parentheses and no assignment?? Are you sure? Does it have any token-level syntax such as string literals etc.? In any case, Lisp has it beat out, with ony token-level syntax and parens, no other syntax at all. Forth has Lisp beat out, not even parens, but that makes Forth code impossible to visually parse. You know the story of Goldilocks and the three bears? Lisp is "just right".

Robert Maas, see http://tinyurl.com/uh3t wrote: >>From: akarl <> >>Or Oberon-2. It has only four (!) precedence levels: logical not, >>multiplicative operators, additive operators and relational operators. > > No parentheses and no assignment?? Are you sure? > Does it have any token-level syntax such as string literals etc.? Sure, it has all you mention, but assignment is not an operator, it's part of an assignment statement. Of course, parenthesized expressions are evaluated first, but that's obvious and not something you have to remember. > In any case, Lisp has it beat out, with ony token-level syntax and > parens, no other syntax at all. Since this is comp.lang.c I mentioned the simplest *procedural* language, Oberon-2. > Forth has Lisp beat out, not even parens, but that makes Forth code > impossible to visually parse. You know the story of Goldilocks and the > three bears? Lisp is "just right". C and Lisp are languages from completely different families. August

> From: akarl <> > assignment is not an operator It is in C and C++ and Java and Algol and Basic, or didn't you know that? It is in Lisp too, but I'm sure you didn't know that because you don't seem to know much about Lisp. An assignment expression can even return a value which can be passed as a rhs to another assignment or even inside a calculation expression. Or didn't you know that either? Note below the operator precedence whereby = is looser than +, for example 2 is added to (x=1) and *then* the result of that is assigned to y: % more x1.c main() { int x; int y; int z; z = (y = (x = 1) + 2) + 4; printf("%d %d %d\n", x,y,z); } % cc x1.c % ./a.out 1 3 7 > > In any case, Lisp has it beat out, with ony token-level syntax and > > parens, no other syntax at all. > Since this is comp.lang.c I mentioned the simplest *procedural* > language, Oberon-2. Are you claiming that Lisp isn't procedural? It most certainly is! To put this issue to test, you tell me which of the following langauges are procedural and which are not: txt html php sh perl python lisp awk f77 c c++ java Then you write a short (4-7 line) program that can be converted line-for-line into each of the languages you claim is procedural but which can *not* be translated line-for-line into Lisp, thereby alleging that Lisp is not procedural. > C and Lisp are languages from completely different families. Here's another exercise for you: Tell me which of the languages I listed above are in which "families", i.e. partition those languages on a per-family basis. Once it's clear what you mean by that word, we can continue this discussion meaningfully.

Robert Maas, see http://tinyurl.com/uh3t wrote: >>From: akarl <> >>assignment is not an operator > > It is in C and C++ and Java and Algol and Basic, or didn't you know > that? It is in Lisp too, but I'm sure you didn't know that because you > don't seem to know much about Lisp. Are you referring to Common Lisp, Scheme, Elisp...? The Lisp languages are mainly functional and in a purely functional language, such as Haskell, assignment is not even a part of the language. When I say that "assignment is not an operator in Oberon-2" I mean that it's not an expression operator; it doesn't return a value. > An assignment expression can even return a value which can be passed as > a rhs to another assignment or even inside a calculation expression. Or > didn't you know that either? Note below the operator precedence whereby > = is looser than +, for example 2 is added to (x=1) and *then* the > result of that is assigned to y: > > % more x1.c > main() { > int x; int y; int z; > z = (y = (x = 1) + 2) + 4; > printf("%d %d %d\n", x,y,z); > } > % cc x1.c > % ./a.out > 1 3 7 Yes this is all true when assignment is an expression operator. >>>In any case, Lisp has it beat out, with ony token-level syntax and >>>parens, no other syntax at all. >> >>Since this is comp.lang.c I mentioned the simplest *procedural* >>language, Oberon-2. > > > Are you claiming that Lisp isn't procedural? It most certainly is! > To put this issue to test, you tell me which of the following langauges > are procedural and which are not: > txt html php sh perl python lisp awk f77 c c++ java > Then you write a short (4-7 line) program that can be converted > line-for-line into each of the languages you claim is procedural but > which can *not* be translated line-for-line into Lisp, thereby alleging > that Lisp is not procedural. > > >>C and Lisp are languages from completely different families. > > > Here's another exercise for you: Tell me which of the languages I > listed above are in which "families", i.e. partition those languages on > a per-family basis. Once it's clear what you mean by that word, we can > continue this discussion meaningfully. C is a procedural and statically typed language and the Lisp family of languages are dynamically typed and "mostly" functional. August

In article <> (Robert Maas, see http://tinyurl.com/uh3t) writes: > > From: akarl <> > > assignment is not an operator > > It is in C and C++ and Java and Algol and Basic, or didn't you know > that? Assignment is not an operator in either Algol 60 or Algol 68, or didn't you know that? -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/