Overflow, Inf and NaN

[Mation]

Hi

 

Apologies if this is a daft question (it probably is). I've searched and haven't found an answer...

 

I'm trying to run a simulation that I've programmed in Matlab. It generates very large and small numbers that can't be represented and so get stored as +/-Inf and further operations on these then become NaN.

 

I can't think of any way to get round this. Is there any way of representing these numbers that would mean I could work on them (on computer), however convoluted?

 

Any help gratefully received, especially if explained as if to a small child

[timo]

It's a bit little you are telling: How large and how small? What kind of simulation and more importantly what kind of data and calculations? The most obvious solution is to rearrange your calculation not to run into the problem. Or you can store the large number as two (or more) large factors which when multiplied would give the large number or you can store the numbers as their logarithms or try if Mathematica (or a similar program) can handle it or look for a custom real number implementation or ... . It's really hard to give a sensible reply when the problem is given as "I have a problem with large numbers, what can I do?".

 

EDIT: Oh ... and are we talking about integer, natural or real numbers?

[Mation]

Many thanks for your reply. Sorry my OP was short on detail.

 

Of the solutions you suggest, I think I definitely need to look at Mathematica, and also a 'custom real number implementation' (I didn't know these existed, so that's a big help). I'm working with real numbers.

 

I'm too shy on this thread to say what the simulation is of as I'm supremely underqualified to do it and it'll take more explanation than I want this thread to be for (I will however stick it all - the idea - on here at some point for criticism and ideas - I just need to work up to it!)

 

The numbers I'm generating at times exceed Matlab's realmin (2.2251e-308) and realmax (1.7977e+308). The simulation requires this - can't get round it in that sense.

 

If I store the numbers as factors how would I then work on the product? Meaning, if I have two huge numbers, both of which are stored as a number of products, what sort of thing do I need to do to unambiguously store the result of an operation that involves both of them? (Again apologies if I'm missing obvious answers).

[D H]

I doubt the simulation require this. Rather it is your formulation of the problem is what requires this. There are often ways around such problems. Scaling and normalization techniques solve many such problems in a neutral way. When these don't work, people sometimes resort to heuristics to get rid of the problematic areas.

 

An example: spherical harmonics. A naive spherical harmonics expansion of some function will often lead to extremely small coefficients. The application of these coefficients leads to some extremely large factors. By use of appropriate normalization factors, the problem of small coefficients and large factors pretty much disappears. Where it doesn't, heuristics such as not bothering to compute the 100, 100 term (or any large term) for large radii are employed. (The computation of the contribution of the n,m term with large n and m and large radii will result in underflow. These tiny terms might change the sum in the hundredth decimal point. Why bother?)

[timo]

If I store the numbers as factors how would I then work on the product? Meaning, if I have two huge numbers, both of which are stored as a number of products, what sort of thing do I need to do to unambiguously store the result of an operation that involves both of them? (Again apologies if I'm missing obvious answers).

My idea would have been to catch growing numbers soon enough, something like when a number is stored as [math]a= a1 * a2[/math] and you want to multiply it with a number b you'd schematically do

while (a1 * b  > something large) {
 a2 = a2 * 1.e20
 a1 = a1 / 1.e20
}
while (a1 * b  < something small) {
 a2 = a2 / 1.e20
 a1 = a1 * 1.e20
}
a1 = a1*b;

Another alternative would be to store the numbers as [math]a = a1 \cdot 10^{a2}[/math]. I recommend considering the idea with the logarithms, though. It's how I store probability distributions with a large range of entries and I am quite happy with it. And to agree with DH and what I said previously: The best solution is not to need a range exceeding the double range.