R: locpoly неправильно возвращает NaN

Выполнение следующего кода дает мне NaN:

library(KernSmooth) 
x <- c(5.84155992364115, 1.55292112974119, 0.0349665318792623, 3.93053647398094,
       3.42790577684633, 2.9715553006801, 0.837108410045353, 2.872476865277, 
       3.89232548092257, 0.206399650539628) 
y <- c(0.141415317472329, 1.34799648955049, 0.0297566221758204, 
       -0.966736679061812, 0.246306732122746, 0.557982376254723, 
       0.740542828791083, 0.162336127802977, -0.428804158514744, 
       0.691280978689863) 

locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

я получил

[1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603
[7]  0.1425592 -0.3600028 -0.7840411 -1.0517612 -1.2690134        NaN

На другом компьютере я получаю то же самое, за исключением того, что я получаю -0.7270521 вместо NaN. Я предполагаю, что большинство из вас также получат это. Итак, вопрос в том, как мне исправить мою сломанную систему? Это связано с моим LAPACK или LIBBLAS?

Обратите внимание, что на обоих компьютерах, упомянутых выше, используется Ubuntu. Тот, который дал NaN, использует Ubuntu 13.10, тот, который дал номер, — 12.04.

РЕДАКТИРОВАТЬ:

Мое новое подозрение заключается в том, что это проблема вычисления с плавающей запятой: локальная полиномиальная регрессия — это просто взвешенная линейная регрессия, где веса уменьшаются по мере удаления точки от точки оценки, в данном случае 5,84. Следует отметить, что полоса пропускания мала, поэтому первая мысль состоит в том, что в пределах полосы пропускания нет точек. Однако locpoly использует ядро ​​Гаусса, так что все точки имеют строго положительный вес. Я предполагаю, что веса настолько малы, что округление или вычисление с плавающей запятой могут быть проблемой. Я не уверен, как это исправить.


r ubuntu lapack blas
person Xu Wang    schedule 16.03.2014    source источник
comment
Я также получаю NaN, работая под Linux.   -  person Rich Scriven    schedule 16.03.2014
comment
@RScriv спасибо за подтверждение. Думаю, я не единственный. Я тоже на линуксе. Я обновил информацию о своей ОС выше.   -  person Xu Wang    schedule 16.03.2014
comment
Я получаю NaN OSX R 3.03. Теперь, прежде чем мы все погрузимся в LAPACK, может кто-нибудь подтвердить, какое значение является правильным?   -  person Carl Witthoft    schedule 16.03.2014
comment
То же самое. R3.0.3 на OS X 10.9.2, и я также получаю NaN.   -  person hrbrmstr    schedule 22.03.2014

Ответы (5)


arrow_upward
3
arrow_downward

Если я использую Windows 7 и R 3.0, я получаю:

 > locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]
 [1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947
 [6]  0.4441603  0.1425592 -0.3600028 -0.7840411 -1.0517612
[11] -1.2690134 -2.8078788

Так что вашей проблемы там не было. Однако, если я использую R 3.0 в Ubuntu 13.04 (GNU/Linux 3.8.0-23-generic x86_64), я получаю:

 > locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

 [1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603
 [7]  0.1425592 -0.3600028 -0.7840411 -1.0517612 -1.2690134        NaN

Я попытался поэкспериментировать и смог получить числа, очень похожие на те, что я получил в Windows 7, используя:

> locpoly(round(x,3), round(y,3), bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

 [1]  0.3032295  0.6459197  0.9533132  1.1121400  0.8118960  0.4437407
 [7]  0.1422658 -0.3604210 -0.7848982 -1.0531299 -1.2710219 -0.7269588

Поэтому я надеюсь, что смогу решить вашу вторую проблему.

Чтобы понять, почему я смог получить не-NaN-ответ с Windows, но не с Ubuntu, мы можем посмотреть http://cran.r-project.org/web/packages/KernSmooth/index..html и обратите внимание на следующее:

Двоичный файл для MacOS X: KernSmooth_2.23-10.tgz Двоичный файл для Windows: KernSmooth_2.23-11.zip

Естественно, есть две разные версии, но двоичный файл Windows на одну версию дальше, чем двоичный файл MacOS X. Я проверил исходный код функций в Ubuntu и Windows, и они выглядят одинаково. Тем не менее, я нашел это различия округления в Windows и Unix на основе системы в sprintf, показывающей, что существует ошибка, связанная с различиями в округлении между unix и windows. Хотя это было задано 3 года назад. Поэтому я бы сказал, что разница может заключаться в ОС или версии для KernSmooth (склоняюсь к ОС, поскольку другие также сталкивались с этой проблемой)

person James Tobin    schedule 25.03.2014
comment
Это не отвечает на вопрос. Если вы используете round, но указываете bandwidth = 0.3821232, проблема возвращается. round просто эффективно увеличивает пропускную способность (в этом конкретном примере). Тем не менее, спасибо за ваши усилия, и я думаю, что вы дали больше всего информации, поэтому я приму ее. - person Xu Wang; 27.03.2014
comment
Спасибо, что выбрали мой ответ. Мне жаль, что я не полностью ответил на ваши вопросы, но это лучшее, что я мог сделать. Последним шагом, который вы можете сделать, было бы написать Брайану Рипли по электронной почте ‹[email protected]›, который поддерживает пакет. - person James Tobin; 01.04.2014

arrow_upward
4
arrow_downward

Не ответ, но хотел опубликовать график. Я до сих пор не понимаю, что вы ожидали получить от locpoly, но вот оно.

Rgames> foo<-locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)
Rgames> foo
$x
 [1] 0.03496653 0.56283866 1.09071078 1.61858291 2.14645504 2.67432716
 [7] 3.20219929 3.73007142 4.25794354 4.78581567 5.31368780 5.84155992

$y
 [1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603
 [7]  0.1425592 -0.3600028 -0.7840411 -1.0517612 -1.2690134        NaN

введите здесь описание изображенияЯ подозреваю, что последняя крайняя правая точка расходится для используемых параметров подгонки, и это было глупой удачей, что вы получили значение, отличное от NaN, под любой ОС.

person Carl Witthoft    schedule 16.03.2014
comment
Спасибо за ваши мысли, Карл. У вас есть чем подтвердить это подозрение? (Я определенно не имею в виду это как вызов, просто любопытно, есть ли у вас понимание.) Что вы подразумеваете под расхождением здесь? Вы заставили меня задуматься о потенциальных проблемах, и я предполагаю, что это проблема вычисления с плавающей запятой. Я добавлю свои догадки с попыткой интуиции к моему вопросу. - person Xu Wang; 17.03.2014
comment
@XuWang Тенденция красных точек (locpoly outout) явно направлена ​​вниз, в сторону от последнего входного значения. Это заставляет меня поверить, что функция подгонки либо игнорирует, либо не может вернуться к входным данным. - person Carl Witthoft; 17.03.2014
comment
Я вижу твою интуицию. Спасибо за объяснение. - person Xu Wang; 17.03.2014

arrow_upward
1
arrow_downward

У меня Windows 7, R 3.0.1.

Это похоже на проблему с плавающей запятой, но из-за max(x): изменение первой записи в x (которой оказывается max) с 5.84155992364115 на 5.841559923 ваш NaN становится Inf, а на 5.84155992 ваш NaN становится -0.7261049.

Кроме того, установка параметра truncate на FALSE значительно меняет вывод:

locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1, truncate=F)[['y']]
[1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603  0.1425592 -0.3600028 -0.7449278 -0.3872891 -0.1235228  0.1414153

чего я не ожидал, поскольку вы не указали range.x.

person djas    schedule 23.03.2014

arrow_upward
1
arrow_downward

Вы запрашиваете локальный многочлен степени 1 (требуется минимум 2 точки для соответствия), и есть только одна точка, локальная для 5,84155992364115. Реальный вопрос в том, почему он не выдал вам хорошую ошибку, говорящую вам увеличить пропускную способность. Поднимите его до 0,5 и все заработает.

person pdb    schedule 25.03.2014
comment
Локальные полиномиальные регрессии взвешивают каждое наблюдение, если используется нормальное ядро. Дело в том, что вес очень мал. Но в теории эта регрессия задана правильно. Для хорошей справки прочитайте amazon.com/Local-Polynomial- Моделирование-его-приложений/dp/ - person Xu Wang; 27.03.2014
comment
Обычно программное обеспечение добавляет точку отсечения, за которой ядро ​​устанавливается на 0. В случае нормальной плотности 4 сигма звучит правильно. Я не умею читать FORTRAN или C, поэтому я не смотрел на фактическую функцию, чтобы увидеть, применяется ли такая точка отсечения, но вы можете проверить это на других примерах. Попробуйте добавить -14, -15, -17,5, -19,5, -20,5, -21,5 к вашему X и 1:6 к вашему Y, и вы получите ошибку, которая жалуется на BW. Опять же, это то, что я ожидал здесь. - person pdb; 27.03.2014

arrow_upward
0
arrow_downward

Я хотел бы выразиться по-другому,

Я не являюсь постоянным пользователем Ubuntu, но знаю NaN (не число), который был запущен Java!

Сначала я скажу обновить Lapack и убедиться, что все файлы установлены правильно (Недавняя ошибка)

если какой-то файл отсутствует и номер плохо обрабатывается.

Разделение на ноль (или неверный результат из-за отсутствия библиотеки) может привести к результату NAN.

Я не думаю, что у Ubuntu есть какие-то проблемы с этим.

Пожалуйста, укажите версию LAPACK для лучшего понимания (включая Ubuntu 32 или 64 бит, а LAPACK 32 или 64 бит)

Я надеюсь, это поможет.

person MarmiK    schedule 26.03.2014
comment
Я действительно подозреваю, что делю на 0, потому что веса такие маленькие. - person Xu Wang; 27.03.2014
comment
Если его разделить на ноль, он не должен работать на других ОС/системах. Так что не скажу.. :) - person MarmiK; 27.03.2014