NA returned with Warning: Embedding 8 connected components using meta-embedding (experimental) n_components

Working enviroment: Mac OS 13.5, PYTHON 3.6. My data is 660K * 6 dimensions. Firstly, I tried n_neighbors =100. It worked fine. Then I tried n_neighbors=15, it gave warning:

lib/python3.6/site-packages/umap/spectral.py:229: UserWarning: Embedding 8 connected components using meta-embedding (experimental) n_components

And the returned embedding is all NA. Then I also tried n_neighbors =200,500, all the embedding is NA. I am not sure what happened.

Thank you!

[lmcinnes]

I suspect the spectral initialisation is failing for one reason or another. This can often happen for particularly oddly distributed data. As a workaround you can use init='random' as a parameter to UMAP. It should stop the NaNs happening at least. This isn’t ideal, but it should get you past the immediate problem. I’ll try to look into the deeper issue soon.

On Sat, Jul 21, 2018 at 2:46 PM Yubin [e-mail] wrote:

Working enviroment: Mac OS 13.5, PYTHON 3.6. My data is 660K * 6 dimensions. Firstly, I tried n_neighbors =100. It worked fine. Then I tried n_neighbors=15, it gave warning:

lib/python3.6/site-packages/umap/spectral.py:229: UserWarning: Embedding 8 connected components using meta-embedding (experimental) n_components

And the returned embedding is all NA. Then I also tried n_neighbors =200,500, all the embedding is NA. I am not sure what happened.

Thank you!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lmcinnes/umap/issues/90, or mute the thread https://github.com/notifications/unsubscribe-auth/ALaKBRtAWlN0oltfU-aY_lOMdy6zb17Uks5uI3cKgaJpZM4VZuTT .

[lmcinnes]

Each instance is viewed as an independent object, so even if they are identical in the data they are treated as technically separate, and thus embed into different locations.

Checking for unique rows is certainly an option, but a very expensive one computationally. There are other checks that should catch such situations, so I’m not sure whether this was technically the problem or not.

On Wed, Aug 1, 2018 at 7:10 AM JoshuaC3 [e-mail] wrote:

I found this issue (Embedding 6 connected instead), and another issue,

“Random Projection forest initialisation failed due to recursion” "limit being reached. Something is a little strange with your " “data, and this may take longer than normal to compute.”

when trying to embed weekday data. Hence, I had only 7 unique rows in my np.array and, after much spluttering and wasted time I got the following plot,

[image: weekday_embedding] https://user-images.githubusercontent.com/11645712/43518194-2d1d86ea-9583-11e8-83a6-0e77845c44a7.png (Interesting how it embeds each instance of the same day of the week in a sightly different (x, y) co-ordinate… @lmcinnes https://github.com/lmcinnes any intuition on this?)

My suggestion would be a check on the number of unique rows in the np.array a users provides. Still, I am not 100% certain that this was the cause of my two warnings but hopefully it might help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lmcinnes/umap/issues/90#issuecomment-409539281, or mute the thread https://github.com/notifications/unsubscribe-auth/ALaKBRO5IscJpFphYRo3jaZ1BTr4HKyyks5uMYyygaJpZM4VZuTT .