अजगर 3.5 के साथ एक ही परिणाम:

Darwin-15.6.0-x86_64-i386-64bit
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
NumPy 1.11.0
SciPy 0.18.1
Scikit-Learn 0.17.1

यह केवल यूक्लिडियन दूरी के साथ होता है और इसे सीधे sklearn.metrics.pairwise.euclidean_distances का उपयोग करके पुन: पेश किया जा सकता है:

import scipy
import sklearn.metrics.pairwise

# create 64-bit vectors a and b that are very similar to each other
a_64 = np.array([61.221637725830078125, 71.60662841796875,    -65.7512664794921875],  dtype=np.float64)
b_64 = np.array([61.221637725830078125, 71.60894012451171875, -65.72847747802734375], dtype=np.float64)

# create 32-bit versions of a and b
a_32 = a_64.astype(np.float32)
b_32 = b_64.astype(np.float32)

# compute the distance from a to b using sklearn, for both 64-bit and 32-bit
dist_64_sklearn = sklearn.metrics.pairwise.euclidean_distances([a_64], [b_64])
dist_32_sklearn = sklearn.metrics.pairwise.euclidean_distances([a_32], [b_32])

np.set_printoptions(precision=200)

print(dist_64_sklearn)
print(dist_32_sklearn)

मैं और त्रुटि को ट्रैक नहीं कर सका।
मुझे उम्मीद है कि यह मदद कर सकता है।

numpy एक उच्च परिशुद्धता संचायक का उपयोग कर सकता है। हां, ऐसा दिखता है
फिक्सिंग के हकदार हैं।

19 जुलाई 2017 को 12:05 बजे, "nvauquie" नोटिफिकेशन @github.com ने लिखा:

अजगर 3.5 के साथ एक ही परिणाम:

डार्विन-15.6.0-x86_64-i386-64bit
पायथन 3.5.1 (v3.5.1: 37a07cee5969, 5 दिसंबर 2015, 21:12:44)
[जीसीसी ४.२.१ (Apple Inc. बिल्ड ५६६६६) (डॉट ३)]
NumPy 1.11.0
विज्ञानपी ०.१ 0..१
स्किटिट-लर्न 0.17.1

यह केवल यूक्लिडियन दूरी के साथ होता है और इसका उपयोग करके पुन: पेश किया जा सकता है
सीधे sklearn.metrics.pairwise.euclidean_distances:

आयात से डर लगता है
आयात sklearn.metrics.pairwise

64-बिट वैक्टर a और b बनाएं जो एक-दूसरे के समान हों

a_64 = np.array ([61.221637725830078125, 71.60662841796875, -65.7512664794921875], dtype = np.flobad64
b_64 = np.array ([61.221637725830078125, 71.60894012451171875, -65.72847747802734375], dtype = np .float64)

a और b के 32-बिट संस्करण बनाएँ

a_32 = a_64.astype (np.float32)
b_32 = b_64.astype (np.float32)

64-बिट और 32-बिट दोनों के लिए, स्केलेर का उपयोग करके बी से दूरी की गणना करें

dist_64_sklearn = sklearn.metrics.pairwise.euclidean_distances ([a_64], [b_64])
dist_32_sklearn = sklearn.metrics.pairwise.euclidean_distances ([a_32], [b_32])

np.set_printoptions (परिशुद्धता = 200)

प्रिंट (dist_64_sklearn)
प्रिंट (dist_32_sklearn)

मैं और त्रुटि को ट्रैक नहीं कर सका।
मुझे उम्मीद है कि यह मदद कर सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/9354#issuecomment-316074315 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAEz65yy8Aq2FcsDAcWHT8qkkdXF_MfPks5sPLu_gaJpZM4OXbpZ
।

यदि संभव हो तो मैं इस पर काम करना चाहूंगा

इसका लाभ उठाएं!

इसलिए मुझे लगता है कि समस्या इस तथ्य के आसपास है कि हम यूक्लिडियन दूरी की गणना के लिए sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y)) का उपयोग कर रहे हैं
क्योंकि अगर मैं कोशिश करता हूं - (-2 * np.dot(X, Y.T) + (X * X).sum(axis=1) + (Y * Y).sum(axis=1) मुझे np.float32 के लिए उत्तर मिलता है, जबकि मुझे np.float 64 के लिए सही ans मिलता है।

@jnothman आपको क्या लगता है कि मुझे तब क्या करना चाहिए? जैसा कि समस्या के ऊपर मेरी टिप्पणी में उल्लेख किया गया है, संभवतः sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y)) का उपयोग करके यूक्लिडियन दूरी की गणना कर रहा है

तो आप कह रहे हैं कि डॉट उत्पाद-तत्कालीन राशि की तुलना में कम सटीक परिणाम दे रहा है?

नहीं, जो मैं कहने की कोशिश कर रहा हूं वह उत्पाद-तब-योग की तुलना में अधिक सटीक परिणाम दे रहा है
-2 * np.dot(X, Y.T) + (X * X).sum(axis=1) + (Y * Y).sum(axis=1) आउटपुट [[0.]]
जबकि np.sqrt(((X-Y) * (X-Y)).sum(axis=1)) आउटपुट [ 0.02290595]

यह स्पष्ट नहीं है कि आप क्या कर रहे हैं, आंशिक रूप से क्योंकि आप पूरी तरह से स्टैंड-अलोन स्निपेट पोस्ट नहीं कर रहे हैं।

आपकी अंतिम पोस्ट को जल्दी से देखने के बाद आप जिन दो चीजों की तुलना करने की कोशिश कर रहे हैं, वे [[0.]] और [0.022...] समान आयाम नहीं हैं (शायद एक कॉपी और पेस्ट समस्या है, लेकिन फिर से जानना मुश्किल है क्योंकि हम नहीं करते हैं एक पूर्ण स्निपेट है)।

ओके सॉरी मेरी बुर

import numpy as np
import scipy
from sklearn.metrics.pairwise import check_pairwise_arrays, row_norms
from sklearn.utils.extmath import safe_sparse_dot

# create 64-bit vectors a and b that are very similar to each other
a_64 = np.array([61.221637725830078125, 71.60662841796875,    -65.7512664794921875],  dtype=np.float64)
b_64 = np.array([61.221637725830078125, 71.60894012451171875, -65.72847747802734375], dtype=np.float64)

# create 32-bit versions of a and b
X = a_64.astype(np.float32)
Y = b_64.astype(np.float32)

X, Y = check_pairwise_arrays(X, Y)
XX = row_norms(X, squared=True)[:, np.newaxis]
YY = row_norms(Y, squared=True)[np.newaxis, :]

#Euclidean distance computed using product-then-sum
distances = safe_sparse_dot(X, Y.T, dense_output=True)
distances *= -2
distances += XX
distances += YY
print(np.sqrt(distances))

#Euclidean distance computed using (X-Y)^2
print(np.sqrt(row_norms(X-Y, squared=True)[:, np.newaxis]))

आउटपुट

[[ 0.03125]]
[[ 0.02290595136582851409912109375]]

पहली विधि यह है कि यह यूक्लिडियन दूरी फ़ंक्शन द्वारा कैसे गणना की जाती है।
यह भी स्पष्ट करने के लिए कि मेरे कहने का मतलब यह था कि योग करने के बाद भी जब हम ऐसा करने के लिए सुन्न कार्यों का उपयोग करते हैं, तब योग सटीक होता है

हां, मैं इसे दोहरा सकता हूं। मुझे लगता है कि शुरू में घटाव कर रही है
अंतर की शुद्धता बनाए रखने की अनुमति देता है। बिंदी लगाना
उत्पाद और फिर घटाना (या जोड़ना और जोड़ना), जैसा कि हम वर्तमान में करते हैं,
सबसे महत्वपूर्ण आंकड़े की तुलना में इस सटीकता को खो देता है
अंतर।

वर्तमान कार्यान्वयन अधिक संख्या के लिए अधिक स्मृति कुशल है
विशेषताएं। लेकिन मुझे लगता है कि यूक्लिडियन दूरी तेजी से अप्रासंगिक हो जाती है
उच्च आयामों में, इसलिए मेमोरी आउटपुट की संख्या पर हावी है
मान।

इसलिए मैं अधिक संख्यात्मक रूप से स्थिर कार्यान्वयन को अपनाने के लिए मतदान करता हूं
d-asymptotically कुशल कार्यान्वयन जो वर्तमान में हमारे पास है। एक सुझाव,
@ogrisel? @agramfort?

और यह निश्चित रूप से एक चिंता का विषय है क्योंकि हमने हाल ही में फ्लोट 32s की अनुमति दी थी
अनुमानकर्ताओं के बीच अधिक सामान्य होना।

तो इस उदाहरण के लिए उत्पाद-तब-योग np.float64 के लिए पूरी तरह से ठीक काम करता है, इसलिए इनपुट को फ्लोट64 में परिवर्तित करने के लिए एक संभावित समाधान हो सकता है, फिर परिणाम की गणना करें और परिणाम को वापस फ्लोट 32 में परिवर्तित कर दें। मुझे लगता है कि यह अधिक कुशल होगा, लेकिन यकीन नहीं होगा कि यह किसी अन्य उदाहरण के लिए ठीक काम करेगा।

float64 में कनवर्ट करने से मेमोरी उपयोग में अधिक कुशल नहीं होगा
घटाव।

ओह, हाँ, आपको इसके बारे में सही खेद है, लेकिन मुझे लगता है कि फ्लोट64 का उपयोग करना और फिर उत्पाद करना-तब-योग करना अधिक कुशल कम्प्यूटेशनल होगा यदि मेमोरी बुद्धिमान नहीं है।

और उत्पाद-तब-योग का उपयोग करने का कारण अधिक कम्प्यूटेशनल दक्षता और स्मृति दक्षता नहीं होना था।

यकीन है, लेकिन मुझे विश्वास नहीं है कि यह मानने का कोई कारण है कि यह वास्तव में है
महसूस करने के लिए नहीं होने के तरीके के अलावा अधिक कम्प्यूटेशनल रूप से कुशल
मध्यवर्ती सरणी। यह मानते हुए कि हम पूर्ण कार्य स्मृति (जैसे) के द्वारा सीमित करते हैं
चूनिंग), डॉट उत्पाद को क्यों लेना, मानदंडों को दोगुना और घटाना होगा
घटाना और वर्ग की तुलना में बहुत अधिक कुशल हो?

बेंचमार्क प्रदान करें?

ठीक है, इसलिए मैंने घटाव-तब-स्क्वरिंग और फ़्लोट64 के लिए रूपांतरण और फिर उत्पाद-तब-योग द्वारा लिए गए समय की तुलना करने के लिए एक पायथन स्क्रिप्ट बनाई और यह पता चला कि अगर हम एक एक्स और वाई को बहुत बड़े वैक्टर के रूप में चुनते हैं तो 2 परिणाम बहुत अलग हैं । इसके अलावा @jnothman आप सही घटाव-तब-
यहां वह स्क्रिप्ट है जो मैंने लिखी है, अगर कोई समस्या है तो कृपया मुझे बताएं

import numpy as np
import scipy
from sklearn.metrics.pairwise import check_pairwise_arrays, row_norms
from sklearn.utils.extmath import safe_sparse_dot
from timeit import default_timer as timer

for i in range(9):
    X = np.random.rand(1,3 * (10**i)).astype(np.float32)
    Y = np.random.rand(1,3 * (10**i)).astype(np.float32)

    X, Y = check_pairwise_arrays(X, Y)
    XX = row_norms(X, squared=True)[:, np.newaxis]
    YY = row_norms(Y, squared=True)[np.newaxis, :]

    #Euclidean distance computed using product-then-sum
    distances = safe_sparse_dot(X, Y.T, dense_output=True)
    distances *= -2
    distances += XX
    distances += YY

    ans1 = np.sqrt(distances)

    start = timer()
    ans2 = np.sqrt(row_norms(X-Y, squared=True)[:, np.newaxis])
    end = timer()
    if ans1 != ans2:
        print(end-start)

        start = timer()
        X = X.astype(np.float64)
        Y = Y.astype(np.float64)
        X, Y = check_pairwise_arrays(X, Y)
        XX = row_norms(X, squared=True)[:, np.newaxis]
        YY = row_norms(Y, squared=True)[np.newaxis, :]
        distances = safe_sparse_dot(X, Y.T, dense_output=True)
        distances *= -2
        distances += XX
        distances += YY
        distances = np.sqrt(distances)
        end = timer()
        print(end-start)
        print('')
        if abs(ans2 - distances) > 1e-3:
            # np.set_printoptions(precision=200)
            print(ans2)
            print(np.sqrt(distances))

            print(X, Y)
            break

यह परीक्षण के लायक है कि यह नमूनों की संख्या के साथ कैसे मापता है, न कि केवल
सुविधाओं की संख्या ... मानदंड लेने से कुछ कंप्यूटिंग के लाभ हो सकते हैं
नमूने के अनुसार एक बार, नमूने की जोड़ी के अनुसार एक बार नहीं

20 अक्टूबर 2017 को 2:39 बजे, "ओशैद रहमान नासिर" सूचनाएं @github.com
लिखा था:

ठीक है तो मैंने समय की तुलना करने के लिए एक अजगर स्क्रिप्ट बनाई
घटाव-तब-वर्ग और फ़्लोट64 में रूपांतरण तब उत्पाद-तब-योग
और यह पता चला कि यदि हम एक X और Y को बहुत बड़े वैक्टर के रूप में चुनते हैं तो 2
परिणाम बहुत अलग हैं। इसके अलावा @jnothman https://github.com/jnothman
आप सही घटाव थे-तब-स्क्वैरिंग तेज है।
यहां वह स्क्रिप्ट है जो मैंने लिखी है, अगर कोई समस्या है तो कृपया मुझे बताएं

आयात एनपीपी के रूप में सुन्न
आयात से डर लगता है
sklearn.metrics.pairwise आयात से check_pairwise_arrays, row_norms
sklearn.utils.extmath से safe_sparse_dot आयात करें
टाइमर के रूप में समय-समय पर आयात default_timer

मैं सीमा में (9):
X = np.random.rand (1,3 * (10 i))। astype (np.float32)Y = np.random.rand (1,3 * (10 i))। astype (np.float32)

X, Y = check_pairwise_arrays (X, Y)
XX = row_norms (X, चुकता = सत्य) [:, np.newaxis]
YY = row_norms (Y, चुकता = सत्य) [np.newaxis,:]

# यूक्लिडियन दूरी उत्पाद-तब-योग का उपयोग कर गणना की
दूरी = safe_sparse_dot (X, YT, dense_output = True)
दूरी * = -2
दूरी + = XX
दूरियाँ = = YY

ans1 = np.sqrt (दूरियां)

स्टार्ट = टाइमर ()
ans2 = np.sqrt (row_norms (XY, चुकता = सत्य) [:, np.newaxis])
अंत = टाइमर ()
अगर ans1! = ans2:
प्रिंट (अंत से शुरू)

  start = timer()
  X = X.astype(np.float64)
  Y = Y.astype(np.float64)
  X, Y = check_pairwise_arrays(X, Y)
  XX = row_norms(X, squared=True)[:, np.newaxis]
  YY = row_norms(Y, squared=True)[np.newaxis, :]
  distances = safe_sparse_dot(X, Y.T, dense_output=True)
  distances *= -2
  distances += XX
  distances += YY
  distances = np.sqrt(distances)
  end = timer()
  print(end-start)
  print('')
  if abs(ans2 - distances) > 1e-3:
      # np.set_printoptions(precision=200)
      print(ans2)
      print(np.sqrt(distances))

      print(X, Y)
      break

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/9354#issuecomment-337948154 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAEz6z5o2Ao_7V5-Lflb4HosMrHCeOrVks5st209gaJpZM4OXbpZ
।

वैसे भी, क्या आप PR, @ragnerok सबमिट करना चाहेंगे?

हाँ, यकीन है, तुम मुझे क्या करना चाहते हो?

एक और अधिक स्थिर कार्यान्वयन प्रदान करें, यह भी एक परीक्षण है कि के तहत विफल हो जाएगा
वर्तमान कार्यान्वयन, और आदर्श रूप से एक बेंचमार्क जो दिखाता है कि हम नहीं खोते हैं
परिवर्तन से बहुत, उचित मामलों में।

मैं पूछना चाहता था कि क्या वेक्टर के साथ पंक्तियों की प्रत्येक जोड़ी के बीच दूरी तय करना संभव है। मैं इसके बारे में सोच नहीं सकता कि इसे कैसे किया जाए।

आप पंक्तियों के जोड़े के बीच अंतर (दूरी नहीं) का मतलब है? यदि आप सुन्न सरणियों के साथ काम कर रहे हैं तो आप यह कर सकते हैं। यदि आपके पास आकृतियों (n_samples1, n_features) और (n_samples2, n_features) के साथ सरणियाँ हैं, तो आपको इसे (n_samples1, 1, n_features) और (1, n_samples2, n_features) को पुन: व्यवस्थित करने की आवश्यकता है।

>>> X = np.random.randint(10, size=(10, 5))
>>> Y = np.random.randint(10, size=(11, 5))
X.reshape(-1, 1, X.shape[1]) - Y.reshape(1, -1, X.shape[1])

हाँ धन्यवाद कि वास्तव में मदद की 😄

मैं यह भी पूछना चाहता था कि क्या मैं एक अधिक स्थिर कार्यान्वयन प्रदान करता हूं मैं X_norm_squared और Y_norm_squared का उपयोग नहीं करूंगा। तो क्या मैं उन्हें तर्कों से भी हटा दूं या मुझे इस बारे में चेतावनी देनी चाहिए कि यह किसी काम का नहीं है?

मुझे लगता है कि उन्हें पदावनत कर दिया जाएगा, लेकिन हमें पहले यह आश्वासन देना होगा
ऐसा कोई मामला नहीं है जहां हमें उस संस्करण को रखना चाहिए।

हम इसे बदलने में काफी सावधान रहने वाले हैं। यह एक व्यापक रूप से इस्तेमाल किया और है
लंबे समय तक कार्यान्वयन। हमें यह सुनिश्चित करना चाहिए कि किसी भी महत्वपूर्ण को धीमा न करें
मामलों। हम उच्च स्मृति से बचने के लिए विखंडू में ऑपरेशन करने की आवश्यकता हो सकती है
उपयोग (जो शायद इस तथ्य से पेचीदा बना है कि यह कहा जाता है
उन कार्यों के भीतर जो आउटपुट मेमोरी से सेवानिवृत्ति को कम करने के लिए कबाड़ करते हैं
जोड़ीदार दूरी)।

मैं वास्तव में अन्य कोर देवों से सुनना चाहूंगा जो कम्प्यूटेशनल के बारे में जानते हैं
लागत और संख्यात्मक परिशुद्धता ... @ogrisel , @lesteve , @rth ...

5 नवंबर 2017 को 5:27 बजे, "ओशैद रहमान नासिर" सूचनाएं @github.com
लिखा था:

मैं यह भी पूछना चाहता था कि क्या मैं एक अधिक स्थिर कार्यान्वयन प्रदान करूँगा जो मैं नहीं करूँगा
X_norm_squared और Y_norm_squared का उपयोग करना। तो क्या मैं उन्हें हटा दूं
तर्क के रूप में अच्छी तरह से या मैं इसके बारे में चेतावनी देना चाहिए किसी भी काम का नहीं है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/9354#issuecomment-341919282 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAEz63izdpQGDEuW32m8Aob6rrsvV6q-ks5szKyHgaJpZM4OXbpZ
।

लेकिन यदि आप एक पीआर खोलते हैं तो ठीक-ठीक चर्चा करना आसान होगा

ठीक है, मैं इस समारोह के एक बहुत ही बुनियादी कार्यान्वयन के साथ एक पीआर तो खोलूंगा

सवाल यह है कि 0.20 रिलीज के लिए इसके बारे में क्या किया जाना चाहिए। क्या कुछ सरल / अस्थायी सुधार (स्मृति उपयोग की लागत पर घटना) पर विचार किया जा सकता है?

# 11271 में प्रस्तावित समाधान और विश्लेषण निश्चित रूप से बहुत मूल्यवान हैं, लेकिन यह इष्टतम समाधान है यह सुनिश्चित करने के लिए कुछ और चर्चा की आवश्यकता हो सकती है। विशेष रूप से, मैं इस तथ्य से चिंतित हूं कि अब हमारे पास CPU प्रकार आदि के आधार पर https://github.com/scikit-learn/scikit-learn/issues/11506 में इष्टतम वैश्विक कामकाजी स्मृति के बारे में कुछ लंबित चर्चा है। अभी तक दूसरे स्तर के मंथन को जोड़ा जाएगा और संपूर्ण की जटिलता आईएमओ को थोड़ा नियंत्रित करेगी। लेकिन शायद यह सिर्फ मुझे है, एक दूसरी राय की तलाश में।

आपको क्या लगता है कि रिलीज के लिए इस मुद्दे के बारे में क्या किया जाना चाहिए @jnothman @amueller @ogrisel ?

स्थिरता ट्रम्प दक्षता। स्थिरता के मुद्दों को भी जब तय किया जाना चाहिए
दक्षता अभी भी tweaks की जरूरत है।

working_memory का ध्यान बड़े नमूने के साथ सिल्हूट जैसी चीजों को बनाने के लिए था
आकार काम करते हैं। यह भी दक्षता में सुधार हुआ है, लेकिन यह नीचे tweaked किया जा सकता है
लाइन।

मेरा दृढ़ता से मानना ​​है कि हमें यूक्लिडियन_डिस्टेंस के लिए एक फिक्स पाने की कोशिश करनी चाहिए
फ्लोट 32 इन। हमने यह मानकर 0.19 में तोड़ दिया कि हम बना सकते हैं
euclidean_distances 32 बिट पर एक भोले तरीके से काम करता है।

मैं मानता हूं कि हमें एक सुधार की आवश्यकता है। यहां मेरी चिंता दक्षता नहीं है, लेकिन कोड आधार में जोड़ा जटिलता है।

एक कदम पीछे लेते हुए, स्कैपी के यूक्लिडियन कार्यान्वयन सी कोड की 10 लाइनें लगती हैं और 32 बिट के लिए, बस उन्हें 64 बिट में डाल दिया जाता है। मैं समझता हूं कि यह सबसे तेज़ नहीं है, लेकिन यह वैचारिक रूप से अनुसरण करने और समझने में आसान है। स्किकिट-लर्न में, हम BLAS में तेजी से गणना करने के लिए ट्रिक का उपयोग करते हैं, फिर https://github.com/scikit-learn/scikit-learn/pull/10212 और अब यूक्लिडियन के संभावित संभावित समाधान के कारण संभावित सुधार होते हैं। 32 बिट में दूरी।

मैं सिर्फ इस विषय पर सामान्य दिशा क्या होनी चाहिए, जैसे इनपुट के लिए देख रहा हूँ (जैसे कि इसे कुछ को ऊपर करने के लिए इसे स्कैपी आदि करने की कोशिश करें)।

डेटा कॉपी करके चिंतित नहीं लगता है ...

पीआर के बाद 0.21 पर जाएं।

अवरोधक निकालें?

sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y))

संख्यात्मक रूप से अस्थिर है, यदि डॉट (x, x) और डॉट (y, y) समान परिमाण के हैं जैसे कि डॉट (x, y) के रूप में जाना जाता है, जिसे भयावह रद्द के रूप में जाना जाता

यह न केवल FP32 परिशुद्धता को प्रभावित करता है, लेकिन यह निश्चित रूप से अधिक प्रमुख है, और बहुत पहले विफल हो जाएगा।

यहां एक सरल परीक्षण मामला दिखाया गया है कि यह दोहरी परिशुद्धता के साथ कितना बुरा है:

import numpy
from sklearn.metrics.pairwise import euclidean_distances

a = numpy.array([[100000001, 100000000]])
b = numpy.array([[100000000, 100000001]])

print "skelarn:", euclidean_distances(a, b)[0,0]
print "correct:", numpy.sqrt(numpy.sum((a-b)**2))

a = numpy.array([[10001, 10000]], numpy.float32)
b = numpy.array([[10000, 10001]], numpy.float32)

print "skelarn:", euclidean_distances(a, b)[0,0]
print "correct:", numpy.sqrt(numpy.sum((a-b)**2))

स्केलेरन sqrt (2) के बजाय दोनों बार 0 की दूरी की गणना करता है।

विचरण और सहसंयोजक के लिए संख्यात्मक मुद्दों की एक चर्चा - और यह तुच्छ रूप से यूक्लिडियन दूरी को तेज करने के इस दृष्टिकोण पर ले जाता है - यहां पाया जा सकता है:

एरिक शुबर्ट, और माइकल गर्ट्ज़।
संख्यात्मक रूप से स्थिर समानांतर संगणना (सह) भिन्न।
में: वैज्ञानिक और सांख्यिकीय डेटाबेस प्रबंधन (SSDBM), बोलजानो-बोजन, इटली पर 30 वें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही। 2018, 10: 1-10: 12

वास्तव में y समन्वय को उस परीक्षण मामले से हटाया जा सकता है, सही दूरी तब तुच्छ हो जाती है। 1. मैंने एक पुल अनुरोध किया है जो इस संख्यात्मक समस्या को ट्रिगर करता है:

    XA = np.array([[10000]], np.float32)
    XB = np.array([[10001]], np.float32)
    assert_equal(euclidean_distances(XA, XB)[0,0], 1)

मुझे नहीं लगता कि ऊपर उल्लिखित मेरा पेपर इस समस्या का समाधान प्रदान करता है - बस यूक्लिडियन की गणना sqrt (योग (पावर))) के रूप में करें और यह एकल-पास है और इसमें उचित परिशुद्धता है। नुकसान पहले से ही, यानी, डॉट (एक्स, एक्स) का उपयोग करके पहले से ही परिशुद्धता खो रहा है।

समस्या के रूप में @amueller समस्या से अधिक गंभीर हो सकता है, मेरा सुझाव है कि अवरोधक लेबल को फिर से जोड़ना ...

इस बहुत सरल उदाहरण के लिए धन्यवाद।

इसे इस तरह से लागू करने का कारण यह है क्योंकि यह तेजी से रास्ता है। निचे देखो:

x = np.random.random_sample((1000, 1000))

%timeit euclidean_distances(x,x)
20.6 ms ± 452 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit cdist(x,x)
695 ms ± 4.06 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

यद्यपि ऑपरेशन की संख्या दोनों विधियों में समान क्रम की है (दूसरे में 1.5x अधिक), स्पीडअप मैट्रिक्स मैट्रिक्स गुणन के लिए अच्छी तरह से अनुकूलित बीएलएएस पुस्तकालयों का उपयोग करने की संभावना से आता है।

यह स्कोर-लर्न में कई अनुमानकों के लिए एक बड़ी मंदी होगी।

हां, लेकिन एफपी 32 के साथ परिशुद्धता के सिर्फ 3-4 अंक , और एफपी 64 के साथ 7-8 अंक पर्याप्त वृद्धि का कारण बनता है, है ना? विशेष रूप से, चूंकि ऐसी त्रुटियां बढ़ जाती हैं ...

वैसे मैं यह नहीं कह रहा हूँ कि यह अभी ठीक है। :)
मैं कह रहा हूं कि हमें बीच में इसका समाधान खोजने की जरूरत है।
एक पीआर (# 11271) है जो कम्प्यूटेशन करने के लिए फ्लोट64 पर डालने का प्रस्ताव करता है। फ्लोट64 के लिए समस्या को ठीक नहीं करता है, लेकिन फ्लोट 32 के लिए बेहतर परिशुद्धता देता है।

क्या आपके पास एक उदाहरण है जहां एक अनुमानक का उपयोग करते हुए जो कि यूक्लिडियन_डिस्टेंस का उपयोग करता है, परिशुद्धता के नुकसान के कारण गलत परिणाम देता है?

मुझे निश्चित रूप से अभी भी लगता है कि यह एक बड़ी बात है और 0.21 के लिए अवरोधक होना चाहिए। यह 0.19 में 32 बिट के लिए पेश किया गया एक मुद्दा था, और इसे छोड़ने के लिए मामलों की एक अच्छी स्थिति नहीं है। काश हमने इसे पहले 0.20 में हल कर लिया होता, और मैं ठीक होता, या यहां तक ​​कि उत्सुक होता, # 11271 अंतरिम में विलीन होता। उस पीआर में केवल एक ही मुद्दा है कि मैं स्मृति दक्षता के चारों ओर अनुकूलन को जानता हूं, जो एक गहरी खरगोश छेद है।

हमारे पास लंबे समय तक इसका "तेज़" संस्करण है, लेकिन हमेशा फ़्लोट 64 में। मुझे पता है, @ kno10 , कि यह सटीक के साथ मुद्दों मिल गया है। जब आप एक समस्या हो सकती है और धीमी-धीमी-लेकिन-समाधान का उपयोग कर सकते हैं, तो क्या हमारे पास एक अच्छा और तेज़ उत्तराधिकार है?

हां, लेकिन एफपी 32 के साथ परिशुद्धता के सिर्फ 3-4 अंक, और एफपी 64 के साथ 7-8 अंकों में पर्याप्त वृद्धि नहीं होती है, यह नहीं है

बहुत सरल उदाहरण के साथ इस मुद्दे को चित्रित करने के लिए धन्यवाद!

मुझे नहीं लगता कि यह मुद्दा उतना ही व्यापक है जितना कि आप सुझाव देते हैं, हालांकि - यह ज्यादातर नमूनों को प्रभावित करता है जिनकी आपसी दूरी उनके मानदंडों के संबंध में छोटी है।

नीचे का आंकड़ा इसे दिखाता है, 2e6 यादृच्छिक नमूना जोड़े के लिए, जहां प्रत्येक 1D नमूने अंतराल [-100, 100] में हैं। स्किटिट-लर्न और स्किपी कार्यान्वयन के बीच की सापेक्ष त्रुटि को नमूने के बीच की दूरी के एक फ़ंक्शन के रूप में प्लॉट किया जाता है, जो उनके एल 2 मानदंडों द्वारा सामान्यीकृत होता है, अर्थात।

d_norm(A, B) = d(A, B) / sqrt(‖A‖₂*‖B‖₂)

(यकीन नहीं कि यह सही पैराट्रिजेशन है, लेकिन डेटा पैमाने पर कुछ हद तक परिणाम प्राप्त करने के लिए बस),

उदाहरण के लिए,

1. यदि कोई [10000] और [10001] L2 सामान्यीकृत दूरी 1e-4 लेता है और दूरी की गणना पर सापेक्ष त्रुटि 64 बिट में 1e-8 और 32 बिट (1e) में> 1 हो जाएगी -8 और> 1 निरपेक्ष मूल्य में क्रमशः)। 32 बिट में यह मामला वास्तव में काफी भयानक है।
2. दूसरी तरफ [1] और [10001] , सापेक्ष त्रुटि 32 बिट में ~ 1e-7, या अधिकतम संभव परिशुद्धता होगी।

सवाल यह है कि मामला 1. अक्सर एमएल अनुप्रयोगों में व्यवहार में कैसे होगा।

दिलचस्प बात यह है कि अगर हम 2 डी पर जाते हैं, फिर से एक समान यादृच्छिक वितरण के साथ, उन बिंदुओं को खोजना मुश्किल होगा जो बहुत करीब हैं,

बेशक, वास्तव में हमारे डेटा को समान रूप से नमूना नहीं किया जाएगा, लेकिन किसी भी वितरण के लिए आयामीता के अभिशाप के कारण किसी भी दो बिंदुओं के बीच की दूरी धीरे-धीरे बहुत समान मूल्यों (0 से अलग) के रूप में परिवर्तित हो जाएगी क्योंकि विचलन बढ़ जाता है। हालांकि यह एक सामान्य एमएल मुद्दा है, यहां यह अपेक्षाकृत कम आयामीता के लिए भी इस सटीकता की समस्या को कम कर सकता है। n_features=5 के परिणामों के नीचे,
।

तो केंद्रित डेटा के लिए, कम से कम 64 बिट में, यह व्यवहार में एक मुद्दे का इतना नहीं हो सकता है (यह मानते हुए कि अधिक हैं तो 2%)। 50x कम्प्यूटेशनल स्पीड-अप (जैसा कि ऊपर सचित्र है) इसके लायक हो सकता है (64 बिट में)। बेशक [1, 1] में सामान्य रूप से कुछ डेटा में 1e6 जोड़ सकते हैं और कह सकते हैं कि परिणाम सटीक नहीं हैं, लेकिन मैं तर्क दूंगा कि एक ही संख्या के संख्यात्मक एल्गोरिदम पर लागू होता है, और 6 में व्यक्त डेटा के साथ काम करना महत्वपूर्ण अंक बस परेशानी की तलाश में है।

(उपरोक्त आंकड़ों के लिए कोड यहां पाया जा सकता

डॉट (x, x) + डॉट (y, y) -2 डॉट (x, y) संस्करण का उपयोग करने वाले किसी भी तेज़ दृष्टिकोण मेरा मानना ​​है कि आपको अनुमानित उत्पादों की सटीकता को दोगुना करना होगा। की शुद्धता (और मुझे लगता है कि अगर कोई उपयोगकर्ता float32 डेटा प्रदान करता है, तो वे float32 परिशुद्धता चाहते हैं, float64 के साथ, वे float64 परिशुद्धता चाहते हैं)। आप इसे कुछ ट्रिक्स (कहन समन के बारे में सोच सकते हैं) के साथ कर सकते हैं, लेकिन यह आपके द्वारा पहले स्थान पर प्राप्त किए गए खर्च की तुलना में बहुत अधिक होने की संभावना है।

मैं यह नहीं बता सकता कि इस दृष्टिकोण का उपयोग करने के लिए आप फ्लोट 32 को फ्लोट64 में फ़्लोट64 में परिवर्तित करने से कितना ओवरहेड प्राप्त करते हैं। कम से कम फ्लोट 32 के लिए, मेरी समझ में, सभी संगणनाएं करना और फ्लोट 64 के रूप में डॉट उत्पादों को संग्रहीत करना ठीक होना चाहिए।

IMHO, प्रदर्शन लाभ (जो घातांक नहीं हैं, बस एक स्थिर कारक हैं) परिशुद्धता में नुकसान के लायक नहीं हैं (जो आपको अप्रत्याशित रूप से काट सकते हैं) और उचित तरीका इस समस्याग्रस्त चाल का उपयोग नहीं करना है। हालांकि, यह "पारंपरिक" गणना करने वाले कोड को और अधिक अनुकूलित करने के लिए अच्छी तरह से संभव हो सकता है, उदाहरण के लिए AVX का उपयोग करने के लिए। क्योंकि सम ((xy) * 2) AVX में लागू करने के लिए सभी मुश्किल है।कम से कम, मैं कभी-कभी कम परिशुद्धता के कारण approximate_euclidean_distances लिए विधि का नाम बदलने का सुझाव दूंगा, (जो कि करीब दो मूल्यों को खराब करता है, जो * शुरू में ठीक हो सकती है) , ताकि उपयोगकर्ताओं को इस मुद्दे के बारे में पता हो।

@ चित्र के लिए धन्यवाद। लेकिन क्या होगा अगर आप ऑप्टिमाइज़ करने की कोशिश कर रहे हैं, जैसे, एक्स कुछ इष्टतम की ओर। सबसे अधिक संभावना यह है कि इष्टतम शून्य पर नहीं होगा (यदि यह हमेशा आपका डेटा केंद्र होगा, तो जीवन बहुत अच्छा होगा), और अंततः आपके द्वारा ग्रेडर आदि के लिए गणना किए जाने वाले डेल्टा में कुछ बहुत छोटे अंतर हो सकते हैं।
इसी तरह, क्लस्टरिंग में, क्लस्टर्स के पास अपने केंद्र शून्य के करीब नहीं होंगे, लेकिन विशेष रूप से कई समूहों के साथ, कुछ अंकों के साथ x digit केंद्र काफी संभव है।

कुल मिलाकर, मैं मानता हूं कि इस मुद्दे को ठीक करने की आवश्यकता है। किसी भी मामले में हमें वर्तमान कार्यान्वयन के सटीक मुद्दों को जल्द से जल्द दस्तावेज़ करने की आवश्यकता है।

सामान्य तौर पर हालांकि मुझे नहीं लगता कि यह चर्चा डरावनी सीख में होनी चाहिए। यूक्लिडियन दूरी का उपयोग वैज्ञानिक कंप्यूटिंग के विभिन्न क्षेत्रों में किया जाता है और आईएमओ स्कैपी मेलिंग सूची या मुद्दों पर चर्चा करने के लिए एक बेहतर स्थान है: इस तरह के संख्यात्मक सटीक मुद्दों के साथ समुदाय को भी अधिक अनुभव है। वास्तव में हमारे यहां जो कुछ भी है वह एक तेज लेकिन कुछ हद तक अनुमानित एल्गोरिथ्म है। हमें अल्पावधि में कुछ सुधारों को लागू करना पड़ सकता है, लेकिन लंबी अवधि में यह जानना अच्छा होगा कि इसमें योगदान दिया जाएगा।

32 बिट के लिए, https://github.com/scikit-learn/scikit-learn/pull/11271 वास्तव में एक समाधान हो सकता है, मैं सिर्फ पुस्तकालय के माध्यम से सभी के कई स्तरों के लिए उत्सुक नहीं हूं क्योंकि इससे कोड की कार्यक्षमता बढ़ जाती है , और यह सुनिश्चित करना चाहते हैं कि इसके आसपास कोई बेहतर तरीका न हो।

आपकी प्रतिक्रिया के लिए धन्यवाद @ kno10! (मेरी उपरोक्त टिप्पणियां इसे अभी तक ध्यान में नहीं लेती हैं) मैं थोड़ा बाद में जवाब दूंगा।

हां, मूल के बाहर किसी बिंदु पर अभिसरण एक मुद्दा हो सकता है।

IMHO, प्रदर्शन लाभ (जो घातांक नहीं हैं, बस एक स्थिर कारक हैं) परिशुद्धता में नुकसान के लायक नहीं हैं (जो आपको अप्रत्याशित रूप से काट सकते हैं) और उचित तरीका इस समस्याग्रस्त चाल का उपयोग नहीं करना है।

खैर 64 बिट में उनकी गणना के लिए एक> 10x धीमा उपयोगकर्ताओं पर बहुत वास्तविक प्रभाव पड़ेगा।

हालांकि, यह "पारंपरिक" गणना करने वाले कोड को और अधिक अनुकूलित करने के लिए अच्छी तरह से संभव हो सकता है, उदाहरण के लिए AVX का उपयोग करने के लिए। क्योंकि सम ((xy) ** 2) AVX में लागू करने के लिए सभी मुश्किल है।

सुंबा (जिसे SSE का उपयोग करना चाहिए) के साथ एक त्वरित भोली कार्यान्वयन की कोशिश की,

@numba.jit(nopython=True, fastmath=True)              
def pairwise_distance_naive(A, B):
    n_samples_a, n_features_a = A.shape
    n_samples_b, n_features_b = B.shape
    assert n_features_a == n_features_b
    distance = np.empty((n_samples_a, n_samples_b), dtype=A.dtype)
    for i in range(n_samples_a):
        for j in range(n_samples_b):
            psum = 0.0
            for k in range(n_features_a):
                psum += (A[i, k] - B[j, k])**2
            distance[i, j] = math.sqrt(psum)
    return distance

cdist अब तक (लेकिन मैं सुंबा विशेषज्ञ नहीं हूं) को डराने के लिए समान गति प्राप्त करना, और fastmath के प्रभाव के बारे में भी निश्चित नहीं हूं।

डॉट (x, x) + डॉट (y, y) -2 * डॉट (x, y) संस्करण का उपयोग करना

केवल भविष्य के संदर्भ के लिए, वर्तमान में हम जो कर रहे हैं वह लगभग निम्नलिखित है (क्योंकि एक आयाम है जो उपरोक्त संकेतन में नहीं दिखता है),

def quadratic_pairwise_distance(A, B):
    A2 = np.einsum('ij,ij->i', A, A)
    B2 = np.einsum('ij,ij->i', B, B)
    return np.sqrt(A2[:, None] + B2[None, :] - 2*np.dot(A, B.T))

जहाँ दोनों einsum और dot अब BLAS का उपयोग करते हैं। मुझे आश्चर्य है, अगर बीएलएएस का उपयोग करने से अलग किया जाता है, तो यह वास्तव में ऊपर के पहले संस्करण के समान गणितीय संचालन भी करता है।

मुझे आश्चर्य है, अगर बीएलएएस का उपयोग करने से अलग किया जाता है, तो यह वास्तव में ऊपर के पहले संस्करण के समान गणितीय संचालन भी करता है।

सं। ((X - y) * 2.sum ()) करता है* n_samples_x * n_samples_y * n_features * (1 घटाव + 1 जोड़ + 1 गुणन)
जबकि xx + yy -2x.y प्रदर्शन करता है
n_samples_x * n_samples_y * n_features * (1 जोड़ + 1 गुणन) ।
2 संस्करणों के बीच संचालन की संख्या के लिए 2/3 अनुपात है।

उपरोक्त चर्चा के बाद,

• पीआर को वैकल्पिक रूप से यूक्लिडियन दूरियों की गणना करने की अनुमति दें https://github.com/scikit-learn/scikit-learn/pull/12136
• कुछ WIP यह देखने के लिए कि क्या हम https://github.com/scikit-learn/scikit-learn/pull/12142 में समस्याग्रस्त बिंदुओं का पता लगा सकते हैं और उन्हें कम कर सकते हैं

32 बिट के लिए, हमें अभी भी https://github.com/scikit-learn/scikit-learn/pull/11271 को किसी न किसी रूप में मर्ज करने की आवश्यकता है, हालांकि IMO, उपरोक्त पीआरओ इसके लिए कुछ हद तक रूढ़िवादी हैं।

FYI करें: ऑप्टिक्स में कुछ मुद्दों को ठीक करते समय, और ELKI से संदर्भ परिणामों का उपयोग करने के लिए परीक्षण को ताज़ा करते हुए, ये metric="euclidean" साथ विफल होते हैं लेकिन metric="minkowski" साथ सफल होते हैं। संख्यात्मक अंतर एक अलग प्रसंस्करण आदेश का कारण बनने के लिए पर्याप्त हैं (बस थ्रेसहोल्ड घटाना पर्याप्त नहीं है)।

https://github.com/kno10/scikit-learn/blob/ab544709a392e4dc7b22e9fd60c4755baf3d3053/sklearn/cluster/tests/test_optics.py#L588

मैं वास्तव में इस पर नहीं पकड़ा गया हूं, लेकिन मुझे आश्चर्य है कि कोई मौजूदा समाधान नहीं है। यह एक बहुत ही सामान्य संगणना लगता है और ऐसा लगता है कि हम पहिया को फिर से मजबूत कर रहे हैं। क्या किसी ने व्यापक वैज्ञानिक कंप्यूटिंग समुदाय तक पहुंचने की कोशिश की है?

अभी तक नहीं, लेकिन मैं मानता हूं कि हमें चाहिए। इस बारे में केवल एक चीज मुझे मिली, वह थी https://github.com/scipy/scipy/pull/2815 और जुड़े हुए मुद्दे।

मुझे लगता है कि @jeremiedbb एक विचार हो सकता है?

दुर्भाग्य से एक संतोषजनक अभी तक नहीं :(

हम इस तरह की संगणना के लिए एक अत्यधिक अनुकूलित पुस्तकालय पर भरोसा करना चाहते हैं, जैसा कि हम BLBL पुस्तकालयों जैसे कि OpenBLAS या MKL के साथ रैखिक बीजगणित के लिए करते हैं। लेकिन यूक्लिडियन दूरी इसका हिस्सा नहीं है। डॉट ट्रिक ऐसा प्रयास है जो बीएलएएस स्तर 3 मैट्रिक्स-मैट्रिक्स गुणन उपखंड पर निर्भर है। लेकिन यह सटीक नहीं है और एक ही विधि का उपयोग करके इसे और अधिक सटीक बनाने का कोई तरीका नहीं है। हमें अपनी प्रत्याशा या तो गति की अवधि में या सटीकता की अवधि में कम करनी होगी।

मुझे लगता है कि कुछ स्थितियों में, पूर्ण परिशुद्धता अनिवार्य नहीं है और तेज़ विधि ठीक है। यह तब है जब "सबसे निकटतम" कार्यों को खोजने के लिए दूरियों का उपयोग किया जाता है। तेज विधि में सटीक मुद्दे तब दिखाई देते हैं जब बिंदुओं के बीच की दूरी उनके मानदंड की तुलना में छोटी होती है (फ्लोट 32 के लिए अनुपात ~ <1e-4 और float64 के लिए ~ <1e-8)। इस स्थिति के होने के लिए सबसे पहले, डेटासेट को काफी घना होना चाहिए। फिर एक ऑर्डर करने में त्रुटि होने के लिए, आपको लगभग समान दूरी के भीतर दो निकटतम बिंदुओं की आवश्यकता होगी। इसके अलावा, उस मामले में, एक एमएल के दृष्टिकोण में, दोनों लगभग समान रूप से अच्छे फिट के लिए नेतृत्व करेंगे।

उपरोक्त स्थिति में, कुछ ऐसा है जिसे हम इन गलत ऑर्डर की आवृत्ति को कम करने के लिए कर सकते हैं (नीचे 0?)। जोड़ीदार दूरी की argmin स्थिति में। हम गलत बिंदुओं को उन बिंदुओं पर ले जा सकते हैं जो निकटतम नहीं हैं। इस तथ्य का अनिवार्य रूप से उपयोग करते हुए कि अर्गमिन को खोजने के लिए आदर्श में से एक आवश्यक नहीं है, टिप्पणी देखें। इसके 2 फायदे हैं। यह अधिक मजबूत है (अब तक मुझे कोई गलत आदेश नहीं मिला है) और यह और भी तेज़ है क्योंकि यह कुछ गणनाओं से बचा जाता है।

एक खामी, अभी भी उसी स्थिति में, यदि अंत में हम निकटतम बिंदुओं के लिए वास्तविक दूरी चाहते हैं, तो उपरोक्त विधि के साथ गणना की गई दूरी का उपयोग नहीं किया जा सकता है। वे केवल आंशिक रूप से गणना की जाती हैं और वे वैसे भी सटीक नहीं हैं। हमें प्रत्येक बिंदु से निकटतम बिंदु तक दूरियों की पुन: गणना करने की आवश्यकता है। लेकिन यह तेज़ है क्योंकि प्रत्येक बिंदु के लिए गणना करने के लिए केवल एक दूरी है।

मुझे आश्चर्य है कि ऊपर वर्णित मैंने स्केलेर में यूक्लिडियन_डिस्टेंस के सभी उपयोग के मामले को कवर किया है। लेकिन मैं यह करने का सुझाव देता हूं कि जहां भी इसे लागू किया जा सकता है। ऐसा करने के लिए, हम एक नए पैरामीटर को जोड़ सकते हैं euclidean_distances केवल आवश्यक भाग की गणना करने के लिए ताकि यह argmin के साथ श्रृंखला बना सके। फिर युग्मक_डिस्टेंस_अर्गमिन में और पेयरवाइज_डिस्टेंस_अर्गेमिन_मिन में इसका उपयोग करें (बाद में अंत में वास्तविक न्यूनतम दूरी की गणना करें)।

जब हम ऐसा नहीं कर सकते हैं, तो धीमी गति से अभी तक सटीक एक पर वापस जाएं, या # 12136 में स्विच जोड़ें।
हम प्रदर्शन ड्रॉप कारण को कम करने के लिए इसे अनुकूलित करने का प्रयास कर सकते हैं क्योंकि मैं सहमत हूं कि यह इष्टतम नहीं लगता है। मेरे पास इसके लिए कुछ विचार हैं।

BLAS का उपयोग करते रहने की एक और संभावना axpy साथ nrm2 का संयोजन है, लेकिन यह इष्टतम से दूर है। दोनों BLAS स्तर 1 फ़ंक्शन हैं, और इसमें एक प्रतिलिपि शामिल है। यह केवल आयाम> 100 में तेज होगा।
आदर्श रूप से हम चाहते हैं कि यूक्लिडियन दूरी को BLAS में शामिल किया जाए ...

अंत में, वहाँ एक और समाधान है, जिसमें upcasting शामिल है। यह फ्लोट 32 के लिए # 11271 में किया गया है। लाभ यह है कि गति वर्तमान में आधी है और सटीक रखी गई है। हालाँकि यह फ़्लोट64 के लिए समस्या का समाधान नहीं करता है। हो सकता है कि हम फ्लोट64 के लिए साइथन में एक समान काम करने का एक तरीका खोज सकें। मैं ठीक से कैसे पता नहीं है, लेकिन एक float128 अनुकरण करने के लिए 2 float64 संख्याओं का उपयोग करना। मैं यह देखने की कोशिश कर सकता हूं कि क्या यह कुछ हद तक संभव है।

आदर्श रूप से हम चाहते हैं कि यूक्लिडियन दूरी को BLAS में शामिल किया जाए ...

क्या पुस्तकालयों पर विचार किया जाएगा? अगर OpenBLAS करता है तो हम पहले से ही काफी अच्छी स्थिति में होंगे ...

इसके अलावा, हमारे द्वारा इसे करने और BLAS करने के बीच सटीक अंतर क्या है? सीपीयू क्षमताओं का पता लगाना और यह तय करना कि किस कार्यान्वयन का उपयोग करना है, या ऐसा कुछ? या बस अधिक विविध आर्किटेक्चर के लिए संकलित संस्करण हैं?
या अधिक समय / ऊर्जा कुशल कार्यान्वयन लिखने में खर्च करते हैं?

यह दिलचस्प है: तेज अस्थिर विधि का एक वैकल्पिक कार्यान्वयन लेकिन स्केलेर की तुलना में बहुत तेज होने का दावा करना:
https://github.com/droyed/eucl_dist
(हालांकि इस मुद्दे को हल नहीं करता है)

यह चर्चा संबंधित https://github.com/scipy/scipy/issues/5657 से संबंधित लगती है

यहाँ क्या जूलिया करता है: https://github.com/JuliaStats/Distances.jl/blob/master/README.md#preaches -for-euclidean-and-sqeuclidean
यह पुनर्गणना के लिए एक सटीक सीमा निर्धारित करने की अनुमति देता है।

मेरे स्वयं के प्रश्न का उत्तर देते हुए: ओपनबीएलएएस के पास प्रत्येक प्रोसेसर के लिए हाथ से लिखी विधानसभा जैसा दिखता है (आर्किटेक्चर नहीं!) और विभिन्न समस्याओं के आकार के लिए गुठली चुनने की विधियां। इसलिए मुझे नहीं लगता कि यह ओपनब्लस में होने का एक मुद्दा है जितना कि उन सभी गुठली को लिखने / अनुकूलित करने के लिए किसी को खोजने के लिए ...

अतिरिक्त विचारों के लिए धन्यवाद!

आंशिक प्रतिक्रिया में,

हम इस तरह की संगणना के लिए एक अत्यधिक अनुकूलित पुस्तकालय पर भरोसा करना चाहते हैं, जैसा कि हम BLBL पुस्तकालयों जैसे कि OpenBLAS या MKL के साथ रैखिक बीजगणित के लिए करते हैं।

हाँ, मैं यह भी उम्मीद कर रहा था कि हम इसे BLAS में और कर सकते हैं। पिछली बार जब मैंने मानक बीएलएएस एपीआई में कुछ भी नहीं देखा, तो वह काफी करीब लग रहा था (लेकिन फिर मैं उन पर विशेषज्ञ नहीं हूं)। BLIS अधिक लचीलेपन की पेशकश कर सकता है, लेकिन चूंकि हम इसे डिफ़ॉल्ट रूप से उपयोग नहीं कर रहे हैं, इसलिए यह कुछ हद तक सीमित उपयोग है (हालांकि किसी दिन सुग्रीव https://github.com/numpy/numpy/issues/7372)

यहाँ क्या जूलिया करता है: यह पुनर्गणना के लिए एक सटीक सीमा निर्धारित करने की अनुमति देता है।

जान कर अच्छा लगा!

क्या हमें उपर्युक्त तेजी से अनुमानित गणना के लिए एक अलग मुद्दा खोलना चाहिए? दिलचस्प लगता है

X2-x4 के CPU पर उनका स्पीडअप https://github.com/scikit-learn/scikit-learn/pull/10212 के कारण हो सकता है।

एक बार जब हम इस प्रश्न का अध्ययन कर चुके हैं, तो मैं वहाँ पर एक समस्या को खोलना चाहूंगा, क्योंकि वहाँ मुझे उचित समाधान मिलेगा (और फिर संभवतः इसे वापस लेना) क्योंकि मुझे लगता है कि यूक्लिडियन दूरी कुछ बुनियादी है, जो एमएल के बाहर कई लोगों के लिए दिलचस्पी की होनी चाहिए। (और साथ ही सटीकता के मुद्दों पर वहां के लोगों की राय होना हेलफपुल होगा)।

यह 60x तक है, है ना?

यह दिलचस्प है: तेज अस्थिर विधि का एक वैकल्पिक कार्यान्वयन लेकिन स्केलेर की तुलना में बहुत तेज होने का दावा करना

हम उस के बारे में निश्चित नहीं हैं। वे %timeit pairwise_distances(a,b, 'sqeuclidean') बेंचमार्किंग कर रहे हैं, जो स्कैपी का उपयोग करता है। उन्हें %timeit pairwise_distances(a,b, 'euclidean', metric_params={'squared': True}) करना चाहिए और उनका स्पीडअप उतना अच्छा नहीं होगा :)
जैसा कि चर्चा में पहले दिखाया गया है, स्केलेरन स्किपी की तुलना में 35x तेज हो सकता है

हां, वे बेंचमार्क केवल ~ 30% बेहतर हैं metric="euclidean" ( squeclidean बजाय),

In [1]: from eucl_dist.cpu_dist import dist                                                                                                                  
    ... import numpy as np                                                                                                                                   
In [4]: rng = np.random.RandomState(1)                                                                                                                        
    ... a = rng.rand(1000, 300)                                                                                                                              
    ...b = rng.rand(1000, 300)                                                                                                                              

In [7]: from sklearn.metrics.pairwise import pairwise_distances                                                                                              
In [8]: %timeit pairwise_distances(a, b, 'sqeuclidean')                                                                                                      
214 ms ± 2.06 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [9]: %timeit pairwise_distances(a, b)                                                                                                                     
27.4 ms ± 2.48 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [10]: from eucl_dist.cpu_dist import dist                                                                                                                 
In [11]: %timeit dist(a, b, matmul='gemm', method='ext', precision='float32')                                                                                
20.8 ms ± 330 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [12]: %timeit dist(a, b, matmul='gemm', method='ext', precision='float64')                                                                                
20.4 ms ± 222 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

क्या पुस्तकालयों पर विचार किया जाएगा? अगर OpenBLAS करता है तो हम पहले से ही काफी अच्छी स्थिति में होंगे ...

सीधी आवाज नहीं करता। बीएलएएस रैखिक बीजगणित दिनचर्या के लिए ऐनक का एक सेट है और इसके कई कार्यान्वयन हैं। मुझे नहीं पता कि वे नए फीचर्स को जोड़ने के लिए कितने खुले हैं मूल चश्मे में नहीं। उसके लिए शायद ब्लिस अधिक खुली होगी लेकिन जैसा कि पहले कहा गया था, यह अभी के लिए डिफ़ॉल्ट नहीं है।

sqeuclidean vs euclidean हैंडलिंग pairwise_distances https://github.com/scikit-learn/scikit-learn/issues/12600 पर खोला गया।

मुझे इसके लिए कुछ स्पष्टता चाहिए। क्या हम pairwise_distances पास होना चाहते हैं - all_close ' के अर्थ में - 'यूक्लिडियन' और 'सिक्व्यूक्लाइडीन' दोनों के लिए?

यह थोड़ा मुश्किल है। क्योंकि x, y के करीब है इसका मतलब यह नहीं है कि x² y y के करीब है। स्क्वेरिंग के दौरान परिशुद्धता खो जाती है।

ऊपर जुड़ा हुआ जूलिया वर्कअराउंड बहुत ही रोचक है और इसे लागू करने के लिए सीधा है। हालाँकि मुझे संदेह है कि यह 'sqeuclidean' के लिए अपेक्षित रूप से काम नहीं करता है। मुझे संदेह है कि आपको वांछित परिशुद्धता प्राप्त करने के लिए नीचे की ओर सीमा निर्धारित करनी होगी।

बहुत कम सीमा निर्धारित करने के साथ समस्या यह है कि यह बहुत सारे पुन: अभिकलन और प्रदर्शन की एक बड़ी बूंद को प्रेरित करता है। हालाँकि यह डेटासेट के आयाम से कम है। एक ही दहलीज उच्च आयाम (दूरियां बड़ी हैं) में कम पुनः गणनाओं को ट्रिगर करेगा।

शायद हमारे पास 2 कार्यान्वयन हो सकते हैं और डेटासेट के आयाम के आधार पर स्विच कर सकते हैं। निम्न आयामी वाले के लिए धीमी लेकिन सुरक्षित एक (वैसे भी उस मामले में घबराहट और स्केलेर के बीच बहुत अंतर नहीं है) और उच्च आयामी वाले के लिए तेज + दहलीज।

स्विच करने के लिए और थ्रेसहोल्ड सेट करने के लिए यह खोजने के लिए कुछ बेंचमार्क की आवश्यकता होगी, लेकिन यह आशा की एक झलक हो सकती है :)

यहां स्कैपी और स्केलेर के बीच गति की तुलना के लिए कुछ बेंचमार्क हैं। बेंचमार्क सभी आकारों के Xs के लिए sklearn.metrics.pairwise.euclidean_distances(X,X) scipy.spatial.distance.cdist(X,X) करते हैं। नमूनों की संख्या 2⁴ (16) से 2 8 (8192) तक जाती है, और सुविधाओं की संख्या 2⁰ (1) से 2 1 (8192) हो जाती है।

प्रत्येक सेल में मान स्केलेर बनाम स्कैपी का स्पीडअप होता है, अर्थात 1 स्केलेर से नीचे धीमा होता है और 1 स्केलेर से ऊपर तेज होता है।

पहला बेंचमार्क BLAS के MKL कार्यान्वयन और एक कोर का उपयोग कर रहा है।

दूसरा व्यक्ति BLAS के OpenBLAS कार्यान्वयन और एक कोर का उपयोग कर रहा है। यह जांचना है कि MKL और OpenBLAS दोनों का व्यवहार समान है।

तीसरा एमएलएल बीएलएएस और 4 कोर के एमकेएल कार्यान्वयन का उपयोग कर रहा है। बात यह है कि euclidean_distances को BLAS LEVEL 3 फ़ंक्शन के माध्यम से समानांतर किया जाता है, लेकिन cdist केवल BLAS LEVEL 1 फ़ंक्शन का उपयोग करता है। दिलचस्प बात यह है कि यह लगभग सीमा को नहीं बदलता है।

जब n_samples बहुत कम (> 100) नहीं है, तो ऐसा लगता है कि सीमा 32 के आसपास है। हम n_features <32 और euclidean_distances n_features> 32 के दौरान cdist का उपयोग करने का निर्णय ले सकते हैं। यह तेज है और कोई सटीक मुद्दा नहीं है। इससे यह भी फायदा होता है कि जब n_features छोटा होता है, तो जूलिया थ्रेशहोल्ड बहुत सारे पुन: संगणना करता है। सीडीस्ट का उपयोग करने से बचा जाता है।

जब n_features> 32, हम euclidean_distances कार्यान्वयन रख सकते हैं, जूलिया दहलीज के साथ अद्यतन किया गया। दहलीज को जोड़ने से euclidean_distances बहुत धीमा नहीं होना चाहिए क्योंकि सुविधाओं की संख्या इतनी अधिक है कि केवल कुछ पुन: संगणना आवश्यक हैं।

@jeremiedbb महान, विश्लेषण के लिए धन्यवाद। निष्कर्ष मेरे लिए एक शानदार तरीका है।

ओह, मुझे लगता है कि यह सब फ्लोट64 के लिए था, है ना? हम फ्लोट 32 के साथ क्या करते हैं? हमेशा बना रहा? अपस्ट्रीम> 32 सुविधाओं के लिए?

मैंने टिप्पणियों के माध्यम से ध्यान से नहीं पढ़ा है (जल्द ही होगा), बस FYI कि फ्लोट64 में इसकी सीमाएं हैं, # 12128 देखें

@ qinhanmin2014 हां, फ्लोट64 सटीक की सीमाएं हैं, लेकिन यह सटीक है कि मैं सभी के लिए विश्वसनीय fp32 परिणाम तैयार कर सकता हूं। सवाल यह है कि fp64 के लिए एक अपस्टेक पैरामीटर वास्तव में scipy से cdist का उपयोग करने की तुलना में सस्ता है।
जैसा कि ऊपर के बेंचमार्क में देखा गया है, यहां तक ​​कि मल्टी-कोर बीएलएएस भी आम तौर पर तेज नहीं है । ऐसा लगता है कि ज्यादातर उच्च आयामी डेटा (64 आयामों से अधिक) के लिए पकड़ है, इससे पहले कि लाभ आम तौर पर प्रयास IMHO के लायक नहीं है) - और चूंकि यूक्लिडियन दूरियां घने उच्च आयामी डेटा में विश्वसनीय नहीं हैं, इसलिए उपयोग के मामले में IMHO का महत्व नहीं है। । कई उपयोगकर्ताओं के पास 10 से कम आयाम होंगे। इन मामलों में, सीडीस्ट आमतौर पर तेज हो गया है?

ओह, मुझे लगता है कि यह सब फ्लोट64 के लिए था, है ना?

वास्तव में यह फ्लोट 32 और फ्लोट64 दोनों के लिए है (मेरा मतलब बहुत समान है)। मैं हमेशा c_ist का उपयोग करने का सुझाव देता हूं जब n_features <32।

सवाल यह है कि fp64 के लिए एक अपस्टेक पैरामीटर वास्तव में scipy से cdist का उपयोग करने की तुलना में सस्ता है।

Upcasting ~ 2 के एक कारक से मंदी होगी इसलिए मुझे n_features = 64 के आसपास लगता है।

कई उपयोगकर्ताओं के पास 10 से कम आयाम होंगे।

लेकिन हर कोई नहीं, इसलिए हमें अभी भी उच्च आयामी डेटा के लिए एक समाधान खोजने की आवश्यकता है।

बहुत अच्छा विश्लेषण @jeremiedbb !

कम आयामी डेटा के लिए यह निश्चित रूप से तब cdist का उपयोग करने के लिए समझ में आएगा।

इसके अलावा, FYI scipy की सीडीस्ट अपस्टॉक्स फ्लोट 32 से फ्लोट64 https://github.com/scipy/scipy/issues/8771#issuecomment -384015674, मुझे यकीन नहीं है कि यह सटीकता के मुद्दों या कुछ और के कारण है।

कुल मिलाकर, मुझे लगता है कि https://github.com/scikit-learn/scikit-learn/pull/12601#pullrequestestview -176076355, संभवतः में सुझाए गए "एल्गोरिथ्म" पैरामीटर को euclidean_distance में जोड़ने का अर्थ हो सकता है। "कोई नहीं" के लिए एक डिफ़ॉल्ट के साथ ताकि यह भी एक वैश्विक विकल्प के माध्यम से सेट किया जा सके जैसे कि https://github.com/scikit-learn/scikit-learn/pull/12136।

स्थिर मानदंडों की गणना करने के लिए Eigen3 में एक दिलचस्प दृष्टिकोण भी है: https://eigen.tuxfamily.org/dox/StableNorm_8h_source.html (जो मैंने अभी तक नहीं देखा है)

अच्छी व्याख्या, मेरी समझ में सुधार

हमने स्प्रिंट पर इस पर कोई प्रगति नहीं की है और हमें शायद ... और @ आज के आसपास नहीं है।

यदि आप समय निर्धारित करते हैं तो मैं दूरस्थ रूप से शामिल हो सकता हूं। शायद दोपहर की शुरुआत में?

स्थिति को संक्षेप में बताने के लिए,

यूक्लिडियन दूरी की गणना में सटीक मुद्दों के लिए,

• निम्न आयामी मामले में, जैसा कि @jeremiedbb ने ऊपर दिखाया, हमें शायद cdist का उपयोग करना चाहिए
• उच्च आयामी मामले और फ्लोट 32 में, हम चुन सकते हैं,
  
  
  
  • चूनिंग, 64 बिट में दूरी की गणना और समवर्ती
  
  
  • मामलों में cdist का गिरना जब परिशुद्धता एक मुद्दा है (कैसे एक खुला सवाल है - उदाहरण के लिए scipy तक पहुंच उपयोगी हो सकता है https://github.com/scikit-learn/scikit-learn/issues/9354#uuecomment-438522881 )
  
  

फिर यूक्लिडियन, स्क्वेयुक्लिडियन, मिंकोवस्की, आदि के बीच विसंगतियों के सभी मुद्दे हैं।

पूर्वाधारों के संदर्भ में, @amueller और मेरे पास एक त्वरित चैट थी, जो ज्यादातर अपनी विशेषज्ञता के लिए जेरेमी को दूध पिलाती थी। उनका विचार है कि फ्लोट64 में उच्च आयामों में एमएल संदर्भ में अस्थिरता के मुद्दों के बारे में हमें इतना चिंता करने की आवश्यकता नहीं है। जेरेमी ने यह भी आरोप लगाया कि अच्छे परिणाम लौटाए जाने के लिए एक कुशल परीक्षा प्राप्त करना कठिन है (cf. # 12142)

इसलिए मुझे लगता है कि हम फ्लोट 32 के लिए upcasting के साथ पूर्ववर्ती टिप्पणी से खुश हैं। चूँकि cdist भी float64 के लिए upcasts है, इसलिए हम cdist को float32 (लेकिन float64 संचायक के साथ) लेने के लिए पुन: लागू कर सकते हैं, या यदि हम कम-मंद फ्लोट 32 में कम कॉपी करना चाहते हैं, तो chunking का उपयोग कर सकते हैं।

क्या @Celelibi # 11271 में PR को बदलना चाहता है, या किसी और को (हम में से?) को पूर्ण पुल अनुरोध करना चाहिए?

और एक बार यह तय हो जाने के बाद, मुझे लगता है कि हमें sqeuclidean और minkowski बनाना चाहिए (p in {0,1}) हमारे कार्यान्वयन का उपयोग करें। हमने नियरेस्टेनेबर्स के साथ विसंगति पर चर्चा नहीं की है। एक और स्प्रिंट :)

स्प्रिंट पर एक त्वरित चर्चा के बाद हम निम्नलिखित तरीके से समाप्त हुए:

• उच्च आयामी मामले में (> 32 या> 64 सबसे अच्छा चुनते हैं): विखंडू द्वारा फ्लोट64 तक बढ़ाएं जब यह फ्लोट 32 है और 'तेज़' विधि रखें। इस तरह के डेटा के लिए, सांख्यिक मुद्दे, फ्लोट64 पर, लगभग नगण्य हैं (मैं उस के लिए मानदंड प्रदान करूंगा)

• निम्न आयामी मामले में: स्केलेर में सुरक्षित संगणना (उपहास के कारण खुरचनी का उपयोग करने के बजाय) लागू करें।

(यह फ्लोट 32 में भी फ्लोटिंग को फेंकने का प्रलोभन दे रहा है)

यहां स्कैपी और स्केलेर के बीच गति की तुलना के लिए कुछ बेंचमार्क हैं।
[... स्निप ...]

यह बहुत दिलचस्प है। मैं वास्तव में इस परिणाम की उम्मीद नहीं कर रहा था। मैंने आपके बेंचमार्क पर फिर से काम किया और एक समान परिणाम पाया। सिवाय मैं एक निचली निर्णय सीमा की वकालत करूंगा। मेरा बेंचमार्क 8 सुविधाओं का सुझाव देगा।

गलत होने की लागत सममित नहीं है। cdist केवल कुछ सेकंड से कम समय तक चलने वाली संगणना के लिए बेहतर है और फीचर की संख्या बढ़ने पर यह वास्तव में धीमी गति से बढ़ता है। इसलिए, संदेह होने पर बीएलएएस कार्यान्वयन का बेहतर उपयोग करें।

संपादित करें: यह बेंचमार्क Float64 के लिए था, लेकिन मुझे यह भी पता चलता है कि फ्लोट64 तक के फ्लोट 32 मैट्रिसेस को केवल मुश्किल से कुल समय में कुछ प्रतिशत जोड़ते हैं और निष्कर्ष को नहीं बदलते हैं।

मैंने देखा कि जिस मशीन पर आप बेंचमार्क चला रहे हैं, उस सीमा पर निर्भर करता है। मुझे संदेह है कि इसे AVX निर्देशों के साथ करना पड़ सकता है। मुझे एहसास हुआ कि मेरे द्वारा प्रकाशित बेंचमार्क एक मशीन पर चलाए गए थे जिसमें एवीएक्स 2 निर्देश नहीं थे, केवल एवीएक्स। और एक मशीन पर जो AVX2 है, मुझे आपके समान परिणाम मिले।

लेकिन सवाल केवल प्रदर्शन के बारे में नहीं है, बल्कि सटीकता के बारे में भी है और जब आयाम छोटा होता है, तो इसमें सटीक मुद्दे होने की संभावना अधिक होती है। शायद 16 एक अच्छा समझौता है। तुम क्या सोचते हो ?

इस चर्चा के संबंध में, मैं कहूंगा कि हमें सूचित निर्णय लेने के लिए सटीकता की आवश्यकता होगी।

हालाँकि, आपके पीआर के संबंध में, सटीकता अब कोई मुद्दा नहीं होना चाहिए। लेकिन थोड़ी अधिक महंगी गणना की कीमत पर। इसलिए संभवतया आपके पीआर को बेंचमार्क करके तय किया जाना चाहिए।

बेंचमार्किंग सटीकता इतनी आसान नहीं है। क्योंकि कठिन मामलों को समान रूप से वितरित नहीं किया जाएगा।
और यह समस्याग्रस्त हो सकता है अगर यह एक कोने के मामले में अनिर्धारित होता है। आमतौर पर, आप सस्ती सीपीयू सीमा के भीतर संख्यात्मक सटीकता की गारंटी चाहते हैं।
लेकिन जैसा कि कहीं और उल्लेख किया गया है कि 10000000.01 और 10000000.00 के साथ एक एकल सुविधा को fp64 के साथ संख्यात्मक अस्थिरता को ट्रिगर करने के लिए पर्याप्त होना चाहिए जब ज्ञात-समस्याग्रस्त समीकरण, fp32 के साथ 10000 और 10001 का उपयोग किया जाए। 1024 सुविधाओं के साथ, प्रयास करें

>>> import sklearn.metrics.pairwise as sk, scipy.spatial.distance as sp
>>> X = [[10000.01] * 1024, [10000.00] * 1024]
>>> print(sk.euclidean_distances(X,X), "\n", sp.cdist(X,X))
[[ 0.          0.31895195]
 [ 0.31895195  0.        ]] 
 [[ 0.    0.32]
 [ 0.32  0.  ]]

(यह 0.19.1 का उपयोग कर रहा था) सही दूरी 0.32 है।

जैसा कि आप देख सकते हैं, संख्यात्मक अस्थिरता कई विशेषताओं के साथ खराब हो जाती है (जब तक कि आपका डेटा विरल नहीं है)। यहां, परिणाम में FP64 के साथ परिशुद्धता के दो अंक कम हैं।

13410 इस विशिष्ट मामले को ठीक नहीं करता है। अर्थात फ्लोट64 + उच्च आयाम।

हालाँकि यह फ़्लोट 32 के लिए इसे ठीक करता है।

लेकिन हमने तय किया कि फ्लोट64 + उच्च मंद के लिए, हम इसे वैसे ही रखते हैं, क्योंकि सटीकता के मुद्दे बहुत कम होने की संभावना है और मशीन लर्निंग उपयोग के मामलों पर वास्तव में लागू नहीं होते हैं।

आपके उदाहरण में, X [0] और X [1] के पास 320000.32 और 320000 के बराबर मानदंड हैं और उनकी दूरी 0.32 है, अर्थात 1e-6 उनके मानक से। मशीन लर्निंग में, 16 महत्वपूर्ण अंक (फ्लोट64 में) सभी प्रासंगिक नहीं हैं।

लेकिन हमने तय किया कि फ्लोट64 + उच्च मंद के लिए, हम इसे वैसे ही रखते हैं, क्योंकि सटीकता के मुद्दे बहुत कम होने की संभावना है और मशीन लर्निंग उपयोग के मामलों पर वास्तव में लागू नहीं होते हैं।

मैं इस पर अधिक संयत रहूंगा। आयामी को कम करना एमएल में पहला सामान्य कदम है। एमडीएस का उपयोग उसके लिए किया जा सकता है, और यह यूक्लिडियन दूरी मैट्रिक्स का भारी उपयोग करता है।

यदि कोई फ़्लोट64 मामले की सटीकता में सुधार करना चाहता है, तो मध्यवर्ती परिणामों का प्रतिनिधित्व करने के लिए दो फ़्लोट्स का उपयोग करने का एक तरीका है। हालाँकि मुझे लगता है कि यह शिक्षा के दायरे से परे है।
ftp://ftp.math.ethz.ch/users/wpp/CELL/qd.pdf

मैं स्पष्ट नहीं था। मैं यह नहीं कह रहा हूं कि उच्च आयामी डेटा मशीन सीखने पर लागू नहीं होता है। मैं कह रहा हूं कि फ्लोट64 में होने वाले सटीक प्रकार के मुद्दों में ऐसे बिंदु शामिल हैं जो दूरी उनके मानदंडों से छोटे परिमाण के 6 आदेश हैं। इस तरह की सटीक होने का यथार्थवादी मशीन लर्निंग मॉडल में कोई मतलब नहीं है

मशीन लर्निंग में, 16 महत्वपूर्ण अंक (फ्लोट64 में) सभी प्रासंगिक नहीं हैं।

मैं बिल्कुल भी आश्वस्त नहीं हूं कि यह आम तौर पर सच है।

इस उदाहरण में, हमने परिशुद्धता में 16 में से 15 अंक खो दिए हैं। मैं सहमत हूँ अगर हम सटीक का आधा उपयोग करेंगे, लेकिन हमारे पास ऐसा कोई संबंध नहीं है। माप परिशुद्धता के कारण अक्सर FP64 से FP32 तक का नुकसान सहनीय हो सकता है। और एफपी 64 के साथ उपभोक्ता-ग्रेड जीपीयू एफपी 32 के साथ बहुत तेज हैं, उदाहरण के लिए (कुछ मामलों में, वे एफपी 32 डेटा और एफपी 64 संचयकों को अब अनुमति देते हैं, हालांकि), और तंत्रिका नेटवर्क इंट्रेंस के लिए, आप यहां तक ​​कि अब int8 भी देख सकते हैं। लेकिन वह हर जगह पकड़ नहीं है।

K-साधन क्लस्टरिंग में उदाहरण के लिए, इस धारणा है कि समूहों उनके साधन में काफी अलग है (और है कि हम का मतलब है पहले से पता नहीं है), और इसलिए हम परिशुद्धता में एक नुकसान यहाँ है। यदि आपके पास कई क्लस्टर हैं, तो उनके अलगाव के मुकाबले उनके कुछ मानदंड बड़े हो सकते हैं।
इसके अलावा, पहले शुरुआती पुनरावृत्तियों के बाद, इसकी दूरी में अक्सर छोटे अंतर होते हैं जो एक बिंदु को दूसरे क्लस्टर में बदल देते हैं। यहां परिशुद्धता का नुकसान परिणामों को प्रभावित कर सकता है, और अस्थिरता पैदा कर सकता है।
अब कई चर के साथ समय श्रृंखला टुकड़े पर k- साधन पर विचार करें।

बढ़ते हुए डेटा साइज़ के साथ, हमें यह मान लेना चाहिए कि निकटतम पड़ोसी से दूरी छोटी हो जाती है, और जब तक आपके मानदंड 0 नहीं होते, वे अंततः वेक्टर मानदंडों से छोटे होंगे और समस्याएँ पैदा करेंगे। तो यह संभवतः डेटा सेट आकार बढ़ाने के साथ और अधिक गंभीर हो जाएगा। आयामीता का अभिशाप कहता है कि सबसे बड़ी और सबसे छोटी दूरी अधिक से अधिक समान होती है; इसलिए सही निकटतम पड़ोसी रैंकिंग की गणना करने के लिए, हमें उच्च-आयामी डेटा में अच्छी परिशुद्धता की आवश्यकता हो सकती है। 20news डेटा सेट पर, सबसे छोटी गैर-शून्य दूरी लगभग 0.02 (मानदंड सभी 1 हैं)। लेकिन यह सिर्फ 10k उदाहरण है, और काफी विविध सामग्री है। अब मान लीजिए कि डेटा सेट लगभग डुप्लिकेट डिटेक्शन के बजाय था ...

मुझे यकीन नहीं होगा कि यह "असंभावित" एमएल में होता है ... बेशक यह सभी को प्रभावित नहीं करेगा।

जब मैं कहता हूं "मशीन लर्निंग में, 16 महत्वपूर्ण अंक (फ्लोट64 में) सभी प्रासंगिक नहीं हैं।", मैं गणना की गई दूरी की बात नहीं कर रहा हूं, मैं डेटा एक्स की बात कर रहा हूं।
मशीन लर्निंग में, आपका डेटा एक माप से आता है, और 9 वें अंक के लिए कोई सटीक उपाय नहीं है (कण भौतिकी में बहुत कम लोगों के अलावा)।
तो आपके 10000000.01 और 10000000.00 उदाहरण में, आप 0.01 की दूरी पर कुछ महत्व कैसे देंगे जब एक्स के मूल्यों पर आपकी अनिश्चितता बड़ी हो?

केमियंस के लिए, पहले परिशुद्धता के नुकसान के एक बड़े हिस्से को दूर करने का एक तरीका है। जब आप एक अवलोकन एक्स के निकटतम केंद्र की तलाश कर रहे हैं, तो आपको दूरस्थ गणना में एक्स के आदर्श को जोड़ने की आवश्यकता नहीं है जो ज्यादातर मामलों में विनाशकारी रद्द करने से बचता है।
फिर, यूक्लिडियन दूरी के आधार पर किमी के समूह। लेकिन आपको नहीं पता कि यह सही तरीका है जिससे आपका डेटा इकट्ठा होता है। वास्तव में वहाँ 0 संभावना है कि आपके डेटा को इस तरह से क्लस्टर किया गया है। माइग्रेन एक अनुमान देता है कि आपके डेटा को कैसे क्लस्टर किया जा सकता है और 2 क्लस्टर के मोर्चे पर मौजूद बिंदुओं को निश्चित रूप से एक या दूसरे के साथ निश्चितता से संबंधित नहीं माना जा सकता है। 2 समूहों की समान दूरी पर एक बिंदु की आपकी व्याख्या क्या है? मेरा या तो 2 क्लस्टर है केवल एक क्लस्टर होना चाहिए या केमियां मेरे डेटा को क्लस्टर करने के लिए सबसे अच्छा अहंकार नहीं है (या किमी भी मुझे कुछ हद तक एक अच्छा विचार देता है कि मेरा डेटा कैसे क्लस्टर किया जाता है लेकिन मुझे पता है कि क्लस्टर के सीमांत प्रासंगिक नहीं हैं)।

केवल "| b | ^ 2-2ab" के उपयोग से विनाशकारी निरस्तीकरण नहीं होता है - लेकिन अंतर बनाने वाले अंको में परिशुद्धता में समान नुकसान। परिणाम वही हैं जैसे आपने बाद में प्रत्येक दूरी पर एक का मान जोड़ा; यदि दूरी किसी के मानदंड से बहुत छोटी है, तो आपको सटीक रूप से नुकसान होता है जो कि BLAS हैक के बिना पारंपरिक तरीके से गणना करने से बचा जाता है।
तो आप वास्तव में इस तरह संख्यात्मक समस्या को दूर नहीं कर सकते हैं!

K- साधन एक अनुकूलन समस्या है। तो इस तरह के हैक का मतलब हो सकता है कि स्केलेरोन अन्य उपकरणों की तुलना में केवल बदतर समाधान पाता है। और जैसा कि पहले संकेत दिया गया है, इससे अस्थिरता भी हो सकती है। सबसे खराब स्थिति में, यह स्केलेर किमी को समान राज्यों के माध्यम से max_iter बिना किसी सुधार (मान लें कि यदि आप एक स्थानीय इष्टतम को ढूंढना चाहते हैं) के माध्यम से पुनरावृति का कारण बन सकते हैं, तो यह कहना कि सिद्धांत असंभव है।
जब तक के-साधन अभिसरण नहीं हो जाता, तब तक आप दो समान समूहों के "समान" दूरी वाले बिंदुओं के बारे में बहुत कुछ नहीं कह सकते। अगले पुनरावृत्ति, साधन चले गए हैं और अंतर बहुत बड़ा और मामला बन सकता है!
मैं k- साधनों का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि यह शोर डेटा पर बहुत अच्छी तरह से काम नहीं करता है। लेकिन ऐसी विविधताएं हैं जो ऐसे मामलों को बेहतर तरीके से संभालती हैं। लेकिन फिर भी, यदि आप इसका उपयोग करते हैं, तो आपको संभवतः पूर्ण गुणवत्ता प्राप्त करने का प्रयास करना चाहिए (यही कारण है कि मैं हमेशा tol=0 उपयोग करता हूं) और इसे ज़रूरत से ज़्यादा ख़राब नहीं करना चाहिए। यह उचित गणना करने के लिए पर्याप्त सस्ता है (और, जैसा कि उल्लेख किया गया है, समस्याएं डेटा आकार के साथ खराब हो जाती हैं - इसलिए छोटे डेटा के लिए, धीमे रनटाइम आमतौर पर कोई फर्क नहीं पड़ता है, बड़े डेटा सेट के लिए सटीक अधिक संभावना बन जाता है)।

आवेदन के आधार पर, 10000000.01 और 10000000.00 बीच का अंतर मायने रख सकता है। और जैसा कि मैंने पहले दिखाया, यदि आप कई सुविधाओं का उपयोग करते हैं तो समस्याएं पहले उत्पन्न होती हैं। Fp32 में एक ही फीचर के साथ 10000 और 10001 जितना कम है और 100 के साथ 101 बनाम 100 के साथ मुझे लगता है:

जैसा कि उल्लेख किया गया है, माध्य का एक भौतिक अर्थ हो सकता है जिसे आप खोना नहीं चाहते हैं। यदि आपके पास केल्विन में तापमान के साथ डेटा है, तो आप 0: 1 के पैमाने पर या उन्हें केंद्र नहीं करना चाहते हैं; जो आपके अनुपात के पैमाने को बर्बाद कर देगा। अब यदि आप तुलना करना चाहते हैं, उदाहरण के लिए, कुछ स्टील उत्पाद के तापमान की समय श्रृंखला, क्योंकि यह ठंडा हो जाता है, और यह पता लगाता है कि क्या कूल डाउन प्रक्रिया आपके स्टील उत्पाद की विश्वसनीयता को प्रभावित करती है। यदि आप कोल्डाउन प्रक्रिया का विश्लेषण करना चाहते हैं तो आपके पास 700 K से अधिक का तापमान हो सकता है, और समय श्रृंखला में सैकड़ों डेटा बिंदु हो सकते हैं। यहां तक ​​कि इनपुट सीरीज़ के केवल 5 अंकों (0.01K) के साथ समय श्रृंखला की लंबाई के साथ संख्यात्मक समस्या हो सकती है। आप फिर से परिणाम में केवल 1-2 अंकों के साथ समाप्त हो सकते हैं। मुझे नहीं लगता कि आप एमएल में कभी भी सटीक रूप से बता सकते हैं कि यदि आपके पास इस तरह के विनाशकारी प्रभाव हैं। इसकी एक अलग अगर आप हमेशा प्राप्त करने की गारंटी दे सकते हैं, तो 10 में से 16 अंकों को सटीक कहें। यहां आप ऐसा नहीं कर सकते, आपके पास सबसे खराब स्थिति में 0 अंक सही हो सकते हैं (यही कारण है कि यह भयावह है)।

मशीन लर्निंग में, आपका डेटा एक माप से आता है, और 9 वें अंक के लिए कोई सटीक उपाय नहीं है (कण भौतिकी में बहुत कम लोगों के अलावा)।

वास्तविक दुनिया से कच्चे मूल्यों में शायद ही कभी इस तरह की सटीकता होती है, यह सही है। लेकिन एमएल उस तरह के इनपुट तक सीमित नहीं है। कोई भी व्यक्ति गणितीय समस्याओं के लिए ML को लागू करना चाह सकता है, जैसे कि माणिक की क्यूब जैसी पहेली के ग्राफ पर MDS को लागू करना या पैडमैन खेलने वाले RL एजेंटों के अपने झुंड द्वारा पाई गई सफल रणनीतियों को क्लस्टर करना।
यहां तक ​​कि अगर सूचना का प्रारंभिक स्रोत वास्तविक दुनिया है, तो कुछ मध्य-मार्ग प्रसंस्करण हो सकता है जो क्लस्टर के एल्गोरिदम के लिए अधिकांश अंकों को प्रासंगिक बनाता है। एक समारोह पर एक ढाल वंश के परिणाम की तरह जिसका पैरामीटर वास्तविक दुनिया में सांख्यिकीय रूप से नमूना है।

मैं वास्तव में सोच रहा हूं कि हम अभी भी इस पर चर्चा क्यों कर रहे हैं। मुझे लगता है कि हम सभी सहमत हैं कि स्कोर-लर्न को ट्रेड-ऑफ सटीकता बनाम कम्प्यूटेशन समय में अपना सर्वश्रेष्ठ प्रयास करना चाहिए। और जो कोई भी वर्तमान स्थिति से खुश नहीं है उसे पुल अनुरोध प्रस्तुत करना चाहिए।

केवल "| b | ^ 2-2ab" के उपयोग से विनाशकारी निरस्तीकरण नहीं होता है - लेकिन अंतर बनाने वाले अंको में परिशुद्धता में समान नुकसान। परिणाम वही हैं जैसे आपने बाद में प्रत्येक दूरी पर एक का मान जोड़ा; यदि दूरी किसी के मानदंड से बहुत छोटी है, तो आपको सटीक रूप से नुकसान होता है जो कि BLAS हैक के बिना पारंपरिक तरीके से गणना करने से बचा जाता है।
तो आप वास्तव में इस तरह संख्यात्मक समस्या को दूर नहीं कर सकते हैं!

परिशुद्धता का नुकसान होता है, लेकिन यह एक भयावह रद्द करने का कारण नहीं बन सकता है (कम से कम जब ए और बी करीब हैं), और आप यह दिखा सकते हैं कि दूरी पर सापेक्ष त्रुटि (जो दूरी नहीं है) छोटी रहती है।
KMeans के मामले में जहां आप केवल निकटतम केंद्र खोजने में रुचि रखते हैं, आपके पास ऑर्डर को सही रखने के लिए पर्याप्त सटीकता है। यदि अंत में आप जड़ता चाहते हैं, तो आप सटीक क्लस्टर के साथ इसके क्लस्टर केंद्र के लिए प्रत्येक बिंदु की दूरी की गणना कर सकते हैं।

इसके अलावा, केमन्स एक उत्तल अनुकूलन समस्या नहीं है, इसलिए भले ही आप इसे टोल = 0 के साथ अभिसरण तक चलने दें, आप एक स्थानीय मिनीमा में समाप्त हो जाते हैं जो वैश्विक मिनीमा (किमी के साथ + आरंभीकरण) से भी दूर हो सकता है। इसलिए मैं अलग-अलग init और पुनरावृत्तियों की एक छोटी संख्या के साथ कई बार kmines चलाऊंगा। आपके पास बेहतर स्थानीय मिनीमा में समाप्त होने का बेहतर मौका होगा। फिर आप अभिसरण तक सबसे अच्छे से फिर से दौड़ सकते हैं।

वास्तविक दूरी की तुलना में सापेक्ष त्रुटि बड़ी मनमानी हो सकती है, और इसलिए गलत निकटतम पड़ोसियों का कारण बन सकती है। उदाहरण के लिए tf-idf पर जहाँ मामला है | मान लें कि वैक्टर बहुत करीब हैं। फिर ab भी 1 के करीब है, और इस बिंदु पर आप पहले से ही अपनी सटीकता खो चुके हैं।
जैसा कि मैंने ऊपर लिखा है, त्रुटि है, भले ही आपके पास विपत्तिपूर्ण रद्दीकरण न हो। परिशुद्धता के 8 अंकों पर विचार करें। वास्तविक दूरी 0.000012345678 हो सकती है और FP32 और नियमित यूक्लिडियन दूरी का उपयोग करके आठ अंकों के साथ गणना की जा सकती है। लेकिन इस समीकरण के साथ, आप इसके बजाय ab ab = 0.99998765432 मान की गणना करते हैं, जो FP32 के साथ लगभग 0.99998765 सबसे अच्छे रूप में काट दिया जाएगा, इसलिए आपने इस उदाहरण में परिशुद्धता के तीन अंक अनावश्यक रूप से खो दिए। नुकसान उतना ही बड़ा है, जितना तबाही के मामले में। यदि मानदंड से दूरी बहुत कम है, तो इस दृष्टिकोण के साथ आपकी परिशुद्धता मनमाने ढंग से खराब हो सकती है।

हाँ, kmeans उत्तल नहीं है। लेकिन तब आप कम से कम एक स्थानीय इष्टतम ढूंढना चाहेंगे, और अटक न जाएं (या यहां तक ​​कि दोलन भी करें क्योंकि परिणामी त्रुटियां गलत तरीके से व्यवहार करती हैं) क्योंकि आपकी परिशुद्धता बहुत कम है। तो आपको कम से कम व्यवहार वाले मामलों में और कई प्रयासों के साथ वैश्विक को खोजने का मौका मिलता है।

मैं इस चर्चा की सराहना करता हूं, लेकिन हमें वास्तव में जिस चीज की जरूरत है, वह एक समाधान है जो फ्लोटिंग 64 तक चीजों को रोकने से पहले हम जो कर रहे थे, उससे भी बदतर नहीं है। उस लिहाज से @Celelibi का

भविष्य के संस्करण के बारे में, क्या आप कुशलता से पता लगाने के लिए किसी भी अधिक आत्मविश्वास का अनुभव करते हैं जब हम उच्च आयामों में सटीक गणना पर विचार कर सकते हैं?

मैंने यादृच्छिक संख्या के साथ फ्लोट64 मामले की औसत सटीकता का मूल्यांकन करने के लिए एक बेंचमार्क चलाया है। मैं 3 एल्गोरिदम की तुलना करता हूं: neumaier_sum((x-y)**2) , numpy.sum((x-y)**2) और X2 - 2*X.dot(Y.T) + Y2.T । तुलना करने के लिए सटीक परिणाम 256 बिट्स की परिशुद्धता के साथ mpmath का उपयोग करके प्राप्त किया गया है।
X और Y में 100 नमूने और एक चर संख्या है और -2 और 2 के बीच यादृच्छिक संख्या से भरे हुए हैं।

निम्नलिखित gif पर, प्रति नंबर एक छवि है (1 और 200 के बीच)। प्रत्येक छवि पर, प्रत्येक डॉट X 10000 Y के वैक्टर की एक जोड़ी के बीच वर्गीय यूक्लिडियन दूरी के सापेक्ष त्रुटि का प्रतिनिधित्व करता है। सापेक्षता त्रुटि पठनीयता के लिए 2 ^ 53 से गुणा की जाती है, जो ULP इकाई से लगभग मेल खाती है।
उपरोक्त वक्र अनुमानित वितरण (कर्नेल घनत्व अनुमान का उपयोग करके) हैं।

ध्यान दें कि रेखांकन पठनीयता के लिए 6 ULP पर काटा गया था। यह औसत मामले को दिखाता है, न कि इससे भी बदतर स्थिति को। विस्तारित सूत्र की त्रुटि बहुत बड़ी हो सकती है।

इस परिणाम का मेरा विश्लेषण यह है कि औसतन, विस्तारित सूत्र की सापेक्ष त्रुटि कुछ विशेषताओं के साथ बहुत बड़ी हो सकती है, लेकिन जल्दी से अंतर और संख्यात्मक योग के समान हो जाती है। दहलीज 5 और 10 सुविधाओं के बीच है।

मैं वर्तमान में विस्तारित सूत्र और साथ ही पैथोलॉजिकल उदाहरणों की त्रुटि के लिए एक ऊपरी बाध्य खोजने की कोशिश कर रहा हूं।

मुझे लगता है कि @ kno10 की चिंता यह है कि हम अक्सर ऐसे मामलों में रुचि रखते हैं जहां
अंक बेतरतीब ढंग से वितरित नहीं होते हैं, लेकिन एक दूसरे के पास होते हैं या यूनिट होते हैं
आदर्श।

वास्तव में, लेकिन मुझे यह आश्वस्त करने की आवश्यकता थी कि व्यवहार में, यह पूरी तरह से बीएस नहीं है। ^^

उपरोक्त टिप्पणी को पूरा करने के लिए: सूत्र x²+y²-2ab की सापेक्ष त्रुटि अबाधित प्रतीत होती है। जब तक मेरा विश्लेषण गलत नहीं है, जब x और y एक-दूसरे के करीब होते हैं, तो सापेक्ष त्रुटि 2^(52*2) । कम से कम सैद्धांतिक रूप से। व्यवहार में, मैंने जो सबसे खराब मामला पाया है, वह 2^52+1 की सापेक्ष त्रुटि है।

>>> a, b = (0xfffffec4d6282+1) * 2.0**(511-52), 0xfffffec4d6282 * 2.0**(511-52)
>>> a, b
(6.703903473040778e+153, 6.7039034730407766e+153)
>>> exactdiff = (a-b)**2
>>> exactdiff
2.2158278651204453e+276
>>> computeddiff = a**2 + b**2 - 2*a*b
>>> computeddiff
-9.9792015476736e+291
>>> abs((computeddiff - exactdiff) / exactdiff)
4503599627370497.0
>>> bin(int(abs((computeddiff - exactdiff) / exactdiff)))
'0b10000000000000000000000000000000000000000000000000001'

परिणाम के संकेत को फ़्लिप करना वास्तव में इसे सच्चाई के करीब बना देगा। यह सबसे नाटकीय उदाहरण है जो मुझे मिल सकता है, लेकिन वास्तव में a और b के मूल्यों में प्रतिपादक को बदलना रिश्तेदार त्रुटि को नहीं बदलता है।

>>> a, b = (0xfffffec4d6282+1) * 2.0**(-52), 0xfffffec4d6282 * 2.0**(-52)
>>> a, b
(0.9999999266202912, 0.999999926620291)
>>> exactdiff = (a-b)**2
>>> computeddiff = a**2 + b**2 - 2*a*b
>>> abs((computeddiff - exactdiff) / exactdiff)
4503599627370497.0

मुझे लगता है कि ULPs में एक हिस्टोग्राम प्लॉट उपरोक्त ULP त्रुटि वितरण के साथ एनीमेशन से अधिक समझ में आता है। तो 0 ULP त्रुटि और 1 ULP त्रुटि "जितना अच्छा हो उतना अच्छा है"। 2 वर्गपार्ट की वजह से ULP की संभावना नहीं है। कोई भी बड़ी त्रुटि मैं मानने के लिए जांच के लायक है।

(computed - exact) / exact का उपयोग तब तक उचित है जब तक कि सटीक बड़ा है। लेकिन एक बार जब हमें सटीक मान के लिए संख्यात्मक चुनौतियां मिल रही हैं, तो यह काफी अस्थिर हो जाता है। इस तरह के मामलों में, (computed-exact)/norm बजाय का उपयोग करने के लायक हो सकता है, यानी इनपुट डेटा की तुलना में हमारी दूरी की गणना की सटीकता को देखते हुए, न कि व्युत्पन्न दूरी की तुलना में।
यदि हमारे पास दो एक आयामी मूल्य हैं जो केवल 1 ULP से भिन्न हैं, और 2 ULP की त्रुटि बहुत बड़ी लग सकती है; लेकिन हम पहले से ही इनपुट डेटा रिज़ॉल्यूशन पर हैं, इसलिए परिणाम काफी अस्थिर हैं।
ध्यान दें कि कई आयामों के साथ, हम इनपुट डेटा में एक उच्च रिज़ॉल्यूशन प्राप्त कर सकते हैं।

(1, 1e-16) बनाम (1, 2e-16) इनपुट डेटा पर विचार करें। उदाहरण के लिए, यदि हमारे पास इनपुट डेटा में एक निरंतर विशेषता है, तो कहें, MNIST में एक सफेद पिक्सेल।
अंतर-आधारित समीकरण के साथ यह ठीक होगा, लेकिन डॉट-संस्करण मुश्किल में पड़ जाता है, है ना? इसीलिए इसका अध्ययन करने के लिए एक आयामी प्रयोग पर्याप्त नहीं हो सकता है।

मुझे लगता है कि ULPs में एक हिस्टोग्राम प्लॉट उपरोक्त ULP त्रुटि वितरण के साथ एनीमेशन से अधिक समझ में आता है।

मुझे यकीन नहीं है कि मैं देख सकता हूं कि आपने इसका प्रतिनिधित्व कैसे किया होगा। सुविधा और प्रति एल्गोरिथ्म प्रति संख्या में एक हिस्टोग्राम होगा। वहाँ एक 3 डी साजिश या एक एनीमेशन के बगल में बहुत कुछ नहीं कर सकता हूँ।

(computed - exact) / exact का उपयोग तब तक उचित है जब तक कि सटीक बड़ा है। लेकिन एक बार जब हमें सटीक मान के लिए संख्यात्मक चुनौतियां मिल रही हैं, तो यह काफी अस्थिर हो जाता है।

मुझे यकीन नहीं है कि आप इस संदर्भ में अस्थिर से क्या मतलब है। इसे सटीक बनाने के लिए सटीक मान की गणना की जानी चाहिए।
(जिसके बारे में बोलते हुए, मुझे अपने प्लॉट में भी मनमानी परिशुद्धता के साथ सापेक्ष त्रुटि की गणना करनी चाहिए थी, बिल्कुल गोल परिणाम की तुलना करने के बजाय। मैंने अपने प्लॉट को अपडेट किया, अजीब लहरें गायब हो गईं।)

इस तरह के मामलों में, (computed-exact)/norm बजाय का उपयोग करने के लायक हो सकता है, यानी इनपुट डेटा की तुलना में हमारी दूरी की गणना की सटीकता को देखते हुए, न कि व्युत्पन्न दूरी की तुलना में।

यदि मैं आपके विचार को सही ढंग से समझता हूं, तो आप इनपुट डेटा की परिमाण में पूर्ण त्रुटि की तुलना करेंगे। वेक्टर मानदंड का उपयोग इनपुट के परिमाण के एक संयुक्त माप के रूप में करना। जबकि मानक सापेक्ष त्रुटि इसकी तुलना सटीक परिणाम की भयावहता से करती है।

मुझे लगता है कि इस मीट्रिक के साथ आप कैप्चर करने की कोशिश करते हैं कि एक एल्गोरिथ्म

• यह वास्तव में नहीं कहता है कि परिणाम के कितने अंक अक्षम हैं।
• दरअसल, अधिकांश एल्गोरिदम का स्कोर 1e-15 से कम होगा। यहां तक ​​कि विस्तारित सूत्र (डॉट-आधारित एल्गोरिथ्म) का स्कोर 5 ULP (इनपुट) (किसी न किसी तरह का अनुमान) से घिरा होता है, मैंने पूरा प्रमाण नहीं लिखा था।
• और चूंकि दोनों मैट्रिक्स पूर्ण त्रुटि computed - exact केवल एक उन्नत संस्करण हैं, वे एक ही इनपुट पर मूल्यांकन किए जाने पर एल्गोरिदम को उसी क्रम में रैंक करेंगे।
  तो यह सामान्य सापेक्ष त्रुटि के समान है, बस मूल्य व्याख्या कम उपयोगी (IMO) के साथ।

(1, 1e-16) बनाम (1, 2e-16) इनपुट डेटा पर विचार करें। उदाहरण के लिए, यदि हमारे पास इनपुट डेटा में एक निरंतर विशेषता है, तो कहें, MNIST में एक सफेद पिक्सेल।
अंतर-आधारित समीकरण के साथ यह ठीक होगा, लेकिन डॉट-संस्करण मुश्किल में पड़ जाता है, है ना? इसीलिए इसका अध्ययन करने के लिए एक आयामी प्रयोग पर्याप्त नहीं हो सकता है।

डॉट-आधारित एल्गोरिदम में 1 की सापेक्ष त्रुटि होगी, जिसका अर्थ है कि त्रुटि सटीक परिणाम जितनी बड़ी है, और इस प्रकार, परिणाम का कोई अंक सही नहीं है। और आपके मीट्रिक का मूल्य 1e-16 जिसका अर्थ है कि वेक्टर मानक के पैमाने के सापेक्ष, केवल 16 वां अंक बंद है।
मैं अनिश्चित हूं कि आप इस उदाहरण के साथ क्या दिखाने की कोशिश कर रहे हैं।

अगर हम अभी भी फ्लोट64 के साथ यूक्लिडियन_डिस्टेंस की शुद्धता के बारे में चिंतित हैं, तो शायद इस चर्चा को एक नए मुद्दे में संक्षेप में प्रस्तुत करना बेहतर होगा क्योंकि यहां 100 टिप्पणियां हैं।