* [gentoo-amd64] Possible Math Problem - Request For Verification
@ 2011-06-25 17:41 Frank Peters
2011-06-25 23:54 ` Marc Joliet
` (3 more replies)
0 siblings, 4 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-25 17:41 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
Hello,
Believe it or not, at the very beginning, Linux/GNU had some math problems.
In particular, it would do somewhat poorly on various floating point tests
that are available on-line. Because I do mathematical work on my machine,
I used to regularly evaluate my software using these tests.
However, for the past several years Linux/GNU has gotten nearly perfect
scores on these same tests and it seemed that glibc and/or gcc had finally
gotten the math code right. As a result of this, I stopped my regular
evaluations of the software.
Just recently I decided to run these tests again. I expected to see the
same nearly perfect scores but, to my surprise, a failure occurred in the
area of complex number operations. This may not be a very serious failure,
but it was not present during prior tests and thus it should not be present
now.
Possibly a fault has crept in somewhere either in glibc or gcc. Because
I had stopped my regular testing I can't relate the failure to any specific
version change of either package.
I need to request a verification from any Gentoo users. All that needs to
be done is run a straightforward software test.
The software is called UCBTEST and is described at http://www.netlib.org/fp/
The source code, however, is ancient Unix (1995) code and must be patched.
I have created a patched tarball that can run on recent Linux. This file
is attached as ucbtest.tar.bz2
If one is accustomed to modern GUI software, this code is a mess, but it is
rather straightforward to implement. Here are the steps:
1) Create a directory somewhere, e.g. /tmp/fp-test
2) Unpack the tarball into this directory.
3) Change into the /tmp/fp-test directory
4) Modify the ucbREADME/linux.sh file as follows:
Line 10 -- specify a full path for the results directory -- all test results
will be stored here -- e.g. /tmp/fp-test-results
Line 11 -- specify the full path to the Unix time program -- ucbtest won't run
without time -- for Gentoo just "emerge time" and the path will be "/usr/bin/time"
Line 17 -- specify the full path to the test directory -- same as in step #1
Line 36 -- enter your CFLAGS here
That's it as far as configuration. Now, from the top directory of the source
just execute:
ucbREADME/linux.sh
The code will take several minutes to compile, execute, and complete. While
the test is running it will spit out its progress to stdout. Upon completion
a brief summary is given:
UCBFAIL indicates problems!
/tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
/tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
/tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
only 11 out of 14 show UCBPASS!
There are expected failures in the trigonometric tests since trigonometric
performance is not specified in IEEE754/854. The failure in powd (double power
function) is also expected. But everything else should have passed.
In my case, the new failure occurs in the cabsd test, which is the absolute
value for complex numbers. I have never seen this error previously and
it may possibly indicate some problem with either glibc or gcc.
The results directory is also a mess (someone should really clean this code up).
In the results directory (see step #4) all detailed test results are contained
in the *.output files.
Anyway, if anyone wants to try this test, the steps have been outlined.
In spite of the messiness, the procedure is really quite simple, and the
ucbtest is a very good test of floating point performance.
Frank Peters
[-- Attachment #2: ucbtest.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 520301 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-25 17:41 [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
@ 2011-06-25 23:54 ` Marc Joliet
2011-06-26 0:22 ` Mark Knecht
2011-06-26 1:28 ` Frank Peters
2011-06-26 3:44 ` [gentoo-amd64] Possible Math Problem - Request For Verification [Solved] Frank Peters
` (2 subsequent siblings)
3 siblings, 2 replies; 31+ messages in thread
From: Marc Joliet @ 2011-06-25 23:54 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
Am Sat, 25 Jun 2011 13:41:11 -0400
schrieb Frank Peters <frank.peters@comcast.net>:
> Hello,
>
[background information]
Huh, I was unaware that GNU (since they're the authors of GCC/GLIBC) ever had
problems in this area. Since I use my machine for numerical tasks, too, I was
interested in seeing whether I would see the same problem.
> The code will take several minutes to compile, execute, and complete. While
> the test is running it will spit out its progress to stdout. Upon completion
> a brief summary is given:
>
> UCBFAIL indicates problems!
> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
> /tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
>
> only 11 out of 14 show UCBPASS!
I ran the tests without any modifications to ucbREADME/linux.sh and don't get
the cabsd failure:
UCBFAIL indicates problems!
/tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
/tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
/tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
only 11 out of 14 show UCBPASS!
Out of curiosity, I ran the test two more times and got the same results.
This machine runs on stable, with a slightly older Athlon64 X2.
> There are expected failures in the trigonometric tests since trigonometric
> performance is not specified in IEEE754/854. The failure in powd (double power
> function) is also expected. But everything else should have passed.
Then according to the results above my machine is apparently OK. (I guess I
really should finally read about IEEE floating point more thoroughly, I've been
planning to do that for a while now.)
[...]
> Frank Peters
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-25 23:54 ` Marc Joliet
@ 2011-06-26 0:22 ` Mark Knecht
2011-06-26 1:10 ` Frank Peters
2011-06-26 1:28 ` Frank Peters
1 sibling, 1 reply; 31+ messages in thread
From: Mark Knecht @ 2011-06-26 0:22 UTC (permalink / raw
To: gentoo-amd64
On Sat, Jun 25, 2011 at 4:54 PM, Marc Joliet <marcec@gmx.de> wrote:
> Am Sat, 25 Jun 2011 13:41:11 -0400
> schrieb Frank Peters <frank.peters@comcast.net>:
>
>> Hello,
>>
> [background information]
>
> Huh, I was unaware that GNU (since they're the authors of GCC/GLIBC) ever had
> problems in this area. Since I use my machine for numerical tasks, too, I was
> interested in seeing whether I would see the same problem.
>
>> The code will take several minutes to compile, execute, and complete. While
>> the test is running it will spit out its progress to stdout. Upon completion
>> a brief summary is given:
>>
>> UCBFAIL indicates problems!
>> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
>> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
>> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
>> /tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
>> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
>>
>> only 11 out of 14 show UCBPASS!
>
> I ran the tests without any modifications to ucbREADME/linux.sh and don't get
> the cabsd failure:
>
> UCBFAIL indicates problems!
> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
> /tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests completed
> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
>
> only 11 out of 14 show UCBPASS!
>
Indeed, it was even manageable for a non-programmer like me.
Like Marc's results I do not see the cabsd failure. This machine is an
Intel i7-980x Extreme running Gentoo 64-bit mostly stable.
UCBFAIL indicates problems!
/tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line
444 for generic
/tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in powd at line
701 for double
/tmp/fp-test-results/clib_DP.output:UCBFAIL clib_DP.output , 25 out of
25 tests completed
/tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line
444 for generic
HTH,
Mark
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 0:22 ` Mark Knecht
@ 2011-06-26 1:10 ` Frank Peters
0 siblings, 0 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 1:10 UTC (permalink / raw
To: gentoo-amd64
On Sat, 25 Jun 2011 17:22:41 -0700
Mark Knecht <markknecht@gmail.com> wrote:
>
> Like Marc's results I do not see the cabsd failure. This machine is an
> Intel i7-980x Extreme running Gentoo 64-bit mostly stable.
>
Thanks for doing these tests. I appreciate it very much. Since both of you
see the same results, my machine must be messed up somewhere and I'll have
to do some digging.
Floating point performance seems to have improved dramatically on Linux
since this test was released in 1995. The original source code (not
my patched version) contains the 1995 test logs from Linux and other
machines and the results are terrible. But other machines (like SunOS)
aced everything.
Another good test is paranoia:
http://people.sc.fsu.edu/~jburkardt/c_src/paranoia/paranoia.html
Linux used to flop during some portions of this test but now it gets
a perfect score.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-25 23:54 ` Marc Joliet
2011-06-26 0:22 ` Mark Knecht
@ 2011-06-26 1:28 ` Frank Peters
1 sibling, 0 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 1:28 UTC (permalink / raw
To: gentoo-amd64
On Sun, 26 Jun 2011 01:54:53 +0200
Marc Joliet <marcec@gmx.de> wrote:
>
> Then according to the results above my machine is apparently OK. (I guess I
> really should finally read about IEEE floating point more thoroughly, I've been
> planning to do that for a while now.)
>
These tests are extreme. The accuracy is supposedly less than 1 ulp
(unit in the last place).
You can check the *output files in the results directory to see
more information on the error. For example, the COS(X) error
file is ccos_DP.output and contains the maximum positive and
maximum negative errors in ulps. On my machine these are 1.567
and -3.74 ulps, so the error is small.
In contrast, the LOG(X) function passes the test but it still shows
errors of 0.532 and -0.531 ulps.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-25 17:41 [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
2011-06-25 23:54 ` Marc Joliet
@ 2011-06-26 3:44 ` Frank Peters
2011-06-26 3:54 ` Mark Knecht
2011-06-26 11:30 ` [gentoo-amd64] Possible Math Problem - Request For Verification Volker Armin Hemmann
2011-06-26 17:04 ` Volker Armin Hemmann
3 siblings, 1 reply; 31+ messages in thread
From: Frank Peters @ 2011-06-26 3:44 UTC (permalink / raw
To: gentoo-amd64
On Sat, 25 Jun 2011 13:41:11 -0400
Frank Peters <frank.peters@comcast.net> wrote:
>
> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
>
The culprit seems to be GCC optimization. If I run the test with either "-O0"
or "-O1" flags I can eliminate the cabsd failure. Using "-O2" or "-O3" will
result in the cabsd error.
However, I've used "-O2" previously and had no problems with this test. Possibly,
some of these new LTO and GRAPHITE capabilities of GCC are to blame, even though
I do not compile the ucbtest with either LTO or GRAPHITE enabled. But GCC has itself
been compiled using LTO and GRAPHITE.
Anyway, thanks for all who actually ran the test on their machines. I was
thinking of filing bug reports with GLIBC and GCC and that would have turned
out to be foolish. I did check the Changelogs for GLIBC and there doesn't seem
to have been any modification of the cabs() code over the last several versions.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-26 3:44 ` [gentoo-amd64] Possible Math Problem - Request For Verification [Solved] Frank Peters
@ 2011-06-26 3:54 ` Mark Knecht
2011-06-26 4:39 ` Frank Peters
0 siblings, 1 reply; 31+ messages in thread
From: Mark Knecht @ 2011-06-26 3:54 UTC (permalink / raw
To: gentoo-amd64
On Sat, Jun 25, 2011 at 8:44 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Sat, 25 Jun 2011 13:41:11 -0400
> Frank Peters <frank.peters@comcast.net> wrote:
>
>>
>> /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
>>
>
> The culprit seems to be GCC optimization. If I run the test with either "-O0"
> or "-O1" flags I can eliminate the cabsd failure. Using "-O2" or "-O3" will
> result in the cabsd error.
>
> However, I've used "-O2" previously and had no problems with this test. Possibly,
> some of these new LTO and GRAPHITE capabilities of GCC are to blame, even though
> I do not compile the ucbtest with either LTO or GRAPHITE enabled. But GCC has itself
> been compiled using LTO and GRAPHITE.
>
> Anyway, thanks for all who actually ran the test on their machines. I was
> thinking of filing bug reports with GLIBC and GCC and that would have turned
> out to be foolish. I did check the Changelogs for GLIBC and there doesn't seem
> to have been any modification of the cabs() code over the last several versions.
>
> Frank Peters
I'm using -O2 here on all my machines. Certainly it isn't that option
that causes a problem for everyone. Sounds like something specific to
your processor revision.
Take care,
Mark
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-26 3:54 ` Mark Knecht
@ 2011-06-26 4:39 ` Frank Peters
2011-06-26 11:33 ` James Cloos
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 4:39 UTC (permalink / raw
To: gentoo-amd64
On Sat, 25 Jun 2011 20:54:10 -0700
Mark Knecht <markknecht@gmail.com> wrote:
>
> I'm using -O2 here on all my machines. Certainly it isn't that option
> that causes a problem for everyone. Sounds like something specific to
> your processor revision.
>
What version of gcc are you using?
I was using gcc-4.5.2, which is the latest on Gentoo. Installing gcc-4.4.5,
the previous version, into a new slot and then using gcc-4.4.5 to run the
ucbtest I do *not* get the cabsd error. So the problem is definitely gcc.
All I need now is for someone to come forward and say that he is using
gcc-4.5.2 and has no problem. Then I'll really start to bang my head.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-26 4:39 ` Frank Peters
@ 2011-06-26 11:33 ` James Cloos
2011-06-26 12:57 ` Mark Knecht
2011-06-26 16:30 ` Barry Schwartz
2 siblings, 0 replies; 31+ messages in thread
From: James Cloos @ 2011-06-26 11:33 UTC (permalink / raw
To: gentoo-amd64
>>>>> "FP" == Frank Peters <frank.peters@comcast.net> writes:
FP> All I need now is for someone to come forward and say that he is using
FP> gcc-4.5.2 and has no problem. Then I'll really start to bang my head.
Using gcc-4.6.0 (compiled with +graphite), using:
-O3 -ggdb3 -march=amdfam10 -ftree-vectorize
a number of the cabs(3) and cpow(3) tests returned (0,0) (for each of
float and double, and each of c and fortran) instead of the correct results.
The sin and cos tests had max errors in the +- 5 ulp range for doubles
and the +- 1.5 range for floats.
Your obsercation that graphite may be to blame is likely correct.
You may be interested in crlibm (correctly rounded lib m):
http://lipforge.ens-lyon.fr/projects/crlibm
http://lipforge.ens-lyon.fr/www/crlibm/
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-26 4:39 ` Frank Peters
2011-06-26 11:33 ` James Cloos
@ 2011-06-26 12:57 ` Mark Knecht
2011-06-26 16:30 ` Barry Schwartz
2 siblings, 0 replies; 31+ messages in thread
From: Mark Knecht @ 2011-06-26 12:57 UTC (permalink / raw
To: gentoo-amd64
On Sat, Jun 25, 2011 at 9:39 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Sat, 25 Jun 2011 20:54:10 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> I'm using -O2 here on all my machines. Certainly it isn't that option
>> that causes a problem for everyone. Sounds like something specific to
>> your processor revision.
>>
>
> What version of gcc are you using?
>
> I was using gcc-4.5.2, which is the latest on Gentoo. Installing gcc-4.4.5,
> the previous version, into a new slot and then using gcc-4.4.5 to run the
> ucbtest I do *not* get the cabsd error. So the problem is definitely gcc.
>
> All I need now is for someone to come forward and say that he is using
> gcc-4.5.2 and has no problem. Then I'll really start to bang my head.
>
> Frank Peters
Currently 4.4.5 here.
- Mark
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification [Solved]
2011-06-26 4:39 ` Frank Peters
2011-06-26 11:33 ` James Cloos
2011-06-26 12:57 ` Mark Knecht
@ 2011-06-26 16:30 ` Barry Schwartz
2 siblings, 0 replies; 31+ messages in thread
From: Barry Schwartz @ 2011-06-26 16:30 UTC (permalink / raw
To: gentoo-amd64
Frank Peters <frank.peters@comcast.net> skribis:
> I was using gcc-4.5.2, which is the latest on Gentoo. Installing gcc-4.4.5,
> the previous version, into a new slot and then using gcc-4.4.5 to run the
> ucbtest I do *not* get the cabsd error. So the problem is definitely gcc.
Especially if you are worried about floating point accuracy, but in
any case, I would be conservative with the compiler. I’m an ~amd64
user but by choice am using gcc-4.4.5 without graphite et al. (and
even though gcc-4.5 is installed in a slot, though again without
graphite et al.).
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-25 17:41 [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
2011-06-25 23:54 ` Marc Joliet
2011-06-26 3:44 ` [gentoo-amd64] Possible Math Problem - Request For Verification [Solved] Frank Peters
@ 2011-06-26 11:30 ` Volker Armin Hemmann
2011-06-26 12:13 ` Volker Armin Hemmann
2011-06-26 16:27 ` [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
2011-06-26 17:04 ` Volker Armin Hemmann
3 siblings, 2 replies; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 11:30 UTC (permalink / raw
To: gentoo-amd64
Believe it or not, this tarball is straight from hell.
1. do not tar-bomb. Pack directories not files.
2. the permissions are a nightmare.
3. I accidentally unpacked in /tmp and your tarball tried to set UTIME and the
permissions of the parent directory. WTF?
4. have you checked that the errors you are seeing are really errors?
Just remember that stupidity about 80bit/64bit/128bit floats all around.
5. http://gcc.gnu.org/wiki/FloatingPointMath
without additional settings gcc 4.5.2:
UCBFAIL indicates problems!
/tmp/usbtest/catan_DP.output:UCBFAIL catan_DP.output.tmp 127
/tmp/usbtest/ccos_DP.output:UCBFAIL ccos_DP.output.tmp 127
/tmp/usbtest/cdiv_DP.output:UCBFAIL cdiv_DP.output
/tmp/usbtest/cexp_DP.output:UCBFAIL cexp_DP.output.tmp 127
/tmp/usbtest/cexpm1_DP.output:UCBFAIL cexpm1_DP.output.tmp 127
/tmp/usbtest/cfindpi_DP.output:UCBFAIL cfindpi_DP.output
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
/tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
completed
/tmp/usbtest/clog1p_DP.output:UCBFAIL clog1p_DP.output.tmp 127
/tmp/usbtest/clog_DP.output:UCBFAIL clog_DP.output.tmp 127
/tmp/usbtest/cmul_DP.output:UCBFAIL cmul_DP.output
/tmp/usbtest/cpar_DP.output:UCBFAIL cpar_DP.output
/tmp/usbtest/cpi_DP.output:UCBFAIL cpi_DP.output
/tmp/usbtest/csin_DP.output:UCBFAIL csin_DP.output.tmp 127
/tmp/usbtest/csqr_DP.output:UCBFAIL csqr_DP.output
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 11:30 ` [gentoo-amd64] Possible Math Problem - Request For Verification Volker Armin Hemmann
@ 2011-06-26 12:13 ` Volker Armin Hemmann
2011-06-26 13:17 ` [gentoo-amd64] unsubscribe Piotr Hosowicz
2011-06-26 16:27 ` [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
1 sibling, 1 reply; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 12:13 UTC (permalink / raw
To: gentoo-amd64
On Sunday 26 June 2011 13:30:41 you wrote:
> Believe it or not, this tarball is straight from hell.
>
> 1. do not tar-bomb. Pack directories not files.
> 2. the permissions are a nightmare.
> 3. I accidentally unpacked in /tmp and your tarball tried to set UTIME and
> the permissions of the parent directory. WTF?
> 4. have you checked that the errors you are seeing are really errors?
> Just remember that stupidity about 80bit/64bit/128bit floats all around.
> 5. http://gcc.gnu.org/wiki/FloatingPointMath
>
> without additional settings gcc 4.5.2:
>
> UCBFAIL indicates problems!
> /tmp/usbtest/catan_DP.output:UCBFAIL catan_DP.output.tmp 127
> /tmp/usbtest/ccos_DP.output:UCBFAIL ccos_DP.output.tmp 127
> /tmp/usbtest/cdiv_DP.output:UCBFAIL cdiv_DP.output
> /tmp/usbtest/cexp_DP.output:UCBFAIL cexp_DP.output.tmp 127
> /tmp/usbtest/cexpm1_DP.output:UCBFAIL cexpm1_DP.output.tmp 127
> /tmp/usbtest/cfindpi_DP.output:UCBFAIL cfindpi_DP.output
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
> /tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
> completed
> /tmp/usbtest/clog1p_DP.output:UCBFAIL clog1p_DP.output.tmp 127
> /tmp/usbtest/clog_DP.output:UCBFAIL clog_DP.output.tmp 127
> /tmp/usbtest/cmul_DP.output:UCBFAIL cmul_DP.output
> /tmp/usbtest/cpar_DP.output:UCBFAIL cpar_DP.output
> /tmp/usbtest/cpi_DP.output:UCBFAIL cpi_DP.output
> /tmp/usbtest/csin_DP.output:UCBFAIL csin_DP.output.tmp 127
> /tmp/usbtest/csqr_DP.output:UCBFAIL csqr_DP.output
ignore those results, were without time.
with time and additional -frounding-math -fsignaling-nans -fno-builtin"
UCBFAIL indicates problems!
/tmp/usbtest/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in powd at line 701 for double
/tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
completed
/tmp/usbtest/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
only 11 out of 14 show UCBPASS!
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* [gentoo-amd64] unsubscribe
2011-06-26 12:13 ` Volker Armin Hemmann
@ 2011-06-26 13:17 ` Piotr Hosowicz
2011-06-26 15:40 ` Dale
0 siblings, 1 reply; 31+ messages in thread
From: Piotr Hosowicz @ 2011-06-26 13:17 UTC (permalink / raw
To: gentoo-amd64
unsubscribe
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] unsubscribe
2011-06-26 13:17 ` [gentoo-amd64] unsubscribe Piotr Hosowicz
@ 2011-06-26 15:40 ` Dale
2011-06-26 17:26 ` Lie Ryan
0 siblings, 1 reply; 31+ messages in thread
From: Dale @ 2011-06-26 15:40 UTC (permalink / raw
To: gentoo-amd64
Piotr Hosowicz wrote:
> unsubscribe
>
>
NO !!! You can't leave. :-P
List-Unsubscribe:<mailto:gentoo-amd64+unsubscribe@lists.gentoo.org>
That may help tho. Just do like you did when you checked in. We MAY let you check out. lol
Dale
:-) :-)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] unsubscribe
2011-06-26 15:40 ` Dale
@ 2011-06-26 17:26 ` Lie Ryan
2011-06-26 17:31 ` Volker Armin Hemmann
2011-06-26 17:43 ` [gentoo-amd64] unsubscribe Dale
0 siblings, 2 replies; 31+ messages in thread
From: Lie Ryan @ 2011-06-26 17:26 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
2011/6/27 Dale <rdalek1967@gmail.com>
> Piotr Hosowicz wrote:
>
>> unsubscribe
>>
>>
>>
> NO !!! You can't leave. :-P
>
> List-Unsubscribe:<mailto:gento**o-amd64+unsubscribe@lists.**gentoo.org<gentoo-amd64%2Bunsubscribe@lists.gentoo.org>
> >
>
> That may help tho. Just do like you did when you checked in. We MAY let
> you check out. lol
>
>
Anyone noticed that this list have a higher than normal tendency to bully
those who tried to unsubscribe and failed?
[-- Attachment #2: Type: text/html, Size: 919 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] unsubscribe
2011-06-26 17:26 ` Lie Ryan
@ 2011-06-26 17:31 ` Volker Armin Hemmann
2011-06-26 17:52 ` Dale
2011-06-27 3:22 ` [gentoo-amd64] unsubscribe Duncan
2011-06-26 17:43 ` [gentoo-amd64] unsubscribe Dale
1 sibling, 2 replies; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 17:31 UTC (permalink / raw
To: gentoo-amd64
On Monday 27 June 2011 03:26:59 Lie Ryan wrote:
> 2011/6/27 Dale <rdalek1967@gmail.com>
>
> > Piotr Hosowicz wrote:
> >> unsubscribe
> >
> > NO !!! You can't leave. :-P
> >
> > List-Unsubscribe:<mailto:gento**o-amd64+unsubscribe@lists.**gentoo.org<g
> > entoo-amd64%2Bunsubscribe@lists.gentoo.org>
> >
> >
> > That may help tho. Just do like you did when you checked in. We MAY
> > let
> > you check out. lol
>
> Anyone noticed that this list have a higher than normal tendency to bully
> those who tried to unsubscribe and failed?
bully? No, make fun of people failing to follow basic instructions? Maybe. But
not more than gentoo-user...
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] unsubscribe
2011-06-26 17:31 ` Volker Armin Hemmann
@ 2011-06-26 17:52 ` Dale
2011-06-27 3:22 ` [gentoo-amd64] unsubscribe Duncan
1 sibling, 0 replies; 31+ messages in thread
From: Dale @ 2011-06-26 17:52 UTC (permalink / raw
To: gentoo-amd64
Volker Armin Hemmann wrote:
> On Monday 27 June 2011 03:26:59 Lie Ryan wrote:
>
>> 2011/6/27 Dale<rdalek1967@gmail.com>
>>
>>
>>> Piotr Hosowicz wrote:
>>>
>>>> unsubscribe
>>>>
>>> NO !!! You can't leave. :-P
>>>
>>> List-Unsubscribe:<mailto:gento**o-amd64+unsubscribe@lists.**gentoo.org<g
>>> entoo-amd64%2Bunsubscribe@lists.gentoo.org>
>>>
>>>
>>> That may help tho. Just do like you did when you checked in. We MAY
>>> let
>>> you check out. lol
>>>
>> Anyone noticed that this list have a higher than normal tendency to bully
>> those who tried to unsubscribe and failed?
>>
> bully? No, make fun of people failing to follow basic instructions? Maybe. But
> not more than gentoo-user...
>
>
I admit, it annoys me but I know that a LOT of mailing lists tell a
person to unsubscribe the way they are trying to do here. Thing is, it
doesn't work here. So, I just try to be funny then provide the needed
info to help the person check out. At least they leave laughing,
hopefully.
At least I didn't post the one with the long instructions that involve
contacting their ISP. ;-) It is funny tho, if you bother to read it.
Dale
:-) :-)
^ permalink raw reply [flat|nested] 31+ messages in thread
* [gentoo-amd64] Re: unsubscribe
2011-06-26 17:31 ` Volker Armin Hemmann
2011-06-26 17:52 ` Dale
@ 2011-06-27 3:22 ` Duncan
1 sibling, 0 replies; 31+ messages in thread
From: Duncan @ 2011-06-27 3:22 UTC (permalink / raw
To: gentoo-amd64
Volker Armin Hemmann posted on Sun, 26 Jun 2011 19:31:27 +0200 as
excerpted:
> On Monday 27 June 2011 03:26:59 Lie Ryan wrote:
>> Anyone noticed that this list have a higher than normal tendency to
>> bully those who tried to unsubscribe and failed?
>
> bully? No, make fun of people failing to follow basic instructions?
> Maybe. But not more than gentoo-user...
Exactly.
1) Instructions are in the headers of every post. A simple view-headers
is all that's required.
2) Instructions are available at the same place they signed up, using a
very similar procedure. It's not rocket science. If they could find and
had the intelligence to subscribe (and even verify their subscription,
the list IS double-opt-in, after all), unless they just had a stroke or
some such, they should still be able to find and have the intelligence to
unsubscribe.
3) Simple reason says that if it's a gentoo list, going to the gentoo
site and looking for the mailing list info would be an appropriate way to
figure out how to unsubscribe. Even if they somehow lost all memory of
the subscription process, simple reason remains the same, and indeed, the
gentoo mailing list info can be found on the site exactly as one could
expect.
4) In this case, all they had to do was read the thread from a couple
days ago, on the same subject. Simple netiquette has always expected
that people follow a list or newsgroup for a bit before they ask what may
well be a FAQ, and the same arguably applies here. They can't even read
the existing thread from the last person who apparently had a stroke or
something after he subscribed, losing all memory of the process, as well
as the basic intelligence to reason where he might find unsubscribe
instructions.
So what's up with these people, anyway? Do they simply not even /care/
if they do it right? They obviously have the ability to follow that
level of instructions or they'd not be subscribed in the first place, and
it's unlikely ALL of them are stroke victims! Are they deliberately
TRYING to look dumb? Maybe they just smoked too many mind altering drugs
and it's now /permanently/ altered?
So yeah, they do get a bit of fun poked at them. But along with that
fun, they usually get the unsubscribe help they're apparently too dumb to
find any of the /normal/ ways, or simply don't /care/ if they're
bothering people by not following the easily available instructions. And
if they don't care if they bother other subscribers, why should other
subscribers care about poking a little fun their way even as they point
them at the door? <shrug>
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] unsubscribe
2011-06-26 17:26 ` Lie Ryan
2011-06-26 17:31 ` Volker Armin Hemmann
@ 2011-06-26 17:43 ` Dale
1 sibling, 0 replies; 31+ messages in thread
From: Dale @ 2011-06-26 17:43 UTC (permalink / raw
To: gentoo-amd64
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Lie Ryan wrote:
> 2011/6/27 Dale <rdalek1967@gmail.com <mailto:rdalek1967@gmail.com>>
>
> Piotr Hosowicz wrote:
>
> unsubscribe
>
>
>
> NO !!! You can't leave. :-P
>
> List-Unsubscribe:<mailto:gentoo-amd64+unsubscribe@lists.gentoo.org
> <mailto:gentoo-amd64%2Bunsubscribe@lists.gentoo.org>>
>
> That may help tho. Just do like you did when you checked in. We
> MAY let you check out. lol
>
>
> Anyone noticed that this list have a higher than normal tendency to
> bully those who tried to unsubscribe and failed?
>
Who is bullying? I certainly haven't.
Dale
:-) :-)
[-- Attachment #2: Type: text/html, Size: 1520 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 11:30 ` [gentoo-amd64] Possible Math Problem - Request For Verification Volker Armin Hemmann
2011-06-26 12:13 ` Volker Armin Hemmann
@ 2011-06-26 16:27 ` Frank Peters
1 sibling, 0 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 16:27 UTC (permalink / raw
To: gentoo-amd64
On Sun, 26 Jun 2011 13:30:41 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> Believe it or not, this tarball is straight from hell.
>
> 1. do not tar-bomb. Pack directories not files.
This one was my fault, but I didn't want to complicate the instructions
for those who may not have much background in these things. That is
why I specified to first create a directory and then to unpack within
that directory.
> 2. the permissions are a nightmare.
> 3. I accidentally unpacked in /tmp and your tarball tried to set UTIME and the
> permissions of the parent directory. WTF?
These are the fault of the original programmers. Such messes were common
back in 1995.
> 4. have you checked that the errors you are seeing are really errors?
> Just remember that stupidity about 80bit/64bit/128bit floats all around.
> 5. http://gcc.gnu.org/wiki/FloatingPointMath
You forgot to mention decimal floating point which is yet another
variant.
This particular test is configured to test double precision (64-bit) in
C only which seems to be the standard on Linux. On Intel Linux at least,
64-bit FP is done entirely in hardware.
The IEEE 754 standard was set way back in 1985. Already it may becoming
obsolete (just like IPv4). Hardware is getting more capable and can
allow for greater precisions. Also, we are now seeing hardware for
decimal floating point which will be a boon to financial software.
It should also be noted that the emerging field of computation
with GPUs does not have any floating point standards at all.
With GPU programming, floating point operations are similar
to the chaos that ruled in the CPU world before IEEE 754.
>
> without additional settings gcc 4.5.2:
>
>
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double
>
Thanks for this! It does seem to verify that gcc-4.5.2 does mangle the code
for this particular test.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-25 17:41 [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
` (2 preceding siblings ...)
2011-06-26 11:30 ` [gentoo-amd64] Possible Math Problem - Request For Verification Volker Armin Hemmann
@ 2011-06-26 17:04 ` Volker Armin Hemmann
2011-06-26 17:17 ` Mark Knecht
2011-06-26 17:36 ` Frank Peters
3 siblings, 2 replies; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 17:04 UTC (permalink / raw
To: gentoo-amd64
On Saturday 25 June 2011 13:41:11 Frank Peters wrote:
> Hello,
>
> Believe it or not, at the very beginning, Linux/GNU had some math problems.
> In particular, it would do somewhat poorly on various floating point tests
> that are available on-line. Because I do mathematical work on my machine,
> I used to regularly evaluate my software using these tests.
>
> However, for the past several years Linux/GNU has gotten nearly perfect
> scores on these same tests and it seemed that glibc and/or gcc had finally
> gotten the math code right. As a result of this, I stopped my regular
> evaluations of the software.
>
> Just recently I decided to run these tests again. I expected to see the
> same nearly perfect scores but, to my surprise, a failure occurred in the
> area of complex number operations. This may not be a very serious failure,
> but it was not present during prior tests and thus it should not be present
> now.
>
> Possibly a fault has crept in somewhere either in glibc or gcc. Because
> I had stopped my regular testing I can't relate the failure to any specific
> version change of either package.
>
> I need to request a verification from any Gentoo users. All that needs to
> be done is run a straightforward software test.
>
> The software is called UCBTEST and is described at http://www.netlib.org/fp/
>
> The source code, however, is ancient Unix (1995) code and must be patched.
> I have created a patched tarball that can run on recent Linux. This file
> is attached as ucbtest.tar.bz2
>
> If one is accustomed to modern GUI software, this code is a mess, but it is
> rather straightforward to implement. Here are the steps:
>
> 1) Create a directory somewhere, e.g. /tmp/fp-test
>
> 2) Unpack the tarball into this directory.
>
> 3) Change into the /tmp/fp-test directory
>
> 4) Modify the ucbREADME/linux.sh file as follows:
>
> Line 10 -- specify a full path for the results directory -- all test results
> will be stored here -- e.g. /tmp/fp-test-results
>
> Line 11 -- specify the full path to the Unix time program -- ucbtest won't
> run without time -- for Gentoo just "emerge time" and the path will be
> "/usr/bin/time"
>
> Line 17 -- specify the full path to the test directory -- same as in step #1
>
> Line 36 -- enter your CFLAGS here
>
> That's it as far as configuration. Now, from the top directory of the
> source just execute:
>
> ucbREADME/linux.sh
>
> The code will take several minutes to compile, execute, and complete. While
> the test is running it will spit out its progress to stdout. Upon
> completion a brief summary is given:
>
> UCBFAIL indicates problems!
> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444
> for generic /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd
> at line 701 for double /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL
> in powd at line 701 for double /tmp/fp-test-results/clib_DP.output:UCBFAIL
> clib_DP.output , 25 out of 25 tests completed
> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444
> for generic
>
> only 11 out of 14 show UCBPASS!
>
>
> There are expected failures in the trigonometric tests since trigonometric
> performance is not specified in IEEE754/854. The failure in powd (double
> power function) is also expected. But everything else should have passed.
>
> In my case, the new failure occurs in the cabsd test, which is the absolute
> value for complex numbers. I have never seen this error previously and
> it may possibly indicate some problem with either glibc or gcc.
>
> The results directory is also a mess (someone should really clean this code
> up). In the results directory (see step #4) all detailed test results are
> contained in the *.output files.
>
> Anyway, if anyone wants to try this test, the steps have been outlined.
> In spite of the messiness, the procedure is really quite simple, and the
> ucbtest is a very good test of floating point performance.
>
> Frank Peters
btw, have you tried ekopath? The compiler entered portage shortly after its
open sourcing? Maybe it is more correct. According to some it is faster than
gcc when it comes to math heavy workloads.
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 17:04 ` Volker Armin Hemmann
@ 2011-06-26 17:17 ` Mark Knecht
2011-06-26 17:36 ` Frank Peters
1 sibling, 0 replies; 31+ messages in thread
From: Mark Knecht @ 2011-06-26 17:17 UTC (permalink / raw
To: gentoo-amd64
On Sun, Jun 26, 2011 at 10:04 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
<SNIP>
>
> btw, have you tried ekopath? The compiler entered portage shortly after its
> open sourcing? Maybe it is more correct. According to some it is faster than
> gcc when it comes to math heavy workloads.
> --
Interesting. I hadn't heard about this. Thanks.
- Mark
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 17:04 ` Volker Armin Hemmann
2011-06-26 17:17 ` Mark Knecht
@ 2011-06-26 17:36 ` Frank Peters
2011-06-26 17:45 ` Volker Armin Hemmann
` (2 more replies)
1 sibling, 3 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 17:36 UTC (permalink / raw
To: gentoo-amd64
On Sun, 26 Jun 2011 19:04:48 +0200
Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
>
> btw, have you tried ekopath? The compiler entered portage shortly after its
> open sourcing? Maybe it is more correct. According to some it is faster than
> gcc when it comes to math heavy workloads.
> --
I took a look at it in the past and it was proprietary. But looking
again I see that it is in portage as a binary package. I'll check it
out for sure.
The Intel compiler was always an interest of mine but it can run
on only Gentoo multilib.
Then there is LLVM which I am not sure about. I'll have to research
this one.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 17:36 ` Frank Peters
@ 2011-06-26 17:45 ` Volker Armin Hemmann
2011-06-26 17:54 ` Barry Schwartz
2011-06-26 19:01 ` Volker Armin Hemmann
2 siblings, 0 replies; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 17:45 UTC (permalink / raw
To: gentoo-amd64
On Sunday 26 June 2011 13:36:22 Frank Peters wrote:
> On Sun, 26 Jun 2011 19:04:48 +0200
>
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > btw, have you tried ekopath? The compiler entered portage shortly after
> > its open sourcing? Maybe it is more correct. According to some it is
> > faster than gcc when it comes to math heavy workloads.
>
> I took a look at it in the past and it was proprietary. But looking
> again I see that it is in portage as a binary package. I'll check it
> out for sure.
>
> The Intel compiler was always an interest of mine but it can run
> on only Gentoo multilib.
>
> Then there is LLVM which I am not sure about. I'll have to research
> this one.
>
> Frank Peters
ekopath was opensourced and put under gpl only weeks ago.
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 17:36 ` Frank Peters
2011-06-26 17:45 ` Volker Armin Hemmann
@ 2011-06-26 17:54 ` Barry Schwartz
2011-06-26 19:01 ` Volker Armin Hemmann
2 siblings, 0 replies; 31+ messages in thread
From: Barry Schwartz @ 2011-06-26 17:54 UTC (permalink / raw
To: gentoo-amd64
Frank Peters <frank.peters@comcast.net> skribis:
> Then there is LLVM which I am not sure about. I'll have to research
> this one.
Hmm. I see it has a USE=ocaml. I’ll have to investigate it, too. :)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 17:36 ` Frank Peters
2011-06-26 17:45 ` Volker Armin Hemmann
2011-06-26 17:54 ` Barry Schwartz
@ 2011-06-26 19:01 ` Volker Armin Hemmann
2011-06-26 19:21 ` Barry Schwartz
2 siblings, 1 reply; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 19:01 UTC (permalink / raw
To: gentoo-amd64
On Sunday 26 June 2011 13:36:22 Frank Peters wrote:
> On Sun, 26 Jun 2011 19:04:48 +0200
>
> Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > btw, have you tried ekopath? The compiler entered portage shortly after
> > its open sourcing? Maybe it is more correct. According to some it is
> > faster than gcc when it comes to math heavy workloads.
>
> I took a look at it in the past and it was proprietary. But looking
> again I see that it is in portage as a binary package. I'll check it
> out for sure.
>
> The Intel compiler was always an interest of mine but it can run
> on only Gentoo multilib.
>
> Then there is LLVM which I am not sure about. I'll have to research
> this one.
>
> Frank Peters
ok, I tried ekopath:
UCBFAIL indicates problems!
/tmp/usbtest/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
/tmp/usbtest/cexp_DP.output: ucbtest UCBFAIL in EXP(X) at line 444 for generic
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in ceild at line 701 for double
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in coshd at line 701 for double
/tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in floord at line 701 for double
/tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
completed
/tmp/usbtest/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
only 10 out of 14 show UCBPASS!
options:
make="make"
cpp="cpp -traditional"
#cc=gcc
cc=/opt/ekopath-bin-4.0.10_pre20110612/bin/pathcc
#fcc=gfortran
f77=/opt/ekopath-bin-4.0.10_pre20110612/bin/pathf90
opts="-m64 -O2 -pipe -march=k8"
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 19:01 ` Volker Armin Hemmann
@ 2011-06-26 19:21 ` Barry Schwartz
2011-06-26 19:31 ` Volker Armin Hemmann
2011-06-26 19:49 ` Mark Knecht
0 siblings, 2 replies; 31+ messages in thread
From: Barry Schwartz @ 2011-06-26 19:21 UTC (permalink / raw
To: gentoo-amd64
Volker Armin Hemmann <volkerarmin@googlemail.com> skribis:
> ok, I tried ekopath:
>
> UCBFAIL indicates problems!
> /tmp/usbtest/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
> /tmp/usbtest/cexp_DP.output: ucbtest UCBFAIL in EXP(X) at line 444 for generic
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in ceild at line 701 for double
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in coshd at line 701 for double
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in floord at line 701 for double
> /tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
> completed
> /tmp/usbtest/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
>
> only 10 out of 14 show UCBPASS!
That must be what they mean by "Industry proven robustness and
quality"
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 19:21 ` Barry Schwartz
@ 2011-06-26 19:31 ` Volker Armin Hemmann
2011-06-26 19:49 ` Mark Knecht
1 sibling, 0 replies; 31+ messages in thread
From: Volker Armin Hemmann @ 2011-06-26 19:31 UTC (permalink / raw
To: gentoo-amd64
On Sunday 26 June 2011 14:21:11 Barry Schwartz wrote:
> Volker Armin Hemmann <volkerarmin@googlemail.com> skribis:
> > ok, I tried ekopath:
> >
> > UCBFAIL indicates problems!
> > /tmp/usbtest/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for
> > generic /tmp/usbtest/cexp_DP.output: ucbtest UCBFAIL in EXP(X) at line
> > 444 for generic /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in ceild
> > at line 701 for double /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in
> > coshd at line 701 for double /tmp/usbtest/clib_DP.output: ucbtest
> > UCBFAIL in floord at line 701 for double
> > /tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
> > completed
> > /tmp/usbtest/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for
> > generic
> >
> > only 10 out of 14 show UCBPASS!
>
> That must be what they mean by "Industry proven robustness and
> quality"
no, that probably means that the 'problem' is
either not a problem at all. Failing some test and not being accurate or being
wrong or even not following some standard are very different thins
or not caused by the compilers but something else. Like libc, libm, etc.
--
#163933
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 19:21 ` Barry Schwartz
2011-06-26 19:31 ` Volker Armin Hemmann
@ 2011-06-26 19:49 ` Mark Knecht
2011-06-26 20:33 ` Frank Peters
1 sibling, 1 reply; 31+ messages in thread
From: Mark Knecht @ 2011-06-26 19:49 UTC (permalink / raw
To: gentoo-amd64
On Sun, Jun 26, 2011 at 12:21 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Volker Armin Hemmann <volkerarmin@googlemail.com> skribis:
>> ok, I tried ekopath:
>>
>> UCBFAIL indicates problems!
>> /tmp/usbtest/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 for generic
>> /tmp/usbtest/cexp_DP.output: ucbtest UCBFAIL in EXP(X) at line 444 for generic
>> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in ceild at line 701 for double
>> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in coshd at line 701 for double
>> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in floord at line 701 for double
>> /tmp/usbtest/clib_DP.output:UCBFAIL clib_DP.output , 25 out of 25 tests
>> completed
>> /tmp/usbtest/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 for generic
>>
>> only 10 out of 14 show UCBPASS!
>
> That must be what they mean by "Industry proven robustness and
> quality"
Do you have any info about _any_ system passing this 100% successfully?
What about that the code itself might have a bug in it?
- Mark
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gentoo-amd64] Possible Math Problem - Request For Verification
2011-06-26 19:49 ` Mark Knecht
@ 2011-06-26 20:33 ` Frank Peters
0 siblings, 0 replies; 31+ messages in thread
From: Frank Peters @ 2011-06-26 20:33 UTC (permalink / raw
To: gentoo-amd64
On Sun, 26 Jun 2011 12:49:03 -0700
Mark Knecht <markknecht@gmail.com> wrote:
>
> Do you have any info about _any_ system passing this 100% successfully?
>
If you look at the log files for various systems that are found in the
original source code (http://www.netlib.org/fp) you will see that SunOS
passed 100% but SunOS with GCC did not. These results were from 1995.
> What about that the code itself might have a bug in it?
The package is not documented at all, but the few references to the ucbtest
don't find any fault with it.
However, this thread has strayed a little from the main theme. I just
happened to notice that the cabsd routines failed on my machine and
was wondering what could have caused the failure. It turns out that
the latest GCC somehow produces bad code.
The ucbtest itself should not be of much concern. The failures for
the trig functions, I assume, are because the error is greater than
1 ulp and the upper bound for these errors is usually stated to be
1 ulp (although this is not part of the IEEE standard).
But failures for ceil(), floor(), and cosh() do seem to be of some concern.
The file clib_DP.output should be examined to see what actually happened
with those functions.
There are other FP test packages available, although not many, and most
of these are without documentation and with messy source code as well.
Someone or some organization needs to write a comprehensive, well documented,
and neat test package for FP. The problem is that FP is a very abstruse area
that few people want to bother with and that even fewer possess the
qualifications for.
Frank Peters
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2011-06-27 3:24 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-25 17:41 [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
2011-06-25 23:54 ` Marc Joliet
2011-06-26 0:22 ` Mark Knecht
2011-06-26 1:10 ` Frank Peters
2011-06-26 1:28 ` Frank Peters
2011-06-26 3:44 ` [gentoo-amd64] Possible Math Problem - Request For Verification [Solved] Frank Peters
2011-06-26 3:54 ` Mark Knecht
2011-06-26 4:39 ` Frank Peters
2011-06-26 11:33 ` James Cloos
2011-06-26 12:57 ` Mark Knecht
2011-06-26 16:30 ` Barry Schwartz
2011-06-26 11:30 ` [gentoo-amd64] Possible Math Problem - Request For Verification Volker Armin Hemmann
2011-06-26 12:13 ` Volker Armin Hemmann
2011-06-26 13:17 ` [gentoo-amd64] unsubscribe Piotr Hosowicz
2011-06-26 15:40 ` Dale
2011-06-26 17:26 ` Lie Ryan
2011-06-26 17:31 ` Volker Armin Hemmann
2011-06-26 17:52 ` Dale
2011-06-27 3:22 ` [gentoo-amd64] unsubscribe Duncan
2011-06-26 17:43 ` [gentoo-amd64] unsubscribe Dale
2011-06-26 16:27 ` [gentoo-amd64] Possible Math Problem - Request For Verification Frank Peters
2011-06-26 17:04 ` Volker Armin Hemmann
2011-06-26 17:17 ` Mark Knecht
2011-06-26 17:36 ` Frank Peters
2011-06-26 17:45 ` Volker Armin Hemmann
2011-06-26 17:54 ` Barry Schwartz
2011-06-26 19:01 ` Volker Armin Hemmann
2011-06-26 19:21 ` Barry Schwartz
2011-06-26 19:31 ` Volker Armin Hemmann
2011-06-26 19:49 ` Mark Knecht
2011-06-26 20:33 ` Frank Peters
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox