why Math.Log(8,2) is 2.9999999999999996 and not 3

  • Thread starter Thread starter Whidbey Wave
  • Start date Start date
W

Whidbey Wave

Hello Gurus,
Here is a problem, where i am unable to reason HOW it happens? I wrote
a dll using math.log. This dll when used within application A works
fine, but not with application B. On debugging I was biting my nails,
when i saw result in immediate window.

?Math.Log(8,2)
2.9999999999999996

Currently i am not using it anymore, but like to know if anybody faced
such a situtation. I am aware there were no overrides being used in
any of those two executables.


Thanks
Wave...
 
Whidbey Wave said:
Hello Gurus,
Here is a problem, where i am unable to reason HOW it happens? I wrote
a dll using math.log. This dll when used within application A works
fine, but not with application B. On debugging I was biting my nails,
when i saw result in immediate window.

?Math.Log(8,2)
2.9999999999999996

Currently i am not using it anymore, but like to know if anybody faced
such a situtation. I am aware there were no overrides being used in
any of those two executables.


Thanks
Wave...
Click to expand...

Fairly frequently asked question, though usually in the form of:
"why is 21.9 + 3.1 not exactly equal to 25?"

The "problem" is how computers (*any* computer, it's not
specifically .net related or even microsoft related) handle
floating point numbers. You CAN'T get exact results using
floating points!

As an example: try to specify 1/3 *exactly* in a finite number
of decimals, so that multiplying it by 3 gives exactly 1.

Hans Kesting
 
I think he meant why is it happening on Application B when Application A shows the correct result, 3.
I'm guessing that you don't use Math.Log(8,2) in both places, but pass the variables as floats or doubles that although may seem equal in both places, have been processed slightly different before being sent to Math.Log.
 
Morten Wennevik said:
I think he meant why is it happening on Application B when Application A shows the correct result, 3.
I'm guessing that you don't use Math.Log(8,2) in both places, but pass the variables as floats or doubles that although may seem
Click to expand...
equal in both places, have been processed slightly different before being sent to Math.Log.
Okay, you are right.
What I *should* have added is that the printed result can also
depend on the way that is done: a "print" of the result might
automatically be done in (say) six decimals, in which case
the "real" result of 2.999999999996 can be *displayed*
as "3". So the calculation can result in exactly the same value
(as it should, if the inputvalues are the same) but the displayed
results can differ, if done in different ways (I'm guessing that
Application A was printing the result somewhere. The
result in Application B was viewed in the debugger)

Hans Kesting
 
Hans Kesting said:
Fairly frequently asked question, though usually in the form of:
"why is 21.9 + 3.1 not exactly equal to 25?"

The "problem" is how computers (*any* computer, it's not
specifically .net related or even microsoft related) handle
floating point numbers. You CAN'T get exact results using
floating points!
Click to expand...

0.5 + 0.25 = 0.75

What part of that can't be represented exactly in binary floating-point?
 
See e.g.:

http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html

http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

A quick google search on IEEE floating point will turn up lots more info.

If you need to represent exact numbers (e.g. financial calcs where you can't
just drop a penny here and there) use System.decimal, but note that it will
only work with numbers that you can write down exactly (e.g. 1/3 can't be
represented exactly in decimal or float).

Colin
 
Colin Young said:
See e.g.:

http://www.math.grin.edu/~stone/courses/fundamentals/IEEE-reals.html

http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html

A quick google search on IEEE floating point will turn up lots more info.

If you need to represent exact numbers (e.g. financial calcs where you can't
just drop a penny here and there) use System.decimal, but note that it will
only work with numbers that you can write down exactly (e.g. 1/3 can't be
represented exactly in decimal or float).
Click to expand...

That doesn't answer Stu's question though. He's absolutely right -
calculations involving things like 0.5 and 0.75 may well be represented
exactly.

Note that decimal floating point doesn't fundamentally represent
numbers exactly in a way that binary floating point can't - it's just a
different base, so more numbers are exactly representible.

See http://www.pobox.com/~skeet/csharp/floatingpoint.html and
http://www.pobox.com/~skeet/csharp/decimal.html for more info.
 
I just assumed he had picked those numbers at random. It wasn't entirely
clear from his post if he was genuinely curious, or just being a smart-ass.
I figured the OP could use the links I provided since it seems that their
code isn't dealing with numbers that are guaranteed to be exactly
representable (as does the code most of us probably write).

Colin
 
Colin Young said:
I just assumed he had picked those numbers at random. It wasn't entirely
clear from his post if he was genuinely curious, or just being a smart-ass.
I figured the OP could use the links I provided since it seems that their
code isn't dealing with numbers that are guaranteed to be exactly
representable (as does the code most of us probably write).
Click to expand...

Apologies, it was smart-ass-ness. It was just that chap said you "CAN'T" get
exact results from floating point, which to me seems just as inaccurate as
expecting exact results every time. Some numbers can be represented exactly,
and some (most!) numbers can't be. Obviously all FP numbers are exact
numbers themselves; it's the FP operations which give mathematically inexact
results at certain (but not all) times.

I'll try to hold back a bit on the nit-picking next time,
Stu
Colin
Click to expand...
 
Stu Smith said:
Apologies, it was smart-ass-ness. It was just that chap said you "CAN'T" get
exact results from floating point, which to me seems just as inaccurate as
expecting exact results every time. Some numbers can be represented exactly,
and some (most!) numbers can't be. Obviously all FP numbers are exact
numbers themselves; it's the FP operations which give mathematically inexact
results at certain (but not all) times.
Click to expand...

How you regard FP numbers is an interesting point, actually. You can
either regard them as exact numbers which are within a certain distance
of the last calculation, or you can regard them as a range in and of
themselves. I've never been entirely certain which is the best way of
thinking of them - I suspect it depends on the situation.

My point about decimal vs double is an important one though - people
tend to think of decimals as "exact" and doubles as "rough" when
there's no such distinction in reality - they have different bases,
levels of precision and scale ranges, but they're fundamentally much
more similar than they're usually portrayed.
 
No apologies necessary. I didn't want the OP to get confused since the issue
you raised requires an understanding of FP representation that it was clear
the OP didn't have.

I'm just jealous I didn't think of doing the same thing (I'll lay the blame
on being chronically sleep-deprived these days).

Colin

Stu Smith said:
Colin Young said:
I just assumed he had picked those numbers at random. It wasn't entirely
clear from his post if he was genuinely curious, or just being a smart-ass.
I figured the OP could use the links I provided since it seems that their
code isn't dealing with numbers that are guaranteed to be exactly
representable (as does the code most of us probably write).
Click to expand...

Apologies, it was smart-ass-ness. It was just that chap said you "CAN'T" get
exact results from floating point, which to me seems just as inaccurate as
expecting exact results every time. Some numbers can be represented exactly,
and some (most!) numbers can't be. Obviously all FP numbers are exact
numbers themselves; it's the FP operations which give mathematically inexact
results at certain (but not all) times.

I'll try to hold back a bit on the nit-picking next time,
Stu
Click to expand...
 
Here's a decent article explaining numbers in computers in pretty simple
terms: http://www.sybase.com/detail?id=1012599. I'm including it for
completeness for interested observers, not that I think Mr. Smith or Mr.
Skeet need this explained to them (I have a naive hope that people having
trouble with floating point will do a google search first and find this
thread archived).

I've actually never really completely understood the whole decimal thing. I
blame it on my engineering education. As far as I'm concerned 1.24e4 +
9.3e-1 = 1.24e4, but just try telling an accountant that 93 cents can just
be ignored.

Colin
 
Back
Top