인텔 Windows 컴파일러는 128 비트 정수에 대해 무엇을합니까? Windows의 MT1993에 비해 MSVC로 PCG64 컴파일이 얼마나 느립니까? 점프 어드밴스 기능이 널리 사용될 것으로 예상되므로 기본적으로 사용하는 것이 좋습니다.

인텔 Windows 컴파일러는 128 비트 정수에 대해 무엇을합니까?

완전히 확실하지 않습니다. ICC가 제약을받는 ABI 의미가 있는지 모르겠습니다. 우리가 사용할 수있는 생성 된 어셈블리에 대한 아이디어를 얻으려면 다음이 유용한 리소스입니다. https://godbolt.org/z/kBntXH

점프 어드밴스 기능이 널리 사용될 것으로 예상되므로 기본적으로 사용하는 것이 좋습니다.

오히려 설정 가능한 스트림을 의미합니까? 그것은 좋은 지적이지만, 다른 방식으로 절단되지 않을 수 있는지 궁금합니다. 기본값을 선택하는 것이 실제로 중요하다면 이러한 완전한 기능을 갖춘 PRNG 중 하나를 선택하면 사람들은 이러한 "고급"기능이 필요하다는 문서화없이 라이브러리 코드에서 이러한 기능을 더 광범위하게 사용할 것입니다. "표준"을 사용할 수 있습니다. 그러나 다른 사용자가 속도 나 기타 이유로 기능이 떨어지는 BitGenerator 로 해당 라이브러리를 사용하려고하면 벽돌 벽에 부딪 힐 것입니다. No default 또는 MT19937 세계에서 도서관은 필요한 고급 기능에 대해 생각하고 문서화 할 가능성이 더 높습니다.

손에 쥐고있는 손에, 그 결과는 설정 가능한 스트림이없는 BitGenerator 덜 바람직하게 보이게 만들 것이며, 그 방향으로 모범 사례로 간주되는 것을 발전시키는 개념을 _do_ 좋아합니다 (순전히 개인적으로; NumPy-the-project가 그 개념을 공유하도록 할 의무). 코드 중간에 .seed() 를 사용하는 사람들에게서 볼 수있는 남용을 피하는 데 도움이 될 수 있습니다. 그러나 다시 말하지만, 불이행이 있으면 사람들의 행동이 크게 바뀔 것이라는 개념에 근거한 모든 것이기 때문에 이러한 모든 우려는 상당히 약화 될 가능성이 높습니다.

Windows의 MT1993에 비해 MSVC로 PCG64 컴파일이 얼마나 느립니까?

@bashtage 가 #

인텔 Windows 컴파일러는 128 비트 정수에 대해 무엇을합니까?

Clang, GCC 및 Intel 컴파일러와 같은 다른 컴파일러는 32 비트 시스템에서 64 비트 정수를 구현 한 것과 동일한 방식으로 64 비트 시스템에서 128 비트 정수를 구현합니다. 새로운 아이디어가 필요없는 모든 동일한 기술. Microsoft는 MSVC에 대해 그렇게하지 않았으므로 컴파일러에서 직접 지원하는 128 비트 정수가 없습니다.

그 결과, MSVC 호출 아웃과 같은 마이크로 소프트의 내장 함수에 의해 # 13163 손으로 구현하는 128 비트 수학 PCG64 기존의 구현을위한 _umul128 x86_64에있는 (그리고 아마도 또한 같은 동등한 더 휴대용 인텔 내장 함수 사용할 수 _mulx_u64 대신)을, 따라서 GCC, Clang 및 Intel 컴파일러가 스스로 수행 할 작업을 코딩합니다. 가장 큰 문제는 Microsoft의 컴파일러가 이러한 내장 함수를 잘 최적화하지 못한다는 것입니다 (적어도 인라인 된 것입니까?). 수작업으로 코딩 한 어셈블러가 더 빨리 진행될 수 있지만 적절한 수정은 컴파일러가 너무 나쁘지 않다는 것입니다.

점프 어드밴스 기능이 널리 사용될 것으로 예상되므로 기본적으로 사용하는 것이 좋습니다.

앞서가는 것을 좋아하 신다니 기쁘지만 왜 널리 쓰일 것이라고 생각하는지 궁금합니다. (개인적으로 저는 distance 정말 좋아하는데 두 개의 PRNG가 얼마나 떨어져 있는지 알려줍니다. PCG의 C ++ 버전에는 있지만 C 버전은 아닙니다. 관심.)

앞서가는 것을 좋아하 신다니 기쁘지만 왜 널리 쓰일 것이라고 생각하는지 궁금합니다.

현재 용어에 익숙하지 않을 수 있습니다. 내 말은 시뮬레이션을 병렬로 실행하는 데 사용할 수있는 독립적 인 스트림을 쉽게 얻을 수 있다는 것입니다. 얼마나 많은 시뮬레이션 문제를 병렬화 할 수 있는지 모르겠지만, 요즘 사람들이 칩에 넣는 코어 수를 감안할 때 속도 단점을 쉽게 보완 할 수있는 것이 많은 것 같습니다.

Microsoft는 MSVC에 대해 그렇게하지 않았으므로 컴파일러에서 직접 지원하는 128 비트 정수가 없습니다.

그래서 그것은 우리의 바퀴, OTOH를 해칠 것입니다. Windows의 많은 사람들이 Anaconda 또는 Enthought에서 패키지를 얻습니다. 둘 다 Intel을 사용하고 성능을 정말로 중요하게 생각하는 사람들은 아마도 Linux, Mac 또는 AIX에 있습니다.

편집 : 그리고 아마도 Microsoft가 우려한다면 문제 해결에 대한 현상금을 제공 할 수 있습니다.

FWIW, 다음은 uint128_t 를 uint64_t s의 구조체로 풀거나 다시 압축하는 데 필요한 비트를 포함하여 clang 가 중요한 함수에 대해 생성하는 어셈블리입니다. https : // godbolt.org/z/Gtp3os

@rkern 매우 멋지다. 손으로 작성한 128 비트 코드로 MSVC가 수행하는 작업을 확인하기 위해 동일한 작업을 수행 할 수 있습니까?

@rkern 매우 멋지다. 손으로 작성한 128 비트 코드로 MSVC가 수행하는 작업을 확인하기 위해 동일한 작업을 수행 할 수 있습니까?

어, 예쁘지 않아요. ~ https://godbolt.org/z/a5L5Gz~

죄송합니다. -O3 추가하는 것을 잊으 셨지만 여전히 추악합니다 : https://godbolt.org/z/yiQRhd

그렇게 나쁘지는 않습니다. 최적화를 사용하지 않았으므로 인라인하지 않았습니다. /Ox (더 나은 옵션이 있을까요?). 또한 MSVC가 C 회전 관용구를 찾을 수 없기 때문에 내장 회전 내장 ( _rotr64 )을 사용하도록 코드를 수정했습니다.

그래도 여전히 일종의 열차 사고입니다. 그러나 약간의주의를 기울이면 PCG64 코드를 조정하여 MSVC에서 모든 사람에게 완전히 당황스럽지 않은 것으로 컴파일 할 수 있다고 생각합니다.

다른 모든 항목을 병합하려면 지금은 "기본값 없음"을 선택하는 것이 어떻습니까? 따라서 호환성을 깨지 않고 나중에 (하나 이상의 릴리스 이후에도) 기본값에 대한 결정을 자유롭게 내릴 수 있습니다.

대부분의 사용자는 난수 전문가가 아니므로 기본값을 제공해야합니다.

"이제 더 많은 코드를 입력해야합니다"라는 말을 넘어서 우리가 무언가를 변경하면 어떻게 될까요? BitGenerator가 하드 코딩 된 경우 (기본값을 제공하지 않았기 때문에) 이제 모든 정교하지 않은 사용자는 자신의 코드를 리팩토링해야하며 선택한 뉘앙스를 이해해야합니다. 최고). 그러나 기본값을 제공하면 새 기본값 또는 새 버전이 비트 스트림과 호환되지 않기 때문에 시끄럽게 테스트를 중단 할 수 있습니다.

비트 스트림이 항상 일정 할 것이라는 가정과 NumPy 개발자가 자신이하는 일을 알고 있고 기본값이 최고 브랜드 여야한다는 가정 사이에서, 두 번째 가정의 측면에서 오류가 발생합니다. 첫 번째를 끊습니다.

편집 : 어떤 개발자가 자신이하는 일을 알아야할지 명확히합니다.

대부분의 사용자는 난수 전문가가 아니므로 기본값을 제공해야합니다.

글쎄, 우리는 최소한 우리가 기본값이 있는지 여부 또는 기본값이 무엇인지에 관계없이 권장 사항을 문서화 할 것입니다.

"이제 더 많은 코드를 입력해야합니다"라는 말을 넘어서 우리가 무언가를 변경하면 어떻게 될까요?

무슨 "무언가"에 대해 생각하고 있습니까? 나는 당신의 주장을 따를 수 없습니다.

"이제 더 많은 코드를 입력해야합니다"라는 말을 넘어서 우리가 무언가를 변경하면 어떻게 될까요?

무슨 "무언가"에 대해 생각하고 있습니까? 나는 당신의 주장을 따를 수 없습니다.

@mattip 은 기본 비트 생성기를 변경하는 것을

이 woudl은 그것을 채택한 사용자를 미치게 만들고 일부 코드 변경이 필요합니다.

예를 들어,

g = Generator()
g.bit_generator.seed(1234)

기본 비트 생성기가 변경된 경우 이것은 잘못된 것입니다.

더 건전한 일을하고 사용했다면

Generator(BitGenerator(1234))

그러면 당신은 그것을 보지 못할 것입니다.

IMO, 기본 선택을 고려할 때 기본 비트 생성기에서 치명적인 결함이 발견되거나 인텔이 칩에 QUANTUM_NI를 추가하여 무작위 성능에서 많은 OOM 개선을 생성 할 때까지 수정되었다고 생각해야합니다.

나는 내가 여기서 약간의 외부인이라는 것을 알고 있지만 어떤 PRNG가 기본 선택인지 영원히 고정되고 절대 변경되지 않는다고 기대하는 것이 합리적이라고 생각하지 않습니다. (예를 들어, C ++에서 std::default_random_engine 는 구현의 재량이며 릴리스에 따라 변경 될 수 있습니다.)

오히려 이전 결과를 재현하는 메커니즘이 필요합니다. 따라서 특정 구현이 존재하면 변경하는 것은 매우 좋지 않습니다 (예 : MT19937 _is_ MT19937, 다른 출력을 제공하도록 조정할 수 없음). [이미 존재하는 구현을 제거하는 것도 좋지 않습니다.]

기본값이 변경되면 이전 결과를 계속 재생하려는 사람들은 이름으로 이전 기본값을 요청해야합니다. (이전 릴리스에 해당하는 기본값을 선택하는 메커니즘을 제공하여 만들 수 있습니다.)

즉, 기본 생성기를 다른 것으로 교체 할 수 있더라도 실제로는 더 나아질 필요가 있습니다. 기본 생성기에있는 모든 기능은 향후 해당 기능을 지원하겠다는 약속을 나타냅니다. 기본 생성기가 효율적인 advance 이면 나중에 제거 할 수 없습니다. (이 문제를 피하기 위해 잠재적으로 기본 생성기의 고급 기능을 차단할 수 있습니다.)

요약하면, 기본값이 영원히 변하지 않는 계약에 자신을 고정하지 않고도 사용이 재현 가능한 결과를 얻을 수 있도록하는 방법이 있습니다. 그것은 또한 당신이 내리는 선택에 대한 지분을 감소시킬 것입니다.

(FWIW, 이것이 제가 PCG에서 한 작업입니다. 기본 PCG 32 비트 PRNG는 현재 XSH-RR 변형입니다 [C 라이브러리에서 pcg_setseq_64_xsh_rr_32_random_r 로 액세스하고 C ++에서 pcg_engines::setseq_xsh_rr_64_32 클래스로 액세스) library], 그러나 원칙적으로 미래 보장형 재현성을 원할 경우 별칭 인 pcg32_random_r 또는 pcg32 를 사용하는 대신 XSH-RR을 명시 적으로 지정해야하며 원칙적으로 다른 것으로 업그레이드 할 수 있습니다. .)

정말 영원하지는 않지만 (이 전체 프로젝트는 약 14 년 전에 이루어진 실제적이고 진실하며 영예로운 약속에 의해 90 % 추진됨), 말씀하신 바와 같이 전환은 (a) 변경해야 할 설득력있는 이유이며 (b) 감가 상각주기를 제공하려면 최소한 몇 년이 걸립니다.

가능한 한 오른쪽에 가깝게 만들기 위해 오늘 열심히 노력하는 것이 훨씬 좋습니다.

물론 금지되지 않은 한 가지는 동일한 값을 생성하므로 릴리스 후 PRNG 코드를 logn으로 개선하는 것입니다. 예를 들어, uint128을 사용하는 PRNG를 사용하는 경우 MS가 uint128 지원을 추가하거나 (우연한 기회) 향후 버전에서 Win64 용 어셈블리를 추가 할 수 있습니다.

예를 들어,

g = Generator()
g.bit_generator.seed(1234)

기본 비트 생성기가 변경된 경우 이것은 잘못된 것입니다.

맞습니다. @ eric-wieser와 함께 "기본값 없음"옵션에 대해 논쟁하는 것 같습니다. "대부분의 사용자는 난수 전문가가 아니므로 기본값을 제공해야합니다. . "

기본값 없음과 친숙하고 완전히 가정하는 기본값 사이에서 저는 항상 후자를 선택합니다.

지금:

Generator() # OK
Generator(DefaultBitGenerator(seed)) # OK
Generator(seed) # error

_my_ 기본 설정 :

Generator(1234) == Generator(DefaultBitGenerator(1234)
Generator(*args**kwargs) == Generator(DefaultBitGenerator(*args, **kwargs))

이제는 이것이 들어갈 것이라고 생각하지 않지만 RandomState의 사용을 연장하는 한 가지 방법은 비트 생성기를 선택할만큼 충분히 전문가라고 생각하는 사용자에게만이 기능을 제공하는 것입니다.

요약하면, 기본값이 영원히 변하지 않는 계약에 자신을 고정하지 않고도 사용이 재현 가능한 결과를 얻을 수 있도록하는 방법이 있습니다. 그것은 또한 당신이 내리는 선택에 대한 지분을 감소시킬 것입니다.

네, 있습니다. 사용자는 BitGenerator 를 이름 (예 : MT19937 , PCG64 등)으로 잡고 시드로 인스턴스화 할 수 있습니다. BitGenerator 개체는 균일 한 [0..1) float64 및 정수 (재미있는 점프 어 헤드 / 스트림 기능 포함)를 그리기위한 제한된 메서드 집합을 사용하여 핵심 균일 PRNG 알고리즘을 구현합니다 [0..1) . 우리가 이야기하고있는 Generator 클래스는 제공된 BitGenerator 개체를 가져 와서 모든 비 균일 분포, 가우시안, 감마, 이항 등을 제공하기 위해 래핑합니다. BitGenerator 대한 엄격한 스트림 호환성 보장. 우리는 어떤 것도 제거하지 않을 것이며 (출시 할 수있는) 어떤 것도 변경하지 않을 것입니다.

기본값에 대한 핵심 질문은 "인수가없는 g = Generator() 코드는 무엇을합니까?"입니다. 지금 PR에서 임의의 상태 (예 : /dev/urandom 와 같은 좋은 엔트로피 소스에서 가져옴)로 Xoshiro256 BitGenerator 를 생성합니다. "기본값 없음"옵션은이를 오류로 만드는 것입니다. 사용자는 원하는 BitGenerator 이름을 명시 적으로 지정해야합니다. @ eric-wieser의 요점은 "기본값 없음"이 첫 번째 릴리스의 _safe_ 옵션이라는 것입니다. 기본값을 제공하는 이후 릴리스는 기존 기본값을 변경하는 것과 같은 방식으로 문제를 일으키지 않습니다.

@rkern , 시드가 사용 가능한 엔트로피에서 자동 생성되는 인수가없는 경우에만 관심이 있다면 기본 생성기가 무엇인지는별로 중요하지 않습니다. 결과를 재현 할 수 없기 때문에 시간 단위로 변경 될 수 있습니다 ( 다른 실행은 다른 씨앗을 얻을 것입니다).

대조적으로 @bashtage 는 시드와 함께 제공되는 기본 생성기에 관심이있는 것 같습니다.

@rkern , 시드가 사용 가능한 엔트로피에서 자동 생성되는

BitGenerator 을 만든 후에 다시 시드 할 수 있습니다. 따라서 Generator() 작동하면 시드 된 PRNG를 원하는 사람들은 @bashtage 의 예에서와 같이 다음 줄에 시드 할 것입니다.

g = Generator()
g.bit_generator.seed(seed)

그것은 다소 지루한 일입니다. 그래서 대부분의 사람들이 일반적으로 Generator(PCG64(<seed>)) 선택할 것이라고 제안한 이유는 타이핑 방식만큼이나 편리하기 때문입니다. 그러나 @bashtage 는 추가 결정을 내릴 때 일부 저항을 올바르게 기록합니다.

그래서 저는 "또한 _ 사용자가 이들 중 하나를 인스턴스화하기를 원하는 모든 방법은 무엇입니까? 그리고 이러한 방법에 기본 설정이있는 경우 해당 기본값은 무엇이어야합니까?"라는 더 광범위한 질문이 우리 앞에 있다고 생각합니다. 개방형 디자인 공간이 있으며 Generator(<seed>) 또는 Generator(DefaultBitGenerator(<seed>)) 대한 @bashtage 의 제안은 여전히 ​​가능성입니다.

@bashtage 문서가 얼마나 도움이 될 것이라고 생각하십니까? 즉, 맨 위에 " PCG64 은 (는) 우리가 선호하는 기본값 인 BitGenerator "이고 모든 예제에서 일관되게 Generator(PCG64(seed)) 사용했다면 (다른 알고리즘을 구체적으로 설명하지 않는 경우)?

나는 Generator(<seed>) 또는 g=Generator();g.seed(<seed>) 보다 default_generator(<seed>) _function_을 가지고 있다고 확신 할 수 있습니다. 그런 다음 정말로 변경해야하고 무언가를 깨뜨리고 싶지 않다면 새 기능을 추가하고 이전 기능에 경고를 추가 할 수 있습니다. 첫 번째 릴리스에 experimental 로 표시하여 확고한 약속을하기 전에이 인프라를 야생에서 볼 시간을주는 것이 좋습니다.

내부 상태에 대한 세부 정보를 노출하지 않는 DefaultBitGenerator 개체를 실제로 만드는 것은 어떻습니까? 이것은 다른 비트 생성기 객체 중 하나에 대한 프록시이지만 원칙적으로 생성 된 숫자의 특정 시퀀스를 제외하고는 이들 중 하나를 래핑 할 수 있습니다. 이것은 사용자가 기본 BitGenerator로 할 수있는 작업에 대해 프로그래밍 방식으로 가정하지 못하도록하는 동시에 개선 된 알고리즘을 계속 사용할 수 있도록합니다.

정수 시드를 Generator 대한 인수로 직접 지원하는 것이 훨씬 더 친숙하다는 @bashtage에 동의합니다 (예 : np.random.Generator(1234) . 물론 이것은 DefaultBitGenerator 합니다.

Generator 대한 문서에서 NumPy의 각 과거 버전에서 기본 비트 생성기가 무엇인지에 대한 전체 기록을 제공 할 수 있습니다. 이것은 기본적으로 @imneme 의 제안이며 재현성 목적으로 충분하다고 생각합니다.

(이전 댓글에 대한 수정 사항을 방금 보았습니다)

죄송합니다. -O3 추가하는 것을 잊으 셨지만 여전히 추악합니다 : https://godbolt.org/z/yiQRhd

MSVC의 경우 -O3 가 아니라 /O2 또는 /Ox (하지만 /O3 !).

Generator 대한 문서에서 NumPy의 각 과거 버전에서 기본 비트 생성기가 무엇인지에 대한 전체 기록을 제공 할 수 있습니다. 이것은 기본적으로 @imneme 의 제안이며 재현성 목적으로 충분하다고 생각합니다.

실제로 Generator / DefaultBitGenerator pickle의 protocol 인수 와 같은 명시적인 version 인수를 포함하는 것이 더 좋습니다. 그런 다음 np.random.Generator(123, version=1) 와 같은 것을 작성하여 "버전 1"난수 (그것이 무엇이든) 또는 np.random.Generator(123, version=np.random.HIGHEST_VERSION) (기본 동작)을 사용하여 최신 / 가장 큰 비트 생성기를 원함을 나타낼 수 있습니다. (그게 뭐든간에).

아마도 version=0 는 NumPy가 지금까지 사용한 MT19937 이고 version=1 는 우리가 선택한 새로운 기본값이 될 수 있습니다.

내부 상태의 세부 사항을 노출하지 않는 DefaultBitGenerator 개체를 실제로 만드는 것은 어떻습니까? 이것은 다른 비트 생성기 객체 중 하나에 대한 프록시이지만 원칙적으로 생성 된 숫자의 특정 시퀀스를 제외하고는 이들 중 하나를 래핑 할 수 있습니다. 이것은 사용자가 기본 BitGenerator로 할 수있는 작업에 대해 프로그래밍 방식으로 가정하지 못하도록하는 동시에 개선 된 알고리즘을 계속 사용할 수 있도록합니다.

흠. 그것은 매력적입니다. 너무 복잡하고 고르 디우스 매듭에 또 다른 루프를 추가하는 것처럼 느껴지지만 (알렉산더 스타일의 획이 우리에게 더 많이 제공되어야합니다), 그게 제가 그것에 대해 말해야 할 유일한 나쁜 것입니다. 나머지 결정을 쉽게 _ 할 수 있습니다. 통계 품질과 성과에 집중할 수 있습니다.

실제로 Generator / DefaultBitGenerator pickle 와 같은 명시적인 version 인수를 포함하는 것이 더 좋습니다.

나는 이것의 팬이 아니다. pickle 케이스와는 달리, 이것들은 우리가 사용할 수있는 의미있는 이름을 가지고 있으며 이미 구현 된 메커니즘을 가지고 있습니다.

나는 이것의 팬이 아니다. pickle 케이스와는 달리, 이것들은 우리가 사용할 수있는 의미있는 이름을 가지고 있으며 이미 구현 된 메커니즘을 가지고 있습니다.

일반적인 NumPy 사용자의 관점에서 다음을 고려하십시오.

• np.random.Generator(seed, version=0) 대 np.random.Generator(seed, version=1)
• np.random.Generator(MT19937(seed)) 대 np.random.Generator(PCG64(seed))

대부분의 사용자가 RNG 알고리즘의 상대적인 장점에 대해 거의 알지 못한다고 가정하는 것이 안전하다고 생각합니다. 그러나 문서를 읽지 않아도 대부분의 경우 version=1 (최신 기본값)가 version=0 보다 더 나은 것으로 추측 할 수 있습니다. 대부분의 사용자에게 필요한 것은 이것이 전부입니다.

대조적으로 MT19937 및 PCG64 MT19937 와 같은 이름은 전문가 또는 이미 문서를 읽은 사람들에게만 의미가 있습니다. :).

귀하의 사용 사례에서 아무도 자신이 _ 원하는 version 를 선택하지 않습니다. 알려진 버전의 결과를 복제하기 위해 _ 필요한 _ version 만 선택합니다. 그들은 복제하려는 결과에 사용 된 특정 값을 항상 찾고 있습니다 (암시 적으로 허용했기 때문에 암시 적으로). 여러 값 간의 관계에 대해 추론 할 필요가 없습니다.

그리고 어쨌든, 그 수준의 교차 릴리스 재현성은 우리가 NEP 19 에서 부인 한 것입니다. 배포판의 버전 관리에 대한 주장은 여기에도 적용됩니다.

기본값에 대한 몇 가지 생각 :

• 99.9 %의 사용자는 기본 알고리즘에 대해 관심이 없거나 알고 싶어하지 않으며 난수 만 원합니다. 따라서 기본값에 대해 독단적 인 선택을하려면 +1을하세요. 사용자가 선택하지 마십시오.
• dSFMT 은 단순히 MT19937 보다 빠른 버전 인 것 같습니다 (문서에 "SSE2"를 얼마나 빨리 제거하고 제거하는 것이 좋을까요?). 어쨌든 비트 스트림 재현성을 보장하지 않기 때문에 내부 상태 차이는 그다지 흥미롭지 않으며 여기에서 우승 한 주장이 "기사 검토 중에 삶을 더 쉽게 만들기"라고하더라도 dSFTM 보다 MT19937 선호해야합니다. .
• 성능은 사용자 기반의 상당 부분에 중요합니다. 생성기의 통계적 속성은 _ 매우 _ 소수의 사용자에게만 중요합니다. 포함 된 모든 생성기는 일반적인 사용 사례에 적합합니다. 따라서 가장 빠른 것을 기본으로 선택하려면 +1하십시오.

죄송하지만 Windows에서는 32 비트가 여전히 중요합니다. https://github.com/pypa/manylinux/issues/118#issuecomment -481404761 참조

우리는 데이터 분석에서 리샘플링 방법을 더 많이 사용하는 방향으로 큰 변화를 겪고 있기 때문에 통계적 속성에 대해 많은 관심을 가져야한다고 생각합니다. 파이썬이이 문제에 대해 약간 엉성한 것으로 명성을 얻는다면, 기본적으로 만 그렇더라도 데이터 분석을 위해 파이썬을 고려하는 사람들이 이해하는 데 장애물이 될 수 있습니다. 파이썬이 순열과 시뮬레이션을 진지하게 생각하는 사람들을위한 선택 패키지라면 매우 기쁩니다.

나는 더 빠른 최첨단 알고리즘을 제공하는 것이 괜찮다고 생각하지만, 우리가 그것을 피하고 역 호환성을 유지할 수있는 한 기본적으로는 아닙니다.

일부 법의학 및 토론은 https://arxiv.org/pdf/1810.10985.pdf를 참조하십시오.

교과서는 물질적 오류 [20, 7, 2, 16, 15]를 도입하지 않고 실제 IIDU [0,1) 변수를 PRNG로 대체 할 수 있다고 암시 적 또는 명시 적으로 가정하는 방법을 제공합니다. 여기서는이 가정이 MATLAB, Python의 임의 모듈, R, SPSS 및 Stata를 포함하여 일반적으로 사용되는 많은 통계 패키지의 알고리즘에 대해 올바르지 않음을 보여줍니다.

@kellieotto , @pbstark- 순열 및 부트 스트랩에 대한 최상의 기반을 제공하기 위해 여기서 선택해야하는 PRNG에 대한 의견이 있습니까?

우리는 데이터 분석에서 리샘플링 방법을 더 많이 사용하는 방향으로 큰 변화를 겪고 있기 때문에 통계적 속성에 많은 관심을 가져야한다고 생각합니다.

동의합니다. 이러한 속성이 일부 실제 사용 사례와 관련이있는 한 매우 중요합니다. 일반적으로 제기되는 문제는 항상 매우 학문적입니다.

일부 법의학 및 토론은 https://arxiv.org/pdf/1810.10985.pdf를 참조하십시오.

매우 흥미로운 기사입니다. R, Python stdlib & co와는 달리 NumPy가 올바르게 작동하는 유일한 라이브러리 (9 페이지 상단)에 대한 결론을 내립니다.

논문보다 더 구체적인 예제를 얻는 것이 매우 유용 할 것입니다. 현재 기본 생성기도 어느 시점에서 고장 나면 언제입니까? ~ 17 억 개의 샘플을 그릴 때 40 % 짝수와 60 % 홀수를 생성하는 R의 sample 함수와 같은 예. 여기서 부트 스트랩 / 리샘플링에 해당하는 것은 무엇입니까?

R (3.6)의 최신 릴리스는 자르기 대 임의 비트 접근 방식을 수정합니다.
임의의 정수를 생성합니다. Mersenne Twister는 기본값으로 유지됩니다.
하지만 PRNG.

@Kellie Ottoboni [email protected] 와 기본 PRNG가
과학적 언어 및 통계 패키지는 암호화되어야합니다.
보안 (CS-PRNG, 예 : 카운터 모드의 SHA256), 낙하 옵션 포함
더 빠르지 만 품질이 낮은 것으로 돌아 가기 (예 : Mersenne Twister)
속도가 필요한 경우.

우리는 Python 용 CS-PRNG를 개발하고 있습니다.
https://github.com/statlab/cryptorandom

성능은 (아직) 좋지 않습니다. 병목 현상은 유형 변환 인 것 같습니다.
파이썬 내에서 이진 문자열 (해시 출력)을 정수로 캐스팅합니다. 우리는
더 많은 작업을 C로 옮기는 구현 작업을 수행합니다.

건배,
필립

2019 년 5 월 27 일 월요일 오전 6:27 Ralf Gommers [email protected]
썼다 :

통계적 속성에 많은 관심을 가져야한다고 생각합니다.
리샘플링 방법을 더 많이 사용하는 방향으로 크게 전환하는 과정에서
데이터 분석

동의합니다. 이러한 속성이 실제 사용과 관련이있는 한
매우 중요합니다. 일반적으로 제기되는 문제는 다음과 같습니다.
항상 매우 학문적입니다.

일부 법의학 및 토론은 다음을 참조하십시오.
https://arxiv.org/pdf/1810.10985.pdf

매우 흥미로운 기사입니다. NumPy가 유일한
R, Python stdlib & co와는 달리 올바른 라이브러리 (9 페이지 상단).

보다 구체적인 예제를 얻는 것이 매우 유용 할 것입니다.
종이. 현재 기본 생성기도 어느 시점에서 고장 나면
그게 언제 야? 40 % 짝수를 생성하는 R의 샘플 함수와 같은 예
17 억 개의 샘플을 그릴 때 숫자 및 60 % 홀수. 무엇입니까
여기에서 부트 스트랩 / 리샘플링에 해당합니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJEIA4CTLLHVGZVKBLPXPOUFA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVZLOBW63LNODWcomW2ZLOBW63LNODWcomW2ZLOBW63LNODWcomWXHJKTY
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWJW445QDPGZDGXMPA3PXPOUFANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

성능은 사용자 기반의 상당 부분에 중요합니다. 생성기의 통계적 속성은 _ 매우 _ 소수의 사용자에게만 중요합니다. 포함 된 모든 생성기는 일반적인 사용 사례에 적합합니다. 따라서 가장 빠른 것을 기본으로 선택하려면 +1

첫째, "가장 빠른"것을 선택할 방법이 없습니다. @bashtage 는 # 13163의 현재 코드에 대한 실행 했으며지도 전체에서 dSFMT가 Windows에서 승리하고 Linux에서 PCG-64 및 Xoroshiro 256에 의해 크게 이겼습니다. 그리고 이것은 모두 동일한 벤치 마크를 가진 동일한 머신에 있습니다. 다른 하드웨어 아키텍처 (X86 내의 수정 버전 포함)도 다른 벤치 마크와 마찬가지로 차이를 만듭니다. (이 스레드에서 이미 논의했듯이 PCG는 MSVC 문제로 인해 Windows 벤치 마크에서 제대로 작동하지 않습니다. MSVC가 개선되거나 사람들이 문제를 해결할 수 있기 때문에 일시적인 문제 일 가능성도 있습니다. 아마도 유사한 MSVC 문제가 Xoshiro의 이유를 설명합니다. 맞았다.)

또한 속도에 관심이있는 사용자의 "상당수"가 얼마나 큰지 궁금합니다. 파이썬 자체는 평균적으로 C보다 약 50 배 느립니다 . NumPy 사용자 중 몇 분의 1이 PyPy에서 실행하고 있습니까 (4 배의 속도 향상을 제공함)? 확실히 일부는 있지만 그다지 높지 않은 것 같습니다.

그리고 위에서 설명한 모든 가변성을 고려할 때 속도에 관심이있는 "중요한 부분"에 대해 누가 기본 PRNG가 해당 응용 프로그램에 대해 가장 빠르게 실행될 것이라고 귀하의 말을 받아들이겠습니까? 할 수있는 현명한 일은 (그것은 또한 꽤 재미 있고 대부분의 사용자의 손이 닿는 범위 내에서) 사용 가능한 다양한 PRNG를 벤치마킹하고 어떤 것이 가장 빠른지 확인하는 것입니다.

반대로 문서에서 단서를 찾을 수 있지만 통계적 품질 특정 PRNG를 파악하는 것은 대부분의 사용자의 레이더가 아니며 전문가에게도 어려운 일입니다. 대부분은 그들이 관심을 가져야할지 여부를 알지 못할 것입니다. 나는 이것이 어떤 가부장주의를위한 장소라고 주장하고 싶다. 대부분의 사용자가 무언가에 대해 신경 쓰지 않는다는 사실이 관리자가 그것에 대해 신경 쓰지 말아야한다는 것을 의미하지는 않는다.

포함 된 모든 PRNG가 대부분의 사용 사례에 적합하다는 것은 사실이지만 상당히 낮은 기준입니다. Unix 시스템에는 통계적으로 모두 끔찍한 C 라이브러리 PRNG가 포함되어 있지만 전 세계가 축에서 벗어나지 않고 수년 동안 널리 사용되었습니다.

통계적 속성 외에도 사용자가 원하는 것은 모르지만 원하는 속성이 있습니다. 개인적으로 PRNG 제공 업체로서 저는 사소한 예측 가능성을 피하고 싶습니다. 누군가가 PRNG의 몇 가지 출력을보고 향후 모든 출력이 무엇인지 말할 수 있기를 원하지 않습니다. NumPy가 사용되는 대부분의 상황에서 예측 가능성은 문제가되지 않습니다. 시퀀스를 쉽게 예측할 수 있다는 이점을 얻을 수있는 공격자는 없습니다. 그러나 누군가는 통계를하기 위해 NumPy가 필요하기 때문이 아니라 이전에 PRNG를 발견 한 곳이기 때문에 어딘가에서 NumPy의 PRNG를 사용할 것입니다. 해당 코드는 PRNG를 예측할 수있는 이점을 얻을 수있는 실제 적과 마주 할 수 있습니다. 이러한 특이한 상황에 대해 확고하게 보장하기 위해 많은 비용 (예 : 상당한 속도 손실)을 지불하는 것은 그만한 가치가 없지만 적당한 보험은 그만한 가치가 있습니다.

일부 법의학 및 토론은 https://arxiv.org/pdf/1810.10985.pdf를 참조하십시오.

교과서는 물질적 오류 [20, 7, 2, 16, 15]를 도입하지 않고 실제 IIDU [0,1) 변수를 PRNG로 대체 할 수 있다고 암시 적 또는 명시 적으로 가정하는 방법을 제공합니다. 여기서는이 가정이 MATLAB, Python의 임의 모듈, R, SPSS 및 Stata를 포함하여 일반적으로 사용되는 많은 통계 패키지의 알고리즘에 대해 올바르지 않음을 보여줍니다.

FWIW, @lemire 가 편견없이 범위 내에서 숫자를 효율적으로 생성하는 방법에 대한 멋진 논문 이 있습니다. 나는 그것을 내 기사 에서도 몇 가지 벤치 마크를 탐색하고 실행하기위한 출발점으로 사용했다. (64 비트를 생성 할 때 Lemire의 방법은 MSVC 사용자에게 발생할 수있는 모든 친숙한 문제와 함께 느린 64 비트 분할을 피하기 위해 128 비트 곱셈을 사용합니다.)

@pbstark @kellieotto arXiv에 올라 왔을 때 관심을 가지고 당신의 논문을 읽었습니다. BIDS에있는 친구들을 방문했는데 그들은 당신의 일을 언급했습니다. 토론 섹션에서는 "지금까지 MT19937에 대해 O (10 ^ 5) 복제에서 탐지 될만큼 큰 일관된 편향을 가진 통계를 찾지 못했습니다"라고 언급합니다. 아직 찾았나요? PCG64와 같은 128 비트 상태 PRNG에 대한 구체적인 예를 찾았습니까? 이것은 적어도 범용 기본값을 선택할 목적으로이 고려 사항이 다른 고려 사항 (IMO)을 능가하기 시작할 수있는 실용적인 관련성의 합리적인 임계 값 인 것 같습니다.

새로운 PRNG 프레임 워크 # 13163의 멋진 기능은 누구나 연결할 수있는 자신의 BitGenerator 을 (를) 제공 할 수 있다는 것입니다. 암호. C에서 cryptorandom 를 BitGenerator 로 구현하여 다른 옵션과 정면으로 비교할 수 있습니다.

개인적으로 속도에 관심이있는 사람들은 필요한 경우 더 많은 마일을 사용할 수있을 것으로 기대합니다 (여기에는 많지 않습니다). 우리는 안전한 기본값을 제공해야하며, 현재로서는 이것이 암호화를 제외한 모든 목적에 대해 안전한 기본값을 의미한다는 것입니다 (문서에서 이에 대한 경고가 있어야 함). 많은 사용자가 속도를 중요하게 생각하지만 솔직히 그렇기 때문에 너무 높은 우선 순위를 지정하지 않는 것이 좋습니다.
Numpy가 잘 한 그 기사는 흥미로워 보이지만 (아마도 Robert가 제대로 된 것에 대해 찬사를 보냅니다!), 실제로는 비트 생성기가 아닌 샘플러입니다.

@pbstark 아마도 이것을 numpy / randomgen과 호환되는 BitGenerator로 구현하고 싶습니까? 그 가능성이 모두 그것을 속도를 훨씬 더 유용한 형태로 폭 넓은 관객들에게 사용할 수 있도록하는 가장 쉬운 방법 일 수있다. 당신과 Kellie Ottoboni가 버클리에있는 것 같으니 우리가 시간을 내서 만날 수 있을까요? (단지 제안, 먼저 코드를 자세히 살펴 봐야합니다).

_Random Sampling : Practice Makes Imperfect_ 논문에 관해서는 읽기도 좋지만 100 년 동안 나노 초당 1 개의 숫자를 생성하는 1 조 개의 코어가 있다면 2 ^ 102 개 미만의 숫자를 생성 할 수 있다는 점을 기억할 가치가 있습니다.

사소하게 예측할 수있는 PRNG (Mersenne Twister와 같은 큰 상태 공간이있는 PRNG)의 경우 실제로 특정 출력 시퀀스를 생성 할 수 있는지 여부를 알 수 있습니다 (존재하는 경우 생성 할 시드를 찾거나 그렇지 않은 경우 괴로움을 느낍니다). ), 그러나 사소하게 예측할 수없는 다른 PRNG의 경우 어떤 출력 시퀀스가 ​​생성 될 수 없는지, 어떤 출력 시퀀스가 ​​있는지 (쉽게) 알 수는 없지만, 매우 드물기 때문에 검색 시간이 지나도 찾을 수 없을 것입니다. (아시다시피, 2 ^ 80 출력 내에서 _Twelth Night_가 포함 된 zip 파일을 뱉어 낼 수있는 PRNG 가 있지만 행운을 빕니다.)

정말로 cryptoprng를 원한다면 최신 하드웨어에서 유일한 선택은
전용 명령이 있기 때문에 AES. @lemire 에는 구현이 있습니다.
여기 https://github.com/lemire/testingRNG/blob/master/source/aesctr.h
비 암호화 생성기만큼 빠릅니다. 갈 수있는 ChaCha20도 있습니다
SIMD로 빠르게. 둘 다 오래된 하드웨어에서는 느릴 것입니다. ThreeFry와
Philox는 이미 포함되어 있으며 cryptolite 카운터 제품입니다.

IMO 암호화는 비용 이점 측면에서 과대 평가됩니다. 나는 아무것도 모른다
Mt의 PRNG 문제로 인해 중요한 후퇴가 발생했습니다.
10e6 출판 된 논문에 사용되었습니다. 내가 본 유일한 응용 프로그램
PRNG가 정말 문제가 된 곳은 그 기간이
발전기가 전체 사이클을 완료 한 것입니다. 여기에서도 유일한
효과는 연구의 표본 크기를 줄이는 것이 었습니다.
기간이 더 긴 시스템에서 다시 실행되면 결과가 나타납니다.

2019 년 5 월 27 일 월요일 19:50 Robert Kern [email protected] 작성 :

@pbstark https://github.com/pbstark @kellieotto
https://github.com/kellieotto 나는 당신의 논문을 흥미롭게 읽었습니다.
arXiv에 나타났습니다. BIDS에서 친구들을 만나고 있었는데
당신의 일을 언급했습니다. 토론 섹션에서는 "지금까지는
일관된 편향이 감지 될만큼 큰 통계를 찾았습니다.
O (10 ^ 5) replications "for MT19937. 아직 하나를 찾았습니까?
PCG64와 같은 128 비트 상태 PRNG의 구체적인 예? 그것은 나에게 보인다
실용적인 관련성의 합리적인 임계 값이어야합니다.
적어도 선택의 목적을 위해 다른 사람 (IMO)보다 중요하기 시작할 수 있습니다.
범용 기본값입니다.

새로운 PRNG 프레임 워크의 멋진 기능 # 13163
https://github.com/numpy/numpy/pull/13163 은 누구나
플러그를 꽂을 수있는 자체 BitGenerator를 제공합니다.
사람들이 numpy 코드에서 그것을 사용하려면 numpy에 있어야합니다. 나는
C에서 BitGenerator로 cryptorandom 구현을 살펴 보도록 권장합니다.
다른 옵션과 정면으로 비교할 수 있습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRO5PKW4MRFSBGUFUNTPXQUOLA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMWW2ZLOBW63LNMWVXHJKissue ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABKTSRMRIHC4OYDR52HLTHDPXQUOLANCNFSM4HPX3CHA
.

또한 속도에 관심이있는 사용자의 "상당수"가 얼마나 큰지 궁금합니다. Python 자체는 평균적으로 C보다 약 50 배 더 느립니다. NumPy 사용자 기반 중 몇 분의 1이 PyPy에서 실행 중입니까 (4 배 속도 향상을 제공함)? 확실히 일부는 있지만 그다지 높지 않은 것 같습니다.

나는 당신이 일반 사용자가 아니라고 생각한다 :) NumPy는 대부분 내부적으로 C이고, C에서 당신 자신의 일을하는 것만 큼 빠르다. 또한 PyPy는 과학적 애플리케이션을위한 프로덕션 준비가되어 있지 않으며 어떤 경우에도 느립니다 (NumPy가 사용하는 CPython API를 사용하는 것으로 제한되어 JIT의 이점을 얻을 수 없기 때문입니다).

어느 쪽이든 이것은 주제에서 벗어난 것입니다. 속도 문제를 주장하는 것은 논란의 여지가 없습니다.

@imneme 우리는 제한된 정수에 lemires 메서드를 사용하고 있습니다. 이 이후
레거시 나 감가 상각없이 새로운 시작
좋은 알고리즘.

2019 년 5 월 27 일 월요일 19:46 imneme [email protected] 작성 :

일부 법의학 및 토론은 다음을 참조하십시오.
https://arxiv.org/pdf/1810.10985.pdf

교과서는 PRNG가 할 수 있다고 암시 적 또는 명시 적으로 가정하는 방법을 제공합니다.
재료를 도입하지 않고 실제 IIDU [0,1) 변수로 대체
오류 [20, 7, 2, 16, 15]. 우리는이 가정이
MATLAB을 포함하여 일반적으로 사용되는 많은 통계 패키지의 알고리즘,
Python의 임의 모듈, R, SPSS 및 Stata.

FWIW, @lemire의 멋진 종이 https://arxiv.org/abs/1805.10941
https://github.com/lemire 범위에서 효율적으로 숫자 생성
편견없이. 저는 그것을 탐험하고 실행하기위한 출발점으로 사용했습니다.
내 기사에서도 벤치 마크
http://www.pcg-random.org/posts/bounded-rands.html (생성시
64 비트, Lemire의 방법은 느린 속도를 피하기 위해 128 비트 곱셈을 사용합니다.
MSVC에서 발생할 수있는 모든 친숙한 문제를 포함한 64 비트 분할
사용자.)

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKNAQAK4WIXG5SVLO3PXQUA3A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVRWSG43VMVLOBW63LNODW96284ZLOBW63LNODVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABKTSRKV3KYKRLNMBKNU4JLPXQUA3ANCNFSM4HPX3CHA
.

우리는 _safe_ 기본값을 제공해야하며 현재 가장 좋은 추측은 이것이 암호화를 제외한 모든 목적에 대해 안전한 기본값을 의미한다는 것입니다.

논쟁하기 어렵습니다. 내 질문은-무엇이 안전한가요? 다양한 속성을 가진 준 무작위성의 정도는 다양합니다. 지금까지 다른 문제, PR 또는 스레드에서 구체적인 예를 제시하는 사람을 본 적이 없습니다. 추상적 인 통계적 속성에 대해 이야기하는 것만으로는 도움이되지 않습니다.

내 감각은 PCG64가 좋은 기본값이 될 것이라는 것입니다. Windows의 속도 단점은 Anaconda 등을 사용하는 사람들에게는 분명하지 않습니다. al., 그리고 어느 시점에서 수정 될 가능성이 있습니다. 병렬 실행이 Python의 새로운 기능이므로 설정 가능한 스트림을 갖는 것이 바람직한 속성이라고 생각합니다.

저는 Visual Studio의 PCG64 속도 패널티가 지워질 수 없다는 것에 매우 회의적입니다.

이것은 어딘가에서 신중하게 평가 되었습니까?

속도 문제를 주장하는 것은 논란의 여지가 없습니다.

내 질문은-무엇이 안전한가요?

논리를 일관되게 적용하십시오. "무엇이 빠른가"? 나는 numpy 프로그램이 실제로 BitGenerator 의 성능을 중요한 병목 현상으로 가지고 있는지 잘 모르겠습니다. 두 배 빠른 BitGenerator 를 사용하면 전체 계산에서 5 %의 속도가 향상됩니까? 아마 그것도 아닐 것입니다. C만큼 빠르지 않은 Python은 문제가 아닙니다. 실제로 유용한 PRNG가 많은 프로그램조차도 BitGenerator 에서 많은 시간을 소비하지 않습니다. 아마도 사용 가능한 선택으로 충분할 것입니다.

저는 Visual Studio의 PCG64 속도 패널티가 지워질 수 없다는 것에 매우 회의적입니다.

Up-thread 저는 clang 어떻게 PCG64를 64 비트 MSVC를 위해 훔칠 수있는 어셈블리로 컴파일하는지 보여줍니다. 그래서 64 비트 Windows의 MSVC가 극복 할 수없는 문제라고 생각하지 않습니다.

더 까다로울 수있는 것은 32 비트 시스템의 PCG64이며,이 중 32 비트 Windows만이 여전히 실질적으로 중요 할 수 있습니다. 이 경우 32 비트 ISA로 제한하는 것보다 MSVC에 관한 것이 아닙니다.

@Kellie Ottoboni [email protected] 와 제가 지적한 것은
적당한 크기의 문제라도 MT의 상태 공간은 너무 작아서 추정 할 수 없습니다.
균일 한 순열 (n <2100) 또는 균일 한 랜덤 샘플 (n = 4e8, k = 1000).

이는 부트 스트랩에서 순열 테스트, MCMC에 이르기까지 모든 것에 영향을 미칩니다.
의도 된 배포판과 실제 배포판의 차이
분포는 임의로 클 수 있습니다 (총 변동 거리가
2). 크고 심각합니다.

우리는 "통계적"기능에 대해 MT를 깨뜨리는 노력을하지 않았습니다.
몇 년. 나는 그것을 깨는 체계적인 방법이 있다고 확신합니다
(분포 거리가 너무 크기 때문에).

건배,
필립

2019 년 5 월 27 일 월요일 오후 12:26 Robert Kern [email protected]
썼다 :

속도 문제를 주장하는 것은 논란의 여지가 없습니다.

내 질문은-무엇이 안전한가요?

논리를 일관되게 적용하십시오. "무엇이 빠른가"? 나는 좋은 생각이 없다
어떤 numpy 프로그램이 실제로 BitGenerator의 성능을 가지고 있는지
심각한 병목 현상입니다. 두 배 빠른 BitGenerator를 사용하면
전체 계산에서 5 % 속도 향상을 얻을 수 있습니까? 아마 그것도 아닐 것입니다.
C만큼 빠르지 않은 Python은 문제가 아닙니다. 그것은 심지어 그저
실제로 유용한 PRNG가 많은 프로그램은 많은 비용을 지출하지 않습니다.
BitGenerator의 시간. 아마도 사용 가능한 선택 사항 중 하나는
충분한.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKSMPAG3GFUCUFRXCDPXQYVRA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW290PWSZGODWcomW2ZLO290PWSZGODWcomVXHJKT#5WcomWXHJKT
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWIDCPAJJ6DJ3RO332LPXQYVRANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

@pbstark 내가보고 싶은 것은 MT 또는 128 비트 PRNG가 실패하고 cryptorandom 가 작동하는 문제의 구체적인 구현 (인위적 일 수 있지만 너무 인위적이지는 않음)입니다. 리샘플링 방법이 128 비트 PRNG로 잘못된 추론을 제공하고 cryptorandom 올바른 추론을 제공하는 데이터 세트를 지적 할 수 있습니까?

PCG64로 이동하면 문제 크기의 하한이 더 나빠집니다.
상태 공간이 MT보다 훨씬 작기 때문입니다. 물론
여전히 "더 나은"임의성을 생성합니다.
순열 그룹은 MT보다 더 균등합니다. 그러나 그것은 전에 분해되어야합니다
500은 10을 선택하고 21은 전에!.

건배,
필립

2019 년 5 월 27 일 월요일 오후 12시 30 분 Robert Kern [email protected]
썼다 :

저는 Visual Studio의 PCG64 속도 패널티가
지울 수없는 것.

Up-thread 나는 clang이 PCG64를 어떻게 훔칠 수있는 어셈블리로 컴파일하는지 보여줍니다.
64 비트 MSVC의 경우 64 비트 Windows의 MSVC가
극복 할 수없는 문제.

더 까다로울 수있는 것은 32 비트 시스템의 PCG64입니다.
Windows는 여전히 우리에게 실질적으로 중요 할 수 있습니다. 이 경우 더 적습니다
32 비트 ISA로 제한하는 것보다 MSVC에 대한 것입니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWJFCINQCYGFCI7ULI3PXQZGLA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSEXG43VMV261BW63LNMW2962M261BW63LNMVXHJPI
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWK6QTB65Z4TJU76XKTPXQZGLANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

나는 PRNG에 대해 어떤 경우에도 실제로 무게를 지을만큼 충분히 알지 못합니다. 우선 통계적 속성에 초점을 맞추고 싶습니다 (정답이 모두 매우 훌륭하다는 것이라면 괜찮습니다). 제가 지금 궁금해하는 한 가지는 k 차원 등분 포입니다. 현재 MT에 비해 여기서 잘 작동하는 PCG 변형을 사용하고 있습니까? (비선형 역학에서 나왔기 때문에 약간 긴장되지만 PRNG에 대한 개요가 충분하지 않으며 앞으로 2 일 내에 얻을 수 없습니다 ...

최첨단 성능에 관심이있는 Windows 32 비트 사용자가 많지 않을 것 같습니다. 64 비트로 전환하는 데 많은 노력이 필요하지 않습니다.

저도보고 싶습니다.

우리는 수학에 기초하여 많은 큰 문제가 있어야한다는 것을 압니다.
그러나 우리는 아직 예를 지적 할 수 없습니다.

예방 원칙은 우리가 알고 있기 때문에
문제를 예방하는 방법 (CS-PRNG)을 알고 있습니다.
기본적으로 사용자가 선택하는 경우주의를 덜 기울일 수 있습니다.

2019 년 5 월 27 일 월요일 오후 12:39 Robert Kern [email protected]
썼다 :

@pbstark https://github.com/pbstark 내가보고 싶은 것은 구체적인
문제의 구현 (인위적 일 수 있지만 너무 인위적이지는 않음)
MT 또는 128 비트 PRNG가 실패하고 cryptorandom이 작동합니다. 너는 할수 있니
리샘플링 방법이 잘못된 데이터 세트를 지적하십시오.
128 비트 PRNG로 추론하고 cryptorandom으로 추론을 수정합니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWODTUIPNMVOJB6QP3DPXQ2FPA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSEXG43VMLOBW63LNG43VMVORBW63LNODW962292489 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWITAGQFZDQSIFNEHETPXQ2FPANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

k- 등분 포는 전체 PRNG 출력의 앙상블 속성입니다.
PRNG 기간. 좋은 일이지만 다른 것에 대해서는 아무 말도하지 않습니다
출력의 직렬 상관과 같은 임의성 실패의 종류.
상대적으로 낮은 막대입니다.

2019 년 5 월 27 일 월요일 오후 12:48 Sebastian Berg [email protected]
썼다 :

나는 PRNG에 대해 어떤 경우에도 실제로 무게를 지을만큼 충분히 알지 못합니다.
먼저 통계적 속성에 초점을 맞 춥니 다 (답이
그들은 모두 매우 훌륭합니다). 지금 제가 궁금한 것은
k 차원 등분 포. 현재 PCG의 변형을 사용합니까?
MT에 비해 여기서 잘합니까? (비선형 역학에서 비롯된
조금 긴장되지만 PRNG에 대한 개요가 충분하지 않으며
다음 2 일 내에받지 못할 것입니다 ...

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWPOBTPYHC3XBINQYA3PXQ3HZA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFVREXG43VMVLOBW63LNODcomW2962ZLOBW63LNODMVXHJKT
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWOEB7KR2YJZWHRRAHLPXQ3HZANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

@pbstark MT는 PCG (및 기타 생성기)가 통과하는 여러 통계 테스트에 실패합니다.

@rkern

MSVC에서 ror 명령어를 생성하려면 "_rotr64"내장 함수를 사용해야한다고 생각합니다.

또한 최적화를 위해 '/ O2'플래그를 선호 할 수도 있습니다.

PCG64를 사용하려면 어셈블리로 작성하는 것이 가장 좋습니다.

@pbstark의 경우 다음은 사용자에게 알려지지 않은 시드로 초기화 된 PCG-64의 일부 출력입니다 (실제로 스트림에 대해서도 설명하겠습니다. 0x559107ab8002ccda3b8daf9dbe4ed480 ).

  64bit: 0x21fdab3336e3627d 0x593e5ada8c20b97e 0x4c6dce7b21370ffc
     0xe78feafb1a3e4536 0x35a7d7bed633b42f 0x70147a46c2a396a0
  Coins: TTTHHTTTHHTHTTTTHTHHTTTTTHTTHHTTHHTHHTHHHHHHHHTTHHTTHHTHHHHHTHTHH
  Rolls: 5 3 5 2 5 3 1 6 6 5 4 4 5 5 5 6 2 3 5 3 2 3 2 5 6 2 4 6 2 3 4 6 3
  Cards: 5h 3h 3c 8d 9h 7s Kh Ah 5d Kc Tc 6h 7h 8s Ac 5c Ad Td 8c Qd 2h As
     8h 2d 3s 5s 4d 6d 2s Jd 3d 4h Ks 6s Qc Js Th 9d 9c Ts Jh 4c 2c 9s
     6c 4s 7c 7d Jc Qs Kd Qh

이제 무작위로 선택한 시드로 다른 pcg 생성기를 초기화한다고 가정 해 보겠습니다. 0xb124fedbf31ce435ff0151f8a07496d3 인수를 위해 선택합시다. 이 알려진 출력을 발견하기 전에 몇 개의 출력을 생성해야합니까? 위에서 사용한 시드를 알고 있기 때문에 (PCG의 거리 함수를 통해) 약 2.5 × 10 ^ 38 (또는 약 2 ^ 127.5) 출력에 답할 수 있습니다. 참고로 10 ^ 38 나노초는 우주 나이의 2300 억 배입니다.

그래서 실제로 거기에있는 PCG-64의 시퀀스가 ​​있지만, 실제로는 내가 어디를 봐야할지 말하지 않는 한 당신은 절대 찾을 수 없을 것입니다. (그리고 우리가 스트림을 변화 시키면 더 많은 가능성이있을 것입니다.)

정규 PCG는 실제로 셰익스피어 연극을 출력 할 기회가 없습니다. PCG 확장 생성 방식은 실제로 셰익스피어 연극을 출력 할 수 있지만, 비인 위 시나리오에서 그렇게 할 가능성은 매우 적어서 본질적으로 0입니다. 제 눈에는 실질적인 결과가 전혀없는 재산에는 가치가 거의 없습니다.

(또한 암호화 보안 PRNG는 k 차원 등분 포가 보장되지 않으며 가능한 모든 시퀀스를 생성 할 수있는 PRNG를 원하는 사람들에게 마법의 총알이 아닙니다. PRNG에서받는 것보다 더 많은 비트를 원하는 순간 시드와 저장을 상태로하면 생성 할 수없는 비트 시퀀스가 ​​필연적으로 있습니다 (증명 : 비둘기 구멍 원칙에 의해). 그리고 시드에 넣는 것과 동일한 양의 출력으로 제한하면 실제로 찾고있는 것은 해시 함수이거나, 시드 입력이 PRNG가 아니라 진정으로 무작위 인 경우 식별 함수일 수 있습니다.)

호기심으로 저는 aesctr.h , 임의 값당 ns의 시간을 사용하여 AES 카운터 비트 생성기를 래핑했습니다.

|                     |   Xoshiro256 |    PCG64 |   AESCounter |
|---------------------+--------------+----------+--------------+
| 32-bit Unsigned Int |      3.40804 |  3.59984 |      5.2432  |
| Uniform             |      3.71296 |  4.372   |      4.93744 |
| 64-bit Unsigned Int |      3.97516 |  4.55628 |      5.76628 |
| Exponential         |      4.60288 |  5.63736 |      6.72288 |
| Normal              |      8.10372 | 10.1101  |     12.1082  |
+---------------------+--------------+----------+--------------+

잘 했어요, @bashtage.

명심해야 할 몇 가지 사항 중 하나는 특정 AES 명령이 아키텍처에 따라 다를 수 있으며 활발하게 사용되는 모든 CPU에 존재하지 않으므로 (느린) 폴백 경로가 필요하다는 것입니다.

또한, 그것은 오렌지와 비교하는 약간의 사과입니다. 특수한 명령을 사용하는 것 외에도 AES 코드는 루프 풀기에서 속도의 일부를 얻습니다. 실제로 블록 단위로 숫자를 생성 한 다음이를 읽습니다. 언 롤링은 잠재적으로 PRNG 속도를 높일 수 있습니다. FWIW, @lemire 에는 실제로 AVX 명령어를 사용하여 한 번에 여러 출력을 생성 하는 벡터화 된 버전의 PCG 가 있습니다.

적어도 한 가지 합의점을 요약 할 수 있는지 살펴 보겠습니다. 우리 모두는 numpy가 사용할 BitGenerator 알고리즘에 대해 의견을 제시하고 다른 BitGenerator 알고리즘을 홍보해야한다는 데 동의합니다.

그 합의와 일치하고 다른 옵션 중 일부가 가질 수있는 일부 문제를 피하는 "기본값 없음"옵션을 스케치하는 데 한 번 더 찌르십시오. 견인력이 없으면 입을 다물겠습니다.

"기본값 없음"옵션이 실제로 의미하는 것은 "익명 기본값 없음"이었습니다. 시드 된 Generator 를 얻는 가장 편리한 방법은 우리가 지정한 PRNG의 이름을 지정하는 방법이되도록 API를 설계 할 수있는 방법이 여전히 있습니다. 예를 들어 BitGenerator 알고리즘의 전체 범위를 포함하지 _ 않았다 _ 고 가정 해 보겠습니다. 우리는 numpy를 최소한으로 유지하고 완성도는 일반적으로 scipy 및 기타 타사 라이브러리에 남겨 두려고합니다. 여기에서 그렇게하는 것이 좋습니다. 현재 아키텍처의 장점은 BitGenerator 를 다른 라이브러리로 옮길 수 있다는 것입니다. 따라서 기존 RandomState 및 사람들이 선호하는 BitGenerator 를 지원하기 위해 MT19937 만 제공한다고 가정 해 보겠습니다. 인수를 위해 Xoshiro256 라고 가정 해 보겠습니다. Generator.__init__() 생성자가 BitGenerator 요구하도록합시다. 뿐만 아니라,의는 정의 할 함수 np.random.xoshiro256_gen(seed) 가 반환 Generator(Xoshiro256(seed)) 내부적으로. 우리는 시드 얻을 수있는 방법으로 그 편리한 기능을 문서화 Generator .

이제 몇 가지 릴리스를 빨리 감습니다. 우리가 PCG64 , ThreeFry 등을 random-tng 또는 scipy 또는 다른 패키지로 푸시했는데 그중 하나가 추가 기능 또는 새로운 통계적 결함은 Xoshiro256 에서 발견됩니다. 우리는 BitGenerator 사람들이 사용해야하는 numpy의 의견을 PCG64 로 업데이트하기로 결정했습니다. 그런 다음 PCG64 BitGenerator 클래스를 추가하고 np.random.pcg64_gen(seed) 함수를 추가합니다. np.random.xoshiro256_gen(seed) 에 더 이상 선호되는 알고리즘이 아니라는 경고를 추가합니다. 새 코드는 np.random.pcg64_gen(seed) 를 사용해야하지만 계속해서 Xoshiro256 알고리즘을 사용하는 것이 좋습니다. 경고는 명시 적으로 Generator(Xoshiro256(seed)) 사용해야합니다.

이것은 "익명"API (예 : Generator(seed) , Generator(DefaultBitGenerator(seed)) , np.random.default_gen(seed) )에서 발생하는 몇 가지 문제를 피할 수 있다고 생각합니다. 우리는 더 이상 선호하지 않는 알고리즘을 영구적으로 지원할 수 있습니다. 우리의 의견을 바꿀 때 우리의 "선호하는"생성자가 뭔가 다른 것을하도록 만들 필요는 없습니다. 버전 번호가 아닌 실제 이름을 사용하여 구분하기 때문에 이전 결과를 재현하기 위해 코드를 업데이트하는 방법을 항상 알고 있습니다 (어떤 이유로 든 무해한 경고를 견딜 수없는 경우). 출처가 없거나 기록 된 numpy 릴리스 번호가없는 코드를 선택하여 업데이트 할 수도 있습니다. 동시에 알고리즘의 수를 최소로 제한하고 모범 사례를 라이브러리 작업에 _ 가장 쉬운 _ 방법으로 만들면 numpy의 의견을 효과적으로 표현할 수 있습니다.

어떻게 들리나요? 첫 번째 릴리스에서 BitGenerator 대한 확실한 선택을하기 위해 여전히 많은 노력을 기울여야합니다. 여전히 결과적입니다.

최첨단 성능에 관심이있는 Windows 32 비트 사용자가 많지 않을 것 같습니다. 64 비트로 전환하는 데 많은 노력이 필요하지 않습니다.

나는 동의한다. Win32에서 PCG64 의 문제는 단순히 성능 (그리고 우리가 약간의 노력으로 개선 할 수있는 문제)이기 때문에 이것이 차단기가 아니라는 데 동의하십니까?

MSVC에서 ror 명령어를 생성하려면 "_rotr64"내장 함수를 사용해야한다고 생각합니다.

또한 최적화를 위해 '/ O2'플래그를 선호 할 수도 있습니다.

감사! @imneme 은 나를 위해 이러한 모든 실수를 지적했습니다. :-)

@seberg 당신의 분야에서 당신의 경계를 불러 k . 다른 사람들은 다른 의견을 가지고있을 수 있으며, 내가 알지 못하는 특정 문제가 귀하의 분야에있을 수 있습니다. 이 경우 사용 가능한 특정 솔루션이 있습니다!

궁금해서 aesctr.h 사용하여 AES 카운터 비트 생성기를 포장했습니다.

나는 틀릴 수 있지만 이것이 @pbstark 의 우려에 도움이 될 것이라고 믿지 않습니다. AES-CTR은 CS-RNG이지만 모든 CS-RNG가 (이론적으로) 상당한 k 에 대해 가능한 모든 k! 순열에 도달하는 데 필요한 긴 기간을 갖는 것은 아닙니다. 카운터는 여전히 128 비트 숫자이며 롤오버되면 기간의 끝입니다. @pbstark 는 매우 큰 기간의 PRNG를 옹호하고 있으며, 대부분은 CS-RNG입니다.

일반적으로 등분 포에 대한 나의 견해는 일반적으로 PRNG의 등분 포가 PRNG의 상태 크기에서 허용하는 최대 값에 가까워지기를 원한다는 것입니다.

일부 사람들은 최대 등분 포를 바람직한 속성으로 간주하지만 결함으로 간주 될 수도 있습니다 (그만큼 많은 논문이 나와 있음). _k_-bit PRNG가 있고 모든 _k_-bit 시퀀스가 ​​정확히 한 번 발생하면 생일 문제가 발생하여 약 2 ^ (k / 2) 출력 후에 출력이 반복 될 것으로 예상됩니다. ( 저는 이러한 아이디어를 바탕으로 생일 문제 통계 테스트를 작성했습니다 . 64 비트 출력 64 비트 상태 PRNG 인 SplitMix와 32 비트 출력 64 비트 Xoroshiro64 +에서 통계적으로 믿을 수없는 반복이 없음을 정확하게 감지했습니다. -상태 2 차원 등분 포 PRNG 등.)

흥미롭게도 64 비트 반복 부족 (또는 너무 많은 반복-우리는 푸 아송 분포가 예상 됨)으로 인해 PRNG에 실패하는 통계 테스트를 작성하는 것이 매우 실용적이지만, 반대로 테스트를 작성하는 것은 실용적이지 않습니다. 어떤 값이 생략되었는지 알 수없는 경우 모든 64 비트 값의 36.8 % 누락을 감지합니다.

분명히 _k_가 커짐에 따라 예상되는 반복 부족 결함을 테스트하는 것은 비실용적입니다. 그러나 우리가 더 커지고 더 큰 상태 크기 (및 기간)에 도달함에 따라 추가 된 크기는 두 가지 모두를 보여주는 것이 비실용적임을 의미합니다. 최대 등분 포 PRNG는 반복하지 못하는 결함이 있으며 최대 등분 포가 아닌 PRNG가 일부 _k_ 비트 시퀀스를 (통계적으로 그럴듯한 방식으로) 반복하고 다른 시퀀스를 완전히 생략하는 데 결함이 있음을 보여주기에는 똑같이 비실용적입니다. 두 경우 모두 PRNG가 너무 커서 둘을 구분할 수 없습니다.

저도보고 싶습니다. 우리는 수학에 기초하여 많은 큰 문제가 있어야한다는 것을 알고 있지만 아직 예를 지적 할 수는 없습니다. 예방 원칙은 우리가 큰 문제가 있음을 알고 있고이를 방지하는 방법 (CS-PRNG)을 알고 있기 때문에 기본적으로 그렇게하는 것이 좋으며 사용자가 원하는 경우에는 덜주의 할 수 있도록합니다.

나는이 주장과 증거에 설득되지 않는다고 말해야한다. 따라서 나는 수 많은 사용자 앞에 서서 불편 함을 느끼지 않고 이러한 이유로 전환해야한다고 말합니다. 나는이 진술을 옹호 할 준비가되어 있지 않기 때문에 이러한 예를 요청하는 것입니다. 그것들은 설득력이있을 것이며 우리가 취하도록 권장하는이 입장을 방어 할 준비를 할 것입니다.

유한 PRNG가 실제 RNG에 미치지 못하는 속성이 많이 있습니다. 그리고 이론적으로는 실제 RNG의 속성에 따라 달라지는 계산이 많이 있습니다 (또는 적어도이를 완화 할 수있는 정도를 엄격하게 입증하지 않았습니다). 그러나 이러한 단점 중 상당수는 우리가 수행하는 실제 계산 결과에 매우 작고 실질적으로 눈에 띄지 않는 영향을 미칩니다. 이러한 위반 행위는 혐오 적이거나 전무, 진행 / 불가의 종류가 아닙니다. 그것들은 효과 크기를 가지고 있으며 우리는 그 효과의 어느 정도를 견딜 수 있습니다.

물론 특정 크기의 PRNG가 일부 k 대해 모든 k! 순열을 균등하게 생성 할 수 없다는 것을 설득력있게 보여줍니다. 내가 놓친 단계는 이러한 모든 순열을 생성 할 수없는 것이 내가 수행하고자하는 구체적인 계산에 어떻게 영향을 미치는지입니다. 사람들에게 문제를 보여줄 PractRand 또는 TestU01에 추가하도록 권장하는 테스트가 누락되었습니다.

@imneme 의 PCG 논문 에서 매우 유익한 분석 라인 중 하나는 각 PRNG의 여러 작은 상태 버전을 파생하고 TestU01이 실패하기 시작한 지점을 정확히 확인하는 것이 었습니다. 이를 통해 "X PRNG 통과"또는 실패라고 말하지 않고 일반적으로 PRNG 아키텍처를 비교할 수있는 방법을 제공합니다. 또한 사용중인 상태 크기 (일부 많은 GiB 샘플에서 TestU01을 통과)에서 얼마나 많은 헤드 룸이 있는지 추정 할 수 있습니다. 8 비트 PRNG의 문제를 보여주는 구체적인 계산이 있습니까? 16 비트 PRNG? 그러면이 새로운 테스트가 현재 TestU01 / PractRand보다 이전에 PRNG에 대한 정보를 알려주는지 확인할 수 있습니다. 그리고 그것은 매우 도움이 될 것입니다.

반면에 PractRand의 현재 테스트 제품군에 대한 작은 PRNG의 실패 지점보다 이러한 순열을 기반으로 실패를 표시하기 위해 PRNG에서 가져온 데이터가 더 많이 필요하다면이 문제는 실용적이지 않다고 결론을 내릴 것입니다. 우려 사항이며 순열 문제가 내 계산에 실질적인 영향을 미치는지 여부에 대한 좋은 프록시로 "passes PractRand"를 사용할 수 있습니다.

그러나 내가 실행하고 사람들에게 문제를 보여줄 수있는 프로그램을 손에 쥐기 전까지는이 기준으로 CS-PRNG를 추진하는 것이 편하지 않습니다. 나는 그 선택을 설득력있게 설명 할 수 없을 것이다.

32 개의 아이템을 섞으면 모두 32 개! 셔플 (즉, 모든 263130836933693530167218012160000000)은 32 개의 무작위 샘플 만 제공하는 PRNG가 아니라 생성 가능해야합니다. 셔플, 나는 실제로 당신이 엄청난 숫자를 요구한다면, 당신은 충분히 큰 생각을하지 않는 것 입니다.

따라서 나는 그 셔플이 나오는 순서도 미리 결정되어서는 안된다고 (직접적으로) 주장합니다! 분명히 32를 모두 출력하도록 요구해야합니다! 가능한 모든 순서로 셔플 — (32!)! 당신이 필요합니다! 물론 이것은 상태를위한 3.8 × 10 ^ 18 엑사 바이트와 초기화를 위해 비슷한 양의 엔트로피를 필요로하지만, 모든 것이 거기에 있다는 것을 아는 것은 확실히 가치가 있습니다.

... np.random.xoshiro256_gen(seed) 에 더 이상 선호되는 알고리즘이 아니라는 경고를 추가합니다. 새 코드는 np.random.pcg64_gen(seed) 를 사용해야하지만 경고없이 Xoshiro256 알고리즘을 계속 사용하는 것이 좋습니다. Generator(Xoshiro256(seed)) 명시 적으로 사용해야합니다.

그것은 여전히 ​​지원 중단과 그들이 정말로 알고 싶지 않은 이상한 들리는 이름으로 사용자를 괴롭 히고 있습니다.

NEP는 다음과 같이 말합니다. 둘째, 새로운 기능을 도입하거나 성능을 개선하기 위해 스트림 호환성을 깨는 것은 신중하게 허용됩니다.

우리의 기본값을 업데이트 할 충분한 이유가 있다면, 알고리즘을 명시 적으로 지정하지 않은 사용자에 대한 비트 별 재현성을 깨는 것이 더 나은 옵션 imho (그리고 이전에 주장했던 것)입니다.

"기본값 없음"옵션이 실제로 의미하는 것은 "익명 기본값 없음"이었습니다.

그렇다면 사용자가 사용중인 PRNG의 이름을 알고 싶어한다는 점이 요점입니까?

사용자의 관점에서 이것을보십시오. np.random.rand & co에서 np.random.RandomState() 로 이동 한 다음 메소드를 사용하는 것은 충분히 어렵습니다. 이제 우리는 더 나은 시스템을 소개 할 것입니다. 그리고 그들이 보게되는 것은 np.random.xoshiro256_gen() ? 그것은 유용성 측면에서 주요 회귀가 될 것입니다.

그렇다면 사용자가 사용중인 PRNG의 이름을 알고 싶어한다는 점이 요점입니까?

아니요, 사람들이 작업하던 default_generator(seed) 와 같은 "지정된 이동 대상"API (예 : @shoyer 의 version 인수)를 갖는 문제를 완화하는 것입니다.

NEP 19에서 부인하는 스트림 호환성을 유지하는 것은 API 손상에 이차적입니다. 서로 다른 BitGenerator 은 기능 세트에 따라 다른 효과적인 API를 갖습니다 (주로 PRNG의 매개 변수화 방법에 따라 다른 것이있을 수 있지만 설정 가능한 스트림, jumpahead). 따라서 기본 PRNG 선택의 일부 변경 사항은 실제로 나오는 값을 변경하는 것이 아니라 실제로 코드를 손상시킵니다 (예 : 더 이상 실행되지 않거나 더 이상 올바르게 실행되지 않음).

예를 들어 먼저 PCG64 선택한다고 가정 해 보겠습니다. 128 비트 상태, 2 ^ 127 설정 가능한 스트림을 가지고 있으며 jumpahead를 구현합니다. 훌륭하고 모든 기능을 갖추고 있습니다. 그래서 사람들은 default_generator(seed, stream=whatever) 쓰기 시작합니다. 이제 미래의 작업에서 우리가 다른 것으로 전환하고 싶게 만드는 몇 가지 주요 통계적 결함을 발견했다고 가정 해 보겠습니다. 우리가 기본값으로 승격하는 다음 PRNG는> = 128 비트 상태 여야합니다 (쉬움; 범용 기본값으로 더 작은 것은 권장하지 않음), jumpahead (하드!),> = 2 ^ 127 설정 가능한 스트림 (whoo, boy!), 이미 코드에 존재하는 default_generator() 의 사용을 깨지 않기 위해. 이제 우리는 그 래칫으로 살 수 있습니다.

@shoyer 는 기본 BitGenerator 항상 최소 공분모 기능으로 고의적으로 왜곡 할 수 있다고 제안했습니다. 작동합니다! 그러나 @charris 가 원하는 것과 같은 병렬 스트림 문제를 해결하기 위해 설정 가능한 스트림을 홍보 할 기회도 놓칠 것입니다.

이제 더 나은 시스템을 소개 할 것입니다. 그들이 보게되는 것은 np.random.xoshiro256_gen() ? 그것은 유용성 측면에서 주요 회귀가 될 것입니다.

이상하게 들리는 이름이 문제인 경우 정책이 동일하다면 더 친숙하고 일반적인 이름을 사용하는 것이 좋습니다 (새 기능을 추가하고 이전 기능에 대한 경고를 시작합니다). 나는 그 동등하다고 생각합니다. 이 일을 너무 자주해서는 안됩니다.

우리가 래칫과 함께 살기로 결정하고 version 메커니즘을 피해도 괜찮습니다.

"기본값"은 구현 세부 사항으로 남겨 두어 Generator() 가 항상 작동하도록 할 수 있다는 것입니다. 항상 재현 가능한 결과를 얻을 수있는 유일한 방법 (Generator의 변경 사항까지)은 Generator(BitGenerator(kwarg1=1,kwargs2=b,...)) 구문을 사용하는 것입니다.

상태에 대한 액세스는 피클 링이 필요하기 때문에 구현 세부 사항을 실제로 숨기는 것은 실용적이지 않습니다.

대안은 다른 기능 (일반적으로 임의 생성)과 같이 처리하고 변경해야 할 강력한 요구가있을 경우 표준 지원 중단주기를 거치는 것입니다. 이것은 일을 올바르게 수행하는 사용자에게는 영향을 미치지 않으며, 문서에서 충분한 경고를 받으면 적어도 대규모 프로젝트에서 적절한 적중률을 얻을 수 있습니다. 내가 여기서 제안하는 것은 새로운 API에 대해 생각할 때 스트림 호환성 보장이 이루어 졌다는 것을 잊을 수 있다는 것입니다.

# 13650에서 @bashtage 나는 액세스 허용 Generator().bit_generator 여전히에 직접 액세스 할 수있는 산세 허용하는 방식으로 state . 약간 재 작성된 test_pickle 를 파이썬 Thread 사용할 수있는 방식으로 전달합니다.

내 질문은-무엇이 안전한가요? 다양한 속성을 가진 준 무작위성의 정도는 다양합니다. 지금까지 다른 문제, PR 또는 스레드에서 구체적인 예를 제시하는 사람을 본 적이 없습니다.

일부 _N_ (512, 1024)에 대한 " _N_GiB 에서

알고리즘의 서수 순위를 허용하는보다 정교한 통계 품질보기를 원한다면 알고리즘의 축소 상태 변형 프로필을 사용하여 방법에 대한 아이디어를 얻는 @imneme 의 PCG 논문의 섹션 3 을 권장합니다. 각 전체 알고리즘이 가지고있는 많은 "헤드 룸". 이것은 암호학자가 다른 암호 알고리즘을 분석하는 방법과 매우 유사합니다. 검토되는 모든 실행 가능한 옵션은 "깨지지 않음"이라는 기준 기준을 통과해야하지만 이는 경쟁자 순위를 매기는 데 도움이되지 않습니다. 대신, 그들은 경쟁자 알고리즘의 감소 된 버전을 구축하고 그들이 그것을 깨기 전에 얼마나 감소해야하는지 확인합니다. N- 라운드 전체 알고리즘이 N-1에서 깨지면 헤드 룸이 매우 적고 암호학자는 아마이를 피할 것입니다. 마찬가지로 128 비트 BitGenerator 가 PractRand를 통과하지만 120 비트 버전이 실패하는 경우 꽤 위험 할 수 있습니다.

@mattip 합리적인 것 같습니다. 누군가 어딘가에서

import gc
state = [o for o in gc.get_objects() if 'Xoshiro256' in str(o)][0].state

그들이 그것을 깊이 탐구하고 싶다면 괜찮습니다. 전문가가 아닌 사용자를 돕고 싶습니다.

파이썬 Thread 사용할 수 있도록 약간 재 작성된 test_pickle 를 전달합니다.

이것이 눈에 띄는 문제 (# 9650)라는 점은 주목할 가치가 있습니다. 이상적으로 Generator() 는 자식 스레드에서 다시 시드됩니다. IIRC 이것은 Python> = 3.7에서만 실용적입니다.

"기본값"은 구현 세부 사항으로 남겨 두어 Generator() 가 항상 작동하도록 할 수 있다는 것입니다. 항상 재현 가능한 결과를 얻을 수있는 유일한 방법 (Generator의 변경 사항까지)은 Generator(BitGenerator(kwarg1=1,kwargs2=b,...)) 구문을 사용하는 것입니다.

우리가 구별해야 할 두 가지 종류의 재현성이 있습니다. 하나는 동일한 시드로 프로그램을 두 번 실행하고 동일한 결과를 얻는다는 것입니다. 그것이 우리가 지원해야 할 것입니다. 다른 하나는 적어도 엄격한 의미에서 우리가 부인 한 numpy 버전 간의 재현성입니다.

Argument-less Generator() , 즉 "numpy가 권장하는 임의로 시드 된 PRNG를주세요"는 주요 사용 사례가 아닙니다. 많은 지원이 필요하지 않습니다. "Numpy가 _this_ seed와 함께 권장하는 PRNG를 줘"는 옵션에 대해 논의하고 있습니다. numpy가 시드 된 PRNG를 얻는 방법에 대한 의견을 표현할 수있는 방법이 필요하며, 그 방법은 사용자에게 쉽고 편리해야합니다 (그렇지 않으면 사용하지 않을 것입니다). 나는 알고리즘 이름을 _like_하지만 (더 편리한 기능을 통해)하지만 @rgommers는 그것이 너무 먼 단계라고 생각하고 그것에 공감합니다.

Argument-less Generator (), 즉 "numpy가 권장하는 임의로 시드 된 PRNG를주세요"는 주요 사용 사례가 아닙니다. 많은 지원이 필요하지 않습니다. "Numpy가이 시드와 함께 권장하는 PRNG를 줘"는 옵션에 대해 논의하고 있습니다. numpy가 시드 된 PRNG를 얻는 방법에 대한 의견을 표현할 수있는 방법이 필요하며, 그 방법은 사용자에게 쉽고 편리해야합니다 (그렇지 않으면 사용하지 않을 것입니다). 나는 알고리즘의 이름을 짓는 것을 좋아하지만 (더 편리한 기능을 통해) @rgommers는 그것이 너무 먼 단계라고 생각하고 그것에 공감합니다.

사용자는 실제로 좋은 씨앗을 제공 할 수있는 장비가 부족하다고 주장합니다. 예를 들어, 얼마나 많은 사용자가 Mersenne Twister를 시드하는 올바른 방법을 알고 있습니까? 생각만큼 쉽지 않습니다. 624 개의 임의의 32 비트 정수 (19937 비트의 상태를 제공하기 위해)를 제공하지 않으면 잘못된 것입니다.

따라서 실제로 사용자가 재현 가능한 결과를 얻을 수있는 올바른 방법은 PRNG를 만든 다음 (시드를 제공하지 않고 자동으로 잘 시드되도록 함) 피클하는 것입니다.

토론이 올바른 방법에 관한 것이라면 나는
Generator(BitGenerator(**kwargs)) 만 사용할 것이므로
재현에 관심이있는 반 인식 사용자.

Generator() 에 사용되는 기본값이 중요하다고 생각합니다.
고려 된 선택으로 해석되므로
시드 양식을 사용할 때 권장 사항.

하나 더 버리기 위해 클래스 메소드 Generator.seeded(seed[, bit_generator]) where bit generator is a string. This would allow the pattern of switching from one value to None to warn if the default was going to change, like lstsq. I would also only support a limited pallatte of but generators initially (i.e. 1). Doesn't make it easy to expose advanced features I suppose. In a perfect world it would use kwarg only to allow any keyword argument to be used which avoids most depreciation problems. Of course, this doesn't really need to be a class function, just seeded`.

2019 년 5 월 28 일 화요일 16:38 Robert Kern [email protected] 작성 :

"기본값"에 대한 내 생각은 구현으로 남겨 둘 수 있다는 것입니다.
Generator ()가 항상 작동하도록합니다. 나는 이것을
항상 재현 가능한 결과를 얻을 수있는 유일한 방법은
(Generator의 변경 사항까지) 구문을 사용하는 것입니다.
생성기 (BitGenerator (kwarg1 = 1, kwargs2 = b, ...))

우리가 구별해야 할 두 가지 종류의 재현성이 있습니다. 하나는
동일한 시드로 프로그램을 두 번 실행하고 동일한 결과를 얻습니다.
그것이 우리가 지원해야 할 것입니다. 다른 하나는
최소한 가장 엄격한 의미에서 우리가 부인 한 numpy의 버전.

Argument-less Generator (), 즉 "임의로 시드 된 PRNG를
numpy recommendeds "는 주요 사용 사례가 아닙니다.
지원하다. "넘피 가이 시드와 함께 추천하는 PRNG를 줘"는
그리고 우리가 옵션에 대해 논의하고있는 것입니다. numpy를위한 방법이 필요합니다.
시드 된 PRNG를 얻는 방법에 대한 의견을 표명해야합니다.
사용자에게 쉽고 편리합니다 (또는 사용하지 않을 것입니다). 나는 좋아한다
알고리즘 이름 지정 (더 편리한 기능을 통해), 그러나
@rgommers https://github.com/rgommers는 그것이 너무 먼 단계라고 생각합니다.
나는 그것에 동정한다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVGW5A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSEXG43VMVORP,TDN5W965ZLOBW63LNMVWXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
.

2019 년 5 월 28 일 화요일 16:38 Robert Kern [email protected] 작성 :

"기본값"에 대한 내 생각은 구현으로 남겨 둘 수 있다는 것입니다.
Generator ()가 항상 작동하도록합니다. 나는 이것을
항상 재현 가능한 결과를 얻을 수있는 유일한 방법은
(Generator의 변경 사항까지) 구문을 사용하는 것입니다.
생성기 (BitGenerator (kwarg1 = 1, kwargs2 = b, ...))

우리가 구별해야 할 두 가지 종류의 재현성이 있습니다. 하나는
동일한 시드로 프로그램을 두 번 실행하고 동일한 결과를 얻습니다.
그것이 우리가 지원해야 할 것입니다. 다른 하나는
최소한 가장 엄격한 의미에서 우리가 부인 한 numpy의 버전.

Argument-less Generator (), 즉 "임의로 시드 된 PRNG를
numpy recommendeds "는 주요 사용 사례가 아닙니다.
지원하다. "넘피 가이 시드와 함께 추천하는 PRNG를 줘"는
그리고 우리가 옵션에 대해 논의하고있는 것입니다. numpy를위한 방법이 필요합니다.
시드 된 PRNG를 얻는 방법에 대한 의견을 표명해야합니다.
사용자에게 쉽고 편리합니다 (또는 사용하지 않을 것입니다). 나는 좋아한다
알고리즘 이름 지정 (더 편리한 기능을 통해), 그러나
@rgommers https://github.com/rgommers는 그것이 너무 먼 단계라고 생각합니다.
나는 그것에 동정한다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=ABKTSRKA4SSNW6XZEVFUMCDPXVGW5A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSEXG43VMVORP,TDN5W965ZLOBW63LNMVWXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABKTSROCMLHG6E6BLWI6TWDPXVGW5ANCNFSM4HPX3CHA
.

사용성 관점에서 Generator(seed) 를 지원해야한다고 생각합니다. 그렇지 않으면 준비되지 않은 선택을해야하는 경우 사용자는 RandomState 을 고수 할 것입니다.

의 기본 비트 생성기를 버전의 경우 Generator , 우리가 사용할 수있는 bit_version=1 대신 version=1 나는 또한 하락으로 확인 해요하지만, version 생각. 사용자가 비트 제너레이터를 매우 자주 명시 적으로 설정할 필요가 없다고 생각합니다.

특정 생성기 기능이 필요한 특정 사용 사례를 해결하는 데 선호하는 것은 구현 세부 정보를 숨기는 새롭고 일반적인 BitGenerator API를 설계하는 것입니다. 이것들은 DefaultBitGenerator 되거나, ParallelBitGenerator 와 같이 트레이드 오프가 사용되는 경우 새 클래스에 추가 될 수 있습니다.

기본 비트 생성기 변경으로 인해 RNG 스트림의 향후 변경 사항에 대한 경고를 피하고 싶습니다. 이러한 경고는 그러한 세부 사항에 의존하지 않지만 임의의 숫자가 자발적으로 변경되는 것을 막기 위해 Generator에서 seed 를 설정 한 대다수의 사용자에게는 소음이 될 것입니다.

사용자는 RandomState를 고수 할 것입니다.

괜찮습니다. 그들은 얼리 어답터가 아닙니다. 가능한 최소한의 가능한 API를 위해 열심히 추진하고 있습니다 (아마도 너무 어렵습니까?). 왜냐하면 우리는 항상 API를 넓힐 수 있지만 축소하기가 훨씬 더 어렵 기 때문입니다. Generator(Philox()) , Generator(seed(3)) 및 Generator(bit_version=1) 사이의 뉘앙스는 최종 사용자에게 알려지기 전까지는 확인하기가 약간 어렵습니다.

Generator(seed) 없이 첫 번째 버전을 출시하고 피드백을 받아 보겠습니다.

Generator(seed) 없이 첫 번째 버전을 출시하고 피드백을 받아 보겠습니다.

좋아요, 여기에는 심각한 이의가 없습니다. 이 경우 당분간 전체 BitGenerator를 지정해야 할 수도 있습니다.

따라서 실제로 사용자가 재현 가능한 결과를 얻을 수있는 올바른 방법은 PRNG를 만든 다음 (시드를 제공하지 않고 자동으로 잘 시드되도록 함) 피클하는 것입니다.

나는 똑같은 말을하지만 그것에 대한 견인력이 거의 없다. 당신이 말했듯이 "글쎄요, 뭔가 나쁜 생각이라고해서 사람들이 그것을 원하지 않을 것이라는 의미는 아닙니다!"

문제의 일부는 MT의 거대한 상태로 인해 악화되며, 실제로 파일로의 직렬화가 필요합니다. 파일 기반 댄스를 사용자가 사용하고 싶어하는 가장 쉬운 API로 만드는 것은 어렵습니다. 상태가 훨씬 작은 기본 PRNG를 사용하면 상황이 더 나아질 것입니다. 128 비트는 UUID의 크기로, 16 진수로 인쇄하고 복사하여 붙여 넣을 수있을 정도로 작습니다. 따라서 좋은 패턴은 기본적으로 좋은 엔트로피 시드가되도록 프로그램을 작성한 다음 다음에 프로그램을 실행할 때 복사하여 붙여 넣을 수있는 방식으로 상태를 인쇄하는 것입니다.

❯ python secret_prng.py
Seed: 0x977918d0c7da45e5168f72005586500c
...
Result = 0.7223650399276123

❯ python secret_prng.py
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

❯ python secret_prng.py --seed 0xe8962534e5fb585483b86119fcb852ce
Seed: 0xe8962534e5fb585483b86119fcb852ce
...
Result = 0.10640984721018876

이와 같은 패턴이 단순성과 미래 보장성을 모두 제공하는지 확실하지 않습니다.

NumPy 1. 다음

class Generator:
    def __init__(bitgen_or_seed=None, *, bit_generator='pcg64', inc=0):

NumPy 1.20.x

```파이썬
클래스 생성기 :
def __init __ (bitgen_or_seed = None, *, bit_generator = None, inc = None) :
bit_generator가 None이 아니거나 inc가 None이 아닌 경우 :
warn ( '기본값은 PCG64에서 AESCtr로 변경됩니다. inc 키워드'
'인수는 더 이상 사용되지 않으며 향후 발생할 예정입니다', FutureWarning)
````

NumPy 1.22

```파이썬
클래스 생성기 :
def __init __ (bitgen_or_seed = None, *, bit_generator = 'aesctr', inc = None, counter = 0) :
bit_generator == 'pcg64'또는 inc가 None이 아닌 경우 :
예외 발생 ( 'PCG는 더 이상 지원되지 않으며 inc가 제거되었습니다.')
````

이와 같은 패턴이 단순성과 미래 보장성을 모두 제공하는지 확실하지 않습니다.

위에서 https://github.com/numpy/numpy/issues/13635#issuecomment -496589421에서 언급했듯이 대부분의 사용자에게는 이것이 놀랍고 실망스러운 일이라고 생각합니다. 사용자가 모든 선택적 인수를 설정하지 않은 경우 경고를 발행 할 계획보다 명시적인 BitGenerator 개체를 제공해야합니다. API가 예상치 못한 방식으로 손상되었음을 발견하는 경우에는 이는 실제로 최후의 수단이되어야합니다.

문제는 과도기입니다. 기본값을 사용하는 모든 사람은 전환 기간 동안 전환 할 좋은 방법이없는 갑자기 경고를 받게됩니다. 또는 최소한 Generator(seed) "저에너지 상태"에서 Generator(seed, bit_generator='aesctr') 의 덜 편리한 "고 에너지 상태"로 이동합니다. 이 API의 목표는 편리한 "저에너지 상태"를 제공하는 것이기 때문에이 전환 과정에서 우리의 목적은 실패했습니다. 히스토그램 기능 중 하나 인 IIRC로이 작업을 한 번 수행했는데 악몽이었습니다.

이는 인수의 의미를 제자리에서 변경하려는 모든 지원 중단에 일반적입니다. 한 기능에서 다른 기능으로 _ 이동 _하는 사용 중단은 관리하기가 훨씬 더 쉽습니다. 이것이 제가 옹호했던 것입니다.

Generator(seed) 없이 첫 번째 버전을 출시하고 피드백을 받아 보겠습니다.

"첫 번째 버전"이란 전체 numpy 릴리스를 의미합니까? 아니면 PR을 병합하는 것입니까 (이후 발생)?

전체 numpy 릴리스 인 경우 몇 개의 BitGenerator 를 포함하는지와 같은 몇 가지 사항을 결정할 수 있습니다. 현재 전체 보완을 포함하면 몇 가지 옵션을 공개했습니다.

한 기능에서 다른 기능으로 _ 이동 _하는 사용 중단은 관리하기가 훨씬 더 쉽습니다. 이것이 제가 옹호했던 것입니다.

+1 동의 함

아니요, 사람들이 작업하던 default_generator (seed)와 같은 "지정된 이동 대상"API (예 : @shoyer 의 버전 인수) 문제를 완화하기위한 것입니다.

NEP 19에서 부인하는 스트림 호환성을 유지하는 것은 API 손상에 이차적입니다. BitGenerator마다 효과적인 API가 다릅니다.

아, 이제 더 이해가 되네요.

이상하게 들리는 이름이 문제인 경우 정책이 동일하다면 더 친숙하고 일반적인 이름을 사용하는 것이 좋습니다 (새 기능을 추가하고 이전 기능에 대한 경고를 시작합니다). 나는 그 동등하다고 생각합니다. 이 일을 너무 자주해서는 안됩니다.

이것은 지금까지 최고의 솔루션처럼 들립니다. 여기에서 정상적인 이름을 선택할 수 있습니다. 그리고 우리가 결코 필요로하지 않을 것 같은 다른 건전한 이름의 넓은 공간이 있습니다.

np.random.generator 또는 np.random.default_generator .

우리가 포함하는 BitGenerator의 수

현재 포함 된 항목 (MT19937, DSFMT, PCG32, PCG64, Philox, ThreeFry, Xoshiro256, Xoshiro512)에서 제거해야한다고 생각하는 항목을 삭제하는 제안과 함께 별도의 문제를 열 ​​수 있습니까?

우리는 여전히 여기서 당면한 문제를 해결하지 못했습니다 : 어떤 BitGenerator가 기본값이어야하는지 (현재 Xoshiro256 )

글쎄,이 문제는 "어떤 것이 고유 한 BitGenerator 로 홍보해야하는지"에 관한 것입니다.이 문제는 기본값 선택에 영향을 주지만 포함하거나 삭제해야하는 항목도 제공합니다. 기본값을 제공하는 메커니즘 (기본값을 제공하는 경우)은 몇 가지 제약을 추가하므로 모두 함께 결정되어야하는 모든 것입니다. 그것은 큰 털이 엉망이고, 당신이이 PR을 수행 한 모든 작업을 마친 후에는 아무도 코드를 제공하지 않는 또 다른 메가 스레드를 보는 것에 지쳤을 것이라고 확신합니다. :-)

알고리즘 자체에 관한 한 이미 권장 사항을 제공했습니다. RandomState 및 비교 목적으로 MT19937 을 유지해야하며 추천 목적으로 PCG64 를) 좋아합니다.

컴파일러 탐색기에서 약간 엉망이되었고 컴파일러가 clang의 uint128_t 수학에 가까운 어셈블리를 생성하도록하는 방식으로 내장 함수를 사용하여 64 비트 MSVC 용 PCG64를 구현했다고 생각합니다 : https : // godbolt .org / z / ZnPd7Z

지금은 Windows 개발 환경이 설정되어 있지 않으므로 실제로 _ 정확한 것인지 모르겠습니다 ...

패치 없음 :

Uniforms per second
************************************************************
PCG64            62.77 million

패치 포함 :

Uniforms per second
************************************************************
PCG64           154.50 million

패치는 2 개의 다른 시드에 대해 동일한 1000 개의 uint64 값 세트를 생성하는 것을 포함하여 테스트를 통과합니다.

GCC 네이티브 및 비교 모드에 대한 비교 :

Time to produce 1,000,000 Uniforms
************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms

와, 정말 안 좋은 것 같아요. 아마도 비교 페이지의 정보를 확장하여 동일한 시스템에서 msvc2017-on-win {64, 32} 대 gcc7.4-on-linux {64, 32}의 성능을 입증해야합니다 (단지 msvc2017을 사용하고 있다고 가정합니다. 해당 정보를 어딘가에 포함해야합니다).

Win32는 여기서 희망이 없습니다. Linux 32 비트도 상당히 끔찍할 것이라고 생각하지만 쉽게 테스트 할 32 비트 Linux 시스템이 없습니다.

32 비트 컴퓨터에 집착하는 사람들을위한 추천 사례를 확실히 볼 수 있습니다 (기업 IT 정책으로 인해 Windows 일 가능성이 가장 높음). 이 recco는 분명합니다. 32 비트 용 DSFMT (또는 MT19937도 좋습니다). 하지만 벤치 마크는 좋을 것입니다.

그만한 가치가 있기 때문에, 저는 여러 개의 독립적 인 랜덤 스트림에 대한 자주 반복되는 PCG 주장에 다소 회의적입니다. 독립성 주장을 뒷받침하기 위해 심각한 통계 분석을 한 사람이 있습니까? (사실, O'Neill의 논문은 독립성을 주장하지 않고 "고유 한"흐름만을 언급한다고 생각합니다.)

회의적인 이유가 있다고 생각합니다. 주어진 LCG 승수에 대해 이러한 모든 고유 한 스트림은 단순히 스케일링 [*]을 통해 관련됩니다. 따라서 동일한 승수를 가진 두 개의 LCG 스트림이 주어지면 그 중 하나는 시작점이 다르지만 다른 하나의 상수 배수 (모듈로 2**64 또는 2**32 )가됩니다. PCG의 순열 부분은 이것을 약간 숨기는 데 도움이 될 것이지만 통계적으로 감지 가능한 상관 관계가 있다면 실제로 놀라운 일이 아닙니다.

물론 별개의 스트림이지만, 심각한 테스트 없이는 액면 그대로 독립 스트림의 주장을 받아들이지 않을 것입니다.

[*] 예 : x[0], x[1], x[2], ... 가 x[i+1] := (m*x[i] + a) % 2**64 표준 64 비트 LCG 스트림이라고 가정합니다. 설정 y[i] := 3*x[i] % 2**64 모든 i . 그런 다음 y[i] 포함 된 LCG 스트림입니다 y[i+1] := (m*y[i] + 3*a) % 2**64 단순히 당신이 별개의 LCG 중 하나 같은 승수하지만 서로 다른 첨가제 상수 스트림을 생성 한 원래의 스트림을 확장하여 이렇게. 3 대신 다른 홀수 승수를 사용하고 전체 기간 LCG에만 관심이 있다고 가정하면 (따라서 a 는 홀수 임) 가능한 모든 그 승수로 기간 LCG.

편집 : 활용 클래스 수에 대한 잘못된 진술을 수정했습니다.

PCG 스트림에 대한 가장 철저한 공개 분석이 여기에 있다고 생각합니다. http://www.pcg-random.org/posts/critiquing-pcg-streams.html

@imneme 최종 조언을 확장 할 수 있습니까? "David Blackman과의 대응은 상수 시드 및 1,2,3,4의 스트림과 같은 상관 초기화를 사용하여"근처 "스트림을 만드는 것이 생각했던 것보다 쉬울 수 있음을 보여줍니다. 여러 스트림을 사용할 경우 동시에 지금은 스트림 ID와 시드가 구별되어야하고 서로 명백한 상관 관계가 없어야합니다. 즉, 둘 다 1,2,3,4로 만들지 말아야합니다. "

이것은 하나의 좋은 시드 (예 : 엔트로피 소스에서 파생 됨)와 스트림 ID 1,2,3,4를 갖는 것이 괜찮다고 생각한다는 것을 의미합니까? 아니면 좋은 엔트로피 소스에서 시드와 스트림 ID를 무작위로 선택해야합니까?

일부 Linux-32 (Ubuntu 18.04 / GCC 7.4) 번호

Time to produce 1,000,000 Uniforms
***************************************************************
Linux-64, GCC 7.4                      PCG64            4.18 ms
Linux-64, GCC 7.4, Forced Emulation    PCG64            5.19 ms
Win64                                  PCG64            6.63 ms
Win32                                  PCG64           45.55 ms
Linux-32, GCC 7.4                      PCG64           25.45 ms

따라서 Win-32보다 두 배 빠르지 만 느립니다. 4 개의 타이밍이 모두 동일한 기계에서 만들어졌습니다.

Other Linux-32/GCC 7.4 Timing Results
-----------------------------------------------------------------
DSFMT            6.99 ms
MT19937         13.09 ms
Xoshiro256      17.28 ms
numpy           15.89 ms

NumPy는 NumPy 1.16.4입니다. DSFMT는 32 비트 (x86)에서 우수한 성능을 제공하는 유일한 생성기입니다. 이는 모든 32 비트 사용자에 대해 명확하게 문서화되어야합니다. MT19937은 32 비트 사용자에게도 비교적 좋은 선택입니다.

따라서 레거시 용도로 MT19937 필요합니다. 포함하는 PRNG (예 : MT19937 및 단일 범용 권장 사항)에 대해 최소화하려는 경우 32 비트 성능을 사용하여 단일 범용 권장 사항을 제한 할 필요가 없습니다. 세 번째 "32 비트 용 권장"PRNG를 추가해야합니다. MT19937 은 (는) 항상 사용할 수 있으며 현재 보유하고있는 것보다 나쁘지 않습니다. 그리고 더 많은 틈새 용도로 타사 패키지를 사용할 수 있습니다.

물론, 다른 이유로 더 완전한 PRNG 세트를 포함하려는 경우 문서에 모든 종류의 특정 권장 사항을 만들 수 있습니다.

PCG의 "P"부분이 상관 관계 스트림의 잠재적 인 문제를 얼마나 완화했는지 궁금했습니다.

그래서 여기 (아마도) LCG에 대한 최악의 경우가 있습니다. 여기서 한 LCG 스트림의 가산 상수는 다른 LCG 스트림의 가산 상수의 정확한 부정입니다. 그런 다음 적절하게 끔찍한 종자를 선택하면 LCG 스트림 중 하나가 다른 하나의 정확한 부정이됩니다.

그러나 이제 두 스트림을 모두 사용하여 일련의 부동 소수점을 생성하는 경우 PCG의 순열 부분과 float64 로의 변환이 모두 도움이 될 것입니다.

다음은 순열이 얼마나 도움이되는지 보여주는 도표입니다.

그것은 하나의 그러한 스트림에서 10000 개의 플로트의 산점도이고, 부정 된 쌍둥이의 10000에 대한 것입니다. 끔찍하지는 않지만 훌륭하지는 않습니다. 명확한 인공물이 있습니다.

이것에서 무엇을 결론을 내릴지 모르겠습니다. 그것은 절대적으로 인위적인 예이며, 당신이 우연히 마주 칠 가능성은 거의 없습니다. 반면에 상관되지 않은 여러 스트림이 실제로 필요한 경우 약간의 생각과주의가 필요함을 보여줍니다.

기록을 위해 다음은 출처입니다.

import matplotlib.pyplot as plt
import numpy as np

from pcgrandom import PCG64

gen1, gen2 = PCG64(), PCG64()
multiplier, increment, state = gen1._get_core_state()
new_increment, new_state = -increment % 2**128, -state % 2**128
gen2._set_core_state((multiplier, new_increment, new_state))

xs = np.array([gen1.random() for _ in range(10**4)])
ys = np.array([gen2.random() for _ in range(10**4)])
plt.scatter(xs, ys, s=0.1)
plt.show()

PCG64는 O'Neill이 PCG-XSL-RR이라고 부르는 생성기입니다 (PCG 문서의 섹션 6.3.3). pcgrandom 패키지는 여기에서

독립 스트림을 얻는 표준 방법은 jumpahead ()를 사용하는 것이라고 생각했습니다.
"독립적 인"스트림을 얻기 위해 다시 시드하는 것은 일반적으로 위험합니다.

카운터 / 해시 생성기에는 간단한 jumpahead ()가 있습니다. PCG가 있습니까?

또한 사용자의 부탁 : 최소한 하나의 비트 스트림을 제공하십시오.
무제한 상태 공간이있는 암호화 품질.

건배,
필립

(seberg 편집 : 이메일 견적 제거)

@pbstark : 이것은 단순히 다시 시드하는 것이 아닙니다. 두 개의 기본 LCG 생성기는 실제로 구별됩니다 : x ↦ mx + a (mod 2 ^ 128) 및 x ↦ mx + b (mod 2 ^ 128) for different increments a and b. O'Neill의 PCG 논문은 LCG 증분을 변경하여 다른 스트림을 생성 할 수 있다는 아이디어를 판매합니다 (논문의 섹션 4.3.2 참조).

그러나 LCG의 단순성은 단순 선형 변환 (상수에 의한 곱셈 또는 경우에 따라 상수 추가)과 결합하여 추가 상수 _does_를 변경하면 원래 생성기에서 알 수없는 양만큼 앞당겨진다는 것을 의미합니다.

PCG를 사용하지 않는 이유가 아니며 NumPy의 새로운 메인 PRNG에 적합하지 않다고 잠시 주장하지 않습니다. 나는 사람들이 "독립적 인"랜덤 스트림의 약속에 휩싸이는 것을 원하지 않습니다. 기껏해야 PCG에 대한 설정 가능한 스트림 아이디어는 빠른 점프와 동일한 작업을 수행 할 수있는 편리한 방법과 보너스 추가 곱셈 또는 가산 변환을 제공합니다.

우리는 커뮤니티 콜에서 암호화에 대해 약간 논의했습니다. 나는 우리가 그것에 대해 조금 조심했다고 생각합니다. 좋은 생각처럼 보이지만 암호화 된 건전한 RNG를 포함하면 사용자가 실제 암호화 목적으로 사용하는지 여부를 알 수 없기 때문에 발생하는 모든 보안 문제에 대처해야합니다.

얼마나 많은 것을 포함해야하는지에 대한 메모 : 합의는 주변에 몇 개의 비트 생성기를 더 가지고있는 것이 괜찮은 경향이있었습니다 (물론 작은 문서도 좋을 것입니다). 유지 관리 부담이 너무 크지 않은 것 같습니다. 결국 케빈과 로버트가 제안하는 것은 무엇이든 우리가 할 것이라고 생각합니다.

이름 참고 : 저는 개인적으로 RNG 이름을 사용하고 사용자에게 강제로 사용하는 것을 신경 쓰지 않습니다. 유일한 단점은 코딩하는 동안 이름을 찾아야 할 수도 있다는 것입니다. 지원 중단 경고를 가능한 한 적게 표시해야합니다. 시드없이 기본 RNG에 대한 최소 노출 API를 좋아합니다.

@mdickinson , 그래프를 직접 재현하려고 시도했지만 실패했습니다. 나는이 프로그램과 함께 표준 C ++ 버전 의 코드를 사용했습니다.

#include "pcg_random.hpp"
#include <iostream>
#include <random>

int main() {
    std::random_device rdev;
    pcg_detail::pcg128_t seed = 0;
    pcg_detail::pcg128_t stream = 0;
    for (int i = 0; i < 4; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    pcg64 rng1(seed,stream);
    pcg64 rng2(-seed,-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/18446744073709551616.0 << "\t";
        std::cout << rng2()/18446744073709551616.0 << "\n";
    }
}

이것을 실행하면 (재현성을 허용하기 위해) 다음과 같이 출력됩니다.

RNG1: 47026247687942121848144207491837523525 203756742601991611962280963671468648533 41579532896305845786243518008404876432
RNG2: 47026247687942121848144207491837523525 136525624318946851501093643760299562925 52472962479578397910044896975270170620

다음 그래프를 그릴 수있는 데이터 포인트 :

내가 무엇을 다르게하고 있는지 알아낼 수 있다면 도움이 될 것입니다.

(상관 관계가 가능하다는 생각을 반박하는 것은 아닙니다. 왜냐하면 상관 관계가 가능하다는 생각을 반박하는 것이 아닙니다. 주제에 대해 별도의 코멘트를 작성할 것입니다. 그러나 그 코멘트를 써서 결과를 재현 할 수 없다는 것을 깨달았습니다. 내 평소 도구.)

@mdickinson 은 계산 된 상태에서 구멍을 하여 두 단계로 진행되는

저는 PractRand에 공급하기 위해 다양한 방식으로 구성된 여러 PCG32 스트림을 인터리브하는 간단한 드라이버 스크립트 를 master 의 numpy를 사용합니다. 적대적인 내부 상태 / 증가를 직접 입력하면 PractRand가 빠르게 실패합니다. 적대적 상태를 달성하기 위해 적대적 _seeds_ (실제로 이니셜 라이저 루틴을 통과하는)를 찾을 수있는 합리적인 방법을 찾을 수 있는지 확실하지 않습니다.

앞서 언급 한 내 블로그 게시물 에서 언급했듯이 PCG의 스트림은 SplitMix와 많은 공통점이 있습니다.

@mdickinson 의 그래프와 관련하여 카운터 기반 암호화를 포함하여 전체 상태를 시드 할 수있는 _every_ PRNG의 경우 출력이 어떤 방식 으로든 상관 관계가있는 PRNG가있는 시드를 만들 수 있습니다 (가장 쉬운 방법). 가까운 거리에있는 PRNG 상태를 만드는 것입니다. 그러나 종종 작동 방식에 대한 이해를 바탕으로 다른 작업을 수행 할 수 있습니다. 전체 상태 시드를 허용하지 않는 PRNG는이 문제를 피할 수 있지만, 그렇게하면 가능한 상태의 극히 일부에 대한 실질적인 액세스 만 제공하는 새로운 문제가 도입됩니다.

스트림을 생각하는 올바른 방법은 시드해야하는 더 임의의 상태입니다. 1,2,3과 같은 작은 값을 사용하는 것은 일반적으로 _any_ PRNG에 대한 시드 목적에 대해 나쁜 생각입니다 (모든 사람이 이러한 시드를 선호하면 해당 초기 시퀀스가 ​​과도하게 표현되기 때문입니다).

우리는 그것을 스트림이라고 부르지 않고 단지 상태라고 부를 수 있습니다. 이것이 Marsaglia가 XorWow 에서 한 counter 는 나머지 상태와 전혀 상호 작용하지 않으며 LCG와 마찬가지로 초기 값의 변형은 실제로 추가 된 상수에 해당합니다.

SplitMix, PCG 및 XorWow의 스트림은 "멍청한"스트림이라고 할 수 있습니다. 그들은 생성기의 사소한 재 매개 변수화를 구성합니다. 그러나 여기에는 가치가 있습니다. 스트림이 없으면 PRNG가 42의 흥미로운 근접 반복을 갖는다 고 가정합니다. 여기서 42는 빠르게 연속적으로 여러 번 자르고 42에 대해서만이 작업을 수행하고 다른 수는 없습니다. 어리석은 "단지 증분"또는 "단지 xor"스트림을 사용하면 실제로 이상한 반복을 42로 고정하는 것을 피할 수 있습니다. 모든 숫자는 그들이 이상하게 반복되는 스트림을 가지고 있습니다. (이러한 이유로 Xoshiro 256에서 반복되는 문제 를 복구

저는 전문가는 아니지만 암호화 측면에서 다음에서 사용할 수없는 제안 사항이 있습니다.
https://cryptography.io/en/latest/ from the Python Cryptographic Authority ?

난수 생성 에 관한 페이지에도 다음과 같이 언급되어 있습니다.

Python 3.6부터 표준 라이브러리에는 텍스트 기반 형식에 대한 특정 도우미와 함께 암호 학적으로 안전한 난수를 생성하는 데 사용할 수있는 secrets 모듈이 포함되어 있습니다.

세대에 배열을 추가하는 것 같습니다. 나는 crypotgraphic 견고성과 관련된 잠재적 유지 관리 부담이 NumPy 대 pyca와 통신하고 아마도 타사 생성기 / 플러그인에 대해 생각할 때 그만한 가치가 있고 적절한 지 궁금합니다. 나는 Nathaniel이 이전에 비슷한 우려를 언급했다고 생각합니다.

사실, 잠재적 인 dtype 리팩터링 / 향상과 같은 것들은 매우 다양한 전문화 된 새로운 애플리케이션을 유지하는 부담을 반드시 짊어지지 않고 API 인프라를 제공하도록 설계되어있는 것 같습니다.

BTW, Vigna의 PCG 비평 [ 섹션 ]에 대한 저의 응답 에서 상관 된 PRNG 상태를 고안하는 것에 대한 추가 정보도 있습니다. 제가 목격 한 것은 PCG를 사용하면 거리 기능이 있기 때문에 실제로 거리 기능으로 확인하여 인위적인 씨앗을 감지 할 수 있다는 것입니다. 거리 기능이없는 PRNG에서 사람들은 여전히 ​​잘못된 선택 (특히 시드를위한 공용 API를 우회하는 경우) 인 시드 쌍을 컨트리 션 할 수 있지만 가장 노골적인 인위도 감지 할 수있는 메커니즘이 제공되지 않습니다.

한편으로는 좋아하는 (또는 가장 좋아하지 않는) PRNG를 가져 와서 재미 있거나 끔찍한 일 (예 : 이 병리 )을 할 수 있도록 씨앗을 만들 수 있는지 생각해 보는 것은 재미 있습니다.

하지만 큰 그림을 보면 실제로 사용자가 직면 한 문제를 보는 것이 합리적이라고 생각합니다. 대부분의 사용자는 _ 모든 PRNG (과거 및 미래)에 대해 _ 32 비트 시드가 절대적으로 끔찍한 아이디어이며 어떤 PRNG가 작동하는지에 관계없이 사소한 편견을 유발한다는 사실을 인식하지 못합니다. 물론, 우리는 그것을 무시하고 대신 누군가가 Mersenne Twister를 거의 0 상태 (또는 LFSR이 전혀 작동하지 않는 모두 0 상태!)로 초기화 할 수 있었는지 또는 누군가가 할 수 있는지에 대해 걱정하는 데 시간을 할애 할 수 있습니다. Xoshiro를 11 개의 출력 공간에서 7 번 동일한 출력을 반복하거나 두 개의 유사한 PCG 스트림 등을 변환하는 지점 근처로 Xoshiro를 초기화합니다. 무작위 데이터로 시드됩니다. 이러한 전환만큼 지적으로 흥미롭고 학문적으로 흥미롭지 만, 사용자가 일반적으로 씨 뿌리기에 대해 그들이 무엇을하고 있는지 거의 알지 못한다는 사실은 로마가 불타 오르는 동안 어슬렁 거리는다는 사실을 대부분 무시하면서 그들에 대해 생각합니다.

inc=1,2,3,4 이 (가) 나쁜 생각이라면 매우 명확하게 문서화되어야한다는 뜻이 아닌가, 아니면 약간 다른 API를 가져야한다는 뜻이 아닐까요? new_generator = (Bit)Generator().independent() 조차도 (기본) 비트 생성기가이를 달성하는 좋은 방법을 제공하지 않으면 경고를 표시 할 수 있습니다.

또한 32 비트 시드가 얼마나 나쁜지에 따라 다릅니다. 동결을위한 시드를 생성하고 저장하기위한 멋진 API를 생각할 수 있습니까? 나도 몰라. "존재하지 않는 경우 고정 된 시드 캐시 파일 만들기"일 수도 있습니다.

PCG의 경우 시드-> uint64_t [2]-> splitmix64 (seed_by_array)-> uint128을 사용하면 낮고 연속적인 시드가 흩어져 있는지 확인할 수 있습니다.

PCG의 경우 시드-> uint64_t [2]-> splitmix64 (seed_by_array)-> uint128을 사용하면 낮고 연속적인 시드가 흩어져 있는지 확인할 수 있습니다.

또는 좋은 정수 해시를 사용하십시오. (그것은 bijection이어야합니다.). 싸고 짧은 것이 많이 있습니다. Multiply–XorShift 몇 라운드는 괜찮습니다.

@mdickinson 의 관점에서, 나는 그가 여전히 스트림 의존성이 작은 인위적 / 적대적 설정으로 제한된다는 약간의 설득력을 원한다고 생각합니다. 그럴 경우 적절한 관행으로 문제를 해결할 수 있습니다. 우리가 가지고있는 현재 코드에는 사용자가 현재 API에 쉽게 빠져들 수있는 몇 가지 나쁜 상태가 있습니다. seed=1 와 inc=0,1,2,... 하면 상관 관계가 생성된다는 David Blackman의 결과를 확인할 수 있습니다. 인터리브 된 PCG32 스트림 용 최신 PractRand 드라이버를 사용하여이를 입증 할 수 있습니다.

❯ ./pcg_streams.py --seed 1 --inc 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12728272447693586011,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 7009800821677620407,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x470537d5
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x470537d5
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R=  +9.6  p =  2.3e-4   mildly suspicious
  ...and 116 test result(s) without anomalies

rng=RNG_stdin32, seed=0x470537d5
length= 256 megabytes (2^28 bytes), time= 8.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-2,T)                  R= +26.1  p =  6.3e-13    FAIL           
  ...and 123 test result(s) without anomalies

./RNG_test stdin32  8.86s user 0.11s system 93% cpu 9.621 total

나는 아직 임의의 시드로 실패하지 않았지만 동일한 근접 증분을 가지고 있습니다. 내일 확인하겠습니다.

생성자에 아무것도 지정되지 않은 경우 권장되는 기본 증분을 사용하지 않는다는 것을 알 수 있습니다. 우리는 아마 그것을 고쳐야 할 것입니다. 아마도 그것은 2*inc + 1 대신 주어진 스트림 ID에서 실제 증분을 도출하는 좋은 기본 숫자 일 것입니다.

사람들이 기본 엔트로피 시드를 사용하고 저장하는 데 도움이되는 도구를 구축 할 수 있습니다. 한 가지 질문은 여러 스트림에 대한 증분을 간단하게 생성 할 수 있는지 또는 엔트로피 샘플링을 수행하고 저장해야하는지 여부입니다. 시뮬레이션의 "초기 상태"를 불투명 한 파일이 아닌 동료의 이메일에서 복사하여 붙여 넣을 수있는 단일 숫자로 인코딩 할 수있는 것이 정말 편리합니다. 상태가 128 또는 256 비트에 불과한이 작은 PRNG를 사용하면 16 진수로 로그 파일에 쉽게 인쇄 한 다음 재현하고 싶을 때 명령 줄에 복사하여 붙여 넣을 수 있습니다. 32 비트 정수보다 크지 만 관리 할 수 ​​있습니다. 모든 스트림 ID를 엔트로피 샘플링해야한다면, 그것을 잊어 버리고 모든 것을 상태 파일 어딘가에 기록해야합니다. 그것은 우리가 새로운 스트림을 동적으로 생성하려는 곳에서 논의한 일부 사용 사례를 배제 할 수 있습니다. 좋은 스트림 ID를 얻기 위해 카운터를 증가시킬 수 있다면 (카운터의 해시 등을 통해 파생 될 수 있음) 스트림 ID가 아닌 초기 시드 만 기록하면됩니다.

IIRC, secrets 모듈은 OS의 엔트로피 소스를 호출합니다.
일부 시스템에서는 나쁘고 복제 / 재현이 불가능합니다.

2019 년 5 월 29 일 수요일 오후 3:19 Tyler Reddy [email protected]
썼다 :

나는 전문가는 아니지만 암호화 측면에서 제안 된 것은
사용할 수 없음 :
Python Cryptographic Authority의 https://cryptography.io/en/latest/
https://github.com/pyca ?

난수 생성에 관한 페이지
https://cryptography.io/en/latest/random-numbers/ 도 다음과 같이 언급합니다.

Python 3.6부터 표준 라이브러리에는 비밀이 포함됩니다.
https://docs.python.org/3/library/secrets.html 모듈.
암호로 안전한 난수를 생성하는 데 사용됩니다.
텍스트 기반 형식에 대한 도우미.

세대에 배열을 추가하는 것 같습니다. 나는
crypotgraphic과 관련된 잠재적 유지 관리 부담
견고성은 그만한 가치가 있으며 NumPy 대 say에서 적절합니다.
pyca와 통신하고 타사에 대해 생각할 수 있습니다.
생성기 / 플러그인. 나다니엘이 비슷한 우려를 언급했다고 생각합니다
이전에.

실제로 잠재적 인 dtype 리팩터링 /
개선 사항은 또한 API 인프라를 제공하도록 설계되었습니다.
필연적으로 다양한 유지 관리의 부담을
전문화 된 새로운 응용 프로그램.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWKXSSTX6QI7HJ65GYTPX36O3A5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSVREXG43Z712LOP6A#issue5WWQZLOBW63LNMVWXHJK94
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWKGZMUB67VPCMFZYGTPX36O3ANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

@tylerjereddy 공격자 (그리고 여러분!)가 예측할 수없는 물리적 엔트로피 소스에서 소량의 임의 비트를 가져 오기위한 것입니다. 그것들은 모두 짧은 초기화 벡터, 논스, 키와 같은 것들에 대한 암호화에 사용됩니다. 이것들의 요점은 그것들을 재현 할 방법이 없다는 것입니다. 이것은 np.random 의 수치 시뮬레이션 목적과 상충됩니다. 이 페이지는 cryptography 패키지에서 사용할 수있는 기본 요소로 존재하고 _ 빌드 할 수있는 _ 재생산 가능 _ 암호화 보안 PRNG에 대해 이야기하지 않습니다. 그러나 _practice_에서는 효율적인 C 코드에서 이미 사용할 수있는 알고리즘, 적어도 시뮬레이션 목적으로 공식화되고 테스트 된 알고리즘을 더 잘 구현했습니다. @bashtage 는이 프레임 워크를 위해 몇 가지 를

나는 또한 @pbstark 가 제안하는 것이 암호화 기반 PRNG가 아니라는 것을 numpy 팀에게 분명히하고 싶습니다. 오히려 그는 그가 찾고있는 수학적 속성을 제공 할 _unbounded state_를 가진 것을 원합니다.

시뮬레이션을 위해 일반적으로 고려되는 대부분의 암호화 기반 PRNG는 @pbstark 가 원하는 무제한 상태를 cryptorandom 는 또한 고정 크기 256 비트 다이제스트 상태 및 고정 크기 64 비트 길이 카운터로 인해 2**(256+64) 고유 한 초기 조건에 제한됩니다. 길이 카운터를 임의의 크기로 만들어 진정으로 제한되지 않은 PRNG를 구현하는 방법을 가리킬 수 있지만 그러한 알고리즘이 게시되거나 테스트 된 적이 없습니다.

반면에, 임의의 크기의 상태를 가진 PRNG 알고리즘을 원하면 처음에 필요한 것보다 높은 것으로 고정 된 알고리즘 만 있으면 PCG의 확장 생성기 가 해당 작업에 적합합니다. 이들은 분명히 CS-PRNG가 아니지만 실제로는 필요에 따라 거대한 상태 공간을 가지려는 @pbstark 의 욕구를 충족

표준, 경계, CS-PRNG가 우리가 원할 수있는 다른 속성이 있지만, 그것들은 쉬운 기본값 인 IMO가 아닙니다.

Cryptorandom의 상태 공간은 256 비트 해시가 아닙니다. 제한이 없습니다. 그만큼
시드 상태는 임의 길이의 문자열이며 각 업데이트는 0을 추가합니다.
현재 상태로. 무제한 정수 카운터를 증가 시키면
같은 일을 수행하십시오. 처음에는 구현했지만
더 효율적인 업데이트를 허용하기 때문에 증분보다는 추가
각 상태를 처음부터 해싱하는 것보다 다이제스트 (눈에 띄는 속도 향상).

2019 년 5 월 29 일 수요일 오후 7:26 Robert Kern [email protected]
썼다 :

@tylerjereddy https://github.com/tylerjereddy 그것들은
물리적 엔트로피 소스의 소량의 임의 비트
공격자 (그리고 당신!)에게는 예측할 수 없습니다. 그들은 암호화에 사용됩니다
초기화 벡터, nonce, 키와 같은 것들은 모두 짧습니다. 그만큼
이것들의 요점은 그것들을 재현 할 방법이 없다는 것입니다.
np.random의 수치 시뮬레이션 목적과의 확률. 그 페이지는
재현 가능한 암호화 보안 PRNG에 대해 이야기하지 않습니다.
또한 존재하고 원시로부터 구축 될 수 있는 것들입니다.
암호화 패키지에서 사용할 수 있습니다. 그러나 실제로 우리는
이미 사용 가능한 알고리즘의 더 나은 구현
효율적인 C 코드, 적어도 공식화되고 테스트 된 코드
시뮬레이션 목적으로. @bashtage https://github.com/bashtage 구현
몇 가지 https://github.com/numpy/numpy/issues/13635#issuecomment-496287650
이 프레임 워크를 위해.

나는 또한 @pbstark가 무엇인지 numpy 팀에게 분명히하고 싶습니다.
https://github.com/pbstark 가 제안하는 것은 암호화 기반이 아닙니다.
PRNG. 오히려 그는 무한 상태를 가진 하나를 원합니다.
그가 찾고있는 수학적 속성.

시뮬레이션을 위해 일반적으로 고려되는 대부분의 암호화 기반 PRNG
억제 할 수없는 상태 @pbstark이없는
https://github.com/pbstark 가 원합니다. 그들은 일반적으로
유한 카운터 암호화. 그 카운터가 돌아 가면, 당신은
유한 기간. 기술적으로 그의 cryptorandom
https://statlab.github.io/cryptorandom/ 도 2 ** (256 + 64)로 제한됩니다.
고정 크기 256 비트 다이제스트 상태로 인한 고유 한 초기 조건 및
고정 크기 64 비트 길이 카운터. 그것은 아마도
길이 카운터를 만들어 진정한 제한없는 PRNG 구현
임의의 크기이지만 그러한 알고리즘이 게시되거나
테스트되었습니다.

반면에 PRNG 알고리즘을 원하면
임의의 크기 상태, 처음에 고정 된 상태
필요한 것 이상으로 PCG의 확장 발전기
http://www.pcg-random.org/party-tricks.html 이 잘 작동합니다.
직무. 이들은 분명히 CS-PRNG가 아니지만 실제로 만족할 것입니다.
@pbstark https://github.com/pbstark 의 거대한 상태 공간을 원하는 욕망
주문형. 그럼에도 불구하고 numpy에 포함하는 것은 권장하지 않습니다.

표준, 경계, CS-PRNG가 갖는 다른 속성이 있습니다.
우리가 원할 수도 있지만, IMO는 당연한 기본값이 아닙니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWLGAF6YVIWXYZ2LTT3PX43ONA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSVREXG43VMVORB4QTDN5W2ZLOG458P#Zissuement-4W2177VORBW63LNMVXHJ4K
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWLIJD3UCVY3NXCLPKDPX43ONANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

SHA-256의 온라인 업데이트가 작동하는 방식이 아닌 것 같습니다. 유지하는 상태는 업데이트를 계산할 때 추가하는 256 비트 다이제스트와 고정 크기 64 비트 길이 카운터뿐입니다. 전체 텍스트를 포함하지 않습니다. 해시가 압축됩니다. 이것이 각 바이트에서 효율적인 업데이트를 수행 할 수있는 방법입니다. 기본적으로 유한 한 동일한 내부 SHA-256 상태에 매핑되는 초기화 / 과거 이력이 많이 있습니다. 주기는 확실히 길지만 2**(256+64) 보다 길지만 확실히 존재합니다. 어떤 경우에도 가능한 초기 조건은 2**(256+64) 미만입니다 (각 텍스트 길이 0 ~ 2**64-1 에 대해 최대 2**256 내부 해시 상태를 가질 수 있습니다. 텍스트 길이가 32 바이트를 초과하면 충돌이 발생해야합니다. 데이터 구조에 더 이상 비트가 없습니다.

매우 감사합니다; 이해했습니다. 다르게 표현하겠습니다 : 상태
공간은 무한하지만 (비둘기 구멍에 의해) 많은 별개의 초기 상태가
구별 할 수없는 출력 시퀀스를 생성합니다.

2019 년 5 월 29 일 수요일 오후 8:21 Robert Kern [email protected]
썼다 :

SHA-256의 온라인 업데이트가 작동하는 방식이 아닌 것 같습니다. 상태
유지하는 것은 256 비트 다이제스트와 고정 크기 64 비트뿐입니다.
업데이트를 계산할 때 추가하는 길이 카운터입니다. 유지하지 않습니다
전체 텍스트. 해시가 압축됩니다. 그것이 효율적으로 할 수있는 방법입니다.
각 바이트에 대한 업데이트. 기본적으로 많은 초기화 / 과거가 있습니다.
유한 한 동일한 내부 SHA-256 상태에 매핑되는 이력.
주기는 확실히 길지만 2 (256 + 64) 보다 길 수도
그리고 어쨌든 2 개 미만 (256 + 64)
가능한 초기 조건 (각 텍스트 길이 0 ~ 2 64-1에 대해최대 2256 개의 내부 해시 상태를
바이트, 충돌이 있어야합니다. 아무것도 없습니다
데이터 구조에 더 많은 비트.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/13635?email_source=notifications&email_token=AANFDWO6HRJZHTVBF2TLK3LPX5B3TA5CNFSM4HPX3CHKYY3PNVWWK3TUL52HS4DFWSVREXG43VMVSY#KTDNMVW718ZLOBW63comGOD49HTVMVSY#Kissuement-NMVHTXHJW63com
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANFDWM56HCQRZXDO3BAQHDPX5B3TANCNFSM4HPX3CHA
.

-
필립 비 스타크 | 부학장, 수리 및 물리 과학 |
통계학과 교수 |
캘리포니아 대학교
버클리, CA 94720-3860 | 510-394-5077 | statistics.berkeley.edu/~stark |
뿡 빵뀨

또한 통과 할 수있는 상태가 2**(256+64) 뿐인 경우도 있습니다. 업데이트는 매번 동일한 형태를 취하기 때문에 결국 이전에 본 상태에 도달하고 알 수 없지만 유한 기간의 루프에 들어갑니다. 유한 한 수의 초기 상태이든 유한 기간이든, cryptorandom 에는 둘 다 있으며 MT19937 보다 더 작다고 생각합니다.

그 자체로 cryptorandom 의 문제라고 생각하지는 않습니다. 나는 무한한 초기 상태 세트 또는 무한한 기간을 갖는 것이 실질적인 의미에서 실제로 필요한 것이라고 확신하지 못했습니다.

나는 아직 임의의 시드로 실패하지 않았지만 동일한 근접 증분을 가지고 있습니다. 내일 확인하겠습니다.

512GiB에서 여전히 강세 :

❯ ./pcg_streams.py -i 0 |time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10843219355420032665,
            "inc": 1
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 5124747729404067061,
            "inc": 3
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xb83f7253
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 megabytes (2^27 bytes), time= 4.0 seconds
  no anomalies in 117 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 megabytes (2^28 bytes), time= 8.6 seconds
  no anomalies in 124 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 megabytes (2^29 bytes), time= 16.9 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-2,T)                  R=  -8.0  p =1-2.1e-4   mildly suspicious
  ...and 131 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 1 gigabyte (2^30 bytes), time= 33.8 seconds
  no anomalies in 141 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 2 gigabytes (2^31 bytes), time= 65.7 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+2,13-1,T)                  R=  -7.8  p =1-3.8e-4   unusual          
  ...and 147 test result(s) without anomalies

rng=RNG_stdin32, seed=0xb83f7253
length= 4 gigabytes (2^32 bytes), time= 136 seconds
  no anomalies in 156 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 8 gigabytes (2^33 bytes), time= 270 seconds
  no anomalies in 165 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 16 gigabytes (2^34 bytes), time= 516 seconds
  no anomalies in 172 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 32 gigabytes (2^35 bytes), time= 1000 seconds
  no anomalies in 180 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 64 gigabytes (2^36 bytes), time= 2036 seconds
  no anomalies in 189 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 128 gigabytes (2^37 bytes), time= 4064 seconds
  no anomalies in 196 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 256 gigabytes (2^38 bytes), time= 8561 seconds
  no anomalies in 204 test result(s)

rng=RNG_stdin32, seed=0xb83f7253
length= 512 gigabytes (2^39 bytes), time= 19249 seconds
  no anomalies in 213 test result(s)

아, 순차적으로 증가하는 스트림을 2 개 이상 수행하면 오류가 빠르게 발생합니다. 공간 주위에 퍼 뜨리기 위해 일종의 bijection을 사용하여 사용자 입력에서 실제 증분을 도출해야합니다.

❯ ./pcg_streams.py -n 3  | time ./build/RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 18394490676042343370,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 12676019050026377766,
            "inc": 2891336455
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 6957547424010412162,
            "inc": 2891336457
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0x4a9d21d1
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0x4a9d21d1
length= 128 megabytes (2^27 bytes), time= 3.2 seconds
  Test Name                         Raw       Processed     Evaluation
  DC6-9x1Bytes-1                    R= +19.4  p =  1.6e-11    FAIL           
  [Low8/32]DC6-9x1Bytes-1           R= +13.2  p =  4.6e-8    VERY SUSPICIOUS 
  ...and 115 test result(s) without anomalies

헉

내가 무엇을 다르게하고 있는지 알아낼 수 있다면 도움이 될 것입니다.

난 당신이 라인을 교체 할 필요가 있다고 생각 pcg64 rng2(-seed,-stream); 사용하여 코드에서 pcg64 rng2(-seed,-1-stream); 수 있도록, increment = 2 * stream + 1 변환. 증분의 부정은 스트림 인덱스의 비트 부정에 해당합니다. 변경하고 코드를 실행하면 이전 플롯과 매우 유사한 것을 볼 수 있습니다. (그리고 내가 변경하지 않으면 모든 것이 시각적으로 좋아 보이는지 확인합니다.)

헉

스트림을 생각하는 올바른 방법은 시드해야하는 더 임의의 상태입니다.

동의합니다. 승수 잘 선택 고정으로 64 비트 LCG에 대한 : 난 그 LCGs에 대한 매우 깨끗한 사진을 제공합니다 생각 a , 우리는 다음 크기의 상태 공간이 2^127 모두 쌍으로 구성된 (x, c) 정수 mod 2 ^ 64, 여기서 c 는 홀수 증분입니다. 상태 업데이트 함수는 next : (x, c) ↦ (ax+c, c) 이며 상태 공간을 각각 2^64 길이의 2^63 분리 주기로 나눕니다. 시딩은이 상태 공간에서 시작점을 선택하는 것입니다.

그런 다음 분석을 쉽게하고 서로 다른 스트림 간의 관계를 명확하게하는 명백한 그룹 작업이 있습니다. Z / 2^64Z 의 반전 가능한 1-d 아핀 변환 그룹은 정확히 2^127 순서를 가지며 전 이적으로 작동합니다. (또한 충실하게) 상태 공간에서 : 아핀 변환 y ↦ ey + f 는 (x, c) 쌍을 (ex + f, ec + (1-a)f) 매핑합니다. 와 그 그룹 액션 통근 next 변형 한 점이라는 고유 족 원소이므로 함수 (x, c) 다른으로 상태 공간에서 (x2, c2) , 또한 서열을지도에 의해 생성 (x, c) 를 (x2, c2) 의해 생성 된 시퀀스에 추가합니다.

TL; DR은 : 고정 된 배율을 위해 동일한 배율로 두 LCG 서열 (룩어 케이스, 또는 다른 단위로 동일한 증분 사용 여부)를 아핀 변환에 의해 관련된다. 우리가 피하려고하는 불행한 경우에, 그 아핀 변환을 추가하는 등 무섭게 간단한 일이다 2 하거나 곱하여 -1 . 일반적인 경우, 우리는 표준 통계 테스트가 두 스트림 간의 관계를 감지 할 수 없을만큼 아핀 변환이 충분히 복잡하기를 바랍니다.

@mdickinson 은 상황을 멋지게 다룹니다. PCG의 순열은 LCG 사례에서 약간 변경되지만 많이는 아닙니다. PCG 순열의 요점은 스크램블링의 양을 선택할 수 있다는 것입니다. 잘린 128 비트 LCG는 이미 BigCrush를 통과하기 때문에 pcg64 대한 순열을 선택할 때 해당 크기 LCG (XSL RR)에 대해 적당한 양의 스크램블링을 선택했습니다. 대조적으로 64 비트 LCG는 여러 통계 테스트에 빠르게 실패하므로 pcg32 은 (는) 약간 더 스크램블링을 사용하지만 여전히 PCG 논문에서 가장 강력한 순열은 아닙니다. 스레드 풀 요청 스레드에서 언급했듯이 pcg32 사용 사례에 대해 더 강력한 PCG 순열 (RXS M)을 사용하기 시작했습니다. 아직 기본값이 아니므로 해당 버전을 명시 적으로 요청해야하지만 PCG에 대한 주요 버전 범프를 수행 할 때 기본값을 전환 할 좋은 기회가 있습니다. (RXS M은 Vigna가이 크기와 David Blackman이 좋아하는 순열에서 광범위하게 테스트 한 RXS M XS의 높은 절반입니다).

니어 스트림 테스트 프로그램의 업데이트 된 버전이 pcg32 (XSH RR 및 RCS M [및 원시 기본 LCG도])에 대해 두 가지 방식을 사용하는 차이를 시각화 할 수 있습니다.

#include "pcg_random.hpp"
#include <iostream>
#include <random>

// Create a "PCG" variant with a trivial output function, just truncation

template <typename xtype, typename itype>
struct truncate_only_mixin {
    static xtype output(itype internal)
    {
        constexpr size_t bits = sizeof(itype) * 8;
        return internal >> (bits/32);
    }
};

using lcg32 = pcg_detail::setseq_base<uint32_t, uint64_t, truncate_only_mixin>;

int main() {
    std::random_device rdev;
    uint64_t seed = 0;
    uint64_t stream = 0;
    for (int i = 0; i < 2; ++i) {
        seed   <<= 32;           
        seed   |= rdev();
        stream <<= 32;           
        stream |= rdev();
    }
    lcg32 rng1(seed,stream);
    lcg32 rng2(-seed,-1-stream);
    // pcg32 rng1(seed,stream);
    // pcg32 rng2(-seed,-1-stream);
    // pcg_engines::setseq_rxs_m_64_32 rng1(seed,stream);
    // pcg_engines::setseq_rxs_m_64_32 rng2(-seed,-1-stream);
    std::cerr << "RNG1: " << rng1 << "\n";
    std::cerr << "RNG2: " << rng2 << "\n";
    std::cout.precision(17);
    for (int i = 0; i < 10000; ++i) {
        std::cout << rng1()/4294967296.0 << "\t";
        std::cout << rng2()/4294967296.0 << "\n";
    }
}

시작하기 전에 @mdickinson이 그린 그래프를 살펴 보겠습니다.하지만 순열이없는 LCG의 경우 잘림 만 있습니다.

이것은 상관 관계가있는 상태와 병리학 적 LCG를위한 것입니다. 대신 무작위로 선택된 추가 상수 (하지만 시작 값은 동일)를 사용하여 두 개의 LCG를 선택했다면 다음과 같이 표시됩니다.

PCG의 출력 함수로 이동하면 병리학적인 경우에 XSH RR을 사용하면 다음과 같이 보입니다. 위의 그래프에서 크게 개선되었지만 분명히 끔찍함을 완전히 모호하게하지는 않습니다.

그리고 이것은 동일한 기본 (나쁜 상관 관계) LCG 쌍을 가진 RXS M입니다.

그러나 이것은 내가 pcg32 대해 고민하고있는 것일뿐입니다. 성능 패널티는 적고 pcg32 은 (는) 일부 무거운 사용자가 무작위로 시드 된 pcg32 생성기를 생성하고 그로부터 수많은 숫자를 요청하는 것에 대해 걱정하는 것을 상상할 수있을만큼 충분히 작습니다. 상관 관계의 가능성이 무한하지 않으며 충분하지 않습니다. 솔직히이 신화적인 파워 유저가 처음에 pcg32 를 사용할 것이기 때문에 솔직히 두 가지 생각을 가지고 있습니다.

pcg64 의 스트림을 더 독립적으로 만드는 데 너무 신경 쓰지 않는 한 가지 이유는 다른 모든 상태를 동일하게 유지하고 스트림을 다음으로 전환하는 것이 합리적 일 수있는 사용 사례를 알지 못하기 때문입니다. 다른 것 (예 : 근처에있는 것은 고사하고 임의의 값으로). 거의 모든 PRNG의 경우 두 번째 PRNG를 만드는 올바른 방법은 새로운 엔트로피로 초기화하는 것입니다.

결론적으로, NumPy의 경우, PCG64가 256 비트 2 개의 상태를 원한다고 생각하고 (기술적으로는 스트림의 상위 비트가 무시되기 때문에 255입니다) 완료라고하는 것이 가장 합리적이라고 생각합니다. 그것은 사람들이 다른 BitGenerator가 아닌 하나의 BitGenerator에서 가질 수있는 기능이 줄어들 기 때문에 API와 관련된 문제도 피할 수 있습니다.

(하지만 32 비트 PCG 변형을 RXS M으로 전환하고 싶을 수 있습니다. C 소스의 경우 C 코드에서 RXS M을 명시 적으로 제공하지 않고 C ++에서만 사용할 수 있도록 사용 했으므로 최신 버전이 필요합니다. 강생.)

[당신이 알고 싶었던 것 이상이라면 죄송합니다! 글쎄요, 미안 해요. ;-)]

pcg64 의 스트림을 더 독립적으로 만드는 데 너무 신경 쓰지 않는 한 가지 이유는 다른 모든 상태를 동일하게 유지하고 스트림을 다음으로 전환하는 것이 합리적 일 수있는 사용 사례를 알 수 없다는 것입니다. 다른 것 (예 : 근처에있는 것은 고사하고 임의의 값으로). 거의 모든 PRNG의 경우 두 번째 PRNG를 만드는 올바른 방법은 새로운 엔트로피로 초기화하는 것입니다.

앞서 사용 사례에 대해 설명했습니다. 단일 짧은 "시드"입력 (즉, 이메일에서 명령 줄에 복사하여 붙여 넣을 수있는 크기에 대한 것)을 허용하는 확률 적 프로그램을 작성하여 프로그램의 출력을 결정적으로 만드는 강력한 UX 이유가 있습니다. @stevenjkern 은 오프라인 대화에서 자신의 소프트웨어를 검증 이라고 언급했습니다. 결과를 복제하기 위해 프로그램 실행의 _output_ 파일을 사용해야한다면 그러한 상황에서는 약간 의심스러워 보입니다. 규제 기관은 파일의 정보가 정말 정결한지 확인하기 위해 코드 (실제로 사용할 수 없을 수도 있음)에 대해 심층적으로 조사해야합니다.

이제 Python 에 N 개의 병렬 프로세스를 동적으로 회전시켜 작업의 일부를 수행 한 다음 결과를 수집하고 주 프로세스로 이동하는

N 스트림을 재현 가능하게 유도해야하는 필요성은 사람들이 현재의 MT 알고리즘으로 그것을 얻기 위해 이상한 일을 할만큼 충분히 강합니다. 나는 여러 가지 위험한 계획을 격추해야했고 PCG의 스트림이 우리가 거기에 도달하는 데 도움이되기를 바랐습니다.

2**63 / 2**127 보다 좋은 bijective 해시를 사용하여 상태를 동일하게 유지하면서 카운터 시퀀스 0,1,2,3, ...에서 증분을 유도하는 것에 대해 어떻게 생각하십니까? 그 문제를 예견하십니까? 상태를 새로운주기의 먼 부분으로 옮기기 위해 해시 된 증분과 큰 도약을 결합하는 것에 대해 어떻게 생각하십니까? 이 하위 토론을 이메일이나 다른 문제로 옮기고 다시보고 할 수 있습니다.

@rkern , PRNG에 매우 짧은 시드를 줄 수 있다는 것에 대해 기분이 좋은 것이있을 수 있지만 (PRNG에 관계없이) 끔찍한 아이디어입니다. _k_ 비트의 시드 입력을 제공 한 다음 _k_ 비트를 요구하는 경우 (즉시 또는 _j_ 비트를 먼저 건너 뛰고 [일부 임의의 _j_에 대해] 다음 _k_ 비트를 읽음), 모든 2 ^ _k_ 정수가 모두 2가 아닌 유효한 입력 임에도 불구하고 ^ _k_ 출력이 관찰 될 수 있습니다 (비트 인에서 비트 아웃으로의 함수가 이분법 (bijection) 일 수 있다는 보장이 없기 때문입니다). 예상 분포는 이항 (2 ^ k, 2 ^ -k)이며, 푸 아송 분포로 근사 할 수 있으므로 2 ^ k / e 값이 관찰되지 않습니다. 이것은 PRNG가 무엇이든 상관 없습니다. 우리가 할 수있는 것은 _k_가 빠진 것을 알아내는 것이 완전히 비현실적 일 정도로 충분히 커지는 것입니다.

예를 들어 모든 사람이 동일한 PRNG (예 : Mersenne Twister)를 사용하고 동일한 작은 집합 (예 : 10000 미만의 숫자)에서 시드를 선택하면 문제가 더 복잡해집니다. _이 일을하는 모든 사람을 위해 _ 편견. 예를 들어, 4 자리 시드를 선택한 다음 Mersenne Twister에서 합리적인 수의 숫자 (예 : 백만 미만)를 가져 왔다고 가정 해 보겠습니다. 이 상황에서 불운 한 숫자 13은 100 억 개의 출력 중 하나로 표시되지 않으며 (실제로 32 비트 정수의 약 10 %가 없음) 숫자 123580738은 다음과 같은 요소로 과대 표현됩니다. 16. 이것은 100 억 개의 32 비트 정수로 구성된 무작위 샘플에 대해 정확히 예상 할 수있는 것입니다. 그러나 모든 사람이 동일한 샘플을 사용한다면 실제 문제입니다. 모든 사람이 9 자리 시드를 선택하고 10000 개의 숫자 만 그리는 경우 정확히 유사한 문제가 발생합니다.

많은 사람들이 무언가를하고 싶어한다는 사실은 좋은 생각이 아닙니다. (단순히 사람들에게 그들이 잘못하고 있거나 잘못된 것을 원한다고 말하는 것은 괜찮다는 것을 의미하지 않습니다. 그들이 실제로 필요한 것이 무엇인지 파악해야합니다 (예 : 짧은 명령 줄 인수에서 재현 가능한 결과 — 가능하면 옳은 일은 UUID 와 작은 정수에서 시드를 허용하는 것입니다. 시드 데이터를 만들기 위해 이러한 것들을 멋지게 스크램블하는 방법에 대한 몇 가지 아이디어는 이 블로그 게시물 에서 찾을 수 있으며 randutils 로

(상당히 짧기 때문에 플레이 할 코드가 있습니다 ...)

// mtbias.cpp -- warning, uses 4GB of RAM, runs for a few minutes
// note: this is *not* showing a problem with the Mersenne Twister per se, it is
// showing a problem with simplistic seeding

#include <vector>
#include <iostream>
#include <random>
#include <cstdint>

int main() {
    std::vector<uint8_t> counts(size_t(std::mt19937::max()) + 1);
    for (size_t seed=0; seed < 10000; ++seed) {
        std::mt19937 rng(seed);
        for (uint i = 0; i < 1000000; ++i) {
            ++counts[rng()];
        }
    }
    size_t shown = 0;
    std::cout << "Never occurring: ";
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] == 0) {
            std::cout << i << ", ";
            if (++shown >= 20) {
                std::cout << "...";
                break;
            }
        }
    }
    std::cout << "\nMost overrepresented: ";
    size_t highrep_count = 0;
    size_t highrep_n = 0;
    for (size_t i = 0; i <= std::mt19937::max(); ++i) {
        if (counts[i] > highrep_count) {
            highrep_n = i;
            highrep_count = counts[i];
        }
    }
    std::cout << highrep_n << " -- repeated " << highrep_count << " times\n";
}

이전에 말했듯이 128 비트 시드는 그 목적을 위해 충분히 짧고 사람들이 올바른 작업을 수행하는 프로그램을 작성하는 데 도움이되는 도구를 구축 할 수 있습니다. 즉, 기본적으로 엔트로피 샘플링하여 출력하거나 로깅 한 다음 나중에 전달할 수 있습니다. 각 프로그램에 대한 UUID를 생성하고 실행 당 사용자가 제공 한 더 작은 시드를 혼합하는 방법도 좋습니다.

사람들이 PCG64 의 상태 부분에 대해 좋은 128 비트 시드를 어떤 방식 으로든 사용하도록 할 수 있다고 가정 해 보겠습니다. 동일한 상태에서 스트림을 파생하는 것에 대한 의견이 있습니까? 저는 단일 PCG64 스트림에서보다 전체적으로 더 많은 숫자를 그리려고하지 않습니다. 각 추첨에 대한 조정없이 다른 프로세스에서이 숫자를 그릴 수 있기를 원합니다. ad hoc 63 비트 multiply-xorshift 해시를 사용하면 인터리브 된 8192 개의 스트림에 대해 지금까지는 꽤 잘 작동하는 것 같습니다 (지금은

헉

짧게 의미하는 바를 정의하는 것이 도움이 될 수 있습니다.

저는 @rkern 이 "이메일에서 명령 줄에 복사하여 붙여 넣을 수있는 크기에 대한 내용"을

각 추첨에 대한 조정없이 다른 프로세스에서이 숫자를 그릴 수 있기를 원합니다. ad hoc 63 비트 multiply-xorshift 해시를 사용하면 인터리브 된 8192 개의 스트림에 대해 지금까지는 꽤 잘 작동하는 것 같습니다 (지금은

충분히 큰 수 ( PCG64.jumped 사용되는 2 ** 64)만큼 주를 발전시켜 단일 품질 시드를 사용하여 n 스트림을 인터리빙 해 보셨습니까? 이것은 PCG64(seed).jumped(node_id) 와 같은 것을 사용하여 클러스터에서 대규모 n 스트림을 느슨하게 조정하는 가장 간단한 방법 인 것 같습니다.

여기서 node_id 는 0,1,2, ...

인덱스와 같은 것을 사용하여 간단한 독립 스트림을 생성하는 데 정말 좋은 PRNG가 있습니까? 나는 MLFG가 할 수 있다고 믿지만 63 비트 생성기이기 때문에 이것을 좋아하지 않았다.

@bashtage , 정말 올바른 방법이 아닙니다. 올바른 방법은 시드를 취하는 것입니다. 작은 정수를 추가하려면 해시 함수를 사용하여 해시하십시오. 앞서 언급했듯이 이전에 PCG와 무관 하게 심각한 혼합 함수를 작성

이상적으로는 PCG에만 국한되지 않는 메커니즘을 원합니다. PCG가 기본 선택이 아닐 수 있으며, 그렇더라도 사람들이 모든 생성기로 비슷한 작업을 수행하기를 원합니다. 스트림이나 점프에 의존하는 여러 개의 독립적 인 PRNG를 만들기위한 계획은 필요하지 않습니다.

(죄송합니다. 잘못된 블로그 게시물에 연결했습니다. 이전 메시지를 편집했지만 이메일로 읽는 경우이 블로그 게시물에 연결하려고했습니다.)

@imneme 현재 우리가 가지고있는 모든 제너레이터는 점프를 지원합니다 (그 중 일부는 실제로 사전 유형 호출입니다). 신중하게 시드하는 것이 좋은 생각이라는 것은 의심의 여지가 없습니다. 많은 사용자가 PRNG.jumped() 호출을 사용하고 싶어 할 것입니다. 이것이 설득되어야 할 것입니까?

시딩과 관련하여 MT 생성기는 모두 작성자의 init 루틴을 사용하고 PCG는 사용자의 루틴을 사용하고 나머지는 다음과 같이 사용합니다.

seed = np.array(required_size, dtype=np.uint64)
last = 0
for i in range(len(user_seed))
    if i < len(user_seed)
        last = seed[i] = splitmix64(last ^ user_seed[i])
    else:
        last = seed[i] = splitmix64(last)

나는 이것이 개선 될 수 있다고 생각한다.

이것이 설득되어야 할 것입니까?

나는 jumped 보지 못했습니다. 기본 LCG에게는 매우 끔찍합니다.

0x96704a6bb5d2c4fb3aa645df0540268d 의 승수 M이 있다고 가정합니다. M ^ (2 ^ 64)를 계산하면 끔찍한 LCG 승수 인 0x6147671fb92252440000000000000001 를 얻습니다. 따라서 128 비트 LCG에서 2 ^ 64 번째 항목을 모두 가져 오면 끔찍할 것입니다 (하위 비트는 카운터 일뿐입니다). PCG의 표준 순열 함수는 카운터를 스크램블하는 것이 아니라 LCG의 일반 출력을 스크램블하도록 설계되었습니다.

PCG64는 현재 Practrand를 사용하여 최대 0.5 페타 바이트까지 테스트되었으며 추가 분석에 따르면 2의 거듭 제곱과 관련된 문제없이 많은 페타 바이트를 읽을 수 있습니다. 아아, 만약 당신이 2의 거대한 정확한 거듭 제곱을 앞으로 건너 뛰기 위해 앞으로 뛰어 오르면, PCG의 일반적인 (다소 겸손한) 순열은 이와 같은 근본적인 LCG 거대한 거리를 건너 뛰는 병리 적 순서를 충분히 보상 할 수 없습니다. 이 문제를 해결하기 위해 순열 강도를 높일 수 있으며, 실제로 I와 Vigna는 PCG의 표준 순열을 그렇게 할 가능성이있는 기성 정수 해시 함수와 독립적으로 비교했습니다 (결국, 그들은 SplitMix의 기초입니다. 카운터). 2014 년에 Fast Hash를 사용해 보았을 때 속도가 그렇게 좋지 않은 것 같았지만 Vigna가 최근 murmurhash를 사용했을 때 성능이 표준 PCG (!)를 능가했다고 주장했습니다.

정말로 2 ^ 64 점프를 원하면 더 강력한 출력 함수 순열로 전환해야한다고 생각합니다 (우리가 본 것처럼 저렴한 비용으로 수행 할 수 있음). 그러나 이것이 더 이상 "표준"PCG가 아니라고 생각하고 일반적인 출력 순열을 유지하려면 jumped() 가 필요할 것입니다.

(BTW, 병리학 적 점프 어 헤드는 다른 PRNG에도 적용됩니다. SplitMix는 약간의 잘못된 증가가있는 것으로 알려져 있으며 0xbd24b73a95fb84d9의 일반적인 증가 (일명 "감마")는 괜찮지 만 2 ^ 씩 증가한다고 가정하는 것이 합리적입니다. 32는 0x95fb84d900000000의 증분을 제공하는데, 이는 그다지 좋지 않습니다 .LFSR의 경우 나쁜 점프 어 헤드는 아마도 2의 거듭 제곱이 아니지만 기본 매트릭스가 병리 적으로 끝나는 점프가있을 것이라고 확신합니다. 부족한.)

적어도 PCG32 사용하면 .jumped() 사용하는 4 개의 인터리브 스트림 이 매우 빠르게 실패한다는 것을 확인할 수 있습니다.

❯ ./pcg_streams.py --jumped -n 4 | time ./RNG_test stdin32
[
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10149010587776656704,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1158608670957446464,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 10614950827847787840,
            "inc": 2891336453
        }
    },
    {
        "bit_generator": "PCG32",
        "state": {
            "state": 1624548911028577600,
            "inc": 2891336453
        }
    }
]
RNG_test using PractRand version 0.93
RNG = RNG_stdin32, seed = 0xeedd49a8
test set = normal, folding = standard (32 bit)

rng=RNG_stdin32, seed=0xeedd49a8
length= 128 megabytes (2^27 bytes), time= 2.1 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN(2+0,13-3,T)                  R= +58.7  p =  1.3e-27    FAIL !!!       
  BCFN(2+1,13-3,T)                  R= +48.0  p =  1.5e-22    FAIL !!        
  BCFN(2+2,13-3,T)                  R= +16.0  p =  2.3e-7   very suspicious  
  DC6-9x1Bytes-1                    R= +53.5  p =  1.8e-32    FAIL !!!       
  [Low8/32]DC6-9x1Bytes-1           R= +27.4  p =  1.1e-17    FAIL !         
  ...and 112 test result(s) without anomalies

이상적으로는 PCG에만 국한되지 않는 메커니즘을 원합니다. PCG가 기본 선택이 아닐 수 있으며, 그렇더라도 사람들이 모든 생성기로 비슷한 작업을 수행하기를 원합니다.

글쎄, 그것이 우리가 여기서 결정하려는 것입니다. :-) 우리는 각 알고리즘에 의해 노출 된 속성이 잘 연구되어 있다는 가정하에 각 PRNG가 제공하는 기능을 단순히 노출하는 것에 합리적으로 만족했습니다. 또한 "여기에 우리가 권장하는 기본 PRNG가 있습니다. 유용한 기능이 많이 있습니다. 다른 기능에는 없을 수 있습니다."라는 말에 합리적으로 만족합니다.

모든 알고리즘에 대해 주어진 상태 및 스트림 ID에서 새 상태를 파생하기 위해 해시를 사용하는 개념은 흥미 롭습니다. 그게 얼마나 잘 연구되었는지 아십니까? 모든 알고리즘에서 잘 작동하는지 확인하는 것은 연구 문제처럼 들립니다. 나는 "여기에 우리의 모든 PRNG에 대한 독립적 인 스트림을 도출하는 일반적인 절차가있다"라고 주장하는 것을 주저합니다. 저는 "여기에 독립적 인 스트림을 유도하기위한 공통 API가 있습니다. 각 PRNG는 알고리즘에 적합한 방식으로 구현하고 알고리즘이 제대로 지원하지 않으면 구현하지 않을 수 있습니다."에 더 만족합니다.

반면에, PractRand의 N GiB에 대해 BitGenerator 인터리브 스트림을 테스트하기에 충분한 CPU 사이클을 할당하는 것이 문제라면 그리 부담스럽지 않습니다.

모든 알고리즘에 대해 주어진 상태 및 스트림 ID에서 새 상태를 파생하기 위해 해시를 사용하는 개념은 흥미 롭습니다. 그게 얼마나 잘 연구되었는지 아십니까? 모든 알고리즘에서 잘 작동하는지 확인하는 것은 연구 문제처럼 들립니다. 나는 "여기에 우리의 모든 PRNG에 대한 독립적 인 스트림을 도출하는 일반적인 절차가있다"라고 주장하는 것을 주저합니다. 저는 "여기에 독립적 인 스트림을 유도하기위한 공통 API가 있습니다. 각 PRNG는 알고리즘에 적합한 방식으로 구현하고 알고리즘이 제대로 지원하지 않으면 구현하지 않을 수 있습니다."에 더 만족합니다.

정확히 "연구 문제"라고 부를 수 있는지는 모르겠지만 (따라서 "잘 연구 된") C ++ 11 (대부분 검증 된 진정한 오랜 기술을 사용하는 것에 관한 것이 었습니다)은 _SeedSequence_ 개념을 제공합니다 (그리고 완전히 임의의 PRNG에 시드 데이터를 제공하는 작업을 수행하는 특정 std::seed_seq 구현).

일반적으로 거의 모든 PRNG는 임의 비트로 초기화 / 시드 될 것으로 예상합니다. random.org 나오는 임의의 비트와 더 많은 알고리즘 (CS PRNG, 해시 함수 등)에서 나오는 임의의 비트에 대해 특별히 마법 같은 것은 없습니다.

모두 자체 임의 비트로 시드 된 동일한 체계의 PRNG 모음에 대해 생각하는 것은 매우 간단합니다. 우리가하는 일을 한 줄 (예 : a)에서 선택 지점 (또는 실제로 우리가 예상 할 수있는 임의의 숫자의 양에 해당하는 특정 최대 길이까지의 간격) (예 : 2 ^ 56)으로 생각할 수 있습니다. 2 ^ 255 점이있는 선). _n_ 간격을 요청하면 하나가 다른 간격과 겹칠 확률을 계산할 수 있습니다. 그것은 상당히 기본적인 확률입니다. (내가 이해하는 바와 같이) 아무도 초등 수학을 포함하는 논문에 대해 흥분하지 않기 때문에 그것에 관한 논문을 출판 할 수 있을지 확신하지 못합니다. ( @lemire 는 동의하지 않을 수 있습니다!)

[나는 당신이 일반적으로 _하지 _ 말아야하는 것은 스스로 나오는 임의의 비트로 PRNG를 시드하는 것이라고 주장한다. 너무 근친상간 느낌이 듭니다.]

맞습니다. 잘 설계된 _SeedSequence_와 같은 것을 사용하는 것이 임의의 초기 시드를 취하고 겹치지 않아야하는 알고리즘주기에서 여러 시작점을 그리는 방법이라는 것이 분명합니다. 그것이 독립적 인 스트림을 얻는 유일한 방법이라면 그렇게하세요. 이를 편리하게 만드는 것은 API 설계의 문제입니다.

내가 덜 분명한 것은 초기화 된 PRNG의 현재 상태, 스트림 ID의 해시 믹스를 사용하여주기의 새로운 상태로 점프하는 것이 얼마나 안전한지입니다. 나중에 내가 틀렸을 수도 있다고 생각했습니다). jumped() 의 실패가 보여주는 것처럼주기에서 잘 분리되는 것이 유일한 요인은 아닙니다. jumped() 는 또한 겹치지 않는 시퀀스의 먼 부분으로 보내지는 것을 보장합니다. 점프가 잘 선택되지 않은 경우 초기 부분과 매우 밀접하게 연관 될 수있는 부분 일뿐입니다. 좋은 점프인지 아닌지 알기 위해서는 각 알고리즘의 내부에 대한 지식이 필요할 수 있습니다. 우리는 분명히 PCG의 경우에는 그렇지 않았습니다.

기본적으로 PRNG를 전환 함수 및 출력 함수로 생각하면이 new_state = seed_seq(old_state||streamID) 는 우리가 한 단계에서 사용하는 또 다른 전환 함수입니다. 우리는 seed_seq 관련된 연산이 각 PRNG 알고리즘 (또는 그 역)의 전환 함수와 충분히 다른지 확인해야하며 다른 사항을 확인해야 할 수도 있습니다. 나는 말에서 내장 뭔가 사용하지 것이다 wyhash 초기화하는 wyrand . 말했듯이 PRNG 자체를 사용하여 자체 비트를 제공하고 싶지는 않습니다. 그렇기 때문에 우리의 모든 PRNG (내가 스스로 할 필요가 없었 으면하는 연구)를 확인하기 위해 약간의 연구가 필요하다고 생각합니다.

반면에 new_state = seed_seq(old_state||streamID) 는 다중 스트림에 대해 _SeedSequence_를 사용하는 것보다이 점에서 off보다 나쁘지 않을 것입니다. 두 상태를 순서대로 끌어냅니다. 그렇다면 C ++의 경험, 아마도 당신의 구현에 쉬고, 우리의 모든 알고리즘이 단일 스트림 대응 물보다 나쁘지 않다는 것을 보여주기 위해 PractRand로 몇 가지 경험적 테스트를 수행하는 것이 좋습니다.

조정이 필요없는 방식으로 PRNG를 생성하기위한 몇 가지 사용 사례가 열리기 때문에 해시 점프를 작동시키는 것이 정말 좋을 것입니다. 스트림 ID를 사용하려면 일부 통신 또는 사전 할당이 필요합니다. dask 은 (는) 과거에 이와 같은 것을 요청했습니다.

옳은 일을하기 위해 편리하게 만들 수있는 좋은 시딩에만 의존하는 좋은 대안이 있다면, 우리는 아마도 기본값 선택을위한 기준으로 설정 가능한 스트림을 제거해야 할 것입니다. 우리는 충분히 큰 상태 공간을 가진 기본 알고리즘을 원합니다.

즉, 63 비트 해시 를 사용하여 순차 스트림 ID ( range(N) )에서 PCG32 증분을 유도하는 것처럼 보입니다. 8192 개의 인터리브 스트림은 PractRand를 2TiB로 전달합니다. PCG 생성기에 대한 스트림 ID를 노출하는 경우 사람들이 다른 방법을 사용하여 독립적 인 스트림을 재현 가능하게 얻을 것을 제안하더라도이 기술을 사용하여 증분을 유도 할 수 있습니다.

내가 덜 분명한 것은 초기화 된 PRNG의 현재 상태, 스트림 ID의 해시 믹스를 사용하여주기의 새로운 상태로 점프하는 것이 얼마나 안전한지입니다. 나중에 내가 틀렸을 수도 있다고 생각했습니다).

나는 아마도 모호하게 자신을 표현했지만 아니요 , PRNG의 현재 상태를자가 재 파종에 사용해야한다고 제안하려는 의도는 없었습니다.

그러나 FWIW, SplitMix는이 작업을 수행하며 split() 작업이 수행하는 작업입니다. 그리고 나는 그것이 그것을하는 것을 좋아하지 않는다.

이것은 너무 많은 정보 일 수 있지만, SplitMix의 split() 함수에 의해 내가 왜 겁에 질 렸는지 (아마도 겁에 질 렸을 것보다 더 끔찍 했음)에 대해 조금 공유하겠습니다. 역사적으로, SplitMix와 PCG는 거의 같은시기에 독립적으로 설계되었습니다 (SplitMix는 2014 년 10 월 20 일에 게시 된 반면 pcg-random.org 는 2014 년 8 월에 출시되었으며 2014 년 9 월 5 일에 PCG 논문에 연결되었습니다. ). PCG와 SplitMix (및 Vigna의 xor shift * 및 xorshift +를 포함한 다양한 기타 PRNG — 2014 년에 출시됨) 사이에는 몇 가지 유사점이 있습니다. 모두 스크램블링 출력 함수에 의해 수정 된 상당히 단순하지 않은 상태 전환 함수를 가지고 있습니다. 내가 PCG 논문을 쓸 때, 어떤 사람들이 원하는 것은 split() 함수 였지만이를 수행하는 좋은 방법을 찾지 못했습니다. 대신 각 단계에서 왼쪽 또는 오른쪽으로 이동할 수있는 _k_ 비트 PRNG가있는 경우 _k_ 단계 내에서 이전에 있었던 상태에 도달 할 수 있어야한다는 빠른 증거를 개발하여 전체 개념을 증명했습니다. 잘못 생각했습니다. 그 관찰은 논문에 반영되지 않았습니다. 그러나 그 증거 이전에 내 생각을 숙고 한 결과, 논문의 거의 최종 초안의 각주에서 PCG의 출력이 해시 / 스크램블 / 순열이기 때문에 다소 기발하게 제안했습니다. 장난 스러움을 느끼면 자체 출력으로 발전기를 다시 시드하고 제거 할 수 있습니다. 자체 상태로 PRNG를 다시 시드하는 것이 PRNG의 오용으로 널리 알려져 있다는 점을 감안할 때 이러한 기발함이 리뷰어에게 너무 큰 위험이 될 것이라고 생각했기 때문에 최종 버전에서 제거했습니다. 사용 경험이없는 사람들에게서 볼 수있는 것입니다.

SplitMix 논문을 읽으면서 마음에 드는 것을 많이 찾았지만 split() 보고 매우 당황했습니다. 그것은 내가 기본적으로 농담으로 만 생각하고 핵심 기능으로 만들었습니다. 몇 년이 지나야 이런 종류의 작업을 할 때 어떤 일이 벌어지는 지에 대해 쓰기 시작했습니다 .

전체적인 요점은 충분한 상태 공간이 있고 SplitMix는 거의 충분하지 않은 경우 해시 함수를 통해 자체 다시 시드를 피할 수 있다는 것입니다. 나는 이것이 좋은 생각이 아니라고 생각한다. 랜덤 매핑 (이 상황에서 우리가 다루고있는 것)은 "점근 확률이 0이 아닌 경우, 함수 그래프에서 가장 높은 트리는 가장 긴주기에 뿌리를 두지 않습니다"와 같은 속성을 갖기 때문에 완전한 확신을 갖기가 어렵다고 주장합니다. 디자이너가 그러한 병리가 디자인에 존재하지 않음을 보여주기 위해 필요한 작업을 수행하지 않는 한.

재미를 위해 여기에 next() 와 split() 를 결합하는 세 가지 다른 (그리고 엄격하게 고정 된) 방법을 탐구하는 SplitMix의 작은 버전의 상태 공간 덤프가 있습니다.

Testing: SplitMix16: void advance() { rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 4, at 000043b0 after 516 steps
- state 00000050 -> new cycle 2, size 41, at 00002103 after 2 steps
- state 000000cd -> new cycle 3, size 4, at 0000681a after 6 steps
- state 00000141 -> new cycle 4, size 23, at 00004001 after 11 steps
- state 00000dee -> new cycle 5, size 7, at 00007436 after 4 steps
- state 00008000 -> new cycle 6, size 90278, at 5e5ce38c after 46472 steps
- state 00030000 -> new cycle 7, size 6572, at 12c65374 after 10187 steps
- state 00030016 -> new cycle 8, size 3286, at 65d0fc0c after 402 steps
- state 00058000 -> new cycle 9, size 17097, at 2a2951fb after 31983 steps
- state 08040000 -> new cycle 10, size 36, at 08040000 after 0 steps
- state 08040001 -> new cycle 11, size 218, at 08040740 after 360 steps
- state 08040004 -> new cycle 12, size 10, at 38c01b3d after 107 steps
- state 08040006 -> new cycle 13, size 62, at 38c013a0 after 39 steps
- state 08040009 -> new cycle 14, size 124, at 08045259 after 24 steps
- state 08040019 -> new cycle 15, size 32, at 38c06c63 after 151 steps
- state 08040059 -> new cycle 16, size 34, at 38c00217 after 17 steps
- state 08040243 -> new cycle 17, size 16, at 38c06e36 after 13 steps
- state 123c8000 -> new cycle 18, size 684, at 77d9595f after 194 steps
- state 123c8002 -> new cycle 19, size 336, at 5de8164d after 141 steps
- state 123c9535 -> new cycle 20, size 12, at 123c9535 after 0 steps
- state 139f0000 -> new cycle 21, size 545, at 743e3a31 after 474 steps
- state 139f0b35 -> new cycle 22, size 5, at 139f0b35 after 0 steps
- state 139f1b35 -> new cycle 23, size 5, at 68d3c943 after 8 steps

Cycle Summary:
- Cycle 1, Period 4, Feeders 32095
- Cycle 2, Period 41, Feeders 188
- Cycle 3, Period 4, Feeders 214
- Cycle 4, Period 23, Feeders 180
- Cycle 5, Period 7, Feeders 12
- Cycle 6, Period 90278, Feeders 1479024474
- Cycle 7, Period 6572, Feeders 102385385
- Cycle 8, Period 3286, Feeders 5280405
- Cycle 9, Period 17097, Feeders 560217399
- Cycle 10, Period 36, Feeders 413
- Cycle 11, Period 218, Feeders 51390
- Cycle 12, Period 10, Feeders 1080
- Cycle 13, Period 62, Feeders 4113
- Cycle 14, Period 124, Feeders 4809
- Cycle 15, Period 32, Feeders 2567
- Cycle 16, Period 34, Feeders 545
- Cycle 17, Period 16, Feeders 87
- Cycle 18, Period 684, Feeders 95306
- Cycle 19, Period 336, Feeders 100263
- Cycle 20, Period 12, Feeders 7
- Cycle 21, Period 545, Feeders 163239
- Cycle 22, Period 5, Feeders 12
- Cycle 23, Period 5, Feeders 34

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 36174, at 6b34fe8b after 21045 steps
- state 00000002 -> new cycle 2, size 4300, at 042a7c6b after 51287 steps
- state 0000000f -> new cycle 3, size 11050, at 0b471eb5 after 4832 steps
- state 0000001d -> new cycle 4, size 38804, at 2879c05c after 16280 steps
- state 00000020 -> new cycle 5, size 4606, at 46e0bdf6 after 7379 steps
- state 00046307 -> new cycle 6, size 137, at 0a180f87 after 89 steps
- state 00081c25 -> new cycle 7, size 16, at 177ed4d8 after 27 steps
- state 0044c604 -> new cycle 8, size 140, at 5e1f125b after 44 steps
- state 006e329f -> new cycle 9, size 18, at 006e329f after 0 steps
- state 13ebcefc -> new cycle 10, size 10, at 13ebcefc after 0 steps

Cycle Summary:
- Cycle 1, Period 36174, Feeders 975695553
- Cycle 2, Period 4300, Feeders 766130785
- Cycle 3, Period 11050, Feeders 110698235
- Cycle 4, Period 38804, Feeders 251133911
- Cycle 5, Period 4606, Feeders 43723200
- Cycle 6, Period 137, Feeders 4101
- Cycle 7, Period 16, Feeders 172
- Cycle 8, Period 140, Feeders 2310
- Cycle 9, Period 18, Feeders 124
- Cycle 10, Period 10, Feeders 2

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

Testing: SplitMix16: void advance() { rng.next(); rng = rng.split(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 40959, at 0069b555 after 49520 steps
- state 00000031 -> new cycle 2, size 1436, at 5f619520 after 2229 steps
- state 000003a4 -> new cycle 3, size 878, at 18d1cb99 after 1620 steps
- state 0000046c -> new cycle 4, size 2596, at 46ba79c0 after 1591 steps
- state 0000c6e2 -> new cycle 5, size 24, at 0212f11b after 179 steps
- state 000af7c9 -> new cycle 6, size 61, at 40684560 after 14 steps
- state 00154c16 -> new cycle 7, size 110, at 29e067ce after 12 steps
- state 0986e055 -> new cycle 8, size 4, at 2b701c82 after 7 steps
- state 09e73c93 -> new cycle 9, size 3, at 352aab83 after 1 steps
- state 19dda2c0 -> new cycle 10, size 1, at 78825f1b after 2 steps

Cycle Summary:
- Cycle 1, Period 40959, Feeders 2129209855
- Cycle 2, Period 1436, Feeders 5125630
- Cycle 3, Period 878, Feeders 7077139
- Cycle 4, Period 2596, Feeders 5997555
- Cycle 5, Period 24, Feeders 24221
- Cycle 6, Period 61, Feeders 1774
- Cycle 7, Period 110, Feeders 1372
- Cycle 8, Period 4, Feeders 23
- Cycle 9, Period 3, Feeders 4
- Cycle 10, Period 1, Feeders 3

- Histogram of indegrees of all 2147483648 nodes:
      0  829903716
      1  684575196
      2  468475086
      3  132259769
      4   32192209
      5      58402
      6      17026
      7       1982
      8        261
      9          1

Testing: SplitMix16: void advance() { rng.next(); rng.next(); rng = rng.split();}

Finding cycles...
- state 00000000 -> new cycle 1, size 55038, at 3e57af06 after 30005 steps
- state 00000005 -> new cycle 2, size 376, at 4979e8b5 after 6135 steps
- state 0000001e -> new cycle 3, size 10261, at 0cd55c94 after 1837 steps
- state 0000002d -> new cycle 4, size 3778, at 7f5f6afe after 3781 steps
- state 00000064 -> new cycle 5, size 2596, at 3bc5404b after 5124 steps
- state 0000012b -> new cycle 6, size 4210, at 525cc9f3 after 397 steps
- state 00000277 -> new cycle 7, size 1580, at 410010c8 after 1113 steps
- state 00001394 -> new cycle 8, size 916, at 7b20dfb0 after 193 steps
- state 00063c2d -> new cycle 9, size 51, at 6e92350b after 121 steps
- state 058426a6 -> new cycle 10, size 8, at 058426a6 after 0 steps
- state 0e5d412d -> new cycle 11, size 1, at 0e5d412d after 0 steps
- state 4c2556c2 -> new cycle 12, size 1, at 4c2556c2 after 0 steps

Cycle Summary:
- Cycle 1, Period 55038, Feeders 2027042770
- Cycle 2, Period 376, Feeders 28715945
- Cycle 3, Period 10261, Feeders 49621538
- Cycle 4, Period 3778, Feeders 13709744
- Cycle 5, Period 2596, Feeders 15367156
- Cycle 6, Period 4210, Feeders 10418779
- Cycle 7, Period 1580, Feeders 1782252
- Cycle 8, Period 916, Feeders 744273
- Cycle 9, Period 51, Feeders 2351
- Cycle 10, Period 8, Feeders 24
- Cycle 11, Period 1, Feeders 0
- Cycle 12, Period 1, Feeders 0

- Histogram of indegrees of all 2147483648 nodes:
      0  529334272
      1 1089077248
      2  528875520
      3     131072
      4      65536

기타

아, 좋아요. 나는 몇 년 전에 직접 그 라인에 따라 몇 가지 제안을 내놓았 기 때문에 좋은 것을 놓친 것이 두려웠다. :-)

PCG 스트림에 대한 증분을 유도하기위한 해시 접근 방식에 대한 최종 생각이 있습니까? 그것이 독립적 인 스트림을 얻기위한 주요 메커니즘인지 여부를 제쳐두십시오. 해당 기능에 대한 액세스를 완전히 제거하지 않는 한, 오용하기 쉬운 순차 스트림 ID를 방지하기 위해 우리가 원하는 것처럼 보입니다.

호기심에서 PCG64에서 두 상태가 얼마나 떨어져 있는지 알 수있는 (쉬운) 방법이 있습니까?

예, 공개하지는 않지만 http://www.pcg-random.org/useful-features.html#distance

호기심에서 PCG64에서 두 상태가 얼마나 떨어져 있는지 알 수있는 (쉬운) 방법이 있습니까?

예, 공개하지는 않지만 http://www.pcg-random.org/useful-features.html#distance

C ++ 소스 에서 distance 함수 는 스트림 간의 거리를 알려 주어 가장 가까운 접근 지점을 제공합니다 (스트림 간의 유일한 차이점은 추가 상수 임).

덧붙여서, 기본 LCG의 경우 거리를 사용하여 위치와의 상관 관계를 파악할 수 있습니다. 짧은 거리는 분명히 나쁘지만 (그리고 PRNG에 전혀 나쁘다), 1 비트 세트 만있는 거리도 좋지 않습니다. 따라서 다음과 같이 2 ^ 64 ( 0x10000000000000000 )로 점프합니다. .jumped 은 (는) 나쁜 생각입니다. 내 PCG 할 일 목록에는 두 상태 사이의 거리를보고 거리가 무작위로 보이는지 (해밍 가중치 등을 통해)를 알려주는 " independence_score "함수를 작성하고 있습니다. 이상적으로는 비트는 0과 1이되고 자유롭게 흩어집니다).

PCG64로 _keep_ jumped 하는 한 가지 방법은 n * 0x10000000000000000 만큼 점프하는 대신 n * 0x9e3779b97f4a7c150000000000000000 만큼 점프하는 것입니다 (128 비트로 잘림). 이렇게하면 기본 LCG에 대한 병리학 적이 지 않고 원하는 모든 일반적인 속성 ( .jumped(3).jumped(5) == .jumped(8) )을 얻을 수 있습니다.

(저는 또한 " 0x10000000000000000 전진하지 마십시오"라는 말이 " 잘, 그렇게 응답하지 마십시오 "라는 것을 independence_score 가 존재할 수 있다는 점

PCG 스트림에 대한 증분을 유도하기위한 해시 접근 방식에 대한 최종 생각이 있습니까? 그것이 독립적 인 스트림을 얻기위한 주요 메커니즘인지 여부를 제쳐두십시오. 해당 기능에 대한 액세스를 완전히 제거하지 않는 한, 오용하기 쉬운 순차 스트림 ID를 방지하기 위해 우리가 원하는 것처럼 보입니다.

Murmur3 믹서 를 사용 0x9e3779b97f4a7c15f39cc0605cedc835 (ϕ의 분수 부분)을 좋아하지만 0xb7e151628aed2a6abf7158809cf4f3c7 (e의 분수 부분)도 괜찮거나 _any_ 임의의 숫자입니다.)

BigCrush와 PractRand를 통과 한 가장 빠르고 간단한 wyhash (https://github.com/wangyi-fudan/wyhash)를 추천합니다. c 코드는 다음과 같이 간단합니다.

inline  uint64_t    wyrand(uint64_t *seed){    
    *seed+=0xa0761d6478bd642full;    
    __uint128_t t=(__uint128_t)(*seed^0xe7037ed1a0b428dbull)*(*seed);    
    return  (t>>64)^t;    
}

@ wangyi-fudan, 나는 이것이 bijection이라고 확신 할 수 없습니다.

내 제한된 지식에 대해 죄송합니다. 왜 PRNG에 bijection이 필요하거나 선호됩니까?
몇 가지 설명을 주시면 감사하겠습니다 :-) @imneme

@ wangyi-fudan, 64 비트 정수에서 64 비트 정수로의 해시 함수가 이등분 (즉, 일대일 함수)이 아니면 일부 결과는 두 번 이상 생성되고 일부는 전혀 생성되지 않습니다. 그것은 일종의 편견입니다.

네가 무슨 말을 하려는지 알 겠어. 그러나 64 비트 난수 생성기 R의 경우 1.2 * 2 ^ 32 난수 (http://mathworld.wolfram.com/BirthdayAttack.html) 이후에 한 번의 충돌이 예상됩니다. 2 ^ 64 개의 난수로 충돌이 많은 것은 당연합니다. 충돌은 자연 스럽지만 bijection은 자연스럽지 않습니다. 도박 테이블 (예 : 3 비트 PRNG)이 8 개의 트레일 내에서 0 값을 갖는다 고 판단되면 0이 아닌 5 개를 관찰 한 후 감히 0에 큰 베팅을 할 것입니다.

@ wangyi-fudan,이 맥락에서 우리는 1,2,3과 같은 스트림이 더 무작위로 보이는 (일명 더 정상적)이되도록 스트림 ID를 퍼 뮤팅하는 방법에 대해 이야기했습니다. 이 과정에서 충돌에는 미덕이 없습니다.

일반적으로 PRNG의 경우 임의 매핑을 기반으로하는 PRNG와 임의의 가역 매핑 (일대일 함수)을 기반으로하는 PRNG의 차이점을 읽어야합니다. 나는 그것에 대해 썼지 만 다른 사람들도 있습니다. 작은 크기, 임의 매핑을 기반으로 한 PRNG는 다른 기술을 기반으로 한 것보다 편향을 보이고 더 빨리 실패합니다. 큰 크기에서는 모든 종류의 결함을 감지하기가 더 어려울 수 있습니다.

_n_ 간격을 요청하면 하나가 다른 간격과 겹칠 확률을 계산할 수 있습니다. 그것은 상당히 기본적인 확률입니다. (내가 이해하는 바와 같이) 아무도 초등 수학을 포함하는 논문에 대해 흥분하지 않기 때문에 그것에 관한 논문을 출판 할 수 있을지 확신하지 못합니다.

나는 당신이 Pierre L' Ecuyer가되어야한다고 생각합니다. ;-) 15 페이지

예, 그가 기본을 설명하면 괜찮은 것으로 간주됩니다!

@rkern @imneme 단순성은 소프트웨어와 수학 모두에서 기능입니다. 어떤 사람들이 단순한 작업에 감명을받지 않는다는 것을 모순 된 증거로 간주해서는 안됩니다.

@lemire : 컴퓨터 과학자를 비판하는 방법 _이라는 많은 진실이 있다고 생각하는 유머 작품이 있습니다. 이 작품의 기본 아이디어는 이론가는 정교함을 선호하고 실험가는 단순함을 선호한다는 것입니다. 따라서 청중이 실험 주의자라면 단순함에 기뻐할 것이지만 청중이 이론가 중 한 명이라면 그다지 많지 않습니다.

기본 BitGenerator 는 PCG64 입니다. 사려 깊은 기여에 감사드립니다. 그리고 체력!

이 스레드에서 많은 영감을 받아보고 할 뉴스가 있습니다.

배경

여러 척도에서 pcg64 은 꽤 좋습니다. 예를 들어, 통계적 품질의 일반적인 측정 하에서 깨끗한 건강 진단서를 얻습니다. 다양한 방법으로 테스트되었습니다. 가장 최근에는 PractRand를 사용하여 0.5 페타 바이트까지 실행했습니다. 일반적인 사용 사례에서 잘 작동합니다.

그러나이 실에서 나온 병리학은 저와 잘 어울리지 않았습니다. 물론, " 글쎄요, 그렇게 생각하지 마세요 "라고 말할 수 있지만 범용 PRNG의 요점은 견고해야한다는 것입니다. 더 잘하고 싶었어요 ...

그래서 약 25 일 전에 저는 PCG 제품군의 새로운 구성원을 디자인하는 것에 대해 생각하기 시작했습니다.

골

내 목표는 현재 pcg64 변형을 대체 할 수있는 새로운 PCG 가족 구성원을 설계하는 것이 었습니다. 이와 같이 :

• 출력 함수는 XSL RR보다 더 많은 비트를 스크램블해야합니다 (이렇게하면이 스레드에서 발생한 문제를 피할 수 있기 때문입니다).
• 성능은 현재 pcg64 보다 빠르거나 빠릅니다.
• 디자인은 PCG 방식이어야합니다 (즉, 사소하게 예측할 수 없어야하므로 출력 함수 작업의 _any_를 쉽게 취소 할 수 없습니다).

항상 그렇듯이 가능한 한 빨리 최상의 품질을 얻으려고 노력할 때 절충안이 있습니다. 속도에 대해 전혀 신경 쓰지 않았다면 출력 기능에 더 많은 단계를 추가하여 더 심하게 스크램블 된 출력을 생성 할 수 있었지만 PCG의 요점은 기본 LCG가 "거의 충분"했기 때문에 필요하지 않았다는 것입니다. 카운터가 1 씩 증가하는 것과 같이 많은 노력을 기울여야합니다.

스포일러

성공을보고하게되어 기쁩니다! 약 25 일 전에 처음 생각했을 때 실제로 휴가 중이었습니다. 10 일 전쯤 돌아 왔을 때 제가 가지고 있던 아이디어를 시도해 보았고 잘 작동했다는 사실을 알게되어 기뻤습니다. 이후 시간은 대부분 다양한 종류의 테스트에 사용되었습니다. 어제는 C ++ 버전의 PCG에 코드를 넣을 만큼 만족 스러웠습니다. 작은 크기의 테스트는 XSL RR보다 훨씬 낫고 RXS M과 경쟁하지만 실제로는 더 큰 크기에서 빛납니다. 다른 모든 목표도 충족합니다.

세부

FWIW에서 새로운 출력 함수는 다음과 같습니다 (64 비트 출력의 경우).

uint64_t output(__uint128_t internal)
{
    uint64_t hi = internal >> 64;
    uint64_t lo = internal;

    lo |= 1;
    hi ^= hi >> 32;
    hi *= 0xda942042e4dd58b5ULL;
    hi ^= hi >> 48;
    hi *= lo;
    return hi;
}

이 출력 함수는 널리 사용되는 xorshift-multiply에서 영감을 얻었습니다. 승수의 선택은 (a) 매직 상수의 수를 낮추고 (b) 순열이 취소되는 것을 방지하고 (하위 비트에 대한 액세스 권한이없는 경우) 전체 "무작위 화"를 제공하는 것입니다. PCG 출력 기능이 일반적으로 갖는 자체 품질.

기타 변경 사항

또한 0xda942042e4dd58b5 이이 PRNG (및 모든 cm_ 접두사가있는 128 비트 상태 PCG 생성기)에 대한 LCG 승수 인 경우입니다. 0x2360ed051fc65da44385df649fccf645 사용하는 pcg64 와 비교하면이 상수는 실제로 스펙트럼 테스트 속성 측면에서 상당히 좋지만 128 비트 × 64 비트가보다 쉽기 때문에 곱하는 것이 더 저렴합니다. 128 비트 × 128 비트. 저는이 LCG 상수를 몇 년 동안 문제없이 사용해 왔습니다. 저렴한 승수 변형을 사용할 때 명령 수준의 병렬 처리를 높이기 위해 반복 후 상태가 아닌 반복 전 상태에서 출력 함수를 실행합니다.

테스팅

철저히 테스트 (PractRand 및 TestU01)했으며 만족합니다. 테스트에는이 스레드에 설명 된 시나리오가 포함되었습니다 (예 : 갱 제너레이터를 순차적 인 스팀으로 사용하거나 2 ^ 64로 진행하고 출력을 인터리빙 — 문제없이 4 개의 갱과 8192 개의 갱을 8TB까지 테스트했습니다. 하천과 그 반대편 땅으로).

속도

속도 테스트와 벤치 마크에 대해 자세히 설명 할 수 있습니다. 특정 벤치 마크에서 하나의 PRNG가 다른 PRNG보다 빠르게 실행되는지 여부에 영향을 미치는 모든 종류의 요인이 있지만 전반적으로이 변형은 종종 약간 더 빠르며, 때로는 훨씬 더 빠르며, 때로는 약간 느려진 것 같습니다. 컴파일러 및 응용 프로그램과 같은 요소는 벤치 마크 변동성에 훨씬 더 큰 영향을 미칩니다.

유효성

C ++ 헤더 사용자는이 새 패밀리 구성원 _now_에 pcg_engines::cm_setseq_dxsm_128_64 로 액세스 할 수 있습니다. 앞으로 언젠가는 pcg64 을 pcg_engines::setseq_xsl_rr_128_64 에서이 새로운 체계로 전환 할 것입니다. 나의 현재 계획은 이번 여름에 PCG 2.0 버전 범프의 일부로 그렇게하는 것입니다.

공식 발표

전반적으로 저는이 새로운 가족 구성원에 대해 매우 만족하며 여름 후반에이 스레드를 참조 할 수있는 더 자세한 블로그 게시물이있을 것입니다.

귀하의 선택 ...

물론 이것으로 무엇을해야하는지 알아 내야합니다. 당신이 그것을 사용하든 안하든간에, 나는 그것이 당신의 속도 벤치 마크에서 더 나은지 나쁜지 실제로 매우 궁금합니다.

@imneme 빠른 전체 64 비트 멀티 플라이어가 필요합니까? (x64에서는 초고속이지만 일부 약한 아키텍처에서는 약간 느립니다.)

@lemire : 128 비트 × 64 비트 곱하기, 내부적으로 x86에서 두 개의 곱하기 명령어 (하위 비트에서는 64 비트 × 64 비트 → 128 비트 결과, 64 비트 × 64)로 수행됩니다. -비트 상위 비트. 두 곱셈이 병렬로 발생할 수 있으며 두 결과를 더해야합니다.)

여전히 128 비트 × 128 비트보다 낫습니다. 얼마나 더 나은지는 그 순간에 명령 스케줄링이 얼마나 잘 진행되는지에 달려 있습니다.

ARM에서는 64 비트 × 64 비트 → 128 비트 결과가 실제로 두 개의 명령어라는 것이 맞습니다.

(물론 두 개의 64 비트 LCG를 함께 묶어 혼합하는 것은 전적으로 가능합니다. 존재할 수 있고 잘 작동 할 모든 PRNG의 공간은 상당히 큽니다.)

프레임 워크의 빠르고 더러운 구현 은 최소한 64 비트 Linux에서 약간의 성능 향상을 제안합니다.

Time to produce 1,000,000 64-bit unsigned integers
************************************************************
MT19937      5.42 ms
PCG64        2.59 ms
PCG64DXSM    2.41 ms
Philox       4.37 ms
SFC64        2.07 ms
numpy        5.41 ms
dtype: object

64-bit unsigned integers per second
************************************************************
MT19937      184.39 million
PCG64        386.01 million
PCG64DXSM    415.02 million
Philox       228.88 million
SFC64        483.94 million
numpy        184.79 million
dtype: object

나는 적어도이 맥락에서 그것이 범프를주는 미리 반복 된 상태에서 출력되고 있다고 생각합니다. 처음에는 생략했고 기본적으로 PCG64 1.0과 동일한 성능을 얻었습니다. 진정한 승리는 128 비트 에뮬레이션 아래에있을 것입니다.하지만 저는 그것을 작성하지 않았고 중요한 플랫폼에서 그것을 테스트 할 좋은 방법이 없습니다.

@imneme 라는 진짜 질문은 1.0 알고리즘을 구현하는 numpy.random.PCG64 라는 이름으로 얼마나 짜증나게 될까요? 출시가 임박하고 이미 지연되었으므로 지금은 알고리즘을 변경하지 않겠습니다. 32 비트 플랫폼의 성능이 특히 좋으면 다음 릴리스에서 PCG64DXSM 를 추가하고 몇 번의 릴리스에서 기본값을 다시 고려할 수 있습니다.

당신의 선택입니다!

1.0 버전의 PCG64 배송에 문제가 없습니다. 다른 많은 사람들이 그 변형을 사용했습니다.

DXSM 변형은이 스레드에서 발생한 엣지 케이스 사용 문제를 피할 수있는 장점이 있다고 생각합니다 (결국 존재하는 이유), 반면에 늦었다는 단점이 있습니다. 그 파티. 한 달도 안 된 PRNG를 사용자에게 제공하는 것은 매우 무모한 것처럼 보일 수도 있습니다 (더 오랜 시간 테스트를 거친 PCG 변형과 동일한 아이디어를 기반으로하지만).

(즉, 그것이 _my_ 선택 이었다면, 가능한 무모함의 비난에도 불구하고, 아마도 새 제품을 배송 할 것입니다. Numpy에서 그것을 시작하고 실행하는 데 걸리는 지연은 매우 적다고 생각합니다. 그리고 위험은 매우 낮습니다. 이미 BigCrush로 철저히 테스트하고 PractRand로 16TB (크기 [스트림 없음, 32 비트 출력]의 1/4 인 cm_mcg_dxsm_64_32 포함)로 테스트했으며 1 주일 이내에 32TB에 도달 할 가능성이 높습니다. .)

[공연이 조금 나아진 것을 기뻐. 5 년 전, 사전 반복 상태를 사용하는 것은 128 비트 승수를 사용하는 128 비트 크기에 대한 비관적이었습니다. 하지만 그때는 내가 사용하고 있던 벤치 마크와 함께 테스트하고 있던 기계에서였습니다.]

2.0 변형을 참조하기 위해 해당 이름을 사용할 때 1.0 변형에 PCG64 라는 이름을 사용하는 것에 대해 더 많이 의미했습니다.

@rkern 이름 지정 문제인 경우 PCG64DXSM과 PCG64는 이들을 멋지게 구분합니다.

numpy에게는 확실히. @imneme 가 C ++ 버전에서 해당 이름으로 2.0 변형을 홍보 할 때 1.0 구현의 이름을 PCG64 지정하지 않는 것을 선호하는지 궁금합니다. 나는 이름이 느슨하다는 것은 일부 사람들이 numpy의 PCG64 테스트하고 2.0 버전에 대해 pcg-random.org에서 제기 할 주장과 비교할 수 있다는 사실에 민감합니다. Bob Jenkin의 PRNG에 대한 모든 대화를 참조하십시오.

PCG 논문의 섹션 6.3에서 다음과 같이 말합니다.

또한 생성기가 수행하는 순열에 따라 니모닉 이름이 표시되지만 PCG 라이브러리 사용자는 이러한 니모닉으로 패밀리 구성원을 거의 선택하지 않아야합니다. 라이브러리는 기본 구현이 아닌 속성을 기반으로 명명 된 생성기를 제공합니다 (예 : 고유 스트림이있는 범용 32 비트 생성기의 경우 pcg32_unique). 이렇게하면 더 나은 성과를내는 미래의 가족 구성원이 발견되고 추가 될 때 (다른 사람의 발견으로 인해) 사용자가 원활하게 전환 할 수 있습니다.

그리고 C 및 C ++ 라이브러리는 이러한 방식으로 구성됩니다. 도서관은

• 순열의 이름, 작동하는 비트 크기 및 기본 LCG의 특성을 통해 특정 제품군 구성원을 선택할 수있는 저수준 인터페이스
• 미리 선택된 하위 수준 가족 구성원에 연결하는 pcg64 와 같은 편리한 별칭을 제공하는 상위 수준 인터페이스입니다.

이러한 방식으로 새로운 가족 구성원을 가리 키도록 별칭을 업데이트 할 수 있지만 이전 결과를 정확하게 재현하려는 사용자는 여전히 하위 수준 인터페이스를 사용하여 이전에 편리한 최고 사용자가 도달 할 수 있었던 가족 구성원을 선택할 수 있습니다. 수준 별칭.

PCG64 라는 PRNG를 배송하려는 경우 문서에서 특정 PCG 변형이 무엇인지, 즉 어떤 가족 구성원이 낮은 지에 해당하는지 말하는 것으로 충분하다고 말할 수 있습니다. -레벨 C 또는 C ++ 라이브러리 인터페이스.

기본 생성기는 https://github.com/numpy/numpy/pull/13840 에서 np.random.default_gen() 로 구현됩니다 . (향후 참조를 위해 @rkern , PR을 명시 적으로 호출하는 것이 좋을 것입니다.

하나의 사소한 nit : 대신 np.random.default_generator() 라고 부르는 것은 어떨까요? gen 이 너무 짧거나 분명하지 않다고 느낍니다. 다른 사람들이 어떻게 생각하는지 궁금합니다.

대신이 np.random.default_generator ()를 호출하는 것은 어떻습니까?

저도 같은 생각을했는데, np.random.default_generator() 가 긴 쪽의 머리카락이라서 default_rng 연주했습니다.

같은 I를 👍 default_rng 보다 나은 default_gen 도. 나는 여전히 default_generator 쪽으로 기울 겠지만 이들 중 하나에 만족할 것입니다.

: +1 : default_rng() .