imho를 변경하기에는 너무 늦었습니다.

이것은 모든 numpy에서 가장 널리 사용되는 함수 중 하나입니다 ( assert_allclose ). 유일한 경로는 다른 이름을 선택하는 것입니다.

나는 현재 구현이 버그처럼 보인다고 고백한다. 참고 사용하여 해당 max(abs(a), abs(b)) 대신 abs(b) 기존의 테스트를 중단하지 않습니다, 그것은 단지의 경우 그에 조건을 완화 abs(a) > abs(b) .

적어도 이것은 내장과 일치하지 않는다는 docstring에 경고가 필요합니다.

이것을 추가하는 것은 어떻습니까?

from numpy.__future__ import isclose

덧붙여서, 그것은 난수 버전 관리에 대한 아이디어 일 수 있습니다 ...

설명을 위해 가져 오기는 실제로 isclose를 가져 오지 않지만 새로운 의미 체계를 활성화합니다. 그것은 모듈로 퍼질 것입니다.

아이디어는 사람들이 올바른 기능을 사용하도록 허용하는 동시에 기존 코드를 깰 필요가 없다는 것입니다.

, 가져 오기는 실제로 isclose를 가져 오지 않지만 새로운 의미를 활성화합니다.

나는 이것을 수입하지 않는 것이 가능하다고 생각하지 않습니다. 마찬가지로, 더 긴 이름을 선택 mathlike_ufunc 다룰 수있는, S remainder 뿐만 아니라.

from __future__ import print_function 실제로 print_function 전역을 생성합니다.

실제로 from __future__ import * 스타일의 가져 오기는 여기에 적합하지 않을 수 있습니다. 파이썬에서는 파일 별 수준에서 _syntax_에 영향을 미치며 numpy에서 비슷한 작업을 수행하는 것은 까다로울 것입니다.

반복기 예외는 구문 변경이 아닙니다. 호출 모듈의 네임 스페이스를 검사하려면 작은 C 모듈 만 있으면됩니다. 우리는 모듈을 캐시하여 가져 오기 시간 만 느리게 할 수도 있습니다.

당신 말이 맞고 true_division 은 분명히 isclose와 유사합니다.

이것은 더 이상 사용되지 않는 기능을 관리하기 위해 with 문을 사용하는 대신 # 9444의 문제를 피할 수있는 좋은 방법입니다.

math.isclose 의 제작자로 @ ChrisBarker-NOAA를 CC합시다.

이것은 매우 사소한 문제 IMO입니다. 일반적으로 atol 및 rtol 는 테스트가 통과 될 때까지 조작하여 선택하며, 목표는 허용 오차보다 훨씬 큰 오류를 포착하는 것입니다. @charris가 제안한 것처럼 rtol 부분을 ​​완화하는 것이 합리적 일 수도 있지만,이 작은 조정을 위해 스택 내부 검사 트릭을 끌어낼 가치가 없다고 생각합니다. 그리고 우리는 isclose 가 종종 assert_allclose 또는 다양한 타사 테스트 도우미에 의해 간접적으로 호출된다는 문제가 있습니다.

__future__ 스타일 가져 오기 사용에 대해 StackOverflow에 요청했습니다. https://stackoverflow.com/questions/29905278/using-future-style-imports-for-module-specific-features-in-python

TLDR : 가능하지만 쉽거나 깨끗하지는 않습니다.

스택 인트로 스펙 션은이를위한 것이 아니라 함수의 반환 값을 변경하기위한 일반적인 정책으로 제안됩니다. 문제는 원칙적으로 이것이 변경되어야 하는가입니다. 대답이 '예'라면 광범위한 사용을 감안할 때 사용 중단 기간은 최소한 몇 년이되어야한다고 생각합니다. Python은 과거 모듈을 포함하지 않았지만 수요가있는 경우 API 안정성을 개선하기위한 하나의 옵션입니다.

다른 방법은 isclose(...,symmetric=True) 또는 assert_allclose(symmetric=True) 옵션으로 추가하는 것입니다. 여기서 기본값은 현재 상황 인 False 입니다.

나는 이것이 rtol 및 atol 값에 의미를 부여하지 않을 때 사소한 문제라는 데 동의합니다. @njsmith가 언급 한대로 단위 테스트를 통과하도록 조정하면됩니다.

그러나 때로는 오류가 1 % ( rtol=0.01 ) 내에 있다고 말할 수 있습니다.
이 경우 rtol 측정에 관한 최악의 경우 오류는 100 %입니다 ( rtol * abs(b) 가 atol 가까워지면 atol + rtol * abs(b) ~= 2 * rtol * abs(b) ).

일부 값은 ~ 2 % 오류로 통과 할 수 있습니다.

atol = 1e-8 #default
rtol = 0.01 # 1%

b = 1e-6
a = 1.0199e-6 # ~ 2% larger comapared to b
abs(a - b) <= (atol + rtol * abs(b))
True

@charris 의 아이디어를 구현하면이 특정 경우가 매우 약간 더 나빠질 수 있습니다. 비교를 훨씬 더 완화하기 때문입니다.하지만 대칭 문제를 제거하고 실제로 이전 버전과 호환되므로 여전히 가치가 있습니다.

IMO는 Numpy가 Math 기능을 사용하는 것이 더 나을 것이지만, 변경이 너무 파괴적이고 대부분의 사용자에게 중요하지 않을 수 있음을 이해합니다. isclose 코어간에 변경하는 옵션을 만드는 것이 유용합니다.

@njsmith : 데려와 주셔서 감사합니다.

약간의 역사 : 내가 stdlib에 대해 isclose를 제안했을 때 우리는 확실히 numpy를 선행 기술로 보았습니다. 나만 있었다면 호환성을 위해 호환 가능한 접근 방식을 사용했을 수 있습니다 :-).

하지만 나머지 커뮤니티 생각은 파이썬에 "올바른"일을하는 것이 더 중요하다고 생각했기 때문에 긴 토론이 이어졌습니다. 저는 PEP에서 대부분의 요점을 포착하려고 노력했습니다.

다음은 numpy에 대한 참조입니다.

https://www.python.org/dev/peps/pep-0485/#numpy -isclose

이 토론에서와 동일한 요점이 만들어 졌음을 알 수 있습니다.

결국 세 가지 핵심 사항이 나왔습니다.

1) 대칭 접근 방식은 최소한의 놀라움을 초래합니다.

2) 인수의 크기에 대한 가정을하지 않도록 기본 절대 허용 오차는 아마도 0이어야합니다.

3) "약한"테스트와 "강한"테스트의 차이는 예상되는 사용 사례와 마찬가지로 작은 허용 오차로 사용될 때 무관했습니다.

결국 우리가 math.isclose를위한 "최고의"솔루션을 생각해 냈다고 생각합니다.

그러나 이전 버전과의 호환성을 깨기에 충분할만큼 "더 나은"가요? 나는 그렇게 생각하지 않는다.

불행히도 많은 numpy (및 python)에는 유용했기 때문에 많은 기능이 추가되었지만 현재 논의가 많지 않은 상태에서 이러한 것들에 대해 많은 차선책이 있습니다. 이것은 젊은 도서관에 예상되는 (필요한) 것이며, 우리는 지금 그것과 함께 살아야합니다.

@njsmith 가 맞습니다-np.isclose ()의 사용은 엄격한 FP 오류 분석에 의해 설정된 허용 오차가 있지만 오히려 np.isclose () 자체로 오류를 시도합니다.

그러나 더 큰 문제는 기본 atol 라고 생각합니다. 즉, 인수가 순서 1이라고 가정합니다. 이는 매우 잘못된 가정 일 수 있으며, 테스트를 통과하면 안되는 경우가 많기 때문입니다. , 사용자가 눈치 채지 못할 수 있습니다.

In [85]: np.isclose(9.0e-9, 1.0e-9)
Out[85]: True

아야!

예, atol 원인입니다.

In [86]: np.isclose(9.0e-9, 1.0e-9, atol=0.0)
Out[86]: False

따라서 앞으로 나아갈 길을 갖는 것은 좋은 생각 일 것입니다.

나는 키워드 인수 아이디어를 좋아합니다. __future__ 등을 엉망으로 만드는 것보다 훨씬 간단 해 보입니다.

그런 다음 사용 중단 경고를 발행하고 궁극적으로 다운 스트림 기본 여러 버전을 변경할 것인지 결정할 수 있습니다.

@bashtage 의 제안을 제안하고 싶습니다.

"" "
다른 방법은이 옵션을 isclose (..., symmetric = True) 또는 assert_allclose (symmetric = True) 옵션으로 추가하는 것입니다. 여기서 기본값은 현재 상황 인 False입니다.
"" "

새 함수 이름보다 더 나은 옵션이라고 생각하며 향후 사용 중단 및 기본값 변경 (또는 그렇지 않음)으로 이어질 수 있습니다.

(강력한) 대칭 테스트 외에도 atol 기본적으로 0으로 설정되어야한다고 생각합니다.

이를 감안할 때, 나쁘지는 않지만 symmetric 보다 더 나은 매개 변수 이름이 필요할 수 있습니다.

아-그리고 assert allclose() 외에도 numpy의 다른 곳에서 isclose() 가 호출되지 않는지 확인하는 것이 좋습니다.

가장 쉬운 방법은 지원 중단 경고를 입력하고
병합하기 전에 제거하십시오. 우리는 계속해서
기존 코드를 다음과 같이 변경하라는 사용 중단 경고
대칭 = 거짓; 기본값이되어야한다고 말할 이유가 없습니다.
경고가 있어도 곧 변경됩니다.

assert_allclose 에도 추가해야합니까, 아니면 그냥 조용히 변경해야합니까? 사람들이 경고를 없애기 위해 모든 테스트를 업데이트하도록하는 것은 허용 오차 감소를 수정하기 위해 테스트를 업데이트하도록하는 것과 실제로 다르지 않습니다.

@xoviat @ eric-wieser assert_allclose 대한 이전 버전과 호환되지 않는 변경 사항도있을 수 없으며, 너무 지장을주는 사용 중단 경고도 없습니다. 지원 중단 경고를 표시 할 위치를 놓친 경우가 아니면?

이것은 여전히 ​​극소수에 대한 많은 고통처럼 들릴 까봐 두려워
나에게 이득.

기본적으로 atol이 0이 아닌 것은 우연이 아닙니다. 얻기 위해 필요합니다
예상 결과에 다음이 포함 된 모든 테스트에 대한 합리적인 기본 동작
정확한 0.

assert_allclose에 대한 변경은 필요하지 않습니다.
내부적으로 이전 동작을 사용합니다.

IMO의 조용한 변경은 끔찍합니다! 지원 중단 경고는
사람들은 결국 대화 형 프롬프트에 플래그를 입력 할 필요가 없습니다.
새로운 행동을 얻으십시오.

IMO의 조용한 변경은 끔찍합니다!

동의합니다. 그러나 변경 사항이 없어야합니다. 널리 사용되는 함수의 지원 중단 경고는 사용자 (적어도 실제로 유지 관리를 수행하는 사용자)가 변경하도록 강제합니다.

@charris가 제안한 어떻 습니까? 이것은 또한 atol != 0.0 때 발생할 수있는 나쁜 일들에 대한 경고로 채워질 수있는 문서 공간을 확보 할 수 있습니다.

사람들에게 변경 사항을 알리지 않고는 문제를 해결할 수 없습니다.
행동. 내가 그 방법을 아는 유일한 방법은 경고입니다.

정말 좋은 것은 플래그를 삽입하는 자동화 된 리팩토링 도구입니다.
이전 코드로. 그런 다음 '유지 관리'는 사용자의
암호; 5 분의 작업.

죄송합니다. 새 플래그로 문제를 해결할 수 있습니다.

@charris가 제안한 어떻 습니까?

그 제안 (https://github.com/numpy/numpy/issues/10161#issuecomment-349384830)이 가능해 보입니다.

사람들에게 변경된 행동에 대해 알리지 않고는이 문제를 해결할 수 없습니다.

우리는 그것을 고치는 것이 아닙니다. 이것은 의미 론적 버전 문제에서 방금 논의 된 모든 변경의 비용 / 편익에 관한 것입니다. 이것은 널리 사용되는 테스트 기능에서 변경하거나 경고를 발행하지 않는 경우입니다. 현재 동작은 버그가 아니라는 점에 유의하십시오 (아마도 차선책 일 수 있음).

명확하게 말하면 isclose에 대한 변경을 제안했지만 assert_allclose가 아닙니다.
출처를 살펴보면 그 변화는 파괴적 일 것입니다.
그러나 이점은 여전히 ​​너무 작습니다. 나는 아무도 생각하지 않는다
그래도 플래그를 추가하는 객체, 맞습니까?

나는 아무도 플래그를 추가하는 것에 반대하지 않는다고 생각합니다. 맞습니까?

확실하지 않습니다. 세부 사항에 따라 다릅니다. @charris 의 제안에는 플래그가 필요하지 않을 수 있으며이를 도입하는 플래그는 배열에 대해 약간 의문의 여지가 있습니다.

In [1]: import math

In [2]: math.isclose(0, 1e-200)
Out[2]: False

구체적인 동기와 사용 사례없이 플래그를 추가하는 것을 반대합니다. 유용한 리트머스 테스트 : 초보 개발자가이 플래그가 존재하는 이유를 묻는다면 어떻게 설명 하시겠습니까?

어떻게 설명 하시겠습니까?

1. math.isclose 호출을 벡터화하려면 symmetric=True 플래그를 사용합니다.
2. 기존 코드를 깨지 않도록 플래그 여야했습니다.

실제 문제가 해결되는 상황을 더 찾고 있습니다.

아마 여기서 해결되는 유일한 문제는 초보자를 만드는 것입니다.
부동 소수점 정확도에 대해 더 많이 생각하십시오. @rgommers의 예는
잘못된 것 같지만 정말 작은
번호? IMO는 math.isclose 구현이 더 낫지 만
그것에 대한 합의가 있다고 생각합니다. 불행히도 실제로
숫자가 "가까운"지 여부를 확인하기위한 단일 크기 솔루션입니다. 그러나
다른 사람의 응답을 기반으로 (틀린 것이 아닙니다!), 정말
앞으로 API에 대한 모든 변경. 취할 수있는 유일한 조치는
아마도 문서 업데이트 일 것입니다.
이전에 깃발이 괜찮을 것이라고 생각 했습니까?)

확실히 math.isclose 와 비교하고 원하는 경우 rtol 및 atol을 설정하여 동일한 벡터 동작을 얻는 방법을 문서화하는 메모는 괜찮을 것입니다.

또한 내가 올바르게 이해한다면 @charris 는
현재보다 덜 관대하다.
모든 테스트. 나는 아직도합니다 (이 경고를 방출 할 수있는 좋은 아이디어가 될 것이라고 생각
경고는 한 번만 발생해야 함) isclose가 발생하는 상황이있는 경우
이전에는 그렇지 않았을 때 숫자를 "가까운"것으로 간주합니다. 그것은 많이동작보다 조용히하지시키는
영향을받을 때 누구나 알고 있습니다.

나는 우리가 논의하는 것에 대해 약간의 설명이 필요하다고 생각합니다. math.isclose 다르게 만드는 두 가지가 있습니다.

• atol 대한 다른 기본값
• rtol 의 다른 정의

나는 우리가 첫 번째 문제에 대해`math.isclose와 다른 것으로 문서화하는 것 외에는 아무것도 할 수 없다고 생각한다.

두 번째 문제는 기본값이 False symmetric 인수를 추가하여 해결하는 것이 가장 좋습니다. 이제 우리는 문서에 쓸 수 있습니다. _ " np.isclose(x, y, symmetric=True, atol=0) 는 math.isclose(x, y) "_의 벡터화 된 버전입니다. 저에게는 이것이 우리가 해결하려고하는 것 같습니다.

여기에서 세 가지 옵션이 있습니다.

1. 추가 인수를 문서화하고 다른 작업은 수행하지 않습니다.
2. 인수없이 isclose 호출을 중단하고 사용자가 경고없이 이전 동작을 가져 오도록 isclose(..., symmetric=False) 를 작성하도록합니다 ( allclose 와 유사 함). 나는 이것이 너무 많은 코드를 치지 않을 것이라고 생각하지만, 그 결과는 큰 이득을 얻지 못하여 읽기가 어렵습니다. assert_close 는 내부적으로 isclose(..., symmetric=False) 를 호출하도록 변경되므로 해당 사용자는 영향을받지 않습니다.
3. 위와 비슷하지만 assert_close symmetric 인수도 필요합니다. 이것은 다운 스트림에서 엄청난 이탈이 될 것입니다.
4. 동작을 조용히 변경

이 중 1 번 옵션은 반대 할 수 없다고 생각하지만 나머지는 중단 할만한 가치가있는 것 같지 않습니다.

편집 : 2는 동작이 변경되는 경우에만 경고가 발생하는 경우 허용 될 수 있으며 훨씬 덜 시끄 럽습니다.

@ eric-wieser 세 번째 차이점이 있습니다. atol 와 rtol 가 결합되는 방식입니다. ( math.isclose 는 max , numpy.isclose 는 + ). 즉, atol 또는 rtol 가 0이 아닌 경우 math.isclose 호출을 numpy.isclose 호출과 일치시키는 일반적인 방법이 없습니다.

그래도 사용자가 볼 수있는 API를 추가 할 가치가 없다고 생각합니다.

나는 옵션 2를 선호했습니다. 나는 여전히 그 옵션을 선호합니다.
numpy가 자동으로 제공하는 추가 규정
리팩토링 도구 (entry_points에 추가됨)는
기존 프로젝트를 수정합니다. 다른 사람들의 말에 따르면
이 옵션은 다른 사람들이 선호하지 않습니다.

나는 그렇지 않으며 3 번이나 4 번 옵션에 찬성 한 적이 없습니다. 에
또한 경고가 발생할 때까지 기능 동작 변경을 선호하지 않습니다.
4 개 이상의 주요 릴리스에 대해 방출되었습니다.

다른 사람들이 (그들이 가지고있는) 옵션 2에 동의하지 않는다고 가정하면, 나는
옵션 1을 선호합니다. 그러나 다른 사람들 (특히 @njsmith)은 선호하지 않습니다.
여기에서 제공 한 옵션 중 하나입니다. 적어도 그것은 내 생각입니다.

@njsmith 맞지 않습니다. 플래그로 함수 동작을 변경할 수 있습니다.

세 번째 차이를 핸드 웨이브로 접어 _ "rtol은 다르다"_

"" "
실제 문제가 해결되는 상황을 더 찾고 있습니다.
"" "
도넛에 돈을 걸겠습니다. (이게 무슨 뜻인지 모르겠습니다.) atol이 테스트를 훨씬 덜 민감하게 만들기 때문에 통과해서는 안되는 테스트가 있습니다. 있어야합니다.

현재 구현에는 세 가지 "문제"가있는 것 같습니다.

1) 대칭이 아닙니다.

• 나는 그것이 너무 나쁘다고 생각하지만 실제로 큰 문제는 아니며 값이 실제로 가까울 때 거의 차이가 없습니다 :-) 나는 _think_ rtol <1e-8 (적어도 atol이 0.0이면)이면 문자 그대로 차이가 없습니다.

2) atol은 0과 비교할 수없는 경우에도 결과에 영향을 미칩니다 (피할 수 없음).하지만 약 2 배 정도의 허용 오차를 효과적으로 변경합니다. 또는 atol이 크면 훨씬 더 많은 양으로 작업 할 경우 그럴 수 있습니다. 크기 값.

3) atol은 0이 아닙니다. 기본값입니다 .-- 실제로 이것이 가장 큰 문제라고 생각합니다 (특히 두 가지를 모두 추가하는 현재 알고리즘에서) 안되는 테스트 통과로 쉽게 이어질 수 있기 때문입니다. 약간 게으르다-우리는 기본 허용 오차로 테스트를 작성하고 통과하면 끝났다고 생각합니다. (내가 그것이 작동하는 방법이라는 것을 깨달았을 때, 나는 y 코드로 돌아가서 그 중 몇 개를 찾았습니다-웁스!

이 스레드의 누군가는 "다음과 같은 경우에 뭔가 짜낼 수 있습니다.

isclose (1e-200, 0.0)

기본적으로 False를 반환합니다. 동의하지 않습니다-예, 놀랍지 만 사용자가 무슨 일이 일어나고 있는지 생각하도록 강요하는 반면 현재 구현은 다음과 같은 결과를 낳습니다.

[8]에서 : np.isclose (1e-20, 1e-10)
출력 [8] : 참

정말? 하나는 MAGNITUDE의 TEN ORDERS가 다른 것보다 크고 다시 True ????

내 요점은 atol이 0이 아니면 0과 비교하는 일반적인 경우에는 덜 놀라운 결과를 제공하지만 작은 숫자로 작업 할 때 훨씬 더 위험하고 잘못된 결과를 제공한다는 것입니다 (작은 실제로는 크기 1보다 작은 것임).

그리고 1e8보다 큰 숫자로 작업하는 경우 기본 atol도 부적절합니다.

그리고 (2)와 결합하면 기본 atol이 놀라운 방식으로 상대 허용 오차 테스트를 망칠 수 있음을 의미합니다.

그래서 : 아니오, 그것은 버그가 아니며 "깨진"것도 아니지만 꽤 차선책이므로 더 나은 구현으로 나아갈 수있는 방법이 있으면 좋을 것입니다.

나는 플래그 접근 방식을 좋아했지만 마음이 바뀌고 있다고 생각합니다. 문제는 우리가 그것을 사용하지 않고 어느 시점에서 기본 플래그를 변경하지 않는 한 거의 모든 사람들이 "이전"알고리즘을 사용하게 될 것이라는 것입니다. 거의 영원히. 그리고 왜 우리가 그것을 비난 할 수 없는지에 대한 많은 좋은 주장이있었습니다.

그래서 아마도 새로운 이름을 가진 새로운 기능이 필요합니다. 우리는 사람들이 새로운 것을 사용하도록 장려하는 문서에 추가 할 수 있고, 사람들이 새로운 것을 사용할 때 어떤 시점에서 경고를 추가 할 수 있지만, 우리는 누구의 코드도 깨뜨리지 않을 것입니다.

누구나 새로운 기능의 좋은 이름에 대한 아이디어가 있습니까 ????

어쩌면 np.math.isclose와 친구들? 모르겠어요.

그러면 np.remainder 차이도 해결되고 from numpy import math 사용하여 코드를 쉽게 벡터화 할 수 있습니다.

그래서 저는 np.math 모듈에서 +1 됩니다.

10 년 동안 그렇게 작동했던 다른 기능과 약간 다른 동작을 가진 새로운 기능을 도입하는 것은 일반적으로 매우 좋지 않은 생각입니다. 이 경우 문서로 적절하게 해결할 수없는 문제는 거의 없습니다. 그래서 새로운 기능에서 -1. 그리고 완전히 새로운 서브 모듈에서는 확실히 -1입니다.

정말? 하나는 MAGNITUDE의 TEN ORDERS가 다른 것보다 크고 다시 True ????

당신의 기대가 참인지 거짓인지는 전적으로 문맥에 달려 있습니다. 그것이 [0, 1)의 연속 분포에서 나온 숫자에 대한 것이라면 예, 아마도 True를 기대할 것입니다. 사용자는 절대 / 상대 허용 오차와 함수가 실제로하는 일을 이해해야합니다. 그것이 바로 문서의 목적입니다.

symmetric_isclose() 은 (는) 약간 장황하지만 제 눈에는 불쾌하지 않습니다.: bikeshed : 그림 이모티콘>

2017 년 12 월 10 일 오후 8:09에 Ralf Gommers [email protected] 은 다음과 같이 썼습니다.

다른 동작과 약간 다른 동작으로 새로운 기능을 소개합니다.
10 년 동안 그렇게 작동했던 기능은 일반적으로
생각.

나도 좋아하지 않습니다.하지만 변경 사항으로 사람들의 코드를 깨는 것은 더 나쁩니다.
numpy를 개선하지 않는 단순한 것 외에 다른 아이디어가 있습니까?

이 경우 제대로 될 수없는 문제는 많지 않습니다.
문서로 해결되었습니다.

동의하지 않습니다. 기본값이 중요합니다.

매개 변수를 조정할 수있는 방법이 없다고 생각합니다.
대칭 비교.

그리고 완전히 새로운 서브 모듈에서는 확실히 -1입니다.

나도. numpy없이 수학 모듈에 다른 것이있는 경우
유용한 등가물은 numpy의 네임 스페이스에 추가 할 수 있습니다.
다른 모든 것처럼.

정말? 하나는 MAGNITUDE의 TEN ORDERS가 다른 것보다 큽니다.
진실????

당신의 기대가 참인지 거짓인지는 전적으로 문맥에 달려 있습니다.

바로 그렇기 때문에 atol에 "합리적인"기본값이 없습니다.

[0, 1)의 연속 분포에서 나온 숫자에 대한 경우
예, 아마도 True를 기대할 것입니다.

그러나 isclose는 상대적인 비교로 광고됩니다.
상대성은 완전히 사라지고 있습니다.
사용자가 그것에 대해 생각할 필요없이.

그게 내 요점입니다. 기본값은
자릿수 1의 값이어야합니다. 일반적인 경우입니다.
만능인.

이것은 더 나쁘게 내려갑니다-거짓 음성 또는 거짓 양성입니다.
그리고 테스트의 일반적인 사용 사례에서 오탐은 훨씬 더 나쁩니다.

(예 : 통과해서는 안되는 테스트)

사용자는 절대 / 상대 공차와
함수는 실제로합니다.

물론입니다.하지만 함수에는 합리적인 기본값과
이해하기 쉬운 강력한 알고리즘.

나는 문서를 개선하고 기능은 그대로 두는 경향이 있습니다. 대칭의 부족은 "isclose (a, b)는 a가 b에 가깝다는 것을 의미하지만 부동 소수점의 절대 정밀도가 다양하기 때문에 항상 b가 a에 가까운 경우는 아닙니다. b는 예상 결과이고 a는 실제 결과 여야합니다. " 이것은 테스트에 의미가 있습니다. 대칭 함수 케이스는 실제로 정당화하기가 조금 더 복잡합니다. 나눗셈을 포함하는 상대 오차는 대칭이 아닙니다.

나도 좋아하지 않습니다.하지만 변경 사항으로 사람들의 코드를 깨는 것은 더 나쁩니다. numpy를 개선하지 않는 단순한 것 외에 다른 아이디어가 있습니까?

새 함수를 추가하는 것이 새 함수가없는 것보다 낫다는 가치 판단을 이미 통과하고 있습니다. imho가 아닙니다. 세 가지 옵션 :

1. 브레이킹 체인지-허용되지 않습니다. 논의를 중단 할 수 있습니다.
2. 더 나은 문서 추가
3. 기능 추가

2는 전반적으로 3보다 나은 선택이므로 numpy를 "더 나은"것으로 만듭니다. 당신은 또한이 atol / rtol이 단일 기능에 국한되지 않는다는 것을 무시하고 있습니다. 그래서 다음은 새롭고 약간 "더 나은" assert_allclose ? 이것은 문서 전용의 경우를 더욱 명확하게합니다.

이것은 매우 심각한 결함입니다. 기본적으로 코드 테스트에 버그가 있습니다. 좋지 않습니다. numpy.isclose 및 기본 atol로 테스트되는 달에 무엇이든 보내시겠습니까? 나는 두 번 생각할 것입니다. 그래서 우리는 문서에서 이러한 함정을 눈에 띄게 만들어야합니다.
별칭 함수를 추가하면 사용자에게 강요하지 않는 한 코드베이스가 복잡해집니다 (발생하지 않음).

나는 대칭이 사소하다는 데 동의하지만 우리는 여전히 그것을 고쳐야합니다. 그대로두면 실제 함정에서 사용자의주의가 산만해질 수 있습니다.

@rgommers 는 다음
"" "
새 함수를 추가하는 것이 새 함수가없는 것보다 낫다는 가치 판단을 이미 통과하고 있습니다. imho가 아닙니다.
"" "
글쎄, 나는 math.isclose 에 대해 생각하고 토론하는 데 많은 시간을 보냈고, 우리는 다른 것들 중에서 numpy 구현을 살펴 보는 것으로 시작했습니다. 그렇습니다. 저는 그 접근 방식이 더 낫다고 생각합니다. 그리고 저는이 토론에서 그것이 거의 합의라고 생각했습니다.

그리고 더 나은 알고리즘 / 인터페이스를 numpy로 가져 오면 더 좋습니다.

아마도 numpy에서 이전 기능과 새 기능을 모두 갖는 것이 단순히 이전 (아마 더 잘 문서화 된) 기능을 그대로 두는 것보다 낫지 않다는 것을 의미합니다. 물론, 그것은 완전히 타당한 요점입니다. 그러나 저는 그 논의를하지 않으려 고했습니다. 그리고 이전 코멘트는 "10 년 동안 그렇게 작동해온 다른 기능과 약간 다른 동작으로 새로운 기능을 도입하는 것은 일반적으로 매우 좋지 않은 생각입니다." 토론을 종료하는 것처럼 보였습니다. 내 요점은 새로운 방법이 그만한 가치가있는 것보다 "충분히 낫다"는 것입니다. 우리가 분명히 합의하지 못한 것은이 특정 옵션이 "더 나은"지 아닌지 "충분히 더 나은지"입니다.

그건 그렇고, 나는 개인적으로 그것이 변화의 가치가 있다고 스스로 확신하지 못했지만 나는 토론하고 싶습니다.

여기서 핵심은 제 부분에 대한 몇 가지 가정입니다. 나는 그들이 옳은지 확실히 알 수 있을지 모르겠지만 :

1) np.isclose ()의 가장 큰 사용은 테스트를위한 것입니다-당신의 대답은 당신이 기대하는 것에 충분히 가깝습니까? -이것은 np.assert_all_close를 통하거나 더 직접적으로 pytest 테스트에서 또는 ....

2) 대부분의 사람들은 대답이 얼마나 좋은지 결정하기 위해 엄격한 부동 소수점 오류 분석과 같은 작업을 수행하지 않습니다. 오히려 값을 시도하고 실패하면 결과를보고 그것이 실제로 오류인지 또는 테스트의 허용 오차를 조정해야하는지 결정합니다.

• 이것은 atol과 rtol이 병합되는지 여부와 테스트가 대칭인지 여부가 그다지 중요하지 않다는 것을 의미합니다.

3) 대부분의 사람들은 (2)에서 기본 허용 오차로 프로세스를 시작하고 테스트가 실패한 경우에만 허용 오차를 조정합니다.

• 이것은 기본 atol을 사용하는 것이 매우 위험하다는 것을 의미합니다. 테스트를 통과하면 안되는 것은 정말 나쁜 일입니다.

4) 사람들은 문서를 읽지 않습니다 (초기 "내가 이것을 어떻게 부르는가"단계를 넘어서)-적어도 그들이 혼란스러운 행동을 발견 할 때까지는 말입니다. 그런 다음 그들은 들어가서 혼란을 해소하기 위해 어떤 것이 실제로 어떻게 작동하는지 이해하려고 할 것입니다 . 그러나 (3)을 참조하십시오. 테스트가 실패하지 않으면 문서를보고 이유를 이해하지 못합니다.

이 모든 것이 numpy가 더 math.isclose와 유사한 FP 근접성 테스트를 통해 "더 나을 것"이라는 결론에 이르게합니다.

왜 더 나은 문서가 좋은 아이디어지만 충분하지 않은지.

아마도 내가 완전히 틀렸을 수도 있고, 대부분의 사람들은 문서를주의 깊게 읽고 대부분의 시간 동안 문제에 대해 rtol과 atol을 신중하게 선택합니다.하지만 저는 알고 있습니다. 이러한 문제를 알고 있습니다.

: bikeshed : (이런, 작동하지 않았습니다. 멋진 이모티콘이 없습니다)

relatively_close 또는 rel_close ?

추가 "재미있는"주름 : assert_allclose는 실제로 atol = 0을 사용합니다.
기본. 우리가 고칠 수 있는지 토론하는 또 다른 전체 스레드가 있습니다.
그 불일치. (내 휴대폰에서 쉽게 찾을 수 없습니다.)

2017 년 12 월 11 일 14:58에 "Chris Barker" [email protected]이 작성했습니다.

@rgommers https://github.com/rgommers 작성 :
"" "
이미 여기에서 새 기능을 추가하는 가치 판단을 통과하고 있습니다.
새로운 기능이없는 것보다 낫습니다. imho가 아닙니다.
"" "
글쎄요, 저는 많은 시간을 생각하고 토론했습니다.
math.isclose, 그리고 numpy 구현부터 살펴 보았습니다.
다른 사람 중에서. 그렇습니다. 저는 그 접근 방식이 더 낫다고 생각합니다. 그리고 나는 생각했다
이 토론에서 그것은 꽤 많은 합의였습니다.

그리고 더 나은 알고리즘 / 인터페이스를 numpy로 가져 오면 더 좋습니다.

아마도 당신은 이전과 새, 더 나은 기능을 모두 가지고 있음을 의미합니다.
numpy는 단순히 오래된 것을 떠나는 것보다 낫지 않습니다 (아마도
문서화 됨) 기능. 물론, 그것은 완전히 유효한 포인트이지만
그 토론과 "소개
다른 기능과 약간 다른 동작 만있는 새로운 기능
10 년 동안 그렇게 작동 한 것은 일반적으로 매우 좋지 않은 생각입니다. "
토론을 종료하는 것처럼 보였습니다. 내 요점은 새로운 방법이
그만한 가치가있는 것보다 "충분하다". 우리가 분명히 가지고 있지 않은 것
합의는이 특정 옵션이 "충분히 더 나은지"입니다.
"더 나은"지 여부.

그건 그렇고, 저는 개인적으로 그것이 가치가 있다고 스스로 확신하지 못했습니다.
변경하지만 토론하고 싶습니다.

여기서 핵심은 제 부분에 대한 몇 가지 가정입니다. 우리가 할 수 있는지 모르겠어요
그들이 올바른지 확실히 알지만 :

1.

np.isclose ()의 가장 큰 사용은 테스트를위한 것입니다.
당신이 기대하는 것에 충분히 가깝습니까? -이것은 np.assert_all_close를 통해 이루어집니다.
더 직접적으로, pytest 테스트에서 또는 ....
2.

대부분의 경우 대부분의 사람들은 엄격한
답변이 얼마나 좋은지 결정하기위한 부동 소수점 오류 분석
예상됩니다. 오히려 값을 시도하고 실패하면
결과를 확인하고 실제로 오류인지 또는 조정해야 하는지를 결정합니다.
테스트의 허용 오차.

• 이것은 atol과
  rtol이 병합되고 테스트가 대칭인지 여부.

• 많은 사람들이 (2)에서 프로세스를 시작합니다.
  기본 공차, 테스트가 실패한 경우에만 공차를 조정하십시오.

• 이것은 기본 atol이 매우 위험하다는 것을 의미합니다.
  통과해서는 안되는 건 정말 나쁜 일입니다.

• 사람들은 문서를 읽지 않습니다 (초기 "내가 이것을 어떻게 부르는가"를 넘어서)
  단계)-적어도 혼란스러운 행동을 발견하기 전까지는
  문제를 해결하기 위해 실제로 어떻게 작동하는지 이해하려고
  혼란. 그러나 (3) 참조-테스트가 실패하지 않으면 그들은
  이유를 이해하려면 문서를 살펴보십시오.

이 모든 것이 나를 numpy가 "더 좋을"것이라는 결론에 이르게합니다.
더 많은 math.isclose-like FP 친밀 성 테스트.

왜 더 나은 문서가 좋은 아이디어지만 충분하지 않은지.

아마도 내가 완전히 틀렸을 수도 있고, 대부분의 사람들은 문서를주의 깊게 읽고
대부분의 경우 rtol과 atol을 신중하게 선택하십시오.
하지만 저나 제 팀원 6 명은 제가
이러한 문제를 알게되었습니다.

: bikeshed : (이런, 작동하지 않았습니다. 멋진 이모티콘이 없습니다)

아마도 relative_close 또는 rel_close?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/10161#issuecomment-350886540 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AAlOaNquy47fsOkvBlxcSa-Mxyhgdimlks5s_bORgaJpZM4Q2J-P
.

3183 호 말씀 이세요?

assert_allclose는 실제로 기본적으로 atol = 0을 사용합니다.

흥미 롭습니다. 기분이 좋아집니다.

이것은 둘 사이의 차이점에 대한 과거 토론의 흐릿한 기억을 되 살리고 있습니다.

안녕하세요,
내 thermo, fluids 및 ht 라이브러리는 numpy의 assert_allclose를 광범위하게 사용하므로 관련된 몇 가지 생각을 여기에서 공유하고 있습니다. 이 스레드는 동작 차이를 매우 놀라운 것처럼 보이게하며, 대칭 부족 및 / 또는 atol과 rtol 및 기본 atol (assert_allclose에는 없음 , 알아). 그래서 내 라이브러리에 버그가 있는지 확인하고 assert_allclose의 매우 조잡한 구현을 해킹 한 다음 테스트를 임시로 사용하도록 변경했습니다.

assert_allclose의 사용이 대표적이라고 생각합니다. 개별적으로 선택한 값을 비교하고 함수 결과에 대해 assert_allclose를 매개 변수로 호출하는 테스트를 수행합니다. 나는 모든 종류의 크기의 int와 float를 비교합니다. 나는 rtol 또는 atol을 선택하는 데 상대적으로 거의 고려하지 않았으며, atol을 추가하거나 rtol을 덜 엄격한 기본값으로 변경하는 경우는 거의 없습니다. 라이브러리는 assert_allclose를 각각 13159, 1178 및 4243 번 호출합니다.

그래서 변경을하고 테스트 테스트를 실행했습니다. 새로운 버그 나 테스트 실패를 찾지 못했다고 말하게되어 매우 기쁩니다. 내가 찾을 수있는 유일한 테스트 실패는 assert_allclose의 구현이었습니다.

운이 좋지 않은 다른 사람들이 있다는 것을 알고 있으며 assert_allclose 또는 isclose의 내용이 변경되면 문제가 발생합니다. 다른 함수를 통해서든 symmetric 플래그를 통해서든 math.allclose의 동작을 복제 한 assert_allclose 모드가 있다면 개인적으로 테스트를 작성하는 것이 더 편할 것입니다. 그러나 나는 그것이 누군가에게 할 일이 많고 아직 PR도 없었 음을 알고 있습니다. 비록 한 번이라도이 결함에 대해 내 코드를 확인할 수있어 기쁩니다!

4880은 제가 생각했던 것입니다.

2017 년 12 월 11 일 오후 5:01, Nathaniel J. Smith [email protected]
썼다 :

4880 https://github.com/numpy/numpy/pull/4880 은 제가 생각했던 것입니다.

의.

감사합니다. statsmodel 예제가
기본값 atol — 0.0 이외의 것은 위험합니다.

이것이 2 년마다 발생한다는 사실은 우리가
마침내 그것에 대해 뭔가를합니까?

아마도 그렇습니다. 작은 사마귀이지만 때로는 그 작은 성가심으로 인해
시간이 지남에 따라.

그리고 assert_allclose의 atol 기본값이 0이라는 것에 만족합니다.
(그렇지 않은 경우에도 허용 가능한 옵션이라는 점을 뒷받침합니다.
이것이 최선의 선택이라는 데 동의) 우리 중 많은 사람들이
unittest를 사용하므로 테스트에서 직접 np.all_close를 사용할 수 있습니다.

그리고 그래 Ralf, 우리가 변화를한다면, 우리는 세 가지 모두를 바꾸고 싶을 것입니다.
밀접하게 관련된 함수 :-(. 그러나 그것은 우리에게 그것들을 만들 수있는 기회를줍니다.
더 일관된 보너스?

py2-3 전환이 잘 진행되지는 않았지만해야 할 일이 있습니다.
어떤 시점에서 "사마귀를 정리하는 것은 괜찮습니다"버전을 가지고 있다고 말했다 :-)

실제로 is_close 를 atol=0 의 수학 버전으로 옮기는 다른 옵션이 있습니다. 기본값을 None 로 변경하고 atol=0 시도합니다 ; True 모두 반환하면; 일부 False 이면 표준 atol 다시 시도하고 결과가 변경되면 지원 중단 경고가 발생하고 "이전"결과가 반환됩니다.

슬프게도 대칭과 atol을 동시에 수행 할 수는 없습니다. 왜냐하면 서로 다른 방향으로 이동하기 때문입니다 (즉, 항상 두 경우를 모두 실행해야하는데, 약간 많이 보임). 그러나 나는 대칭이 부족한 것보다 atol 기본값을 훨씬 더 싫어합니다.

나는 어떤 기능도 변경하는 것을 선호하지 않는다.
이전 동작을 사용하여 사용할 수 있습니다. 또한
변경이 완료되면 자동 리팩토링 도구를 사용합니다. 그러나 그것은 아닙니다
지금은 탁자 위에도.

py3k 전환은 우리가 다시하고 싶은 것이 아닙니다.
역할 모델이 아닙니다. 정리를 하나의 큰 릴리스로 롤링하는 것은 좋지 않습니다.
IMO에 접근하십시오.

py2-3 전환이 잘 진행되지는 않았지만 "사마귀를 제거해도 괜찮습니다"버전이 언젠가는 있다고 할 수 있습니다. :-)

그냥 특별한 버전 번호 주요 변경 확인을 할 수있는이 일반적인 생각을 해결하기 : 일반적인 규칙이이 고통을 받아 들일 수없는 수준을 방지 명확한 전환 계획이고 장점이를 정당화하기에 충분한 경우, 사마귀을 정리 괜찮이다 소송 비용. 여기서 핵심은 우리가 "규칙을 따랐는지"가 아니라 사용자에게 미치는 영향에 따라 판단해야한다는 것입니다. (당신이 화려 해지기를 원한다면, 우리는 deontologists가 아니라 결과 주의자 입니다.) 따라서 특정 버전을 "이것은 물건을 깨뜨리는 것"이라고 선언하는 유일한 이유는 사용자가 일을 훨씬 더 쉽게 처리 할 수 ​​있도록 만드는 것입니다. IMO는 변경 사항을 함께 롤업하여 얻을 수있는 이점은 일반적으로 전혀 존재하지 않는 경우 (깨진 코드는 손상된 코드입니다.) 존재하더라도 비용 / 편익 분석을 "아니오"에서 "로 팁을주는 경우는 매우 드뭅니다. 예".

atol은 0이 아닙니다. 기본값입니다. 실제로 이것이 가장 큰 문제라고 생각합니다 (특히 현재 둘 다 추가하는 알고리즘의 경우). 안되는 테스트 통과로 쉽게 이어질 수 있기 때문입니다. lazy-기본 허용 오차로 테스트를 작성합니다. 통과하면 완료되었다고 생각합니다. (내가 그것이 작동하는 방법이라는 것을 깨달았을 때, 나는 y 코드로 돌아가서 그 중 몇 개를 찾았습니다-웁스!

statsmodel 예제는 atol의 기본값에 대해 잘 설명합니다. 0.0이 아닌 것은 위험합니다. [...] 우리 중 많은 사람들과 더 많은 사람들이 unittest를 사용하지 않기 때문에 테스트에서 직접 np.all_close를 사용할 수 있습니다.

"다른 패키지와의 일관성을 높이기 위해 사용자 코드를 깨야합니다."는 비용 / 이익 척도에서 그다지 좋은 점수를받지 못합니다. "Numpy 내부에는 혼란 스러울뿐만 아니라 사용자 코드에서 조용한 버그로 직접 연결되는 방식으로 혼란스러운 불일치가 있으며,이를 수정할 수 있습니다."가 훨씬 더 매력적입니다. 나는 아직 스스로 의견을 정하지 않았지만 여기서 진전을 얻고 싶다면 이것이 내가 추진할 것입니다.

공책:

“””나는 rtol 또는 atol을 선택하는 데 상대적으로 거의 고려하지 않았습니다.
아톨을 거의 추가하지 않음
-한조각-

$는 assert_allclose를 각각 13159, 1178, 4243 번 호출합니다.

-한조각-

새로운 버그 나 테스트 실패를 찾지 못했습니다 .

"" "

좋은 소식이지만 assert_allclose의 atol 기본값은 0입니다. 과
이는 이유 :-)

@njsmith 는 다음

"다른 패키지와의 일관성을 높이기 위해 사용자 코드를 깨야합니다."

나는이 스레드의 누구도 그것을 옹호하지 않는다고 생각합니다. – 나는 확실하지 않습니다. 누구나 옹호하는 유일한 일관성은 관련된 numpy 함수 간의 일관성입니다.

"Numpy 내부에는 혼란 스러울뿐만 아니라 사용자 코드에서 조용한 버그로 직접 이어지는 방식으로 혼란스러운 불일치가 있으며,이를 수정할 수 있습니다."

그것이 내가 적어도 옹호하는 것입니다. 그리고 나는 대부분의 다른 사람들을 생각합니다.

문제는 다음 중 하나없이 해결할 수 없다는 것입니다.

이전 버전과의 호환성을 깨뜨리는 것입니다. 이는 지원 중단주기에도 불구하고 이것이 충분히 심각하다고 생각하지 않습니다.

또는

새 플래그 또는 함수 만들기.

새로운 기능이 더 깨끗한 방법이라고 생각합니다. 이전 코드는 원하는만큼 변경되지 않고 새 코드가 새 기능을 사용할 수 있으며 검색 및 바꾸기 (또는 호출로 몇 번 가져 오기)를 통해 한 번에 하나의 파일을 쉽게 전환 할 수 있습니다.

(나는 당신이 테스트 코드에서 원숭이 패치 numpy조차 할 수 있다고 생각합니다 ....)

우리는 이미 가지고 있습니다 :

• allclose
• assert_allclose
• assert_almost_equal
• assert_approx_equal
• assert_array_almost_equal
• assert_array_almost_equal_nulp
• assert_array_max_ulp

이 목록에 더 많은 옵션을 추가하는 것이 실제로 실제 사용자에게 큰 차이를 만들 것이라고 생각하지 않습니다.

글쎄, 나는 math.isclose에 대해 생각하고 토론하는 데 많은 시간을 보냈고, 우리는 다른 것들 중에서 numpy 구현을 살펴 보는 것으로 시작했습니다. 그렇습니다. 저는 그 접근 방식이 더 낫다고 생각합니다.

저도 그랬고 저는 numpy.testing 의 메인 메인테이너 중 하나였습니다. 이것은 거의 새로운 문제가 아닙니다. 대문자로 당신이 옳다고 주장하는 것은 그렇게되지 않습니다.

아마도 numpy에서 이전 기능과 새 기능을 모두 갖는 것이 단순히 이전 (아마 더 잘 문서화 된) 기능을 그대로 두는 것보다 낫지 않다는 것을 의미합니다. 물론, 그것은 완전히 타당한 요점이지만 저는 그 논의를하지 않으려 고 노력했습니다.

사실, 그것이 내가 의미하는 바가 분명해야합니다.

"10 년 동안 그렇게 작동해온 다른 기능과 약간 다른 동작을 가진 새로운 기능을 도입하는 것은 일반적으로 매우 좋지 않은 생각입니다."

아니요, 너무 자주 무시되거나 충분한 가중치가 부여되지 않은 새로운 기능을 추가하는 데있어 실제 문제를 지적합니다. 이 경우에는 많은 핵심 개발자들에게 분명해 보입니다.이 배가 @njsmith , @pv , @charris 및 저에게서 항해했다는 판단을 내리는 것 같습니다.

나는 이것을 다시 해싱하는 것에 대해 미리 사과하지만 assert_allclose 은 올바른 행동입니다 (또는 적어도 그것에 가깝습니다). 그러나 isclose 는 다른 사람들이 지적한 것처럼 절대적인 관용을 가정하기 때문에 사람들을 문제에 빠뜨릴 수 있습니다. 이 행동에 대해 사람들에게 경고하기 위해 np.isclose 문서 페이지에 큰 빨간색 상자를 넣는 PR 제출을 고려 중입니다. 어떻게 들리나요?

다시 해싱 한 것에 대해 미리 사과 드리지만 assert_allclose 는
올바른 행동 (또는 적어도 그것에 가깝게). 그러나 isclose는
다른 사람들처럼 절대적인 관용을 가정하기 때문에
유명한. 큰 빨간 상자를 올려 놓기 위해 PR 제출을 고려하고 있습니다.
이 동작에 대해 사람들에게 경고하는 np.isclose 문서 페이지. 어떻게
그 소리?

+1

나는 문서가 더 나아야한다는 합의가있다.

감사,

-CHB

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/10161#issuecomment-351182296 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AA38YDw4sdhRWYmeeyr4met1RCwWsjMQks5s_uBmgaJpZM4Q2J-P
.

문서 개선을지지하지만 제안 된 변경 사항이 도움이되지 않는다고 생각합니다.

.. 경고 :: 기본 atol 은
1보다 훨씬 적습니다.

첫째,이 경고는 일반적으로 사실이 아닙니다. 1e-8 보다 작은 숫자를 0으로 처리하려는 경우 기본 atol _is_가 적합합니다. 이것은 상대 공차로는 불가능하므로 절대 공차가 존재합니다. 반대로, 1e-8 보다 작은 숫자를 의미있는 것으로 취급하려는 경우 기본 atol _는 적절하지 않습니다 _. 하나의 크기가 모든 것에 적합하다고 가정하지 마십시오.

따라서 @xoviat 는 가장 깊은 존경심을 가지고 귀하의 주관적인 진술에 강력히 반대합니다.

... assert_allclose _is_ 올바른 동작입니다 (또는 적어도 이에 가깝습니다).

현재 문서의 문제점은 _what_ atol 을 (를) 설명하는 것은 매우 훌륭하지만 _why_는 설명하지 않아서 사용자가 기본값을 변경해야하는시기를 이해하지 못할 수 있다는 것입니다. .

나는 다음과 같은 내용을 제안합니다.

" atol 의 0이 아닌 작은 값을 설정하면 0에 매우 가까운 숫자를 사실상 0과 동일하게 처리 할 수 ​​있습니다. 따라서 atol 의 기본값은 사용하기에 적합하지 않을 수 있습니다. 경우. 선택 atol 보다 큰 수 있도록 atol 의미있는 (제로 구별)로 고려하고,보다 작은 숫자 atol 당신이 무시할 수로 간주됩니다 (0과 동일). "

마지막으로 isclose 및 allclose 의 독 스트링에 동일한 메모를 추가합니다.

이것은 제 제안입니다. 받던가 말던가.
건배.

PR에 대한 리뷰 피드백을 남겨주세요. 특히 귀하의 제안은 너무 장황한 IMO입니다.

내가 너무 짜증 나면 미안합니다. 아직 합의가 없다고 생각했습니다.

@xoviat : 문서 작업에 감사드립니다.

이것이 다시 나올 것이기 때문에, 나는 거절하도록 설계된 NEP의 미니 버전으로이 토론을 끝내려고합니다 .- 제안과 거절 이유를 요약합니다. 기록을 위해-이전 문제가 약간 사라졌기 때문에.

py2 / 3 문제를 제기하여 죄송합니다-numpy에서 사마귀를 정리할지 여부는 다른 장소와 시간에 대한 토론입니다.

isclose()

이 문제 (및 기타 참조)는 numpy.isclose() 및 친구들이 최적이 아닌 알고리즘을 사용하고 atol에 대해 논쟁의 여지가있는 기본값을 가지고 있으며 다양한 관련 함수의 기본값이 서로 다르다는 관찰 결과입니다. 이로 인해 전체적으로 사용자에게 혼란이 생기고 최악의 경우 사용자가 atol 값 설정에 대해 생각하지 않는 경우 오 탐지 테스트가 발생합니다.

특히 stdlib : math.isclose() 의 구현은 더 나은 알고리즘과 기본값을 제공합니다. 대칭 테스트이고 rtol과 atol을 혼합하지 않으며 기본 atol은 0.0입니다.

상황이 이상적이지 않다는 데는 거의 합의가 이루어졌지만 이에 대해 무엇이든 할만큼 나쁘다는 합의는 없습니다.

고려되는 옵션 :

알고리즘 및 / 또는 기본값 변경 :

지원 중단 기간과 경고가 있더라도 이전 버전과의 호환성 문제로 인해 일반적으로 거부되었습니다. 이러한 기능은 테스트에서 널리 사용되므로 최소한 큰 성가 시게됩니다.

다른 알고리즘을 선택하기 위해 플래그가있는 추가 매개 변수 추가

이것은 기존 코드를 깨뜨리지 않지만 추악하고 혼란스러운 API로 영원히 지속됩니다.

__future__-유형 지시문 추가

TLDR : 가능하지만 쉽거나 깨끗하지는 않습니다. 아무도 이것을 추구하고 싶지 않은 것 같았습니다.

또 다른 기능 만들기

이 옵션은 관심을 끌 수있는 유일한 옵션으로 보였지만 토론에 참여한 핵심 개발자는 지원하지 않았습니다.

이것을 "수정"하는 가장 깨끗한 방법은 math.isclose 에서 사용 된 것과 같은 새로운 알고리즘과 기본값으로 np.rel_close() [또는 다른 이름]을 추가하는 것입니다. 새로운 기능은 향후 코드에 사용할 "권장"기능으로 문서화됩니다. 향후 이전 버전에 지원 중단 경고를 추가하는 것이 가능할 것입니다.하지만이 시점에서 그만한 가치가 있다고 생각하는 사람은 아무도 없었습니다.

리팩토링 도구를 구축하여 대체 할 수 있습니다.하지만 이번 한 번에 누가 그렇게할까요?

이로 인해 가까운 미래에 두 개의 매우 유사한 기능이 생성 될 것입니다. "10 년 동안 그렇게 작동 한 다른 기능과 약간 다른 동작을 가진 새로운 기능을 도입하는 것은 일반적으로 매우 좋지 않은 생각입니다."

결론:

작은 이득으로는 가치가 없지만 더 나은 문서가 정리되어 있으며 여기에서 수행됩니다. # 10214

아직 한 가지 질문이 남아 있습니다.

@njsmith 는 다음

"" "
우리는 이미 가지고 있습니다 :

assert_allclose
assert_almost_equal
assert_approx_equal
assert_array_almost_equal
assert_array_almost_equal_nulp
assert_array_max_ulp

이 목록에 더 많은 옵션을 추가하는 것이 실제로 실제 사용자에게 큰 차이를 만들 것이라고 생각하지 않습니다.
"" "

새로운 것을 추가하는 것이 괜찮은 아이디어라는 뜻입니까?

또한 다음 사항을 참고하십시오.

이들 대부분은 단언이며 단언의 확산은 단위 테스트 아키텍처의 부작용입니다.

우리 중 많은 사람들이 다른 테스트 아키텍처 (예 : pytest)로 이동함에 따라 어설 션의 필요성이 사라집니다.

따라서 numpy.testing 로 무엇을 할 것인가는 numpy 코어로 무엇을 할 것인가와는 별개의 질문입니다.

우리 중 많은 사람들이 다른 테스트 아키텍처 (예 : pytest)로 이동함에 따라 어설 션의 필요성이 사라집니다.

사실 이것은 그 자체로 위험합니다. 테스트는 assert_allclose(...) 에서 assert np.allclose(...) 로 변경 될 수 있으며 조용히 덜 엄격 해집니다. 이는 나쁜 일입니다.

유용한 실패 메시지를 제공하기 때문에 여전히 pytest 환경에서 assert_allclose 을 사용합니다.

    def test_shs():
        a = [0.1, 0.2, 0.3, 0.4]
        b = [0.2, 0.3, 0.3, 0.4]

>       np.testing.assert_allclose(a,b)
E       AssertionError: 
E       Not equal to tolerance rtol=1e-07, atol=0
E       
E       (mismatch 50.0%)
E        x: array([ 0.1,  0.2,  0.3,  0.4])
E        y: array([ 0.2,  0.3,  0.3,  0.4])

assert np.allclose() 사용 대비

    def test_shs():
        a = [0.1, 0.2, 0.3, 0.4]
        b = [0.2, 0.3, 0.3, 0.4]
>       assert np.allclose(a, b)
E       assert False
E        +  where False = <function allclose at 0x7f20b13c9840>([0.1, 0.2, 0.3, 0.4], [0.2, 0.3, 0.3, 0.4])
E        +    where <function allclose at 0x7f20b13c9840> = np.allclose

pytest_assertrepr_compare 구현하여 문제를 해결할 수 있지만 함수 호출에 적용하는 방법을 잘 모르겠고 pytest가 호출하는 위치를 파악할 수 없습니다.

@ eric-wieser : 작성 :

"실제로 이것은 그 자체로 위험합니다. 테스트는 assert_allclose (...)에서 np.allclose (...)를 주장하도록 변경 될 수 있으며 조용히 덜 엄격 해집니다. 이것은 나쁜 일입니다."

내 요점은 모든 사람이 어설 션을 테스트에 사용할 것이라고 가정하는 것은 "나쁜 아이디어"이므로 isclose () 및 allclose ()의 기본값이 테스트에 적합한 지 여부에 대해 신경 쓰지 않는 것이 이상적입니다. 확실히해야합니다.

새로운 것을 추가하는 것이 괜찮은 아이디어라는 뜻입니까?

아니요, 거의 동일한 테스트를 표현하는 약간 다른 방법을 이미 가지고 있다는 점을 감안할 때 불행히도 대부분의 사용자는 아직 다른 추가 사항을 알아 차 리거나 이해하지 못할 것입니다.

또한 다음 사항을 참고하십시오.
이들 대부분은 단언이며 단언의 확산은 단위 테스트 아키텍처의 부작용입니다.
우리 중 많은 사람들이 다른 테스트 아키텍처 (예 : pytest)로 이동함에 따라 어설 션의 필요성이 사라집니다.

그것들은 어설 션으로 작성되지만 AFAICT는 모든 함수가 실제로 "거의 같음"이라는 다른 정의를 인코딩합니다. (나는 생각한다. 일부 구별이 너무 모호해서 그것이 진짜인지 아닌지 말할 수 없다.)

알고리즘 및 / 또는 기본값 변경 :
지원 중단 기간과 경고가 있더라도 이전 버전과의 호환성 문제로 인해 일반적으로 거부되었습니다. 이러한 기능은 테스트에서 널리 사용되므로 최소한 큰 성가 시게됩니다.

나는 확실히 그런 넣어하지 않을 것입니다. 저에게는 이것이 비용을 정당화하기에 충분한 이점을 잠재적으로 가질 수있는 유일한 접근 방식입니다. 나는 그들이 그렇게 할

예를 들어, 누군가 나타나서 "내가 제안한 변경 사항을 3 개의 큰 프로젝트에 시도했는데, 그 결과 10,000 개의 테스트 중 12 개의 추가 실패가 발생했으며 그 중 12 개 중 8 개는 이전에 숨겨져 있던 실제 조용한 버그였습니다. 나쁜 기본값 "... 꽤 설득력이 있습니다. 특히 이것은 우리가 좁은 범위의 경고를 할 수있는 기술적 능력이있는 경우이기 때문입니다. 나는 실제 수치가 그렇게 호의적이지 않을 것이라고 생각하지만 누군가가 확인하기 전까지는 누가 알 수 있습니다.

2017 년 12 월 18 일 월요일 오후 3:57, Nathaniel J. Smith <
[email protected]> 작성 :

아니, 우리가 이미
불행히도 거의 동일한 테스트를 표현하는 약간 다른 방법
대부분의 사용자는 또 다른 추가 사항을 알아 차 리거나 이해하지 못할 것입니다.

음, 한 가지 큰 차이점이 있습니다.
뭔가 다르고 부동 소수점의 변동으로
차이가 중요 할 수 있습니다.

새로운 상대적 근접성 함수는 본질적으로 동일한 작업을 수행하지만
좀 더 잘 해봐". 목표는 새로운 것을 사용하도록 권장하는 것입니다.
오래된 것 대신에 (그리고 결국 오래된 것을 비난 할 수도 있습니다).

솔직히 그게 아이디어에 대한 논쟁인지, 반대인지는 잘 모르겠습니다.
그러나.

예를 들어 누군가 나타나서 "제 제안한 변경 사항을 3 대

10,000 개의 테스트 중 12 개의 추가 실패가 발생했습니다.
12, 8 개는 오래된 악당에 의해 숨겨져 있던 실제 조용한 버그였습니다.
기본값 "... 꽤 설득력이 있습니다. 특히 이것은
좁은 범위의 경고를 할 수있는 기술적 능력이있는 경우.
실제 수치는 그리 호의적이지 않을 것 같지만
누가 알고 있는지 확인합니다.

흠, 내 코드 기반에는 10,000 개가 아닌 약 1500 개의 테스트가 있습니다.
사격. 다른 것이 없다면 버그 또는 불량한 테스트를 찾을 수 있습니다. 또는 더 많은 것을 얻으십시오
안심!

모두 안녕,

동료가이 문제에 직면 한 후 여기에 차임하고 싶었습니다.

_ 면책 조항 : "화장실에서 불"을 외치고 울타리 너머로 던지기 전에는 논리에 대해 많이 생각하지 않았습니다. 부끄러운 해시를 만들었 으면 친절 해주세요.

나에게이 모든 것은 고전적인 아키텍처 / 디자인 "치킨 앤 에그"문제-의미론 대 구현과 매우 비슷하게 들립니다. 모든 버그가 코드 내에 존재하는 것은 아니며 때로는 의미 체계 내에 존재합니다. 이것은 알고리즘에 결함이 있음을 발견하기 위해서만 완벽하게 구현되는 알고리즘과 크게 다르지 않습니다. 버그는 코드에 있지 않고 알고리즘에 있지만 어느 쪽이든 여전히 버그입니다. 기본적으로이 토론은 "버그가 아니라 기능"이라는 고전적인 농담처럼 들립니다. 물론, "선택"은 그저 그렇습니다. 그러나 IMHO는 일반적으로 이론적 근거의 끝을 나타냅니다. 의미론이 구현 된 그대로 선택되면 구현은 모두 멋지고 토론의 끝입니다.

그래서 isclose() 의 "원하는"및 / 또는 "예상 된"시맨틱은 무엇입니까? 이것을 생각하면, 나는 사용자가 정의하는 시맨틱에 수렴하게 남습니다. 즉, 사용자가 시맨틱을 정의 할 수 있어야합니다. "닫기"의 정의.

기본값

기본값과 관련하여 이것은 궁극적으로 의미 체계를 깨지 않습니다. 그러나 잘못된 선택은 위험합니다. 0이 아닌 기본값이 abs(a - b) == 0 때 합리적인 동작을 제공하기 위해 _only_ 선택 되었다면 이것은 확실히 잘못된 해결책처럼 들립니다. 이 특정 상태는 의미 상 특수 케이스이므로 특수 케이스가 더 나을 것입니다. diff가 0 일 때 "close"의 정의에는 "wiggle room"이 없습니다. 자체 정의하는 코너 스톤입니다. 즉, _close_가 아니라 _exact_입니다. 여기서 "close"는 정확한 값과의 상대적인 편차입니다. . (_ 참고 : _ 특수 케이스 조건은 성능에 영향을 줄 수도 있고 그렇지 않을 수도 있습니다.)

+ 대 max

max _does_가 아닌 합계를 사용하는 구현으로 인해 rel_tol 및 a_tol 의 혼합 또는 "그림자"는 위의 함수 의미를 손상시킵니다. "close"에 대한 사용자의 정의는 "relative"와 "absolute"의 의미를 엉망으로 만들 므로 사소하지 않은 방식으로 묶여 있습니다. 위의 의미 만 고려하면이 측면은 _is_ 버그입니다. 예를 들어 설명 합니다.

교환 성 (즉, 대칭)

여기 두 사업자 정말 있습니다 - 에서 a-b 및 <= 에서 |a-b| <= f(a, b, atol, rtol) . 뺄셈은 역 교환 적이지만 |a - b| 은 그렇지 않지만 정의에 따라 교환 적입니다. 그러나 이것만으로는 f(a, b, atol, rtol) 의 교환을 표현하기에 충분하지 않을 수 있습니다. 그러나 여기에는 강력하고 약한 논쟁이 있습니다.

• 기능 분리의 캡슐화 또는 부족 - - 약한은 간단한되는 arithemtically 교환 법칙 동안 |a - b| 의 집행하지 않을 수 있습니다 f(a, b, atol, rtol) 프로그래밍, f(a, b, atol, rtol) 정말 아닙니다을 질문이지만 isClose(a, b, atol, rtol) . 여기서 |a - b| 계산은 isClose() := |a-b| <= f(a, b, atol, rtol) 함수에 대해 내부적으로 수행됩니다. 이것은 내부이고 a 및 b 가 전달되기 때문에 |a-b| 가 교환 형이 되려면 isClose() 있어야합니다. 그렇지 않은 경우 |a-b| 의 commutativity는 모든 의미를 잃습니다.
• 강력한 인수 : 비교 작업은 엄격하지 않습니다. 즉, <= 아니라 < 이므로 비교의 동등 부분에 대해 |a-b| = f(a, b, atol, rtol) 를 의미하는 f(a, b, atol, rtol) _must_ 역시 교환 적이어야합니다 (내 생각에는?). 그렇지 않다는 것은 위의 평등이 _never_ true (이를 충족하는 a & b 이 없음)이거나 완전 불평등 인 < 가 실제로 의미 론적으로 정의 되었죠?

이것의 전부 또는 일부에 대해 당신이하는 (또는하지 않는) 것은 완전히 별개의 질문입니다.