Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.physics > #511307 > unrolled thread

What Floating-Point Precisions Would Physicists Prefer?

Back to article view | Back to sci.physics

Contents

  What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-04 20:41 -0700
    Re: What Floating-Point Precisions Would Physicists Prefer? Fabian Russell <root@localhost.localdomain> - 2015-08-05 05:14 +0000
      Re: What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-05 04:38 -0700
        Re: What Floating-Point Precisions Would Physicists Prefer? Fabian Russell <root@localhost.localdomain> - 2015-08-05 14:22 +0000
          nano-M-sets noTthaTguY <abu.kuanysh05@gmail.com> - 2015-08-05 13:14 -0700
            Re: nano-M-sets Fabian Russell <root@localhost.localdomain> - 2015-08-05 21:23 +0000
              Re: nano-M-sets Poutnik <poutnik4nntp@gmail.com> - 2015-08-06 08:16 +0200
                Re: nano-M-sets Fabian Russell <root@localhost.localdomain> - 2015-08-06 17:34 +0000
                  Re: nano-M-sets Quadibloc <jsavard@ecn.ab.ca> - 2015-08-06 11:23 -0700
                    Re: nano-M-sets Fabian Russell <root@localhost.localdomain> - 2015-08-06 18:39 +0000
                      Re: nano-M-sets Poutnik <poutnik4nntp@gmail.com> - 2015-08-06 21:07 +0200
                        Re: nano-M-sets Fabian Russell <root@localhost.localdomain> - 2015-08-06 19:14 +0000
                          Re: nano-M-sets Poutnik <poutnik4nntp@gmail.com> - 2015-08-07 07:41 +0200
                      Re: nano-M-sets Quadibloc <jsavard@ecn.ab.ca> - 2015-08-06 14:17 -0700
                        Re: nano-M-sets Fabian Russell <root@localhost.localdomain> - 2015-08-06 21:36 +0000
                          Re: nano-M-sets Poutnik <poutnik4nntp@gmail.com> - 2015-08-07 08:08 +0200
                  Re: nano-M-sets Poutnik <poutnik4nntp@gmail.com> - 2015-08-06 21:05 +0200
          Re: What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-06 11:18 -0700
            Re: What Floating-Point Precisions Would Physicists Prefer? Fabian Russell <root@localhost.localdomain> - 2015-08-06 19:03 +0000
              Re: What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-06 14:11 -0700
                Re: What Floating-Point Precisions Would Physicists Prefer? Fabian Russell <root@localhost.localdomain> - 2015-08-06 21:51 +0000
                  Re: What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-06 15:18 -0700
                    Re: What Floating-Point Precisions Would Physicists Prefer? Fabian Russell <root@localhost.localdomain> - 2015-08-07 01:11 +0000
                      Re: What Floating-Point Precisions Would Physicists Prefer? noTthaTguY <abu.kuanysh05@gmail.com> - 2015-08-07 10:25 -0700
                      Re: What Floating-Point Precisions Would Physicists Prefer? Quadibloc <jsavard@ecn.ab.ca> - 2015-08-07 11:41 -0700
                      Re: What Floating-Point Precisions Would Physicists Prefer? "hanson" <hanson@quick.net> - 2015-08-07 16:21 -0700
    Re: What Floating-Point Precisions Would Physicists Prefer? Timo <timo@physics.uq.edu.au> - 2015-08-05 04:47 -0700
      Re: What Floating-Point Precisions Would Physicists Prefer? Poutnik <Poutnik4NNTP@gmail.com> - 2015-08-05 14:36 +0200

Page 2 of 2 — ← Prev page 1 [2]

#511665

On Thu, 06 Aug 2015 14:11:40 -0700, Quadibloc wrote:

> 
> If calculating with such numbers "takes a lot of time", then such an option, to 
> decrease exponent range, is reasonable
>

Reducing exponent range will only create a larger and larger unusable interval
around zero, and this would be counterproductive to many applications.

>
> It doesn't reduce the precision or accuracy of calculations that don't involve 
> very small numbers.
> 

No.  That's why "flush to zero" in entirely optional.


>
> However, for such calculations _to_ take a lot of time means that IEEE 754 was 
> not implemented correctly on the processor
>

IEEE 754 only specifies what to accomplish and not so much how to accomplish it.

The fact that denormal numbers take longer to process is a natural consequence
of hardware registers, which are designed for the normalized format.  Thus
a lot of pre-processing for each denormal number is required.  Off the top of
my head, arithmetic on normalized FP takes about 4-5 machine cycles whereas
denormals require about 20-50 machine cycles.  In algorithms that involve much
looping this can add up.

Denormals are a way to avoid the large "gap" around zero and they are very
good to have.

[toc] | [prev] | [next] | [standalone]

#511671

On Thursday, August 6, 2015 at 3:52:07 PM UTC-6, Fabian Russell wrote:

> The fact that denormal numbers take longer to process is a natural consequence
> of hardware registers, which are designed for the normalized format.  Thus
> a lot of pre-processing for each denormal number is required.

Pre-processing to convert to an internal FP format which like the extended format 
has a larger exponent range, and no hidden first bit, can be done on load and 
store.

This assumes, however, dedicated FP registers that may not be accessed as raw 
bits - some RISC architectures store both integers and FP in the same 
registers, and thus have to keep the FP numbers in them in external format.

John Savard

[toc] | [prev] | [next] | [standalone]

#511687

On Thu, 06 Aug 2015 15:18:58 -0700, Quadibloc wrote:

> 
> This assumes, however, dedicated FP registers that may not be accessed as raw 
> bits ...
>

Well, one is always free to implement custom FP arithmetic in software.
In C, for example, one could replace libm.

In fact, due to the Intel transcendental fiasco, hardware trig functions
are no longer used due to cases of extreme inaccuracy.  Trig functions
are now computed in software.

This is one case where precision is important.  To compute accurate
sine, cosine, etc. data reduction must be done to bring all values
into the range of +/- pi/4.  Intel actually made a serious error by
not using enough precision in a value stored in hardware.  The
algorithm led to catastrophic cancellation for certain arguments
and consequent extreme error in the final result.

Every Intel processor ever made, and there are hundreds of millions
of them in the world, is FUBAR with respect to the trig functions. 

So I should amend my original statement by saying that data reduction
is no longer done in hardware,  But once the data is reduced, then
the hardware trig function is applied.

This is why I emphasize that an understanding of the algorithm is
most important.

[toc] | [prev] | [next] | [standalone]

#511751

yeah, 03.1/0.25 ... I mean, 3.1/4

> Every Intel processor ever made, and there are hundreds of millions
> of them in the world, is FUBAR with respect to the trig functions. 
> 
> So I should amend my original statement by saying that data reduction
> is no longer done in hardware,  But once the data is reduced, then
> the hardware trig function is applied.
> 
> This is why I emphasize that an understanding of the algorithm is
> most important.

[toc] | [prev] | [next] | [standalone]

#511767

On Thursday, August 6, 2015 at 7:12:29 PM UTC-6, Fabian Russell wrote:
 
> Well, one is always free to implement custom FP arithmetic in software.

That doesn't count if one is concerned about efficiency and performance. I am 
talking about the fact that it is not necessary to implement the hardware in such 
a way that denormalized numbers take extra time.

John Savard

[toc] | [prev] | [next] | [standalone]

#511825

"Fabian Russell" <root@localhost.localdomain> the Fagie
who also posts as <whataguy@zen.info> the criminal swine 
"Bo Dai", which is an acronym for "Brainless Old Dreck And
Imbecile" and whose real name is Bodaiski, a US Jew, aka 
"Joe Genteel" <root@localhost.localdomain> aka 
Frank, the Crank Colessi, which means in Sicilian Slang 
"Little Asshole" , etc, under a "new nym -- but same old idiot", 
who got fired over his loud-mouthing and his total lack of 
productivity, is still unemployed & on welfare... etc, etc...
> 
< snip kike Fagie's & John Savard Quadibloc's bantering> 
> 
Fagie Bodaiski wrote:
> > So I should amend my original statement 
> 
hanson wrote:
IOW Fagie, you don't know what you are talking about. Pity.

Fagie Bodaiski wrote:
> This is why I emphasize that...  
>
hanson wrote
Fagie Bodaiski,listen "This is why I emphasize that" this
is what got you fired. Any new job prospects yet?
Thanks for the laughs though... ahahahahahanson

[toc] | [prev] | [next] | [standalone]

#511340

On Wednesday, August 5, 2015 at 1:43:24 PM UTC+10, Quadibloc wrote:
> 
> Also, there is a lot of historical evidence - from scientific pocket 
> calculators going all the way back to logarithm tables - that ten digits was 
> viewed as the appropriate precision to reach for when high accuracy was needed.
> 
> This would mesh well with a 48-bit floating point format, which can give eleven 
> digits of precision.

Assuming you start with 11 digits of precision, how many correct digits are you left with after calculating a derivative numerically?

If you're going to do that kind of thing, better to start with double precision, and have those extra digits available to lose.

> Are there sources of informatiion on how much precision is needed for various 
> types of scientific computation?

Practical experience says that, most of the time, double precision is enough. Can lose half the precision, and still have an accurate result. Can lose half the precision twice, and still have an adequate result.

I like a correct digit or two more than the experimental results I'll be comparing my calculations to. I won't complain about more correct digits than that, but that's enough.

[toc] | [prev] | [next] | [standalone]

#511347

On 08/05/2015 01:47 PM, Timo wrote:
> On Wednesday, August 5, 2015 at 1:43:24 PM UTC+10, Quadibloc wrote:
>>
>> Also, there is a lot of historical evidence - from scientific pocket 
>> calculators going all the way back to logarithm tables - that ten digits was 
>> viewed as the appropriate precision to reach for when high accuracy was needed.
>>
>> This would mesh well with a 48-bit floating point format, which can give eleven 
>> digits of precision.
> 
> Assuming you start with 11 digits of precision, how many correct digits are you left with after calculating a derivative numerically?
> 
> If you're going to do that kind of thing, better to start with double precision, and have those extra digits available to lose.
> 
>> Are there sources of informatiion on how much precision is needed for various 
>> types of scientific computation?
> 
> Practical experience says that, most of the time, double precision is enough. Can lose half the precision, and still have an accurate result. Can lose half the precision twice, and still have an adequate result.
> 
> I like a correct digit or two more than the experimental results I'll be comparing my calculations to. I won't complain about more correct digits than that, but that's enough.
> 
Physics itself IMHO usually need not high precission,
but underlying numeracal math procedures often do.

Especially  if many iterations with error propagation are involved,
like  numerical solution of differencial equations
with particular border/initial conditions.

Also if math nature of the equation is being dynamically unstable,
like Richardson's partial differential equation for athmosphere
evolvement, or equations describing fluid turbulence.

-- 
Poutnik ( the Czech word for a wanderer )

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | sci.physics

csiph-web