Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.physics > #532129 > unrolled thread
| Started by | Fabian Russell <root@localhost.localdomain> |
|---|---|
| First post | 2015-11-11 18:01 +0000 |
| Last post | 2015-11-11 15:28 -0500 |
| Articles | 20 on this page of 82 — 14 participants |
Back to article view | Back to sci.physics
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-12 04:55 +0000 |
| Message-ID | <pan.2015.11.12.04.55.45@localhost.localdomain> |
| In reply to | #532223 |
On Wed, 11 Nov 2015 17:37:00 -0600, Odd Bodkin wrote: > On 11/11/2015 5:15 PM, Fabian Russell wrote: >> Anytime a discussion rears its head Oddball spews forth his >> psychological neologisms. > > By the way, when you choose to use a word, check what it means first. > Oddball, let me make it clear. I do not like you or what you are attempting to insinuate. You exploit the freedom and openness of this forum to serve your own factitious ends. I consider such tactics to be reprehensible, unconscionable, and inexcusable. You violate trust, Oddball, and thereby you destroy the only mechanism that keeps the spirit of the open Net alive. For that you deserve retribution of the highest order. Unfortunately, I can do nothing, but if I could, be assured that you would not for long continue in your flagrant violations.
[toc] | [prev] | [next] | [standalone]
| From | Odd Bodkin <bodkinodd@gmail.com> |
|---|---|
| Date | 2015-11-12 09:26 -0600 |
| Message-ID | <n22b2l$civ$1@speranza.aioe.org> |
| In reply to | #532282 |
On 11/11/2015 10:55 PM, Fabian Russell wrote: > On Wed, 11 Nov 2015 17:37:00 -0600, Odd Bodkin wrote: > >> On 11/11/2015 5:15 PM, Fabian Russell wrote: >>> Anytime a discussion rears its head Oddball spews forth his >>> psychological neologisms. >> >> By the way, when you choose to use a word, check what it means first. >> > > Oddball, let me make it clear. I do not like you or what you > are attempting to insinuate. And what do you think I'm trying to insinuate? > You exploit the freedom and openness > of this forum to serve your own factitious ends. And what do you think my factitious ends are? > I consider such tactics > to be reprehensible, unconscionable, and inexcusable. And frankly, I don't care what you consider. > > You violate trust, Oddball, and thereby you destroy the only mechanism > that keeps the spirit of the open Net alive. Consider your own behavior, then. > > For that you deserve retribution of the highest order. > > Unfortunately, I can do nothing, but if I could, be assured that > you would not for long continue in your flagrant violations. > Alrighty then, stop complaining about things out of your control. If you don't like the environment, then leave the environment. -- Odd Bodkin --- maker of fine toys, tools, tables
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-12 20:56 +0000 |
| Message-ID | <pan.2015.11.12.20.56.15@localhost.localdomain> |
| In reply to | #532318 |
On Thu, 12 Nov 2015 09:26:14 -0600, Odd Bodkin wrote: > > And frankly, I don't care what you consider. > With that statement, you are attempting to demonstrate to the world that you are not being intimidated. For you, it is a face saving stance. But you will care. You will care very, very much. The only thing that will save the world from its innate stupidity is severe and unbending AUTHORITARIANISM. You and your paltry, noxious brethren had better take cover when that day arrives. Ha, ha, ha, ha, ha, ha! Oddball will lose his Hollywood -- for him a fate worse than a thousand deaths.
[toc] | [prev] | [next] | [standalone]
| From | Odd Bodkin <bodkinodd@gmail.com> |
|---|---|
| Date | 2015-11-12 20:00 -0600 |
| Message-ID | <n23g88$sag$2@speranza.aioe.org> |
| In reply to | #532451 |
On 11/12/2015 2:56 PM, Fabian Russell wrote: > On Thu, 12 Nov 2015 09:26:14 -0600, Odd Bodkin wrote: > >> >> And frankly, I don't care what you consider. >> > > With that statement, you are attempting to demonstrate to the > world that you are not being intimidated. For you, it is a face > saving stance. > > But you will care. You will care very, very much. LOL. > > The only thing that will save the world from its innate stupidity > is severe and unbending AUTHORITARIANISM. Oh my. > > You and your paltry, noxious brethren had better take cover when > that day arrives. Look at that spittle fly. > > Ha, ha, ha, ha, ha, ha! > > Oddball will lose his Hollywood -- for him a fate worse than > a thousand deaths. > > > > -- Odd Bodkin --- maker of fine toys, tools, tables
[toc] | [prev] | [next] | [standalone]
| From | Odd Bodkin <bodkinodd@gmail.com> |
|---|---|
| Date | 2015-11-11 16:48 -0600 |
| Message-ID | <n20gj4$p50$3@speranza.aioe.org> |
| In reply to | #532200 |
On 11/11/2015 3:54 PM, Fabian Russell wrote: > You talking to me? You talking to ME? Unless you have substantive > and relevant ideas to contribute I will > advise you to keep your fscking mouth shut. > > Is that clear? http://www.imdb.com/title/tt0075314/ -- Odd Bodkin --- maker of fine toys, tools, tables
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-11 23:08 +0000 |
| Message-ID | <pan.2015.11.11.23.07.02@localhost.localdomain> |
| In reply to | #532208 |
On Wed, 11 Nov 2015 16:48:07 -0600, Odd Bodkin wrote: > > http://www.imdb.com/title/tt0075314/ > Oddball racks his brains to be able to get in what he thinks is the last word. Don't ponder too hard, Oddball, you'll get a migraine.
[toc] | [prev] | [next] | [standalone]
| From | Odd Bodkin <bodkinodd@gmail.com> |
|---|---|
| Date | 2015-11-11 17:12 -0600 |
| Message-ID | <n20i0v$sqi$1@speranza.aioe.org> |
| In reply to | #532213 |
On 11/11/2015 5:08 PM, Fabian Russell wrote: > On Wed, 11 Nov 2015 16:48:07 -0600, Odd Bodkin wrote: > >> >> http://www.imdb.com/title/tt0075314/ >> > > Oddball racks his brains to be able to get in what he thinks > is the last word. Oh, now, now. I was the one that brought up the last word thing to you earlier. You can't even insult with originality or insight. > > Don't ponder too hard, Oddball, you'll get a migraine. > I'm not the one with the compulsive attention-whoring disorder, remember? Can't help yourself, I know. Makes me want to poke the sore. -- Odd Bodkin --- maker of fine toys, tools, tables
[toc] | [prev] | [next] | [standalone]
| From | Odd Bodkin <bodkinodd@gmail.com> |
|---|---|
| Date | 2015-11-11 17:06 -0600 |
| Message-ID | <n20hl8$rir$1@speranza.aioe.org> |
| In reply to | #532200 |
On 11/11/2015 3:54 PM, Fabian Russell wrote: > Now, you listen and you listen good, you fscking little weasel. > > This is a very important floating point test suite that could be > immensely valuable to physicists and scientists of all persuasions. > I am taking the responsibility to bring it to the attention of all > dedicated professionals. > > Yet you are attempting to cheapen and degrade the discussion with > you inane outbursts. > > Unless you have substantive and relevant ideas to contribute I will > advise you to keep your fscking mouth shut. > > Is that clear? http://caselaw.findlaw.com/ny-supreme-court-appellate-division/1203033.html -- Odd Bodkin --- maker of fine toys, tools, tables
[toc] | [prev] | [next] | [standalone]
| From | dvus <dven1@adelphia.net> |
|---|---|
| Date | 2015-11-12 07:35 -0500 |
| Message-ID | <dajfctFm6rfU1@mid.individual.net> |
| In reply to | #532200 |
On 11/11/2015 4:54 PM, Fabian Russell wrote: > On Wed, 11 Nov 2015 15:16:41 -0600, Odd Bodkin wrote: > >> >> Attention whores be whorin'. >> > > Now, you listen and you listen good, you fscking little weasel. > > This is a very important floating point test suite that could be > immensely valuable to physicists and scientists of all persuasions. > I am taking the responsibility to bring it to the attention of all > dedicated professionals. > > Yet you are attempting to cheapen and degrade the discussion with > you inane outbursts. > > Unless you have substantive and relevant ideas to contribute I will > advise you to keep your fscking mouth shut. Hey, sci.physics now has a (self-appointed) moderator! > Is that clear? [looks over shoulder for sci.physics police] It's clear you forget where you are. -- dvus
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-12 19:29 +0000 |
| Message-ID | <pan.2015.11.12.19.29.21@localhost.localdomain> |
| In reply to | #532300 |
On Thu, 12 Nov 2015 07:35:37 -0500, dvus wrote: > > Hey, sci.physics now has a (self-appointed) moderator! > It is supposed to moderate itself through a system of honor. One day I walked into a small copy and print shop to make some copies of various documents. After I finished, I looked to find a clerk to make payment but there was none. On a table near the door was a small basket with coins and cash and a sign that read "Make your own change." All the store personnel were in the back rooms and had no time for the front desk. Customers were supposed to deposit the correct payment in the basket and make their own change. Here we see the honor system in action. There was a fair amount of cash in the basket and anyone could easily have absconded with all of it. But no one ever did. Note: In other neighborhoods in the region, this honor system would have been broken within seconds. Usenet is the same. It depends entirely on the honor of the participant to adhere to reasonableness and respect. But that "pussy" brained Oddball, and his low-rent compatriots, attempts to exploit this bastion of honor to promulgate his narrow-minded and bigoted "pussy" psychology. His transgressions must be met head-on.
[toc] | [prev] | [next] | [standalone]
| From | Monkey Man <manm0nk3y@gmail.com> |
|---|---|
| Date | 2015-11-11 21:33 -0600 |
| Message-ID | <WJ-dnVQVTK3yldnLnZ2dnUU7-fOdnZ2d@giganews.com> |
| In reply to | #532168 |
On Wed, 11 Nov 2015 19:58:35 +0000, Fabian Russell wrote:
> On Wed, 11 Nov 2015 18:01:38 +0000, Fabian Russell wrote:
>
>> Greetings physics enthusiasts:
>>
>>
> What? No takers?
Hi Fabian,
Thanks for posting the floating-point test code. Right out of the gate,
I'm not great at math, nor am I a physicist. I enjoy reading about
science and watching those with an actual aptitude for it talk about
smart stuff. I enjoy working with Linux though, and when I saw the
opportunity to try out something new I jumped at it :D
I configured and ran linux.sh as instructed by the README.txt file. When
the compilation and execution was complete, I took a peak at the output
but wasn't sure what to make of it. It looks like some of the tests pass
(only 11 out of 14 show UCBPASS!); but again, I don't know much about
what I'm looking for, or what to expect.
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.
8<
rm -f *.o *.out *.tmp core fpce/fpce.o
make -f ../libctest/Makefile SRC=.. clean
make[1]: Entering directory '/pathto/ucbtest-src/ucbtest-results'
make[1]: Leaving directory '/pathto/ucbtest-src/ucbtest-results'
if test -d `dirname fpce/fpce.o` ; then : ; else mkdir -p `dirname fpce/
fpce.o` ; fi
cpp -traditional -P -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../
ucbtest/fpce.S > fpce.s
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET -c fpce.s
mv fpce.o fpce/fpce.o
make -f ../libctest/Makefile SRC=".." \
F77OPTS="-O2 -pipe -march=native -mtune=native -mfpmath=sse " CPP="cpp -
traditional" CPPOPTS="-DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET"
make[1]: Entering directory '/pathto/ucbtest-src/ucbtest-results'
a - testabsd.o
a - testabss.o
a - testabsx.o
a - testacosd.o
a - testacoss.o
a - testacosx.o
a - testaddd.o
a - testadds.o
a - testaddx.o
a - testasind.o
a - testasins.o
a - testasinx.o
a - testatan2d.o
a - testatan2s.o
a - testatan2x.o
a - testatand.o
a - testatans.o
a - testatanx.o
a - testcabsd.o
a - testcabss.o
a - testcabsx.o
a - testceild.o
a - testceils.o
a - testceilx.o
a - testcosd.o
a - testcoshd.o
a - testcoshs.o
a - testcoshx.o
a - testcoss.o
a - testcosx.o
a - testdivd.o
a - testdivs.o
a - testdivx.o
a - testexpd.o
a - testexpm1d.o
a - testexpm1s.o
a - testexpm1x.o
a - testexps.o
a - testexpx.o
a - testfloord.o
a - testfloors.o
a - testfloorx.o
a - testhypotd.o
a - testhypots.o
a - testhypotx.o
a - testlog10d.o
a - testlog10s.o
a - testlog10x.o
a - testlog1pd.o
a - testlog1ps.o
a - testlog1px.o
a - testlogd.o
a - testlogs.o
a - testlogx.o
a - testmodd.o
a - testmods.o
a - testmodx.o
a - testmuld.o
a - testmuls.o
a - testmulx.o
a - testpowd.o
a - testpows.o
a - testpowx.o
a - testsignifd.o
a - testsignifs.o
a - testsignifx.o
a - testsind.o
a - testsinhd.o
a - testsinhs.o
a - testsinhx.o
a - testsins.o
a - testsinx.o
a - testsqrtd.o
a - testsqrts.o
a - testsqrtx.o
a - testsubd.o
a - testsubs.o
a - testsubx.o
a - testtand.o
a - testtanhd.o
a - testtanhs.o
a - testtanhx.o
a - testtans.o
a - testtanx.o
a - testtodoubled.o
a - testtodoubles.o
a - testtodoublex.o
a - testtoextd.o
a - testtoexts.o
a - testtoextx.o
a - testtointd.o
a - testtoints.o
a - testtointx.o
a - testtosingled.o
a - testtosingles.o
a - testtosinglex.o
make[1]: Leaving directory '/pathto/ucbtest-src/ucbtest-results'
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
pi.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/fpce.o -DDP libctest.a -o
cpi_DP.out -I../ucbtest -lm
if /usr/bin/time cpi_DP.out > cpi_DP.output.tmp 2>&1 ; then : ; else \
if grep UCBFAIL cpi_DP.output.tmp ; then : ; else \
echo UCBFAIL cpi_DP.output >> cpi_DP.output.tmp ; \
fi ; \
fi
mv cpi_DP.output.tmp cpi_DP.output
tail cpi_DP.output :
J 20 A 21053343141 / B 6701487259 + C
2.61640504633870695e-22
J 20 R 9.40395480657830006e-38 +- 4.821956586e-36
J 21 A 1783366216531 / B 567663097408 + C
-1.22774977633403598e-24
J 21 R 1.83670992315982423e-40 +- 2.371752362e-38
J 22 A 3587785776203 / B 1142027682075 + C
3.14776981445437118e-25
J 22 R -9.18354961579912116e-41 +- 6.360402274e-39
J 23 A 5371151992734 / B 1709690779483 + C
-1.97383186734566763e-25
J 23 R 1.37753244236986817e-40 +- 4.163647813e-39
J 24 A 8958937768937 / B 2851718461558 + C
7.72159398007597394e-27
J 24 R -2.86985925493722536e-42 +- 1.697392902e-40
J 25 A 139755218526789 / B 44485467702853 + C
-1.61109530158630018e-28
J 25 R 4.48415508583941463e-44 +- 3.684670703e-42
J 26 A 428224593349304 / B 136308121570117 + C
3.80544972802866803e-30
J 26 R 1.40129846432481707e-45 +- 9.041281521e-44
J 27 A 5706674932067741 / B 1816491048114374 + C
-2.33281989961436183e-31
J 27 R 4.37905770101505335e-47 +- 5.749689810e-45
J 28 A 6134899525417045 / B 1952799169684491 + C
4.86271497755635769e-32
J 28 R -1.64214663788064500e-47 +- 1.241700570e-45
ucbtest UCBPASS in ../ucbctest/pi.c at line 129 for double
/usr/bin/time
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
par.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/fpce.o -DDP libctest.a -o
cpar_DP.out -I../ucbtest -lm
if /usr/bin/time cpar_DP.out > cpar_DP.output.tmp 2>&1 ; then : ; else \
if grep UCBFAIL cpar_DP.output.tmp ; then : ; else \
echo UCBFAIL cpar_DP.output >> cpar_DP.output.tmp ; \
fi ; \
fi
ucbtest UCBFAIL in ../ucbctest/par.c at line 2035 for double
mv cpar_DP.output.tmp cpar_DP.output
tail cpar_DP.output :
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
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
findpimain.c ../ucbtest/findpi.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/randm.c
libctest.a -DDP -o cfindpi_DP.out -I../ucbeef -I../ucbtest -lm -DTEST_cos
-DTEST_sin
if /usr/bin/time cfindpi_DP.out > cfindpi_DP.output.tmp 2>&1 ; then : ;
else \
if grep UCBFAIL cfindpi_DP.output.tmp ; then : ; else \
echo UCBFAIL cfindpi_DP.output >> cfindpi_DP.output.tmp ; \
fi ; \
fi
mv cfindpi_DP.output.tmp cfindpi_DP.output
tail cfindpi_DP.output :
/*
* The PI sin() & cos() use appears to agree with true PI to
* at least twice the working precision, or 106 bits.
*/
#define MPI2_P 0x1921fb, 0x54442, 0xd1846, 0x9898c, 0xc5170, 0x1c000 /
* 107(->109)-bit */
ucbtest UCBPASS in ../ucbtest/findpi.c at line 225 for double
/usr/bin/time
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
libmain.c ../ucbtest/lib.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o libctest.a -DDP -o clib_DP.out -I../ucbtest -lm
rm -f clib_DP.output.tmp
case DP in \
SP) suffix=s.input ;; \
DP) suffix=d.input ;; \
QP) suffix=q.input ;; \
esac ; \
for f in ../ucblib/*${suffix} ; do \
echo $f ; \
clib_DP.out < $f >> clib_DP.output.tmp 2>&1 & \
bgproc=$! ; sleep 10 ; kill $bgproc 2>/dev/null ; \
done ; \
started=`ls ../ucblib/*${suffix} 2>/dev/null | wc -w` ; \
finished=`grep Total clib_DP.output.tmp | wc -l` ; \
if grep UCBFAIL clib_DP.output.tmp 1>/dev/null 2>&1 || test $finished -ne
$started ; then \
echo UCBFAIL clib_DP.output , $finished out of $started tests completed
>> clib_DP.output.tmp ; \
else echo UCBPASS clib_DP.output >> clib_DP.output.tmp ; fi
../ucblib/acosd.input
../ucblib/addd.input
../ucblib/asind.input
../ucblib/atan2d.input
../ucblib/atand.input
../ucblib/cabsd.input
../ucblib/ceild.input
../ucblib/cosd.input
../ucblib/coshd.input
../ucblib/divd.input
../ucblib/expd.input
../ucblib/fabsd.input
../ucblib/floord.input
../ucblib/fmodd.input
../ucblib/hypotd.input
../ucblib/log10d.input
../ucblib/logd.input
../ucblib/muld.input
../ucblib/powd.input
../ucblib/sind.input
../ucblib/sinhd.input
../ucblib/sqrtd.input
../ucblib/subd.input
../ucblib/tand.input
../ucblib/tanhd.input
mv clib_DP.output.tmp clib_DP.output
Totals clib_DP.output :
Total 60 tests: pass 60, flags err 0, value err 0, acosd
Total 352 tests: pass 352, flags err 0, value err 0, addd
Total 77 tests: pass 77, flags err 0, value err 0, asind
Total 104 tests: pass 104, flags err 0, value err 0, atan2d
Total 57 tests: pass 57, flags err 0, value err 0, atand
Total 126 tests: pass 126, flags err 0, value err 0, cabsd
Total 99 tests: pass 99, flags err 0, value err 0, ceild
Total 53 tests: pass 53, flags err 0, value err 0, cosd
Total 68 tests: pass 68, flags err 0, value err 0, coshd
Total 383 tests: pass 383, flags err 0, value err 0, divd
Total 97 tests: pass 97, flags err 0, value err 0, expd
Total 37 tests: pass 37, flags err 0, value err 0, fabsd
Total 103 tests: pass 103, flags err 0, value err 0, floord
Total 352 tests: pass 352, flags err 0, value err 0, fmodd
Total 126 tests: pass 126, flags err 0, value err 0, hypotd
Total 89 tests: pass 89, flags err 0, value err 0, log10d
Total 83 tests: pass 83, flags err 0, value err 0, logd
Total 340 tests: pass 340, flags err 0, value err 0, muld
Total 1543 tests: pass 1543, flags err 0, value err 0, powd
Total 52 tests: pass 52, flags err 0, value err 0, sind
Total 72 tests: pass 72, flags err 0, value err 0, sinhd
Total 102 tests: pass 102, flags err 0, value err 0, sqrtd
Total 321 tests: pass 321, flags err 0, value err 0, subd
Total 54 tests: pass 54, flags err 0, value err 0, tand
Total 72 tests: pass 72, flags err 0, value err 0, tanhd
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
divmain.c ../ucbtest/div.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o libctest.a -DDP -o cdiv_DP.out -I../ucbtest -lm
if /usr/bin/time cdiv_DP.out > cdiv_DP.output.tmp 2>&1 ; then : ; else \
if grep UCBFAIL cdiv_DP.output.tmp ; then : ; else \
echo UCBFAIL cdiv_DP.output >> cdiv_DP.output.tmp ; \
fi ; \
fi
mv cdiv_DP.output.tmp cdiv_DP.output
tail 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
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
mulmain.c ../ucbtest/mul.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o libctest.a -DDP -o cmul_DP.out -I../ucbtest -lm
if /usr/bin/time cmul_DP.out > cmul_DP.output.tmp 2>&1 ; then : ; else \
if grep UCBFAIL cmul_DP.output.tmp ; then : ; else \
echo UCBFAIL cmul_DP.output >> cmul_DP.output.tmp ; \
fi ; \
fi
mv cmul_DP.output.tmp cmul_DP.output
tail cmul_DP.output :
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
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
sqrmain.c ../ucbtest/sqr.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o libctest.a -DDP -o csqr_DP.out -I../ucbtest -lm
if /usr/bin/time csqr_DP.out > csqr_DP.output.tmp 2>&1 ; then : ; else \
if grep UCBFAIL csqr_DP.output.tmp ; then : ; else \
echo UCBFAIL csqr_DP.output >> csqr_DP.output.tmp ; \
fi ; \
fi
mv csqr_DP.output.tmp csqr_DP.output
tail csqr_DP.output :
ucbtest START in ../ucbtest/sqr.c at line 361 for double
1000000 tests on 1 regions with 53 significant bits
Number of failures (out of 353648 cases) = 0
ucbtest UCBPASS in ../ucbtest/sqr.c at line 459 for double
/usr/bin/time
test=`echo csin_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o csin_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo ccos_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o ccos_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo catan_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o catan_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo cexp_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o cexp_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo cexpm1_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o cexpm1_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo clog1p_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o clog1p_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
test=`echo clog_DP.out | awk -F_ '{print $1}' | sed 's/^c//g'` ; \
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbctest/
beefmain.c ../ucbtest/beef.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/
fpce.o ../ucbeef/anlyzr.c ../ucbeef/distd.c ../ucbeef/others.c ../ucbeef/
randm.c ../ucbeef/report.c ../ucbeef/er_atn.c ../ucbeef/er_dfl.c ../
ucbeef/er_em1.c ../ucbeef/er_l1p.c ../ucbeef/er_log.c ../ucbeef/er_sin.c
libctest.a -DDP -o clog_DP.out -I../ucbtest -I../ucbeef -lm -DTEST_$test
gcc -O2 -pipe -march=native -mtune=native -mfpmath=sse -fno-strict-
aliasing -DNO_FUNCF -DNTESTS=1000000 -DNREGIONS=16 -DQUIET ../ucbeef/
beefscan.c ../ucbtest/init.c ../ucbtest/ieee.c fpce/fpce.o -o beefscan.out
-lm -I../ucbtest
if /usr/bin/time csin_DP.out > csin_DP.output.tmp 2> csin_DP.output.err ;
then \
cat csin_DP.output.tmp | beefscan.out | cat - csin_DP.output.err
> csin_DP.output ; \
else \
echo UCBFAIL csin_DP.output.tmp $? | cat csin_DP.output.tmp
csin_DP.output.err - > csin_DP.output ; \
fi
rm csin_DP.output.tmp csin_DP.output.err
csin_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
SIN(X) ALL [ 0.0000000, 7.0000000) -5.104 2.695 0
ucbtest UCBFAIL in SIN(X) at line 444 for generic
/usr/bin/time
if /usr/bin/time ccos_DP.out > ccos_DP.output.tmp 2> ccos_DP.output.err ;
then \
cat ccos_DP.output.tmp | beefscan.out | cat - ccos_DP.output.err
> ccos_DP.output ; \
else \
echo UCBFAIL ccos_DP.output.tmp $? | cat ccos_DP.output.tmp
ccos_DP.output.err - > ccos_DP.output ; \
fi
rm ccos_DP.output.tmp ccos_DP.output.err
ccos_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
COS(X) ALL [ 0.0000000, 7.0000000) -3.740 1.567 0
ucbtest UCBFAIL in COS(X) at line 444 for generic
/usr/bin/time
if /usr/bin/time catan_DP.out > catan_DP.output.tmp 2>
catan_DP.output.err ; then \
cat catan_DP.output.tmp | beefscan.out | cat - catan_DP.output.err
> catan_DP.output ; \
else \
echo UCBFAIL catan_DP.output.tmp $? | cat catan_DP.output.tmp
catan_DP.output.err - > catan_DP.output ; \
fi
rm catan_DP.output.tmp catan_DP.output.err
catan_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
ATAN(X) ALL [ 0.0000000, 65536.0000000) -0.539 0.539 0
ucbtest UCBPASS in ATAN(X) at line 442 for generic
/usr/bin/time
if /usr/bin/time cexp_DP.out > cexp_DP.output.tmp 2> cexp_DP.output.err ;
then \
cat cexp_DP.output.tmp | beefscan.out | cat - cexp_DP.output.err
> cexp_DP.output ; \
else \
echo UCBFAIL cexp_DP.output.tmp $? | cat cexp_DP.output.tmp
cexp_DP.output.err - > cexp_DP.output ; \
fi
rm cexp_DP.output.tmp cexp_DP.output.err
cexp_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
EXP(X) ALL [ -663.0585938, 663.0585938) -0.505 0.506 0
ucbtest UCBPASS in EXP(X) at line 442 for generic
/usr/bin/time
if /usr/bin/time cexpm1_DP.out > cexpm1_DP.output.tmp 2>
cexpm1_DP.output.err ; then \
cat cexpm1_DP.output.tmp | beefscan.out | cat -
cexpm1_DP.output.err > cexpm1_DP.output ; \
else \
echo UCBFAIL cexpm1_DP.output.tmp $? | cat cexpm1_DP.output.tmp
cexpm1_DP.output.err - > cexpm1_DP.output ; \
fi
rm cexpm1_DP.output.tmp cexpm1_DP.output.err
cexpm1_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
EXPM1(X) ALL [ -1.0371094, 1.0087891) -0.774 0.825 0
ucbtest UCBPASS in EXPM1(X) at line 442 for generic
/usr/bin/time
if /usr/bin/time clog1p_DP.out > clog1p_DP.output.tmp 2>
clog1p_DP.output.err ; then \
cat clog1p_DP.output.tmp | beefscan.out | cat -
clog1p_DP.output.err > clog1p_DP.output ; \
else \
echo UCBFAIL clog1p_DP.output.tmp $? | cat clog1p_DP.output.tmp
clog1p_DP.output.err - > clog1p_DP.output ; \
fi
rm clog1p_DP.output.tmp clog1p_DP.output.err
clog1p_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
6250 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
LOG1P(X) ALL [ -0.2928932, 0.4142136) -0.824 0.823 0
ucbtest UCBPASS in LOG1P(X) at line 442 for generic
/usr/bin/time
if /usr/bin/time clog_DP.out > clog_DP.output.tmp 2> clog_DP.output.err ;
then \
cat clog_DP.output.tmp | beefscan.out | cat - clog_DP.output.err
> clog_DP.output ; \
else \
echo UCBFAIL clog_DP.output.tmp $? | cat clog_DP.output.tmp
clog_DP.output.err - > clog_DP.output ; \
fi
rm clog_DP.output.tmp clog_DP.output.err
clog_DP.output :
ucbtest START in ../ucbtest/beef.c at line 448 for double
625 tests on 16 regions with 53 significant bits
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count
{SYM}= Non-symmetry count if nonzero
[ From , to ) N.M.E. P.M.E. NMC
{SYM}
LOG(X) ALL [ 0.7071068, 1.4142135) -0.532 0.531 0
ucbtest UCBPASS in LOG(X) at line 442 for generic
/usr/bin/time
UCBFAIL indicates problems!
../ucbtest-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444
for generic
../ucbtest-results/cpar_DP.output: ucbtest UCBFAIL in ../ucbctest/par.c
at line 2035 for double
../ucbtest-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444
for generic
only 11 out of 14 show UCBPASS!
Wed Nov 11 21:19:12 CST 2015
Linux computername 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU/Linux
WHO username HOST bigred ID 007f0101 WD /pathto/ucbtest-src/ucbtest-
results
>8
By the way, this thread is hilarious :D
Thanks Fabian,
Monkey Man
>
> What's the matter? Floating point numbers are not impressive enough to
> your digital savoir-faire?
>
> Floating point numbers make the computing world go around. Nothing
> could be done without them, from calculating a flight to Mars to
> balancing grandma's check book.
>
> What's the matter? Y'all a bunch of Object Oriented a$$wipes that have
> never experienced the real machine? Y'all a bunch of hardware virgins?
>
> Does the expression "Branch On Carry Clear" have any significance to
> y'all?
>
> Ha, ha! Y'all couldn't construct a 2's complement to save grandma from
> being sold to the Arabs!
>
> Catastrophic cancellation would bite your lame asses and no dick head in
> the OO department would ever suspect the least.
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-12 04:47 +0000 |
| Message-ID | <pan.2015.11.12.04.47.15@localhost.localdomain> |
| In reply to | #532262 |
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.
>
The test goes back a long way when there many different kinds of
machines in the computing universe and floating point hardware
differed among them. Today, most hardware is either Intel or AMD,
which contain the same FP hardware, and the test is no longer that
significant. But since the test is so rigorous, it could still be
interesting to run it to see if everything performs as expected.
Since the Intel/AMD hardware contains essentially two separate and
distinct arithmetic/FP units, the results can differ depending on
which of the two is selected by the compiler. In this case, however,
I have set the compiler flags to use the newer SIMD FP unit,
which is IEEE754 compliant.
The test is basically a test for IEEE754 compliance, which is standard
nowadays, and is limited to certain aspects of the arithmetic functions
such as correct rounding, guard bits, etc. If a multiplication suite passes,
then the processor fulfills all IEEE754 requirements for multiplication.
It doesn't sound too impressive, but there are subtle details of digital
arithmetic that can be missed by hardware or by compiler configuration
of that hardware.
IEEE754 compliance is intended to allow all machines to produce the
same results for mathematical computations. Surprisingly, this did
not always happens, and it still may not happen depending, as mentioned,
on compiler configuration of the hardware or even of the hardware itself.
Yes, the output is atrocious. I suppose that academics do not strive
for writing code and output that other people can read. As long as they
can read their own results then they are satisfied. But the output is little
more than just a statement of addition passed, subtraction passed,
etc. All the output boils down to basically that.
You have posted the linux.log file, which is sort of a running commentary
during the program execution. For each test suite, the details are summarized
in the various *.output files. You can also check those for more information.
In your case all tests passed except for these:
>
> UCBFAIL indicates problems!
> ../ucbtest-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444
> for generic
> ../ucbtest-results/cpar_DP.output: ucbtest UCBFAIL in ../ucbctest/par.c
> at line 2035 for double
> ../ucbtest-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444
> for generic
>
> only 11 out of 14 show UCBPASS!
>
Now, two of these failures involve the transcendental SINE and COSINE function.
These results are not actually failures. The reason is that IEEE754 does
not create standards for the SINE or COSINE. Hardware, or software, is free
to implement them in any way. But the UCBTEST marks these as failures because
the results for certain inputs to these two functions have exceeded a certain
tolerance. If you check the ccos_DP.output and csin_DP.output files you should
see something like this:
[ From , to ) N.M.E. P.M.E. NMC {SYM}
COS(X) ALL [ 0.0000000, 7.0000000) -3.740 1.567 0
ucbtest UCBFAIL in COS(X) at line 444 for generic
Here, the NME and PME columns indicate NME and PME values of -3.740 and
1.567.
What does this mean?
Error units in FP calculations are expressed in ulp's, or "units in the
last place.' In double FP precision, an ulp is about 1e-15. The UCBTEST
expects COSE and SINE errors to be less than 1 ulp. In your case, the
max errors observed were -3.74 ulps and 1.567 ulps. Therefore, although
this is not technically an error, it has been flagged as such.
If you check all the other *.output files you will see the same summary
in terms of ulp's. The tests that pass all had errors that were less
than 1 ulp.
So, everything looks fine except for cpar_DP test.
Unfortunately, this is UNEXPECTED and possibly represent a true error.
First, some background.
This test is actually not a part of the UCBTEST. It is taken from
the famous PARANOIA test of W. Kahan, who is a big name in the FP
world. The PARANOIA test examines all facets of FP on a system.
On your machine, something went wrong. Please check the file cpar_DP
output, which should contain the specific error or defect found.
I've been using Linix since 1998. Currently, I see no errors with
the PARANOIA test, but in the past I would regularly get certain
failures.
The fault could be with glibc or with the compiler gcc.
Again, please check the cpar_DP.output.
Well, I've been trying to make a very complex story very short
and I know I've missed a lot of detail. If you need more clarification
I will try to fill in any gaps.
incidentally, this UCBTEST will test all FP formats, that is double
precision, single precision, and quad precision. I have switched
on only the double precision test since it is usually the only format
used. But the other two can be switched on by modifying the linux.sh
script.
Note: quad precision is actually "extended" precision on the Intel
microprocessor and is NOT IEEE754 compliant and will fail the test.
[toc] | [prev] | [next] | [standalone]
| From | Monkey Man <manm0nk3y@gmail.com> |
|---|---|
| Date | 2015-11-12 20:19 -0600 |
| Message-ID | <MZydnSKCm4Jd1djLnZ2dnUU7-YPOydjZ@giganews.com> |
| In reply to | #532279 |
Hi Fabian,
Thanks for the reply! I've in-lined my comments/questions below:
On Thu, 12 Nov 2015 04:47:10 +0000, Fabian Russell wrote:
> 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.
>>
>>
> The test goes back a long way when there many different kinds of
> machines in the computing universe and floating point hardware differed
> among them. Today, most hardware is either Intel or AMD,
> which contain the same FP hardware, and the test is no longer that
> significant.
Interesting, nice to get some context around why this thing even came
into existence. I wonder if this program would work across non-x86/AMD
hardware (ex. ARM, MIPS, SPARC, etc.) so that there can be a single
comprehensive test suite that ensures floating point hardware is
operating according to the IEEE specification. Perhaps this application
can handle that.
> But since the test is so rigorous, it could still be
> interesting to run it to see if everything performs as expected.
Absolutely, it looks like it's already provided some insight into one or
more potential issues with my computer.
> Since the Intel/AMD hardware contains essentially two separate and
> distinct arithmetic/FP units, the results can differ depending on which
> of the two is selected by the compiler. In this case, however,
> I have set the compiler flags to use the newer SIMD FP unit,
> which is IEEE754 compliant.
Oh interesting. I didn't know there were two FP units on Intel/AMD
processors. I'll have to look that up. I wonder what logic the compiler
uses when deciding which to use. Thanks for the info, that's good to know!
>
> The test is basically a test for IEEE754 compliance, which is standard
> nowadays, and is limited to certain aspects of the arithmetic functions
> such as correct rounding, guard bits, etc. If a multiplication suite
> passes, then the processor fulfills all IEEE754 requirements for
> multiplication.
>
> It doesn't sound too impressive, but there are subtle details of digital
> arithmetic that can be missed by hardware or by compiler configuration
> of that hardware.
I'm a massive fan of testing; part of my job at work is making sure our
software has been tested thoroughly. To do so we build automated test
suites, build servers, and other supporting infrastructure that ensure
everything meets expectations. I can completely appreciate the value of
test suites, especially for such a fundamental and critical piece of
hardware.
>
> IEEE754 compliance is intended to allow all machines to produce the same
> results for mathematical computations. Surprisingly, this did not
> always happens, and it still may not happen depending, as mentioned,
> on compiler configuration of the hardware or even of the hardware
> itself.
For sure, I've been involved in projects where we've run into bizarre
floating point behavior and the _solution_ usually ends up being a tirade
about how flawed floating point processors are, and an assertion that
they cannot be trusted. Generalities abound, people vent their
frustrations blaming whatever the actual problem was on the FP hardware
(which it may have been), and then they move on.
>
> Yes, the output is atrocious. I suppose that academics do not strive
> for writing code and output that other people can read. As long as they
> can read their own results then they are satisfied. But the output is
> little more than just a statement of addition passed, subtraction
> passed,
> etc. All the output boils down to basically that.
LOL, agreed. Whoever wrote this code seems pretty smart, and because they
did the world (and a few companies) a favor by implementing this robust
test-suite, I'll try to let it slide :D Also, now that I've skimmed
through the *.output files, it's a bit easier to piece together the
overall structure of the output.
>
> You have posted the linux.log file, which is sort of a running
> commentary during the program execution. For each test suite, the
> details are summarized in the various *.output files. You can also
> check those for more information.
>
> In your case all tests passed except for these:
>
>
>> UCBFAIL indicates problems!
>> ../ucbtest-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line
>> 444 for generic ../ucbtest-results/cpar_DP.output: ucbtest UCBFAIL in
>> ../ucbctest/par.c at line 2035 for double
>> ../ucbtest-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line
>> 444 for generic
>>
>> only 11 out of 14 show UCBPASS!
>>
>>
> Now, two of these failures involve the transcendental SINE and COSINE
> function.
> These results are not actually failures. The reason is that IEEE754
> does not create standards for the SINE or COSINE. Hardware, or
> software, is free to implement them in any way. But the UCBTEST marks
> these as failures because the results for certain inputs to these two
> functions have exceeded a certain tolerance. If you check the
> ccos_DP.output and csin_DP.output files you should see something like
> this:
>
> [ From , to ) N.M.E. P.M.E. NMC
> {SYM}
>
> COS(X) ALL [ 0.0000000, 7.0000000) -3.740 1.567 0
> ucbtest UCBFAIL in COS(X) at line 444 for generic
>
>
> Here, the NME and PME columns indicate NME and PME values of -3.740 and
> 1.567.
>
> What does this mean?
>
> Error units in FP calculations are expressed in ulp's, or "units in the
> last place.' In double FP precision, an ulp is about 1e-15. The
> UCBTEST expects COSE and SINE errors to be less than 1 ulp. In your
> case, the max errors observed were -3.74 ulps and 1.567 ulps.
> Therefore, although this is not technically an error, it has been
> flagged as such.
Ahhh, interesting. This is a great explanation, thank you! So, just to
make sure I understand (which I probably don't)... It's comparing the
result against an expectation up to the 1e-15'th place?
Compared: N.NNNNNNNNNNNNNNYYYY
Expected: 1.123456789123456789
Produced: 1.123456789123453049
------------------------------
Differed: 0.000000000000003740
>
> If you check all the other *.output files you will see the same summary
> in terms of ulp's. The tests that pass all had errors that were less
> than 1 ulp.
>
> So, everything looks fine except for cpar_DP test.
>
> Unfortunately, this is UNEXPECTED and possibly represent a true error.
>
> First, some background.
>
> This test is actually not a part of the UCBTEST. It is taken from the
> famous PARANOIA test of W. Kahan, who is a big name in the FP world.
> The PARANOIA test examines all facets of FP on a system.
>
> On your machine, something went wrong. Please check the file cpar_DP
> output, which should contain the specific error or defect found.
Thanks for the info about the paranoia suite. I looked through the
cpar_DP.output file and noted the following:
8<
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.
>8
As an exercise, I think I might look at the implementation and see if I
can dig up what it's doing. Anything else you think I might want to do
about this error? I'm guessing it's not going to manifest itself, or if
it does it'll be subtle, since it's using a ULP of ~1e-15; although I'm
not sure if it's using the same ULP for this particular test case, or
what the actual variation was.
Also, can you explain what chopping is about? I'm sure I could look it
up, but you are pretty good at explaining things, so I wonder if you
wouldn't mind taking a crack at it.
>
> I've been using Linix since 1998. Currently, I see no errors with the
> PARANOIA test, but in the past I would regularly get certain failures.
Pretty cool that you've been a Linux user for so long; I've only been
using Linux since 2002. If you don't mind my asking, are you using it at
home and/or work; and what sort of computing do you use it for?
>
> The fault could be with glibc or with the compiler gcc.
Ah, perhaps. I'm a big fan of Gentoo and LFS, but to get this computer up
and running rapidly I elected to throw Debian on it. Soooooo, whatever
the upstream maintainers did to build _every_binary_on_my_system_, as you
stated, may not be jiving with my hardware. I've got another drive around
as well that I built for this computer using LFS, I could throw the test-
suite on that and see what results we get. Perhaps that'd help identify
whether or not this is a problem with the binaries distributed with
Debian.
>
> Again, please check the cpar_DP.output.
>
> Well, I've been trying to make a very complex story very short and I
> know I've missed a lot of detail. If you need more clarification I will
> try to fill in any gaps.
LOL, I don't know what other physicists might think of this thread, but I
think you've done a great job explaining things. It's been really
educational, and fun. Thanks man!
>
> incidentally, this UCBTEST will test all FP formats, that is double
> precision, single precision, and quad precision. I have switched on
> only the double precision test since it is usually the only format used.
> But the other two can be switched on by modifying the linux.sh script.
Good to know, I think I'll do that just because this is Linux, I have the
source code, I have the time, and... I can!
>
> Note: quad precision is actually "extended" precision on the Intel
> microprocessor and is NOT IEEE754 compliant and will fail the test.
Cool, I'll lower my expectations. Gotta love extensions to standards.
What is quad precision used for, and what sort of applications/industries
would use something like that?
Thanks Fabian,
Monkey Man
P.S. Someone mentioned I might be Fabian. I'm sorry to disappoint, but
I'm not.
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-13 03:28 +0000 |
| Message-ID | <pan.2015.11.13.03.28.24@localhost.localdomain> |
| In reply to | #532606 |
On Thu, 12 Nov 2015 20:19:44 -0600, Monkey Man wrote: > > I wonder if this program would work across non-x86/AMD > hardware (ex. ARM, MIPS, SPARC, etc.) > That was the whole point of the test, I suppose. If you download the original source code from the Netlib link I gave in the original post, you will find the output logs from many different architectures. I glanced through some and the results are very poor for some of those machines.. On my current Linux machine I only get the two pseudo-errors with SINE and COSINE. > > Oh interesting. I didn't know there were two FP units on Intel/AMD > processors. I'll have to look that up. > Check the Intel hardware manuals: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html Wonderful stuff. > > For sure, I've been involved in projects where we've run into bizarre > floating point behavior and the _solution_ usually ends up being a tirade > about how flawed floating point processors are > Well, there are many compiler options that influence the FP unit. The Intel ICC compiler, reputed to be the best, has default settings that optimize for computational speed. This destroys all IEEE754 compliance and therefore reproducability. The GNU Compile Collection (GCC) has a similar setting called fast-math. IEEE754 is about reproducubility, but it seems that it may be too slow for some programmers. Fast math also disables what are known as "denormal" numbers and enables a computational technique known as "flush to zero." Although simple ideas, I'd better not venture into denormals or flush-to-zero at this time, but suffice it to say that they can severely effect certain kinds of computations. > > just to > make sure I understand (which I probably don't)... It's comparing the > result against an expectation up to the 1e-15'th place? > Basically, yes. The maximum error for arithmetic should never be more than 0.5 ulp between representable numbers. If you check the directory "ucblib" you will find the actual test values used, in hexadecimal notation. There are input numbers and expected output values plus the expected condition flags set by the FP processor. (Different precisions are indicated by "s," "d," and "q.") > > 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. > Yes, that seems to be the error, or FLAW, actually. This means that the computations are correct but the rounding is not ideal. > > Also, can you explain what chopping is about? > Regarding this program, chopping likely means just "truncation" where the least significant bits are just discarded rather than rounded. I say "likely means" because there is no documentation, but I don't know what else it could mean. Truncation is actually a form of rounding, but they indicate it by saying "chopping." > > I've only been > using Linux since 2002. If you don't mind my asking, are you using it at > home and/or work; and what sort of computing do you use it for? > Well, Linux is the only OS, isn't it? Therefore I use it for everything. > > Gotta love extensions to standards. > What is quad precision used for, and what sort of applications/industries > would use something like that? > More precision is always better, especially if there is hardware for it. Quad precision is actually 128 bits. It is part of the C standard as float128. But on Intel/AMD machines it has to be implemented in software only. There are other architectures with float128 hardware (I can't recall specifically which). However, the older Intel 387 FP processor has 80-bit floats. This is "extended" precision. See the Intel manuals above for lots more info on this. But as I mentioned the 387 FP is not IEEE754 complaint. In fact, if you set the compiler flags to switch on 387 FP, the UCBTEST will fail in many places. If you have any more concerns, feel free to post them. I am by no means an expert in this area but all questions can stimulate and further refine my knowledge. > > Monkey Man > > P.S. Someone mentioned I might be Fabian. I'm sorry to disappoint, but > I'm not. > I hate to be uncivil and impolite, but those folks are crass idiots that deserve no respect or dignity whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Big Fish in a Small Crotch <bigfishinasmallcrotch@myself.com> |
|---|---|
| Date | 2015-11-12 22:40 -0500 |
| Message-ID | <12ajdcfpljus4.tt3u89xa1a9j.dlg@40tude.net> |
| In reply to | #532631 |
On 13 Nov 2015 03:28:26 GMT, Fabian Russell wrote: > I hate to be uncivil and impolite, but those folks are crass idiots that > deserve no respect or dignity whatsoever. +1 COLA is a cesspit of Linux loons who do NOTHING to advocate Linux. They are in fact Linux's worst nightmare in terms of public relations. Several of them don't even use Linux, if you can believe that. Your problem is you are an old school nix elitist and you have seen your superiority (knowledge) erode away as people no longer need to know HOW a computer works much like they no longer need to know how a car functions in order to get to grandma's house for Thanksgiving dinner. It's the way things are. The problem is you paint these people with a wide brush. A brain surgeon doesn't need to know how an MRI machine works to save lives. He also doesn't need to know how to program his computer to save lives. A friend of mine designs components for GM's race car division and he has no clue how his network and corporate VPN works. Why should he have to? That's where the nix elitist, like you, fail. And by virtue of your distaste and narcissistic traits you are part of the problem of Linux adoption and in effect almost, not quite but almost as bad as the Linux loons in COLA. Sure if you are in IT you should know as much about everything computer related as you can. Absolutely. Same goes for the brain surgeon, in his chosen field. But to call people ignorant just because they don't know a bite from a byte is arrogant. And to call the 98.5 percent of the computer users who don't use Linux, morons, is ludicrous. Like I said, you are seeing your worth as a super geek drying up as computers become appliances and your skills are no longer looked upon as God like. -- You Ain't The Biggest Fish In The Crotch.
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-13 03:59 +0000 |
| Message-ID | <pan.2015.11.13.03.59.49@localhost.localdomain> |
| In reply to | #532634 |
On Thu, 12 Nov 2015 22:40:20 -0500, Big Fish in a Small Crotch wrote: > > Like I said, you are seeing your worth as a super geek drying up as > computers become appliances and your skills are no longer looked upon as > God like. > I have no worth as a "super geek," nor do I desire a worth. I tried programming as a career. In quick succession I obtained several positions as a programmer, none of which were to my liking. The programming trade, as currently practiced, would never be attractive to me. There are still the necessary niche areas where fundamental stuff, like C and assembly, still occur, but I doubt if I could become established there, even if I wanted to, which I don't. My interests are largely avocational, but since computers are so entrenched, they are still nonetheless important. I don't care what the majority of the world does. There are always places to find kindred spirits.
[toc] | [prev] | [next] | [standalone]
| From | benj <none@gmail.com> |
|---|---|
| Date | 2015-11-13 00:16 -0500 |
| Message-ID | <Eme1y.81004$lL.42187@fx28.iad> |
| In reply to | #532639 |
On 11/12/2015 10:59 PM, Fabian Russell wrote:
> On Thu, 12 Nov 2015 22:40:20 -0500, Big Fish in a Small Crotch wrote:
>
>>
>> Like I said, you are seeing your worth as a super geek drying up as
>> computers become appliances and your skills are no longer looked upon as
>> God like.
>>
>
> I have no worth as a "super geek," nor do I desire a worth.
>
> I tried programming as a career. In quick succession I obtained
> several positions as a programmer, none of which were to my liking.
> The programming trade, as currently practiced, would never be attractive
> to me.
>
> There are still the necessary niche areas where fundamental stuff,
> like C and assembly, still occur, but I doubt if I could become
> established there, even if I wanted to, which I don't.
>
> My interests are largely avocational, but since computers are so
> entrenched, they are still nonetheless important.
>
> I don't care what the majority of the world does. There are always
> places to find kindred spirits.
>
Yeah, that's why I'm here too! Fellow kooks!
--
___ ___ ___ ___
/\ \ /\ \ /\__\ /\ \
/::\ \ /::\ \ /::| | \:\ \
/:/\:\ \ /:/\:\ \ /:|:| | ___ /::\__\
/::\~\:\__\ /::\~\:\ \ /:/|:| |__ /\ /:/\/__/
/:/\:\ \:|__| /:/\:\ \:\__\ /:/ |:| /\__\ \:\/:/ /
\:\~\:\/:/ / \:\~\:\ \/__/ \/__|:|/:/ / \::/ /
\:\ \::/ / \:\ \:\__\ |:/:/ / \/__/
\:\/:/ / \:\ \/__/ |::/ /
\::/__/ \:\__\ /:/ /
~~ \/__/ \/__/
[toc] | [prev] | [next] | [standalone]
| From | GreyCloud <cumulus@mist.com> |
|---|---|
| Date | 2015-11-13 15:00 -0700 |
| Message-ID | <f5-dnTVEx_U8wNvLnZ2dnUU7-VWdnZ2d@bresnan.com> |
| In reply to | #532639 |
On 11/12/15 20:59, Fabian Russell wrote: > On Thu, 12 Nov 2015 22:40:20 -0500, Big Fish in a Small Crotch wrote: > >> >> Like I said, you are seeing your worth as a super geek drying up as >> computers become appliances and your skills are no longer looked upon as >> God like. >> > > I have no worth as a "super geek," nor do I desire a worth. > > I tried programming as a career. In quick succession I obtained > several positions as a programmer, none of which were to my liking. > The programming trade, as currently practiced, would never be attractive > to me. > > There are still the necessary niche areas where fundamental stuff, > like C and assembly, still occur, but I doubt if I could become > established there, even if I wanted to, which I don't. > > My interests are largely avocational, but since computers are so > entrenched, they are still nonetheless important. > > I don't care what the majority of the world does. There are always > places to find kindred spirits. > OTW, you were let go. -- My problem is that I don't have enough middle fingers.
[toc] | [prev] | [next] | [standalone]
| From | Monkey Man <manm0nk3y@gmail.com> |
|---|---|
| Date | 2015-11-13 01:40 -0600 |
| Message-ID | <xKKdndnBT7OfCdjLnZ2dnUU7-SWdnZ2d@giganews.com> |
| In reply to | #532631 |
On Fri, 13 Nov 2015 03:28:26 +0000, Fabian Russell wrote: > On Thu, 12 Nov 2015 20:19:44 -0600, Monkey Man wrote: > > >> I wonder if this program would work across non-x86/AMD hardware (ex. >> ARM, MIPS, SPARC, etc.) >> >> > That was the whole point of the test, I suppose. Right, I think you're right. After thinking about your response, I realized support (meaning what platforms it can run on) mainly depends on the toolchain (and make, autotools, etc.), so by implication it should "work" on any platform that GCC can generate binaries for. LOL, I just noticed the ucbDOS directory. Looks like it's even got some *.exe's in there. I'm almost tempted to try 'em out at work tomorrow since one of the projects we're working on does quite a lot of floating point calculations. > > If you download the original source code from the Netlib link I gave in > the original post, you will find the output logs from many different > architectures. I glanced through some and the results are very poor for > some of those machines.. Interesting, I'll have to take a look. > > On my current Linux machine I only get the two pseudo-errors with SINE > and COSINE. > > > >> Oh interesting. I didn't know there were two FP units on Intel/AMD >> processors. I'll have to look that up. >> >> > Check the Intel hardware manuals: > > http://www.intel.com/content/www/us/en/processors/architectures- software-developer-manuals.html > > Wonderful stuff. > You know? I think I may have those already. A while back I was trying to read up on MIPS assembly and downloaded the Intel documentation to compare the two instruction sets (MIPS/Intel). It's pretty fun to see how they each approached ISA design. Some really smart people working really hard problems. > > Well, there are many compiler options that influence the FP unit. > > The Intel ICC compiler, reputed to be the best, has default settings > that optimize for computational speed. This destroys all IEEE754 > compliance and therefore reproducability. > Wow, that doesn't seem like a good idea. I prefer GCC's approach of -O1. > > The GNU Compile Collection (GCC) has a similar setting called fast-math. > > IEEE754 is about reproducubility, but it seems that it may be too slow > for some programmers. Cool, I can definitely see the value in having reproducability as a main goal for a floating point standard, or any standard for that matter. I read one of your other posts where you mentioned another standard that dealt with financial floating point numbers. I'd be interested in learning what the difference is between the two standards. I think a trip to the IEEE site is in order. > > Fast math also disables what are known as "denormal" numbers and enables > a computational technique known as "flush to zero." > > Although simple ideas, I'd better not venture into denormals or > flush-to-zero at this time, but suffice it to say that they can severely > effect certain kinds of computations. Woah, they sound scary. "Flush" is a word I don't want associated with my floats; "Denormal" is also a pretty freaky word when used in the same sentence as "valuable floating point data." :o > Regarding this program, chopping likely means just "truncation" where > the least significant bits are just discarded rather than rounded. > > I say "likely means" because there is no documentation, but I don't know > what else it could mean. Seems like a reasonable assumption. A quick search of the net found this article that has some information about chopping and a nice illustration of what is entailed: http://user.engineering.uiowa.edu/~carch/lectures06/55035-060306-prn.pdf > > Truncation is actually a form of rounding, but they indicate it by > saying "chopping." > > Well, Linux is the only OS, isn't it? Therefore I use it for > everything. I would have to agree. Even though I work in an almost 99% Windows/C# shop, I tend to go about my day as if Linux is indeed the only OS. > > >> Gotta love extensions to standards. >> What is quad precision used for, and what sort of >> applications/industries would use something like that? >> >> > More precision is always better, especially if there is hardware for it. > Solid assertion, agreed. > > Quad precision is actually 128 bits. It is part of the C standard as > float128. Oh I see, so the quad in quad-precision refers to the four blocks of thirty-two bits that the data occupies. Geeeze, that's an awful lot of precision :o From wikipedia, it looks like the max is somewhere around: 1.189731495357231765085759326628007 × 10^4932 Any thoughts around what that type of precision would be used for? Perhaps some type/branch of physics or mathematics maybe? > But on Intel/AMD machines it has to be implemented in software only. > There are other architectures with float128 hardware (I can't recall > specifically which). > > However, the older Intel 387 FP processor has 80-bit floats. This is > "extended" > precision. See the Intel manuals above for lots more info on this. > Cool, definitely will. > > But as I mentioned the 387 FP is not IEEE754 complaint. In fact, if you > set the compiler flags to switch on 387 FP, the UCBTEST will fail in > many places. > > > If you have any more concerns, feel free to post them. I am by no means > an expert in this area but all questions can stimulate and further > refine my knowledge. > Sounds cool, will do Fabian. Thanks again for your well thought out and thorough answers. Really appreciate the discussion. > > >> Monkey Man >> >> P.S. Someone mentioned I might be Fabian. I'm sorry to disappoint, but >> I'm not. >> >> > I hate to be uncivil and impolite, but those folks are crass idiots that > deserve no respect or dignity whatsoever. The more of the threads I read in this group (and some other groups), the more I'm starting to agree. It's been quite some time since I've dug around on usenet, but some groups seem to have taken a turn for the worse. Thanks again Fabian, Monkey Man
[toc] | [prev] | [next] | [standalone]
| From | Fabian Russell <root@localhost.localdomain> |
|---|---|
| Date | 2015-11-13 08:22 +0000 |
| Message-ID | <pan.2015.11.13.08.22.14@localhost.localdomain> |
| In reply to | #532662 |
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. > > Geeeze, that's an awful lot of > precision :o From wikipedia, it looks like the max is somewhere around: > > 1.189731495357231765085759326628007 × 10^4932 > > Any thoughts around what that type of precision would be used for? > Perhaps some type/branch of physics or mathematics maybe? > Everyone says that double (64-bits) is enough for anything. My attitude, which is not entirely scientific, is that if you got it then use it. The more the better. A lot of numerical format decisions were made at a time when the hardware was limited by technology. But it seems that those limits are being removed and extreme precision (both FP and integer) is more and more becoming possible. But it is probably just an extravagance. Better algorithms for computing are more important. Extended precision, via software, is used a lot in cryptography.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | sci.physics
csiph-web