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

[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...

[Hans Kesting]

"Whidbey Wave" <in*********@yahoo.com> wrote in message news:77**************************@posting.google.c om...

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...

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

[Morten Wennevik]

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.

--
Happy coding!
Morten Wennevik [C# MVP]

[Hans Kesting]

"Morten Wennevik" <Mo************@hotmail.com> wrote in message news:opr9xsacxpklbvpo@morten_x.edunord...

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.
--
Happy coding!
Morten Wennevik [C# MVP]

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

[Stu Smith]

"Hans Kesting" <ne***********@spamgourmet.com> wrote in message
news:OP**************@TK2MSFTNGP11.phx.gbl...

"Whidbey Wave" <in*********@yahoo.com> wrote in message news:77**************************@posting.google.c om...

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...

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!

0.5 + 0.25 = 0.75

What part of that can't be represented exactly in binary floating-point?

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

[Colin Young]

See e.g.:

http://www.math.grin.edu/~stone/cour...EEE-reals.html

http://research.microsoft.com/~holla...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

"Stu Smith" <st*****@nospam-digita.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"Hans Kesting" <ne***********@spamgourmet.com> wrote in message
news:OP**************@TK2MSFTNGP11.phx.gbl...

"Whidbey Wave" <in*********@yahoo.com> wrote in message

news:77**************************@posting.google.c om...

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...

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!

0.5 + 0.25 = 0.75

What part of that can't be represented exactly in binary floating-point?

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

[Jon Skeet [C# MVP]]

Colin Young <[e-mail]> wrote:

See e.g.:

http://www.math.grin.edu/~stone/cour...EEE-reals.html

http://research.microsoft.com/~holla...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).

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Colin Young]

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Colin Young <[e-mail]> wrote:

See e.g.:

http://www.math.grin.edu/~stone/cour...EEE-reals.html

http://research.microsoft.com/~holla...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).

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Stu Smith]

"Colin Young" <[e-mail]> wrote in message
news:u9**************@TK2MSFTNGP10.phx.gbl...

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).
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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Colin Young <[e-mail]> wrote:

See e.g.:

http://www.math.grin.edu/~stone/cour...EEE-reals.html

http://research.microsoft.com/~holla...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).

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.

--
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]]

Stu Smith <st*****@nospam-digita.com> wrote:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Colin Young]

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" <st*****@nospam-digita.com> wrote in message
news:ux**************@TK2MSFTNGP11.phx.gbl...

"Colin Young" <[e-mail]> wrote in message
news:u9**************@TK2MSFTNGP10.phx.gbl...

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).

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Colin Young <[e-mail]> wrote:
> See e.g.:
>
> http://www.math.grin.edu/~stone/cour...EEE-reals.html
>
> http://research.microsoft.com/~holla...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).

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Colin Young]

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Stu Smith <st*****@nospam-digita.com> wrote:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too