Scikit-learn: O t-SNE falha com a matriz não deve conter infs ou NaNs (específico do OSX)

Mesmo com ('Scikit-Learn', '0.18.dev0')

Você se importa em compartilhar seus dados X comigo?

Claro, onde e em que formato você gostaria?

Em 17 de abril de 2016, às 09:11, 康 洋[email protected] escreveu:

Você se importa em compartilhar seus dados X comigo?

-
Você está recebendo isso porque é o autor do tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -210968577

Meu e-mail é [email protected]
Como eu sei, existe uma função numpy.save para salvar um array em um arquivo binário no formato .npy ~~

Eu testo seus dados no ubuntu 14.04 LTS com
Python == 2.7.6
scikit-learn == 0.17.1
numpy == 1.8.2
scipy == 0.13.3
Está tudo bem e não aumenta o ValueError. O código de teste é:
`import numpy
a = numpy.load ('/ root / test.npy')
print a.shape
imprimir numpy.isnan (a) .all () #False
imprimir numpy.isfinite (a) .all () #True
imprimir numpy.isinf (a) .all () #False

de sklearn.manifold import TSNE
proj = TSNE (). fit_transform (a) # [[2.35503527e + 00 1.15976751e + 01] .... [3.29832591e + 00 8.98212513e + 00]]
imprimir proj`

Então eu atualizo o numpy, scipy para 1.11.0, 0.17.0 e teste com o mesmo código e também não gera nenhum erro.

Reproduzido para 3.5 com anaconda no OS X El Capitan.

Darwin 15.4.0
Python 3.5.1 :: Anaconda custom (x86_64)
numpy 1.10.4
scipy 0.17.0
scikit-learn 0.17.1

Exemplo de execução:

import random
from sklearn.manifold import TSNE
random.seed(1)
a = np.random.uniform(size=(100,20))
TSNE(n_components=2).fit_transform(a)

Obrigado @ ivan-krukov, mas não estou conseguindo replicar no Python 3.3. Vou tentar 3,5

Isso não se aplica a linux (4.4.0-21, Ubuntu 16.04) com os mesmos pacotes em 3.5.

Estou no El-Capitan, mas não consigo fazer uma instalação do Python 3.5 instalada e funcionando.

Existe alguma atualização sobre isso?

Tenho o problema em um conjunto de dados meu, no Anaconda, Py 3.5, sklearn 0.17.1, OSX El Capitan.
Posso reproduzir o erro com o exemplo fornecido por @ ivan-krukov.

O mesmo problema. Python 2.7.6 no OS X El Capitan no 0.17. Tentei o mesmo código no Linux usando Python 2.7.6 e 0.17, e funcionou.

O mesmo problema.
OSX El Capitan Python 3.5.1
scikit-learn == 0.17.1
scipy == 0.17.1

Tenho o mesmo problema e gostaria de uma solução (ou solução alternativa?)
Versão do sistema: OS X 10.11.5
Python 3.5.1 :: Anaconda 4.0.0 (x86_64)
numpy.version.version 1.11.0
scipy.version 0.17.1
sklearn. versão 0.17.1

Também posso reproduzir o bug com o exemplo de código de ivan-krukov

Mesmo problema no OS X EI Capitan usando Python 3.5

Versão do sistema: OS X 10.11.5
Python 3.5.1 :: Continuum Analytics, Inc.
entorpecido. versão 1.11.1
scipy. versão 0.16.0
sklearn. versão 0.17.1

Mesmo problema. Embora eu tenha notado que isso ocorre apenas para um subconjunto do meu conjunto de dados e não com a coisa toda . Ou seja, se eu faço TSNE em todo o conjunto de dados, ele funciona , se eu faço em um conjunto reduzido, não funciona.

O_o ;; Isso só acontece, se eu repetir o mesmo subconjunto 'quebrado' que não funciona (por meio da lista * 10), então funciona. Multiplicar cada vetor individual por 10 não funciona, mas duplicar a data sim. apenas dobrar o comprimento da lista é insuficiente. Talvez seja algum tipo de verificação dos graus de liberdade descontrolada?

@ ivan-krukov Eu mordi a bala hoje e instalei um El Capitan VM. Infelizmente não consigo reproduzir o seu problema.

@Concomitant, você pode reproduzir o erro no exemplo independente fornecido em https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -218365487?

Estou no El-Capitan, mas não consigo fazer uma instalação do Python 3.5 instalada e funcionando.

@jnothman , não parece estar acontecendo apenas no Python 3.5, então se você pudesse tentar reproduzir com Python 2.7 (snippet: https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment-218365487 ) isso seria bom.

@lesteve , posso reproduzir o problema.

import numpy as np
import random
from sklearn.manifold import TSNE
random.seed(1)
a = np.random.uniform(size=(100,20))
TSNE(n_components=2).fit_transform(a)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/sklearn/manifold/t_sne.py", line 866, in fit_transform
    embedding = self._fit(X)
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/sklearn/manifold/t_sne.py", line 777, in _fit
    skip_num_points=skip_num_points)
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/sklearn/manifold/t_sne.py", line 832, in _tsne
    params, error, it = _gradient_descent(obj_func, params, **opt_args)
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/sklearn/manifold/t_sne.py", line 387, in _gradient_descent
    grad_norm = linalg.norm(grad)
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/scipy/linalg/misc.py", line 115, in norm
    a = np.asarray_chkfinite(a)
  File "/Users/dshank/miniconda3/envs/python3/lib/python3.5/site-packages/numpy/lib/function_base.py", line 1033, in asarray_chkfinite
    "array must not contain infs or NaNs")
ValueError: array must not contain infs or NaNs

Seguindo o mesmo código, no entanto:

>>> a = np.random.uniform(size=(10000,20))
>>> TSNE(n_components=2).fit_transform(a)
array([[  3.25766047e+11,  -2.74708004e+11],
       [  2.43498802e+11,  -7.68189047e+10],
       [ -6.00107639e+09,  -1.13548763e+11],
       ..., 
       [  3.02794039e+10,   6.64402020e+11],
       [  2.55855781e+10,   5.67932400e+10],
       [  1.42040378e+11,  -7.55188994e+10]])

Bizarro.

Também não consigo reproduzir com python 3.5.1, numpy 1.11.1, scipy 0.17.1 e scikit-learn 0.17.1 do miniconda (com MKL) em uma caixa virtual com OSX El Capitan. Vou experimentar um hardware Mac real mais tarde.

Além disso, @joelkuiper e @Concomitant você pode verificar se consegue reproduzir o problema no estado atual do branch master do scikit-learn?

@lesteve e outros, não consigo reproduzir o erro com o snippet postado anteriormente no último master com python 2.7.

Informação do sistema:

Darwin-15.0.0-x86_64-i386-64bit
('Python', '2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]')
('NumPy', '1.11.0')
('SciPy', '0.17.0')
('Scikit-Learn', '0.18.dev0')

Tentei novamente em um Mac real rodando OSX El Capitan 10.11.3 (com os últimos numpy scipy e scikit-learn do anaconda, a mesma configuração relatada por @Concomitant em https://github.com/scikit-learn/scikit-learn/issues / 6665 # issuecomment-229703129), mas também não conseguiu reproduzir o problema (tentei executar o snippet várias vezes).

O que é estranho é que apesar da linha np.random.seed(1) eu obtenho resultados diferentes para a saída de fit_transform . Isso pode ser um bug em si.

O que é estranho é que apesar da linha np.random.seed (1) eu obtenho resultados diferentes para a saída de fit_transform. Isso pode ser um bug em si.

Na verdade, eu li o trecho de código de @Concomitant muito rápido: em vez de random.seed(1) , deveria ser np.random.seed(1) caso contrário, o RNG numpy não é propagado novamente de forma adequada e não se pode obter resultados determinísticos.

Também agora percebi que li toda a discussão muito rapidamente e que o bug só acontece com o python 2.7. Vou tentar novamente.

Também não consigo reproduzir com o python 2.7.12 do conda no OSX 10.11.3.

Na verdade, @Ekliptor pode reproduzir o problema com o python 3.5.1 do conda, portanto, provavelmente também não está relacionado à versão do Python. Talvez dependa da versão secundária do OSX. Irá atualizar e tentar novamente.

Também não consigo replicar com OSX 10.11.5. Tentei ambos com Python 2.7.12 e 3.5.2 instalados com conda junto com numpy 1.11.1, scipy 0.17.1 e scikit-learn 0.17.1.

Eu não sei o que fazer. Se um de vocês puder reproduzir o problema, tente encontrar uma semente aleatória numpy que desencadeie o problema (usando np.random.seed(my_seed) vez de random.seed(1) no trecho acima) e comunique o valor aqui (junto com a versão do OSX e seus pacotes de python).

Posso confirmar que o problema foi corrigido com a versão mais recente. Não consigo mais reproduzir como antes.
Eu só atualizei numpy:
numpy.version.version 1.11.1

A todas as pessoas que trabalham com o Tensorflow, posso acrescentar:
Quando tento plotar uma amostra muito pequena (<200 pontos), às vezes ainda encontro esse erro. Depois de aumentar o tamanho da amostra, passo para tsne.fit_transform (), ele sempre funciona.

Obrigado @Ekliptor por verificar se ele funciona com o scikit-learn master. @joelkuiper e @Concomitant , vocês confirmam que o scikit-learn master também funciona para você? Nesse caso, podemos encerrar este problema.

Eu instalei o master, o trecho de código funciona perfeitamente agora.

parece funcionar para todos agora. fechando.

Desculpe, mas ainda recebo isso no Python 3.5.1, scikit 0.17, scikit-learn 0.18 (commit 9e913c04d748) e Numpy 1.11.1 no Mac OS 10.11.5.

@dmyersturnbull você obtém o erro ao executar o snippet de https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -218365487?

@lesteve eu fiz com aquele trecho exato, sim. No entanto, eu não entendo mais depois de limpar minha instalação do Anaconda e reinstalar do zero com Python 3.5.2.

Tenho o mesmo problema com Python 3.5.2, scikit-learn 0.17.1, scipy 0.17.1, numpy 1.11.1 no Mac OS X El Capitan 10.11.3. Funciona quando tenho mais de 2100 pontos, mas falha para valores mais baixos.

Tenho o mesmo problema com Python 3.5.2, scikit-learn 0.17.1, scipy 0.17.1, numpy 1.11.1 no Mac OS X El Capitan 10.11.3. Funciona quando tenho mais de 2100 pontos, mas falha para valores mais baixos.

Falha analogicamente

Reabrir por favor

Estou tendo o mesmo problema no OS X 10.11.6, python 3.5.1, sklearn 0.17.1 e numpy 1.11.1.
Neste conjunto de dados: https://dl.dropboxusercontent.com/u/103591/vals.out (com np.savetxt)

Falha analogicamente para valores de pontos baixos

@Lucidyan Não entendo o que você quer dizer com isso.

Estou tendo o mesmo problema no OS X 10.11.6, python 3.5.1, sklearn 0.17.1 e numpy 1.11.1.
Neste conjunto de dados: https://dl.dropboxusercontent.com/u/103591/vals.out (com np.savetxt)

@pbnsilva você pode tentar este trecho postado abaixo? Pode ser necessário executá-lo várias vezes porque, infelizmente, a semente não está configurada apropriadamente (você precisa usar np.random.seed vez de random.seed ).

import random
from sklearn.manifold import TSNE
random.seed(1)
a = np.random.uniform(size=(100,20))
TSNE(n_components=2).fit_transform(a)

Pontos de bônus se você encontrar um argumento semente para np.random.seed e um argumento random_state para TSNE que torna o trecho determinístico.

Alternativamente, algumas pessoas relataram que este bug foi corrigido no master. Você poderia tentar construir o scikit-learn master para ver se o problema desaparece?

@lesteve, eu quis dizer que recebo o mesmo erro com um pequeno número de instâncias, com os mesmos parâmetros de sistema (Python 3.5.2, scikit-learn 0.17.1, scipy 0.17.1, numpy 1.11.1 no Mac OS X El Capitan 10.11.3)

@pbnsilva você pode tentar este trecho postado abaixo? Pode ser necessário executá-lo várias vezes porque, infelizmente, a semente não está configurada apropriadamente (você precisa usar np.random.seed em vez de random.seed).

Eu tentei e ele falhou com X_SIZE <= 1750 (Y_SIZE = 20, n_components = 2 tornaram-se constantes). se eu começar a mudar as constantes (aumentar) com X_SIZE = 1750 fixo, também falha.

@Lucidyan você poderia tentar o mesmo snippet com o scikit-learn master e ver se ele também falha?

sim, não está funcionando para mim (numpy 1.11.1, El capitan.10.11, sklearn 0.17.1, python 3.5.2) irritantemente, ele quebrou um código antigo que funcionou. o que vocês mudaram ...?

@ act65 estamos mais do que ansiosos para chegar ao fundo disso, mas não conseguimos reproduzir e parece que estamos recebendo relatórios mistos de usuários até agora, infelizmente.

Portanto, se ainda não o fez (infelizmente não somos leitores de mentes e "não estamos trabalhando para mim" não nos diz o que você tentou), pode tentar executar o trecho mencionado acima em https://github.com/scikit-learn / scikit-learn / issues / 6665 # issuecomment -243782185. Tente executá-lo várias vezes, pois a semente aleatória não está configurada corretamente e pode haver alguma aleatoriedade deixada no snippet.

Então, o que seria realmente ótimo se você pudesse tentar com o release candidate 0.18, que é simples de instalar (altamente recomendado fazê-lo em um virtualenv ou conda env separado):

pip install --pre scikit-learn -U

Editado: 0.18 foi lançado para que você possa apenas usar (não há necessidade de usar --pre ):

pip install scikit-learn -U

e execute novamente o snippet para ver se ele está corrigido em 0,18, como alguns usuários já relataram neste tópico.

0.18 será lançado em algumas semanas, senão dias, então você sabe o que precisa fazer se quiser nos ajudar a descobrir isso antes do lançamento ;-).

sim, meu mal, deveria ter sido mais claro. (Eu tentei quase a mesma coisa que outros, apenas no MNIST).

de qualquer maneira, funciona! obrigado :)
pip install --pre scikit-learn -U corrigiu

OK, obrigado por nos reportar e ótimo saber que isso foi corrigido para você no candidato a lançamento do 0.18! Isso parece corresponder ao que outros relataram quando dizem que foi corrigido no master.

Porém, apenas para completar, é recomendado manter as versões lançadas para o código de produção, então você pode precisar esperar um pouco mais até que a versão 0.18 seja lançada.

@lesteve
Eu tentei o snippet na versão 0.18rc2, instalado por

pip install --pre scikit-learn -U

E parece funcionar! Felicidades!

Obrigado @Lucidyan por tentar.

Ainda estou recebendo este erro com o trecho de código acima após atualizar para o scikit-learn 0.18 ( pip install --pre scikit-learn -U ) no env conda.

Aqui estão as informações do meu sistema:
OS X El Capitan Versão 10.11.4
Python 2.7.12
sklearn 0.18 (obteve o mesmo erro no sklearn 0.17.1 também)
numpy 1.11.1 (obteve o mesmo erro no numpy 1.11.2 também)
scipy 0.18.1

No entanto, executei o mesmo trecho de código no sistema Linux, não obtive um erro.
As informações do sistema Linux são:
Ubuntu 14.04.5 LTS (GNU / Linux 3.13.0-91-x86_64 genérico)
Python 2.7.6
sklearn 0,18
numpy 1.11.2
scipy 0.13.3

Tente desinstalar e reinstalar o numpy, scipy e scikit-learn. Se isso ainda falhar, tente em um virtualenv diferente (ou ambiente conda se você estiver usando conda) para se certificar de que algo não está errado em seu ambiente Python.

Ainda recebo o mesmo erro ( ValueError: array must not contain infs or NaNs ) no sklearn 0.18 ( 0.18-np111py35_0 ) via conda. As rodas pip parecem funcionar bem!

Ainda obtém o mesmo erro (ValueError: array não deve conter infs ou NaNs) em sklearn 0.18 (0.18-np111py35_0) via conda. As rodas pip parecem funcionar bem!

Hmmm interessante ... você poderia tentar usar pacotes conda sem mkl, ou seja, algo como conda create -n sklearn_nomkl python scikit-learn nomkl para que possamos ver se isso é uma coisa MKL vs openblas?

Também pontos de bônus se você puder fornecer um snippet reproduzindo o problema com uma semente aleatória fixa (ou seja, usando np.random.RandomState(some_int) ) que pode ser usado como um snippet de referência no futuro. Até agora, o snippet que temos é não determinístico ( random.seed é usado e não tem influência da semente numpy.random).

Claro, sem problemas. Este pode ser um problema BLAS de fato, o conda create -n sklearn_nomkl python scikit-learn nomkl env funciona bem.

Em relação ao snippet ... isso fica interessante. Por exemplo,

from sklearn.manifold import TSNE
from sklearn.model_selection import train_test_split
from sklearn.datasets import load_digits

digits = load_digits()

X_train, X_test, y_train, y_test = train_test_split(digits.data, 
                                                    digits.target, 
                                                    random_state=1)

tsne = TSNE(random_state=1)
digits_tsne_train = tsne.fit_transform(X_train)

reproduz o problema na minha máquina. No entanto, quando substituo digits_tsne_train = tsne.fit_transform(X_train) por digits_tsne_train = tsne.fit_transform(digits.data) , parece que está tudo bem. Seria bom encontrar um exemplo mais leve, talvez, para adicionar este caso particular aos testes de travis.

EDIT: O mesmo vale para a íris. iris.data funciona em fit_transform, um conjunto de dados dividido ( X_train ) não. Talvez haja algo engraçado acontecendo em train_test_split . No entanto, tanto X_train quanto iris.data parecem ser matrizes flutuantes 64 ...

E quanto ao snippet de https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -243782185, você não encontrou uma maneira de torná-lo determinístico e ainda falhar em sua máquina?

O trecho

import numpy as np
from sklearn.manifold import TSNE

np.random.seed(1)

a = np.random.uniform(size=(100, 20))
TSNE(n_components=2, random_state=1).fit_transform(a)

reproduz o erro (mas funciona bem no env nomkl)

OK, muito obrigado por isso, pelo menos temos um trecho determinístico agora. Para registro, você pode postar a saída deste snippet:

import platform; print(platform.platform())
import sys; print("Python", sys.version)
import numpy; print("NumPy", numpy.__version__)
import scipy; print("SciPy", scipy.__version__)
import sklearn; print("Scikit-Learn", sklearn.__version__)

Além disso, apenas por uma questão de sanidade, você pode ter certeza de que pode reproduzir o problema em um ambiente novo de conda.

Para ser honesto, não sei para onde vamos a partir disso. Não tentei desde então, mas não consegui reproduzir em uma caixa El Capital Virtual, @ogrisel também não conseguiu reproduzir em um laptop OSX, então na época ele disse que pode haver algum problema específico de hardware envolvido.

Certo,

a máquina que causa este problema:

Darwin-16.1.0-x86_64-i386-64bit
Python 3.5.2 |Continuum Analytics, Inc.| (default, Jul  2 2016, 17:52:12) 
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)]
NumPy 1.11.2
SciPy 0.18.1
Scikit-Learn 0.18

(testei em um ambiente novo de conda)

pode haver algum problema específico de hardware envolvido.

Eu acho que você pode estar no caminho certo! Eu tentei no meu outro Mac, e funciona bem lá. A única diferença é que a saída acima está rodando em um kernel antigo ( Darwin-15.6.0-x86_64-i386-64bit ). Ainda não atualizei o segundo mac para o macOS Sierra, que está rodando na máquina anterior com este problema. Pode ser relacionado ao sistema operacional. Vou atualizar a segunda máquina para Sierra no próximo mês ou depois (estou no meio de um projeto e não quero quebrar as coisas), mas posso informá-lo se a atualização para Sierra levar a esse problema no segunda máquina (ou talvez outra pessoa com macOS Sierra possa testá-la para que possamos saber se é uma coisa do sistema operacional)

Dado que o problema foi relatado em diferentes versões do OSX, eu duvido que seja apenas um problema de versão do OSX. O palpite de @ogrisel do

Outra maneira (mais demorada) de depurar esse problema seria rastrear onde os NaNs aparecem no código.

O palpite de @ogrisel do

Hm, como a versão conda scikit-learn difere das rodas pip? Porque o último parece funcionar na mesma máquina. Talvez seja de alguma forma relacionado a conda

Outra maneira (mais demorada) de depurar esse problema seria rastrear onde os NaNs aparecem no código.

Notei que o gradiente em https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/manifold/t_sne.py#L387 explode, até se tornar -inf em uma posição após a 25ª iteração no https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/manifold/t_sne.py#L386 for-loop

...
   0.00000000e+00   0.00000000e+00   0.00000000e+00   0.00000000e+00
   0.00000000e+00   0.00000000e+00   6.06587795e+32  -1.10699515e+33
  -1.55245133e+34              inf  -1.52569936e+33  -3.43926080e+33
  -1.92332051e+32  -2.73996151e+32  -2.57570880e+33  -3.64962271e+33
...

Na outra máquina (aquela que funciona bem), os gradientes são todos <0 após a mesma iteração. Então, de alguma forma a função _gradient_descent não funciona corretamente (talvez devido a alguma coisa do BLAS).

Hm, como a versão conda scikit-learn difere das rodas pip? Porque o último parece funcionar na mesma máquina. Talvez seja de alguma forma relacionado a conda

As engrenagens estão usando OpenBLAS e você não tem problemas ao usar OpenBLAS com conda (por meio do truque nomkl ), então isso parece um problema MKL, que além disso é provavelmente específico da CPU.

A propósito, ótimo trabalho ao depurar o problema! Pontos de bônus se você conseguir isolar ainda mais o problema (por exemplo, separando os dados antes da iteração inf aparecer). O problema surge muito provavelmente em algum código de cython em sklearn / manifold / _barnes_hut_tsne.pyx.

Esta edição não deveria ser reaberta com as últimas descobertas? Eu também acertei e consegui superar com o truque do nomkl, mas parece um bug ativo contra um fechado, não?

Outros que estão acertando isso: https://discussions.udacity.com/t/assignment-5-error-in-the-main-code-valueerror-array-must-not-contain-infs-or-nans/178187 / 7

Você está certo, reabrindo. Este é sério, parece específico do hardware e nenhum dos desenvolvedores principais poderia reproduzi-lo. A única maneira de isso ser corrigido é se as pessoas com o problema investirem algum tempo para depurar o problema posteriormente.

A propósito, ótimo trabalho ao depurar o problema! Pontos de bônus se você conseguir isolar ainda mais o problema (por exemplo, separando os dados antes que a iteração inf apareça). O problema surge muito provavelmente em algum código de cython em sklearn / manifold / _barnes_hut_tsne.pyx.

Estou feliz em dar uma olhada nisso em dezembro, depois de todos os prazos de novembro ... No entanto, mesmo isso pode ser ainda mais isolado, estou curioso para saber se há uma solução para esse problema específico de hardware. Talvez, até que isso seja totalmente resolvido, possa valer a pena levantar uma exceção / aviso mais específico se o gradiente contiver infs com uma observação sobre esse problema.

Acabei de criar um novo conda virtualenv e construir uma versão devp do sklearn a partir do código-fonte recém-bifurcado no branch master do sciki-learn, o erro desapareceu. O devp sklearn é construído a partir do código-fonte usando OpenBLAS em vez de MKL?

Estou feliz em analisá-lo melhor em dezembro, depois de todos os prazos de novembro ...

Parece ótimo, muito obrigado!

No entanto, mesmo isso pode ser ainda mais isolado, estou curioso para saber se há uma solução para esse problema específico de hardware.

Não tenho certeza sobre uma correção, uma esperança seria se pudéssemos mudar nosso código de cíton para contornar o problema, uma vez que o tenhamos isolado. Também pode muito bem ser um problema do openblas e seria ótimo reportá-lo no upstream, especialmente porque o wheel usa o openblas.

Talvez, até que isso seja totalmente resolvido, possa valer a pena levantar uma exceção / aviso mais específico se o gradiente contiver infs com uma observação sobre esse problema.

Adicionar alguns conselhos à mensagem de erro (apenas no OS X) parece uma boa ideia, mas não tenho certeza do que deveria dizer, talvez "considere usar conda e instale scikit-learn com MKL" ou algo assim.

O devp sklearn é construído a partir do código-fonte usando OpenBLAS em vez de MKL?

@zhongyuk depende de qual biblioteca você instalou. Uma maneira de saber depois de criar o scikit-learn a partir da fonte é executar o equivalente a ldd (o Google parece dizer otool -L ) em sklearn/cluster/_k_means.so (o nome será diferente se você está usando Python 3, ou seja, algo como sklearn/cluster/_k_means.cpython-35m-x86_64-linux-gnu.so ). Na minha máquina Ubuntu, por exemplo, recebo o seguinte:

sklearn/cluster/_k_means.so:
        linux-vdso.so.1 =>  (0x00007ffc2312a000)
        libmkl_intel_lp64.so => /home/lesteve/miniconda3/envs/py27/lib/libmkl_intel_lp64.so (0x00007fadc2865000)
        libmkl_intel_thread.so => /home/lesteve/miniconda3/envs/py27/lib/libmkl_intel_thread.so (0x00007fadc0ee4000)
        libmkl_core.so => /home/lesteve/miniconda3/envs/py27/lib/libmkl_core.so (0x00007fadbf483000)
        libiomp5.so => /home/lesteve/miniconda3/envs/py27/lib/libiomp5.so (0x00007fadbf139000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fadbeeeb000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fadbebe1000)
        libpython2.7.so.1.0 => /home/lesteve/miniconda3/envs/py27/lib/libpython2.7.so.1.0 (0x00007fadbe7fa000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fadbe431000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fadbe22c000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fadbe016000)
        /lib64/ld-linux-x86-64.so.2 (0x0000563bdeda1000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fadbde12000)

Então você pode ver na terceira linha, que está usando MKL.

mas não tenho certeza do que deveria dizer, talvez "considere usar conda e instale o scikit-learn com MKL" ou algo assim.

Eu só queria escrever que acho que você mudou: as rodas funcionaram e o problema só ocorreu quando eu estava usando via conda com MKL ... Agora, acho que tenho boas notícias de alguma forma: eu só queria execute novamente o exemplo acima que causou esse problema para confirmar

import numpy as np
from sklearn.manifold import TSNE

np.random.seed(1)

a = np.random.uniform(size=(100, 20))
TSNE(n_components=2, random_state=1).fit_transform(a)

e não estou mais tendo esse problema. Eu me lembro que reinstalei o miniconda na outra semana devido a alguns outros problemas. Você acha que pode estar relacionado a algum problema no antigo conda? Seria ótimo se outras pessoas que tiveram esse problema também pudessem tentar atualizar / reinstalar o conda e verificar se isso resolve o problema para elas. Enquanto isso, tentarei ver se consigo encontrar um backupstate antigo para descobrir qual versão do conda eu havia instalado anteriormente. (agora, tenho conda 4.2.12)

Só quero dizer que executei otool -L em sklearn/manifold/_barnes_hut_tsne.so (presumo que este seja o arquivo t_sne.py compilado?), Parece que realmente está usando o BLAS. E aquele que gerou erro parece usar MKL ..

A versão do conda que tenho é 4.2.13, tanto o env que lança o erro quanto o env com o código-fonte construído sklearn (que não lança o erro) estão dentro do conda.

Hm, interessante, então não é um problema de conda afinal ... Curioso por que funciona para mim agora: /
(tudo o que posso pensar que mudou (exceto para reinstalar o conda) foi reiniciar: P)

Eu só queria escrever que acho que você mudou: as rodas funcionaram em localizar e o problema só ocorreu quando eu estava usando via conda com MKL

Sim, desculpe por isso. Vou editar o título do problema para tentar lembrá-lo da próxima vez.

Hm, interessante, então não é um problema de conda afinal ... Curioso por que funciona para mim agora: /
(tudo o que posso pensar que mudou (exceto para reinstalar o conda) foi reiniciar: P)

Hmmm, adivinhe aleatoriamente talvez a versão mkl, embora se eu acreditar que a saída de conda info mkl a versão mais recente do mkl (11.3.3) seja de 2016-05-13.

@zhongyuk tente construir scikit-learn dentro de um env conda que usa mkl, acredito que isso deve ser o suficiente para o mkl ser pego (provavelmente uma boa ideia neste caso fazer make clean e então make in para reconstruir do zero).

@lesteve Eu construí o scikit-learn em dois ambientes virtuais conda a partir do código-fonte (versão do branch 0.18), o que usa MKL realmente gera o erro; aquele que usa libBLAS não lança erro.

A saída executando otool -L em sklearn/manifold/_barnes_hut_tsne.so está aqui (no caso da versão MKL lhe dar alguma pista?)

```@rpath/libmkl_intel_lp64.dylib (versão de compatibilidade 0.0.0, versão atual 0.0.0)
@ rpath / libmkl_intel_thread.dylib (versão de compatibilidade 0.0.0, versão atual 0.0.0)
@ rpath / libmkl_core.dylib (versão de compatibilidade 0.0.0, versão atual 0.0.0)
@ rpath / libiomp5.dylib (versão de compatibilidade 5.0.0, versão atual 5.0.0)
/usr/lib/libSystem.B.dylib (versão de compatibilidade 1.0.0, versão atual 1226.10.1)

@zhongyuk ótimo! Para completar, você pode postar a saída de conda list '(mkl|cython|numpy|scipy)$' (em seu ambiente MKL conda)? Já que estamos nisso, suas informações de CPU ( sysctl -n machdep.cpu.brand_string acordo com o Google) e as informações de sua plataforma ( python -c 'import platform; print(platform.platform())' ) seriam ótimas.

O que seria realmente ótimo é continuar onde o @rabst parou e isolar ainda mais o problema:
https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -258311980

Como isso está relacionado ao BLAS, meu palpite é que algo está errado nesta linha, fazendo com que o gradiente tenha alguns valores não finitos.

@lesteve Saída de informações do ambiente conda MKL:

Cython                    0.25.1                    <pip>
mkl                       11.3.3                        0  
numpy                     1.11.1                    <pip>
numpy                     1.11.1                   py27_0 
scipy                     0.18.1              np111py27_0 

Informações da CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Informações da plataforma: Darwin-15.4.0-x86_64-i386-64bit

Analisarei o problema de explosão de gradiente que Manterei todos atualizados com quaisquer descobertas interessantes.

@zhongyuk Se ajudar, tenho uma configuração muito semelhante (não consigo mais reproduzir o problema desde a reinstalação do miniconda), exceto que tenho o macOS Sierra em vez do OS X El Capitan e o numpy 1.11.2 em vez do 1.11.1 .

@rasbt hmm, me pergunto se o problema desaparece em Sierra ... Não quero atualizar o sistema operacional ainda b / z pensei ter lido em algum lugar que o TensorFlow ainda não é compatível com Sierra (pode estar enganado ou não é mais verdade já não me lembro onde ou há quanto tempo li)? E eu não quero quebrar meus projetos com dependência TF

@zhongyuk Hm, acho improvável que esteja relacionado. Antes de reinstalar o miniconda, também tive o problema no macOS Sierra. PS: Tensorflow funciona bem para mim no Sierra, mas eu só faço CPU e prototipagem em meus macs, então não sei sobre problemas de GPU relacionados ao Sierra

@rasbt hmm, é bom saber que o TF funciona bem no Sierra. Você quer executar otool -L no arquivo sklearn/manifold/_barnes_hut_tsne.so em sua plataforma para ver qual biblioteca de matemática aprende usando embaixo? Pelo menos assim poderemos saber se o problema foi embora depois de reinstalar o miniconda está fundamentalmente ligado à biblioteca matemática?

Estou recebendo o seguinte em _barnes_hut_tsne.cpython-35m-darwin.so :

    @rpath/libmkl_intel_lp64.dylib (compatibility version 0.0.0, current version 0.0.0)
    @rpath/libmkl_intel_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
    @rpath/libmkl_core.dylib (compatibility version 0.0.0, current version 0.0.0)
    @rpath/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

@rasbt Hmm, isso é realmente interessante. Ele também está usando MKL. Não sei o suficiente sobre a biblioteca matemática para especular o que isso significa ... @lesteve provavelmente será capaz de inferir mais disso?

Notei que em minha plataforma libmkl_intel_lp64.dylib não está carregado ... É possível que tenha causado o problema?

Uau, sim! é causado por libmkl_intel_lp64.dylib não carregado !!! Eu encontrei este tópico no estouro de pilha e então executei conda install --debug mkl , então executei otool -L no arquivo sklearn/manifold/_barnes_hut_tsne.so , então libmkl_intel_lp64.dylib carregou e executei o trecho de código , o erro foi embora! Tenha cinco equipes de trabalho! @rasbt

Se qualquer outra pessoa pudesse verificar em sua plataforma e ver se o erro desapareceu após ter certeza de que libmkl_intel_lp64.dylib está carregado, isso seria ótimo!

@lesteve Já que parece que muitos ppl atingiram esse problema, e parece que está relacionado a (alguma versão de?) conda não extrair bibliotecas MKL completas (meu entendimento da situação até agora), embora não seja um bug do scikit-learn, acho que seria bom adicionar algum tipo de observação ou aviso ou mensagens de erro aos usuários do (OS X)? Assim, pelo menos, eles podem verificar se a lib MKL foi totalmente extraída em sua plataforma e corrigir se não estiver.

@zhongyuk incrível, fico feliz em saber que você conseguiu restringi-lo! Esperançosamente, é apenas o link quebrado / instalação incompleta de libmkl_intel_lp64.dylib - isso seria incrível (em termos de saber o que está acontecendo) :). Isso também explicaria por que funciona para mim agora após a reinstalação do Miniconda ... Seria ótimo se outra pessoa pudesse tentar a "correção".

Se o libmkl_intel_lp64.dylib mencionado anteriormente realmente causou esse problema, a questão restante seria como lidar com isso no scikit-learn. Quer dizer, esse "bug" é meio hediondo e pode ser um pouco complicado para as pessoas descobrirem que é devido a libmkl_intel_lp64.dylib . Eu provavelmente não injetaria um adicional "se o gradiente contiver inf raise error + message" no código do scikit-learn, pois isso poderia ser muito irritante em termos de desempenho. No entanto, acho que adicionar uma nota ou comentário na instalação e / ou documentos do T-SNE seria uma boa ideia.

Só quero adicionar uma atualização rápida: eu tinha 2 envs virtuais em conda, ambos usando MKL. Um deles está equipado com numpy 1.11.1 e o outro está equipado com numpy 1.11.2 . A execução de otool -L indicou que ambos, de alguma forma, não tinham libmkl_intel_lp64.dylib carregados. Depois de certificar-se de que libmkl_intel_lp64.dylib carregou, o erro desapareceu do env virtual com numpy 1.11.2 . Porém, o erro permaneceu aparecendo no env com numpy 1.11.1 . Depois de atualizar numpy para 1.11.2, não consigo mais reproduzir o erro em nenhum dos ambientes virtuais do conda. Como parece complicado e a causa exata do erro ainda é obscura, especulo que é provavelmente uma complicação entrelaçada pelo carregamento incompleto da biblioteca MKL e bibliotecas dependentes de scikit-learn (possivelmente entorpecidas?) (Embora eu não tenha tentado criar um virtualenv com MKL e numpy 1.11.1 para ver se isso reproduzia o erro.)

E eu concordo com a sugestão do

@zhongyuk que bom que você consertou! Parece que reinstalar os pacotes com o conda pode ajudar, mas não parece haver uma imagem muito clara da causa do problema :(.

Este é um bug do conda, certo? Ou alguém experimentou o bug de não usar o conda?

Eu consegui encontrar uma maneira de reproduzir, acho, instalando a roda numpy e depois scikit-learn via conda em cima dela (peguei a dica da saída conda list em https://github.com/scikit- learn / scikit-learn / issues / 6665 # issuecomment-262800762 onde dois numpy estão listados).

conda create -n tmp python=3 -y
. activate tmp
pip install numpy -y
conda install scikit-learn -y

em seguida, execute o snippet de https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -262800762.

Portanto, parece que isso está acontecendo ao misturar numpy instalado via pip e conda. No meu livro, nunca é uma boa ideia misturar pip e conda para um determinado pacote, mas acho que isso pode acontecer sem perceber facilmente (por exemplo, você instala um projeto que depende de numpy via pip e, em seguida, scikit-learn via conda )

Por que isso exatamente acontece, eu não sei ... e parece acontecer apenas no OSX, a propósito (ou seja, não na minha caixa do Ubuntu).

Para qualquer pessoa afetada por isso, isso deve corrigir:

conda remove numpy --force -y
pip uninstall numpy -y
conda install numpy

Deixe-me saber se isso não funcionar para você.

Obrigado pelo mergulho profundo (de novo!) @Lesteve

Para ser honesto, pensei que nunca chegaríamos ao fundo dessa questão :)! OK, não é exatamente o fundo, mas é baixo o suficiente para mim.

Tenho que admitir que ainda gostaria de entender o que está acontecendo dentro do numpy instalado com pip e conda ...

Oi
Tentei duas configurações, onde

• TSNE funciona bem com uma configuração (onde Tensorflow é desativado, Python-3.x), no entanto,

• TSNE não funciona com a outra configuração (onde Tensorflow está ativado, Python 2.x).

A configuração onde o TSNE funciona bem:

Terminal:

Macbook:~ BG$ which jupyter
/Users/BG/anaconda/bin/jupyter

Caderno de Jupyer:

import sys
print (sys.version)

>

3.5.2 |Anaconda 4.2.0 (x86_64)| (default, Jul  2 2016, 17:52:12) 
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)]

Nota: eu tentei

conda remove numpy --force -y
pip uninstall numpy -y
conda install numpy

para fazer o TSNE funcionar bem com o Tensorflow desativado.
No entanto, com a nova configuração abaixo (onde tenho que usar o Tensorflow), isso não funciona mais.
——-———-———-———-———-———-———-———-

A configuração onde o TSNE não funciona:

Terminal:

Macbook:~$ source activate tensorflow
(tensorflow) Macbook:~$ which jupyter
/Users//anaconda/envs/tensorflow/bin/jupyter
(tensorflow) Macbook:~$ 

Caderno de Jupyer:

import sys
print (sys.version)

>

2.7.13 |Continuum Analytics, Inc.| (default, Dec 20 2016, 23:05:08) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]

Erro :
ValueError: array must not contain infs or NaNs

Alguma sugestão ? Muito obrigado

Interessante. Acho que não tem nada a ver com tensorflow; meu palpite é que

[GCC 4.2.1 compatível com Apple LLVM 4.2 (clang-425.0.28)]

vs

[GCC 4.2.1 compatível com Apple LLVM 6.0 (clang-600.0.57)]

é o culpado !?

Obrigado pela resposta :) Alguma solução sugerida / to_do_list?

Precisa usar ambos
Tensorflow e
TSNE
no caderno Jupyter ....

BTW: acabei de tentar "da divisão de importação __future__" no Python 2.xe não resolveu o problema.

Hm, não tenho certeza se isso ajuda - pessoalmente, não estou mais tendo esse problema misterioso com

Python 3.5.3 |Continuum Analytics, Inc.| (default, Feb 22 2017, 20:51:01) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

Também estou no Tf (agora 1.0) e não tenho mais esse Error: ValueError: array must not contain infs or NaNs problema quando executo

import numpy as np
from sklearn.manifold import TSNE

np.random.seed(1)

a = np.random.uniform(size=(100, 20))
TSNE(n_components=2, random_state=1).fit_transform(a)

que anteriormente não funcionava.

Talvez tente criar um novo env python 3.5 e tente o snippet mencionado acima para ver se funciona sem erros:

conda create -n yourenv python=3.5 numpy scipy scikit-learn
source activate yourenv
pip install tensorflow(-gpu)

Oi rasbt,
Sim, fiz o TSNE funcionar no Python 3.5.
No entanto, por alguma outra razão, é melhor usar o Python 2.7, então tenho que continuar a explorar ... dedos cruzados

Obrigado pela ajuda.

Você tem uma distribuição Miniconda / Anaconda 2.7 antiga instalada? Nesse caso, talvez considere instalar um dos mais recentes ou atualizar sua raiz conda ou python padrão e tentar novamente (ou criar um novo env py 27 substituindo 3,5 por 2,7 em conda create -n yourenv python=3.5 numpy scipy scikit-learn )? (não tenho certeza se este é realmente o motivo, mas acho que LLVM 4.2 (clang-425.0.28) pode ser um problema; já que o erro não parece ocorrer por meio de [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] )

Atualização: TSNE (perplexidade = 30, n_components = 2, init = 'pca', n_iter = 1000, método = 'exato' ) faz funcionar ...
método = 'exato' era o truque.

Também tenho tido esse problema. Usar method = 'exact' parece funcionar para mim, mas é dolorosamente lento. Não existe realmente nenhuma outra solução que as pessoas tenham encontrado?

Você já leu https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -264029983 e https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -264087057 ?

A única maneira de reproduzir esse problema foi instalar o numpy com pip e conda no mesmo ambiente conda. Se você criar um ambiente conda do zero, não deverá ter esse problema.

Caso seu problema pareça não corresponder a esta descrição, poste os comandos exatos que você executou para criar seu ambiente conda, para que possamos tentar reproduzi-lo.

Oi,
Eu li os comentários acima e posso reproduzir isso. Eu executei novamente o código de algumas semanas atrás e agora esse problema aparece. Aqui está um exemplo mínimo que agora reproduz esse problema:

from sklearn.manifold import TSNE
a = [[1,2,3],[4,5,6], [7,8,9]]
TSNE(n_components=2,).fit_transform(a)

E a saída de

import platform; print(platform.platform())
import sys; print("Python", sys.version)
import numpy; print("NumPy", numpy.__version__)
import scipy; print("SciPy", scipy.__version__)
import sklearn; print("Scikit-Learn", sklearn.__version__)

é

Darwin-16.5.0-x86_64-i386-64bit
Python 3.6.0 |Anaconda 4.3.0 (x86_64)| (default, Dec 23 2016, 13:19:00) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
NumPy 1.12.1
SciPy 0.19.0
Scikit-Learn 0.18.1

Novamente, alterar o método para exato ( TSNE(method='exact') ) elimina o erro.

De modo mais geral, observei resultados totalmente diferentes ao usar o TSNE do sklearn (com perplexidade idêntica e outros parâmetros) da implementação bh publicada por Laurens van der Maaten e a versão MATLAB. Eu me pergunto se pode haver uma conexão?

Você se referiu a https://github.com/scikit-learn/scikit-learn/issues/6665#issuecomment -264087057

Isso resolveu. Minhas desculpas - eu tinha desinstalado separadamente um numpy, scikit learn e scipy reinstalado, mas não como no 6665.

Tive o mesmo problema relatado aqui e não utilizo conda.

Minha versão Python é instalada via brew no macOS Sierra 10.12.4

Python 3.6.1
scipy==0.19.0
scikit-learn==0.18.1
numpy==1.11.1

Adicionar mode='exact' resolveu meu problema.

@lesteve : Eu tive este erro ao usar a configuração que você descreve (duas versões do numpy instaladas). simplesmente atualizar o conda install do numpy para a mesma versão do pip install (1.12.1) funcionou para mim. Eu removi a instalação pip numpy, pois não pretendia ter duas versões :)

@lesteve : Obrigado pela solução! Acontece que tive este erro e então encontrei esta discussão. Corrija-o imediatamente após remover a versão duplicada do numpy.

Replicado , removi as instalações de pip do numpy e atualizei o conda.

Darwin-16.7.0-x86_64-i386-64bit
('Python', '2.7.13 | Anaconda custom (x86_64) | (padrão, 20 de dezembro de 2016, 23:05:08) \ n [GCC 4.2.1 compatível com Apple LLVM 6.0 (clang-600.0.57)]')
('NumPy', '1.13.1')
('SciPy', '0.19.0')
('Scikit-Learn', '0.18.1')

Parece bom na minha máquina Linux Linux:
Linux-3.0.101-0.47.71-default-x86_64-with-SuSE-11-x86_64
('Python', '2.7.12 | Anaconda 2.3.0 (64 bits) | (padrão, 2 de julho de 2016, 17:42:40) \ n [GCC 4.4.7 20120313 (Red Hat 4.4.7-1) ] ')
('NumPy', '1.12.1')
('SciPy', '0.19.1')
('Scikit-Learn', '0.18.1')

@wolfiex então você fez

conda remove numpy --force -y
pip uninstall numpy -y
conda install numpy

Algo relacionado, recomendo que você atualize para o scikit-learn 0.19, que possui algumas correções no t-SNE

recebendo o mesmo erro agora

Olá @rahulsnair , você se importa em abrir um novo exemplar, com código reproduzível, seu traceback e as versões que está usando? Este problema é muito antigo e o código mudou muito. Obrigado!