C# can't do fractions!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Just made a startling discovery - C# interprets 4/3 as 1 and 2/3 as 0 etc.
C# needs explicit statement of numerator and denominator as float/double
etc. e.g. 4d/3d or 4.0/3.0 to be interpreted correctly
This seems really archaic...surely i'm doing it wrong and there's something
i'm missing!?
 
KimD said:
Just made a startling discovery - C# interprets 4/3 as 1 and 2/3 as 0 etc.
C# needs explicit statement of numerator and denominator as float/double
etc. e.g. 4d/3d or 4.0/3.0 to be interpreted correctly
Click to expand...

No, it needs a floating point operand before it
is willing to promote the other operand to floating
point and perform a floating point divide. This
has been the way C has worked for decades and
C++ for most of 2 decades.

What you call an incorrect result is the correct
result of performing an integer divide as called
for the C# language specification.
This seems really archaic...surely i'm doing it wrong and there's something
i'm missing!?
Click to expand...

Perhaps you a missing a C# reference.
 
Just made a startling discovery - C# interprets 4/3 as 1 and 2/3 as 0 etc.
C# needs explicit statement of numerator and denominator as float/double
etc. e.g. 4d/3d or 4.0/3.0 to be interpreted correctly
This seems really archaic...surely i'm doing it wrong and there's something
i'm missing!?
Click to expand...

This is akin to Delphi where we have the integer division operator (div) and
the fp division operator (/).

AFAIK, this is necessary because of implicit casting that may occur during
the calculation.

Joanna
 
KimD said:
Just made a startling discovery - C# interprets 4/3 as 1 and 2/3 as 0 etc.
C# needs explicit statement of numerator and denominator as float/double
etc. e.g. 4d/3d or 4.0/3.0 to be interpreted correctly
This seems really archaic...surely i'm doing it wrong and there's
something
i'm missing!?
Click to expand...

This is normal behavior for integer division, found in C, C++, Java and in
C#. I'm sure there are many other languages that share the same approach on
integer division. Any competently taught beginning programming class will
pound this concept into the heads of students. The result is determined by
the operand types, *not* by the type where the result is stored.
IOW, double res = 2/3; will not give you 0.6666..., but 0 in res as the
result is already determined by the division operation on two integer
literals.
If you divide one integer into another, the result will be an integer.
Casting one or the other operand to a real number type, as you've shown,
gets the other operand promoted to the "higher" type and preserves the
precision in the result.
It's *not* a C# thing!
 
I think the main problem in the assumption is that 4 / 3 as it reads means
the number 4 divided by the number 3.

The compiler doesn't have an understanding of a number in that way, but
needs to differentiate between whole integers and fractionally valued floats
(or doubles etc).

This is done by either an explicit cast
(float)4 / (float)3
or by giving the compiler a sign that the number is not a whole number
4.0 / 3.0

As everyone has already pointed out, this is a compiler design that has
existed since the beginning.
 
Sorry - didn't mean to offend anybody's sensibilities! I've been programming
with Delphi for some time and this was never an issue and hence came as a
surprise. I suppose I just expected it to use the type of the result rather
than assume it to be an integer. Thanks for all the advice.
-Kim
 
That's the point... integer IS the type of the result. It's not that the
compiler assumes a return type, it's just that the / operator is defined on
types to return the same type as the inputs, in the same way as
multiplication, addition and subtraction are. And we've all been caught out
by this at some time or another :-)

Steve
 
and the problem is??


Steve McLellan said:
That's the point... integer IS the type of the result. It's not that the
compiler assumes a return type, it's just that the / operator is defined on
types to return the same type as the inputs, in the same way as
multiplication, addition and subtraction are. And we've all been caught out
by this at some time or another :-)

Steve
Click to expand...
 
Back
Top