Milyonlarca veri noktası için tekrarlanan en yakın komşu hesaplaması çok yavaş

3D olarak milyonlarca veri noktasına çalışan bir veri setim var. Yaptığım hesaplama için, bir yarıçaptaki her veri noktasına komşu (aralık arama) hesaplamam, bir fonksiyona uymaya çalışmam, uyum için hatayı hesaplamam, bir sonraki veri noktası için bunu tekrarlamam vb. Kodum düzgün çalışıyor, ancak veri noktası başına yaklaşık 1 saniye çalıştırmak çok uzun zaman alıyor! Muhtemelen her nokta için tüm veri kümesini aramak zorundadır. Süreci hızlı bir şekilde yapabilmemin bir yolu var mı? İlk komşular arasında bir şekilde bir bitişiklik ilişkisi kurabilirsem, bunun daha az yavaş olabileceğine dair bir fikrim var. Eğer yardımcı olursa, 3B'de optimum Parzen pencere genişliği bulmaya çalışıyorum.

Cilt hiyerarşileri sınırlamak için googling öneririm (özellikle BSP ağacı). Nokta bulutunuz göz önüne alındığında, onu iki eşit alt klora ayıran bir uçak bulabilirsiniz. Daha sonra, bir test noktasının R yarıçapında olan noktaların toplanmasını bulmanız gerektiğinde, önce test noktanızı o düzlemle karşılaştırabilirsiniz ve üzerindeki yükseklik R'den fazlaysa, düzlemin altındaki tüm alt bulut ayrıca R'den daha uzakta olmalıdır (bu yüzden bu noktalardan herhangi birini kontrol etmeniz gerekmez). Bu fikri özyinelemeli olarak da uygulayabilirsiniz, sonuçta n-kare yerine n log n tipi karmaşıklık verir. (Bu BSP / ikili alan bölümleme,

Konum ve yakınlık hakkındaki bilgileri koruyan verileri depolamak için birkaç veri yapısı vardır; orada en yakın komşu (lar) ın belirlenmesine izin vererek.

Özellikle R-ağaçları (ve R * -trees gibi özel formlar ) ve X-ağaçları . Biraz farklı kullanımlar için optimize edilmiş çok sayıda seçenek.

En yakın naif bir komşu araması yerine bir R * ağacı seçmek, belirli bir koddan 10000 hızlanma faktörü elde etmemin büyük bir parçasıydı. (Tamam, bunun belki birkaç yüz R naif benzerim kadar kötü önbelleği çökerttiğini o kadar kodlanmış çünkü kalan çoğu idi *-ağacı oldu. :: sigh :: )

Bu yapılar tipik ( depolanan nokta sayısı) ekleme performansı ve depolama gereksinimi ve arama performansına sahiptir, bu nedenle birçok arama yapacaksanız ( DBSCAN'daki gibi her nokta için bir tane); ancak bazıları çok kötü bir kötü performansa sahiptir.$O(N \log N)$$N$$O(\log N)$

Bu, moleküler dinamikler alanındaki en büyük zorluklardan birine çok benzer - bağlanmamış parçacıklar arasındaki tüm ikili etkileşimleri hesaplar.

Orada, yakınlarda ne olduğunu anlamamıza yardımcı olmak için hücre listelerini (veya komşu listelerini ) kullanıyoruz; Bu uygulama için, hücre listesi muhtemelen kullanımı daha kolay algoritmadır:

• Kutuyu bir dizi hücreye bölün.
• Her bir partikül için, hangi hücreye atanması gerektiğini belirleyin (partikül başına O (1)).
• Sonra, her bir parçacık için, "kendi" hücresi artı komşu hücreleri kontrol edin; bunlardan herhangi biri işgal edilmişse, başka bir araştırmaya gerek yoktur.
• En yakın komşuların tümü boşsa, bir parçacık bulunana kadar en yakın komşuları genişletin.

Sisteminizde az ya da çok düzgün partikül dağılımı varsa, bu, şebekenin kalınlığına göre algoritmanızın maliyetini büyük ölçüde azaltacaktır. Bununla birlikte, bazı ince ayarlar gereklidir: çok kaba bir ızgara ve fazla zaman kazanmazsınız; çok iyi ve boş ızgara hücreleri üzerinde bisiklete binmek için çok zaman harcayacaksınız!

Nokta kümeleri için tercih edilen yöntem olan KD ağaçlarını ve sekizliklerini kesinlikle kontrol etmelisiniz ( BSP'ler genel nesneler için ve az ya da çok düzgün yoğunluklar için ızgaralar). Çok kompakt ve hızlı olabilirler, hem bellekte hem de hesaplamada ek yükü en aza indirirler ve uygulanması kolaydır.

Puanlarınız az çok düzgün bir şekilde dağıldığında (boş alanlarla bile olsa, ancak yoğunluk tekilliği veya başka bir yüksek konsantrasyon olmamalıdır), ızgara benzeri hiyerarşik olmayan bir alan alt bölümünü denemek istiyorsanız küre paketlerini kontrol edin.

Muhtemelen Delaunay üçgenlemesini oluşturmayı düşünmelisiniz (iyi, onun 3D analogu). 2D'de, her zaman en yakın komşuyu içeren veri noktalarının özel bir üçgenlemesi. Aynı şey 3D'de de var, ancak tetrahedra ile.

$n \log(n)$

Umarım yardımcı olur!