472,144 Members | 1,931 Online

# Is integer division always truncated

In .NET, can I be sure that the result of a division between two integers
always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis
Jul 21 '05 #1
24 18780
Yes. You can also get the remainder that results in an integer division.

If you need rounding, use floating point division and round the result.

"Teis Draiby" <te*************@draiby.com> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...
In .NET, can I be sure that the result of a division between two integers
always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis

Jul 21 '05 #2
Ah! That must be the Math.IEEERemainder()

Thanks, Teis
Jul 21 '05 #3
I don't think so. At first I would have said "yes" agreed with you. But in machine language .9999999999999999 is 1
not 0 16 bit here. In other words in pure mathematics .99999... = 1 but the machine cannot run out to infinity it can only
run out to the bits allowed allowed for integers. In this case ..99999....9 = 1. We'd have to test that to be sure but that
seems reasonable.

--
George Hester
_________________________________
"Marina" <so*****@nospam.com> wrote in message news:eT**************@tk2msftngp13.phx.gbl...
Yes. You can also get the remainder that results in an integer division.

If you need rounding, use floating point division and round the result.

"Teis Draiby" <te*************@draiby.com> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...
In .NET, can I be sure that the result of a division between two integers
always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis

Jul 21 '05 #4

"Teis Draiby" <te*************@draiby.com> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...
In .NET, can I be sure that the result of a division between two integers
always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis

Um, I would have to disagree with those that say yes.
I haven't taken it to the IL or assembly level, but I believe as written the
values will be cast to doubles, divided, then the result rounded to get your
Integer. Even if that is not exactly what happens, you will NOT get 1.

The key here is the operator you are using ( / ) this is a floating point
division operator.
What you will want to employ is the often overlooked ( \ ) operator, which
is an integer division operator.
Aside from being much faster then ( / ), you should get your desired
results.
Put this into a function and step through it, monitoring the values of each
variable:

Dim intA, intB As Integer
Dim dblA, dblB As Double
Dim int1, int2, int3, int4 As Integer
Dim dbl1, dbl2, dbl3, dbl4 As Double

intA = 99
intB = 50
dblA = 99.0#
dblB = 50.0#

int1 = intA / intB '=2
int2 = intA \ intB '=1
int3 = dblA / dblB '=2
int4 = dblA \ dblB '=1

dbl1 = intA / intB '=1.98
dbl2 = intA \ intB '=1.0
dbl3 = dblA / dblB '=1.98
dbl4 = dblA \ dblB '=1.0

Gerald
Jul 21 '05 #5
Amazing. I was expecting a simple yes or no answer. Thank you very much,
Teis

"Gerald Hernandez" <Cablewizard@sp*********@Yahoo.com> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...

"Teis Draiby" <te*************@draiby.com> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...
In .NET, can I be sure that the result of a division between two integers always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis

Um, I would have to disagree with those that say yes.
I haven't taken it to the IL or assembly level, but I believe as written

the values will be cast to doubles, divided, then the result rounded to get your Integer. Even if that is not exactly what happens, you will NOT get 1.

The key here is the operator you are using ( / ) this is a floating point
division operator.
What you will want to employ is the often overlooked ( \ ) operator, which
is an integer division operator.
Aside from being much faster then ( / ), you should get your desired
results.
Put this into a function and step through it, monitoring the values of each variable:

Dim intA, intB As Integer
Dim dblA, dblB As Double
Dim int1, int2, int3, int4 As Integer
Dim dbl1, dbl2, dbl3, dbl4 As Double

intA = 99
intB = 50
dblA = 99.0#
dblB = 50.0#

int1 = intA / intB '=2
int2 = intA \ intB '=1
int3 = dblA / dblB '=2
int4 = dblA \ dblB '=1

dbl1 = intA / intB '=1.98
dbl2 = intA \ intB '=1.0
dbl3 = dblA / dblB '=1.98
dbl4 = dblA \ dblB '=1.0

Gerald

Jul 21 '05 #6
Gerald Hernandez <Cablewizard@spam_remove> wrote:
Um, I would have to disagree with those that say yes.
I haven't taken it to the IL or assembly level, but I believe as written the
values will be cast to doubles, divided, then the result rounded to get your
Integer. Even if that is not exactly what happens, you will NOT get 1.

The key here is the operator you are using ( / ) this is a floating point
division operator.

Well, maybe so if the OP is using VB.NET. Not if they're using C#.
Unfortunately, we have no way of knowing from their post...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #7
Jon,

You can use in C# this for what you ask.

int a = (int) 99 / (int) 50;

I hope this helps?

Cor
Jul 21 '05 #8

"Teis Draiby" <te*************@draiby.com> wrote in message
news:u8**************@TK2MSFTNGP11.phx.gbl...
In .NET, can I be sure that the result of a division between two integers
always is truncated rather that rounded to nearest?

Example:
99 / 50 = 1

regards, Teis

Language dependent, not framework dependent.
For example in C++ the behavior is exactly as you describe and can only be
altered by casting one of the operands to a floating point type: double
answer = 99 / 50.0; will result in a real number answer.

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.
Jul 21 '05 #9

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Gerald Hernandez <Cablewizard@spam_remove> wrote:
Um, I would have to disagree with those that say yes.
I haven't taken it to the IL or assembly level, but I believe as written the values will be cast to doubles, divided, then the result rounded to get your Integer. Even if that is not exactly what happens, you will NOT get 1.

The key here is the operator you are using ( / ) this is a floating point division operator.

Well, maybe so if the OP is using VB.NET. Not if they're using C#.
Unfortunately, we have no way of knowing from their post...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet

Thanks for the additional input. Unfortunately, I forgot to consider C#.
This seems pretty unfriendly, on the part of VB.

Gerald
Jul 21 '05 #10
Cor Ligthert <no************@planet.nl> wrote:
You can use in C# this for what you ask.

int a = (int) 99 / (int) 50;

I hope this helps?

I think you missed the point of my post.

In C#, 99/50 is 1, because the exact meaning of the / operator depends
on the type of the operands.

In VB.NET, 99/50 is 1.98, because / always means "floating point
division".

As the OP hasn't specified what language they're using, but many people
up to) have assumed one language or another. (Most have assumed C# or
C++, Gerald has assumed VB.NET.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #11
Jon,

I know, however for the same sake could you have given this answer direct.

Cor
Jul 21 '05 #12
Thanks for all the informative posts on the art of dividing.
I use C#.
Usually you are told that the choice of .NET language is, to a great extend,
a matter of preference, thus I considered standard operations like division
to be the identical across .NET languages.

I assume the behaveiours in C#, managed C++ and C++ are identical. Is that
right?

In C#, is there any difference between:
int i = 99 / 50;
and: int i = (int) 99 / (int) 50;
Isn't the numbers already considered integers and therefore forcing an
integer division?
Thank you, Teis
"Jon Skeet [C# MVP]" wrote:
Cor Ligthert <no************@planet.nl> wrote:
You can use in C# this for what you ask.

int a = (int) 99 / (int) 50;

I hope this helps?

I think you missed the point of my post.

In C#, 99/50 is 1, because the exact meaning of the / operator depends
on the type of the operands.

In VB.NET, 99/50 is 1.98, because / always means "floating point
division".

As the OP hasn't specified what language they're using, but many people
up to) have assumed one language or another. (Most have assumed C# or
C++, Gerald has assumed VB.NET.)

Jul 21 '05 #13
Teis Draiby <te*************@draiby.com> wrote:
Thanks for all the informative posts on the art of dividing.
I use C#.
Usually you are told that the choice of .NET language is, to a great extend,
a matter of preference, thus I considered standard operations like division
to be the identical across .NET languages.
The operation is - but the syntax isn't. It's only a syntactic
difference here, just as another language could use "div" for integer
division and "fdiv" for floating point division. C# uses one operator
and overloads it depending on operand type; VB.NET uses two different
operators (presumably mainly for historical reasons).
I assume the behaveiours in C#, managed C++ and C++ are identical. Is that
right?
I believe so.
In C#, is there any difference between:
int i = 99 / 50;
and: int i = (int) 99 / (int) 50;
Isn't the numbers already considered integers and therefore forcing an
integer division?

Indeed.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #14
Jon,

I was me not aware of that, does that mean that we can say that VBNet is
more precise in calculating than C#?

Dim a As Double = 99 * 1 / 50
a = 1.98

double a = 99 * 1 / 50;
a = 1.0

Cor
Jul 21 '05 #15

"Cor Ligthert" <no************@planet.nl> wrote in message
news:u1**************@TK2MSFTNGP14.phx.gbl...
Jon,

I was me not aware of that, does that mean that we can say that VBNet is
more precise in calculating than C#?

Dim a As Double = 99 * 1 / 50
a = 1.98

double a = 99 * 1 / 50;
a = 1.0

Cor
heh, no. The precision is the same. The syntax is different.
Jon is just pointing out that C# chooses which method to use based on
From a VB background, I am used to the two different operators. With C style
syntax being different, I was not surprised that C# seemed to deal with both
But I was a little surprised that given your sample: double a = 99 * 1 / 50;
a = 1.0

I would have made the assumption that because the return value was double,
the undecorated constants would have been treated as doubles. Clearly I
would be wrong. From a VB users point of view, this would cause confusion,
just as VB's method would cause a C# user to be confused.

double a = 99 * 1 / 50;
it is evaluated as:
double a = (99 * 1) / 50;
a = 1.0

If it was evaluated as:
double a = 99 * (1 / 50);
Then a = 0.0

Who would have thought something so simple could be confusing?

Gerald
Jul 21 '05 #16
Cor Ligthert <no************@planet.nl> wrote:
I was me not aware of that, does that mean that we can say that VBNet is
more precise in calculating than C#?
No. It just means that when the operands of an arithmetic operator are
both integeral types, so is the result of the operator.
Dim a As Double = 99 * 1 / 50
a = 1.98

double a = 99 * 1 / 50;
a = 1.0

So cast one of the sides appropriately:

double a = 99 * (double)1/50;
a=1.98

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #17
Jon,

I was before aware of almost the exact answer I would get, however could not
resist this one.

And I can give comments on that, however I don't

:-)

Cor
Jul 21 '05 #18
Gerald Hernandez <Cablewizard@spam_remove> wrote:
But I was a little surprised that given your sample:
double a = 99 * 1 / 50;
a = 1.0
I would have made the assumption that because the return value was double,
the undecorated constants would have been treated as doubles.

No - the use of the result of an operator never affects what the
operator does.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #19

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Gerald Hernandez <Cablewizard@spam_remove> wrote:
But I was a little surprised that given your sample:
double a = 99 * 1 / 50;
a = 1.0
I would have made the assumption that because the return value was

double, the undecorated constants would have been treated as doubles.

No - the use of the result of an operator never affects what the
operator does.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet

Lesson learned. Thank you for you pointing out the differences for me.

Gerald
Jul 21 '05 #20
> double a = 99 * (double)1/50;
a=1.98
Instead of casting one of the operands, couldn't I just add a decimal point.
Can I then be sure that the operand is always interpreted as a double rather
than, e.g., a float?
Like this:

double a = 99 * 1.0 / 50;
a = 1.98;

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Cor Ligthert <no************@planet.nl> wrote:
I was me not aware of that, does that mean that we can say that VBNet is
more precise in calculating than C#?

No. It just means that when the operands of an arithmetic operator are
both integeral types, so is the result of the operator.
Dim a As Double = 99 * 1 / 50
a = 1.98

double a = 99 * 1 / 50;
a = 1.0

So cast one of the sides appropriately:

double a = 99 * (double)1/50;
a=1.98

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet

Jul 21 '05 #21
Teis Draiby <te*************@draiby.com> wrote:
double a = 99 * (double)1/50;
a=1.98

Instead of casting one of the operands, couldn't I just add a decimal point.
Can I then be sure that the operand is always interpreted as a double rather
than, e.g., a float?

Yes, that's fine. If you don't have a suffix, a real literal is always
taken to be a double. Of course, you could always put 1.0d in there

Using a cast is handy when the operands are variables rather than
literals.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
Jul 21 '05 #22
Thank you,
Teis
Jul 21 '05 #23
George, you're mixing apples and oranges. .99999... is a decimial character
representation of a floating point number. Integers are never stored or
handled on the chip with any fractional portion. Don't forget that floating
point numbers are just the best attempt to fit numbers into the registers,
and not necessarily accurate to the last decimal character input or output.

"George Hester" wrote:
I don't think so. At first I would have said "yes" agreed with you. But in machine language .9999999999999999 is 1
not 0 16 bit here. In other words in pure mathematics .99999... = 1 but the machine cannot run out to infinity it can only
run out to the bits allowed allowed for integers. In this case ..99999....9 = 1. We'd have to test that to be sure but that
seems reasonable.

Jul 21 '05 #24
Yes well I tried this:

/* inttest.c */
#include <stdio.h>
void main(){
printf("n is %d", (int).99999999999999999);
return;
}

This:

/* inttest.c */
#include <stdio.h>
void main(){
printf("n is %d", (int).9999999999999999);
return;
}

That was my point. The op's assumption that integer/integer will always be truncated to the largest integer < than the value is not right. The finiteness of the "registers" makes that not true.

--
George Hester
_________________________________
"heb" <he*@discussions.microsoft.com> wrote in message news:80**********************************@microsof t.com...
George, you're mixing apples and oranges. .99999... is a decimial character
representation of a floating point number. Integers are never stored or
handled on the chip with any fractional portion. Don't forget that floating
point numbers are just the best attempt to fit numbers into the registers,
and not necessarily accurate to the last decimal character input or output.

"George Hester" wrote:
I don't think so. At first I would have said "yes" agreed with you. But in machine language .9999999999999999 is 1
not 0 16 bit here. In other words in pure mathematics .99999... = 1 but the machine cannot run out to infinity it can only
run out to the bits allowed allowed for integers. In this case ...99999....9 = 1. We'd have to test that to be sure but that
seems reasonable.

Jul 21 '05 #25

### This discussion thread is closed

Replies have been disabled for this discussion.