lme() разные результаты, каждый из которых работает под революцией R (MKL виноват?)

Question

Обновление (август 2014): Я так и не дошел до конца и никогда не получал отзывов на форуме Revolution. Однако этот вопрос, как представляется, был зафиксирован в Revolution R 7.2 (с R 3.0.3, опять же академическая версия). Я проверил тест lme() ниже нескольких сотен раз, все они дали равные результаты, как и ожидалось. [конец обновления]

Я только что установил академическую версию Revolution R 7.0 (R 3.0.2) на новый ПК и получаю странные результаты для кода ниже. Каждый раз, когда код запускается, он дает разные результаты. В CRAN-R результат всегда один и тот же (как я думаю, он должен быть). Фрагмент кода из теста 527 от test.data.table() версии 1.8.10, который указал мне на ошибку.

library(nlme) 
all.equal(lme(distance ~ age, data=Orthodont), lme(distance ~ age, data=Orthodont)) 

Я получаю что-то вроде ниже, но каждый раз каждый раз.

> all.equal(lme(distance ~ age, data=Orthodont), lme(distance ~ age, data=Orthodont)) 
[1] "Component 4: Component 2: Component 1: Mean relative difference: 1.774149e-08" 
[2] "Component 7: Mean relative difference: 0.0003335902" 

«удовольствие» Дело в том, что nlme пакета (из которых lme() является частью) сам по себе является идентичной, я удалил и переустановил, чтобы быть уверенными (nlme_3.1-113.zip файл пакета является бит для бит-бит идентичны).

Я еще недостаточно знаю, чтобы идти под капот. Любые указатели или идеи будут оценены. Я также разместил на форуме Revolutions, но он кажется гораздо менее заполненным, чем здесь ...

Это 64-разрядная версия Windows 8.1, 64-разрядная R, а также процессор Intel i7-4770, если это имеет значение. И текущая версия Revolution R (R 3.0.2), и предыдущая (2.15.3) производят неожиданное (для меня) поведение. CRAN-R 3.0.1 и 3.0.2 дают идентичные результаты.

sessionInfo() выход для Revolution R:

> sessionInfo() 
R version 3.0.2 (2013-09-25) 
Platform: x86_64-w64-mingw32/x64 (64-bit) 

locale: 
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252 
[3] LC_MONETARY=English_United States.1252 
[4] LC_NUMERIC=C       
[5] LC_TIME=English_United States.1252  

attached base packages: 
[1] stats  graphics grDevices utils  datasets methods base  

other attached packages: 
[1] nlme_3.1-113  Revobase_7.0.0 RevoMods_7.0.0 RevoScaleR_7.0.0 
[5] lattice_0.20-24 rpart_4.1-3  

loaded via a namespace (and not attached): 
[1] codetools_0.2-8 foreach_1.4.1  grid_3.0.2  iterators_1.0.6 
[5] pkgXMLBuilder_1.0 revoIpe_1.0  tools_3.0.2  XML_3.98-1.1 

UPDATE 1: я прослеживал вопрос (после некоторых указателей от ответа & комментариев ниже) с тем, что использование Revolution R библиотека Intel MKL BLAS. Если я переключусь на библиотеку BLAS, поставляемую CRAN, проблемы исчезнут. (Примечание: я не знаю достаточно для компиляции R, поэтому я не тестировал OpenBLAS и другие альтернативы. В Revolution R это просто вопрос переименования двух dll-s.).

Казалось бы, другие люди получают inconsistent results with MKL as well. Различия в пределах толерантности машины, то есть all.equal() имеет значение TRUE, а identical() - FALSE. Различные результаты в моем случае кажутся значимо большими.

Я опубликовал эту проблему на форуме Revolution R и обновится здесь, если я получу ответ. Полагаю, в этот момент мой вопрос должен быть изменен как «когда использовать MKL BLAS и когда CRAN-R BLAS». Это не проблема скорости (*), а последовательные и правильные результаты. Я потрачу еще некоторое время на поиск стандартного набора тестов (не уверенный в терминологии здесь?), Чтобы проверить выход R в отношении результата с точностью до правильной. Это одна из вещей, которые мне нравятся в data.table, у нее есть собственный тест, видимый конечному пользователю. Я знаю, что я не должен ожидать, что один тест будет охватывать все (или даже большинство) пакетов, но, по крайней мере, что-то покрывающее базовую функциональность.

(*) Скорость зависит от конкретного рабочего процесса. В этом конкретном случае CRAN BLAS быстрее, чем MKL (оба работают однопоточно). В другой работе Revolution R был значительно быстрее, поэтому я изучаю его.

Answer 1

При предположении, Revo R параллелирует его по ядрам ЦП, а арифметика в рекомбинации параллельных вещей не всегда ассоциативна. Другими словами, это зависит от порядка операций. Если потоки заканчиваются в разных порядках, что может произойти, если ядра должны сделать что-то еще, тогда результаты будут добавлены в другом порядке и (a + b) + c не всегда равны + (b + c) в плавающих point ...

Чтобы проверить, есть ли способ, которым вы можете сказать Revo R, использовать только одно ядро ​​процессора?