@brtzsnrおそらく、提案プロセスのステップで概説されているように、このドキュメントを提案リポジトリに送信する必要があり

テンプレートに続いてすでにマークダウンされているため、CLにコピーアンドペーストしてファイルdesign / 18616-bit-twiddling.md（またはその他）を作成するのは簡単です。

@cespare from https://github.com/golang/proposal 「作成者がデザインドキュメントを作成したい場合は、作成できます」。 デザインドキュメントとしてスタートしましたが、提出したいという気持ちが強ければ大丈夫です。

私はこれで大丈夫だと思います、それは多くのアルゴリズムライブラリで使用される十分に一般的な機能であり、数学/ビットは適切な場所のようです。

（1つには、math / bigはnlz（== clz）も実装します。）

名前については、おそらくいくつかの自転車の脱落があります。 私は、関数が何をするかよりも、何を返すかを言う方が好きです。 これにより、名前が短くなる可能性があります。 例えば：

bits.TrailingZeros64(x)ではなくbits.CountTrailingZeros64(x)

などなど。

提案はかなり明確で最小限のようです-設計ドキュメントはやり過ぎのようです。 現時点ではCLの方が適切だと思います。

（これは、APIと基本的な実装を備えたCLです。設計ドキュメントの代わりに議論するためです。この提案を受け入れるかどうかを決定する必要があります。）

@brtzsnrはすでに設計ドキュメントを作成しています。これは問題の説明にあり、テンプレートに従います。 これらのドキュメントをすべて1か所にまとめることには何らかの価値があると思いました。

ハードウェアサポートテーブルにリストされている最後のアーチは「BSWAP」です-タイプミス？

これを書いてくれてありがとう。

ctzおよびclzのdoc文字列は、0が渡されたときの結果を指定する必要があります。

また、CountTrailingZeros32よりもTrailingZeros32の方が好きです。 Ctz32にも満足しています。 それは簡潔で、ほとんどの人に馴染みがあり、残りの人は簡単にグーグルで検索できます。

提案してくれてありがとう。
指示だけに焦点を合わせるのではなく、おそらく使用にも焦点を合わせたいと付け加えたいと思います。 たとえば、 @ dr2chaseは、コンパイラ/アセンブラにいくつかのlog2関数があることを一度見つけました。 CLZに近いですが、同じではありません。 このような機能は、おそらくビットをいじるパッケージにも含まれているはずです。 また、これらの指示に関係のない便利な機能も含まれている可能性があります。

によって定義されたすべてのビットをいじるプリミティブのパッケージを提供するのはどうですか
ハッカーの喜び？

パッケージを設計する際に、機能かどうかを考慮する必要はありません。
内在化することもしないこともできます。 最適化は後で行うことができます。 あれは、
低レベルの実装に高レベルのパッケージを制御させないでください
インターフェース。 たとえそれらのいくつかができないとしても、私たちは良いパッケージインターフェースを望んでいます
単一の命令にマップされます。

@minux 、幸いなことに、これまでに必要だったすべてのビット調整関数は、まさにこの提案に含まれているものです。

Hacker's Delightに従うことには、名前について議論する時間を無駄にする必要がないという利点があります。

以下を追加したいと思います。

ReverseBits（uint32およびuint64の場合）
RotateLeft / Right（2シフトでインライン展開できますが、コンパイラー
シフト範囲の問題により、常に変換を実行できるとは限りません）

たぶん、加算と減算の2つの結果形式もありますか？ 例えば

func AddUint32（x、y、carryin uint32）（carryout、sum uint32）//キャリーインマスト
0または1になります。
そして、uint64についても同様です。

そしてSqrtInt。

私の提案の多くは単一の命令で実装することはできませんが、
それがポイントです：私たちは単なるものではなく、ちょっといじるパッケージが欲しいのです
intrisicsパッケージ。 ハードウェアが高レベルのパッケージを制限しないようにしてください
インターフェース。

関連して、加算/乗算がオーバーフローするかどうかをチェックする関数。

関連するデータポイント：より高速なcgoのために提出されたさまざまな問題があります。 そのような例の1つ（提案＃16051）では、bsr / ctz / etcの高速実装という事実。 goを書いている人々がcgoを使いたがっている一連のユースケースでうまくいけば欠けていると言われたかもしれません。

@aclementsは2016年7月1日にコメントしました：

@eloff 、サポートされている場合は組み込み関数としてコンパイルされるpopcountやbsrなどの関数を追加するためのいくつかの議論がありました（私の知る限り具体的な提案はありませんが）（math.Sqrtは今日です）。 1.7では、ランタイムでこれを試しています。これにより、amd64SSAでctz組み込みが使用できるようになります。 明らかに、それは全体的な問題を解決するわけではありませんが、オーバーヘッドの少ないコンテキストでcgoを使用するもう1つの理由があります。

パフォーマンスのおかげで多くの人（私も含めて）が行きたがっているので、この現在のちょっとしたいじりの提案のようなものが役立つでしょう。 （はい、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))
}

次に、（＆63を介して）コンパイラーがkの範囲が制限されていることを認識していることを確認できます。
したがって、コンパイラが入力が制限されていることを証明できない場合は、追加のANDが必要です。 これは、回転アセンブリをまったく生成しないよりも優れています。

金には、2017年1月13日午前10時37分PMで、キース・ランドール[email protected]
書きました：

@brtzsnr https://github.com/brtzsnr：Minuxが参照しているものだと思います
toは、（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で高速化できます。

23:24時金、2017年1月13日には、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ネイティブ実装があります。 一方、rotateは、コンパイラが認識できる方法でインラインで簡単に記述できます。

@minuxと他のすべての人：一定でない数の回転ビットで左/右回転が使用される場所を知っていますか？ たとえば、crypto / sha256はrotateを使用しますが、ビット数は一定です。

回転は、コンパイラが認識できる方法でインラインで簡単に記述できます。

コンパイラの内部に精通している人にとっては簡単です。 それを数学/ビットパッケージに入れると、誰にとっても簡単になります。

回転ビットの数が一定でない場合に、左/右回転が使用される場所を知っていますか？

＃9337の例を次に示します。

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

各呼び出しでは、毎回一定数のローテーションされたビットですが、関数自体は現在インライン化されていないため、ローテーション命令なしでコンパイルされます。 数学/ビットライブラリ関数は間違いなくここで役立ちます。

土では、2017年1月14日午前5時05分AMで、アレクサンドルMoşoi [email protected]
書きました：

現在提案されている関数には、はるかに大きなGoネイティブ実装があります
最適よりも不釣り合いに高価です。 一方、回転します
コンパイラが認識できる方法でインラインで書くのは簡単です。

この問題で何度も強調したように、これは正しい方法ではありません
Goパッケージを設計します。 基盤となるハードウェアとの結びつきが強すぎます。 私たちが何を
wantは、一般的に役立つちょっとした調整パッケージです。 どうにか
関数を単一の命令に拡張できる限り、関係ありません
APIインターフェースはよく知られており、一般的に便利です。

@minux https://github.com/minuxそして他のみんな：知っていますか
左/右回転は、一定数の回転ビットで使用されますか？
たとえば、crypto / sha256はrotateを使用しますが、ビット数は一定です。

実際の問題では、回転のビット数が一定であっても、
コンパイラはそれを見ることができないかもしれません。 シフトカウントが保存されている場合など
配列内、またはループカウンター内に非表示、あるいはインライン化されていない呼び出し元
関数。

可変数の回転を使用する簡単な例の1つは、興味深いものです。
popcountの実装：
// 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(x, y uint64) (c, s uint64) ？ math/bigを見ると、おそらくAdd(x, y uintptr) (c, s uintptr)も必要です。

rotがインライン化されていない場合、この例は悪いインライン化決定のように見えます。

はい。 これは、インライン化について不平を言うバグの一部です。 :)

関数をrot = func（x、n）ではなくfunc rot（x、n）として記述しようとしましたか？

それは私のコードではありません-そしてそれは要点の一部です。 そしてとにかく、それは合理的なコードです。

暗号化アルゴリズムで安全に使用できるように、rotate関数とbyte-swap関数が定数時間の操作であることを（パッケージのドキュメントで）保証すると便利です。 おそらく他の機能についても考える必要があります。

木では、2017年1月19日11:50で、マイケル・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が小さくなり、それでも実装に関しては十分に高速です）
• いくつかの名前の自転車の脱落（私は「ハッカーの喜び」という用語が好きですが、それを綴る方が適切かもしれません）
• このパッケージには数学/ビットよりも良い場所がありますか？

@brtzsnrこの取り組みの先頭に立ち続けますか？ 最初の設計を採用してこの号で繰り返したい場合、または専用の設計ドキュメントを設定したい場合は問題ありません。 または、これを手に取って前に進めることもできます。 私はこれが1.9フェーズの間に入るのを見るのが好きです。

個人的には、スペルアウトされたxx名の方が好きです：bits.TrailingZeroes（uint64（x）、32）は、bits.TrailingZeroes32（x）、imoよりも扱いにくく、読みにくく、その命名スキームはプラットフォーム変数サイズで機能しますuintptrがより簡単になります（xx = Ptr？）。

また、たとえば、最初のリリースにuint8を含めなかったが、後で追加した場合は、さらに明確になります。突然、8を追加する一連の更新されたドキュメントコメントの代わりに、多くの新しいxx = 8関数があります。見逃しがちなリリースドキュメントのメモとともに、有効なサイズのリストに移動します。

スペルアウトされた名前が使用されている場合、間違ったスペルを検索した場合に検索（ページ内または検索エンジン経由）で正規名を簡単に見つけられるように、ハッカーの喜びの用語を「別名」として説明に含める必要があると思います。 。

数学/ビットは素晴らしい場所だと思います—それはビットを使った数学です。

SwapBytes{16,32,64}は、 sync/atomicよりもSwapBytes(..., bitSize uint) sync/atomic関数との整合性が高いことに注意してください。

がstrconvパッケージを使用しParseInt(..., bitSize int)パターンを、間のより関連があるbitsおよびatomicであるよりも、 strconv 。

SwapBytes（uint64、size uint）が気に入らない3つの理由：

1. サイズがコンパイル時定数でない場合に使用する可能性があります（
   少なくとも現在のコンパイラに）、
2. 多くの型変換が必要です。 最初にuint32をに変換します
   uint64、そしてそれを元に戻す。
3. 将来のジェネリックのためにジェネリック名SwapBytesを予約する必要があります
   関数のバージョン（Goがジェネリックスのサポートを取得したとき）。

@griesemerロバート、提案を引き継いでください。 この提案を1か月以内に進める時間はありますが、それまでは進展が止まらないはずです。

フォームの署名には明確な好みがあるようです。

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

スワップ関数のセットもあるかもしれません。 個人的に私はこれらについて懐疑的です：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 has has
RBIT命令。

@griesemer次のような関数の型署名に関する限り

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

RotateLeftNなどは、簡単に内在化するために必要なため（可能な場合）、またはそれがドメインであるという理由だけで、uintを取りますか？ 強い技術的ニーズがない場合は、負の値が意味をなさない場合でも、intを取得するためのより強力な前例があります。 強い技術的ニーズがある場合、それらは規則性のための適切なNのuintNである必要がありますか？

OnesNとその同類は、そうでない限りintを返す必要があります。そうしないと、これらの演算を他のビット演算と組み合わせることができます。その場合、適切なNに対してuintNを返す必要があります。

@jimmyfrascheそれはドメインだからです。 CPUは気にしません。 何かがintであるかuintであるかは、比較を除くほとんどの操作には関係ありません。 とはいえ、それをintにすると、決して負ではない（結果）、負であってはならない（引数）、または負の場合に何をすべきか（回転の引数）を指定する必要があります。 その場合、1回の回転で逃げることができるかもしれません。

intを使用すると作業が簡単になるとは思いません。 適切に設計されている場合、uintはuintに流れ（math / bigの場合）、変換は必要ありません。 ただし、変換が必要な場合でも、CPUコストの点では無料になります（読みやすさの点ではありませんが）。

しかし、そうでなければ説得力のある議論を聞いたり見たりすることができてうれしいです。

回転ビット数は、（特定のサイズなしで）uintである必要があります。
言語のシフト演算子。

intを使用しない理由は、かどうかがあいまいになるためです。
RotateRight-2ビットはRotateLeft2ビットと同じです。

@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ビットローテーションに対してmod32を効果的に実行しています。

唯一の本当の議論は、stdlibの残りの部分との規則性です。 uintが非常に理にかなっている場所はたくさんありますが、代わりにintが使用されます。

math / bigは注目に値する例外なので、これが別のものであることに問題はありませんが、考慮すべき点があります。

@minuxは、実装のあいまいさではなく、コードを読んだりデバッグしたりする人にとってのあいまいさを意味していると

パッケージの名前がす​​でにbitsと呼ばれている場合、bits.SwapBitsには実際にビットサフィックスを付けて名前を付ける必要がありますか？ ビットスワップはどうですか？

もう1つのアイデアは、bits.SwapBytesではなくbits.SwapN（v uint64、n int）です。ここで、nは、スワップのためにグループ化するビット数を表します。 n = 1の場合、ビットが逆になり、n = 8の場合、バイトが交換されます。 1つの利点は、bits.SwapBytesが存在する必要がなくなったことです。ただし、他のnの値が必要になることは一度も見たことがありませんが、他の人が同意しない可能性があります。

上でLeadingZeros64 、 TrailingZeros64 、 Ones64すべてのLGTM。

署名されたローテーション金額を持つ単一のRotate64は魅力的です。 ほとんどの回転も一定量で行われるため、（これが組み込みになる場合）、個別の右/左関数を使用しないことによる実行時のコストは発生しません。

ビット/バイトのシャッフル/スワッピング/リバースについては強い意見はありません。 ビットを逆にするために、 bits.Reverse64はより良い名前のようです。 そしておそらくbits.ReverseBytes64 ？ Swap64は少し不明瞭だと思います。 Swap64にグループサイズをとらせることの魅力はわかりますが、グループサイズが64を均等に分割しない場合の動作はどうなりますか？ 重要なグループサイズが1と8だけの場合は、それらに別々の関数を与える方が簡単です。 また、ある種の一般的なビットフィールド操作の方が優れているのではないかと思います。おそらく、arm64およびamd64BMI2の命令を参考にしてください。

整数の数学関数がこのパッケージに含まれているとは思いません。 それらは、実装でビット関数を使用できるパッケージ数学に属しているように見えます。 関連して、なぜfunc Sqrt(x uint64) uint32 （ uint64を返す代わりに）ではないのですか？

AddUint32と友達は複雑ですが、最終的には再訪したいと思います。 他のことに加えて、 MulUint64はHMULへのアクセスを提供します。HMULは、超ミニマリストのRISC-VISAでさえ命令として提供されます。 しかし、はい、最初に何かを取得しましょう。 後でいつでも拡張できます。

bitsは明らかに正しいパッケージ名のようです。 インポートパスはmath/bitsではなくbitsである必要があると言いたくなりますが、私は強く感じません。

ビットは明らかに正しいパッケージ名のようです。 インポートパスは数学/ビットではなくビットだけである必要があると言いたくなりますが、私は強く感じていません。

IMO、それがbitsだけだった場合、（パッケージのドキュメントを読まずに）パッケージbytesいくらか似ていると思います。 つまり、ビットを操作する関数に加えて、バイトストリームとの間でビットを読み書きするためのReaderとWriterが見つかると思います。 math/bitsすると、ステートレス関数のセットだけがより明確になります。

（ビットストリーム用にリーダー/ライターを追加することは提案していません）

署名された回転量を持つ単一のRotate64は魅力的です。 ほとんどの回転も一定量で行われるため、（これが組み込みになる場合）、個別の右/左関数を使用しないことによる実行時のコストは発生しません。

左/右回転を1つのRotateに組み合わせることで、パッケージAPIを少し小さくすると便利なことがわかりますが、 nパラメーターを効果的に文書化することもできます。次のことを示します。

• 負のnは、左回転になります
• ゼロnは変更されません
• 正のnは、右回転になります

私には、追加されたメンタルとドキュメントのオーバーヘッドは、2つを1つのRotate結合することを正当化するようには思えません。 明示的なRotateLeftとRotateRight （ nはuintと、より直感的になります。

@mdlayher nビットワードを左にkビット回転させることは、nkビットを右に回転させることと同じであることに

その上、ハードウェア（x86など）は、kが一定でない場合でも、これを自動的に実行します。

@griesemer 、 Rotate欠点は、どちらの方向が正であるかがわからないことです。 Rotate32(1, 1) 2または0x80000000に等しいですか？ たとえば、それを使用するコードを読んでいた場合、結果は2になると予想されますが、 @ mdlayherは0x80000000になると予想しているようです。 一方、 RotateLeftとRotateRightは、符号付きまたは符号なしの引数を取るかどうかに関係なく、明確な名前です。 （ @minuxには、RotateRight by-2がRotateLeft2と等しいかどうかがあいまいであることに同意しません。これらは明らかに私と同等のようであり、他にどのように指定できるかわかりません。）

RotateLeft64と呼ばれる関数を1つだけ持ち、負の値を使用して右に回転することで修正できる

持っている少し奇妙に思えるものの@josharianは、私は、同意RotateLeftもせずにRotateRight 。 回転が計算される場合、符号付き回転を持つことの一貫性は潜在的に価値があるように見えますが、一定の回転の場合、「負の2ビットを冗談で左に回転する」よりも「2ビット右に回転する」というコードを読みたいと思います。

ドキュメントでこれを修正する際の問題は、ドキュメントが関数を呼び出すコードの読みやすさを助けないことです。

コードを書いている人は、左に回転したり、右に回転したりしたいと思っています。 それに応じて、彼らは左にも右にも回転したくありません。 左回転のみを提供する場合、右回転を希望する人は、右回転を左回転に変換する式を作成する必要があります。 これは、コンピューターが簡単に実行できる種類の表現ですが、プログラマーは間違いを犯します。 なぜプログラマーに自分で書かせるのでしょうか？

私は確信しています。

@ aclements @ ianlancetaylorポイントを取得しました。 （とはいえ、RotateLeft / Rightの実装は、おそらく、rotateの1つの実装を呼び出すだけです。）

名前のアイデアは、署名名ではなくパッケージ名にタイプを入れることです。 bits64.Onesではなくbits.Ones64 。

@btracey 、私はそこに少し口の中に投げました。 :) flag64.Intまたはmath64.Floatfrombitsまたはsort64.Floatsまたはatomic64.StoreIntはありません。

@ bradfitzgolang.org/x/image/math/f64とgolang.org/x/image/math/f32は存在しますが

私はatomicを前例として考えていませんでした（ありがたいことに、私の通常のGoの使用法ではありません）。 他の例は、パッケージが多くの異なるタイプに対して繰り返される関数のセットよりも大きいため、異なります。

bits64にアクセスして表示すると、ドキュメントが見やすくなります（たとえば、godocで）。
Ones LeadingZeros TrailingZeros

bitsに行って見る代わりに
Ones8 Ones16 Ones32 Ones64 LeadingZeros8 ...

@iand 、それもかなりグロスです。 32と64は、Aff、Mat、およびVecの既存のすべての数値接尾辞に見栄えがよくなかったと思います。 それでも、それは通常のGoスタイルではなく例外だと思います。

Goには、pkg64.fooではなくpkg.foo64命名スタイルを使用するというかなり強力な前例があります。

n個のタイプがある場合、パッケージAPIはn倍大きくなりますが、APIの複雑さはそうではありません。 これを解決するためのより良いアプローチは、ドキュメントと、godocなどのツールを介して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よりも読みやすくなっています（Log2はそこに属していると思います-そしてパッケージの命名はそれを排除する良い理由ではありません）

結局、それはスカラータイプによって「パラメータ化」された各タイプの同じAPIであるため、関数がタイプ間で同じ名前を持っている場合、コードは別々のパッケージでリファクタリングするのが簡単です-インポートパスを変更するだけです（単語全体の置換はgofmt -rを使用すると簡単ですが、カスタムサフィックス変換はより厄介です）。

関数名のビットサイズの接尾辞は慣用的なものである可能性があるという@griesmeyerに同意しますが、タイプに依存しない重要なコードがパッケージに含まれている場合にのみ、それだけの価値があると思います。

エンコーディング/バイナリから遊びを盗み、関連する事前定義されたタイプを受け入れるメソッドを持つUint64、Uint32、...という名前の変数を作成することができます。

ビット.Uint64.RightShift
ビット.Uint8。リバース
bits.Uintptr.Log2
..。

@griesemerどのようにそれらをグループ化する方法を知っているでしょうか？ ドキュメント内で実際の名前の代わりに関数名がNで終わる1つのドキュメント文字列で、不一致に一致するドキュメント文字列のない関数間で共通のプレフィックスを見つけますか？ それはどのように一般化されますか？ 非常に少数のパッケージを提供するのは複雑な特殊なケースのようです。

@rogpeppeそれは

@nerdatmathこれは、エンコーディング/バイナリの場合のように、口語的な意味では同じインターフェイスを持ちますが、Goの意味ではないため、わずかに異なります（どちらもbinary.ByteOrderを実装します）。したがって、変数は名前空間用になります。そして、godocは、型がエクスポートされない限り、どのメソッドも取得しません（＃7823）。これは別の方法で面倒です。

サイズの接尾辞は問題ありませんが、全体として、個別のパッケージを使用したいと思います。 しかし、このコメントを超えてそれをプッシュすることをわざわざするのに十分ではありません。

@nerdatmathがvarsの場合、それらは変更可能であり（ bits.Uint64 = bits.Uint8実行できます）、コンパイラーがそれらを組み込み関数として扱うのを防ぎます。これは、パッケージ（の少なくとも一部）の動機の1つでした。

変数がエクスポートされていないタイプであり、状態がない場合（エクスポートされていない空の構造体）、変数は実際には変更できません。 しかし、共通のインターフェースがなければ、godoc（今日）はひどいものになるでしょう。 それが答えなら修正可能です。

ただし、すべてが複数のパッケージを使用することになった場合でも、それを保証するのに十分な繰り返しとボリュームがある場合は、少なくとも「X / bits / int64s」、「X / bits / ints」、「X /」のようにパッケージに名前を付けてください。 「エラー」、「文字列」、「バイト」に一致する「ビット/ int32s」。 まだ多くのパッケージ爆発のようです。

複数のタイプ固有のパッケージへのパスに進むべきではないと思います。単一のパッケージビットを持つことは単純であり、Goライブラリ内のパッケージの数を増やすことはありません。

Ones64とTrailingZeroes64は良い名前ではないと思います。 彼らは彼らがカウントを返すことを知らせません。 プレフィックスCountを追加すると、名前がさらに長くなります。 私のプログラムでは、これらの関数は大きな式に埋め込まれていることが多いため、関数名を短くすると読みやすくなります。 「Hacker'sDelight」という本の名前を使用しましたが、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は、優れたグローバルプロパティがすでに失われているため、あまり役に立ちません。

私はめったにビットレベルのものをいじりません。 考えなければならなかったのは何年も前のことなので、毎回このようなものをたくさん調べなければならないので、ハッカーの喜び/ asmスタイルの名前はすべて腹立たしいほど不可解です。 必要なものを見つけてプログラミングに戻ることができるように、それが何をしたかを言っただけです。

私は@ulikunitzに同意し

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

さらに、私はそのビットに挑戦します。TrailingZeroes64は自己文書化です。 ゼロが末尾にあるとはどういう意味ですか？ 自己文書化プロパティは、ユーザーが最初に文書化のセマンティクスについて何かを知っていることを前提として存在します。 一貫性を保つためにHacker'sDelightを使用していない場合は、RotateRight64とRotateLeft64に一致するようにZeroesRight64とZeroesLeft64と呼んでみませんか？

明確にするために、私はそれを使用するときはいつでも最初にすべきことは短いエイリアスを作成することであり、与えられた名前を決して使用してはならないことを意味するつもりはありませんでした。 つまり、繰り返し使用している場合は、コードの可読性が向上すれば、エイリアスを作成できます。

たとえば、strings.HasSuffixを呼び出す場合、1回または2回呼び出すため、ほとんどの場合、指定された名前を使用しますが、1回限りのETLスクリプトなどで時々使用します。最終的にはそれを束と呼ぶことになりますので、 ends := strings.HasSuffixを実行します。これは短く、コードが明確になります。 エイリアスの定義がすぐ近くにあるので問題ありません。

非常に一般的なものには、省略名で十分です。 多くの非プログラマーはOSの意味を知っています。 Goを知らなくても、コードを読んでいる人は誰でも、funcが関数の略であることに気付くでしょう。 チャンネルはGoの基本であり、広く使用されているので、chanは問題ありません。 ビット関数が極端に一般的になることは決してありません。

TrailingZeroesは、概念に慣れていない場合、何が起こっているのかを正確に伝えることができない場合がありますが、少なくとも大まかに言って、Ctzよりもはるかに優れたアイデアを提供します。

@jimmyfrasche https://github.com/golang/go/issues/18616#issuecomment -275828661について：go / docは、名前がすべてで始まる同じファイル内の連続する一連の関数を認識するのは非常に簡単です。同じ接頭辞があり、数字のシーケンスである接尾辞や、接頭辞に対して「短い」単語である可能性があります。 これらの関数の最初の関数だけがドキュメント文字列を持ち、一致するプレフィックスを持つ他の関数は持っていないという事実と組み合わせます。 これは、より一般的な設定で非常にうまく機能すると思います。 そうは言っても、この提案を乗っ取らないように、他の場所でこれについて話し合いましょう。

参考までに、 go/doc変更について話し合い、その会話をこれとは別にするために＃18858を作成しました。

@mdlayherそれをしてくれてありがとう。

@rogpeppeパッケージ名にサイズを入れるのは

@ulikunitz私は通常、短い名前に最初に投票した人の1人です。 特にローカルコンテキスト（および非常に頻繁に使用される名前のグローバルコンテキスト）で。 しかし、ここにはパッケージAPIがあり、（少なくとも私の経験では）関数はクライアントに広く表示されません。 たとえば、math / big makeはLeadingZeros、Log2などを使用しますが、それは1つか2つの呼び出しにすぎません。 長い説明的な名前でも大丈夫だと思います。議論から判断すると、コメントの大部分はそれを支持しています。 関数を頻繁に呼び出す場合は、短い名前の関数でラップする方が安価です。 追加の通話はインライン化されます。 FWIW、Intelのニーモニックも素晴らしいものではなく、「カウント」（cnt）に重点が置かれているため、復号化する必要のある2文字が残ります。

Log2の2は必要ないことに同意します。 bits.Logは、2の底を意味します。

bits.Log64SGTM。

@griesemer私のカットオフセンテンスは、おそらく不器用な編集のアーティファクトでした。 取り外したところです。

@griesemer名前の自転車の脱落を続ける価値があるかどうか

@ulikunitzここでのフィードバックの大部分は、ショートカットではない明確な関数名を支持していると思います。

@ulikunitz 、さらに：

パッケージbigは、LeadingZerosではなくnlzを内部的に使用します。

内部のプライベートなエクスポートされていない名前は、ここでは影響を与えません。

重要なのは、パブリックAPIの一貫性と標準的な感触です。

バイクシェディングは煩わしいかもしれませんが、私たちが永遠にそれらに固執するときは名前が重要です。

CLhttps ： //golang.org/cl/36315はこの問題について言及しています。

レビュー用の初期（部分的にテスト済み）API（予備実装あり）としてhttps://go-review.googlesource.com/#/c/36315/をアップロードしました（設計ドキュメントの代わりに）。

APIが正しいことを確認しているので、今のところAPI（bits.go）についてのみコメントしてください。 マイナーな問題（タイプミスなど）については、CLにコメントしてください。 デザインの問題については、この問題についてコメントしてください。 インターフェイスに満足するまで、CLを更新し続けます。

具体的には、実装について心配する必要はありません。 これは基本的なものであり、部分的にしかテストされていません。 APIに満足したら、実装を簡単に拡張できます。

@griesemer大丈夫だと思いますが、それが役立つ場合は、テスト付きのCLZアセンブリの実装がありますhttps://github.com/ericlagergren/decimal/tree/ba42df4f517084ca27f8017acfaeb69629a090fb/internal/arith盗む/いじる/何でも。

@ericlagergrenリンクをありがとう。 APIが落ち着き、あらゆる場所でテストが実施されたら、実装の最適化を開始できます。 私はこれを心に留めておきます。 ありがとう。

@griesemer 、提案されたAPIドキュメントは、同じプレフィックスで整数のサフィックスを持つ関数を適切にドキュメント化できるgo / docに依存しているようです。

1.9より前にもそれに取り組む計画はありますか？

18858、つまり！

@mdlayherそれは理想的です。 ただし、APIには影響せず、「唯一の」ドキュメントに影響するため、目を見張るものにはなりません（今後も下位互換性を維持する必要があります）。

@ griesemer @ bradfitz関数名に関する自分の立場を再考するために時間を費やしています。 名前を選択する重要な目的は、APIを使用したコードの可読性である必要があります。

次のコードは確かに理解しやすいです：

n := bits.LeadingZeros64(x)

Ones64（x）の明確さについてはまだ少し疑問がありますが、LeadingZerosおよびTrailingZerosと一致しています。 だから私は自分の主張を休ませ、現在の提案を支持します。 実験として、テストケースを含むパッケージの実験的な純粋なGo実装に既存のコードを使用しました。

リポジトリ： https ：
ドキュメント： https ：

スワップ関数のセットもあるかもしれません[...] SwapBytesのほとんどの使用は、あるべきではないときにエンディアンを認識するコードによるものです。 コメント？

このため、 SwapBytes APIから除外したいと思います。 binary/encoding.BigEndianよりも単純である（または高速であると想定される）ため、人々が移植性のない方法でそれを使い始めるのではないかと心配しています。

このため、SwapBytesをAPIから除外したいと思います。 binary / encoding.BigEndianよりも単純である（または高速であると想定される）ため、人々が移植性のない方法でそれを使い始めるのではないかと心配しています。

@mundaymこれらのルーチンはこれまでに内在化される予定ですか？ SwapBytes64をBSWAPとして直接コンパイルさせると、不適切に使用する人よりも多くなる可能性があります、imo。

バイナリ/エンコーディングよりも単純である（または高速であると想定される）ため、人々が移植性のない方法でそれを使い始めるのではないかと心配しています。BigEndian

ReverseBytes使用は、マシンがデータをメモリに配置する方法で低レベルのデータにアクセスするunsafeと組み合わせて使用​​した場合にのみ、移植性がないと思います。 ただし、 encoding.{Little,Big}Endian.Xをそのように使用すると、移植性がなくなります。 ReverseBytesが圧縮で使用されるのを楽しみにしていますが、含まれていなかったら悲しいです。

@ericlagergren

これらのルーチンはこれまでに内在化されるのでしょうか？

はい、バイト反転を実行するencoding/binaryの関数は、コンパイラーによって認識され、整列されていないデータをサポートするプラットフォームで単一の命令（ BSWAP ）に最適化されている（または最適化できる）コードパターンを使用しますアクセス（例：386、amd64、s390x、ppc64leなど）。

SwapBytes64をBSWAPとして直接コンパイルさせると、不適切に使用している人々よりも重要になる可能性があります。

私は反対する傾向があります。 エンディアンを認識しないコードではSwapBytesが合法的に使用されている可能性がありますが、正しく使用されるよりも頻繁に誤用されると思われます。

runtime / internal / sysは、後続ゼロとバイトスワップのGo、アセンブリ、およびコンパイラ組み込みバージョンをすでに最適化しているため、これらの実装を再利用できることに注意してください。

@dsnet興味深いことに、何か具体的なことを考えていますか？

@aclementsバイトスワップ組み込み関数がランタイムのどこで使用されているか知っていますか？ テスト以外の用途は見つかりませんでした。

@ mundaym 、AFAIKランタイムでは使用されません。 内部APIにそれほど注意を払う必要はないので、簡単だったので、ctzを追加するときに追加しただけだと思います。 ：）（ポップカウントはより良い選択だったでしょう。）

すべて：今のところAPIに集中してください。 CLでの実装は、これらの関数を実際に使用してテストできるようにする、単純で遅い実装です。 APIに満足したら、実装を調整できます。

注： uint32またはuint64と同じサイズであることが保証されていないため、おそらくuintptrバージョンを含める必要があります。 （uintは常に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が最も
アーキテクチャニュートラル整数ではなく、ポインタ用。

ただし、1つの解決策は、APIに型エイリアスを導入することです（おそらくそれ
ブランドタイプである必要があります、これは議論の余地があります）。
タイプWord = uint32 //または64ビットアーキテクチャではuint64
//おそらくWordのようないくつかの理想的な定数も提供する必要があります
ビット数、マスクなど。

次に、Wordを取得するために、型接頭辞のない関数を導入します。

実際、math / bitが2つの結果を提供する場合、add、sub、mul、
div; math / bigは、アーキテクチャ固有のアセンブリなしで書き直すことができます。

math / big exports type Word uintptr 。 それは間違いだったかもしれないと私は同意しますが、互換性にはそれが残っていることが必要だと思います。 したがって、math / bitsを使用してmath / bigを実装する場合は、uintptrAPIが必要です。

少し話題から外れていますが、ネイティブの符号なしワードサイズは単なる無意味ではありませんか？ その場合、uintの接尾辞がないのはほぼ正しいようです。

単一のタイプであるWordがアーキテクチャーごとに異なることは望ましくありません。 これは、呼び出し元とドキュメントに多くの複雑さをもたらすようです。 既存のタイプに固執することは、あなたがそれを単に使うことができることを意味します。 アーキテクチャ間で型が異なるということは、その型を中心にすべてのコードを設計するか、ビルドタグで保護されたファイルに多数のアダプタを含めることを意味します。

FWIW、math / bigの実装では、uint32 / 64ベースのビットAPIを引き続き使用できます（関数のuintptrバージョンがない場合）。

@minux私は2つの結果のadd、sub、mul、divに反対していませんが、2番目のステップでそれを実行しましょう。 ただし、適切なパフォーマンスが必要な場合は、アセンブリコードが必要です。 しかし、私はコンパイラーによって他の方法で納得できてうれしいです...

uintバージョンとuintptrバージョンをAPIに追加しました。 CLを見てコメントしてください。 しかし、機能の急増にはあまり満足していません。

@josharianネイティブuintは、64ビットマシンでも32ビット値になる場合があります。 保証はありません。 uintptrはマシンのワードサイズも保証しないことを私は理解しています。 しかし当時、振り返ってみると間違っていたとしても、それはより賢明な選択のように思われました。 おそらく、本当にWordタイプが必要です。

uintptr関数の唯一の正当な必要性がmath / bigをサポートすることである場合、おそらくmath / bitsの実装は内部パッケージに入れることができます。math/ bigでuintptrのものだけを使用し、残りを公開します。

@ jimmyfrasche 、 @ griesemerそれは

uintも間違っています。 amd64p32では32ビットです。
実際、math / bigはuintptrの代わりにuintを使用できたかもしれませんが、Go1では
int / uintは常に32ビットであるため、uintptrが唯一の可能な解決策になります。
math /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ビットであったため、math / bigではuintを使用しませんでしたが、それ以降は修正されています。 math / bigはそれ自体が一貫した世界であり、独自のタイプbig.Wordを持つことは理にかなっていますが、このパッケージは、選択して選択するユーティリティルーチンのコレクションです。 このコンテキストで新しいタイプを定義することは、それほど説得力がありません。

int / uintバリアントが必要かどうかはまったくわかりません。 それらが一般的に必要な場合は、このパッケージでそれらを定義する方が、すべての呼び出し元にifステートメントの記述を強制するよりも理にかなっています。 しかし、それらが一般的に必要になるかどうかはわかりません。

math / bigとの潜在的な不一致に対処するために、ここのAPIでuintptrに言及することを含まないソリューションが少なくとも2つあります。

1. math / bigでファイルword32.goとword64.goを、ビルドタグとuintptrを使用して定義します。適切にリダイレクトするラッパーを受け入れます（コンパイラのインライン化が正しいことを確認します）。

2. big.Wordの定義をuintに変更します。 正確な定義は、APIで公開されている場合でも、内部実装の詳細です。 それを変更しても、amd64p32を除いてコードを壊すことはできず、それでもmath / big以外で問題になる可能性は非常に低いようです。

@rsc ：「64ビットシステムでは32ビットだったのでmath / bigではuintを使用しませんでしたが、それを修正しました。」ああ、そうです、uintptrを選択した理由を完全に忘れました。 Go uint / int型の要点は、マシンの自然なレジスタサイズを反映する整数型を持つことでした。 big.Wordをuintに変更して、何が起こるか見てみましょう。

すべて： https ：//go-review.googlesource.com/#/c/36315/を更新して、上記の説明に従ってuintptr関数のバージョンを除外しました。

math / bigを暫定的に更新して、math / bitsを使用して効果を確認しました（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）です。

コメント？

私はOneという名前のファンではありませんが、Leading / TrailingZerosと一致しています。 人口はどうですか？

なぜ伝統的なPopcountないのですか？

あるいは、ビット単位のxの長さであるLen関数を使用することもできます。 つまり、 `Log（x）== Len（x）-1）です。

LenまたはLengthは、良い名前と良いアイデアのように聞こえます。

1.1。

私はOneという名前のファンではありませんが、Leading /と一致しています
TrailingZeros。 人口はどうですか？

ビット数？

@aclements何を数えますか？

人口は歴史的な理由からより良い名前かもしれませんが、あなたがその用語に精通しておらず、同じ問題を抱えているのであれば、実際には1つ以上とは言えません。

パッケージ内であっても、それはやや単調ですが、CountOnesが明確で明白な名前を付けているのかもしれません。

@aclements何を数えますか？

「ビット」と呼ばれるパッケージでは、設定されたビット以外に何を数えることができるかわかりませんが、CountOnesも問題なく、明らかにより明確です。 「Ones」を追加すると、 LeadingZeros / TrailingZerosの「Zeros」にも対応します。

これが最も明白な解釈ですが、あいまいさが残っています。 未設定ビットまたは合計ビットをカウントしている可能性があります（最後の解釈は非常にありそうにありませんが、関連する概念に精通しておらず、サフィックスのないカウントはunsafe.SizeOfのように思われるビットを使用してコードを読み取る人にとっては潜在的なトラップです）

Trailing / LeadingZeroesをミラーリングするAllOnesやTotalOnesのようなものかもしれませんが、それらとは異なり、位置が考慮されないように指定します。

AllOnesは、すべてのものを返すように聞こえます（ビットマスクで？）、またはすべて1である単語かもしれません。

CountOnesとTotalOnesはほぼ同じように見えますが、この操作で最も一般的に知られている名前は「population count」であるため、CountOnesの方が望ましいと思われます。

いくつかの変更を加えた新しいバージョン（https://go-review.googlesource.com/#/c/36315/）をアップロードしました。

1） Ones名前をPopCount ：ほとんどの人は、一貫性のある、しかしやや単調な名前Onesあまり興奮していませんPopCountが何をするのかを正確に知っているでしょう。これは、この関数が一般的に知られている名前です。 他の部分とは少し矛盾していますが、その意味は非常に明確になっています。 これについてはラルフ・ワルド・エマーソンと一緒に行きます（「愚かな一貫性は小さな心のホブゴブリンです...」）。

2）私は名前を変更LogするLenのようにbits.Len 。 数値xのビット長は、xを2進表現で表すのに必要なビット数です（https://en.wikipedia.org/wiki/Bit-length）。 ふさわしいようで、ここでLogする必要がなくなります。これは、「ちょっと面倒な」品質ではありません。 Log定義方法を考えると、 Len(x) == Log(x) + 1もあるので、これも勝利だと思います。 さらに、結果が常に> = 0になるという利点があり、（些細な）実装で+/- 1の修正がいくつか削除されます。

全体として、この時点でこのAPIにはかなり満足しています（後で関数を追加したい場合があります）。 私たちが真剣に検討したいと思うかもしれない他の唯一のことは、すべての結果に署名を付けるべきかどうかです。 前に指摘したように、トレーリング/リーディングゼロ関数の結果は、符号なしでなければならないシフト演算への入力になる傾向があります。 それは、間違いなく符号なしの値も返す可能性があるLenとPopCountだけを残します。

コメント？

math / bigでの私の経験は、シフトしていないときに関数によってuintモードに強制されることに不満を感じていました。 math / big / prime.goで、私は書いた

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

s.bitLen（）がintをuintではなく返す場合でも、私は見ずに確信が持てず、将来のCLがuintを返すように変更しない可能性があることも確信していなかったため、forループが無限ループになりました。 この防御的である必要があることは、問題があることを示唆しています。

Uintは、intよりもエラーが発生しやすいため、ほとんどのAPIでUintを推奨していません。 とにかくほとんどのシフト式で必要なように、数学/ビットのすべての関数がintを返し、uintへの変換をシフト式で実行するようにした方がはるかに良いと思います。

（私は変更を提案していませんが、uintを必要とするシフトは振り返ってみると間違いだったと思います。いつか修正できるかもしれません。他のAPIを傷つけなければいいのですが。）

末尾のゼロとpopcount関数の呼び出しのためにコードをgrepした後、intを返すことをサポートしています。 呼び出しの大部分は、短い変数宣言とint型の比較です。 シフトでの呼び出しにはもちろんuint型が必要ですが、驚くほどまれです。

マイナーな調整をアップロードしました。 +1とコメントごとに、カウントの結果をintとして残しましょう。

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

RotateLeft/Rightの入力カウントをuintそうしないと、値が負の場合に何が起こるかを指定するか、許可しないようにする必要があります。

最後に、私たちも離れ去るかもしれないLen以来、すべての後にLenN(x) == N - LeadingZerosN(x) 。 意見は？

この時点で重要なフィードバックがなくなった場合は、このAPIを使用して、レビュー後に最初の実装をコミットすることをお勧めします。 その後、実装の調整を開始できます。

次のステップでは、他にどの関数を含めるか、具体的には2つの引数を使用してキャリーし、結果を生成してキャリーするAdd / Sub /などについて説明します。 。

@griは10Len関数について考えていますか？ ((N - clz(x) + 1) * 1233) >> 12

ベース2よりも「ビットハッキー」ではありませんが、それでも便利です。
17:03ロバート・グリーズマーで金、2017年2月10日には[email protected]
書きました：

マイナーな調整をアップロードしました。 +1とコメントごとにの結果を残しましょう
intとしてカウントされます。

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

RotateLeft / Rightの入力カウントをuintのままにしました。それ以外の場合は、
値が負の場合に何が起こるかを指定するか、それを許可しない必要があります。

最後に、LenN（x）== N-なので、結局Lenを除外することもできます。
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)

20:16時金、2017年2月10日には、エリックLagergren [email protected]
書きました：

また。 この問題の範囲外になっている場合はご容赦ください。
チェックされた算術の支持。 例：AddN（x、y T）（sum T、overflow bool）

署名されたオーバーフローについて話しているのですか？ または符号なしオーバーフロー（キャリー/ボロー）？

また、単純化するために、オーバーフロー/キャリー/ボローをタイプTとして返すことを好みます
多倍長演算。

@ericlagergren （基数2） Len関数は、ほぼlog2ですが、本質的にはビットカウント関数です。 基数10のLen関数は、実際には対数関数です。 それが有用であることは否定できませんが、このパッケージにはあまり適切ではないようです。

はい、 checked演算を取り入れるといいと思います。最初に現在のAPIを閉じて、前後に移動するのではなく、進歩できるようにしたかっただけです。 これまでにコメントしたほとんどの人はそれに満足しているようです。

Add、Sub関数に関して：キャリーは引数と同じ型でなければならないという@minuxに同意します。 また、これらの関数にはuint引数以外に何かが必要だとは思いません。要点は、（ほとんどの場合）uintにはプラットフォームの自然なレジスタサイズがあり、それがこれらの操作が最も理にかなっているレベルであるということです。

数学/チェックされたパッケージはそれらのためのより良い家であるかもしれません。 checked.Addはbits.Addよりも明確です。

@minux符号付きチェック演算を考えていたので、オーバーフローしました。

@griesemer re：ベース10 Len ：理にかなっています！

必要に応じて、チェック演算用のCLを送信できます。 @jimmyfrascheが別のパッケージ名で作成するというアイデアが

Add / sub / mulはbitsに属する場合と属さない場合がありますが、これらの操作の用途はチェックされた数学だけではありません。 より一般的には、これらは「ワイド」な算術演算であると言えます。 add / subの場合、1ビットのキャリー/オーバーフローの結果とオーバーフローのブールインジケーターの間にほとんど違いはありませんが、これらをチェーン可能にするために、add-with-carryとsubtract-with-borrowも提供する必要があります。 また、ワイドmulの場合、オーバーフローよりも追加の結果にはるかに多くの情報があります。

チェックされた/ワイドな算術演算を覚えておくことをお勧めしますが、ラウンド2のためにそれらを残しておきましょう。

「このパッケージを使用するすべての人は、PopCountが何をするかを正確に知っています」

私は以前にその機能を使用したことがあり、どういうわけかPopCount名に慣れていませんでした（ただし、「pop」を使用するHacker's Delightから実装をピンチしたと確信しているため、使用する必要があります）。

私はパーティーに参加していることは知っていますが、「OnesCount」は私にはかなり明白に思えます。ドキュメントのコメントに「PopCount」という単語が記載されていれば、それを探している人はとにかくそれを見つけるでしょう。

チェック/ワイド演算に関連：＃6815。 しかし、はい、1つを取りましょう！

@griesemerは書いた：

（基数2）Len関数は、ほぼlog2ですが、本質的にはビットカウント関数です。 10進数のLen関数は、実際には対数関数です。 それが有用であることは否定できませんが、このパッケージにはあまり適切ではないようです。

昨年10月に「10進数の長さ」の問題に対するいくつかのアプローチを比較するためのベンチマークを作成しました。これをた。

提案として受け入れられました。 おそらく前進するためのマイナーな調整があるでしょう、そしてそれは問題ありません。

@rogpeppe ： PopCountをOnesCountました。これは、4つの親指を立てたためです（ PopCountを使用するという私の提案のように）。 ドキュメント文字列で「人口数」と呼ばれます。

@rscごとに、チェック済み/ワイド算術演算は今のところ除外します。

また、 @ rscごとに、すべてのカウント関数はint値を返します。使いやすくするために（そして＃19113に注目して）、ローテーションカウントにint値を使用します。

単にN - LeadingZerosNであるにもかかわらず、 LenN関数を残しました。 しかし、 RotateLeft / Rightも同様の対称性があり、両方があります。

TrailingZeroesわずかに高速な実装を追加し、テストを完了しました。

この時点で、使用可能な最初の実装があると思います。 https://go-review.googlesource.com/36315のコード、特にAPIを確認してください。 私たち全員が満足しているなら、これを提出してもらいたいです。

次のステップ：

• より高速な実装（プライマリ）
• 機能の追加（セカンダリ）

新しいパッケージを設計しています

@minuxあなたは新しい数学/ビッグを意味しますか？ どこかでプロセスをたどることは可能ですか？

@TuomLarsen ： @minuxは「新しいパッケージ」で数学/ビットを参照しました。 彼は、数学/ビットが使用される場合として、数学/ビッグについて言及しました。 （将来的には、コメントをより具体的にしてください。そうすれば、参照している内容を検索して推測する必要がなくなります。ありがとうございます）。

CL https://golang.org/cl/37140は、この問題について言及しています。

Go 1.9の数学/ビットでコンパイラ支援の組み込み化が発生しますか？

@cespare到達するかどうかによって異なります（@khr？）。 それとは別に、プラットフォームに依存しない適切な実装が必要です。 （math / bigを完全にmath / bitsの使用に移行したくない理由の1つは、現在、math / bigにプラットフォーム固有のアセンブリがあり、より高速であるためです。）

私のプレートでは、少なくともアーチについては、すでに組み込み関数を実行しています
（386、amd64、arm、arm64、s390x、mips、おそらくppc64）。

2017年2月17日金曜日12:54 PM、Robert Griesemer < [email protected]

書きました：

@cespare https://github.com/cespare到達するかどうかによって異なり
@khr https://github.com/khr ？）。 それとは別に、
適切なプラットフォームに依存しない実装。 （私たちがしない理由の1つ
数学/ビッグを完全に数学/ビットの使用に移行したいのは、現在私たちが
math / bigにプラットフォーム固有のアセンブリがあります。これはより高速です。）

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/18616#issuecomment-280763679 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AGkgIIb8v1X5Cr-ljDgf8tQtT4Dg2MGiks5rdgkegaJpZM4Lg5zU
。

x86-64で人口カウントを実装する最速の方法に関するこの記事は役立つかもしれません：手作業でコーディングされたアセンブリは、速度と単純さにおいて組み込み関数を打ち負かします

CL https://golang.org/cl/38155は、この問題について言及しています。

CLhttps ： //golang.org/cl/38166はこの問題について言及しています。

CLhttps ： //golang.org/cl/38311はこの問題について言及しています。

CLhttps ： //golang.org/cl/38320はこの問題について言及しています。

CLhttps ： //golang.org/cl/38323はこの問題について言及しています。

もう少し議論：

自分：

math / bits.RotateLeftは現在、引数がゼロ未満の場合にパニックになるように定義されています。
引数がゼロ未満の場合に右回転を行うようにRotateLeftを定義するように変更したいと思います。

このような基本的なルーチンを持つことは、不必要に厳しいように思われます。 負の量の回転は、ゼロ除算（パニックを起こす）ではなく、ワードサイズ（パニックを起こさない）よりも大きいシフトに類似していると私は主張します。 ゼロ除算は、代わりに返す合理的な結果がないため、実際にはパニックに陥る必要があります。 負の量で回転すると、完全に明確に定義された結果が返されます。

RotateLeftとRotateRightは、もう一方と一緒に実装できるようになりましたが、別々の関数として保持する必要があると思います。 標準的な使用法は、非負の引数を使用します。

ここで何かをする場合は、フリーズする必要があります。 1.9がリリースされると、考えを変えることはできません。

ロブ：

このようなものが本当に必要な場合は、回転という1つの関数があります。この関数は、左が正、右が負になります。

自分：

問題は
ビット.Rotate（x、-5）

このコードを読んだときに、最終的に左に回転するのか右に回転するのかは明確ではありません。
bits.RotateRight（5）
数学/ビットに2倍のRotate *関数があることを意味する場合でも、はるかに明確です。

マイケル・ジョーンズ：

署名された回転とは、コード内でジャンプすることを意味しますね。 残念なようです。

自分：

いいえ、提案されたセマンティクスを使用すると、実装は実際には簡単になります。 下位6ビット（64ビット回転の場合）をマスクすると、正常に機能します。

関数の数が半分であり、パニックや条件分岐さえもなしにすべての場合に非常に効率的に実行できるため、符号付き引数を使用した単一のRotateを好みます。

とにかく回転は専門的な機能なので、それを使用する人々は、正の引数が左にシフトし、負の引数が右にシフトすることを覚えておくように求められることを確実に快適にします。

いつでも差を分割して、符号付き引数でRotateLeftのみを提供できます。 これにより、方向に便利なニーモニックが提供されますが、機能の重複は回避されます。

@bcmills @robpike https://github.com/golang/go/issues/18616#issuecomment -275598092から始まり、いくつかのコメントを続けるこの正確なトピックに関する以前のディスカッションも参照して

@josharianコメントを見たことがありますが、それでも自分のバージョンを好みます。 これは永遠に自転車に乗ることができますが、私は実装が簡単で、定義が簡単で、理解が簡単で、文書化が簡単になろうとしています。 符号付き引数を持つ単一のRotate関数は、符号を定義する必要があることを除いて、すべてを満たすと思いますが、左が正であるということは、rotate命令を使用できる人なら誰でも直感的に理解できるはずです。

しかし、その左が正であるということは、回転命令を使用できる人なら誰でも直感的に理解できるはずです。

私は自分が回転命令を使用できると考えるのが好きで、私の直感は「そうねえ、なぜこれがどの方向であるかを言わないのですか？おそらく残っていますが、確実にドキュメント必要があります。」 正の方向を選択する場合は左回転になるのは直感的ですが、何かが明らかに正しい答えになるにははるかに高いしきい値があるため、すべての通話サイトで、何も言わずに回転している方向が明確になります。それ。

読みやすさに関しては、 time.Duration APIに沿ったものはどうでしょうか。

const RotateRight = -1

bits.Rotate(x, 5 * RotateRight)

多分ビットによって定義された定数または多分読者のための練習（呼び出しサイト）？

@aclementsしたがって、引数の符号だけが異なる、同じ機能を持つ2つの（N型の）関数になります。 今ではAddとSubでそれを許容していますが、それが私が考えることができる唯一の例です。

数値軸では、正の数が右に増加するため、正の数の場合、符号で定義された方向の回転/シフトによってビットが右に移動すると予想されます。

それが[文書化された]反対になるかどうかは問題ありませんが、私はそれを直感的とは言いません。

@cznicビットは右から左に書かれていますが

また、双方向で機能させる場合は、 Rotate （https://github.com/golang/go/issues/18616#issuecomment-275016583）だけを支持します。

方向性について@aclementsの懸念に反論として：提供RotateLeft権利を回転させることも、誤った安心感を提供することができますも動作すること：それは言う、」 RotateLeftので、確かにそれが回転していません右！"。 つまり、 RotateLeftと表示されている場合は、他に何もしません。

また、 bits.Rotateは、実際にはスペシャリストコードでのみ使用されます。 これは、多くのプログラマーが使用する機能ではありません。 本当にそれを必要とするユーザーは、回転の対称性を理解するでしょう。

@nathany

ビットは右から左に書かれていますが

ビットは単なる2進数です。 基数の桁数は左から右に書き込まれます。すべてではないにしても、ほとんどの右から左の書記体系でも同様です。 123は、百二十三ではなく、百二十三です。

桁の被乗数の累乗が右に減少することは別のことです。

繰り返しになりますが、私は方向性を気にしません。直感的な方向性は個人的な想像力の問題であるというだけです。

私は回転が好きです。 私の見解では、最下位ビットは直感的に十分です。

開発者の半数が覚えていないことをするのではなく、RotateLeftとRotateRightの両方を維持してください。 ただし、負の数を処理するのは問題ないようです。

開発者の99％は回転命令をプログラムすることは決してないので、明確な方向の必要性はせいぜい弱いです。 1回の呼び出しで十分です。

この議論を呼び起こした問題は、両方を持つには、負の値が問題ないかどうか、そうでない場合はどうするかについて議論する必要があるということです。 1つしかないことで、その議論全体が失われます。 すっきりとしたデザインです。

クリーンなデザインについての議論には多少共感しますが、それを実現するために、同じ実装を維持しながら「RotateRight」から「Right」を削除しなければならないのは奇妙に思えます。 実際には、質問に答えるように見える唯一の方法は、名前が提起する質問によって、それを見る人々にドキュメントを読ませるということです。
結局のところ、それは明確な方向と負の値の明確な振る舞いの問題です。 一般的なケースでは、負の値はおそらくそれほど問題にならないはずです。

私が言っているのは、Rotateはすべての人に1つの質問を提起し、ドキュメントを通じて間接的にそれに答えることです。
RotateRightは、ドキュメントを気にかけている場合にそれを読むことができる（そして読むべきである）非常に少数の人々に1つの質問を提起します。

一方、Rotateは、おそらく人々がif n < 0 { RotateLeft(...) } else { RotateRight(...) }書くのを妨げるでしょう。

@ golang / proposal-reviewはこれについて議論し、結局1つの関数しか持たないことになりましたが、呼び出しサイトでさらに明確にするために、 RotateだけでなくRotateLeftという名前を付けました。 負の数は右に回転し、ドキュメントでこれが明確になります。

CL https://golang.org/cl/40394は、この問題について言及しています。

CLhttps ： //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は、有効な質問を提起しましたが、有効な拡張ポイントではありません。 彼の質問は、「整数が増加するのと同じように、RTLです」と答えられた可能性があります。 簡単ですよね？

しかし、代わりに、賢さが続きます。

「スペシャリスト機能」とは、とても単純なことで、すぐに却下された可能性があります。 コードサンプルを考えると、コード行に遭遇する前であっても、発生する回転と方向をすでに理解している可能性があります。 このようなコードの前には、通常、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