[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Float Pt Precision

On Thu, 29 Jul 1999, EXT Uncle George wrote:

> Been trying to determine why the double's between an Intel Box & and
> Alpha box are different on postgresql.
> The algoritms:
> 1a)    t1.q = result.A * pt1.x;
> 1b)   t2.q = pt1.y - t1.q;
> and
> 2)    t3.q = result.C = pt1.y - result.A * pt1.x;
> will produce the same results on the Alpha    0x402ec4ec4ec4ec50,
> but will produce different results in the intel    0x402ec4ec4ec4ec50,
> 0x402ec4ec4ec4ec54

To judge the errors involved, it would be easier if you'd converted these
to human readable form and provided us with the input values.

My guess is that you're suffering from canelling. It frequently happens
that subtraction can yield hopelessly imprecise answers.

> I suppose that this can be chalked up to the extended ( 80bit) precision
> on the Intel box,

Indeed, consider it to have 18 guard digits, to alpha's 2 (a guess)
Crays (e.g. Y-MPs) are worse... (0 guard digits)

> BUT IT MAKES MY life at porting postgres to the alpha, as well as other
> projects very difficult to perform alike equally . A few more
> calculations, and you begin to wonder where the least sig digit has gone
> off to.

Alas there's not much you can do, apart from reading "What every computer
scientist should know about floating point arithmetic" by Professer Kahan.
It comes bundled on every Sun system I've seen, and is freely available on
the internet. (it's name may be slightly different, but the gist is
there). Once armed with that you're as well equipt as anyone can be to
tackle the problem.

> 80 bit extended precision on alpha? This particular feature is not
> mentioned too much ( if at all ) in the alpha literature. Nor are the
> internal methods of processing floating points really described.
> It seems that a lot of folks believe the FP is fast(er than the intel ),
> but it seems to be at the cost of precision. Which for me would be of
> some concern in massive numerical calculations.
> gat
> BTW as a side issue, there doesn't seem to be any way to get the
> compiler to do different 'rounding' techniques.  Ie chopped, +infinity,
> -Infinity.

In C there isn't a way to specify this. 
C defines the rounding which should be used, and it's non IEEE 754/854
compliant. Alas.

If there are any particular expresssions which are giving you problems,
then I'm sure there are other mathematicians on the list who'd be prepared
to cast a numerical analyst's eye to try to help find workarounds. It's
annoying keyhole work, but it sounds as if it may be necessary.

Good luck,

Phil Carmody.
Not speaking for or on behalf of Nokia Telecommunications

Quoted-Printable: a standard for mangling Internet messages
Quoted-Unreadable: the result of applying said standard
Unquoted-Unprintable: the comments from the recipients of the above
-- bf8 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []