.NET calculations around the number 16384.51

Hot Topic

Local Security Policy
Passing NULL for Callback Function Parameter
Can flash files be imported in Csharp with providing interaction between Csharp and Actionscript?
C# Conversion Issue From Java Encryption...
temp+=temp.Replace(chr(13),"<br>");
Generics: Test for a datatype
pass argument to the Thread
Conversion Issue from VS.NET 2002 to VS.NET 2005
could not find file--dll
How to check 2 reference objects for equality?

Visual C#

Why can't an interface method be internal?
Windows Service or Scheduled Task
Exporting a DLL with Intellisense Descriptions?
Updating references
How to read current active IE window's html content
Using Type specific collections
Read 1 byte at a time from an array
report logging
class design: protected fields
Allow only one instance of an application

.NET calculations around the number 16384.51

I have a question regarding why .NET calculates something strange. We encountered this by accident. Consider the two below lines of code:

int iOK = (int)(16383.51 * 100);
int iNotOK = (int)(16384.51 * 100);

When this is compiled and run, the variable iOK will hold the value 1638351. The value iNokOK will hold the value 1638450 - note the 0 in the end when 1 was expected.

I tried different values for some time, and it breaks just at that number 16384, which is nowhere near the limits of int.

How can this happen



Answer this question

.NET calculations around the number 16384.51

  • chinmayv84

    This is a floating point precision problem.

    The compiler most likely evaluates the expression 16384.51 * 100 as doubles. The result of this is expression is 1638450.9999999998. Casting this to an int results in 1638450.

    One possible solution is as followed
    int rightValue = (int)Math.Round (16384.51 * 100);

  • Saurabh_Mathur

    int iOK = (int)(16383.51m * 100);
    int iNotOK = (int)(16384.51m * 100);

  • KevinDSE

    It's default behaviour as casting to an integer type does not round off, it cuts off the fractional part and leaves you only with the digit before the comma.

  • Digital Mind

    So the default beahviour is the truncating Can you confirm

  • Morten Nielsen

    16384 is a power of 2, perhaps that has something to do with it



  • Mr_White

     Peter N Roth wrote:

    Not so much ‘default behavior’ as it is ‘natural properties of integers and floats’.

     

    thak you for your reply, I feel a bit uneducated when a waste the other time asking basic things I coul find in manuals, sorry, it's not my abit.

    Btw, I don't agree with you that is a "natural properties". It depends by the semantic choosen by the language designer.

    It's more common to observer the truncating which, for performance issue, is better (C, C++, Java, C#, etc... essentially alla C-derived languages) but other language adopt a "default behaviour" different like Pascal (if I right recall).

    I posted that just because sometimes I like to be publicly silly :).

    Bye guys

  • balti bob

    Not so much ‘default behavior’ as it is ‘natural properties of integers and floats’.



  • .NET calculations around the number 16384.51
Answer this question