Numpy: clang-compiled np.float32 .__ mul__에 의한 무의미한 RuntimeWarning

numpy.float32('1.5').__mul__(x) 및 __add__ 및 __sub__ 와 동일한 사진.

이 유형의 오류는 nan 또는 infinity 를 포함하는 일반적인 배열입니다. np.array(x) 는 무엇을 반환합니까?

@ eric-wieser : 경고없이 array(x, dtype=object) 반환합니다.

np.multiply(np.float32('1.5'), x) 동일한 경고를 표시합니까?

numpy.multiply(numpy.float32('1.5'), x) 는 동일한 경고를 제공합니다.

type(x).__rmul__(numpy.float32('1.5'), x) 어떻습니까?

또한 warnings.filterwarnings('error') 를 실행할 수 있다면 전체 스택 추적을 얻을 수 있습니다.

type(x).__rmul__(numpy.float32('1.5'), x)

TypeError: descriptor '__rmul__' requires a 'sage.structure.element.Element' object but received a 'numpy.float32'

x.__rmul__(numpy.float32('1.5')) 잘 통과합니다.

rmul 작동 방식을 잊은 것 같습니다. 나는 type(x).__rmul__(x, numpy.float32('1.5')) 의미했지만 x 이 정말 이상하지 않다면 x.__rmul__ 과 똑같은 일을한다고 생각합니다.

이것도 실패합니까? np.multiply(np.array(1.5, dtype=object), x) (이번에는 filterwarnings 와 함께하세요)

type(x).__rmul__(x,numpy.float32('1.5')) 은 (는) 경고없이 진행됩니다.

그런데 warnings.filterwarnings('error') 설정해도 흥미로운 것은 없습니다.

RuntimeWarning                            Traceback (most recent call last)
<ipython-input-50-b3ece847d318> in <module>()

sage: np.multiply(np.array(1.5, dtype=object), x)
---------------------------------------------------------------------------
RuntimeWarning                            Traceback (most recent call last)
<ipython-input-52-706823a0b5a2> in <module>()
----> 1  np.multiply(np.array(RealNumber('1.5'), dtype=object), x)

RuntimeWarning: invalid value encountered in multiply

흠, 세이지는 내가 거기에서 예상하지 못한 일을했다. 그래도 float('1.5') 와 같은 동작 이겠죠?

좋아, 내가 생각하는 일은 다음과 같다.

• numpy 는 ufunc에서 개체 루프를 올바르게 사용하고 있으며 PyNumber_Multiply 만 호출합니다.
• sage 에서 무언가가 FPU에서 오류 플래그를 설정하고 있습니다 (현자 버그?).
• numpy 는 ufunc (객체 루프의 버그?)를 종료 할 때 정상적인 fpu 플래그 검사를 수행하고 sage 가 남긴 오류를 찾습니다.

sage: float(1.5).__mul__(x)
NotImplemented
sage: np.float(1.5).__mul__(x)
NotImplemented
sage: np.float32(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float64(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

호환성 이유로 np.float is float 에 주목할 가치가 있습니다.

np.float32(1.5).__mul__(x) NotImplemented 반환하지 않는 이유는 무엇입니까?

객체 루프를 사용하여 np.multiply 로 처리 할 수 ​​있다는 것을 알고 있으므로 해당 루프 내에서 float * x 다시 시도합니다. 불행히도 해당 루프를 둘러싼 래퍼는 sage가 설정 한 FPU 플래그를 선택합니다.

자세히 살펴보면 x.__rmul__ 가 여전히 스택에서 더 깊게 호출되고 있음을 알 수 있습니다.

sage: np.float32(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float128(1.5)*x
1.50000000000000*x
sage: np.float64(1.5)*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

np.float128 가 괜찮은 것처럼 보이지만

sage: np.float128(1.5).__mul__(x)
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x

이것은 이상합니다. 컴파일러 버그, 아마도 (우리가 gcc에서 결코 볼 수 없기 때문에), 그러나 어느 곳에서?

FPU 플래그는 어떤 이유로 clang에 설정되어 있지만 세이지 코드 내에서는 gcc가 아닌 것 같습니다. Numpy는 그것에 대해 소음을내는 책임이 있지만 처음에 그것을 설정 한 책임은 매우 의심 스럽습니다.

불행히도 numpy 는 FPU 플래그를 명시 적으로 요청할 수있는 방법을 제공하지 않습니다. 이는 현자 내에서 문제를 양분하는 데 매우 유용합니다.

나는 이것이 동일한 경고를 유발한다고 가정합니다 (그렇게하려면 1.12가 필요하다고 생각합니다)

mul = np.vectorize(x.__rmul__)
mul(float('1.5'))

똑같지는 않지만 가깝습니다.

/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/numpy/lib/function_base.py:2652: RuntimeWarning: invalid value encountered in __rmul__ (vectorized)
  outputs = ufunc(*inputs)
array(1.50000000000000*x, dtype=object)

좋아요, 이것은 np.float32 또는 np.float64 특별한 것이 없음을 나타내는 것 같습니다. 여기에서 경고를 생성하는 더 일반적인 numpy 메커니즘입니다.

컴파일러 작성자가 버그로 간주할지 모르겠습니다. 경고가 작동하는 방식은 프로세서가 추적하는 일부 매직 상태 플래그가 있으며 해당 이벤트가 발생할 때마다 자동으로 설정됩니다. Numpy는 계산을 시작하기 전에이를 지우고 마지막에 다시 확인합니다. 따라서 이러한 지점 사이 어딘가에서 clang에 의해 생성 된 어셈블리는 NaN을 포함하는 계산을 수행합니다. 그러나 추적하기가 어렵고 (실제 플래그 설정은 전적으로 하드웨어에서 수행되기 때문에) 대부분의 경우 사람들은 코드가 fpu 플래그에 어떻게 영향을 미치는지 걱정하지 않습니다. (Libm 구현은 이러한 플래그를 설정했는지 여부에 대해서도 일관 적이 지 않은 것으로 악명이 높습니다.) 정확한 결과는 생성되는 정확한 asm에 따라 크게 달라 지므로 다른 구성이 아닌 특정 구성에서만 볼 수 있다는 것은 놀라운 일이 아닙니다.

네, 내 의심을 확인하고 디버깅 방법을 제공합니다. 이 코드

def check_fpu(f):
    @functools.wraps(f)
    def wrapped(*args, **kwargs):
        excluded = list(range(len(args))) + list(kwargs.keys())
        fvec = np.vectorize(f, excluded=excluded)
        return fvec(*args, **kwargs)
    return wrapped

Python 함수에 적용되어 해당 코드 청크 내에서 경고를 분리 할 수 ​​있습니다.

제 말은, 그것이 전혀 일어나고 있다는 것은 꽤 이상합니다. 컴파일러는 보통 아무 이유없이 NaN을 발명 한 다음 버리지 않습니다.

당신이 그것을 추적하려고한다면, 아마도 그 다항식에 대한 곱셈을 구현하는 현명한 코드를 봐야 할 것입니다. 이상한 플래그 설정이 항상 일어나고있을 가능성이 높습니다. .

또한 numpy가 객체 루프에서 이러한 플래그를 확인하려고 시도하지 않아야한다는 꽤 좋은 주장이 있습니다. (또는 그 문제에 대한 정수 루프이지만, 정수 오버플로를보고하는 방식은 다소 복잡하고 fpu 플래그를 사용하기 때문에 까다 롭습니다.) numpy가 여기서 할 수있는 유일한 작업입니다.

check_fpu() 에 오타가 있습니다. fvec = np.vectorize(f, excluded=exclude) 이어야합니다.
그리고 우리는 python2 : import functools32 as functools 있습니다.

functools.wraps 에는 파이썬 3이 필요하지 않습니까?

setattr() 호출에서 python2의 functools를 사용하면 오류가 발생합니다.

AttributeError: 'method-wrapper' object has no attribute '__module__'

예, FPU 플래그를 설정하는 것은 RealField 의 계수에 대한 산술을 구현하는 다 정밀도 라이브러리라고 생각합니다. 각기 다른 상황에서 기본 라이브러리가 numpy와 동일한 컴파일러로 컴파일됩니까? 아니면 numpy 만 다른 컴파일러로 다시 빌드되고 있습니까?

예, RealField의 계수에 대한 산술을 구현하는 다 정밀 라이브러리라고 생각합니다.

그것은 기록을위한 MPFR입니다.

우리는 Sagemath를 clang + gfortran (주로 clang이 기본 컴파일러 인 플랫폼 인 OSX 및 FreeBSD에서)으로 포팅하여 OSX에서 빌드하고 실행하는 것이 더 쉽고 빠릅니다 (FreeBSD는 OSX 및 Apple 하드웨어의 번거 로움).

여기에보고하는 모든 비교는 gcc / g +++ gfortran이 아닌 clang / clang +++ gfortran을 사용한 전체 빌드에 대한 것입니다.

래퍼는 x.__rmul__ 가 FPU 플래그를 설정한다고 알려주는 것 같습니다.

check_fpu(x.__rmul__)(np.float32('1.5'))

경고를 인쇄하지만 x.__rmul__(np.float32('1.5')) 는 인쇄하지 않습니다.

실제로-내 가정은 x.__rmul__ 가 파이썬으로 작성되었으며 소스 코드를 양분하여 플래그를 구체적으로 설정하는 비트를 찾을 수 있다고 가정했습니다.

x.__rmul__ 은 (는) Cython에 있지만 여전히 조사해야 할 작은 코드입니다.

경고를 오류로 변경하는 간단한 방법이 있으면 트레이스 백을 얻을 수 있습니다 (Cython은 오류에 대한 트레이스 백을 생성하지만 경고에 대해서는 생성하지 않음).

@jdemeyer IMHO numpy 경고는 코드 경로에서 훨씬 나중에 발행됩니다. 즉, 인터럽트 세트가 아닌 FPU 플래그를 명시 적으로 확인한 결과입니다.

numpy는이 경고를 오류로 변경할 수있는 인터페이스를 제공하지만, 역 추적없이 기본 iPython 인터프리터 루프로 돌아가는 것뿐입니다.

@jdemeyer 는 FPU 플래그가 발생하면 cysignals의 sig_on() / sig_off() 사이의 Cython 코드에서 예외가 발생합니까? 아니면 깃발에 달려 있습니까?

cysignals는 SIGFPE 가 발생하면 FPU 구성에 따라 FPU 플래그가 발생하면 예외가 발생할 수 있습니다. 그러나 기본적으로 그렇지 않습니다.

유사한 경고 : RuntimeWarning: invalid value encountered in greater
np.float64(5)>e 에서옵니다. 여기서 e 는 자연 로그 2.71828 ...의 밑을 지정하는 Sagemath 상수입니다. 따라서 이것을 True 로 평가하려면 "변환"해야합니다 (확실히 e "알고 "그것의 수치 근사, 그것은 숫자에 대한 e.n() )입니다.
이 근사치는 위에서 이미 언급 한 RealField 유형입니다 (따라서이 경고는 밀접한 관련이 있습니다).

다시 한 번 질문은 numpy 가 np.float64(5)>e 를 평가하기 위해 무엇을합니까?
또는 동일하게 np.float64(5).__gt__(e) 에서 동일한 경고가 표시되므로 거기에서 시작할 수도 있습니다.

type(e) 는 sage.symbolic.constants_c.E . 기본적으로 (거의) 더미 클래스입니다.
Sagemath의 기호 표현식 ( SR ) 래핑.

np.float64(5).__gt__(e.n()) 또는 np.float64(5)>e.n() 경고가 없습니다.
e 를 pi (명백한 pi.n()==3.1.415... )로 바꾸면 본질적으로 동일한 (같은 경고 / 경고 패턴 없음)이 발생합니다.
pi 유형은 SR , 즉 sage.symbolic.expression.Expression 입니다.

대답은 여기에서 동일합니다-numpy는 객체 루프로 np.greater 를 호출합니다. 하단 수준에서 e.__lt__(5.0) 를 호출합니다. 그러나 다시 한 번 이전과 이후의 FPU 플래그를 확인하고 무언가 잘못되었음을 알 수 있습니다.

대부분의 ndarray 산술 / 논리 연산자 ( - 및 divmod 제외)는 ufuncs에 위임합니다. sage 객체와 함께 호출되면 이러한 ufuncs에 대해 O (객체) 루프를 호출합니다. 이러한 객체 루프는 배열 (이 경우 0d)을 반복하고 요소에서 일반 파이썬 연산자를 실행하고 _하지만 그렇게 할 때 FPU 플래그를 확인합니다 _.

다시 한 번 세이지가이 플래그를 설정하고 있습니다. 아마도 이것은 버그의 징후 일 수도 있고 아닐 수도 있습니다.

numpy가 이러한 경우에 fpu 플래그를 확인하지 않아야한다는 좋은 주장이 있다고 생각합니다. @njsmith , 객체 유형 검사를 제거해야한다고 생각하십니까?

사실 e.__lt__(5.0) 는 기호 표현식입니다.

sage: type(e.__lt__(np.float32(5.0)))
<type 'sage.symbolic.expression.Expression'>
sage: e.__lt__(np.float32(5.0))
e < 5.0
sage: bool(e.__lt__(np.float32(5.0)))  # this is how it's evaluated
True

그래서 나는 그것이 True 얻었 기 때문에 결국 그것이 호출되었는지 정말로 의심합니다. 또한 위의 check_fpu 래퍼는 경고를 인쇄하지 않습니다. 즉, 다음이 작동합니다.

sage: check_fpu(e.__lt__)(np.float32(5.0))
e < 5.0

나는 Sagemath의 문제를 fpectl Python 모듈을 사용하여 특정 C 확장에 고정 할 수있었습니다. 실제로 설치가 완료되면 매우 빨랐습니다.

IMHO fpectl은 매우 유용하여 수정 해야합니다. 아마도 np.seterr() 대신 또는 추가로 numpy에서 사용되었을 수도 있습니다. 컴파일 된 구성 요소에 대해 더 나은 세분성을 제공하기 때문입니다.

fpectl의 접근 방식과 np.seterr의 차이점은 다음과 같습니다.

np.seterr 는 ufunc 루프를 실행 한 다음 플래그가 설정되어 있는지 확인합니다.

fpectl 플래그 중 하나를 설정하는 작업이 발생할 때마다 하드웨어가 인터럽트를 발생시키고 커널이이를 프로세스에 전달 된 SIGFPE로 변환하고 longjmp 신호 처리기에서 직접 오류 처리 코드로 들어가는 SIGFPE 처리기.

fpectl 접근 방식의 몇 가지 단점은 다음과 같습니다. (a) Windows에서 전혀 작동하지 않습니다. (b) 내부적으로 이러한 플래그 중 하나를 일시적으로 설정 한 다음이를 지 웁니다. 합법적이며 그렇게하는 libm이있을 것으로 예상합니다.), (c) longjmp 는 엄청나게 취약합니다. 기본적으로 당신은 그것을 할 때마다 세그 폴트 위험을 감수하고 있습니다. 임의의 사용자 정의 ufunc에 대한 일반적인 솔루션이 될 수는 없습니다.

이 모든 것을 감안할 때 numpy가 전환되지 않을 것이라고 생각합니다.

어쨌든 원래 문제가 해결 된 것처럼 들리므로이 문제를 종료합니다. seterr 에서 변경 사항에 대한 케이스를 만들고 싶다면 언제든지 새 문제를 열 ​​수 있습니다.

어쨌든 원래 문제가 해결 된 것 같습니다.

객체 루프에 대한 FPU 플래그 검사를 비활성화하고 싶지 않습니까? 그것은 numpy에 대한 꽤 현명한 변화처럼 보일 것입니다.

@ eric-wieser : 오, 그거 흥미로운 생각 이네요. 아마도 그것에 대한 문제를 여는 것이 가치가 있습니다 :-). 하지만 "올바른 것"은 매우 복잡합니다. 이상적으로는 객체 dtype (사용자 dtype을 생각해보십시오)을 특수 케이스로 지정해서는 안되며 정수 루프도이를 사용해서는 안됩니다 (이것은 검사하는 일부 아키텍처에서 실제 최적화 일 수 있습니다 / FPU 플래그를 지우는 것은 매우 느립니다), 그러나 정수 루프는 정수 오류를 명시 적으로 신호하는 방법이 필요합니다. 현재는 FPU 플래그를 명시 적으로 설정하여 수행합니다. -매달린 과일?

아니면 내가 오해를했고 현자는 문제를 확인했을 뿐이고 실제로 문제를 해결하기 위해 여전히 엄청난 변화가 필요합니까?

@njsmith : Windows에서 작동하지 않는 이유를 이해할 수 없습니다. (그러나 이것은 C99 이전 시대에 맞을 것입니다). 최신 FPU 처리 함수 (fenv)는 C 컴파일러가 C99 표준을 준수하는 즉시 사용할 수 있습니다. fenv 외에 필요한 것은 setjmp / longjmp (다시 말하지만 표준 C 기능)입니다.

또한 정상적인 작업 과정에서 FE 예외 중 하나를 발생시키는 libm에 대해 듣고 싶습니다.
(버그로 분류되지 않는 한).

@dimpase : C99에 지정되지 않은 SIGFPE 지원도 필요합니다. (글쎄, C99는 SIGFPE가 있어야한다고 말하지만, 그것은 0으로 나누기위한 것입니다. 부동 소수점 예외에 연결하는 방법을 지정하지 않습니다.) 즉, 제가 잘못 기억 한 것 같습니다. MSVCRT는 신호를 지원하지 않고, MSVCRT는 구조적 예외 처리를 사용하여 SIGFPE를 에뮬레이트하고, 특정 fp 예외에 사용할 수 있도록 비표준 _control_fp 함수를 제공하므로 Windows 지원은 실제로 장벽이 아닙니다. OTOH longjmp 는 매우 좋은 이유 없이는 확실히 일어나지 않기 때문에 그다지 중요하지 않습니다. :-)

그리고 FWIW, libm이 FE 예외를 일으킨 다음 다시 지우면 왜 버그로 간주하는지 알 수 없습니다. 나는 그러한 구현이 존재하는지 확신하지 못하지만 그럴듯하다. 그렇다면 우리가 알아내는 방법은 누군가가 플랫폼 X에서 numpy가 고장 났다고 알려주고 유일한 수정 사항은 변경 사항을 되 돌리는 것입니다. 당신이 제안했습니다.

이전 댓글 끝에 내가 물어 본 질문에 답할 수 있습니까?

@njsmith : libm (또는 다른 사용자 코드)이 FE 예외를 발생시키고 처리해야하는 경우 자체 FE 예외 처리기를 설정하고 이전 예외 처리기를 저장하고 종료시 이전 예외를 복원합니다.
따라서 기본 코드가 규칙에 따라 작동하는 경우 문제가되지 않습니다.

이에 대한 MS 지원과 관련하여 Visual C (++) 2013 이후로 fenv.h를 제공 합니다.
그것은 특히 setjmp / longjmp와 함께 유용하게 사용하기위한 것입니다.

numpy의 RuntimeWarning과 관련하여 :

• 사용자 코드가 FP 플래그로 빠르고 느슨하게 재생 될 수 있다고 생각하는 경우 이러한 경고는 기껏해야 선택 사항입니다.
• 그렇지 않으면 표준으로 유지 될 수 있지만 적어도 그들이 온 곳의 바닥에 도달하는 방법은 유용하기 위해 중요합니다. (개선됨) fpectl 는 후자를 달성하는 빠른 방법입니다. 외부 도구 (예 : 모든 명령어를 확인할 때 코드를 계측 할 수 있도록하는 디버거)를 사용하는 것은 더 어렵고 느리고 오류가 발생하기 쉽습니다. 디버깅이 가능한 바이너리에서 찾으려고하면 즉시 사라집니다.
• 어쨌든, RuntimeWarning은 끌 수 있어야합니다.

Sage의이 문제와 관련하여-여전히 수정 중입니다 ( MPFR의 일부 문제로만 제한되기를 바랍니다).

죄송합니다. 이것은 원으로 진행되고 있으며 다른 작업으로 넘어 가야합니다. fenv / sigfpe 문제에 대해 새로운 것이 나오지 않는 한 이것이 주제에 대한 마지막 메시지가 될 것입니다. (세이지 버그에 대해 numpy 가해 야 할 일이 있는지 여전히 관심이 있습니다.)

libm (또는 다른 사용자 코드)이 FE 예외를 발생시키고 처리해야하는 경우 자체 FE 예외 처리기를 설정하여 이전 예외 처리기를 저장합니다.

당신이 제안하는 것은 일반적으로 신호 처리기를 실행하지 않는 작업을 수행하고 신호 처리기를 실행하는 비표준 모드에서 프로세서를 구성하는 것입니다. 코드가이 작업을 수행하고 신호 처리기를 전혀 트리거하지 않을 것으로 예상하는 것은 전적으로 합리적입니다.

이에 대한 MS 지원과 관련하여 Visual C (++) 2013 이후로 fenv.h를 제공합니다.
특히 setjmp / longjmp와 함께 유용합니다.

여기서 무슨 말을하는지 모르겠네요. fenv.h의 표준 기능인 Afaict는 numpy 스타일 기능을 구현하는 데만 유용하며 MS는 표준을 고수합니다. setjmp / longjmp와 함께 사용할 수있는 함수가 전혀 보이지 않습니다.

사용자 코드는 FP 플래그로 빠르고 느슨하게 재생할 수 있으며 이러한 경고는 기껏해야 선택 사항입니다.

중간 계산에 의해 설정된 플래그를 조심스럽게 지우는 것은 빠르고 느슨하게 플레이하는 것과 정반대입니다. 또한 경고는 선택 사항입니다.

그들이 온 곳의 바닥에 도달하는 방법은 그들이 유용하기 위해 매우 중요합니다. (개선됨) fpectl은 후자를 달성하는 빠른 방법입니다.

당신은 말 그대로 10 년 만에 이런 종류의 문제를 디버깅하기 위해 SIGFPE가 필요한 최초의 사람입니다. 그리고 세이지 버그 댓글을 다시 살펴보면 실제로 fpectl이 작동하지 않은 것 같습니다. 코어 덤프를 유발해서는 안됩니다. (cysignals가 fpectl 코드를 재정의하는 것처럼 보이므로 실행되지도 않습니다.)

이 문제가 다시 발생하면 한 번의 C 호출을 수행하여 SIGFPE를 활성화 한 다음 디버거를 사용하여 스택 추적을 가져옵니다. 스택 추적을 얻기 위해 디버그 빌드가 필요하지 않습니다. 기호를 제거하지 않으면됩니다. 그리고 이제 우리는 이것이 다시 발생할 경우를 알고 있습니다.

디버깅이 정말 힘들다는 것을 이해합니다.하지만 이것이 무엇을 성취 할 것인지 명확하게 설명 할 수없는 경우 다른 프로젝트가 기본 인프라를 변경하거나 유지해야한다고 주장하는 것은 도움이되지 않습니다. (실제로 여기서 numpy가 뭔가를 변경하면 이런 종류의 버그를 더 빨리 찾는 데 어떻게 도움이된다고 생각하는지 전혀 모릅니다. longjmp 의 전체 아이디어는 사용자가 원하는 더 정확한 정보를 파괴하는 것입니다.)

마지막으로 clang C 컴파일러의 오랜 버그 로 귀결됩니다. 기본적으로 double 의 특정 범위에서 할당은

unsigned long a;
double b;
...
a = b;

FE_INVALID 모금 (때로는 FE_INEXACT ); btw 이것은 다른 유형의 float 데이터에도 영향을 미칩니다. 훌륭한 MPFR (MPFR은 임의의 정밀도 부동 소수점에 double을 복사해야 함) 사람들이 해결 방법을 제공하여 현명한 문제를 해결했습니다.

덧붙여서, 관련 훨씬 더 오래 지속되는 (2010 년 이후로 12 개의 닫힌 중복이 있음) clang 버그 8100 은 clang의 fenv.h 를 사용하여 현재 fpectl 제대로 작동시킬 희망이 없다고 말합니다. . Clang은이 점에서 C99를 완전히 준수하지 않으며 정말 부끄러워합니다.

numpy 이 (가) 그것에 대해 무엇이든 할 것인지 확실하지 않습니다. RuntimeWarning 가 단지 컴파일러 버그 때문일 수 있다는 언급 ( "clang bug 8100"을 인용하면 매우 눈에 띄는 예임)이 도움이 될 수 있습니다.

버그 8100은 관련이 없습니다. 이는 C99 pragma가 부동 소수점 최적화를 비활성화하는 것이며, 주류 컴파일러는이를 지원하지 않습니다. numpy는 어쨌든 (대부분) 작동하는 것 같습니다 :-)

버그 8100의 정신은 clang이 FP 작업이 올바르게 컴파일되는 것을 신경 쓰지 않는다는 것입니다. 변호사는 동의하지 않을 수 있습니다. :-)

좋아, 이미 언급 한 버그 17686 은 확실히 관련이 있습니다.