# 1/2 =?

Discussion in 'C Programming' started by hyu163@gmail.com, Jun 24, 2005.

1. ### Guest

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!

, Jun 24, 2005

2. ### Lew PitcherGuest

-----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-----

Lew Pitcher, Jun 24, 2005

3. ### peteGuest

wrote:

> so, 1/2=?

1 / 2 == 0
1 / 2.0 == 0.5
1.0 / 2 == 0.5
1.0 / 2.0 == 0.5

--
pete

pete, Jun 24, 2005
4. ### Artie GoldGuest

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

Artie Gold, Jun 24, 2005
5. ### Dan HenryGuest

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

Dan Henry, Jun 24, 2005
6. ### Robert GambleGuest

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

Robert Gamble, Jun 24, 2005
7. ### CBFalconerGuest

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

CBFalconer, Jun 24, 2005
8. ### MJGuest

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

MJ, Jun 24, 2005
9. ### akarlGuest

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.

akarl, Jun 25, 2005
10. ### snnnGuest

>
> 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=?
>

^_^

snnn, Jun 27, 2005
11. ### Robert Maas, see http://tinyurl.com/uh3tGuest

> From:
> 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, Jun 28, 2005
12. ### akarlGuest

Robert Maas, see http://tinyurl.com/uh3t wrote:
>>From:

>
>
>>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

akarl, Jun 29, 2005
13. ### Chris CroughtonGuest

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

Chris Croughton, Jun 29, 2005
14. ### Walter RobersonGuest

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

For example, if in the below, _ represents a space (just for
readability, as trailing spaces are not normally visible)

then at current, leading and trailing spaces on the expansion are
trimmed, making this equivilent to

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

instead of 3 + 3 +
--
Look out, there are llamas!

Walter Roberson, Jun 30, 2005
15. ### CBFalconerGuest

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
>
>
> 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.

CBFalconer, Jun 30, 2005
16. ### Robert Maas, see http://tinyurl.com/uh3tGuest

> 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, Jul 27, 2005
17. ### akarlGuest

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

akarl, Jul 28, 2005
18. ### Robert Maas, see http://tinyurl.com/uh3tGuest

> 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, Jul 29, 2005
19. ### akarlGuest

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

akarl, Jul 30, 2005
20. ### Dik T. WinterGuest

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/

Dik T. Winter, Jul 31, 2005