Mail Archives: djgpp/1999/05/31/14:20:24
El día Sat, 29 May 1999 21:10:17 GMT, f DOT natter AT ndh DOT net (Felix Natter)
escribió:
>the thing is that when you solve this system using Gaussian
>Elimination, all the factors by which you scale the 'rows' are
>rational numbers. the most "complicated" fraction by which you
>multiply is probably -1/11 - would this bring the accuracy of a double
>to its knees.
It shouldn't, if that was the only operation to do.
But if you have to multiply, for example, 20 by 1/11 (which is first
evaluated to a limited-precision double) and then let's say subtract
from (10 * 2/11), then, maybe the result is not exactly zero. But it
should be below a given threshold.
>Would you recommend that I always use arbitrary precision math for
>such algorithms ? (I don't think the idea to set anything to zero if
>|x| < SMALL_NUMBER, as this would make the algorithm unusable for
>other systems.
For a simple program, it should be easier to handle thresholding
yourself (this would NOT make the algorithm unusable for other systems
- read on), while if you are writing a complex application, the
arbitrary precision math would be of much help. It is probably a
matter of taste: do whatever you like best.
Regarding the portability issue, you should know that DBL_EPSILON is
part of the ANSI standard as the minimum double so that ((1.0 + x) !=
1.0), so every compliant compiler should define it appropiately. Other
appropiate constants are defined for other floating types. So, if you
use a multiple of DBL_EPSILON as your threshold (the factor depends on
the absolute values of the numbers you are working with), your program
will be portable.
By the way, keep in mind that due to the limited precission,
comparisons like:
if (a == b) { ... }
are WRONG when a, b are doubles (or floats); instead, use:
if (fabs(a - b) < threshold) { ... }
Regards,
GUILLE
----
Guillermo Rodriguez Garcia
XXguille AT XXiies DOT XXes (ya sabes :-)
- Raw text -