파이썬 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는 더 높은 정밀도의 누산기를 사용할 수 있습니다. 네, 이렇게 생겼어요
고칠 가치가 있습니다.

2017 년 7 월 19 일 오전 12:05에 "nvauquie" [email protected]이 작성했습니다.

파이썬 3.5와 동일한 결과 :

Darwin-15.6.0-x86_64-i386-64 비트
Python 3.5.1 (v3.5.1 : 37a07cee5969, 2015 년 12 월 5 일, 21:12:44)
[GCC 4.2.1 (Apple Inc. 빌드 5666) (3 점)]
NumPy 1.11.0
SciPy 0.18.1
Scikit-Learn 0.17.1

유클리드 거리에서만 발생하며 다음을 사용하여 재현 할 수 있습니다.
직접 sklearn.metrics.pairwise.euclidean_distances :

수입 scipy
sklearn.metrics.pairwise 가져 오기

서로 매우 유사한 64 비트 벡터 a와 b 생성

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)

a 및 b의 32 비트 버전 생성

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

64 비트 및 32 비트 모두에 대해 sklearn을 사용하여 a에서 b까지의 거리를 계산합니다.

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)

print (dist_64_sklearn)
print (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에 대한 답은 0이고 np.float 64에 대한 정확한 ans를 얻습니다.

@jnothman 그럼 내가 뭘해야한다고 생각하니? 위의 의견에서 언급했듯이 문제는 아마도 sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y)) 사용하여 유클리드 거리를 계산하는 것입니다.

그래서 당신은 점이 product-then-sum보다 덜 정확한 결과를 반환한다고 말하고 있습니까?

아니요, 제가 말하려는 것은 dot이 product-then-sum보다 더 정확한 결과를 반환한다는 것입니다.
-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]]

첫 번째 방법은 유클리드 거리 함수로 계산하는 방법입니다.
또한 위에서 의미 한 바를 명확히하기 위해 sum-then-product는 numpy 함수를 사용하여도 정밀도가 낮다는 사실입니다.

예, 복제 할 수 있습니다. 처음에는 뺄셈을하는 것이 보입니다.
차이의 정밀도를 유지할 수 있습니다. 점하기
곱한 다음 빼기 (또는 부정하고 더하기)합니다.
최상위 숫자가 다음보다 훨씬 크기 때문에이 정밀도를 잃습니다.
차이점들.

현재 구현은 많은 수의 경우 메모리 효율성이 더 높습니다.
풍모. 하지만 유클리드 거리가 점점 무의미 해 졌다고 생각합니다
따라서 메모리는 출력 수에 의해 지배됩니다.
가치.

그래서 저는 수치 적으로 더 안정적인 구현을 채택하는 것에 투표합니다.
d- 점근 적으로 효율적인 구현입니다. 의견,
@ogrisel? @agramfort?

그리고 이것은 우리가 최근에 float32s를 허용했기 때문에 당연히 더 많은 관심사입니다.
추정자들 사이에서 더 흔하게 사용됩니다.

따라서이 예제의 경우 product-then-sum이 np.float64에 대해 완벽하게 작동하므로 가능한 해결책은 입력을 float64로 변환 한 다음 결과를 계산하고 다시 변환 된 결과를 float32로 반환하는 것입니다. 나는 이것이 더 효율적이라고 생각하지만 이것이 다른 예에서 잘 작동하는지 확실하지 않습니다.

float64로 변환하는 것보다 메모리 사용이 더 효율적이지 않습니다.
빼기.

오, 네, 죄송 합니다만, float64를 사용한 다음 product-then-sum을 수행하는 것이 메모리가 현명하지 않다면 계산적으로 더 효율적일 것이라고 생각합니다.

그리고 product-then-sum을 사용하는 이유는 메모리 효율성이 아니라 계산 효율성이 더 높기 때문입니다.

물론입니다.하지만 사실이라고 생각할 이유가 없다고 생각합니다.
실현할 필요가 없다는 방법을 제외하고는 계산적으로 더 효율적입니다.
중간 배열. 절대 작업 메모리를 제한한다고 가정합니다 (예 :
chunking), 왜 내적을 취하고 규범을 두 배로 빼고
뺄셈과 제곱보다 훨씬 효율적입니까?

벤치 마크를 제공 하시겠습니까?

좋아 그래서 나는 빼기 후 제곱과 float64 로의 변환에 걸린 시간을 비교하기 위해 파이썬 스크립트를 만들었습니다. . 또한 @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

샘플 수뿐만 아니라 샘플 수에 따라 어떻게 확장되는지 테스트 할 가치가 있습니다.
기능의 수 ... 규범을 취하면 일부를 계산하는 이점이있을 수 있습니다.
샘플 쌍당 한 번이 아니라 샘플 당 한 번

2017 년 10 월 20 일 2:39 am, "Osaid Rehman Nasir" [email protected]
썼다 :

좋아 그래서 나는 시간을 비교하기 위해 파이썬 스크립트를 만들었습니다.
뺄셈-제곱 및 float64로 변환 한 다음 곱-다음-합
X와 Y를 매우 큰 벡터로 선택하면 2
결과는 매우 다릅니다. 또한 @jnothman https://github.com/jnothman
당신은 뺄셈이 옳았다-그 다음 제곱이 더 빠릅니다.
제가 작성한 스크립트는 다음과 같습니다. 문제가 있으면 알려주세요.

numpy를 np로 가져 오기
수입 scipy
sklearn.metrics.pairwise import check_pairwise_arrays, row_norms에서
sklearn.utils.extmath에서 가져 오기 safe_sparse_dot
timeit에서 default_timer를 타이머로 가져옵니다.

범위 (9)에있는 i의 경우 :
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, :]

# product-then-sum을 사용하여 계산 된 유클리드 거리
거리 = safe_sparse_dot (X, YT, density_output = True)
거리 * = -2
거리 + = XX
거리 + = YY

ans1 = np.sqrt (거리)

시작 = 타이머 ()
ans2 = np.sqrt (row_norms (XY, squared = True) [:, 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?

그래, 내가 뭘하길 바라 니?

보다 안정적인 구현을 제공하고
현재 구현, 이상적으로는 우리가 잃지 않는다는 것을 보여주는 벤치 마크
합리적인 경우에 많은 변화가 있습니다.

벡터화를 사용하여 각 행 쌍 사이의 거리를 찾을 수 있는지 묻고 싶었습니다. 나는 그것을 벡터화하는 방법에 대해 생각할 수 없습니다.

행 쌍 사이의 차이 (거리가 아님)를 의미합니까? numpy 배열로 작업하는 경우 확실히 할 수 있습니다. 형태가있는 배열 (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 ...

2017 년 11 월 5 일 오전 5:27, "Osaid Rehman Nasir" [email protected]
썼다 :

또한 더 안정적인 구현을 제공하는지 묻고 싶었습니다.
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
.

하지만 PR을 열면 정확하게 논의하는 것이 더 쉬울 것입니다.

좋아,이 기능의 아주 기본적인 구현으로 PR을 열겠습니다.

질문은 0.20 릴리스에 대해 이것에 대해 수행해야 할 작업입니다. 고려할 수있는 단순 / 일시적 개선 (예 : 메모리 사용 비용이 드는 이벤트)이있을 수 있습니까?

# 11271에서 제안한 솔루션과 분석은 확실히 매우 가치가 있지만 이것이 최적의 솔루션인지 확인하려면 더 많은 논의가 필요할 수 있습니다. 특히, CPU 유형 등에 따라 https://github.com/scikit-learn/scikit-learn/issues/11506 에서 최적의 글로벌 작업 메모리에 대한 논의가 보류 중이라는 사실에 대해 우려합니다. 또 다른 수준의 청킹을 추가하고 전체의 복잡성은 약간의 제어 IMO를 얻는 것입니다. 하지만 어쩌면 그것은 나일 뿐이고, 이차 의견을 찾고 있습니다.

@jnothman @amueller @ogrisel 릴리스에서이 문제에 대해 어떻게해야한다고 생각

안정성이 효율성보다 우선합니다. 안정성 문제는 다음과 같은 경우에도 수정되어야합니다.
효율성은 여전히 ​​조정이 필요합니다.

working_memory의 초점은 큰 샘플로 실루엣 같은 것을 만드는 것이 었습니다.
크기가 작동합니다. 또한 효율성이 향상되었지만
선.

나는 우리가 euclidean_distances에 대한 수정을 시도해야한다고 강력히 믿습니다.
float32 in. 우리가 만들 수 있다고 가정하여 0.19에서 깨뜨 렸습니다.
euclidean_distances는 순진한 방식으로 32 비트에서 작동합니다.

수정이 필요하다는 데 동의합니다. 여기서 내 관심사는 효율성이 아니라 코드 기반의 추가 복잡성입니다.

한 발 물러서서 scipy의 유클리드 구현은 10 줄의 C 코드로 보이며 32 비트의 경우 단순히 64 비트로 변환합니다. 나는 그것이 가장 빠르지는 않지만 개념적으로 따르고 이해하기 쉽다는 것을 이해합니다. scikit-learn에서 우리는 트릭을 사용하여 BLAS에서 계산을 더 빠르게 수행 한 다음 https://github.com/scikit-learn/scikit-learn/pull/10212 및 이제 유클리드에 대한 가능한 청크 솔루션으로 인해 가능한 개선이 있습니다. 32 비트의 거리.

이 주제에 대한 일반적인 방향이 무엇인지에 대한 정보를 찾고 있습니다 (예 : 일부를 scipy로 업스트림하려고 시도).

scipy는 데이터 복사에 대해 걱정하지 않는 것 같습니다.

PR 이후 0.21로 이동합니다.

차단기를 제거 하시겠습니까?

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

dot (x, x) 및 dot (y, y)가 catastrophic cancel 이라고 알려진 때문에 dot (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))

sklearn은 여기에서 sqrt (2)가 아닌 0의 거리를 계산합니다.

분산 및 공분산에 대한 수치 적 문제에 대한 논의는 다음과 같이 유클리드 거리를 가속화하는 이러한 접근 방식으로 이어집니다.

Erich Schubert 및 Michael Gertz.
(공) 분산의 수치 적으로 안정적인 병렬 계산.
에서 : 과학 및 통계 데이터베이스 관리 (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 (sum (power ()))로 계산하고 단일 패스이며 합리적인 정밀도를가집니다. 손실은 이미 제곱을 사용하는 것입니다. 즉, dot (x, x) 자체가 이미 정밀도를 잃고 있습니다.

@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.5 배 더 많음) 매트릭스 행렬 곱셈을 위해 잘 최적화 된 BLAS 라이브러리를 사용할 수 있기 때문에 속도가 향상됩니다.

이것은 scikit-learn의 여러 추정자들에게 엄청난 속도 저하가 될 것입니다.

예,하지만 FP32에서는 3 ~ 4 자리 정밀도 , FP64에서는 7 ~ 8 자리 숫자만으로도 상당한 부정확성 이 발생하지 않습니까? 특히 이러한 오류가 증폭되는 경향이 있기 때문에 ...

글쎄요, 지금은 괜찮다는 말이 아닙니다. :)
나는 우리가 그 사이에 해결책을 찾아야한다고 말하는 것입니다.
계산을 수행하기 위해 float64에서 캐스트하도록 제안하는 PR (# 11271)이 있습니다. In은 float64에 대한 문제를 해결하지 않지만 float32에 대해 더 나은 정밀도를 제공합니다.

euclidean_distances를 사용하는 추정기를 사용하여 정밀도 손실로 인해 잘못된 결과를 제공하는 예가 있습니까?

나는 여전히 이것이 큰 문제라고 생각하며 0.21을 차단해야합니다. 0.19에서 32 비트에 대해 도입 된 문제 였고, 떠나기에 좋은 상태가 아닙니다. 0.20에서 더 일찍 해결했으면 좋겠고, 중간에 # 11271이 합쳐지는 것을 봐도 괜찮을 것입니다. 그 PR에서 내가 아는 메모리 효율성의 서라운드 최적화에 대해 아는 유일한 문제는 깊은 토끼 구멍입니다.

우리는이 "빠른"버전을 오랫동안 사용해 왔지만 항상 float64입니다. @ kno10 , 정확성에 문제가 있다는 것을 알고 있습니다. 문제가 될 수있는시기를 해결하고 더 느리지 만 더 확실한 솔루션을 사용할 수있는 빠르고 좋은 휴리스틱이 있습니까?

예,하지만 FP32에서는 3 ~ 4 자리의 정밀도, FP64에서는 7 ~ 8 자리의 정밀도만으로도 상당한 부정확성이 발생합니다.

매우 간단한 예제로이 문제를 설명해 주셔서 감사합니다!

나는이 문제가 당신이 제안한 것처럼 널리 퍼져 있지 않다고 생각합니다. 대부분은 그들의 규범에 비해 상호 거리가 작은 샘플에 영향을줍니다.

아래 그림은 각 1D 샘플이 [-100, 100] 간격에있는 2e6 임의 샘플 쌍에 대해이를 보여줍니다. scikit-learn과 scipy 구현 간의 상대 오차는 L2 표준에 의해 정규화 된 샘플 간의 거리 함수로 표시됩니다.

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

(올바른 매개 변수화인지 확실하지 않지만 데이터 스케일에 다소 불변하는 결과를 얻기 위해),

예를 들어

1. [10000] 및 [10001] 하는 경우 L2 정규화 된 거리는 1e-4이고 거리 계산의 상대 오류는 64 비트에서 1e-8, 32 비트에서> 1 (또는 1e -8 및> 1). 32 비트에서이 경우는 참으로 끔찍합니다.
2. 반면에 [1] 및 [10001] 의 경우 상대 오류는 32 비트에서 ~ 1e-7 또는 가능한 최대 정밀도입니다.

문제는 사례 1이 실제로 ML 애플리케이션에서 발생하는 빈도입니다.

흥미롭게도 다시 균일 한 무작위 분포를 사용하여 2D로 이동하면 매우 가까운 점을 찾기가 어렵습니다.

물론 실제로 우리의 데이터는 균일하게 샘플링되지 않지만 차원의 저주로 인해 어떤 분포에 대해서도 차원이 증가함에 따라 두 점 사이의 거리가 매우 유사한 값 (0과 다름)으로 천천히 수렴됩니다. 일반적인 ML 문제이지만 여기서는 상대적으로 낮은 차원의 경우에도이 정확도 문제를 다소 완화 할 수 있습니다. n_features=5 대한 결과 아래,
.

따라서 중앙 데이터의 경우, 적어도 64 비트에서는 실제로 문제가되지 않을 수 있습니다 (2 개 이상의 기능이 있다고 가정). 50 배의 계산 속도 향상 (위 그림 참조)은 그만한 가치가 있습니다 (64 비트). 물론 [-1, 1]에서 정규화 된 일부 데이터에 항상 1e6을 추가하고 결과가 정확하지 않다고 말할 수 있지만, 여러 수치 알고리즘에도 동일하게 적용되고 6 번째로 표현 된 데이터로 작업한다고 주장합니다. 중요한 숫자는 문제를 찾고 있습니다.

(위 그림의 코드는 여기 에서 찾을 수

dot (x, x) + dot (y, y) -2 dot (x, y) 버전을 사용하는 모든 빠른 접근 방식 나는 당신이 내적의 정밀도를 두 배로 늘려야 약. 의 정밀도 (사용자가 float32 데이터를 제공하면 float32 정밀도를 원하고 float64 정밀도를 원한다고 가정합니다). 몇 가지 트릭 (카한 합산을 생각해보십시오)으로 이것을 할 수 있지만, 처음에 얻은 것보다 훨씬 더 많은 비용이들 것입니다.

이 접근 방식을 사용하기 위해 float32를 float64로 즉시 변환 할 때 얼마나 많은 오버 헤드가 발생하는지 알 수 없습니다. 적어도 float32의 경우 모든 계산을 수행하고 내적을 float64로 저장하는 것이 좋습니다.

IMHO, 성능 향상 (기하 급수적이지 않고 일정한 요소)은 정밀도 손실 (예기치 않게 물릴 수 있음)의 가치가 없으며 적절한 방법은이 문제가있는 트릭을 사용하지 않는 것입니다. 그러나 예를 들어 AVX를 사용하기 위해 "전통적인"계산을 수행하는 코드를 추가로 최적화하는 것이 가능할 수 있습니다. sum ((xy) * 2)은 AVX에서 구현하기가 어렵 기 때문입니다.최소한, 가끔 낮은 정밀도 때문에 메서드 이름을 approximate_euclidean_distances 바꾸는 것이 좋습니다 (두 값이 가까울수록 더 나빠집니다. , 사용자가이 문제를 알 수 있습니다.

@rth 삽화에 감사드립니다. 그러나 최적화를 시도하는 경우, 예를 들어 x를 최적으로 최적화하려고하면 어떨까요? 대부분의 경우 최적 값은 0이 아닐 것이며 (항상 데이터 센터라면 삶은 좋을 것입니다), 결국 그라디언트 등을 위해 계산하는 델타에는 아주 작은 차이가있을 수 있습니다.
마찬가지로 군집에서 군집의 중심이 모두 0에 가까워지는 것은 아니지만 특히 군집이 많은 경우 x ≈ 중심이 몇 자릿수로 가능합니다.

그러나 전반적으로이 문제를 해결해야한다는 데 동의합니다. 어쨌든 우리는 가능한 한 빨리 현재 구현의 정밀도 문제를 문서화해야합니다.

일반적으로 나는이 토론이 scikit-learn에서 일어나야한다고 생각하지 않습니다. 유클리드 거리는 다양한 과학 컴퓨팅 분야에서 사용되며 IMO scipy 메일 링리스트 또는 문제는 토론하기에 더 좋은 장소입니다. 커뮤니티는 이러한 수치 정밀도 문제에 대한 경험이 더 많습니다. 사실 우리가 여기에있는 것은 빠르지 만 다소 근사한 알고리즘입니다. 단기간에 몇 가지 수정 해결 방법을 구현해야 할 수도 있지만 장기적으로는 이것이 기여할 것이라는 것을 아는 것이 좋습니다.

32 비트의 경우 https://github.com/scikit-learn/scikit-learn/pull/11271 이 실제로 해결책이 될 수 있습니다. 코드 복잡성을 증가시키기 때문에 라이브러리 전체에서 여러 수준의 청킹을 좋아하지는 않습니다. , 더 나은 방법이 없는지 확인하고 싶습니다.

@ kno10에 응답 해 주셔서 감사합니다! (위의 의견은 아직 고려하지 않았습니다.) 잠시 후 답변하겠습니다.

예, 원점을 벗어난 지점으로의 수렴이 문제가 될 수 있습니다.

IMHO, 성능 향상 (기하 급수적이지 않고 일정한 요소)은 정밀도 손실 (예기치 않게 물릴 수 있음)의 가치가 없으며 적절한 방법은이 문제가있는 트릭을 사용하지 않는 것입니다.

64 비트에서 계산 속도가 10 배 이상 느리면 사용자에게 매우 실질적인 영향을 미칩니다.

그러나 예를 들어 AVX를 사용하기 위해 "전통적인"계산을 수행하는 코드를 추가로 최적화하는 것이 가능할 수 있습니다. sum ((xy) ** 2)는 AVX에서 구현하기가 어렵 기 때문입니다.

numba (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

지금까지 scipy cdist 와 비슷한 속도를 얻었으며 (하지만 저는 numba 전문가는 아닙니다) fastmath 의 효과에 대해서도 확신하지 못합니다.

dot (x, x) + dot (y, y) -2 * dot (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를 사용합니다. BLAS를 사용하는 것 외에도 실제로 위의 첫 번째 버전과 동일한 수의 수학 연산을 수행하는지 궁금합니다.

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/3 비율이 있습니다.

위의 논의에 따라

• 선택적으로 유클리드 거리를 정확하게 계산할 수 있도록 PR을 만들었습니다. https://github.com/scikit-learn/scikit-learn/pull/12136
• https://github.com/scikit-learn/scikit-learn/pull/12142 에서 문제 지점을 감지하고 완화 할 수 있는지 확인하기위한 일부 WIP

32 비트의 경우 여전히 IMO를 통해 https://github.com/scikit-learn/scikit-learn/pull/11271 을 일부 형태로 병합해야합니다. 위의 PR은 이와 다소 직교합니다.

참고 : OPTICS의 일부 문제를 수정하고 ELKI의 참조 결과를 사용하기 위해 테스트를 새로 고칠 때 metric="euclidean" 에서는 실패하지만 metric="minkowski" 에서는 성공합니다. 수치 차이는 다른 처리 순서를 유발할만큼 충분히 큽니다 (임계 값을 줄이는 것만으로는 충분하지 않음).

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

나는 이것에 정말로 익숙하지 않지만 기존 솔루션이 없다는 것에 놀랐습니다. 이것은 매우 일반적인 계산으로 보이며 우리가 바퀴를 재발 명하는 것처럼 보입니다. 더 넓은 과학 컴퓨팅 커뮤니티에 접근 해 본 사람이 있습니까?

아직은 아니지만 그래야한다는 데 동의합니다. scipy에서 이것에 대해 찾은 유일한 것은 https://github.com/scipy/scipy/pull/2815 및 연결된 문제였습니다.

@jeremiedbb 가 아이디어를 가질 수 있다고 생각합니까?

불행히도 아직 만족스럽지 않습니다 :(

OpenBLAS 또는 MKL과 같은 BLAS 라이브러리를 사용하는 선형 대수에 대해 수행하는 것처럼 이러한 종류의 계산을 위해 고도로 최적화 된 라이브러리에 의존하고 싶습니다. 그러나 유클리드 거리는 그것의 일부가 아닙니다. 도트 트릭은 BLAS 레벨 3 행렬-행렬 곱셈 서브 루틴에 의존하는 시도입니다. 그러나 이것은 정확하지 않으며 동일한 방법을 사용하여 더 정확하게 만들 수있는 방법이 없습니다. 속도 나 정확성 측면에서 기대치를 낮춰야합니다.

어떤 상황에서는 완전한 정밀도가 필수가 아니며 빠른 방법을 유지하는 것이 좋습니다. 거리가 "가장 가까운 찾기"작업에 사용되는 경우입니다. fast 방법의 정밀도 문제는 포인트 간의 거리가 표준에 비해 작을 때 나타납니다 (float 32의 경우 ~ <1e-4, float64의 경우 ~ <1e-8 비율). 먼저 이러한 상황이 발생하려면 데이터 세트가 매우 조밀해야합니다. 그런 다음 순서 오류가 발생하려면 거의 동일한 거리 내에 가장 가까운 두 점이 있어야합니다. 더욱이이 경우 ML 관점에서 둘 다 거의 똑같이 잘 맞을 것입니다.

위의 상황에서 이러한 잘못된 순서의 빈도를 낮추기 위해 할 수있는 작업이 있습니다 (0?). 쌍 단위 거리 argmin 상황에서. 가장 가까운 지점이 아닌 지점으로 오 순서를 옮길 수 있습니다. 본질적으로 표준 중 하나가 argmin을 찾는 데 필요하지 않다는 사실을 사용하여 comment를 참조하십시오. 두 가지 장점이 있습니다. 더 강력하고 (지금까지 잘못된 순서를 찾지 못했습니다) 일부 계산을 피할 수 있기 때문에 더 빠릅니다.

한 가지 단점은 여전히 ​​동일한 상황에서 가장 가까운 지점까지의 실제 거리를 원하면 위의 방법으로 계산 된 거리를 사용할 수 없다는 것입니다. 부분적으로 만 계산되며 어쨌든 정확하지 않습니다. 각 지점에서 가장 가까운 지점까지의 거리를 다시 계산해야합니다. 그러나 이것은 각 포인트에 대해 계산할 거리가 하나뿐이기 때문에 빠릅니다.

위에서 설명한 내용이 sklearn에서 euclidean_distances의 모든 사용 사례를 다루는 지 궁금합니다. 그러나 나는 그것이 적용될 수있는 곳이면 어디에서나 그렇게 할 것을 제안합니다. 이를 위해 euclidean_distances에 새 매개 변수를 추가하여 argmin과 연결하기 위해 필요한 부분 만 계산할 수 있습니다. 그런 다음 pairwise_distances_argmin 및 pairwise_distances_argmin_min에서 사용합니다 (후자의 끝에서 실제 최소 거리 계산).

그렇게 할 수 없으면 느리지 만 정확한 것으로 돌아가거나 # 12136과 같은 스위치를 추가합니다.
성능 저하를 줄이기 위해 약간의 최적화를 시도 할 수 있습니다. 이것이 최적으로 보이지 않는다는 데 동의합니다. 그것에 대한 몇 가지 아이디어가 있습니다.

BLAS를 계속 사용할 수있는 또 다른 가능성은 axpy 와 nrm2 것이지만 이는 최적이 아닙니다. 둘 다 BLAS 레벨 1 기능이며 사본이 포함됩니다. 이것은 차원> 100에서만 더 빠를 것입니다.
이상적으로는 유클리드 거리가 BLAS에 포함되기를 원합니다.

마지막으로 업 캐스팅으로 구성된 또 다른 솔루션이 있습니다. 이것은 float32의 경우 # 11271에서 수행됩니다. 장점은 속도가 현재 속도의 절반에 불과하고 정밀도가 유지된다는 것입니다. 그러나 float64의 문제는 해결되지 않습니다. 아마도 우리는 float64에 대해 cython에서 비슷한 일을하는 방법을 찾을 수있을 것입니다. 정확히 어떻게하는지 모르겠지만 float128을 시뮬레이션하기 위해 2 개의 float64 숫자를 사용합니다. 나는 그것이 어느 정도 가능한지보기 위해 그것을 시도 할 수있다.

이상적으로는 유클리드 거리가 BLAS에 포함되기를 원합니다.

그것이 도서관이 고려할 것입니까? OpenBLAS가 그렇게한다면 우리는 이미 꽤 좋은 상황에있을 것입니다 ...

또한 우리가하는 것과 BLAS가하는 것의 정확한 차이점은 무엇입니까? CPU 기능을 감지하고 어떤 구현을 사용할지 결정합니까? 아니면 단지 더 다양한 아키텍처를 위해 컴파일 된 버전을 가지고 있습니까?
아니면 효율적인 구현을 작성하는 데 더 많은 시간 / 에너지를 소비합니까?

이것은 흥미 롭습니다. 빠르고 불안정한 방법의 대체 구현이지만 sklearn보다 훨씬 빠르다고 주장합니다.
https://github.com/droyed/eucl_dist
(이 문제를 전혀 해결하지 못합니다.)

이 토론은 https://github.com/scipy/scipy/issues/5657 과 관련된 것으로 보입니다.

Julia가하는 일은 다음과 같습니다 : https://github.com/JuliaStats/Distances.jl/blob/master/README.md#precision -for-euclidean-and-sqeuclidean
재 계산을 강제하기 위해 정밀도 임계 값을 설정할 수 있습니다.

내 질문에 답하기 : OpenBLAS에는 각 프로세서 (아키텍처가 아님)에 대해 손으로 작성한 어셈블리처럼 보이는 것과 다양한 문제 크기에 맞는 커널을 선택하는 휴티 스틱이 있습니다. 그래서 모든 커널을 작성 / 최적화 할 사람을 찾는 것만 큼 openblas에 들어가는 문제라고 생각하지 않습니다.

추가 의견에 감사드립니다!

부분 응답에서

OpenBLAS 또는 MKL과 같은 BLAS 라이브러리를 사용하는 선형 대수에 대해 수행하는 것처럼 이러한 종류의 계산을 위해 고도로 최적화 된 라이브러리에 의존하고 싶습니다.

네, BLAS에서 더 많은 일을 할 수 있기를 바랐습니다. 지난번에 표준 BLAS API에서 아무것도 보지 못했지만 충분히 가깝게 보였습니다 (하지만 나는 전문가가 아닙니다). BLIS 는 더 많은 유연성을 제공 할 수 있지만 기본적으로 사용하지 않기 때문에 다소 제한적으로 사용됩니다 (numpy는 언젠가 https://github.com/numpy/numpy/issues/7372)

Julia가 수행하는 작업은 다음과 같습니다. 정밀 임계 값을 설정하여 강제로 재 계산할 수 있습니다.

알아두면 좋습니다!

위에 링크 된 더 빠른 근사 계산을 위해 별도의 문제를 열어야합니까? 흥미 롭다

x2-x4의 CPU 속도 향상은 https://github.com/scikit-learn/scikit-learn/pull/10212 때문일 수

나는 유클리드 거리가 ML 외부의 많은 사람들이 관심을 가져야 할 정도로 충분히 기본적인 것이라고 생각하기 때문에 합리적인 해결책을 찾을 수있을만큼 충분히이 질문을 연구 한 후에 scipy에 대한 문제를 열고 싶습니다. (그리고 동시에 사람들의 의견을 갖는 것은 정확성 문제에 대한 것입니다.)

최대 60 배죠?

이것은 흥미 롭습니다. 빠르고 불안정한 방법의 대체 구현이지만 sklearn보다 훨씬 빠르다고 주장합니다.

그것에 대해 잘 모르겠습니다. 그들은 scipy의 것을 사용하는 %timeit pairwise_distances(a,b, 'sqeuclidean') 벤치마킹하고 있습니다. 그들은 %timeit pairwise_distances(a,b, 'euclidean', metric_params={'squared': True}) 을해야하고 속도 향상은 좋지 않을 것입니다. :)
논의의 앞부분에서 볼 수 있듯이 sklearn은 scipy보다 35 배 빠를 수 있습니다.

예, 벤치 마크는 metric="euclidean" ( squeclidean 대신)에서 30 % 만 더 우수합니다.

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가 그렇게한다면 우리는 이미 꽤 좋은 상황에있을 것입니다 ...

간단하게 들리지 않습니다. BLAS는 선형 대수 루틴에 대한 일련의 사양이며 여러 가지 구현이 있습니다. 원래 사양에없는 새로운 기능을 추가하는 데 얼마나 개방적인지 모르겠습니다. 이를 위해 blis가 더 열려있을 수 있지만 이전에 말했듯이 지금은 기본값이 아닙니다.

sqeuclidean 대 euclidean 처리에서 pairwise_distances 에서 https://github.com/scikit-learn/scikit-learn/issues/12600 을 열었습니다.

나는 우리가 이것을 위해 원하는 것에 대해 약간의 명확성이 필요합니다. pairwise_distances 가 '유클리드'와 'sqeuclidean'모두에 대해 all_close 의 의미에서 가깝기를 원합니까?

약간 까다 롭습니다. x가 y에 가깝다고해서 x²가 y²에 가깝다는 의미는 아닙니다. 제곱하는 동안 정밀도가 손실됩니다.

위에 링크 된 줄리아 해결 방법은 매우 흥미롭고 구현하기 쉽습니다. 그러나 'sqeuclidean'에 대해 예상대로 작동하지 않는 것 같습니다. 원하는 정밀도를 얻으려면 아래 임계 값을 설정해야한다고 생각합니다.

매우 낮은 임계 값을 설정하는 문제는 많은 재계 산과 성능 저하를 유발한다는 것입니다. 그러나 이것은 데이터 세트의 차원에 의해 완화됩니다. 동일한 임계 값은 높은 차원에서 더 적은 재 계산을 트리거합니다 (거리가 더 큼).

아마도 우리는 두 가지 구현을 가질 수 있고 데이터 세트의 차원에 따라 전환 할 수 있습니다. 낮은 차원의 경우 느리지 만 안전한 것 (어쨌든 scipy와 sklearn 사이에는 큰 차이가 없음)과 높은 차원의 경우 빠른 + 임계 값입니다.

전환시기를 찾고 임계 값을 설정하려면 몇 가지 벤치 마크가 필요하지만 희망이 희미해질 수 있습니다. :)

다음은 scipy와 sklearn의 속도 비교를위한 몇 가지 벤치 마크입니다. 벤치 마크는 모든 크기의 X에 대해 sklearn.metrics.pairwise.euclidean_distances(X,X) 와 scipy.spatial.distance.cdist(X,X) 를 비교합니다. 샘플 수는 2⁴ (16)에서 2¹³ (8192)로, 기능 수는 2⁰ (1)에서 2¹³ (8192)로 이동합니다.

각 셀의 값은 sklearn 대 scipy의 속도 향상입니다. 즉, 1 미만의 sklearn은 느리고 1 이상의 sklearn은 더 빠릅니다.

첫 번째 벤치 마크는 BLAS의 MKL 구현과 단일 코어를 사용하는 것입니다.

두 번째는 BLAS의 OpenBLAS 구현과 단일 코어를 사용하는 것입니다. MKL과 OpenBLAS의 동작이 동일한 지 확인하는 것입니다.

세 번째는 BLAS 및 4 코어의 MKL 구현을 사용하는 것입니다. 문제는 euclidean_distances 는 BLAS LEVEL 3 함수를 통해 병렬화되지만 cdist 는 BLAS LEVEL 1 함수 만 사용한다는 것입니다. 흥미롭게도 그것은 거의 국경을 바꾸지 않습니다.

n_samples가 너무 낮지 않은 경우 (> 100), 경계는 약 32 개 피처 인 것 같습니다. n_features <32 일 때 cdist를 사용하고 n_features> 32 일 때 euclidean_distances를 사용하기로 결정할 수 있습니다. 이것은 더 빠르고 정밀도 문제가 없습니다. 이것은 또한 n_features가 작을 때 julia 임계 값이 많은 재 계산으로 이어진다는 장점이 있습니다. cdist를 사용하면 그것을 피할 수 있습니다.

n_features> 32 인 경우 줄리아 임계 값으로 업데이트 된 euclidean_distances 구현을 유지할 수 있습니다. 임계 값을 추가한다고해서 euclidean_distances 너무 느려지지 않아야합니다. 기능 수가 충분히 높아서 몇 번의 재계 산만 필요하기 때문입니다.

@jeremiedbb 좋아요,

오, 나는 이것이 모두 float64를위한 것이라고 생각합니다. float32로 무엇을합니까? 항상 기분 나쁜가요? 32 개 이상의 기능에 대한 기대감?

나는 주석을주의 깊게 읽지 않았다 (곧 예정), float64에 제한이 있다는 것을 참고하십시오. # 12128을 참조하십시오.

@ qinhanmin2014 예, float64 정밀도에는 한계가 있지만 내가 말할 수있는 모든 것에 대해 신뢰할 수있는 fp32 결과를 생성하기에 충분히 정확합니다. 문제는 fp64로 업 캐스트하는 매개 변수가 실제로 scipy의 cdist를 사용하는 것보다 저렴하다는 것입니다.
위의 벤치 마크에서 볼 수 있듯이 멀티 코어 BLAS조차도 일반적으로 더 빠르지 않습니다 . 이것은 주로 고차원 데이터 (64 차원 이상, 그 전에는 이점이 IMHO의 가치가 없음)에 적용되는 것으로 보입니다. 유클리드 거리는 고밀도 고차원 데이터에서 그다지 신뢰할 수 없기 때문에 IMHO 사용 사례는 가장 중요하지 않습니다. . 많은 사용자가 측정 기준이 10 개 미만입니다. 이 경우 cdist가 일반적으로 더 빠른 것 같습니다.

오, 나는 이것이 모두 float64를위한 것이라고 생각합니다.

실제로 float32와 float64 모두에 해당합니다 (매우 비슷하다는 의미입니다). n_features <32 일 때 항상 cdist를 사용하는 것이 좋습니다.

문제는 fp64로 업 캐스트하는 매개 변수가 실제로 scipy의 cdist를 사용하는 것보다 저렴하다는 것입니다.

업 캐스팅은 ~ 2 배로 느려지므로 n_features = 64 정도라고 생각합니다.

많은 사용자가 측정 기준이 10 개 미만입니다.

그러나 모든 사람이 아니므로 여전히 고차원 데이터에 대한 솔루션을 찾아야합니다.

@jeremiedbb 아주 좋은 분석!

저 차원 데이터의 경우 cdist를 사용하는 것이 확실히 합리적입니다.

또한 FYI scipy의 cdist는 float32를 float64로 업 캐스트 https://github.com/scipy/scipy/issues/8771#issuecomment -384015674, 이것이 정확성 문제 또는 다른 이유로 인한 것인지 확실하지 않습니다.

전반적으로 https://github.com/scikit-learn/scikit-learn/pull/12601#pullrequestreview -176076355에서 제안한대로 euclidean_distance "algorithm"매개 변수를 추가하는 것이 합리적이라고 생각합니다. 기본값은 "None"이므로 https://github.com/scikit-learn/scikit-learn/pull/12136 에서와 같이 전역 옵션을 통해 설정할 수도 있습니다

Eigen3에는 안정적인 표준을 계산하는 흥미로운 접근 방식도 있습니다. https://eigen.tuxfamily.org/dox/StableNorm_8h_source.html

좋은 설명, 이해도 향상

우리는 스프린트에서 이것에 대해 어떤 진전도 이루어지지 않았고 아마도 우리는 ... 그리고 @rth 는 오늘 주변에 없습니다.

시간을 설정하면 원격으로 참여할 수 있습니다. 오후 초에?

상황을 요약하면

유클리드 거리 계산의 정밀도 문제의 경우

• 저 차원의 경우 @jeremiedbb 가 위에서 보여준 것처럼 아마도 cdist를 사용해야합니다.
• 고차원 케이스와 float32에서 다음 중에서 선택할 수 있습니다.
  
  
  
  • 청킹, 64 비트로 거리 계산 및 연결
  
  
  • 정밀도가 문제인 경우 cdist로 돌아갑니다 (공개 질문은 어떻게됩니까-예를 들어 scipy에 문의하는 것이 유용 할 수 있습니다. )
  
  

그런 다음 유클리드, sqeuclidean, minkowski 등의 모든 불일치 문제가 있습니다.

정밀도 측면에서 @jeremiedbb , @amueller 및 나는 빠른 대화를

그래서 저는 우리가 float32에 대한 업 캐스팅에 대한 @rth 의 이전 코멘트에 만족한다고 생각합니다. cdist도 float64로 업 캐스트하기 때문에, 우리는 cdist를 다시 구현하여 float32 (그러나 float64 누산기를 사용합니까?)를 취하거나, 낮은 희미한 float32에서 복사를 줄이려면 청킹을 사용할 수 있습니다.

@Celelibi 가 # 11271에서 PR을 변경하고 싶

이 문제가 해결되면 sqeuclidean 및 minkowski (p in {0,1})가 구현을 사용하도록해야한다고 생각합니다. NearestNeighbors와의 불일치를 논의하지 않았습니다. 또 다른 스프린트 :)

스프린트에서 빠른 토론 후 우리는 다음과 같은 방식으로 끝났습니다.

• 높은 차원의 경우 (> 32 또는> 64가 최선을 선택) : float32 일 때 덩어리별로 float64로 업 캐스트하고 'fast'메서드를 유지합니다. 이런 종류의 데이터의 경우 float64의 수치 문제는 거의 무시할 수 있습니다 (그에 대한 벤치 마크를 제공하겠습니다).

• 저 차원의 경우 : sklearn에서 (업 캐스트 때문에 scipy cdist를 사용하는 대신) 안전한 계산을 구현합니다.

(Upcasting float32를 0.20.3으로 던지는 것도 유혹적입니다)

다음은 scipy와 sklearn의 속도 비교를위한 몇 가지 벤치 마크입니다.
[... 싹둑 ...]

이것은 매우 흥미 롭습니다. 나는 실제로이 결과를 기대하지 않았습니다. 벤치 마크를 다시 수행 한 결과 매우 유사한 결과를 찾았습니다. 내가 더 낮은 결정 경계를 옹호하는 것을 제외하고. 내 벤치 마크는 8 가지 기능을 제안합니다.

잘못되는 비용은 대칭이 아닙니다. cdist 는 계산이 몇 초 미만으로 지속되는 경우에만 더 좋으며 기능 수가 증가하면 정말 빠르게 느려집니다. 따라서 의심스러운 경우 BLAS 구현을 사용하는 것이 좋습니다.

편집 :이 벤치 마크는 float64에 대한 것이었지만, float64로 업 캐스팅하는 float32 행렬은 총 시간에 몇 퍼센트 만 추가하고 결론을 변경하지 않습니다.

임계 값은 벤치 마크를 실행중인 컴퓨터에 따라 달라집니다. AVX 지침과 관련이 있다고 생각합니다. 나는 내가 발표 한 벤치 마크가 AVX2 명령이없고 AVX 만있는 컴퓨터에서 실행되었다는 것을 깨달았습니다. 그리고 AVX2가있는 컴퓨터에서 당신과 비슷한 결과를 얻었습니다.

그러나 문제는 성능뿐만 아니라 정밀도에 관한 것이며 치수가 작을 때 정밀도 문제가 발생할 가능성이 더 큽니다. 아마도 16은 좋은 타협입니다. 어떻게 생각해 ?

이 논의와 관련하여 정보에 입각 한 결정을 내리려면 정확성을 벤치마킹해야합니다.

그러나 PR과 관련하여 정확도는 더 이상 문제가되지 않습니다. 그러나 약간 더 비싼 계산 비용이 발생합니다. 따라서 임계 값은 PR을 벤치마킹하여 결정해야합니다.

벤치마킹 정확도는 그렇게 쉽지 않습니다. 어려운 경우는 균일하게 분배되지 않기 때문입니다.
그리고 코너 케이스에서 발견되지 않으면 문제가 될 수 있습니다. 일반적으로 합리적인 CPU 한도 내에서 수치 정확도를 보장해야합니다.
그러나 다른 곳에서 언급했듯이 10000000.01 및 10000000.00을 사용하는 단일 기능은 알려진 문제 방정식, fp32와 함께 10000 및 10001을 사용할 때 fp64에서 숫자 불안정성을 트리거하기에 충분해야합니다. 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은이 특정 경우를 수정하지 않습니다. 즉, float64 + 높은 차원.

그러나 float32에 대해 수정합니다.

그러나 우리는 float64 + high dim의 경우 그대로 유지하기로 결정했습니다. 정확도 문제가 발생할 가능성이 거의없고 기계 학습 사용 사례에 실제로 적용되지 않기 때문입니다.

귀하의 예에서 X [0] 및 X [1]은 320000.32 및 320000과 같은 규범을 가지며 거리는 0.32, 즉 규범의 1e-6 배입니다. 기계 학습에서 16 개의 유효 숫자 (float64)가 모두 관련이있는 것은 아닙니다.

그러나 우리는 float64 + high dim의 경우 그대로 유지하기로 결정했습니다. 정확도 문제가 발생할 가능성이 거의없고 기계 학습 사용 사례에 실제로 적용되지 않기 때문입니다.

나는 이것에 대해 더 온건 할 것입니다. 차원을 줄이는 것은 ML의 일반적인 첫 번째 단계입니다. 이를 위해 MDS를 사용할 수 있으며 유클리드 거리 행렬을 많이 사용합니다.

누군가 float64 케이스의 정확도를 개선하려는 경우 중간 결과를 나타 내기 위해 두 개의 부동 소수점을 사용하는 방법이 있습니다. 나는 그것이 scikit-learn의 범위를 벗어나기 시작한다고 생각하지만.
ftp://ftp.math.ethz.ch/users/wpp/CELL/qd.pdf

나는 명확하지 않았다. 고차원 데이터가 기계 학습에 적용되지 않는다는 말은 아닙니다. float64에서 발생하는 정밀도 문제의 종류는 거리가 표준보다 6 배 더 작은 지점과 관련이 있습니다. 이러한 정밀도는 현실적인 기계 학습 모델에서 의미가 없습니다.

기계 학습에서 16 개의 유효 숫자 (float64)가 모두 관련이있는 것은 아닙니다.

나는 이것이 일반적으로 사실이라고 전혀 확신하지 않습니다.

이 예에서는 16 자리 중 15 자리의 정밀도를 잃었습니다. 정밀도의 절반을 사용하면 동의하지만 그런 관계는 없습니다. FP64에서 FP32 로의 다운 캐스팅 손실은 측정 정밀도로 인해 허용되는 경우가 많습니다. 예를 들어 소비자 용 GPU는 FP64보다 FP32에서 훨씬 빠릅니다. 그러나 그것이 모든 곳에 적용되는 것은 아닙니다.

예를 들어 k- 평균 군집화에서는 군집의 평균이 상당히 다르다는 가정 이 있으며 (사전에 평균을 알지 못하므로) 여기서 정밀도가 손실됩니다. 클러스터가 많은 경우 일부 규범은 분리에 비해 클 수 있습니다.
또한 첫 번째 초기 반복 후에 한 지점이 다른 클러스터로 전환되는 거리의 작은 차이가 종종 발생합니다. 여기서 정밀도가 떨어지면 결과에 영향을 미치고 불안정해질 수 있습니다.
이제 많은 변수가있는 시계열 조각에 대한 k- 평균을 고려하십시오.

데이터 크기가 증가함에 따라 가장 가까운 이웃까지의 거리가 더 작아 진다고 가정해야하며, 표준이 0이 아니면 결국 벡터 표준보다 작아 져 문제가 발생할 것입니다. 따라서 이것은 데이터 세트 크기가 증가함에 따라 더욱 심각해질 것입니다. 차원의 저주에 따르면 가장 큰 거리와 가장 작은 거리는 점점 더 비슷해집니다. 따라서 정확한 최근 접 이웃 순위를 계산하려면 고차원 데이터에서 우수한 정밀도가 필요할 수 있습니다. 20news 데이터 세트에서 0이 아닌 가장 작은 거리는 약 0.02입니다 (표준은 모두 1 임). 그러나 그것은 단지 10,000 개의 인스턴스이며 상당히 다양한 콘텐츠입니다. 이제 데이터 세트가 거의 중복 감지에 관한 것이라고 가정합니다.

나는 이것이 ML에서 일어날 가능성이없는 일이라고 확신 할 수 없다. 물론 모든 사람에게 영향을 미치지는 않을 것이다.

"머신 러닝에서 16 개의 유효 숫자 (float64)는 모두 관련이 없습니다."라고 말하면 계산 된 거리를 말하는 것이 아니라 데이터 X를 말하는 것입니다.
기계 학습에서 데이터는 측정 값에서 비롯되며 9 번째 자리까지 정확한 측정 값은 없습니다 (입자 물리학에서는 매우 적은 측정 값 제외).
따라서 10000000.01 및 10000000.00 의 예에서 X 값에 대한 불확실성이 훨씬 클 때 0.01 거리를 어떻게 중요시 할 수 있습니까?

KMeans의 경우 먼저 정밀도 손실의 상당 부분을 극복하는 방법이 있습니다. 관측치 x의 가장 가까운 중심을 찾을 때 대부분의 경우 치명적인 취소를 방지하는 거리 계산에 x의 표준을 추가 할 필요가 없습니다.
그런 다음 유클리드 거리를 기반으로 kmeans 군집을 만듭니다. 그러나 이것이 데이터를 수집하는 정확한 방법인지는 알 수 없습니다. 실제로 데이터가 이러한 방식으로 클러스터링 될 확률은 0입니다. Kmeans는 데이터가 어떻게 군집 될 수 있는지에 대한 추정치를 제공하며 두 군집의 경계에있는 점은 확실히 어느 하나에 속하는 것으로 간주 될 수 없습니다. 두 군집의 같은 거리에있는 점에 대한 당신의 해석은 무엇입니까? 내 데이터는 2 개의 클러스터가 하나의 클러스터 여야하거나 KMeans가 내 데이터를 클러스터링하는 데 가장 적합한 알고리즘이 아닙니다 (또는 kmeans조차도 내 데이터가 클러스터링되는 방법에 대해 다소 좋은 아이디어를 제공하지만 클러스터의 경계는 관련이 없다는 것을 알고 있습니다).

"| b | ^ 2-2ab"만 사용하면 치명적인 취소가 발생하지 않지만 차이를 만드는 숫자의 정밀도 손실은 동일합니다. 결과는 나중에 각 거리에 a의 표준을 추가 한 것과 동일합니다. 거리가 a의 표준보다 훨씬 작 으면 BLAS 해킹없이 기존 방식으로 계산을 수행하여 피할 수있는 정밀도 손실을 얻을 수 있습니다.
따라서 실제로 이런 식으로 수치 문제를 극복 할 수 없습니다!

K- 평균은 최적화 문제입니다. 따라서 그러한 해킹은 sklearn이 다른 도구보다 더 나쁜 솔루션을 찾는 것을 의미 할 수 있습니다. 그리고 앞서 언급했듯이 이것은 또한 불안정성을 유발할 수 있습니다. 최악의 경우, 이것은 sklearn kmeans가 개선없이 max_iter 까지 동일한 상태를 반복하도록 만들 수 있습니다 (로컬 최적 값을 찾으려면 tol = 0 가정). 이론은 불가능하다고 말합니다.
k- 평균이 수렴 될 때까지 두 군집에 대해 "동일한"거리를 가진 점에 대해 많은 것을 말할 수 없습니다. 다음 반복에서는 평균이 이동했을 수 있으며 그 차이는 훨씬 더 커지고 중요해질 수 있습니다!
나는 k- 평균이 잡음이 많은 데이터에서 너무 잘 작동하지 않기 때문에 열렬한 팬이 아닙니다. 그러나 그러한 경우를 더 잘 처리하는 변형이 있습니다. 그러나 그럼에도 불구하고 그것을 사용한다면 아마도 완전한 품질을 얻으려고 노력해야 할 것입니다 (이것이 항상 tol=0 사용하는 이유입니다). 적절한 계산을 수행하는 것은 충분히 저렴합니다 (그리고 언급했듯이 데이터 크기에 따라 문제가 악화됩니다. 따라서 작은 데이터의 경우 느린 런타임은 일반적으로 중요하지 않으며 큰 데이터 세트의 경우 정밀도가 더 중요해질 가능성이 높습니다).

응용 프로그램에 따라 10000000.01 와 10000000.00 가 중요

언급했듯이 평균은 잃고 싶지 않은 물리적 의미를 가질 수 있습니다. 온도가 켈빈 단위 인 데이터가있는 경우 0 : 1의 크기를 조정하거나 중앙에 배치하는 것을 원하지 않습니다. 그것은 당신의 비율 척도를 망칠 것입니다. 예를 들어, 일부 철강 제품이 냉각 될 때 온도의 시계열을 비교하고 냉각 프로세스가 철강 제품의 신뢰성에 영향을 미치는지 알아보고 싶다면. 온도가 700K 이상일 수 있으며 냉각 프로세스를 분석하려는 경우 시계열에 수백 개의 데이터 포인트가있을 수 있습니다. 시계열 길이와 함께 5 자리의 입력 정밀도 (0.01K)만으로도 숫자 문제가 발생할 수 있습니다. 결과에서 다시 1-2 자리 숫자로 끝날 수 있습니다. 이 치명적인 효과가 있다면 ML에서 정밀도가 중요하다는 것을 배제 할 수 없다고 생각합니다. 16 자리 숫자 중 10 자리 정밀도를 항상 확보 할 수 있다면 다릅니다. 여기서는 그렇게 할 수 없습니다. 최악의 경우에는 0 자리 숫자가있을 수 있습니다 (이것이 재앙적인 이유입니다).

기계 학습에서 데이터는 측정 값에서 비롯되며 9 번째 자리까지 정확한 측정 값은 없습니다 (입자 물리학에서는 매우 적은 측정 값 제외).

현실 세계의 원시 값은 그런 정확도를 거의 갖지 않습니다. 맞습니다. 그러나 ML은 이러한 종류의 입력에만 국한되지 않습니다. 루빅스 큐브와 같은 퍼즐의 그래프에 MDS를 적용하거나 팩맨을 플레이하는 RL 에이전트 무리가 찾은 성공적인 전략을 클러스터링하는 것과 같은 수학 문제에 ML을 적용 할 수 있습니다.
정보의 초기 소스가 실제 세계인 경우에도 대부분의 숫자를 클러스터링 알고리즘과 관련시키는 중간 처리가있을 수 있습니다. 매개 변수가 실제 세계에서 통계적으로 샘플링 된 함수에 대한 경사 하강 법의 결과와 같습니다.

왜 우리가 여전히 이것을 논의하고 있는지 궁금합니다. 나는 우리 모두 scikit-learn이 계산 시간에 대한 절충 정확도에서 최선을 다해야한다는 데 동의한다고 생각합니다. 그리고 현재 상태에 만족하지 않는 사람은 풀 요청을 제출해야합니다.

"| b | ^ 2-2ab"만 사용하면 치명적인 취소가 발생하지 않지만 차이를 만드는 숫자의 정밀도 손실은 동일합니다. 결과는 나중에 각 거리에 a의 표준을 추가 한 것과 동일합니다. 거리가 a의 표준보다 훨씬 작 으면 BLAS 해킹없이 기존 방식으로 계산을 수행하여 피할 수있는 정밀도 손실을 얻을 수 있습니다.
따라서 실제로 이런 식으로 수치 문제를 극복 할 수 없습니다!

정밀도는 떨어지지 만 치명적인 취소 (적어도 a와 b가 가까울 때)를 유발할 수 없으며 거리 (거리가 아님)에 대한 상대 오차가 작다는 것을 보여줄 수 있습니다.
가장 가까운 중심을 찾는 데에만 관심이있는 KMeans의 경우 순서를 올바르게 유지하기에 충분한 정밀도가 있습니다. 마지막에 관성을 원하는 경우 정확한 공식을 사용하여 각 점에서 클러스터 중심까지의 거리를 계산할 수 있습니다.

게다가 KMeans는 볼록 최적화 문제가 아니므로 수렴 될 때까지 tol = 0으로 실행하더라도 전역 최소값에서 멀리 떨어져있을 수있는 로컬 최소값이됩니다 (kmeans ++ 초기화를 사용하더라도). 그래서 나는 다른 init과 합리적으로 적은 수의 반복으로 kmeans를 여러 번 실행하고 싶습니다. 더 나은 로컬 최소값으로 끝날 수있는 더 나은 기회가 있습니다. 그런 다음 수렴 될 때까지 가장 좋은 것을 다시 실행할 수 있습니다.

실제 거리와 비교 한 상대 오차는 임의적으로 클 수 있으므로 잘못된 가장 가까운 이웃이 발생할 수 있습니다. 예를 들어 tf-idf에서 | a | ² = | b | ² = 1 인 경우를 고려하십시오. 벡터가 매우 가깝다고 가정합니다. 그러면 ab도 1에 가까우며이 시점에서 이미 많은 정밀도를 잃었습니다.
위에서 썼 듯이 치명적인 취소가 없더라도 오류가 있습니다. 8 자리 정밀도를 고려하십시오. 실제 거리는 0.000012345678 일 수 있으며 FP32 및 일반 유클리드 거리를 사용하여 8 자리 숫자로 계산할 수 있습니다. 그러나이 방정식을 사용하면 대신 ab = 0.99998765432 값을 계산합니다. FP32를 사용하면 기껏해야 약 0.99998765로 잘 리므로이 예에서는 불필요하게 세 자리의 정밀도를 잃었습니다. 손실은 재앙적인 경우만큼 큽니다. 거리가 표준보다 훨씬 작 으면이 방법을 사용하면 정밀도가 임의로 나빠질 수 있습니다.

예, kmeans는 볼록하지 않습니다. 그러나 그런 다음 최소한 로컬 최적을 찾고 정밀도가 너무 낮기 때문에 멈춤 (또는 결과 오류가 비정상적으로 작동하기 때문에 진동)하지 않기를 원할 것입니다. 당신이 그래서 적어도 잘 동작하는 경우와 여러 시도와 세계를 찾을 수있는 기회를 얻을.

이 토론에 감사드립니다.하지만 우리에게 정말로 필요한 것은 float64에 대한 업 캐스트를 중단하기 전에했던 것보다 나쁘지 않은 해결책입니다. 그런 의미에서 @Celelibi 의 업 캐스팅 솔루션으로 충분했습니다. 낮은 차원에서 정확한 솔루션을 사용하면 이전에 수행하던 작업이 추가로 향상됩니다.

향후 버전과 관련하여 높은 차원에서 정확한 계산을 고려할 때 효율적으로 감지 할 수 있다는 자신감이 더 있습니까?

난수로 float64 케이스의 평균 정확도를 평가하기 위해 벤치 마크를 실행했습니다. 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 및 Y 의 10000 쌍의 벡터 중 하나 사이의 제곱 된 유클리드 거리의 상대 오차를 나타냅니다. 가독성을 위해 상대 오차에 2 ^ 53을 곱하며, 이는 대략 ULP 단위에 해당합니다.
위의 곡선은 근사 분포입니다 (커널 밀도 추정값 사용).

그래프는 가독성을 위해 6 ULP로 잘 렸습니다. 더 나쁜 경우가 아니라 평균 사례를 보여줍니다. 확장 된 수식의 오류는 상당히 커질 수 있습니다.

이 결과에 대한 나의 분석은 평균적으로 확장 된 공식의 상대적 오차는 몇 가지 특징으로 매우 클 수 있지만 빠르게 차이와 numpy 합계의 오차와 비슷해집니다. 임계 값은 5 ~ 10 개 기능 사이입니다.

나는 또한 현재 병리학적인 예뿐만 아니라 확장 된 공식의 오류에 대한 상한선을 찾으려고 노력하고 있습니다.

@ kno10 의 우려는 종종 다음과 같은 경우에 관심이 있다는 것입니다.
점이 무작위로 분포되어 있지는 않지만 서로 가깝거나 단위가 있습니다.
표준.

사실,하지만 실제로, 그것은 완전한 BS 아니라고 확신 할 필요가 있었다. ^^

위의 설명을 완료하려면 수식 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

ULP의 히스토그램 플롯이 ULP 내 오류 분포가있는 위의 애니메이션보다 더 합리적이라고 생각합니다. 따라서 0 ULP 오류와 1 ULP 오류는 "가득한대로"입니다. 2 ULP는 sqrt 때문에 피할 수 없습니다. 더 큰 오류는 조사 할 가치가 있다고 가정합니다.

정확한 값이 크면 (computed - exact) / exact 것이 합리적입니다. 그러나 정확한 값에 대한 수치 적 도전을 받으면 이것은 상당히 불안정 해집니다. 이러한 경우 (computed-exact)/norm 대신 사용할 가치가 있습니다. 즉, 파생 된 거리와 비교하지 않고 입력 데이터와 비교 한 거리 계산의 정밀도를 살펴볼 수 있습니다.
1 ULP 만 다른 2 개의 1 차원 값이 있고 2 ULP의 오류가 엄청나게 보일 수 있습니다. 그러나 우리는 이미 입력 데이터 해상도에 있으므로 결과가 상당히 불안정합니다.
여러 차원을 사용하면 입력 데이터에서 더 높은 해상도를 얻을 수 있습니다.

(1, 1e-16) 대 (1, 2e-16) 유형의 입력 데이터를 고려하십시오. 예를 들어 입력 데이터에 상수 속성이있는 경우 (예 : MNIST의 흰색 픽셀).
차이 기반 방정식을 사용하면 괜찮지 만 도트 버전이 문제가되지 않습니까? 그렇기 때문에 1 차원 실험으로는 이것을 연구하기에 충분하지 않을 수 있습니다.

ULP의 히스토그램 플롯이 ULP 내 오류 분포가있는 위의 애니메이션보다 더 합리적이라고 생각합니다.

나는 당신이 그것을 어떻게 표현했는지 잘 모르겠습니다. 기능 수 및 알고리즘 당 하나의 히스토그램이 있습니다. 3D 플롯이나 애니메이션 외에는 할 수있는 일이별로 없습니다.

정확한 값이 크면 (computed - exact) / exact 것이 합리적입니다. 그러나 정확한 값에 대한 수치 적 도전을 받으면 이것은 상당히 불안정 해집니다.

이 맥락에서 불안정하다는 것이 무엇을 의미하는지 잘 모르겠습니다. 정확한 값은 정확히 만들기 위해 필요한 모든 것을 사용하여 계산해야합니다.
(말하자면, 정확히 반올림 된 결과와 비교하는 대신 내 플롯에서도 임의의 정밀도로 상대 오차를 계산해야했습니다. 플롯을 업데이트했는데 이상한 파도가 사라졌습니다.)

이러한 경우 (computed-exact)/norm 대신 사용할 가치가 있습니다. 즉, 파생 된 거리와 비교하지 않고 입력 데이터와 비교 한 거리 계산의 정밀도를 살펴볼 수 있습니다.

내가 당신의 아이디어를 올바르게 이해한다면 절대 오차를 입력 데이터의 크기와 비교하는 것이 좋습니다. 벡터 노름을 입력 크기의 집계 척도로 사용합니다. 표준 상대 오차는 정확한 결과의 크기와 비교합니다.

이 메트릭을 사용하여 알고리즘에 얼마나 많은 결함 이

• 결과의 몇 자릿수가 정확하지 않은지는 실제로 말하지 않습니다.
• 실제로 대부분의 알고리즘의 점수는 1e-15 미만입니다. 확장 된 공식 (점 기반 알고리즘)조차도 5 ULP (입력) (대략 추정, 완전한 증명을 작성하지 않음)와 같은 점수로 제한됩니다.
• 그리고 두 측정 항목 모두 절대 오류 computed - exact 의 재조정 된 버전이므로 동일한 입력에 대해 평가할 때 동일한 순서로 알고리즘의 순위를 매 깁니다.
  따라서 값 해석이 덜 유용하다는 점만 제외하면 일반적인 상대 오차와 동일합니다 (IMO).

(1, 1e-16) 대 (1, 2e-16) 유형의 입력 데이터를 고려하십시오. 예를 들어 입력 데이터에 상수 속성이있는 경우 (예 : MNIST의 흰색 픽셀).
차이 기반 방정식을 사용하면 괜찮지 만 도트 버전이 문제가되지 않습니까? 그렇기 때문에 1 차원 실험으로는 이것을 연구하기에 충분하지 않을 수 있습니다.

점 기반 알고리즘의 상대 오류는 1 . 이는 오류가 정확한 결과만큼 크기 때문에 결과의 숫자가 정확하지 않음을 의미합니다. 측정 항목의 값은 1e-16 가됩니다. 즉, 벡터 표준의 척도에 비해 16 번째 숫자 만 꺼져 있음을 의미합니다.
이 예에서 무엇을 보여 주려는 지 잘 모르겠습니다.

우리가 여전히 float64를 사용한 euclidean_distances의 정밀도에 대해 우려하고 있다면, 여기에 100 개의 주석이 있으므로이 토론을 새로운 문제에 요약하는 것이 좋습니다.