1/2 =?

H

hyu163

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

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Artie Gold

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
 
D

Dan Henry

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

Robert Gamble

Lew said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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
 
C

CBFalconer

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

MJ

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
 
A

akarl

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

snnn

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=?
^_^
 
R

Robert Maas, see http://tinyurl.com/uh3t

From: (e-mail address removed)
(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. :)
 
A

akarl

Robert said:
(your third case:)



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
 
C

Chris Croughton

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
 
W

Walter Roberson

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

CBFalconer

Walter said:
.... 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.
 
R

Robert Maas, see http://tinyurl.com/uh3t

From: akarl said:
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".
 
A

akarl

Robert said:
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
 
R

Robert Maas, see http://tinyurl.com/uh3t

From: akarl said:
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
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.
 
A

akarl

Robert said:
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.
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.




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
 
D

Dik T. Winter

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top