[RESOLVED] Math/stats question - Infinity / (1 + Infinity)

[gigemboy]

I am using the Math.Exp function in a calculation, and the result essentially is Infinity / 1 + Infinity, which is 1 statistically, but it is showing as "NaN" (not a number). Is there a way to calculate/show the result of this as 1 (besides just testing for NaN and explicitly setting it as 1?)

The equation simplifies as:

Math.Exp(X) / (1 + Math.Exp(X))

X is a number larger than 709.782712893 in order to get the NaN result.

[Megalith]

you would best have something like this

If X > 709.782712893 then
    result=1
Else 
    result = Math.Exp(X) / (1 + Math.Exp(X))
End If

EDIT: What type is X and the type where you are placing the result? presumably they are double?

[gigemboy]

That is one way that I was aware of, but was wanting to see if there was a way to calculate it that takes that into consideration automatically and knows that the result is 1, instead of explicitly testing the input/output values. I guess what I'm saying is, are there statistical/math functions in .Net that would calculate the result correctly?

The result should be 1, which makes NaN incorrect. It is NaN I am assuming because of the overflow of a double on the Exp function return value when the input value is greater than 709.782712893 (which makes the exp function result go farther into infinity)

[Pradeep1210]

I get 1 as the result when I try to do this:

Dim result = Math.Exp(709.782712893) / (1 + Math.Exp(709.782712893))
Debug.Print(result.ToString)

[gigemboy]

I get 1 as the result when I try to do this:

Dim result = Math.Exp(709.782712893) / (1 + Math.Exp(709.782712893))
Debug.Print(result.ToString)

Now increase that by .000000001, since that is not larger than 709.782712893

[Megalith]

you could override the Exponential function and derive an answer using a Taylor Series perhaps? or even better create a function that gives the result of this using a Taylor function (or another finite series expression) see this wiki http://en.wikipedia.org/wiki/Taylor_series

[cicatrix]

NaN is not an overflow, it's an acronym from Not a Number. It's a feature of floating point calculations mechanism and I doubt it can be overridden.

[Pradeep1210]

Does this help?

Private Sub Button11_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button11.Click
    Dim n1 As Double = FixD(709.78271289983434, 7)
    Dim result = Math.Exp(n1) / (1 + Math.Exp(n1))
    Debug.Print(result.ToString)
End Sub
 
Function FixD(ByVal number As Double, ByVal digits As Integer) As Double
    Dim x As Double = 10 ^ digits
    Return Fix(number * x) / x
End Function

[gigemboy]

Does this help?

Not sure if that helps or not. What is that doing?

[Pradeep1210]

The FixD function truncates the number to specified number of digits. (In this case 7 digits, which is safe for us to work with)
The truncated result is then used for calculation.

[Megalith]

NaN is not an overflow, it's an acronym from Not a Number. It's a feature of floating point calculations mechanism and I doubt it can be overridden.

I mean to write your own function using a finite series of polynomials that are the equivalent to the expression needed, in this particular case the function will need to evaluate:-
(the Sum of with n = 0 to infinity(ish)) (X^n / n!) / (1 + (X^n / n!)) where n! is a factorial. you would not really need to be needing n over about 10 to get an accurate result but you could compare the last value to the current one and see the accuracy and decide when you were near enough.

[gigemboy]

NaN is not an overflow, it's an acronym from Not a Number. It's a feature of floating point calculations mechanism and I doubt it can be overridden.

A signalling NaN (listed in the same wiki page) can in fact represent a number that is in overflow. Whether that is the case here or not, I'm not sure.

[gigemboy]

I mean to write your own function using a finite series of polynomials that are the equivalent to the expression needed, in this particular case the function will need to evaluate:-
(the Sum of with n = 0 to infinity(ish)) (X^n / n!) / (1 + (X^n / n!)) where n! is a factorial. you would not really need to be needing n over about 10 to get an accurate result but you could compare the last value to the current one and see the accuracy and decide when you were near enough.

Megalith, I appreciate the effort, but you are speaking Greek to me I'm not a math/stats guy, just writing some code to see if we can perform some calculations in .Net for our stats guy here, and he is picky about the underlying code. Sounds good, though

[Shaggy Hiker]

For the compiler to give you the right answer in this case, it would have to evaluate the whole function rather than just the Math.Exp portion followed by the / portion. There could be rules if NAN/NAN is ALWAYS 1, but I don't believe it is, because NAN can mean many different things. X/NAN can evaluate to 0, 1, Infinity (which would be a form of NAN), or NAN (not meaning infinity), depending on how NAN was arrived at. Therefore, NAN/NAN would also require knowledge of how the NAN was arrived at, which means that the compiler would have to have contextual information.

Furthermore, Exp(710) is not actually infinity, it's just a number that is too large to represent in the double data type. Exp(810)/Exp(710) is certainly not 1, but by the rules you are applying it would be, as it is NAN/NAN.

So the solution is that Math.Exp(x) doesn't provide valid results for values of x above a certain point. If you want valid results up there, you will have to write your own replacement. If you don't care about valid results up there, or want them to evaluate to some value, then you also have to write your replacement, it would just be easier.

[Megalith]

Megalith, I appreciate the effort, but you are speaking Greek to me I'm not a math/stats guy, just writing some code to see if we can perform some calculations in .Net for our stats guy here, and he is picky about the underlying code. Sounds good, though

I wish i could explain it in terms you would understand essentially you need to do a sum and add the result to a running total, you would need to have an additional function to calculate the factorial, not sure if vb has a function for this but its not too hard, factorial of 7 for example is !7 (or 7!) which is 1 x 2 x 3 x 4 x 5 x 6 x 7. I could write an example if needed but although we aren't talking simple maths this is the kind of thing a pc could easily work out. The result would be a real number in this case and not a Nan (although strictly speaking it could be but it would be higher than you used in the first place) you could also use a string and evaluate but this would be considerably harder (although you would be not restricted to 64 bits) there are examples of code to do this on the net however. its a similar problem mathematically as (sin x) / x which evaluates to infinity. thinking about it also, it is possible to scale an exponential so you could use 70.9782712894
and exp(10) not sure on how that works off the top of my head though. and i seem to remember you can evaluate exponential using sin or cos.

[gigemboy]

Thanks for all the input, fellas. The values really didn't matter for input values larger than the 709.782712893 number, so I just "cheated" and evaluated the input first to see if it was larger. If so, it just returned 1 for the equation. Simple and effective for me, but for stats people, who knows

[Shaggy Hiker]

In the case of statistics, a value raised to 709 is effectively infinite in all cases that I can think of.

[NickThissen]

First of all, Infinity / (1 + Infinity) is not a valid equation, nor does it yield a number, and it certainly does not equal 1. It is true though that the limit of your function, for x to infinity, is equal to 1. However, 710 is not quite infinity, nor is e⁷¹⁰.

The reason for the NaN result is simple: the result for e⁷¹⁰ is about 2,23 x 10³⁰⁸, which is more than the Double datatype (or any numeric datatype for that matter) can hold. So, .NET makes it Double.Infinity.
The denominator of your equation thus yields 1 + Double.Infinity, which is again Double.Infinity.
Finally, the result is Double.Infinity / Double.Infinity, which is not 1 (because infinity is not a number), but NaN (not a number).


The value for your function for x = 710 is this:

0.99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999552371377432487004391683929770867765950639

The deviation from exactly 1 starts around the 300th digit. In other words, you need to calculate the value with more than 300 digits of precision before you notice that the value is not 1.
I doubt you need that much precision

In fact, your equation is already nearly indistinguishable from 1 for x around 20. For x = 20, the value is 0.9999999979...
So you may as well 'hardcode' the equation to return 1 for x > 20 or something.

[NickThissen]

In the case of statistics, a value raised to 709 is effectively infinite in all cases that I can think of.

I can't think of any application of values raised to such large powers where the result is not regarded as infinite. Hell, in physics we regularly take values raised to a power of 4 or 5 as infinite