I am not a Matlab user so take that in mind.
The main problem behind this is first to detect overflow/underflows
That is sometimes hard because they appear also in other cases when the computation does not return zero
or inf
. For example during numerical integration overflow/underflows can cause the result to be wrong but still a non zero number.
In my experience I tent to see as useful to look at numbers in their hex representation (unless your HW/SW computations use decadic base internally for variables which is rare because most HW/SW is binary). So see the number in Hex form and detect patterns like:
??????????.????FFFFFFFFFFF?? hex
when you look at the fractional part and detect that many FFFFF
's are present near the lowest digits then you number is most likely underflowing or is very near that point. The number of zeros or what ever at the end is usually decreasing with each iteration saturating to:
??????????.????FFFFFFFFFFF hex
The overflows are saturated similarly but on the other side like this:
FFFFFFFFFFF.FFFFFF?????? hex
For some algorithms is more precise to round up/down such numbers before next iteration but you need always check if that is the case on some well known example of computations before applying on unknowns ... Look here:
it is a nice example of algorithm using this technique
Another way to detect overflow/underflows is the prediction of the outcome number magnitude. For example
*
sums the exponents together
/
substract the exponents
sqrt
halves the exponent
+
,-
can result in +1/-1
of the bigger exponent
So if you are dealing with big/small exponents you know which operations could lead to overflowing problems.
On top of that underflows can occur when your results precision does not fit into mantissa. So you need to be careful with operations that increase the used bits of the result like:
a*b
sum of used bits in a
,b
+,-
max used bit of (a,b) - min used bit of (a,b)
/
adds some bits to hold the fractions ...
The +,-
operation is the worst for example if you add 2^100 + 2^-100
then the result needs 200 bits of mantissa while the operands itself have booth just 1 bit of mantissa.
What to do if overflow/underflow is detected:
change equation
As mentioned you can switch to log
which can handle bigger ranges with ease, but have other issues. Also usually slight change in algorithm can lead to results scaled by different factor, but with sub-results still in safe range so you need just the final result to scale back to dangerous range. While changing equations you should always take into account the precision and validity of the outcome.
use bigger variable data type
If I remember correctly Matlab have arbitrary precision numbers so use them if needed. You can also use standard float/double
variables and store the value into more variables something like here:
stop iterating
For example some algorithms use series like:
1/1! + 1/2! + 1/3! + ... + 1/n!
in some cases if you detect you hit the overflowing/underflowing subresult when stop the iteration you still have relatively accurate result of the computation. Do not forget not to include overflowed subresults to the final result.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…