Re: Numerical Accuracy
From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 09/16/04
- Next message: Nick Landsberg: "Re: [EGN] Variable hoisting (Updated results...)"
- Previous message: Randy Howard: "Re: [EGN] Variable hoisting (Updated results...)"
- In reply to: Paul Hsieh: "Re: Numerical Accuracy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Sep 2004 19:13:19 -0700
qed@pobox.com (Paul Hsieh) wrote in message news:<796f488f.0409142127.3aed3126@posting.google.com>...
> spinoza1111@yahoo.com (Edward G. Nilges) wrote:
> > "Andrew Au \(Newsgroup\)" <eg_ayh@hotmail.com> wrote:
> > Willem suggests going to double. This will only make the problem
> > worse.
>
> The OP asked for improved tolerance, not necessarily an exact answer
> (the used assert cannot be made to be correct for general input except
> with a bigInt rational number system.) Unless there is an extreme
> requirement that d == c in the OP's calculation (unlikely) then just
> moving to double is likely to be sufficient.
OK. My concern was that the situation seemed to be a floating
situation such as is sometimes encountered with floating point, where
semirandom changes are made until the code works on one platform.
>
> > Jens is right: no simple solution exists. In fact, the code will not
> > be portable.
>
> If there is another requirement such as d <= c, then setting a
> non-portable round-toward-zero mode, while using double might be an
> idea. Otherwise portability should not enter into it.
>
> > I'm wondering if you couldn't use integers that represent percentage
> > probabilities where you would assert that they always sum to certainty
> > (100%).
>
> So long as the final result is required as a floating point, holding
> intermediates in integer form will not help the problem. You need a
> real rational package -- nothing less will make the assert work.
>
> > If your application requires greater precision make these integers the
> > fixed-point representation of numbers with a fixed number of decimal
> > points, indeed, selecting the number of digits to be at the limit of
> > ability to discriminate speech.
>
> This is silly. Only 64 bit platforms have accuracy in their integers
> that isn't supersetted by the accuracy of their double's (speaking of
> non-portable ...)
64 bit platforms are already in wide use. But, this is a portability
hit.
>
> > Any time you need to calculate, transform the integer "just in time"
> > to a double-precision number.
> >
> > int intProbabilities[10];
> > #define PRECISION 2
> > .
> > .
> > .
> > for ( intIndex1 = 0; intIndex1 < 10; intIndex++ )
> > fltSum += (float)(intProbabilities[intIndex1]) / (10 ** PRECISION);
> > assert(fltSum == 100);
>
> This is *NOT* the OP's question. The OP wishes to use the original
> parameters as normalized weights (such that their scaled sum is always
> equal to the scalar itself.) In general the scalar is not an integer,
> so you cannot use this transformation to any relevant effect on
> accuracy of the weighted sum problem.
>
> > The general filassaphy is to minimize floating point errors by using
> > fp only when necessary [...]
>
> This is not a generally applicable heuristic. Using fixed point as
> stand ins for floating point is not necessarily going to be the best
> bet for accuracy of a numerical application. Your best bet is to do
> the full numerical analysis and do what it takes to deal with the
> resulting accuracy problem.
You are right.
>
> For example, one solution not suggested so far, is to *dither* the
> result through the expected sum so as to balance the round off errors
> exactly. This would make the scaled sum artifically sum up as closely
> as possible to the correct scalar, however its arguable as to whether
> performing such an operation leads to a truly more accurate result (it
> might -- this works well in graphics). This would not reduce the
> number of FP operations at all, and it also has no appeal to fixed
> point usage (which just doesn't help in this case.)
OK. But if floating point is causing problems, then one would ask why
use floating point, or, why not use a package such as Mathematica in
which you sacrifice speed for almost any precision you want?
- Next message: Nick Landsberg: "Re: [EGN] Variable hoisting (Updated results...)"
- Previous message: Randy Howard: "Re: [EGN] Variable hoisting (Updated results...)"
- In reply to: Paul Hsieh: "Re: Numerical Accuracy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
