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

Groups > sci.physics > #532129 > unrolled thread

Floating Point Test Suite

Back to article view | Back to sci.physics

Contents

  Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 18:01 +0000
    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 18:09 +0000
    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 19:58 +0000
      Re: Floating Point Test Suite Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-11-11 15:19 -0500
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 20:28 +0000
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 20:37 +0000
          Re: Floating Point Test Suite Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-11-11 16:33 -0500
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 21:13 +0000
          Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 15:16 -0600
            Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 21:42 +0000
            Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 21:54 +0000
              Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 16:43 -0600
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 23:15 +0000
                  Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 17:34 -0600
                  Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 17:37 -0600
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 23:47 +0000
                      Re: Floating Point Test Suite dvus <dven1@adelphia.net> - 2015-11-12 07:56 -0500
                        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 19:07 +0000
                          Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-12 19:57 -0600
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 00:45 +0000
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 04:55 +0000
                      Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-12 09:26 -0600
                        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 20:56 +0000
                          Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-12 20:00 -0600
              Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 16:48 -0600
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-11 23:08 +0000
                  Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 17:12 -0600
              Re: Floating Point Test Suite Odd Bodkin <bodkinodd@gmail.com> - 2015-11-11 17:06 -0600
              Re: Floating Point Test Suite dvus <dven1@adelphia.net> - 2015-11-12 07:35 -0500
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 19:29 +0000
      Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-11 21:33 -0600
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 04:47 +0000
          Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-12 20:19 -0600
            Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 03:28 +0000
              Re: Floating Point Test Suite Big Fish in a Small Crotch <bigfishinasmallcrotch@myself.com> - 2015-11-12 22:40 -0500
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 03:59 +0000
                  Re: Floating Point Test Suite benj <none@gmail.com> - 2015-11-13 00:16 -0500
                  Re: Floating Point Test Suite GreyCloud <cumulus@mist.com> - 2015-11-13 15:00 -0700
              Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-13 01:40 -0600
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 08:22 +0000
                  Re: Floating Point Test Suite benj <none@gmail.com> - 2015-11-13 12:41 -0500
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 19:16 +0000
                      Re: Floating Point Test Suite Apollyon <adravirgo@gmail.com> - 2015-11-13 13:04 -0800
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 22:58 +0000
                  Re: Floating Point Test Suite Big Fish in a Small Crotch <bigfishinasmallcrotch@myself.com> - 2015-11-14 18:08 -0500
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 23:39 +0000
                  Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-14 18:26 -0800
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-15 07:07 +0000
                      Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-14 23:42 -0800
                        Re: Floating Point Test Suite Poutnik <poutnik4nntp@gmail.com> - 2015-11-15 09:49 +0100
                        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-15 21:01 +0000
                          Re: Floating Point Test Suite jimp@specsol.spam.sux.com - 2015-11-15 21:33 +0000
                          Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-15 14:24 -0800
                            Re: Floating Point Test Suite jimp@specsol.spam.sux.com - 2015-11-15 22:55 +0000
                        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-15 22:25 +0000
                          Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-15 14:59 -0800
                      Re: Floating Point Test Suite Poutnik <poutnik4nntp@gmail.com> - 2015-11-15 09:41 +0100
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-12 06:24 +0000
          Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-12 20:29 -0600
            Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 03:49 +0000
              Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-12 22:49 -0600
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 04:59 +0000
                  Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-13 01:56 -0600
                    Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 08:28 +0000
                      Re: Floating Point Test Suite Monkey Man <manm0nk3y@gmail.com> - 2015-11-13 22:24 -0600
                        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 04:45 +0000
            Re: June 1986 ? ! Fabian Russell <root@localhost.localdomain> - 2015-11-13 06:19 +0000
              Re: June 1986 ? ! GreyCloud <cumulus@mist.com> - 2015-11-13 15:03 -0700
        Re: MonkeyMan is FabianRussell. Fabian Russell <root@localhost.localdomain> - 2015-11-12 19:44 +0000
      Re: Floating Point Test Suite Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2015-11-13 01:59 -0500
        Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-13 07:43 +0000
          Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-13 15:11 -0800
            Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 00:00 +0000
              Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-13 16:31 -0800
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 02:26 +0000
                  Re: Floating Point Test Suite jimp@specsol.spam.sux.com - 2015-11-14 03:52 +0000
                Re: Floating Point Test Suite Fabian Russell <root@localhost.localdomain> - 2015-11-14 02:46 +0000
                  Re: Floating Point Test Suite Timo <timo@physics.uq.edu.au> - 2015-11-13 19:26 -0800
                    Re: Floating Point Test Suite benj <none@gmail.com> - 2015-11-14 02:11 -0500
                Re: Floating Point Test Suite noTthaTguY <abu.kuanysh05@gmail.com> - 2015-11-14 15:20 -0800
              Re: Floating Point Test Suite jimp@specsol.spam.sux.com - 2015-11-14 00:47 +0000
    Re: Floating Point Test Suite Big Fish in a Small Crotch <bigfishinasmallcrotch@myself.com> - 2015-11-11 15:28 -0500

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#532768

On 11/13/2015 03:22 AM, Fabian Russell wrote:
> On Fri, 13 Nov 2015 01:40:50 -0600, Monkey Man wrote:
>
>>>>
>>> Check the Intel hardware manuals:
>>>
>>> http://www.intel.com/content/www/us/en/processors/architectures-
>> software-developer-manuals.html
>>>
>>
>> You know? I think I may have those already.
>> Some really smart people working really hard problems.
>>
>
> LOL!  Those manuals are a trip.  It seems that processor design is
> a task for superhumans.
>
> But I imagine that there are lots of people involved in the effort.

But, Fabio, I doubt that any of those "lots of people" really comprehend 
the entire process that goes into building a modern processor. In fact, 
I'd bet that only a couple of "superhumans" do. There are probably only 
a handful of humans on the entire planet that could recreate a modern 
processor if all the current records were wiped. Or conversely a 
terrorist need only take out a handful of specialists to bring human 
civilization back to the dark ages. That is the thread that technology 
has us all hanging by.

-- 

       ___           ___           ___            ___
      /\  \         /\  \         /\__\          /\  \
     /::\  \       /::\  \       /::|  |         \:\  \
    /:/\:\  \     /:/\:\  \     /:|:|  |     ___ /::\__\
   /::\~\:\__\   /::\~\:\  \   /:/|:|  |__  /\  /:/\/__/
  /:/\:\ \:|__| /:/\:\ \:\__\ /:/ |:| /\__\ \:\/:/  /
  \:\~\:\/:/  / \:\~\:\ \/__/ \/__|:|/:/  /  \::/  /
   \:\ \::/  /   \:\ \:\__\       |:/:/  /    \/__/
    \:\/:/  /     \:\ \/__/       |::/  /
     \::/__/       \:\__\         /:/  /
      ~~            \/__/         \/__/

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

#532793

On Fri, 13 Nov 2015 12:41:53 -0500, benj wrote:


> There are probably only 
> a handful of humans on the entire planet that could recreate a modern 
> processor if all the current records were wiped. Or conversely a 
> terrorist need only take out a handful of specialists to bring human 
> civilization back to the dark ages.
>

That would make a good Hollywood movie plot.

A group of eccentric survivalists are hording microproceesors
and associated chips, and when Armaggedon finally arrives,
it is they would hold the ultimate power.

They are approached by people with gifts of gold, diamonds,
and oil to exchange for the precious chips, but they must
also fight off the evil warlords from foreign lands.

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

#532818

On Friday, November 13, 2015 at 1:16:50 PM UTC-6, Fabian Russell wrote:
> On Fri, 13 Nov 2015 12:41:53 -0500, benj wrote:
> 
> 
> > There are probably only 
> > a handful of humans on the entire planet that could recreate a modern 
> > processor if all the current records were wiped. Or conversely a 
> > terrorist need only take out a handful of specialists to bring human 
> > civilization back to the dark ages.
> >
> 
> That would make a good Hollywood movie plot.
> 
> A group of eccentric survivalists are hording microproceesors
> and associated chips, and when Armaggedon finally arrives,
> it is they would hold the ultimate power.
> 

Live Free Or Die.
 Close. Microprocessors are key (as are Dragons Tears)
http://www.baenebooks.com/p-1108-live-free-or-die.aspx
> They are approached by people with gifts of gold, diamonds,
> and oil to exchange for the precious chips, but they must
> also fight off the evil warlords from foreign lands.

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

#533147

On Fri, 13 Nov 2015 01:40:50 -0600, Monkey Man wrote:

> 
> Any thoughts around what that type of precision would be used for? 
> Perhaps some type/branch of physics or mathematics maybe?
> 

I just discovered a book that has been right under my nose for
some time already.  It is "Handbook of Floating Point Arithmetic"
by Jean-Michel Muller, et.al.

On page 28:

"With regard to accuracy, the most accurate current physical measurements
allow one to check some predictions of quantum mechanics or general
relativity with a relative accuracy close to 1e-15. This of
course means that in some cases, we must be able to represent numerical
data with a similar accuracy (which is easily done, using formats that
are implemented on almost all current platforms). But this also means
that we might sometimes be able to carry out computations that must end
up with a relative error less than or equal to 1e-15, which is
much more difficult. Sometimes, one will need a
significantly larger floating-point format or smart
tricks such as those presented in Chapter 4."

What are folks in QED doing?  I hear that the electron parameters are
known to a VERY large number of decimal places.  Quad (128-bit) precision
may be useful in QED which deals with constants to very high accuracy.

Maybe some of the sci.physics "experts" can further comment on this
need for ultra-high precision.

But I wouldn't hold my breath.  LOL!

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

#533150

On 14 Nov 2015 22:58:12 GMT, Fabian Russell wrote:

> On Fri, 13 Nov 2015 01:40:50 -0600, Monkey Man wrote:
> 
>> 
>> Any thoughts around what that type of precision would be used for? 
>> Perhaps some type/branch of physics or mathematics maybe?
>> 
> 
> I just discovered a book that has been right under my nose for
> some time already.  It is "Handbook of Floating Point Arithmetic"
> by Jean-Michel Muller, et.al.
> 
> On page 28:
> 
> "With regard to accuracy, the most accurate current physical measurements
> allow one to check some predictions of quantum mechanics or general
> relativity with a relative accuracy close to 1e-15. This of
> course means that in some cases, we must be able to represent numerical
> data with a similar accuracy (which is easily done, using formats that
> are implemented on almost all current platforms). But this also means
> that we might sometimes be able to carry out computations that must end
> up with a relative error less than or equal to 1e-15, which is
> much more difficult. Sometimes, one will need a
> significantly larger floating-point format or smart
> tricks such as those presented in Chapter 4."
> 
> What are folks in QED doing?  I hear that the electron parameters are
> known to a VERY large number of decimal places.  Quad (128-bit) precision
> may be useful in QED which deals with constants to very high accuracy.
> 
> Maybe some of the sci.physics "experts" can further comment on this
> need for ultra-high precision.
> 
> But I wouldn't hold my breath.  LOL!

You probably should have read the book before you were fired from your job.

-- 
You Ain't The Biggest Fish In The Crotch.

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

#533164

On Sat, 14 Nov 2015 18:08:41 -0500, Big Fish in a Small Crotch wrote:

> 
> You probably should have read the book before you were
> fired from your job.
>

Fired?  Ha, ha, ha, ha, ha, ha, ha!

After I walked out, a manager From Hewlett-Packard called me
the next day and practically begged me to return.

I should give you the guy's name so that he could verify,
but I have an undying respect for the principle of confidentiality.

I cannot be blamed for the abysmal intellectual decrepitude of
my fellow man.

Ha, ha, ha, ha, ha, ha!

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

#533189

On Sunday, November 15, 2015 at 8:59:37 AM UTC+10, Fabian Russell wrote:
> On Fri, 13 Nov 2015 01:40:50 -0600, Monkey Man wrote:
> > 
> > Any thoughts around what that type of precision would be used for? 
> > Perhaps some type/branch of physics or mathematics maybe?
[...]
> Maybe some of the sci.physics "experts" can further comment on this
> need for ultra-high precision.

The main use for higher-than-double precision in computational physics is to push algorithms that suffer severely from growth of errors a little bit further. A common example is badly conditioned linear systems. If you want to solve a linear system with condition number 1e20, there isn't much point in using double precision. Quadruple precision will work. Another common example is special functions calculated using series that almost cancel. Going to higher precision lets you calculate the functions to higher order and/or argument.

In these cases, the final required accuracy isn't usually very high, but starting with double precision will leave you with 0 correct digits. Not good. Either give up, use another algorithm, or use higher precision.

If you are comparing two theories, with result A predicted by theory 1, and result B predicted by theory 2, and |A-B|/A<1e-15, it's usually better to directly calculate (A-B), rather than calculating A, calculating B, and finding the difference.

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

#533226

On Sat, 14 Nov 2015 18:26:28 -0800, Timo wrote:

> 
> The main use for higher-than-double precision in computational physics
> is to push algorithms that suffer severely from growth of errors a
> little bit further.
>

I had no idea that "brute force" was still necessary.

I thought that numerical analysts had developed enough "tricky"
techniques to satisfy all cases.

But I can understand the problem with ill-conditioned matrices.

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

#533233

On Sunday, November 15, 2015 at 5:08:00 PM UTC+10, Fabian Russell wrote:
> On Sat, 14 Nov 2015 18:26:28 -0800, Timo wrote:
> 
> > The main use for higher-than-double precision in computational physics
> > is to push algorithms that suffer severely from growth of errors a
> > little bit further.
> 
> I had no idea that "brute force" was still necessary.
> 
> I thought that numerical analysts had developed enough "tricky"
> techniques to satisfy all cases.
> 
> But I can understand the problem with ill-conditioned matrices.

So, you're loudly bleating about what is required for computational physics, essential for computational physics, and important for computational physics. Despite having apparently no real experience in computational physics (or even numerical methods), you've been insisting that you are *right*, and your opinion, even in the absence of evidence, trumps that of people who've been working in the field. Wonderful!

Numerical methods are still dominated by the same old tripod: numerical calculus, linear algebra, and Monte Carlo. What tricks are there that will save you from step-size error, round-off error, and statistical error? Take a common task: solving IVPs. The standard methods date back to c. 1900 (RK). The old-timers put a lot of effort into getting the most bang for their buck, since their flops were expensive. Paper-and-pencil expensive. We moderns are spoiled by cheap computational power.

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

#533238

Dne 15/11/2015 v 08:42 Timo napsal(a):

> .........Take a common task: solving IVPs. The standard methods date back to c. 1900 (RK). 

I suppose you mean Initial value problem
and Runge-Kutta numerical methods.

https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods
http://mathworld.wolfram.com/Runge-KuttaMethod.html

I remember myself programming the calculations
on programmable calculators and 8bit computers in 80s/90s.

-- 
Poutnik ( the Czech word for a wanderer )

Knowledge makes great men humble, but small men arrogant.

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

#533357

On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:

> 
> Numerical methods are still dominated by the same old tripod: numerical calculus,
> linear algebra, and Monte Carlo. 
>

And mathematics still continues to be hailed as "the queen of the sciences"
when in reality it is a crock of impotence and ineffectiveness.

To compute an integral I can cut out with scissors a drawing of the region
in question and weigh it a scale thereby arriving at an answer faster than
the world's greatest supercomputer.

There have been some theoretical breakthroughs over the past hundred
years that have revolutionized some methods, but off the top of my
head I can't recall what they were.  But progress will always remain
very slow in a field that is innately crippled to begin with.

Analog computers, if perfected, could perhaps make the paper-scissors
method a standard.

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

#533370

Fabian Russell <root@localhost.localdomain> wrote:
> On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:
> 
>> 
>> Numerical methods are still dominated by the same old tripod: numerical calculus,
>> linear algebra, and Monte Carlo. 
>>
> 
> And mathematics still continues to be hailed as "the queen of the sciences"
> when in reality it is a crock of impotence and ineffectiveness.
> 
> To compute an integral I can cut out with scissors a drawing of the region
> in question and weigh it a scale thereby arriving at an answer faster than
> the world's greatest supercomputer.
> 
> There have been some theoretical breakthroughs over the past hundred
> years that have revolutionized some methods, but off the top of my
> head I can't recall what they were.  But progress will always remain
> very slow in a field that is innately crippled to begin with.
> 
> Analog computers, if perfected, could perhaps make the paper-scissors
> method a standard.

Analog computers were perfected many, many decades ago and are just
wonderfull for a single, complex system of differential equations,
such as was done by the Nike-Hercules fire control computer designed
in the 1950's, but are not so handy as a general purpose computer.

As a die hard time waster, you would have loved spending hours setting
up the plug board and then setting all the pots on an analog computer.

 

-- 
Jim Pennino

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

#533382

On Monday, November 16, 2015 at 7:03:12 AM UTC+10, Fabian Russell wrote:
> On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:
> 
> > Numerical methods are still dominated by the same old tripod: numerical calculus,
> > linear algebra, and Monte Carlo. 
> 
> And mathematics still continues to be hailed as "the queen of the sciences"
> when in reality it is a crock of impotence and ineffectiveness.
> 
> To compute an integral I can cut out with scissors a drawing of the region
> in question and weigh it a scale thereby arriving at an answer faster than
> the world's greatest supercomputer.

"Chemist's integration". A good idea when the data were never digital; beats counting squares under the curve by hand, if you have a milligram balance. But you won't beat the world's greatest supercomputer. Try it, and time yourself. You wouldn't even beat a PDP-11.

> There have been some theoretical breakthroughs over the past hundred
> years that have revolutionized some methods, but off the top of my
> head I can't recall what they were.  But progress will always remain
> very slow in a field that is innately crippled to begin with.

FFT, and a whole bunch of Monte Carlo algorithms that were impractical in the paper and pencil and adding machine days.

> Analog computers, if perfected, could perhaps make the paper-scissors
> method a standard.

"If perfected"? What are you suggesting needs to be/can be done to improve existing and past analog computers?

Why do you think those improvements would be enough to make analog computers the standard tool again? Digital computers much less capable than what we have today replaced analog computers as the standard numerical tool long ago; your improved analog computers would need to be *much* better than current ones.

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

#533396

Timo <timo@physics.uq.edu.au> wrote:
> On Monday, November 16, 2015 at 7:03:12 AM UTC+10, Fabian Russell wrote:
>> On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:
>> 
>> > Numerical methods are still dominated by the same old tripod: numerical calculus,
>> > linear algebra, and Monte Carlo. 
>> 
>> And mathematics still continues to be hailed as "the queen of the sciences"
>> when in reality it is a crock of impotence and ineffectiveness.
>> 
>> To compute an integral I can cut out with scissors a drawing of the region
>> in question and weigh it a scale thereby arriving at an answer faster than
>> the world's greatest supercomputer.
> 
> "Chemist's integration". A good idea when the data were never digital; beats counting squares under the curve by hand, if you have a milligram balance. But you won't beat the world's greatest supercomputer. Try it, and time yourself. You wouldn't even beat a PDP-11.
> 
>> There have been some theoretical breakthroughs over the past hundred
>> years that have revolutionized some methods, but off the top of my
>> head I can't recall what they were.  But progress will always remain
>> very slow in a field that is innately crippled to begin with.
> 
> FFT, and a whole bunch of Monte Carlo algorithms that were impractical in the paper and pencil and adding machine days.
> 
>> Analog computers, if perfected, could perhaps make the paper-scissors
>> method a standard.
> 
> "If perfected"? What are you suggesting needs to be/can be done to improve existing and past analog computers?
> 
> Why do you think those improvements would be enough to make analog computers the standard tool again? Digital computers much less capable than what we have today replaced analog computers as the standard numerical tool long ago; your improved analog computers would need to be *much* better than current ones.

The only "problem" with analog computers was the tube based operational
amplifiers required a LOT of circuitry to eliminate drift. Modern,
stabilized integrated opamps do not have that issue, which solved
that problem decades ago.

Finding precision multiturn potentiometers was somewhat of an issue
up until the late 70's when laser trimmed film potentiometers became
common off the shelf items.

The pen on the chart recorder, which always seemed to run out of ink
in the middle of a solution, is eliminated by an A to D  converter and
a PC.



-- 
Jim Pennino

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

#533383

On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:

> 
> What tricks are there that will save you from step-size error, round-off error,
> and statistical error?
>

I refer to the iterative methods for solving linear systems.

Non one would use Cramer's Rule or even Gaussian elimination with
full pivoting to solve a vast linear system.  The round-off error
would be too great.

Consequently, iterative methods have been developed such as the
Gauss-Seidel method.  This is what I meant by "tricks."

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

#533395

On Monday, November 16, 2015 at 8:26:34 AM UTC+10, Fabian Russell wrote:
> On Sat, 14 Nov 2015 23:42:05 -0800, Timo wrote:
> 
> > What tricks are there that will save you from step-size error, round-off error,
> > and statistical error?
> 
> I refer to the iterative methods for solving linear systems.
> 
> Non one would use Cramer's Rule or even Gaussian elimination with
> full pivoting to solve a vast linear system.  The round-off error
> would be too great.
> 
> Consequently, iterative methods have been developed such as the
> Gauss-Seidel method.  This is what I meant by "tricks."

1) Gauss-Seidel was published in 1874. Not a recent trick.

2) Iterative methods for linear systems don't save you from round-off error. Typically, for ill-conditioned systems, they don't converge.

3) Iterative methods let you solve larger linear systems than direct solution. Iterative methods typically scale as O(n^2), compared with O(n^3) for direct solution, for nxn systems.

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

#533237

Dne 15/11/2015 v 08:07 Fabian Russell napsal(a):
> On Sat, 14 Nov 2015 18:26:28 -0800, Timo wrote:
> 
>>
>> The main use for higher-than-double precision in computational physics
>> is to push algorithms that suffer severely from growth of errors a
>> little bit further.
>>
> 
> I had no idea that "brute force" was still necessary.
> 
> I thought that numerical analysts had developed enough "tricky"
> techniques to satisfy all cases.
> 
> But I can understand the problem with ill-conditioned matrices.
> 

Tricks works only for particular conditions, not generally.

Other application of quad precision
may be in iterative computations with progressive cumulation of errors,
like numerical solutions of some differential equations.


-- 
Poutnik ( the Czech word for a wanderer )

Knowledge makes great men humble, but small men arrogant.

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

#532287

On Wed, 11 Nov 2015 21:33:03 -0600, Monkey Man wrote:

> 
> I've included the results in this post if you care to have a look. I'd be 
> happy to learn about what this is telling me if you wouldn't mind 
> breaking it down a bit for me.
> 

Hello M.M.,

Well, I find something interesting with your results.  At first, I didn't
expect anything wrong.  The PARANOIA error was unusual but, not knowing
the exact nature of the error, I didn't consider it too serious.

But on closer inspection I found something that I never saw before
or expected.  It is here:

> 
> 
> 1. One-shot test of multiplication & division: failed for A = 1717.000000.
> 

You have a one-shot test failure for a particular value.  This indicates
that rounding is not being performed correctly according to IEEE754.
On a modern Linux system this would be very strange.

It COULD be related to the PARANOIA failure/defect, but I don't know.

Please post the files cdiv_DP.output, cmul_DP.output, and cpar_DP.output.
I would appreciate it.

If you want, you could delete all files in ucbtest-results and run
the test again to see if the same thing happens.

Thanks.

 

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

#532614

Hi Fabian,

On Thu, 12 Nov 2015 06:24:03 +0000, Fabian Russell wrote:
>
> Hello M.M.,
> 
> Well, I find something interesting with your results.  At first, I
> didn't expect anything wrong.  The PARANOIA error was unusual but, not
> knowing the exact nature of the error, I didn't consider it too serious.
> 
> But on closer inspection I found something that I never saw before or
> expected.  It is here:
> 
> 
>> 
>> 1. One-shot test of multiplication & division: failed for A =
>> 1717.000000.
>> 
>> 
> You have a one-shot test failure for a particular value.  This indicates
> that rounding is not being performed correctly according to IEEE754.
> On a modern Linux system this would be very strange.

Huh, totally missed that when looking through the log file. Ugh that 
thing is difficult to visually parse :/ Good eye.

> 
> It COULD be related to the PARANOIA failure/defect, but I don't know.

It's funny you should mention that because the paranoia suite did catch 
something about a rounding/chopping failure. I included the snippet for 
the paranoia test failure in your first reply.

> 
> Please post the files cdiv_DP.output, cmul_DP.output, and
> cpar_DP.output.
> I would appreciate it.

You got it; the contents can be found below:

8< cdiv_DP.output --------------------------------------------------------
 ucbtest START   in ../ucbtest/div.c at line 324 for double 
 1000000 tests on 1 regions with 53 significant bits 

Number of significant bits : m = 53 ...

Number of failures (out of 1693289 cases) = 0
 ucbtest UCBPASS in ../ucbtest/div.c at line 447 for double 
/usr/bin/time
>8 -----------------------------------------------------------------------

8< cmul_DP.output --------------------------------------------------------
 ucbtest START   in ../ucbtest/mul.c at line 593 for double 
 1000000 tests on 1 regions with 53 significant bits 


1. One-shot test of multiplication & division: failed for A = 1717.000000.

2. Halfway cases, 1000000 cases tested:

  a. Passed consistency tests for halfway cases.

  b. Passed correctness tests for halfway cases.


3. Nearly halfway cases, 1000000 cases tested:

  a. Passed consistency tests for nearly halfway cases.

  b. Passed correctness tests for nearly halfway cases. 

 ucbtest UCBPASS in ../ucbtest/mul.c at line 612 for double 
/usr/bin/time
>8 -----------------------------------------------------------------------

8< cpar_DP.output --------------------------------------------------------
 ucbtest START   in ../ucbctest/par.c at line 339 for double 
 1000000 tests on 1 regions with 53 significant bits 
Lest this program stop prematurely, i.e. before displaying

    `END OF TEST',

try to persuade the computer NOT to terminate execution when an
error like Over/Underflow or Division by Zero occurs, but rather
to persevere with a surrogate value after, perhaps, displaying some
warning.  If persuasion avails naught, don't despair but run this
program anyway to see how many milestones it passes, and then
amend it to make further progress.

Answer questions with Y, y, N or n (unless otherwise indicated).


Diagnosis resumes after milestone Number 0          Page: 1

Users are invited to help debug and augment this program so it will
cope with unanticipated and newly uncovered arithmetic pathologies.

Please send suggestions and interesting results to
	Richard Karpinski
	Computer Center U-76
	University of California
	San Francisco, CA 94143-0704, USA

In doing so, please include the following information:
	Precision:	double;
	Version:	9 June 1986;
	Computer:

	Compiler:

	Optimization level:

	Other relevant compiler options:

Diagnosis resumes after milestone Number 1          Page: 2

Running this program should reveal these characteristics:
     Radix = 1, 2, 4, 8, 10, 16, 100, 256 ...
     Precision = number of significant digits carried.
     U2 = Radix/Radix^Precision = One Ulp
	(OneUlpnit in the Last Place) of 1.000xxx .
     U1 = 1/Radix^Precision = One Ulp of numbers a little less than 1.0 .
     Adequacy of guard digits for Mult., Div. and Subt.
     Whether arithmetic is chopped, correctly rounded, or something else
	for Mult., Div., Add/Subt. and Sqrt.
     Whether a Sticky Bit used correctly for rounding.
     UnderflowThreshold = an underflow threshold.
     E0 and PseudoZero tell whether underflow is abrupt, gradual, or 
fuzzy.
     V = an overflow threshold, roughly.
     V0  tells, roughly, whether  Infinity  is represented.
     Comparisions are checked for consistency with subtraction
	and for contamination with pseudo-zeros.
     Sqrt is tested.  Y^X is not tested.
     Extra-precise subexpressions are revealed but NOT YET tested.
     Decimal-Binary conversion is NOT YET tested for accuracy.

Diagnosis resumes after milestone Number 2          Page: 3

The program attempts to discriminate among
   FLAWs, like lack of a sticky bit,
   Serious DEFECTs, like lack of a guard digit, and
   FAILUREs, like 2+2 == 5 .
Failures may confound subsequent diagnoses.

The diagnostic capabilities of this program go beyond an earlier
program called `MACHAR', which can be found at the end of the
book  `Software Manual for the Elementary Functions' (1980) by
W. J. Cody and W. Waite. Although both programs try to discover
the Radix, Precision and range (over/underflow thresholds)
of the arithmetic, this program tries to cope with a wider variety
of pathologies, and to say how well the arithmetic is implemented.

The program is based upon a conventional radix representation for
floating-point numbers, but also allows logarithmic encoding
as used by certain early WANG machines.

BASIC version of this program (C) 1983 by Prof. W. M. Kahan;
see source comments for more history.

Diagnosis resumes after milestone Number 3          Page: 4

Program is now RUNNING tests on small integers:
-1, 0, 1/2, 1, 2, 3, 4, 5, 9, 27, 32 & 240 are O.K.

Searching for Radix and Precision.
Radix = 2.000000 .
Closest relative separation found is U1 = 1.1102230e-16 .

Recalculating radix and precision.confirms closest relative separation 
U1 .
Radix confirmed.
The number of significant digits of the Radix is 53.000000 .

Diagnosis resumes after milestone Number 30          Page: 5

Subtraction appears to be normalized, as it should be.
Checking for guard digit in *, /, and -.
     *, /, and - appear to have guard digits, as they should.

Diagnosis resumes after milestone Number 40          Page: 6

Checking rounding on multiply, divide and add/subtract.
* is neither chopped nor correctly rounded.
Division appears to round correctly.
Addition/Subtraction appears to round correctly.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

Does Multiplication commute?  Testing on 20 random pairs.
     No failures found in 20 integer pairs.

Running test of square root(x).
Testing if sqrt(X * X) == X for 20 Integers X.
Test for sqrt monotonicity.
sqrt has passed a test for Monotonicity.
Testing whether sqrt is rounded or chopped.
Square root appears to be correctly rounded.

Diagnosis resumes after milestone Number 90          Page: 7

Testing powers Z^i for small Integers Z and i.
... no discrepancies found.

Seeking Underflow thresholds UfThold and E0.
Smallest strictly positive number found is E0 = 4.94066e-324 .
Since comparison denies Z = 0, evaluating (Z + Z) / Z should be safe.
What the machine gets for (Z + Z) / Z is  2.00000000000000000e+00 .
This is O.K., provided Over/Underflow has NOT just been signaled.
Underflow is gradual; it incurs Absolute Error =
(roundoff in UfThold) < E0.
 test double rounding in gradual underflow E0 4.94066e-324 y4-E0 0 y 
6.77626e-21 1.01644e-20 1.37153e+303 4.94066e-324 
The Underflow threshold is 2.22507385850720188e-308,  below which
calculation may suffer larger Relative error than merely roundoff.
Since underflow occurs below the threshold
UfThold = (2.00000000000000000e+00) ^ (-1.02200000000000000e+03)
only underflow should afflict the expression
	(2.00000000000000000e+00) ^ (-1.02200000000000000e+03);
actually calculating yields: 0.00000000000000000e+00 .
This computed value is O.K.

Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as X -
> 1.
Accuracy seems adequate.
Testing powers Z^Q at four nearly extreme values.
 ... no discrepancies found.


Diagnosis resumes after milestone Number 160          Page: 8

Searching for Overflow threshold:
This may generate an error.
Can `Z = -Y' overflow?
Trying it on Y = -inf .
Seems O.K.
Overflow threshold is V  = 1.79769313486231571e+308 .
Overflow saturates at V0 = inf .
No Overflow should be signaled for V * 1 = 1.79769313486231571e+308
                           nor for V / 1 = 1.79769313486231571e+308 .
Any overflow signal separating this * from the one
above is a DEFECT.


Diagnosis resumes after milestone Number 190          Page: 9


What message and/or values does Division by Zero produce?
    Trying to compute 1 / 0 produces ...  inf .

    Trying to compute 0 / 0 produces ...  -nan .

Diagnosis resumes after milestone Number 220          Page: 10


The number of  FLAWs  discovered =           1.

The arithmetic diagnosed seems satisfactory though flawed.
END OF TEST.
 ucbtest UCBFAIL in ../ucbctest/par.c at line 2035 for double 
Command exited with non-zero status 42
/usr/bin/time
>8 -----------------------------------------------------------------------

> 
> If you want, you could delete all files in ucbtest-results and run the
> test again to see if the same thing happens.

Sure thing, I'll do that and then diff against the results I have now. 
I'll report back on what is produced.

> 
> Thanks.

Thanks Fabian,

Monkey Man

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

#532636

> 
> Checking rounding on multiply, divide and add/subtract.
> * is neither chopped nor correctly rounded.
> Division appears to round correctly.
> Addition/Subtraction appears to round correctly.
> Sticky bit used incorrectly or not at all.
> FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
> (noted above) count as one flaw in the final tally below.
> 

It seems that multiplication does not meet ideal rounding.

This is a FLAW, which that computations are correct but rounding
is not ideal.

I don't know what could be causing this.

What processor do you have?

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | sci.physics

csiph-web