On Tuesday 12 December 2006 11:30, david eddy wrote:
> I have to confess that I tend to work with
> and think in terms of fixed point arithmetic.
> If the source of error in floating point is
> primarily the loss of guard bits (binary places)
> when an intermediate number has an integer part
> say 50 bits long, then I can well understand why the
> analysis of errors differs fundamentally in the two cases.
>
>
> It sounds as if an analysis should determine the frequency with which the
> number of guard bits drops to dangerous levels.
>
> I must concede that this is not a problem in fixed point (IFF you have
> enough bits to contain the integer part at all times!).
> Do you agree that my conjecture about the normal distribution of errors
> makes sense in fixed point?
>
Actually fixed or floating makes little difference. Your analysis looks 
reasonable so long as the precision of the results is infinite or nearly so. 
The problem is that it isn't. Whenever A and B are similar in sign and 
magnitude, the actual precision of the difference of A and B is always a lot 
less than its apparent precision.

The difference between fixed and floating is that, in the case of floating but 
not in the case of fixed, the actual precision of the difference is dependent 
(in a very discrete, discontinuous way) on the absolute magnitude of the 
input values.

There still seems to be an unexplained input of some sort or other which needs 
to be accounted for, as if you plot max error found during N iterations 
against exponent (for a fixed FFT run length) you do not get a smooth 
monotonic increase - some exponents seem to have higher errors than others 
which are a bit bigger, whilst some exponents seem to have lower errors than 
others which are a bit smaller. This effect seems to be consistent as N 
increases, and persistent with different values of offset. There doesn't seem 
to be anything other than actual trial which can distinguish "difficult" 
exponents from "easy" ones, again leading towards the "safety first" strategy 
i.e. if you're a bit unsure, jump to the next run length.

Regards
Brian Beesley
_______________________________________________
Prime mailing list
[email protected]
http://hogranch.com/mailman/listinfo/prime

Reply via email to