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.
