@brtzsnr 제안 프로세스 단계에 설명된 대로 이 문서를 제안 리포지토리에 제출해야 합니까?

템플릿에 따라 이미 마크다운되어 있으므로 design/18616-bit-twiddling.md(또는 무엇이든) 파일을 생성하는 CL에 복사하여 붙여넣기가 쉬워야 합니다.

@cespare from https://github.com/golang/proposal "저자가 디자인 문서를 작성하고 싶다면 작성할 수 있습니다." 디자인 문서로 시작했는데, 제출해야 한다는 강한 느낌이 든다면 전 괜찮습니다.

나는 이것으로 괜찮을 것입니다. 많은 알고리즘 라이브러리에서 사용되는 충분한 기능이며 수학/비트는 적절한 장소처럼 보입니다.

(예를 들어, math/big은 nlz(== clz)도 구현합니다.)

아마도 이름에 대해 약간의 자전거 흘리기가있을 것입니다. 나는 함수가 무엇을 하는 것보다 반환하는 것을 말하는 것을 선호합니다. 이는 차례로 더 짧은 이름으로 이어질 수 있습니다. 예를 들어:

bits.TrailingZeros64(x) 아닌 bits.CountTrailingZeros64(x)

기타 등등.

제안은 매우 명확하고 최소한으로 보입니다. 디자인 문서는 너무 과한 것 같습니다. 이 시점에서 CL이 더 적절할 것 같습니다.

(이것은 API 및 기본 구현이 포함된 CL입니다. - 설계 문서 대신 토론을 위한 것입니다. 이 제안을 수락할지 여부를 결정해야 합니다.)

@brtzsnr 은 이미 디자인 문서를 작성했습니다. 문제 설명에 있으며 템플릿을 따릅니다. 이러한 문서를 한 위치에 모두 보관하는 데는 어느 정도 가치가 있다고 생각했습니다.

하드웨어 지원 테이블에 나열된 마지막 아치는 "BSWAP"입니다. 오타가 있습니까?

작성해 주셔서 감사합니다.

ctz 및 clz에 대한 문서 문자열은 0을 전달할 때 결과를 지정해야 합니다.

나는 또한 CountTrailingZeros32보다 TrailingZeros32를 선호합니다. 나는 또한 Ctz32에 만족할 것입니다. 간결하고 대부분의 사람들에게 친숙하며 나머지는 쉽게 구글링할 수 있습니다.

제안해 주셔서 감사합니다.
나는 우리가 지침에만 집중하는 대신 사용에 집중하고 싶다고 덧붙이고 싶습니다. 예를 들어 @dr2chase 는 컴파일러/어셈블러에 여러 log2 함수가 있음을 발견했습니다. CLZ에 가깝지만 동일하지는 않습니다. 이와 같은 기능은 아마도 비트 트위들링 패키지에도 있을 것입니다. 또한 이러한 지침과 관련이 없는 유용한 기능을 포함할 수도 있습니다.

다음으로 정의된 모든 비트 트위들링 프리미티브에 대한 패키지를 제공하는 것은 어떻습니까?
해커의 기쁨?

패키지를 디자인할 때 기능이
내재화될 수도 있고 그렇지 않을 수도 있습니다. 최적화는 나중에 발생할 수 있습니다. 그건,
하위 수준 구현이 상위 수준 패키지를 제어하도록 허용하지 마십시오.
상호 작용. 우리는 그들 중 일부가 할 수 없더라도 좋은 패키지 인터페이스를 원합니다.
단일 명령어에 매핑됩니다.

@minux , 다행스럽게도 지금까지 내가 필요로 했던 모든

Hacker's Delight를 따르면 이름에 대해 논쟁하느라 시간을 낭비할 필요가 없다는 장점이 있습니다.

다음을 추가하고 싶습니다.

ReverseBits(uint32 및 uint64용)
RotateLeft/Right(2교대로 인라인으로 확장할 수 있지만 컴파일러는
시프트 범위 문제로 인해 항상 변환을 수행할 수는 없음)

더하기와 빼기의 두 가지 결과 형태도 될까요? 예

func AddUint32(x, y, carryin uint32) (carryout, sum uint32) // carryin은 반드시
0 또는 1이 됩니다.
uint64도 마찬가지입니다.

그리고 SqrtInt.

내 제안 중 많은 부분을 단일 명령으로 구현할 수 없지만
이것이 요점입니다. 우리는 단순한 패키지가 아니라 약간의 엉뚱한 패키지를 원합니다.
인트라식스 ​​패키지. 하드웨어가 높은 수준의 패키지를 제한하지 않도록 하십시오.
상호 작용.

이와 관련하여 덧셈/곱셈이 오버플로되는지 여부를 확인하는 함수입니다.

관련 데이터 포인트: 더 빠른 cgo를 위해 제출된 다양한 문제가 있습니다. 그러한 예(제안 #16051)에서 bsr/ctz/etc의 빠른 구현이 있습니다. 아마도 go를 작성하는 사람들이 cgo를 사용하도록 유혹되는 일련의 사용 사례에서 칩을 제거하는 것으로 언급되었습니다.

@aclements가 2016년 7월 1일에 댓글을

@eloff , 지원되는 경우 내장 함수로 컴파일되는 popcount 및 bsr과 같은 기능을 추가하기 위한 논의(내 지식에 대한 구체적인 제안은 없음)가 있습니다(예: 오늘날의 math.Sqrt). 1.7에서는 런타임에서 이것을 시도하고 있으며 이제 amd64 SSA에서 사용할 수 있는 ctz 내장 기능이 있습니다. 분명히 그것이 전체 문제를 해결하지는 못하지만 낮은 오버헤드 컨텍스트에서 cgo를 사용해야 하는 또 하나의 이유를 제거할 것입니다.

많은 사람들(저 포함)이 성능 때문에 끌리므로 비트 트위들링에 대한 현재 제안과 같은 것이 도움이 될 것입니다. (그리고 예, cgo도 이제 1.8에서 더 빨라졌습니다. 이것도 좋습니다.)

RotateLeft/Right(2교대로 인라인으로 확장할 수 있지만 컴파일러는
시프트 범위 문제로 인해 항상 변환을 수행할 수는 없음)

@minux 문제가 무엇인지 자세히

@brtzsnr : Minux가 말하는 것은 (x << k) | (x >> (64-k)) 를 쓸 때 0 <= k < 64 사용하고 있다는 것을 알지만 컴파일러가 마음을 읽을 수 없다는 것입니다. 코드에서 파생됩니다. 우리에게 기능이 있다면

func leftRot(x uint64, k uint) uint64 {
   k &= 63
   return (x << k) | (x >> (64-k))
}

그런 다음 컴파일러가 k 범위가 제한되어 있음을 알고 있는지 (&63을 통해) 확인할 수 있습니다.
따라서 컴파일러가 입력이 제한되어 있음을 증명할 수 없으면 추가 AND가 필요합니다. 회전 어셈블리를 전혀 생성하지 않는 것보다 낫습니다.

2017년 1월 13일 금요일 오후 10시 37분, Keith Randall [email protected]
썼다:

@brtzsnr https://github.com/brtzsnr : Minux가 무엇을 말하는 것 같아요
(x << k) | (x >> (64-k)), 0을 사용하고 있다는 것을 알고 있습니다.
<= k < 64, 그러나 컴파일러는 당신의 마음을 읽을 수 없으며 분명히
코드에서 파생됩니다. 우리에게 기능이 있다면

func leftRot(x uint64, k uint) uint64 {
k &= 63
반환 (x << k) | (x >> (64-k))
}

그런 다음 컴파일러가 범위를 알고 있는지 (&63을 통해) 확인할 수 있습니다.
k의 경계가 있습니다.
따라서 컴파일러가 입력이 제한되어 있음을 증명할 수 없으면 추가 작업이 필요합니다.
그리고. 회전 어셈블리를 전혀 생성하지 않는 것보다 낫습니다.

오른쪽. RotateLeft 및 RotateRight 함수를 정의하면 공식적으로 다음을 수행할 수 있습니다.
왼쪽/오른쪽으로 k 비트 회전 기능을 정의합니다(k가 무엇이든 상관없음). 이것은
시프트 작업이 정의되는 방식과 유사합니다. 그리고 이 정의 또한
실제 회전 명령에 멋지게 매핑됩니다(교대와 달리
직관적인 정의는 특정 아키텍처에 대한 비교가 필요합니다.

blosc 압축 라이브러리에서 사용하는 바이트 및 비트 셔플링(및 언셔플링) 기능은 어떻습니까? 슬라이드 (셔플은 슬라이드 17부터 시작됨). 이러한 기능은 SSE2/AVX2 가속이 가능합니다.

2017년 1월 13일 금요일 오후 11시 24분에 opennota [email protected]에서 다음과 같이 썼습니다.

blosc에서 사용하는 바이트 및 비트 셔플링 기능은 어떻습니까?
https://github.com/Blosc/c-blosc 압축 라이브러리? 슬라이드
http://www.slideshare.net/PyData/blosc-py-data-2014 (셔플
슬라이드 17)부터 시작합니다. 이러한 기능은 SSE2/AVX2 가속이 가능합니다.

SIMD는 더 큰 문제이며 이 패키지의 범위를 벗어납니다. 이것의

17373.

현재 제안된 기능은 Go 기본 구현이 최적보다 훨씬 크고 불균형적으로 더 비쌉니다. 반면에 회전은 컴파일러가 인식할 수 있는 방식으로 인라인으로 작성하기 쉽습니다.

@minux 및 다른 모든 사람: 회전된 비트 수가 일정하지 않은 경우 왼쪽/오른쪽 회전이 사용되는 위치를 알고 있습니까? crypto/sha256은 예를 들어 회전을 사용하지만 비트 수는 일정합니다.

회전은 컴파일러가 인식할 수 있는 방식으로 인라인으로 작성하기 쉽습니다.

컴파일러의 내부에 익숙한 사람들에게는 쉽습니다. 수학/비트 패키지에 넣으면 누구나 쉽게 사용할 수 있습니다.

회전된 비트 수가 일정하지 않은 경우 왼쪽/오른쪽 회전이 사용되는 위치를 알고 있습니까?

다음은 #9337의 예입니다.

https://play.golang.org/p/rmDG7MR5F9

각 호출에서 매번 회전된 비트 수는 일정하지만 함수 자체는 현재 인라인되지 않으므로 회전 명령 없이 컴파일됩니다. 수학/비트 라이브러리 기능이 확실히 도움이 될 것입니다.

2017년 1월 14일 토요일 오전 5:05, Alexandru Moșoi [email protected]
썼다:

현재 제안된 기능에는 훨씬 더 큰 Go 네이티브 구현이 있습니다.
최적보다 불균형적으로 더 비쌉니다. 반면에 회전
컴파일러가 인식할 수 있는 방식으로 인라인으로 작성하기 쉽습니다.

이 문제에서 여러 번 강조했듯이 이것은 올바른 방법이 아닙니다.
Go 패키지를 디자인합니다. 기본 하드웨어에 너무 많이 연결됩니다. 우리가 무엇을
want 는 일반적으로 유용한 약간 엉뚱한 패키지입니다. 이든
기능은 단일 명령어로 확장될 수 있습니다.
API 인터페이스는 잘 알려져 있고 일반적으로 유용하기 때문입니다.

@minux https://github.com/minux 및 다른 모든 사람: 알고 계십니까?
회전된 비트 수가 일정하지 않은 경우 왼쪽/오른쪽 회전이 사용되는 곳은 어디입니까?
crypto/sha256은 예를 들어 회전을 사용하지만 비트 수는 일정합니다.

실제 문제에서 회전 비트 수가 일정하더라도
컴파일러는 그것을 보지 못할 수도 있습니다. 예: 시프트 카운트가 저장된 경우
배열에서 숨기거나 루프 카운터에서 숨기거나 인라인되지 않은 호출자
기능.

가변 회전 수를 사용하는 간단한 예는 흥미롭습니다.
팝카운트 구현:
// https://play.golang.org/p/ctNRXsBt0z

func RotateRight(x, k uint32) uint32
func Popcount(x uint32) int {
    var v uint32
    for i := v - v; i < 32; i++ {
        v += RotateRight(x, i)
    }
    return int(-int32(v))
}

@josharian 이 예제는 rot이 인라인되지 않은 경우 잘못된 인라인 결정처럼 보입니다. 당신은 함수를 작성하려고 했 func rot(x, n) 대신 rot = func(x, n) ?

@minux : 동의합니다. API를 특정 명령어 세트에 연결하려는 것이 아닙니다. 하드웨어 지원은 좋은 보너스입니다. 내 주요 초점은 컨텍스트를 이해하기 위해 실제 코드(장난감 코드 아님)에서 사용법을 찾는 것입니다. 가장 좋은 서명은 무엇이며 모든 사람이 좋아하는 기능을 제공하는 것이 얼마나 중요한지 이해합니다. 지금 제대로 하지 않으면 호환성 약속이 나중에 우리를 물릴 것입니다.

예를 들면: add with carry return의 서명은 무엇이어야 합니까? Add(x, y uint64) (c, s uint64) ? math/big 보면 Add(x, y uintptr) (c, s uintptr) 도 필요할 것입니다.

rot이 인라인되지 않은 경우 예제는 잘못된 인라인 결정처럼 보입니다.

예. 인라인에 대해 불평하는 버그의 일부입니다. :)

함수를 rot = func(x, n) 대신 func rot(x, n)으로 작성하려고 했습니까?

그것은 내 코드가 아니며 그것이 요점의 일부입니다. 그리고 어쨌든 합리적인 코드입니다.

회전 및 바이트 스왑 기능이 암호화 알고리즘에서 안전하게 사용할 수 있도록 일정 시간 작업임을 보장하는 것이 좋습니다(패키지 설명서에서?). 다른 기능에 대해서도 생각할 수 있습니다.

2017년 1월 19일 목요일 오전 11시 50분, Michael Munday [email protected]
썼다:

(패키지 문서에서?)
회전 및 바이트 스왑 기능은 일정 시간 작업이므로
암호화 알고리즘에서 안전하게 사용할 수 있습니다. 아마도 생각해볼 문제
다른 기능에도.

바이트 스왑의 사소한 구현은 일정한 시간이지만 기본
아키텍처는 가변 시프트 명령을 제공하지 않으므로 어려울 것입니다.
일정한 시간 회전 구현을 보장합니다. 아마도 Go는 실행되지 않을 것입니다
하지만 그 아키텍처에.

즉, 기저에 깔릴 가능성도 무시할 수 없습니다.
마이크로아키텍처는 다중 사이클 시프터를 사용하며 보장할 수 없습니다.
이러한 구현에서 일정한 시간 회전합니다.

엄격한 일정한 시간이 필요한 경우 아마도 유일한 방법은 어셈블리를 작성하는 것입니다.
(그리고 그 경우에도 사용된 모든
명령 자체는 상수 시간이며, 이는
마이크로아키텍처.)

이러한 보장의 필요성을 이해하지만 실제로는
우리의 통제.

나는 @minux에 동의하는 경향이 있습니다. 상시 암호화 프리미티브를 원한다면 암호화/미묘하게 살아야 합니다. crypto/subtle은 해당 구현이 검증된 플랫폼에서 수학/비트로 쉽게 리디렉션할 수 있습니다. 느리지만 지속적인 구현이 필요한 경우 다른 작업을 수행할 수 있습니다.

이것은 할 가치가 있는 것 같습니다. @griesemer 와 @randall77 은 수의사에게

이제 이 제안을 진행할 수 있으므로 API의 세부 사항에 동의해야 합니다. 현재 내가 보는 질문:

• 어떤 기능을 포함할 것인가?
• 처리할 유형( uint64 , uint32 전용 또는 uint64 , uint32 , uint16 , uint8 , 또는 uintptr )?
• 서명 세부 정보(예: TrailingZeroesxx(x uintxx) uint , xx = 64, 32 등, vs TrailingZeroes(x uint64, size uint) uint 여기서 크기는 64, 32 등 중 하나) - 후자는 더 작은 API로 이어질 수 있으며 구현에 따라 여전히 충분히 빠름)
• 일부 이름 자전거 흘리기(나는 "Hacker's Delight" 용어를 좋아하지만 철자가 더 적절할 수 있음)
• 이 패키지에 대해 수학/비트보다 더 나은 곳이 있습니까?

@brtzsnr 이 노력을 계속 주도하시겠습니까? 나는 당신이 초기 디자인을 가져오고 이 문제에서 그것을 반복하고 싶거나 전용 디자인 문서를 설정하는 것을 선호하는 경우에 괜찮습니다. 또는 이것을 선택하고 앞으로 밀어낼 수 있습니다. 나는 이것이 1.9 단계에서 들어가는 것을 보고 싶습니다.

나는 개인적으로 철자가 있는 xx 이름을 선호합니다. bits.TrailingZeroes(uint64(x), 32)는 bits.TrailingZeroes32(x), imo보다 더 복잡하고 가독성이 낮습니다. uintptr이 더 쉽습니다(xx = Ptr?).

또한 예를 들어 첫 번째 릴리스에 uint8을 포함하지 않았지만 나중에 추가했다면 더 분명해질 것입니다. 놓치기 쉬운 릴리스 문서의 메모와 함께 유효한 크기 목록으로 이동합니다.

철자가 있는 이름이 사용되는 경우 Hacker의 기쁨 용어는 설명에 "~라고도 알려진"으로 포함되어 잘못된 철자를 검색하는 경우 검색(페이지 또는 검색 엔진을 통해)이 표준 이름을 쉽게 찾을 수 있도록 해야 한다고 생각합니다. .

저는 수학/비트가 좋은 곳이라고 생각합니다. 비트가 있는 수학입니다.

SwapBytes{16,32,64} 는 sync/atomic 보다 SwapBytes(..., bitSize uint) sync/atomic 함수와 더 일관성이 있습니다.

있지만 strconv 패키지를 사용하지 ParseInt(..., bitSize int) 패턴 사이에 더 관계가 bits 및 atomic 와 거기보다 strconv .

내가 SwapBytes(uint64, size uint)를 좋아하지 않는 세 가지 이유:

1. 사람들은 크기가 컴파일 시간 상수가 아닌 경우에 사용할 수 있습니다.
   최소한 현재 컴파일러),
2. 많은 유형 변환이 필요합니다. 먼저 uint32를 다음으로 변환합니다.
   uint64로 변환한 다음 다시 변환합니다.
3. 미래의 제네릭을 위해 제네릭 이름 SwapBytes를 예약해야 합니다.
   함수의 버전(Go가 제네릭 지원을 받는 경우).

@griesemer Robert, 제안을 받아주세요. 한 달 안에 이 제안을 추진할 시간이 있지만 그 때까지 진행이 지연되어서는 안 됩니다.

형식의 서명에 대한 명확한 기본 설정이 있는 것 같습니다.

func fffNN(x uintNN) uint

어떤 NN을 지원할지 열어 둡니다. 계속되는 논의를 위해 NN=64에 초점을 맞추겠습니다. 필요에 따라 나머지 유형을 추가하는 것은 간단합니다(uintptr 포함).

이는 @brtzsnr 의 원래 제안과 다음 기능(및 다양한 유형에 대한 각각의 변형) 및 그 동안 사람들이 제안한 내용으로 바로 돌아갑니다.

// LeadingZeros64 returns the number of leading zero bits in x.
// The result is 64 if x == 0.
func LeadingZeros64(x uint64) uint

// TrailingZeros64 returns the number of trailing zero bits in x.
// The result is 64 if x == 0.
func TrailingZeros64(x uint64) uint

// Ones64 returns the number of bits set in x.
func Ones64(x uint64) uint

// RotateLeft64 returns the value of x rotated left by n%64 bits.
func RotateLeft64(x uint64, n uint) uint64

// RotateRight64 returns the value of x rotated right by n%64 bits.
func RotateRight64(x uint64, n uint) uint64

Swap 기능 세트도 있을 수 있습니다. 개인적으로 나는 이것에 대해 회의적입니다. 1) SwapBits가 필요하지 않았으며 대부분의 SwapBytes 사용은 엔디안을 인식하지 않아야 할 때 코드를 인식하기 때문입니다. 코멘트?

// SwapBits64 reverses the order of the bits in x.
func SwapBits64(x uint64) uint64

// SwapBytes64 reverses the order of the bytes in x.
func SwapBytes64(x uint64) uint64

그런 다음 정수 연산 세트가 있을 수 있습니다. 그것들 중 일부(예: Log2)가 이 패키지의 다른 기능에 가까울 수 있기 때문에 그것들은 이 패키지에만 있을 것입니다. 이러한 기능은 다른 곳에 있을 수 있습니다. 패키지 이름 bits 을 조정해야 할 수도 있습니다. 코멘트?

// Log2 returns the integer binary logarithm of x.
// The result is the integer n for which 2^n <= x < 2^(n+1).
// If x == 0, the result is -1.
func Log2(x uint64) int

// Sqrt returns the integer square root of x.
// The result is the value n such that n^2 <= x < (n+1)^2.
func Sqrt(x uint64) uint64

마지막으로 @minux 는 AddUint32 등과 같은 작업을 제안했습니다. 올바르게 지정하기가 더 까다롭다고 생각하기 때문에 지금은 생략하겠습니다(그리고 더 다양합니다). 나중에 다시 연락할 수 있습니다. 위의 내용에 대해 합의를 봅시다.

질문:

• 함수 이름에 대한 의견이 있으십니까?
• 정수 연산에 대한 의견이 있으십니까?
• 패키지 이름/위치에 대한 의견이 있으십니까?

나는 긴 함수 이름을 선호합니다. Go는 함수 이름의 약어를 피합니다. 댓글은 그런 식으로 패키지를 검색하는 사람들의 별명("nlz", "ntz" 등)을 말할 수 있습니다.

@griesemer님 , 메시지에 오타가 있는 것 같습니다. 주석이 함수 서명과 일치하지 않습니다.

압축 응용 프로그램에서 SwapBits 를 사용합니다. 즉, 주요 아키텍처가 비트 반전을 효율적으로 수행할 수 있는 기능을 제공합니까? 나는 내 자신의 코드에서 할 계획이었습니다.

v := bits.SwapBytes64(v)
v = (v&0xaaaaaaaaaaaaaaaa)>>1 | (v&0x5555555555555555)<<1
v = (v&0xcccccccccccccccc)>>2 | (v&0x3333333333333333)<<2
v = (v&0xf0f0f0f0f0f0f0f0)>>4 | (v&0x0f0f0f0f0f0f0f0f)<<4

@bradfitz , @dsnet : 업데이트된 서명(오타 수정). 또한 업데이트된 질문(사람들은 바로 가기의 명시적 이름을 선호함).

비트 스와핑에 대한 기본 지원이 없으면 SwapBits 생략하는 데 투표하겠습니다. 비트가 각 바이트 내에서만 교환되는지 또는 전체 uint64에서 교환되는지 여부는 이름만으로 약간 모호할 수 있습니다.

지침 가용성만을 기준으로 무언가를 제외하는 이유는 무엇입니까? 리버스 비트
FFT에서 주목할만한 용도가 있습니다.

역 비트 명령어 가용성에 대한 귀하의 질문에 답하기 위해: arm에는
RBIT 명령.

@griesemer 다음과 같은 함수의 유형 서명만큼

func Ones64(x uint64) uint
func RotateLeft64(x uint64, n uint) uint64

RotateLeftN 등은 용이한 내면화에 필요하기 때문에(가능한 경우) 또는 단지 그것이 도메인이기 때문에 단위를 사용합니까? 강력한 기술적 요구가 없다면 음수 값이 이해되지 않더라도 int를 취하는 더 강력한 선례가 있습니다. 강력한 기술적 요구가 있는 경우 규칙성을 위한 적절한 N에 대해 uintN이어야 합니까?

OnesN 와 관계없이 해당 ilk는 int를 반환해야 합니다. 그렇지 않으면 이러한 연산을 다른 비트 연산으로 구성할 수 있으며 이 경우 적절한 N에 대해 uintN을 반환해야 합니다.

@jimmyfrasche 도메인이기 때문입니다. cpu는 상관없습니다. 무언가가 int인지 uint인지는 비교를 제외한 대부분의 작업과 관련이 없습니다. 즉, int로 만들면 결코 음수(결과)가 아니거나 음수가 아니어야 한다고(인수) 설명하거나 음수(회전에 대한 인수)일 때 수행해야 할 작업을 지정해야 합니다. 이 경우에는 하나의 회전으로 벗어날 수 있습니다.

나는 int를 사용하는 것이 일을 더 쉽게 만든다고 확신하지 않는다. 적절하게 설계된 경우 단위는 단위로 흐르고(math/big의 경우) 변환이 필요하지 않습니다. 그러나 변환이 필요하더라도 CPU 비용 측면에서(가독성 측면에서는 아님) 무료입니다.

그러나 그렇지 않으면 설득력 있는 주장을 듣거나 보게 되어 기쁩니다.

회전 비트 수는 uint여야 합니다(특정 크기 없음).
언어의 시프트 연산자.

int를 사용하지 않는 이유는 모호성이 있기 때문입니다.
RotateRight -2비트는 RotateLeft 2비트와 같습니다.

@minux Rotate(x, n) 가 x 만큼 n mod 64 비트로 회전하도록 정의된 경우 모호함이 없습니다. 왼쪽으로 10비트 회전하는 것은 64-10 = 54비트로 오른쪽으로 회전하는 것과 같습니다. 또는 (int 인수를 허용하는 경우) -10비트(양수 값이 왼쪽 회전을 의미한다고 가정). -10 mod 64 = 54. 아마도 CPU 명령으로도 효과를 무료로 얻을 수 있습니다. 예를 들어, 32비트 x86 ROL/ROR 명령어는 이미 CL 레지스터의 맨 아래 5비트만 보고 32비트 회전에 대해 mod 32를 효과적으로 수행합니다.

유일한 실제 인수는 나머지 stdlib와의 규칙성입니다. uint가 많은 의미가 있지만 int가 대신 사용되는 곳이 많이 있습니다.

math/big은 주목할만한 예외이기 때문에 이것이 다른 것에 문제가 없지만 고려해야 할 사항입니다.

@minux 는 구현의 모호성보다는 코드를 읽고/디버깅하는 사람에게 모호성을 의미한다고 가정합니다. 이는 uint를 사용하는 설득력 있는 인수입니다.

패키지 이름이 이미 비트라고 하는 경우 bits.SwapBits에 실제로 비트 접미사를 붙여야 합니까? 비트스왑은 어때요?

또 다른 아이디어는 bits.SwapBytes가 아닌 bits.SwapN(v uint64, n int)입니다. 여기서 n은 스왑을 위해 그룹화할 비트 수를 나타냅니다. n=1일 때 비트가 반전되고 n=8일 때 바이트가 스왑됩니다. 한 가지 이점은 bits.SwapBytes가 더 이상 존재할 필요가 없다는 것입니다. 비록 n의 다른 값에 대한 필요성을 본 적이 없지만 다른 사람들은 동의하지 않을 수도 있습니다.

위에서 지정한 대로 LeadingZeros64 , TrailingZeros64 , Ones64 모든 LGTM.

서명된 회전 금액이 있는 단일 Rotate64 가 매력적입니다. 대부분의 회전은 일정한 양만큼 이루어지므로(이것이 내장이 되는 경우) 별도의 오른쪽/왼쪽 기능이 없어도 런타임 비용이 발생하지 않습니다.

나는 비트/바이트 셔플링/스와핑/역방향에 대한 강한 의견이 없습니다. 반전 비트의 경우 bits.Reverse64 가 더 나은 이름처럼 보입니다. 그리고 아마도 bits.ReverseBytes64 ? Swap64 이 약간 불분명합니다. Swap64 이 그룹 크기를 사용하는 것이 매력적이지만 그룹 크기가 64를 균등하게 나누지 않을 때 동작은 무엇입니까? 중요한 그룹 크기가 1 및 8 인 경우 별도의 기능을 제공하는 것이 더 간단합니다. 나는 또한 영감을 얻기 위해 arm64 및 amd64 BMI2 명령어를 보고 일반적인 비트 필드 조작이 더 나을지 여부도 궁금합니다.

정수 수학 함수가 이 패키지에 속한다고 확신할 수 없습니다. 그것들은 구현에서 비트 함수를 사용할 수 있는 패키지 수학에 속하는 것처럼 보입니다. 관련하여 func Sqrt(x uint64) uint32 ( uint64 를 반환하는 대신)가 아닌 이유는 무엇입니까?

AddUint32 와 친구들이 복잡하긴 하지만 언젠가는 다시 만나길 바란다. 다른 것들과 함께 MulUint64 는 초소형 RISC-V ISA조차도 지침으로 제공하는 HMUL에 대한 액세스를 제공합니다. 하지만 네, 먼저 무언가를 시작합시다. 나중에 언제든지 확장할 수 있습니다.

bits 는 분명히 올바른 패키지 이름처럼 보입니다. 가져오기 경로가 math/bits 가 아니라 bits 여야 한다고 말하고 싶지만 그렇게 강하게 느껴지지는 않습니다.

bits는 분명히 올바른 패키지 이름처럼 보입니다. 가져오기 경로는 수학/비트가 아닌 비트여야 한다고 말하고 싶지만 그렇게 강하게 느껴지지는 않습니다.

IMO, bits 이면 (패키지 문서를 읽지 않고) bytes 패키지와 다소 비슷할 것으로 예상됩니다. 즉, 비트에 대해 작동하는 기능 외에도 바이트 스트림에서/로부터 비트를 읽고 쓰기 위해 Reader 및 Writer 를 찾을 것으로 예상합니다. math/bits 만들면 상태 비저장 기능 집합이라는 것이 더 분명해집니다.

(비트 스트림에 대해 Reader/Writer를 추가하는 것을 제안하지 않습니다)

서명된 회전량이 있는 단일 회전64가 매력적입니다. 대부분의 회전은 일정한 양만큼 이루어지므로(이것이 내장이 되는 경우) 별도의 오른쪽/왼쪽 기능이 없어도 런타임 비용이 발생하지 않습니다.

회전 왼쪽/오른쪽을 하나의 Rotate 로 결합하여 약간 더 작은 패키지 API를 갖는 것이 얼마나 편리한지 알 수 있지만 n 매개변수를 다음과 같이 효과적으로 문서화하는 문제도 있습니다. 다음을 나타냅니다.

• 음수 n 결과 왼쪽 회전
• 0 n 결과 변경 없음
• 양수 n 결과 오른쪽 회전

나에게 추가된 정신적 및 문서 오버헤드는 둘을 단일 Rotate 로 결합하는 것을 정당화하지 않는 것 같습니다. n 가 uint 인 명시적 RotateLeft 및 RotateRight 갖는 것이 더 직관적으로 느껴집니다.

@mdlayher n비트 워드의 경우 왼쪽으로 k비트 회전하는 것은 nk비트를 오른쪽으로 회전하는 것과 같습니다. 이것을 두 개의 함수로 분리하더라도 왼쪽으로 k 비트만큼 회전한다는 것은 항상 (k mod n) 비트만큼 회전한다는 것을 의미한다는 것을 이해해야 합니다(n 비트 이상 회전하면 다시 시작합니다). 그렇게 하면 회전 기능이 항상 k mod n 비트만큼 회전한다고 말할 수 있습니다. 음수 값이나 두 번째 기능을 설명할 필요가 없습니다. 그것은 단지 작동합니다. 실제로는 더 간단합니다.

게다가 하드웨어(예: x86)는 상수 k가 아닌 경우에도 자동으로 이 작업을 수행합니다.

@griesemer , Rotate 의 단점은 어느 방향이 양수인지 말하지 않는다는 것입니다. Rotate32(1, 1) 2 또는 0x80000000과 같습니까? 예를 들어, 내가 그것을 사용하는 코드를 읽고 있다면 결과가 2가 될 것으로 예상하지만 분명히 @mdlayher 는 0x80000000이 될 것으로 예상합니다. 반면에 RotateLeft 및 RotateRight 는 서명된 인수 또는 서명되지 않은 인수를 취하는지 여부에 관계없이 명확한 이름입니다. (RotateRight by -2가 RotateLeft 2와 같은지 여부가 모호하다는 @minux의 의견에 동의하지 않습니다. 이것들은 분명히 저와 동등해 보이며 다른 방법을 지정할 수 없습니다.)

RotateLeft64 라는 하나의 함수만 갖고 음수 값을 사용하여 오른쪽으로 회전하면 @aclements를 수정할 수 있습니다. 또는 문서와 함께. (FWIW, 귀하의 예에서는 0x800000000이 아닌 2도 예상합니다.)

그것을 가지고 이상한 조금 보이지만 @josharian, 내가 동의 RotateLeft 도하지 않고 RotateRight . 부호 있는 회전을 갖는 일관성은 회전이 계산되는 경우 잠재적으로 가치가 있는 것처럼 보이지만 일정한 회전의 경우 "음수 2비트를 농담으로 왼쪽으로 회전"보다 "오른쪽으로 2비트 회전"이라는 코드를 읽는 것이 좋습니다.

문서로 이 문제를 해결할 때의 문제는 문서가 함수를 호출하는 코드의 가독성에 도움이 되지 않는다는 것입니다.

코드를 작성하는 사람들은 왼쪽으로 회전하거나 오른쪽으로 회전하기를 원합니다. 그들은 좌우로 회전하는 것을 원하지 않습니다. 왼쪽 회전만 제공한다면 오른쪽 회전을 원하는 사람은 오른쪽 회전을 왼쪽 회전으로 변환하는 표현식을 작성해야 합니다. 이것은 컴퓨터가 하찮게 할 수 있는 표현이지만 프로그래머는 실수를 할 것입니다. 왜 프로그래머가 직접 작성하게 합니까?

확신합니다.

@aclements @ianlancetailor 포인트가

이름 아이디어는 서명 이름 대신 패키지 이름에 유형을 넣는 것입니다. bits64.Ones 대신 bits.Ones64 .

@btracey 거기에 입에 살짝 토했어요. :) 우리는 flag64.Int 또는 math64.Floatfrombits 또는 sort64.Floats 또는 atomic64.StoreInt .

@bradfitz golang.org/x/image/math/f64 및 golang.org/x/image/math/f32가 존재하지만

나는 atomic 에 대해 선례로 생각하지 않았습니다. 패키지가 여러 다른 유형에 대해 반복되는 함수 집합보다 크기 때문에 다른 예는 다릅니다.

문서는 bits64 로 이동하여
Ones LeadingZeros TrailingZeros

bits 에 가서 보는 대신
Ones8 Ones16 Ones32 Ones64 LeadingZeros8 ...

@iand , 그것도 꽤

Go에서는 pkg64.foo 대신 pkg.foo64 이름 지정 스타일을 사용하는 강력한 선례가 있습니다.

패키지 API는 n개의 유형이 있으면 n배 커지지만 API 복잡성은 그렇지 않습니다. 이 문제를 해결하기 위한 더 나은 접근 방식은 문서와 go doc과 같은 도구를 통해 API를 제공하는 방법을 사용하는 것입니다. 예를 들어 다음 대신:

// TrailingZeros16 returns the number of trailing zero bits in x.
// The result is 16 if x == 0.
func TrailingZeros16(x uint16) uint

// TrailingZeros32 returns the number of trailing zero bits in x.
// The result is 32 if x == 0.
func TrailingZeros32(x uint32) uint

// TrailingZeros64 returns the number of trailing zero bits in x.
// The result is 64 if x == 0.
func TrailingZeros64(x uint64) uint

API를 볼 때 정신적 오버헤드가 분명히 추가되므로 다음과 같이 나타낼 수 있습니다.

// TrailingZerosN returns the number of trailing zero bits in a uintN value x for N = 16, 32, 64.
// The result is N if x == 0.
func TrailingZeros16(x uint16) uint
func TrailingZeros32(x uint32) uint
func TrailingZeros64(x uint64) uint

godoc은 그런 의미에서 유사한 기능에 대해 현명할 수 있으며 단일 doc 문자열을 사용하여 그룹으로 제공할 수 있습니다. 이것은 다른 패키지에서도 도움이 될 것입니다.

요약하자면, 제안된 명명 체계는 Go 전통에서 훌륭해 보인다고 생각합니다. 프레젠테이션 문제는 다른 곳에서 논의할 수 있는 별도의 질문입니다.

패키지 이름에 비트 크기를 넣을 때 +1.

bits64.Log2는 bits.Log264보다 더 잘 읽힙니다.

결국, 스칼라 유형에 의해 "매개변수화된" 각 유형에 대해 동일한 API이므로 함수 유형 간에 동일한 이름이 있는 경우 코드를 별도의 패키지로 리팩토링하는 것이 더 쉽습니다. 가져오기 경로를 변경하기만 하면 됩니다(전체 단어 교체는 gofmt -r에서는 사소하지만 사용자 정의 접미사 변환은 더 어색합니다.

함수 이름의 비트 크기 접미사가 관용적일 수 있다는 @griesmeyer의 말에 동의하지만 유형과 무관한 패키지에 중요하지 않은 코드가 있는 경우에만 가치가 있다고 생각합니다.

인코딩/바이너리에서 플레이를 훔쳐 Uint64, Uint32, ...라는 이름의 변수를 만들 수 있습니다.

bit.Uint64.RightShift
bits.Uint8.Reverse
bit.Uintptr.Log2
...

@griesemer 그룹화 방법을 어떻게 알 수 있습니까? 문서에서 실제 이름 대신 N으로 끝나는 함수 이름을 가진 하나의 문서 문자열과 부조화와 일치하는 문서 문자열이 없는 함수 사이에서 공통 접두사를 찾으십니까? 그것이 어떻게 일반화됩니까? 아주 적은 수의 패키지를 제공하는 것은 복잡한 특별한 경우처럼 보입니다.

@rogpeppe 그것은

@nerdatmath 이것은 인코딩/바이너리(둘 다 binary.ByteOrder를 구현함)의 경우와 같이 구어체 의미에서 동일한 인터페이스를 갖지만 Go 의미에서가 아니기 때문에 약간 다를 수 있으므로 변수는 네임스페이스용일 뿐입니다. 그리고 godoc은 유형을 내보내지 않는 한 메소드(#7823)를 선택하지 않습니다. 이는 다른 방식으로 지저분합니다.

크기 접미사는 괜찮지만 대체로 별도의 패키지를 선호합니다. 하지만 이 댓글을 지나치도록 귀찮게 하는 것만으로는 충분하지 않습니다.

@nerdatmath가 var 이면 변경 가능합니다( bits.Uint64 = bits.Uint8 할 수 있음). 컴파일러가 패키지를 (적어도 일부) 패키지에 대한 동기 중 하나인 내장 함수로 처리하지 못하게 합니다.

변수가 내보내지지 않은 유형이고 상태가 없는 경우(내보내지 않은 빈 구조체) 변수는 실제로 변경할 수 없습니다. 그러나 공통 인터페이스가 없으면 godoc(오늘날)은 끔찍할 것입니다. 그것이 답이라면 고칠 수 있습니다.

하지만 여러 패키지를 사용하게 되더라도 이를 보증하기에 충분한 반복과 양이 있다면 최소한 "X/bits/int64s", "X/bits/ints", "X/"와 같은 패키지 이름을 지정해야 합니다. "오류", "문자열", "바이트"와 일치하는 비트/int32s". 여전히 많은 패키지 폭발처럼 보입니다.

단일 패키지 비트를 갖는 것이 간단하고 Go 라이브러리의 패키지 수를 부풀리지 않는 여러 유형별 패키지 경로로 이동해야 한다고 생각하지 않습니다.

Ones64와 TrailingZeroes64는 좋은 이름이 아니라고 생각합니다. 그들은 그들이 카운트를 반환한다는 것을 알리지 않습니다. 접두사 Count를 추가하면 이름이 더 길어집니다. 내 프로그램에서 이러한 함수는 종종 더 큰 표현식에 포함되므로 짧은 함수 이름은 가독성을 높입니다. "Hacker's Delight" 책의 이름을 사용했지만 Intel 어셈블러 니모닉인 Popcnt64, Tzcnt64 및 Lzcnt64를 따르는 것이 좋습니다. 이름은 짧고 일관된 패턴을 따르며 카운트가 반환되고 이미 설정되었음을 알립니다.

일반적으로 Go의 카운트는 카운트가 음수가 될 수 없는 경우에도 int로 반환됩니다. 대표적인 예는 내장 함수 len이지만 Read, Write, Printf 등은 모두 정수를 반환합니다. 카운트에 uint 값을 사용하는 것은 매우 놀라운 일이며 int 값을 반환할 것을 제안합니다.

선택이 (표기법을 남용하기 위해) math/bits/int64s.Ones와 math/bits.Ones64 중 하나라면, 저는 확실히 단일 패키지를 선호할 것입니다. 크기별로 분할하는 것보다 패키지 식별자에 비트를 포함하는 것이 더 중요합니다. 패키지 식별자에 비트가 있으면 코드를 더 쉽게 읽을 수 있습니다. 이는 패키지 설명서에서 반복되는 사소한 불편함보다 더 중요합니다.

@ulikunitz 비트를 광범위하게 사용하는 코드에서 항상 ctz := bits.TrailingZeroes64 등을 수행할 수 있습니다. 이는 전역적으로 자체 문서화되는 이름과 복잡한 코드에 대한 로컬 압축 이름 사이의 균형을 유지합니다. 반대 변환인 countTrailingZeroes := bits.Ctz64 는 멋진 전역 속성이 이미 손실되었기 때문에 덜 유용합니다.

나는 아주 드물게 비트 수준에서 물건을 엉망으로 만듭니다. 나는 그것에 대해 생각해야 했던 몇 년이 지났기 때문에 매번 이 항목을 많이 찾아보아야 합니다. 그래서 모든 Hacker's Delight/asm 스타일 이름이 짜증날 정도로 비밀스럽습니다. 차라리 내가 필요한 것을 찾아 프로그래밍으로 돌아갈 수 있도록 그것이 한 일을 말했으면 합니다.

나는 @ulikunitz에 동의합니다. 긴 이름은 눈이 아프

init() instead of initialize(), 
func instead of function
os instead of operatingsystem
proc instead of process
chan instead of channel

또한 bits.TrailingZeroes64가 자체 문서화된다는 점에 도전하고 싶습니다. 0이 뒤에 오는 것은 무엇을 의미합니까? self documentation 속성은 사용자가 처음부터 문서의 의미에 대해 어느 정도 알고 있다는 가정 하에 존재합니다. 일관성을 위해 Hacker's Delight를 사용하지 않는 경우 RotateRight64 및 RotateLeft64와 일치하도록 ZeroesRight64 및 ZeroesLeft64라고 부르지 않겠습니까?

명확히 하자면, 당신이 그것을 사용할 때마다 가장 먼저 해야 할 일은 짧은 별칭을 만드는 것이고 주어진 이름을 사용해서는 안된다는 것을 암시하려는 것은 아닙니다. 반복적으로 사용하는 경우 코드의 가독성이 향상되면 별칭을 지정할 수 있습니다.

예를 들어, 내가 string.HasSuffix를 호출하는 경우 한 번 또는 두 번 호출하기 때문에 주어진 이름을 대부분 사용하지만 가끔은 일회성 ETL 스크립트 등에서 결국에는 ends := strings.HasSuffix 를 사용하여 더 짧고 코드를 더 명확하게 만들겠습니다. 별칭의 정의가 가깝기 때문에 괜찮습니다.

축약된 이름은 매우 일반적인 항목에 적합합니다. 많은 비 프로그래머는 OS가 무엇을 의미하는지 알고 있습니다. Go를 모르더라도 코드를 읽는 사람은 func가 function의 약자라는 것을 알게 될 것입니다. 채널은 바둑의 기본이고 널리 사용되기 때문에 chan은 괜찮습니다. 비트 기능은 절대 일반적이지 않습니다.

TrailingZeroes는 개념에 익숙하지 않은 경우 무슨 일이 일어나고 있는지 정확히 말할 수 없을 수도 있지만 Ctz보다 적어도 대략적으로 무슨 일이 일어나고 있는지 훨씬 더 잘 알 수 있습니다.

@jimmyfrasche 관련 https://github.com/golang/go/issues/18616#issuecomment -275828661: go/doc이 모두 다음으로 시작하는 이름을 가진 동일한 파일의 연속적인 기능 시퀀스를 인식하는 것은 꽤 쉬울 것입니다. 동일한 접두사를 가지며 일련의 숫자 및/또는 접두사에 상대적으로 "짧은" 단어인 접미사를 갖습니다. 이 함수 중 첫 번째 함수에만 문서 문자열이 있고 접두어가 일치하는 다른 함수에는 그렇지 않다는 사실과 결합할 것입니다. 더 일반적인 설정에서 꽤 잘 작동할 수 있다고 생각합니다. 즉, 이 제안을 가로채지 않기 위해 다른 곳에서 논의합시다.

참고로, go/doc 변경 사항에 대해 논의하고 해당 대화를 이 대화와 별도로 유지하기 위해 #18858을 만들었습니다.

@mdlayher 그렇게

@rogpeppe 패키지 이름에 크기를 넣는 것이 흥미롭게 들리지만 댓글과 기존 Go 스타일을 감안할 때 함수 이름으로 크기를 넣는 것이 더

@ulikunitz 저는 보통

Log2의 2가 필요하지 않다는 데 동의합니다. bits.Log 는 2의 밑을 의미합니다.

비트.Log64 SGTM.

@griesemer 내 잘린 문장은 아마도 서투른 편집의 인공물이었을 것입니다. 방금 제거했습니다.

@griesemer 바이크 셰딩 이라는 이름을 계속 쓸 가치가 있는지 궁금합니다. 나는 그것을 짧게 유지한다. 나는 두 가지 주장이 있었다: 숫자 반환에 대한 간결함과 명확성. 패키지 빅은 내부적으로 LeadingZeros가 아닌 nlz를 사용합니다. 이러한 기능의 사용 횟수가 적다는 데 동의합니다.

@ulikunitz 여기 피드백의 대부분은 바로 가기가 아닌 명확한 함수 이름에 찬성한다고 생각합니다.

@ulikunitz , 추가로:

패키지 빅은 내부적으로 LeadingZeros가 아닌 nlz를 사용합니다.

내보내지 않은 내부 비공개 이름은 여기에 영향을 미치지 않습니다.

중요한 것은 공개 API의 일관성과 표준 느낌입니다.

Bikeshedding은 성가 시지만 우리가 영원히 붙어있을 때 이름은 중요합니다.

CL https://golang.org/cl/36315에 이 문제가 언급되어 있습니다.

https://go-review.googlesource.com/#/c/36315/ 를 초기(부분적으로 테스트된) API(예비 구현 포함)로 업로드하여 검토를 위해(디자인 문서 대신)

API가 올바른지 계속 확인하고 있으므로 지금은 API(bits.go)에 대해서만 의견을 말해주세요. 사소한 문제(오타 등)는 CL에 댓글을 남겨주세요. 디자인 문제의 경우 이 문제에 대해 의견을 말하십시오. 인터페이스에 만족할 때까지 CL을 계속 업데이트하겠습니다.

특히 구현에 대해 걱정하지 마십시오. 기본적이며 부분적으로만 테스트되었습니다. API에 만족하면 구현을 쉽게 확장할 수 있습니다.

@griesemer 나는 당신이 괜찮다고 확신하지만 유용하다면 https://github.com/ericlagergren/decimal/tree/ba42df4f517084ca27f8017acfaeb69629a090fb/internal/arith 테스트가 포함된 CLZ 어셈블리 구현이 있습니다. 훔치다 / 만지작거리다 / 무엇이든.

@ericlagergren 링크 주셔서 감사합니다. API가 설정되고 모든 곳에서 테스트가 수행되면 구현 최적화를 시작할 수 있습니다. 명심하겠습니다. 감사 해요.

@griesemer , 제안한 API 문서는 go/doc이 접두사는 같지만 정수 접미사가 있는 기능을 적절하게 문서화할 수 있는지에 달려 있는 것 같습니다.

1.9 이전에도 작업할 계획입니까?

18858, 즉!

@mdlayher 이상적일 것입니다. 그러나 API가 아닌 "유일한" 문서에만 영향을 미치기 때문에 (앞으로 이전 버전과의 호환성을 유지해야 함) 이것은 눈에 띄지 않을 것입니다.

@griesemer @bradfitz 시간을 할애하여 함수 이름에 대한 제 입장을 재고합니다. 이름 선택의 중요한 목표는 API를 사용하는 코드의 가독성 이어야 합니다.

다음 코드는 실제로 이해하기 쉽습니다.

n := bits.LeadingZeros64(x)

나는 여전히 Ones64(x)의 명확성에 대해 약간 의심이 있지만 LeadingZeros 및 TrailingZeros와 일치합니다. 그래서 나는 내 사건을 쉬고 현재 제안을 지지합니다. 실험으로 테스트 케이스를 포함한 패키지의 실험적인 순수 Go 구현을 위해 기존 코드를 사용했습니다.

저장소: https://github.com/ulikunitz/bits
문서: https://godoc.org/github.com/ulikunitz/bits

Swap 함수 세트도 있을 수 있습니다. [...] 대부분의 SwapBytes 사용은 엔디안을 인식하지 않아야 할 때 엔디안을 인식하는 코드 때문입니다. 코멘트?

이러한 이유로 SwapBytes 를 API에서 제외하고 싶습니다. 나는 그것이 binary/encoding.BigEndian 보다 더 간단하기 때문에(또는 더 빠르다고 가정하기 때문에) 사람들이 휴대용이 아닌 방식으로 그것을 사용하기 시작할 것이라고 걱정합니다.

이러한 이유로 SwapBytes를 API에서 제외하고 싶습니다. 이진/인코딩.BigEndian보다 더 간단(또는 더 빠를 것으로 가정)하기 때문에 사람들이 휴대용이 아닌 방식으로 사용하기 시작할까봐 걱정됩니다.

@mundaym 이러한 루틴이 SwapBytes64 를 BSWAP 로 직접 컴파일하게 하는 것이 부적절하게 사용하는 사람들보다 더 중요할 수 있습니다.

바이너리/인코딩보다 더 간단(또는 더 빠를 것으로 가정)하기 때문에 사람들이 휴대용이 아닌 방식으로 사용하기 시작할까봐 걱정됩니다.BigEndian

나는 ReverseBytes 사용이 unsafe 와 함께 사용되는 경우에만 이식성이 없다고 생각합니다. 여기서 기계가 메모리에 데이터를 배치하는 방식으로 낮은 수준에서 데이터에 액세스합니다. 그러나 encoding.{Little,Big}Endian.X 를 그렇게 사용하면 이식성이 없습니다. 압축에 사용할 ReverseBytes 를 기대하며 포함되지 않으면 슬플 것입니다.

@ericlagergren

이러한 루틴이 내재화될 예정입니까?

예, 바이트 반전을 수행하는 encoding/binary 의 함수는 컴파일러에서 인식하고 정렬되지 않은 데이터를 지원하는 플랫폼에서 단일 명령어(예: BSWAP )에 최적화된(또는 최적화될 수 있는) 코드 패턴을 사용합니다. 액세스(예: 386, amd64, s390x, ppc64le 및 기타).

BSWAP로 SwapBytes64를 직접 컴파일하면 부적절하게 사용하는 사람들보다 더 중요할 수 있습니다.

나는 동의하지 않는 경향이 있다. 엔디안을 인식하지 못하는 코드에서 SwapBytes 의 합법적인 사용이 있을 수 있지만 올바르게 사용되는 것보다 더 자주 오용될 것이라고 생각합니다.

runtime/internal/sys에는 이미 최적화된 Go, 어셈블리 및 후행 0 및 바이트 스왑의 컴파일러 내장 버전이 있으므로 이러한 구현을 재사용할 수 있습니다.

@dsnet 흥미

@aclements 런타임에서 바이트 스왑 내장 함수가 사용되는 위치를 알고 있습니까? 테스트 이외의 용도는 찾지 못했습니다.

@mundaym , AFAIK 런타임에서 사용되지 않습니다. 내부 API는 그렇게 조심할 필요가 없어서 그냥 ctz 추가할 때 추가하기 쉽기 때문에 추가한 것 같아요. :) (팝카운트가 더 나은 선택이었을 것입니다.)

전체: 지금은 API에 집중하라는 알림입니다. CL에서의 구현은 실제로 이러한 기능을 사용하고 테스트할 수 있도록 하는 사소하고 느린 구현입니다. API에 만족하면 구현을 조정할 수 있습니다.

참고: uint32 또는 uint64 와 크기가 같다는 보장이 없기 때문에 uintptr 버전을 포함해야 합니다. (단위는 항상 uint32 또는 uint64 ). 의견? 나중을 위해 남겨두시겠습니까? 좋은 이름은 무엇입니까? ( LeadingZerosPtr ?).

지금 uintptr을 수행해야 합니다. 그렇지 않으면 math/big에서 사용할 수 없습니다. 접미사 Ptr SGTM. uint 도 수행해야 한다고 생각합니다. 그렇지 않으면 모든 호출 코드가 변환 없는 호출을 만들기 위해 int 크기 주위에 조건부 코드를 작성해야 합니다. 네이밍 아이디어가 없습니다.

uintptr의 경우 Ptr, uint의 경우 접미사가 없습니다. Ones, Ones8, Ones16, Ones32, Ones64, OnesPtr 등

저는 소수일 수도 있지만 uintptr을 사용하는 기능을 추가하는 것에 반대합니다.
math/big은 처음부터 uint32/uint64를 사용해야 합니다. (사실 나는
모든 아키텍처에 uint64를 사용하고 최적화는
컴파일러.)

문제는 다음과 같습니다.
math/big은 최적의 성능을 위해 기본 단어 크기를 사용하려고 합니다.
그러나 닫혀 있는 동안 uintptr은 올바른 선택이 아닙니다.
포인터의 크기가 포인터의 크기와 같다는 보장은 없습니다.
네이티브 단어 크기.
대표적인 예는 amd64p32이며 mips64p32를 추가할 수도 있습니다.
mips64p32le 나중에, 64비트 MIPS 호스트에 훨씬 더 많이 사용됩니다.

나는 확실히 그러한 사용을 더 권장하고 싶지 않습니다. uintptr은 가장
아키텍처 중립 정수가 아닌 포인터의 경우.

그러나 한 가지 해결책은 API에 유형 별칭을 도입하는 것입니다(아마도
브랜드 유형이어야 하며 이는 논의 대상입니다.)
type Word = uint32 // 또는 64비트 아키텍처의 경우 uint64
// Word에 다음과 같은 이상적인 상수를 몇 가지 제공해야 할 수도 있습니다.
비트 수, 마스크 등

그런 다음 Word를 사용하기 위해 유형 접두사 없이 함수를 도입합니다.

사실, 수학/비트가 두 가지 결과를 제공하면 add, sub, mul,
div; math/big은 아키텍처별 어셈블리 없이 다시 작성할 수 있습니다.

수학/큰 수출 type Word uintptr . 나는 그것이 실수 일 수 있다는 데 동의하지만 호환성을 위해서는 그것이 남아 있어야한다고 믿습니다. 따라서 수학/비트를 사용하여 수학/빅을 구현하려면 uintptr API가 필요합니다.

주제에서 약간 벗어나지만 기본 부호 없는 단어 크기는 uint가 아닌가요? 이 경우 uint에 대한 접미사가 없는 것이 맞는 것 같습니다.

단일 유형인 Word가 다른 아키텍처에서 다른 것을 원하지 않습니다. 그것은 호출자와 문서에 많은 복잡성을 도입하는 것처럼 보입니다. 기존 유형을 고수한다는 것은 단순히 사용할 수 있음을 의미합니다. 아키텍처에 따라 유형이 다르다는 것은 해당 유형을 중심으로 모든 코드를 설계하거나 빌드 태그 보호 파일에 어댑터를 많이 사용하는 것을 의미합니다.

FWIW, math/big 구현은 여전히 ​​uint32/64 기반 비트 API를 사용할 수 있습니다(함수의 uintptr 버전이 없는 경우).

@minux 저는 2-result add,sub,mul,div에 반대하지 않습니다. 하지만 두 번째 단계에서 그렇게 합시다. 그래도 괜찮은 성능을 원한다면 어셈블리 코드가 필요합니다. 그러나 나는 컴파일러에 의해 그렇지 않으면 확신하게되어 기쁩니다 ...

API에 uint 및 uintptr 버전을 추가했습니다. CL을 보고 댓글을 달아주세요. 그러나 기능의 확산에 너무 만족하지 않습니다.

@josharian 기본 단위는 64비트 시스템에서도 32비트 값일 수 있습니다. 보장이 없습니다. 나는 uintptr이 기계어 크기도 보장하지 않는다는 것을 알고 있습니다. 그러나 당시에는 돌이켜 보면 그것이 틀렸다면 더 합리적인 선택처럼 보였습니다. 아마도 우리는 정말로 Word 유형이 필요합니다.

uintptr 함수에 대한 유일한 합법적인 필요가 math/big을 지원하는 것이라면 math/bits의 구현은 내부 패키지에 들어갈 수 있습니다. math/big에서 uintptr 항목만 사용하고 나머지는 노출하십시오.

@jimmyfrasche , @griesemer 그게 big.Int.Bits에 어떤 영향을 미칠까요? 즉, 여전히 제로 할당이 될까요?

uint도 잘못되었습니다. amd64p32에서 32비트입니다.
실제로 math/big은 uintptr 대신 uint를 사용할 수 있었지만 Go 1에서는
int/uint는 항상 32비트이므로 uintptr이 가능한 유일한 솔루션입니다.
수학/big.Word.

우리는 새로운 패키지를 설계하고 있으므로 호환성이 그다지 중요하지 않다고 생각합니다.
우려. math/big은 잘못된 유형을 사용하고 있지만 이는 역사적
사고. 더 이상 실수하지 맙시다.

항상 가장 많이 사용되는 통합 유형 "Word"를 사용하는 이유를 이해하지 못합니다.
주어진 아키텍처에 대한 효율적인 정수 유형은 다음보다 더 복잡합니다.
uintptr을 사용하여 사용자 코드의 경우 다음과 같은 매직 유형으로 처리할 수 있습니다.
아키텍처에 따라 32비트 또는 64비트입니다. 쓸 수 있다면
uintptr(너비도 아키텍처에 따라 다름)을 사용하는 코드
아키텍처에 독립적인 방법을 사용하는 경우 Word에서도 동일한 작업을 수행할 수 있습니다.
그리고 Word는 모든 아키텍처에서 정확합니다.

API의 확산을 위해 8에 대한 기능을 생략하는 것이 좋습니다.
및 첫 번째 패스의 16비트 유형. 거의 사용되지 않으며 대부분
아키텍처는 어쨌든 32비트 및 64비트 명령어만 제공합니다.

math/big은 Word를 정의하고 내보내지만 a) uintptr과 직접 호환되지 않고(다른 유형임) b) Word를 적절하게 사용하고 구현에 대해 가정하지 않는 코드는 모든 종류의 Word 구현과 함께 사용할 수 있습니다. . 변경할 수 있습니다. API 호환성 보장에 영향을 미치는 이유를 모르겠습니다(시도하지는 않았습니다). 어쨌든, 이것은 제쳐두고 가자. 별도로 처리할 수 있습니다.

명시적으로 크기가 지정된 모든 uint 유형을 간단히 수행할 수 있습니까? uint/uintptr 크기를 상수로 알고 있다면 올바른 크기의 함수를 호출하는 if 문을 간단하게 작성할 수 있습니다. if 문은 일정하게 접혀 있고 각 래퍼 함수는 단순히 인라인될 크기가 지정된 함수를 호출합니다.

마지막으로, Word 유형(수학/대형과 무관)과 관련된 올바른 솔루션은 무엇입니까? 물론 우리는 그것을 수학/비트로 정의할 수 있지만 그것이 올바른 장소입니까? 플랫폼별 유형입니다. 미리 선언된 '단어' 유형이어야 합니까? 그리고 왜 안되지?

여기에 uintptr을 직접 언급하는 함수 서명(또는 이름)이 있는 것은 실수처럼 보입니다. 사람들은 Go 포인터에서 이런 종류의 비트를 조작해서는 안 됩니다.

자연어 유형에 대한 기능이 있어야 한다면 이제 int/uint를 참조할 수 있다고 생각합니다. 우리는 64비트 시스템에서 32비트였기 때문에 수학/큰에서 uint를 사용하지 않았지만 그 이후로 수정했습니다. 그리고 math/big은 자체적으로 일관된 세계이지만 big.Word 자체 유형을 갖는 것이 합리적입니다. 이 패키지는 선택 및 선택 유틸리티 루틴의 모음입니다. 이 컨텍스트에서 새 유형을 정의하는 것은 덜 매력적입니다.

int/uint 변형이 필요한지 여부를 모르겠습니다. 일반적으로 필요한 경우 이 패키지에서 정의하는 것이 모든 호출자가 if 문을 작성하도록 강제하는 것보다 더 합리적입니다. 그러나 그것들이 일반적으로 필요할지는 모르겠습니다.

math/big과의 잠재적 불일치를 해결하기 위해 여기 API에서 uintptr을 언급하지 않는 솔루션이 두 개 이상 있습니다.

1. 빌드 태그와 적절하게 리디렉션되는 uintptr 허용 래퍼를 사용하여 math/big에서 word32.go 및 word64.go 파일을 정의하고 컴파일러 인라인이 올바른 작업을 수행하는지 확인합니다.

2. big.Word의 정의를 uint로 변경합니다. 정확한 정의는 API에 노출되어 있어도 내부 구현 세부 사항입니다. 그것을 변경하면 amd64p32를 제외하고는 어떤 코드도 깨뜨릴 수 없으며, 심지어 수학/큰 외부에서는 문제가 되지 않을 것 같습니다.

@rsc : "64비트 시스템에서 32비트였기 때문에 수학/big에서 uint를 사용하지 않았지만 이후로 수정했습니다. " 아 예, uintptr을 선택한 이유를 완전히 잊었습니다. Go uint/int 유형의 요점은 기계의 자연 레지스터 크기를 반영하는 정수 유형을 갖는 것입니다. 나는 큰 변화를 시도할 것이다.Word를 uint로 바꾸고 무슨 일이 일어나는지 보자.

전체: 위의 논의에 따라 uintptr 함수 버전을 제외하도록 https://go-review.googlesource.com/#/c/36315/ 를 업데이트했습니다.

효과를 보기 위해 math/bits를 사용하도록 math/big을 잠정적으로 업데이트했습니다(https://go-review.googlesource.com/36328).

몇 가지 의견:
1) 나는 결과를 만드는쪽으로 기울고 있어요 Leading / TrailingZeros 기능 uint 보다는 int . 이러한 결과는 그에 따라 값을 이동하는 데 사용되는 경향이 있습니다. math/big 가 이를 증명합니다. 또한 일관성을 위해 Ones 가 uint 반환하도록 하는 것에 찬성합니다. 반대 주장?

2) 나는 One 라는 이름의 팬이 아니지만 Leading / TrailingZeros 와 일치합니다. Population 어떻습니까?

3) 어떤 사람들은 Log 가 이 패키지에 맞지 않는다고 불평했습니다. Log 는 msb의 인덱스와 동일합니다(x == 0의 경우 -1 사용). 따라서 MsbIndex 라고 부를 수 있습니다(Log가 더 좋아 보이지만). 또는 x의 길이(비트)인 Len 함수를 사용할 수 있습니다. 즉, `Log(x) == Len(x)-1).

코멘트?

나는 Leading/TrailingZeros와 일치하지만 One이라는 이름의 팬은 아닙니다. 인구는 어떻습니까?

기존의 Popcount 아닌 이유는 무엇입니까?

또는 x의 길이(비트)인 Len 함수를 가질 수 있습니다. 즉, `Log(x) == Len(x)-1).

Len 또는 Length 좋은 이름과 좋은 생각처럼 들립니다.

1.

나는 One이라는 이름의 팬이 아니지만 Leading/
후행제로. 인구는 어떻습니까?

비트.카운트?

@aclements 무엇을

Population은 역사적 이유로 더 나은 이름일 수 있지만 용어에 익숙하지 않고 동일한 문제가 있는 경우 Ones보다 더 많이 말하지는 않습니다. Count: Population of what?

패키지 내에서도 다소 단조롭지만 명확하고 분명한 이름을 지정하기 위해 CountOnes를 사용할 수 있습니다.

@aclements 무엇을

"bits"라는 패키지에서 세트 비트를 제외하고 무엇을 셀 수 있는지 잘 모르겠지만 CountOnes도 훌륭하고 분명히 더 명시적입니다. "1"을 추가하는 것은 LeadingZeros / TrailingZeros 의 "0"과도 유사합니다.

가장 분명한 해석이지만 여전히 모호합니다. 설정되지 않은 비트 또는 총 비트 수를 계산할 수 있습니다(마지막 해석은 극히 드물지만 관련된 개념에 익숙하지 않고 접미사가 없는 Count가 안전하지 않다고 생각할 수 있는 비트를 사용하여 코드를 읽는 사람에게는 여전히 잠재적인 함정입니다.SizeOf)

Trailing/LeadingZeroes를 미러링하는 AllOnes 또는 TotalOnes와 같은 것일 수 있지만 이와는 달리 위치가 고려되지 않도록 지정합니다.

AllOnes는 모든 것을 반환하는 것처럼 들립니다.

CountOnes와 TotalOnes는 거의 같은 것 같지만 이 작업의 가장 일반적으로 알려진 이름이 "population count"이기 때문에 CountOnes가 더 바람직할 것 같습니다.

몇 가지 변경 사항이 포함된 새 버전(https://go-review.googlesource.com/#/c/36315/)을 업로드했습니다.

1) Ones 을 PopCount . 대부분의 사람들은 일관성이 있지만 다소 단조로운 Ones 이름에 대해 그다지 흥분하지 않았습니다. 이 패키지를 사용하려는 모든 사람은 PopCount 가 하는 일을 정확히 알 것입니다. 이 기능을 일반적으로 부르는 이름입니다. 나머지 부분과 약간 일치하지 않지만 의미가 훨씬 명확해졌습니다. 나는 이것에 대해 Ralph Waldo Emerson과 함께 할 것입니다("어리석은 일관성은 작은 마음의 홉고블린입니다...").

2) bits.Len 에서와 같이 Log 를 Len 로 변경했습니다. 숫자 x의 비트 길이는 x를 이진 표현으로 나타내는 데 필요한 비트 수입니다(https://en.wikipedia.org/wiki/Bit-length). 적절해 보이며 "조금 까다로운" 품질이 아닌 Log 가 필요하지 않습니다. Log 정의된 방식을 감안할 때 Len(x) == Log(x) + 1 이기 때문에 이것이 또한 승리라고 생각합니다. 또한 결과가 항상 >= 0이고 (사소한) 구현에서 일부 +/-1 수정을 제거한다는 이점이 있습니다.

전반적으로 이 시점에서 이 API에 매우 만족합니다(나중에 더 많은 기능을 추가할 수 있음). 우리가 진지하게 고려하고 싶은 유일한 다른 것은 모든 결과가 서명되지 않아야 하는지 여부입니다. 이전에 지적했듯이 Trailing/Leading Zero 함수 결과는 부호가 없어야 하는 시프트 연산에 대한 입력인 경향이 있습니다. 이는 틀림없이 부호 없는 값도 반환할 수 있는 Len 및 PopCount만 남게 됩니다.

코멘트?

수학/big에 대한 내 경험은 내가 이동하지 않을 때 함수에 의해 uint 모드로 강제 전환되는 것에 대한 좌절감이었습니다. math/big/prime.go에서 나는 썼습니다.

for i := int(s.bitLen()); i >= 0; i-- {

s.bitLen()이 uint가 아닌 int를 반환하더라도 나는 보지 않고 확신할 수 없었고 미래의 CL이 uint를 반환하도록 변경하지 않을 수도 있다는 확신이 없었기 때문에 for 루프를 무한 루프로 바꿉니다. 이러한 방어가 필요하다는 것은 문제가 있음을 시사합니다.

Uint는 int보다 오류 발생 가능성이 훨씬 높기 때문에 대부분의 API에서 권장하지 않습니다. 어쨌든 대부분의 시프트 표현식에서 필요한 것처럼 수학/비트의 모든 함수가 int를 반환하고 변환을 시프트 표현식에서 수행하도록 uint로 남겨두면 훨씬 더 좋을 것이라고 생각합니다.

(변경을 제안하는 것은 아니지만 uint를 요구하는 shift가 돌이켜보면 실수였을 수도 있다고 생각합니다. 언젠가는 고칠 수 있을 것입니다. 다른 API에 피해를 주지 않는다면 좋을 것입니다.)

나는 후행 0 및 popcount 함수 호출에 대해 내 코드를 grepping한 후 int 반환을 지원합니다. 대부분의 호출은 짧은 변수 선언과 int 유형의 비교에 있습니다. 교대 호출에는 물론 uint 유형이 필요하지만 놀랍게도 드뭅니다.

약간의 조정을 업로드했습니다. +1 및 댓글에 따라 counts의 결과를 int 로 둡니다.

https://go-review.googlesource.com/36315

나는에 대한 입력 카운트 왼쪽 RotateLeft/Right 로 uint , 그렇지 않으면 우리는 값이 허용 안 그것을 부정하거나 때 발생하는 지정해야합니다.

마지막으로, 우리는 심지어 멀리 떠날 수 Len 이후의 모든 후 LenN(x) == N - LeadingZerosN(x) . 의견?

이 시점에서 더 이상 중요한 피드백이 없으면 이 API로 진행하고 검토 후 초기 구현을 커밋하는 것이 좋습니다. 그런 다음 구현 조정을 시작할 수 있습니다.

다음 단계에서는 2개의 인수를 사용하고 캐리하고 결과를 생성하고 캐리하는 다른 함수, 특히 Add / Sub / etc. .

@gri 기본 10 Len 기능에 대한 생각? 그냥 ((N - clz(x) + 1) * 1233) >> 12

기본 2보다 덜 "약간 해키"하지만 여전히 유용합니다.
2017년 2월 10일 금요일 오후 5:03 Robert Griesemer [email protected]
썼다:

약간의 조정을 업로드했습니다. +1 및 댓글에 따라 결과를 남겨 보겠습니다.
정수로 계산합니다.

https://go-review.googlesource.com/36315

RotateLeft/Right에 대한 입력 수를 uint로 남겨두었습니다. 그렇지 않으면
값이 음수이거나 허용하지 않을 때 어떤 일이 발생하는지 지정해야 합니다.

마지막으로 LenN(x) == N -
LeadingZerosN(x). 의견?

이 시점에서 더 이상 중요한 피드백이 없으면
이 API로 진행하고
검토. 그런 다음 구현 조정을 시작할 수 있습니다.

나는 다음 단계로 우리가 어떤 다른 기능을 할 수 있는지 논의하고 싶을 것입니다.
특히 2개의 인수를 사용하는 Add/Sub/ 등을 포함하고 싶습니다.
수행하고 결과를 생산하고 수행하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/18616#issuecomment-279107013 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFnwZ_QMhMtBZ_mzQAb7XZDucXrpliSYks5rbQjCgaJpZM4Lg5zU
.

또한. 이 문제의 범위를 벗어나더라도 실례지만 저는 확인된 산술을 선호합니다. 예: AddN(x, y T) (sum T, overflow bool)

2017년 2월 10일 금요일 오후 8:16 Eric Lagergren [email protected]
썼다:

또한. 이 문제의 범위를 벗어나더라도 실례합니다.
확인된 산술을 선호합니다. 예: AddN(x, y T) (합 T, 오버플로 부울)

서명된 오버플로에 대해 이야기하고 있습니까? 또는 서명되지 않은 오버플로(carry/borrow)?

또한 오버플로/캐리/빌러를 T 유형으로 반환하여 단순화하는 것을 선호합니다.
다중 정밀도 산술.

@ericlagergren (기본 2) Len 함수는 거의 log2이지만 본질적으로 여전히 비트 계산 함수입니다. 밑이 10인 Len 함수는 실제로 로그 함수입니다. 유용하다는 것은 부정할 수 없지만 이 패키지에는 적합하지 않은 것 같습니다.

예, checked 산술을 입력하는 것이 좋을 것이라고 생각합니다. 저는 단지 현재 API를 먼저 종료하여 앞뒤로 이동하는 대신 진행을 할 수 있기를 원했습니다. 지금까지 댓글을 달았던 대부분의 사람들은 그것에 만족하는 것 같습니다.

Add, Sub 기능에 관하여: 나는 캐리가 인수와 같은 유형이어야 한다는 @minux에 동의합니다. 또한 이러한 함수에 대해 uint 인수 외에 다른 것이 필요하다고 확신하지 않습니다. 요점은 (대부분의 경우) uint에 플랫폼의 고유 레지스터 크기가 있고 이것이 이러한 연산이 가장 의미 있는 수준이라는 것입니다.

수학/체크 패키지는 그런 사람들에게 더 나은 집이 될 수 있습니다. checked.Add 는 bits.Add 보다 명확합니다.

@minux 나는 부호 있는 체크 산술 연산을 생각하고 있었기 때문에 오버플로가 발생했습니다.

@griesemer re: base 10 Len : 말이 되네요!

원하는 경우 확인된 산술에 대한 CL을 제출할 수 있습니다. 나는 그것을 별도의 패키지 이름 아래에 두는 @jimmyfrasche 의 아이디어를 좋아합니다.

Add/sub/mul 은 bits 속할 수도 있고 속하지 않을 수도 있지만 이러한 연산에 체크된 수학만 사용되는 것은 아닙니다. 더 일반적으로, 나는 이것이 "넓은" 산술 연산이라고 말하고 싶습니다. add/sub의 경우 캐리/오버플로 결과의 1비트와 오버플로의 부울 표시기 사이에는 거의 차이가 없지만, 우리는 아마도 이것을 연쇄 가능하게 하기 위해 add-with-carry 및 빼기-with-borrow를 제공하기를 원할 것입니다. 그리고 wide mul의 경우 추가 결과에 overflow보다 훨씬 더 많은 정보가 있습니다.

체크/와이드 산술 연산을 기억하는 것은 좋은 생각이지만, 2차로 남겨두도록 합시다.

"이 패키지를 사용하려는 모든 사람은 PopCount가 무엇을 하는지 정확히 알 것입니다."

이전에 그 기능을 사용한 적이 있고 어떻게든 PopCount 이름에 익숙하지 않았습니다("팝"을 사용하는 Hacker's Delight에서 구현을 꼬집었다고 확신하기 때문에 알아야 하지만).

나는 내가 파티에 있다는 것을 알고 있지만 "OnesCount"가 나에게 훨씬 더 분명해 보이며 "PopCount"라는 단어가 문서 댓글에 언급되면 그것을 찾는 사람들이 어쨌든 그것을 찾을 것입니다.

체크/와이드 산술 관련: #6815. 하지만 네, 1라운드를 시작합시다!

@griesemer 는 다음

(base 2) Len 함수는 거의 log2이지만 본질적으로 여전히 비트 계산 함수입니다. 밑이 10인 Len 함수는 실제로 로그 함수입니다. 유용하다는 것은 부정할 수 없지만 이 패키지에는 적합하지 않은 것 같습니다.

난에 게시 지난 10 월 "진수 길이"문제에 대한 몇 가지 접근 방식을 비교하는 벤치 마크 쓴 요지를 .

제안으로 수락됨; 앞으로 약간의 조정이 있을 수 있으며 괜찮습니다.

@rogpeppe : PopCount 을 OnesCount 로 변경했습니다( PopCount 을 사용하라는 제 제안처럼). 문서 문자열에서 "인구 수"를 참조합니다.

@rsc 당, 지금은 체크/와이드 산술 연산을 생략합니다.

또한 @rsc에 따라 모든 카운팅 함수는 int 값을 반환하고 사용 편의성을 위해(#19113에 주목) 회전 수에 int 값을 사용합니다.

LenN 함수는 단순히 N - LeadingZerosN 임에도 불구하고 에 남습니다. 그러나 비슷한 대칭이 RotateLeft / Right 하며 우리는 둘 다 가지고 있습니다.

TrailingZeroes 대해 약간 더 빠른 구현을 추가하고 테스트를 완료했습니다.

이 시점에서 사용 가능한 첫 번째 구현이 있다고 생각합니다. https://go-review.googlesource.com/36315 , 특히 API에서 코드를 검토하세요. 우리 모두가 행복하다면 이것을 제출하고 싶습니다.

다음 단계:

• 더 빠른 구현(기본)
• 추가 기능 추가(보조)

우리는 새로운 패키지를 디자인하고 있습니다

@minux 당신은 새로운 수학/큰을 의미합니까? 어딘가에서 프로세스를 따를 수 있습니까?

@TuomLarsen : @minux 는 "새 패키지"로 수학/비트를 참조했습니다. 그는 수학/비트가 사용되는 경우로 수학/빅을 언급했습니다. (앞으로 귀하의 의견을 보다 구체적으로 작성하여 귀하가 말하는 내용을 검색하고 추측할 필요가 없도록 하십시오. 감사합니다.)

CL https://golang.org/cl/37140에 이 문제가 언급되어 있습니다.

Go 1.9의 수학/비트에서 컴파일러 지원 내장화가 있습니까?

@cespare 도달 여부에 따라 다릅니다(@khr?). 그것과는 별개로, 우리는 적절한 플랫폼 독립적 구현을 ​​원합니다. (수학/대형을 수학/비트 사용으로 완전히 옮기고 싶지 않은 이유 중 하나는 현재 더 빠른 수학/대형에 플랫폼별 어셈블리가 있기 때문입니다.)

내 접시에는 적어도 아치에 대해서는 이미 내장되어 있습니다.
(386,amd64,arm,arm64,s390x,mips, 아마도 ppc64).

2017년 2월 17일 금요일 오후 12시 54분, Robert Griesemer < [email protected]

썼다:

@cespare https://github.com/cespare 도달 여부에 따라 다릅니다 (
@khr https://github.com/khr ?). 그것과 별개로 우리는
적절한 플랫폼 독립적 구현. (우리가 하지 않는 이유 중 하나는
수학/비트를 수학/비트 사용으로 완전히 옮기고자 하는 것은 현재 우리가
더 빠른 math/big에 플랫폼별 어셈블리가 있습니다.)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/18616#issuecomment-280763679 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AGkgIIb8v1X5Cr-ljDgf8tQtT4Dg2MGiks5rdgkegaJpZM4Lg5zU
.

x86-64에서 인구 수를 구현하는 가장 빠른 방법에 대한 이 기사가 도움이 될 수 있습니다. 손으로 코딩한 어셈블리는 속도와 단순성 면에서 내장 기능을 능가합니다. – Dan Luu, 2014년 10월

CL https://golang.org/cl/38155에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/38166에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/38311에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/38320에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/38323에 이 문제가 언급되어 있습니다.

더 많은 토론:

나:

math/bits.RotateLeft는 현재 인수가 0보다 작은 경우 패닉하도록 정의되어 있습니다.
arg가 0보다 작은 경우 오른쪽 회전을 수행하도록 RotateLeft를 정의하도록 변경하고 싶습니다.

이 패닉과 같은 기본 루틴을 갖는 것은 불필요하게 가혹한 것처럼 보입니다. 음수만큼 회전하는 것은 0으로 나누기(패닉 발생) 대신 단어 크기(패닉하지 않음)보다 큰 시프트와 더 유사하다고 주장합니다. 0으로 나누기는 실제로 당황해야 합니다. 대신 반환할 합리적인 결과가 없기 때문입니다. 음수만큼 회전하면 반환할 수 있는 완벽하게 정의된 결과가 있습니다.

이제 둘 중 하나를 다른 하나와 함께 구현할 수 있지만 RotateLeft와 RotateRight를 별도의 기능으로 유지해야 한다고 생각합니다. 표준 사용법은 여전히 ​​음수가 아닌 인수와 함께 사용됩니다.

우리가 여기서 뭔가를 하려면 동결로 해야 합니다. 일단 go 1.9가 나오면 마음을 바꿀 수 없습니다.

롭:

정말 이런 것을 원하신다면, 왼쪽에는 양수를, 오른쪽에는 음수를 사용하는 회전 기능만 있으면 됩니다.

나:

문제는
bits.Rotate(x, -5)

이 코드를 읽을 때 왼쪽 또는 오른쪽으로 회전하는지 여부는 명확하지 않습니다.
bits.RotateRight(5)
수학/비트에 두 배의 회전* 함수가 있음을 의미하더라도 훨씬 더 명확합니다.

마이클 존스:

부호 있는 회전은 코드에서 점프를 의미합니다. 예? 불쌍해 보인다.

나:

아니요, 제안된 의미 체계를 사용하면 실제로 구현이 더 간단합니다. 하위 6비트(64비트 회전의 경우)를 마스킹하면 제대로 작동합니다.

나는 서명된 인수가 있는 단일 회전을 선호합니다. 이는 함수 수의 절반을 의미하고 패닉이나 조건 분기 없이 모든 경우에 매우 효율적으로 수행될 수 있기 때문입니다.

어쨌든 회전은 전문 기능이므로 이를 사용하는 사람들은 긍정적인 인수가 왼쪽으로 이동하고 부정적인 인수가 오른쪽으로 이동한다는 점을 기억하는 것이 편안할 것입니다.

항상 차이를 분할하고 서명된 인수와 함께 RotateLeft 만 제공할 수 있습니다. 그것은 방향에 대한 편리한 니모닉을 제공하지만 중복 기능을 피합니다.

@bcmills @robpike 또한 https://github.com/golang/go/issues/18616#issuecomment -275598092에서 시작하여 몇 가지 의견에 대해 계속해서 이 정확한 주제에 대한 이전 토론을 참조하십시오.

@josharian 나는 댓글을 보았지만 여전히 내 버전을 선호합니다. 이것은 영원히 자전거를 탈 수 있지만 구현하기 쉽고, 정의하기 쉽고, 이해하기 쉽고, 문서화하기 쉽습니다. 나는 서명된 인수가 있는 단일 회전 함수가 부호를 정의할 필요성을 제외하고는 모든 것을 충족한다고 생각하지만 왼쪽은 양수이므로 회전 명령을 사용할 수 있는 모든 사람에게 직관적이어야 합니다.

그러나 그 왼쪽은 회전 명령을 사용할 수 있는 모든 사람에게 직관적이어야 합니다.

나는 스스로 회전 명령을 사용할 수 있다고 생각하고 내 직감은 "이런, 왜 이것이 방향이 무엇인지 말하지 않습니까? 아마도 왼쪽이지만 확실하게 문서 할 것 입니다." 긍정적인 방향을 선택하려는 경우 왼쪽 회전이 될 것이라는 직관적인 데 동의합니다. 하지만 어떤 것이 매우 명백하게 정답이 되기에는 훨씬 더 높은 임계값이 있어서 모든 호출 사이트에서 말할 필요 없이 회전하는 방향이 무엇인지 명확합니다. 그것.

가독성에 관해서는 time.Duration API 라인을 따라가는 것은 어떻습니까?

const RotateRight = -1

bits.Rotate(x, 5 * RotateRight)

비트로 정의된 상수 또는 독자(호출 사이트)를 위한 연습일 수 있습니까?

@aclements 따라서 인수의 부호만 다른 동일한 기능을 가진 두 개의(N 유형의 배) 함수가 생성됩니다. 이제 우리는 Add 및 Sub에 대해 그것을 허용하지만 내가 생각할 수 있는 유일한 예입니다.

숫자 축에서 양수는 오른쪽으로 증가하므로 부호에 의해 정의된 방향 회전/이동이 양수에 대해 비트를 오른쪽으로 이동할 것으로 예상합니다.

[문서화] 반대의 경우 문제가 없지만 직관적이라고 부르지는 않습니다.

@cznic 비트는 오른쪽에서 왼쪽으로 쓰여지지만

또한 양방향으로 작동하게 하는 경우 Rotate (https://github.com/golang/go/issues/18616#issuecomment-275016583)에 찬성합니다.

방향에 대한 @aclements 우려에 대한 반론으로서: 오른쪽으로 회전할 때도 작동하는 RotateLeft 를 제공하면 잘못된 보안 감각을 제공할 수도 있습니다. " RotateLeft 되어 있으므로 확실히 회전하지 않습니다. 오른쪽!". 즉, RotateLeft 라고 표시되면 다른 작업을 수행하지 않는 것이 좋습니다.

또한 bits.Rotate 은 실제로 전문가 코드에서만 사용됩니다. 이것은 많은 프로그래머가 사용하는 기능이 아닙니다. 그것을 정말로 필요로 하는 사용자는 회전의 대칭을 이해할 것입니다.

@나다니

비트는 오른쪽에서 왼쪽으로 쓰여지지만

비트는 이진수일 뿐입니다. 모든 기수에서 숫자의 숫자는 왼쪽에서 오른쪽으로 기록됩니다. 모든 것은 아니지만 대부분의 오른쪽에서 왼쪽 쓰기 시스템에서도 마찬가지입니다. 123은 삼백이십일이 아니라 백이십삼입니다.

숫자에 대한 피승수의 거듭제곱이 오른쪽으로 감소한다는 것은 다른 것입니다.

다시 한 번: 나는 방향에 대해 신경 쓰지 않습니다. 직관적인 방향은 개인적인 상상의 문제일 뿐입니다.

나는 회전을 좋아합니다. 최하위 비트는 직관적으로 충분히 0입니다.

개발자의 절반이 잘못 기억할 작업을 하는 대신 RotateLeft와 RotateRight를 모두 유지하십시오. 하지만 음수를 처리하는 것은 괜찮은 것 같습니다.

개발자의 99%는 회전 명령을 프로그래밍하지 않으므로 명확한 방향에 대한 필요성은 기껏해야 약합니다. 전화 한 통이면 충분합니다.

이 논의를 다시 일깨워준 문제는 두 가지를 모두 갖추려면 음수 값이 괜찮은지 여부와 그렇지 않은 경우에 대해 논의해야 한다는 것입니다. 하나만 있으면 전체 논쟁이 사라집니다. 더 깔끔한 디자인입니다.

깔끔한 디자인에 대한 주장에는 다소 공감하지만 "RotateRight"에서 "Right"를 제거하면서 동일한 구현을 유지해야 하는 것이 이상해 보입니다. 실용적인 측면에서 질문에 대답하는 유일한 방법은 이름이 제기하는 질문을 통해 문서를 보는 사람들에게 문서를 읽도록 강요하는 것입니다.
결국 음수 값에 대한 명확한 방향 대 모호하지 않은 동작의 문제입니다. 음수 값은 일반적인 경우에 덜 문제가 될 것입니다.

내가 말하는 것은 회전이 모든 사람들에게 하나의 질문을 제기하고 문서를 통해 간접적으로 대답한다는 것입니다.
RotateRight는 문서에 관심이 있다면 문서를 읽을 수 있고 읽어야 하는 소수의 사람들에게 한 가지 질문을 제기합니다.

반면에 회전은 아마도 사람들이 if n < 0 { RotateLeft(...) } else { RotateRight(...) } 를 쓰는 것을 방지할 것입니다.

@ golang / 제안서 검토는이 문제를 논의하고 한 기능을 가진, 그러나 그것을 명명에 결국 RotateLeft 다만,하지 Rotate 호출 사이트에서 추가 명확하게하기 위해. 음수는 오른쪽으로 회전하며 문서에서 이를 명확히 할 것입니다.

CL https://golang.org/cl/40394에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/41630에 이 문제가 언급되어 있습니다.

이 시점에서 원래 제안과 몇 가지 추가 기능이 설계 및 구현되었습니다. 시간이 지남에 따라 이 라이브러리에 추가할 수 있지만 현재로서는 합리적으로 "완벽한" 것 같습니다.

특히 다음과 같은 기능을 결정하거나 구현 하지 않았습니다 .

• add/mul/etc 오버플로 여부 테스트
• 들어오는 캐리를 받아들이고 결과와 캐리(또는 더 높은 단어)를 생성하는 add/mul/etc를 구현하는 기능을 제공합니다.

개인적으로 나는 그것들이 "비트" 패키지에 속한다고 확신하지 않습니다(테스트가 그럴 수도 있음). 다중 정밀도 add/sub/mul을 구현하는 함수는 일부 수학/큰 커널의 순수한 Go 구현을 허용하지만 세분성이 옳다고 생각하지 않습니다. 우리가 원하는 것은 벡터에서 작동하는 최적화된 커널과 최대 해당 커널에 대한 성능입니다. add/sub/mul "본질"에만 의존하는 Go 코드로 이를 달성할 수 있다고 생각하지 않습니다.

따라서 현재로서는 큰 반대가 없는 한 이 문제를 "완료"로 닫고 싶습니다. 폐쇄에 반대하는 경우 다음 주에 걸쳐 발언하십시오.

나는 그 라인을 따라 기능을 추가하는 것에 찬성합니다.

나는 그들이 그들의 집합적 기능을 더 잘 반영하는 이름을 부여하는 것 외에 다른 이유가 없다면 그것들이 그들 자신의 패키지에 속한다고 강력하게 믿습니다.

:+1: 이 문제를 종료할 때 및 :heart: 지금까지 완료된 작업에 대해.

이의가 없어 폐쇄합니다.

이것은 API에 관한 향후 결정에 대한 의견입니다. 이 특정 항목이 설정되어 있음을 이해합니다.

Rotate 는 전문 기능입니다. LTR 또는 RTL은 주어진 컨텍스트에서만 관련이 있습니다. @aclements 가 유효한 질문을 제기

그러나 대신 영리함이 뒤따릅니다.

"전문 기능"이 의미하는 것은 그렇게 간단한 것이므로 빨리 무시되었을 것입니다. 코드 샘플이 주어지면 코드 라인을 만나기 전에도 회전이 발생하고 방향을 이미 이해하고 있을 것입니다. 이러한 코드는 대개 이미 있는 그대로의 예시적인 ASCII 문서가 선행됩니다.

정신적으로 혼란스러운 것은 Go가 단순히 API 관점에서 비트를 해석하는 표준 방법으로 RTL을 선택할 수 있다는 것이 아니라, 먼저 1.9의 변경 사항을 가져와서 상대가 없는 RotateLeft를 찾았고 문서에서 부정적인 보폭. 이것은 1.9에 상륙하는 것이 매우 불행한 마음을 마비시키는 위원회와 같은 결정입니다.

나는 미래를 위해 사용 컨텍스트를 고수하기를 간청합니다. 이 모든 것은 "왜 우리는 RotateLeft에 대응하는 것을 제공하지 않고, 부정적인 보폭에 대해 당황하거나 보폭에 대해 int 대 uint에 대해 토론하는 이유는 무엇입니까?"와 같은 질문으로 자명해야 합니다. 결국 '전문적 기능'이 의미하는 바는 영리하지 못하다는 이유로 쉽게 외면당했다고 생각하기 때문이다.

API를 정당화하는 데 영리함을 피하도록 합시다. 이 1.9 업데이트에서 보여줍니다.

https://golang.org/cl/90835 에서 이 문제를 언급 변경: cmd/compile: arm64 intrinsics for math/bits.OnesCount