Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion CMUCL18d on Alpha?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Joe Marshall  
View profile  
 More options Apr 22 2002, 3:34 pm
Newsgroups: comp.lang.lisp
From: "Joe Marshall" <prunesqual...@attbi.com>
Date: Mon, 22 Apr 2002 18:48:19 GMT
Local: Mon, Apr 22 2002 2:48 pm
Subject: Re: CMUCL18d on Alpha?

"Raymond Toy" <t...@rtp.ericsson.se> wrote in message

news:4n8z7fk7cz.fsf@rtp.ericsson.se...

>     Joe> There is another benefit to using the extra precision:  the
regions
>     Joe> of instability in numeric algorithms will be smaller.  Naive
users
>     Joe> may be far less likely to get bogus answers.

> I'm not a numerical analyst and don't pretend to be, but I disagree
> with this statement.  If the extra precision was always available, I'd
> agree.  But usually you'll have to convert that 80-bit float to a
> 64-bit float and that's where you lose.

> Somewhere on the web there's an article by Kahan about fused
> multiply/add operations that some machines provide.  Not exactly the
> same, but I think it hints at the subtleties.

The article to which you refer,
``Matlab's Loss is Nobody's Gain''
is available at
http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf

Matlab is a numerical computation package that is quite popular.
Matlab versions prior to 5.0 used the full precision available
in the hardware (64-bit mantissa) and rounded to double precision
when storing the results in memory.  Upon version 5 on Windows,
Matlab changed to using double-precision (53-bit mantissa) in
the hardware.

Kahan argues that this is a mistake and the extra precision should
be turned back on.  To quote Kahan, ``Why not get different results
that are better results whenever the hardware affords the opportunity?''

This paper also talks about the `Fused Multiply Accumulate' instruction
(FMAC) which computes
   (fp-round (+ s (* r q)))
rather than
   (fp-round (+ s (fp-round (* r q))))

(assume fp-round is a function that maps the exact result into the nearest
result that can be represented in a floating point number).

Kahan notes that FMAC in general produces more accurate answers, but that
there are subtle problems with using it indiscriminately.  In particular,
when evaluating an expression like this:  (- (* u v) (* r q)), do you
want to round the (* u v) or the (* r q) prior to using the FMAC
instruction?  It almost never matters, but if u = r and v = q, FMAC can
produce a non-zero answer whereas rounding both produces a zero.

However, this does not argue against using as much precision as possible.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.