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 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
Ah! That must be the Math.IEEERemainder()
Thanks, Teis
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
"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
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
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
If replying to the group, please do not mail me too
Jon,
You can use in C# this for what you ask.
int a = (int) 99 / (int) 50;
I hope this helps?
Cor
"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.
"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 If replying to the group, please do not mail me too
Thanks for the additional input. Unfortunately, I forgot to consider C#.
This seems pretty unfriendly, on the part of VB.
Gerald
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
replying on this thread (including Gerald, whose post I was following
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
If replying to the group, please do not mail me too
Jon,
I know, however for the same sake could you have given this answer direct.
Cor
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 replying on this thread (including Gerald, whose post I was following up to) have assumed one language or another. (Most have assumed C# or C++, Gerald has assumed VB.NET.)
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
If replying to the group, please do not mail me too
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
"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
overloading, whereas VB "/" uses Doubles, and "\" uses Integers.
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
by overloading.
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.
FYI, given your example,
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
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
If replying to the group, please do not mail me too
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
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
If replying to the group, please do not mail me too
"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 If replying to the group, please do not mail me too
Lesson learned. Thank you for you pointing out the differences for me.
Gerald
> 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 If replying to the group, please do not mail me too
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
instead to make it clear.
Using a cast is handy when the operands are variables rather than
literals.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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.
Yes well I tried this:
/* inttest.c */
#include <stdio.h>
void main(){
printf("n is %d", (int).99999999999999999);
return;
}
The answer here is 1
This:
/* inttest.c */
#include <stdio.h>
void main(){
printf("n is %d", (int).9999999999999999);
return;
}
the answer is 0.
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. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
23 posts
views
Thread by Teis Draiby |
last post: by
| | | | | | | | | | |