Wow. You are entirely correct. I would not have been able to pinpoint the problem, or how to test it. Thank you.
I am unhappy you are right, since these are the fast workstations I use for all of my heavy-duty analysis, and it's not even *possible* to rerun everything. Oh dear. Here, with the options you suggested, it produces the expected results: # env OPENBLAS_CORETYPE=Haswell R --vanilla > white <- c(x = 0.953205712549377, 1, y = 1.08538438164692) > red10.rgb <- structure(c(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0), .Dim = c(10L, 3L), .Dimnames = list( > NULL, c("r", "g", "b"))) > convertColor(red10.rgb, from = "sRGB", to = "Lab") L a b [1,] 53.48418 80.01027 67.38407 [2,] 53.48418 80.01027 67.38407 [3,] 53.48418 80.01027 67.38407 [4,] 53.48418 80.01027 67.38407 [5,] 53.48418 80.01027 67.38407 [6,] 53.48418 80.01027 67.38407 [7,] 53.48418 80.01027 67.38407 [8,] 53.48418 80.01027 67.38407 [9,] 53.48418 80.01027 67.38407 [10,] 53.48418 80.01027 67.38407 > red10.rgb %*% as.list(environment(grDevices::colorspaces$sRGB$toXYZ))$M [,1] [,2] [,3] [1,] 0.4168213 0.2149235 0.0195385 [2,] 0.4168213 0.2149235 0.0195385 [3,] 0.4168213 0.2149235 0.0195385 [4,] 0.4168213 0.2149235 0.0195385 [5,] 0.4168213 0.2149235 0.0195385 [6,] 0.4168213 0.2149235 0.0195385 [7,] 0.4168213 0.2149235 0.0195385 [8,] 0.4168213 0.2149235 0.0195385 [9,] 0.4168213 0.2149235 0.0195385 [10,] 0.4168213 0.2149235 0.0195385 On Thu, Jul 18, 2019 at 1:59 PM Ivan Krylov <krylov.r...@gmail.com> wrote: > > On Thu, 18 Jul 2019 13:30:09 -0400 > Sarah Goslee <sarah.gos...@gmail.com> wrote: > > > I'm not even remotely a hardware expert: if the difference is due to > > changes in the instruction set, I assume that has potential > > consequences for other things, and I just happened to spot it in this > > particular case because it's visualization-based? (Yikes.) > > Yes, this might be bad. I have heard about OpenBLAS (specifically, the > matrix product routine) misbehaving on certain AVX-512 capable > processors, so much that they had to disable some optimizations in > 0.3.6 [*], which you already have installed. Still, would `env > OPENBLAS_CORETYPE=Haswell R --vanilla` give a better result? > > > As it says in my first email (but way at the bottom), I'd already > > gotten as far as locating the problem in this line from > > grDevices::convertColor() > > > > xyz <- from$toXYZ(color, from.ref.white) > > Thanks for confirming this! It felt that I had to make sure, since the > behaviour we observe is so confusing. > > > > (red.xyz <- grDevices::colorspaces$sRGB$toXYZ(red.rgb, > > > white.point))[1,] > > [1] 0.7733981 0.9280769 0.1383974 > > > # [1] 0.4168213 0.2149235 0.0195385 > > One last check: would > > red.rgb %*% as.list(environment(grDevices::colorspaces$sRGB$toXYZ))$M > > still produce different results on your computers? > > > blas.x86_64 3.8.0-12.fc30 > > openblas.x86_64 0.3.6-2.fc30 > > I do not know enough about Fedora's "alternatives" system, but it does > look like R is using OpenBLAS. > > > A: working > > Model name: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz > > > B: not working > > Model name: Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz > > Again, this points in the direction of OpenBLAS not doing AVX-512 math > properly. Let's hope that OPENBLAS_CORETYPE=Haswell solves it. > > -- > Best regards, > Ivan > > [*] > https://github.com/xianyi/OpenBLAS/issues/1955 > https://github.com/xianyi/OpenBLAS/issues/2029 > https://github.com/xianyi/OpenBLAS/issues/2168 > https://github.com/xianyi/OpenBLAS/issues/2182 -- Sarah Goslee (she/her) http://www.numberwright.com ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.