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

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

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

"Whidbey Wave" <indianiowan@yahoo.com> wrote in message news:77860a1a.0406202213.1f9d78ad@posting.google.c om...[color=blue]
> 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...[/color]

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

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

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]

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

"Morten Wennevik" <MortenWennevik@hotmail.com> wrote in message news:opr9xsacxpklbvpo@morten_x.edunord...[color=blue]
> 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[/color]
equal in both places, have been processed slightly different before being sent to Math.Log.[color=blue]
>
> --
> Happy coding!
> Morten Wennevik [C# MVP][/color]

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

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

"Hans Kesting" <news.2.hansdk@spamgourmet.com> wrote in message
news:OPrH3p2VEHA.2840@TK2MSFTNGP11.phx.gbl...[color=blue]
>
> "Whidbey Wave" <indianiowan@yahoo.com> wrote in message[/color]
news:77860a1a.0406202213.1f9d78ad@posting.google.c om...[color=blue][color=green]
> > 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...[/color]
>
> 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![/color]

0.5 + 0.25 = 0.75

What part of that can't be represented exactly in binary floating-point?
[color=blue]
>
> 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
>
>[/color]

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

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" <stuarts@nospam-digita.com> wrote in message
news:%23ib11T5VEHA.3024@TK2MSFTNGP09.phx.gbl...[color=blue]
>
> "Hans Kesting" <news.2.hansdk@spamgourmet.com> wrote in message
> news:OPrH3p2VEHA.2840@TK2MSFTNGP11.phx.gbl...[color=green]
> >
> > "Whidbey Wave" <indianiowan@yahoo.com> wrote in message[/color]
> news:77860a1a.0406202213.1f9d78ad@posting.google.c om...[color=green][color=darkred]
> > > 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...[/color]
> >
> > 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![/color]
>
> 0.5 + 0.25 = 0.75
>
> What part of that can't be represented exactly in binary floating-point?
>[color=green]
> >
> > 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
> >
> >[/color]
>
>[/color]

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

Colin Young <x@nospam.com> wrote:[color=blue]
> 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).[/color]

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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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

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]" <skeet@pobox.com> wrote in message
news:MPG.1b40fe2919e247e798ad22@msnews.microsoft.c om...[color=blue]
> Colin Young <x@nospam.com> wrote:[color=green]
> > 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[/color][/color]
info.[color=blue][color=green]
> >
> > If you need to represent exact numbers (e.g. financial calcs where you[/color][/color]
can't[color=blue][color=green]
> > just drop a penny here and there) use System.decimal, but note that it[/color][/color]
will[color=blue][color=green]
> > only work with numbers that you can write down exactly (e.g. 1/3 can't[/color][/color]
be[color=blue][color=green]
> > represented exactly in decimal or float).[/color]
>
> 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 - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

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

"Colin Young" <x@nospam.com> wrote in message
news:u99R3o7VEHA.3696@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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[/color]
smart-ass.[color=blue]
> 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).[/color]

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
[color=blue]
>
> Colin
>
> "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
> news:MPG.1b40fe2919e247e798ad22@msnews.microsoft.c om...[color=green]
> > Colin Young <x@nospam.com> wrote:[color=darkred]
> > > 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[/color][/color]
> info.[color=green][color=darkred]
> > >
> > > If you need to represent exact numbers (e.g. financial calcs where you[/color][/color]
> can't[color=green][color=darkred]
> > > just drop a penny here and there) use System.decimal, but note that it[/color][/color]
> will[color=green][color=darkred]
> > > only work with numbers that you can write down exactly (e.g. 1/3 can't[/color][/color]
> be[color=green][color=darkred]
> > > represented exactly in decimal or float).[/color]
> >
> > 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 - <skeet@pobox.com>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

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

Stu Smith <stuarts@nospam-digita.com> wrote:[color=blue]
> 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.[/color]

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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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

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" <stuarts@nospam-digita.com> wrote in message
news:uxWgVHDWEHA.4092@TK2MSFTNGP11.phx.gbl...[color=blue]
>
> "Colin Young" <x@nospam.com> wrote in message
> news:u99R3o7VEHA.3696@TK2MSFTNGP10.phx.gbl...[color=green]
> > 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[/color]
> smart-ass.[color=green]
> > I figured the OP could use the links I provided since it seems that[/color][/color]
their[color=blue][color=green]
> > code isn't dealing with numbers that are guaranteed to be exactly
> > representable (as does the code most of us probably write).[/color]
>
> Apologies, it was smart-ass-ness. It was just that chap said you "CAN'T"[/color]
get[color=blue]
> exact results from floating point, which to me seems just as inaccurate as
> expecting exact results every time. Some numbers can be represented[/color]
exactly,[color=blue]
> and some (most!) numbers can't be. Obviously all FP numbers are exact
> numbers themselves; it's the FP operations which give mathematically[/color]
inexact[color=blue]
> results at certain (but not all) times.
>
> I'll try to hold back a bit on the nit-picking next time,
> Stu
>[color=green]
> >
> > Colin
> >
> > "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
> > news:MPG.1b40fe2919e247e798ad22@msnews.microsoft.c om...[color=darkred]
> > > Colin Young <x@nospam.com> wrote:
> > > > See e.g.:
> > > >
> > > > http://www.math.grin.edu/~stone/cour...EEE-reals.html
> > > >
> > > >[/color][/color][/color]
http://research.microsoft.com/~holla...ieeefloat.html[color=blue][color=green][color=darkred]
> > > >
> > > > A quick google search on IEEE floating point will turn up lots more[/color]
> > info.[color=darkred]
> > > >
> > > > If you need to represent exact numbers (e.g. financial calcs where[/color][/color][/color]
you[color=blue][color=green]
> > can't[color=darkred]
> > > > just drop a penny here and there) use System.decimal, but note that[/color][/color][/color]
it[color=blue][color=green]
> > will[color=darkred]
> > > > only work with numbers that you can write down exactly (e.g. 1/3[/color][/color][/color]
can't[color=blue][color=green]
> > be[color=darkred]
> > > > 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[/color][/color][/color]
represented[color=blue][color=green][color=darkred]
> > > exactly.
> > >
> > > Note that decimal floating point doesn't fundamentally represent
> > > numbers exactly in a way that binary floating point can't - it's just[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > 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 - <skeet@pobox.com>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too[/color]
> >
> >[/color]
>
>[/color]

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

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]" <skeet@pobox.com> wrote in message
news:MPG.1b421be616c5d79098ad36@msnews.microsoft.c om...[color=blue]
> Stu Smith <stuarts@nospam-digita.com> wrote:[color=green]
> > Apologies, it was smart-ass-ness. It was just that chap said you "CAN'T"[/color][/color]
get[color=blue][color=green]
> > exact results from floating point, which to me seems just as inaccurate[/color][/color]
as[color=blue][color=green]
> > expecting exact results every time. Some numbers can be represented[/color][/color]
exactly,[color=blue][color=green]
> > and some (most!) numbers can't be. Obviously all FP numbers are exact
> > numbers themselves; it's the FP operations which give mathematically[/color][/color]
inexact[color=blue][color=green]
> > results at certain (but not all) times.[/color]
>
> 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 - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]