-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"pathological example" fails on i386 architecture #33
Comments
Thanks for finding this.
Can you tell me the exact CPU model and also which blas library you've
got R linked to?
In the short term though, I propose simply disabling this test on
32-bit systems...does that seem reasonable?
…On 3/20/18, Graham Inggs ***@***.***> wrote:
In case it helps, printing **l$d** at the point of failure produces the
following on i386:
```
[1] 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000
[8] 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 0.9999999 0.9999996
[15] 0.9999978 0.9999895 0.9999511 0.9997809 0.9990578 0.9961445
```
...and the following on all other architectures (x86_64, ARM, POWER,
etc.):
```
[1] 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000
[8] 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 0.9999999
[15] 0.9999996 0.9999978 0.9999895 0.9999511 0.9997809 0.9990578
```
I think this may be caused by i386 using 80-bit floating point precision
internally, while other architectures use 64-bit.
Is it possible to adjust this test so that it would pass under both
conditions?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#33
|
The CPU is an Intel Core i7-2600 running the 32-bit version of Ubuntu 18.04. The test passes on the same CPU running the 64-bit version. I believe that R is linked to OpenBLAS is 0.2.20. In case it is helpful, you can click on the links on the following page to see passing and failing test logs on the various architectures tested in Ubuntu: The test does pass on ARM 32-bit systems, so I'd rather not disable the test there if possible. |
Lowering the precision of the test as below worked for me, but is the test still meaningful with this change?
|
Is it possible for you to check the latest version 2.3.2 that's on
cran? Is that also failing?
…On 3/20/18, Graham Inggs ***@***.***> wrote:
Lowering the precision of the test as below worked for me, but is the test
still meaningful with this change?
```
--- a/tests/test.R
+++ b/tests/test.R
@@ -148,7 +148,7 @@
x <- tprolate(512)
set.seed(1)
l <- irlba(x, nv=20, fastpath=FAST)
- if (isTRUE(max(abs(l$d - 1)) > 1e-3))
+ if (isTRUE(max(abs(l$d - 1)) > 1e-2))
{
stop("Failed tprolate test fastpath=", FAST)
}
```
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#33 (comment)
|
Aha, I see it's failing there with Intel MKL too (2.3.2). Investigating... |
In case it helps, printing l$d at the point of failure produces the following on i386:
...and the following on all other architectures (x86_64, ARM, POWER, etc.):
I think this may be caused by i386 using 80-bit floating point precision internally, while other architectures use 64-bit.
Is it possible to adjust this test so that it would pass under both conditions?
The text was updated successfully, but these errors were encountered: