【高速化】ビット演算　0x02

【高速化】ビット演算 ..

554:518
07/11/16 13:09:18
>>553
65536より、R - 1のがいい理由は何？

555:デフォルトの名無しさん
07/11/16 13:24:06
理由は、Xが16bitの範囲を超えて入力された時の誤差が多少でも減る事だな

556:518
07/11/16 13:36:17
>>555
誤差が許される場合はいいかもね。
そうでない場合は、素直に３２ビットに拡張した方が良くないか？

557:デフォルトの名無しさん
07/11/16 14:03:01
ようするに
(A * x + A-1 ) >> B
として AのMSBが1になるように B を調整するって事だよね？

Ｂは常に32以上だから、実際には上位ワードだけを>>(B-32) するのだろうけど

558:518
07/11/16 17:10:53
>>557
いや、そうじゃなくて、余計なA - 1 という演算を使うのではなく、
550の式を32ビットに拡張すればいいってこと。

32ビット範囲の X / Dなら、R = ((1 << 64) - 1) / D として、
X / D の値は (R * X + (1 << 32)) >> 64となる。

559:デフォルトの名無しさん
07/11/17 04:25:26
>>530
ルネサスのマニュアルによるとシフト演算と割り算に迷ったら割り算の方が大抵速いみたいなことが書いてあったけど

560:デフォルトの名無しさん
07/11/17 07:26:50
>>558 さすがに64bit掛算はまだ普及してないだろ

561:デフォルトの名無しさん
07/11/17 07:28:20
>>559 SHが特殊で固定シフト命令が1,2,4,8みたいな飛び飛びのシフトしか１命令で出来なかったりするからじゃないの？

562:デフォルトの名無しさん
07/11/17 12:16:14
でも、仕事で使用するとしたら、普通に割り算したほうがソースとして見やすいよね。
2で割るのを1ビットシフトするぐらいはいいけど、あえて複雑な演算にするほど処理能力を求められないでしょ？普通の開発は。

でも、このような議論って技術者としては面白いし、ある意味大切だよね。

563:デフォルトの名無しさん
07/11/17 12:40:03
>>560
アルゴリズム上の話で、実際に64bit乗算をするわけではないと思う。

元ネタはこれじゃね？
URLﾘﾝｸ(www.emit.jp)

564:デフォルトの名無しさん
07/11/17 13:51:33
>>560
コンパイラがやってくれることもしばしば。
まぁ尤も、コンパイラのアセンブリ出力を見たときに「割り算がない」って悩まないためにも
知識はあったほうがいいのだけれどね。

565:デフォルトの名無しさん
07/11/17 13:57:31
Y = (R * X ) >> 64 って事は、R = 2^64 / D って事だろ？
Dが16bitの範囲なら Rは　48bitって事になるぞ。　64bitモードに以降しないと効率悪いぞ

566:デフォルトの名無しさん
07/11/17 14:00:28
もともと
D=100の場合

1　: ( x * 4294967200 + 65536) >> 32
2　: ( x * 4294967200 + 4294967199 >> 32
のどっちが大きな x までまともに計算出来るかって問題でしょ？

567:デフォルトの名無しさん
07/11/17 14:01:49
違うか
1　: ( x * 42949672 + 65536 ) >> 32
2　: ( x * 42949672 + 42949671 ) >> 32

568:デフォルトの名無しさん
07/11/17 15:24:56
BCCで出来ないんだけど・・・CPUのせいかもしれない
内部で32+24ビット程度しか保持していない気がする

569:デフォルトの名無しさん
07/11/17 15:33:51
>>518がちゃんとうごくぱそこんってあるの?
テストプログラム作ったけど上位1ビットの値は壊れているようだ

#include <iostream>
using namespace std;

main(){
int n;
for(n=50;n<=64;n++)
cout<<n<<" "<<(unsigned int)((1<<n)>>(n-1))<<endl;
}

570:デフォルトの名無しさん
07/11/17 15:43:45
これっていくつになりますか?
1になるはずですよね?

cout << (unsigned int) ( ((1<<64)-2) >> 63 );

571:デフォルトの名無しさん
07/11/17 17:43:47
>>570
-1を unsigned にキャストしてるんだからUINT_MAXになると思う。

572:デフォルトの名無しさん
07/11/17 18:06:10
符号付整数の右シフトが論理シフトになるか算術シフトになるかは処理系定義

573:ヽ・´∀｀・,,）っ━━━━━━┓
07/11/17 19:18:14
>>569
unsigned __int64かunsigned long longでおｋ

574:ヽ・´∀｀・,,）っ━━━━━━┓
07/11/17 19:20:40
>>570
なんで普通のコンピュータで使えるビット数越えたシフト使うんだ。
1 << 64なんてオーバーフローで0になること確定じゃないか。

575:デフォルトの名無しさん
07/11/17 20:42:48
~0ULLでおｋ

576:デフォルトの名無しさん
07/11/17 23:58:43
>>569

>>563のコードと同じだからそっちでやってみればいいんじゃないか。

577:デフォルトの名無しさん
07/11/18 07:54:51
#include <iostream>
using namespace std;

main(){
unsigned int n;
for(n=60;n<64;n++)
cout<<n<<" "<<(unsigned int)(((1<<n)-2)>>(n-1))<<endl;
cout<<63<<" "<<(unsigned int) ( ((1<<63)-2) >> 62 );
}

63の値が変わるのはなぜ?

578:デフォルトの名無しさん
07/11/18 08:34:36
>>577
サイズを超えるシフトは未定義。

579:デフォルトの名無しさん
07/11/18 22:48:23
ARMは割り算使うと糞遅いから困るな。

580:デフォルトの名無しさん
07/12/03 22:55:09
age

581:デフォルトの名無しさん
07/12/03 23:13:14
32bitパソコンだと、16*16しか値は保証されないよね
a + b * 65536　などと表示して、32bit以上を表現したら
ハードウェア搭載の除算よりビット演算のほうが速い?
除算が現れたらintを16bit数に変換して計算する

582:デフォルトの名無しさん
07/12/04 05:02:29
X = 65536 、R = 1/Xとすると

(a+bX) / (c+dX) = (b+aR) / (d+cR)であり、

1/(1+R)　のテイラー展開は、　1　-　R + R^2 - ・・・+(-R)^n+ ・・・
Rの巾は非常に小さいため2乗までを採用すると、

(a+bX) / (c+dX)　=　( (b+aR)/d ) * 1/(1 + cR/d)
=( (b+aR)/d ) * (1 - cR/d + (cR/d)^2 )
=1/(X^3 * d^3) * (a + bX ) * (c^2 -cdX + d^2X^2 )　となる

これで32bit除法を高速化出来るか?

583:582
07/12/04 05:12:33
32bit内で処理しようとすると大変だ　普通にCPUに任せた方が楽そう

584:デフォルトの名無しさん
07/12/16 20:25:38
BOOL bResultの値が 0 か -1
if (bResult == 0 || bResult == -1)

じゃなくて、一発で調べる方法はないですか？

585:デフォルトの名無しさん
07/12/16 20:42:35
BOOLなのに何故数値と比較してるんだ？

586:デフォルトの名無しさん
07/12/16 21:10:40
GetMessageじゃね？

587:デフォルトの名無しさん
07/12/16 21:30:22
BOOLは偽==0、真==0以外じゃなかったか？
定義を調べた方が良さそう。

588:デフォルトの名無しさん
07/12/16 22:05:41
世の中には変な使い方する椰子がいるのよ。MSとかw

URLﾘﾝｸ(msdn.microsoft.com)

589:デフォルトの名無しさん
07/12/16 22:08:46
if(bResult^0==-1)

590:デフォルトの名無しさん
07/12/16 22:37:38
x^0=x

591:デフォルトの名無しさん
07/12/16 22:42:19
if (((((uint32_t)bResult) + 1) >> 1) == 0)

同じ3演算だけど-1をロードしないだけ早いかも？
uint32_tがいいかどうかはよくわからない。

592:デフォルトの名無しさん
07/12/17 00:16:01
-1か0、限定なんだからそのまま書いたほうが分かりやすいような。

593:デフォルトの名無しさん
07/12/17 00:26:58
>>588
( ･д⊂ヽ゛

594:デフォルトの名無しさん
07/12/17 00:29:32
>>588
>警告 GetMessage 関数は、0 以外の値、0、-1 のいずれかを返します。したがって、次のようなコードは避けてください。

そもそも…

595:デフォルトの名無しさん
07/12/17 00:30:54
まー継ぎ接ぎだからな

596:デフォルトの名無しさん
07/12/17 00:39:34
>>591
右シフト・条件分岐より、比較・条件分岐の方が速くない？

if (((uint32_t)bResult + 1) <= 1)

597:デフォルトの名無しさん
07/12/17 00:50:04
>>596
マシン語レベルでは結局0比較に変換されるから同じ程度じゃないかな。
でもCレベルではそっちの方が短くていいと思う。

598:デフォルトの名無しさん
07/12/17 01:17:11
>>597
ちょっと前まで主流だった某CPUではシフトは加減算の
8倍遅かったし、それ以外のCPUでも演算器の関係で
シフトの方が並列化されにくいかも、とかそういう話。

599:デフォルトの名無しさん
07/12/17 01:19:21
で、何億回呼ぶのよ

600:デフォルトの名無しさん
07/12/17 02:05:25
シフトのほうが速いと思ってたのに・・・

601:デフォルトの名無しさん
07/12/17 03:12:30
>>599
そんなこと言うならこのスレの意義って一体なんなのさ。

確かにWindows APIをそんなアホみたいに呼ぶ事はないだろうが、
こんな風に一般化してみれば、それなりに使い道はあるだろ。

_Bool bounds_check(int n, int lower, int upper)
{
　return (unsigned)(n - lower) < (unsigned)(upper - lower);
}

>>600
加減算よりシフトの方が速いCPUなんてあるのかな？
演算の頻度からいっても普通は加減算を最速に設計すると思うけど。
x86系を数種類しか触った事ないから、他にはあるのかも知れないが。

602:デフォルトの名無しさん
07/12/17 04:47:19
ハードウェアの構造上加減算よりシフトの方が圧倒的に単純なんだよ
小さい加算器を作ったことがあればわかるはず
クロック数が一緒ってことはあるかもしれんが、
シフトの方が遅いってことはまずないだろう

603:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/17 05:39:05
ARMだと全命令にプレディケーション使えるからCレベルの単純な分岐は直列化できるよ
分岐は極端に遅いなんていうのはCellプログラマだけにしてください。

604:デフォルトの名無しさん
07/12/17 07:41:05
>>602
このケースは1bitだからその通りだけど
x86の8086-286までは、2bit以上のシフトは遅かったんだよ。
最初は直接bit数指定のインストラクションすらなかったし。

605:デフォルトの名無しさん
07/12/17 13:11:19
URLﾘﾝｸ(answers.google.com)

606:デフォルトの名無しさん
07/12/17 13:13:10
>>603
単純な分岐なら、if文使ってコンパイラに任せた方が速いね。
絶対値求める時とか、NULLならreturnするとか、分岐コストかからなくていい。

607:デフォルトの名無しさん
07/12/17 14:37:02
むしろif文にbool型しかとらないJava/C#が異端なんじゃねーの？
俺もbool型オンリーの方が好きだが、スクリプト言語してるとそうじゃない方が多い気がする。

608:デフォルトの名無しさん
07/12/17 18:27:51
ifの選択肢にTrueとFalse以外なんてあり得るの？

609:デフォルトの名無しさん
07/12/17 18:33:36
if(666){//実行されます。}

610:デフォルトの名無しさん
07/12/17 19:02:56
コメントに括弧閉じ書いて意味あんの

611:デフォルトの名無しさん
07/12/17 21:34:17
if (GetMessage(...) <= 0)

で充分でね?

612:デフォルトの名無しさん
07/12/17 21:49:47
>>602
シフタってのはデータセレクタの塊だから多ビットのシフトは
シリコンの面積を喰うのよ

613:デフォルトの名無しさん
07/12/17 23:54:21
>>611
-1以外の負の値が未定義

614:デフォルトの名無しさん
07/12/17 23:54:34
シフタのないプロセッサには出会ったことが無いけどね。

615:デフォルトの名無しさん
07/12/17 23:58:16
if (bResult == 0 || bResult == -1)

は

if (((uint32_t)bResult + 1) <= 1)

と同じコードになったぞ。
gcc賢いな。
ちなにみRISCでどうなるか見たかったので団子の嫌いなCELLのgccでコンパイルしたw
ちなみにCELL(SPE)もヒントブランチあるから。
むしろARMのプリディケーションいまいちだと思うけど。

616:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:11:17
知ってるが

Cellのスカラ性能が
気に食わない

617:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:45:11
分岐ヒントもBranchの15クロックくらい前くらいに入れないと駄目じゃなかったっけ
しかも二重に使うとハングする致命的なバグ持ちだから始末に困る

618:デフォルトの名無しさん
07/12/18 00:47:47
if (bResult == 0 || bResult == -1) こんなん対して食わないだろ゜

619:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:52:15
SSE4.1のXMMに対する比較命令が加わったから4条件同時判定とかも便利そうだね

620:デフォルトの名無しさん
07/12/18 08:10:08
ダンゴさんが連投するとスレが引き締まるな

621:デフォルトの名無しさん
07/12/18 11:30:40
ダンゴage

622:デフォルトの名無しさん
07/12/18 20:46:31
test

623:デフォルトの名無しさん
07/12/21 07:08:36
test

624:デフォルトの名無しさん
07/12/21 07:18:07
URLﾘﾝｸ(www.nicovideo.jp)

625:デフォルトの名無しさん
07/12/30 10:37:00
年末あげ

626:デフォルトの名無しさん
08/01/03 18:36:52
URLﾘﾝｸ(itl.jisakuita.net)

ダンゴさんすげえな

627:デフォルトの名無しさん
08/01/09 19:20:08
sge

628:デフォルトの名無しさん
08/01/14 22:47:23
V(･∀･)V

629:デフォルトの名無しさん
08/01/21 23:54:19
あげ

630:デフォルトの名無しさん
08/01/22 00:09:06
以下の2つの値があったとします。
x1 = 0xFF842144
x2 = 0x5400FF33

ユーザからの入力u1、u2が入力された場合
考えられるケースは以下の4つになると思います。
・u1=x1、u2=x2一致
・u1=x1一致
・u2=x2一致
・どちらとも一致しない

最低3回比較しないとどのケースか判断できないって
思い込んでるのですが
何かいいアイディアくれる人いませんか？

631:デフォルトの名無しさん
08/01/22 00:46:32
愚問だと思いますが。。

しかし、そんあ80年代前半のBASICの論理式みたいなアナクロな発想をするって
今日日奇特な人だね。

632:デフォルトの名無しさん
08/01/22 00:50:58
u1がx1と一致するケースに
・u1=x1一致、u2=x2一致
・u1=x1一致、u2=x2不一致
がある
u1がx1と一致しないケースに
・u1=x1不一致、u2=x2一致
・u1=x1不一致、u2=x2不一致
がある

つまり４通り
比較は最大２回

633:デフォルトの名無しさん
08/01/22 01:21:29
その比較を10^12回通りくらい計算するつもりなら最適化もあり

634:デフォルトの名無しさん
08/01/22 01:30:35
あらかじめ
p = x1 XOR x2
の値を取得しておく
q1 = p XOR u1
q2 = p XOR u2
を得る

635:ヽ・´∀｀・,,）っ━━━━━━┓
08/01/22 01:30:56
SSE4のptest使えば一回で済む

636:デフォルトの名無しさん
08/01/22 01:54:14
>>634
得た後はどうすればいいのw？
q1とq2をどうやって使うの？

637:デフォルトの名無しさん
08/01/22 02:56:20
>>632
＞・u1=x1一致、u2=x2一致
あんた馬鹿?

638:デフォルトの名無しさん
08/01/22 11:10:15
>>635
無理だろ，あれは and と andnot だから．pcmpeqd の方が良さげ

639:デフォルトの名無しさん
08/01/22 11:49:49
632ってこういうことだろ？

if( u1 == x1 ) {
if( u2 == x2 ) {
//ryouhou
} else {
//u1 nomi
}
} else {// not
if( u2 == x2 ) {
//u2 nomi
} else {
//ryouhou itti sinai
}
}

どこも間違ってるように思えないんだが。

640:デフォルトの名無しさん
08/01/22 12:34:57
しかし、BY（文脈読めない）な奴が多いな。

ここがどういうスレかを考えれば、>>630が何を聞きたいか
多少説明不足でもだいたい分かるだろ普通w

641:デフォルトの名無しさん
08/01/22 13:13:10
ほうほう。それでそれで?

642:デフォルトの名無しさん
08/01/22 18:32:50
int a[] = {両方一致, 片方一致, 片方一致, 一致しない};
b1 = (u1 == x1)
b2 = (u2 == x2)
return a[(b1 << 1) | b2];

643:642
08/01/22 18:33:45
× int a[] = {両方一致, 片方一致, 片方一致, 一致しない};
○ int a[] = {一致しない, 片方一致, 片方一致, 両方一致};

644:デフォルトの名無しさん
08/01/23 10:32:39
ゼロフラグでレジスタに0,1をセットする命令があるならソレが効率的だね。

それがないと、減算して、さらに１引いてキャリーを出してローテートしなくちゃいけない
アキュムレータが2個しかないCPUなら
AccA := u1-x1-1;
RotWithC(AccB);
AccA := AccA+x1+1-x2-1;
RotWithC(AccB);
AccB := AccB and 3;

結局、そのあたり何が効率的かはアセンブラで見ないといけないけど
アセンブラで出来る高速化は、リニアにしか効かないから、そんなに意味ないんだよね

645:デフォルトの名無しさん
08/01/23 20:55:34
全面的に同意．ただ２倍位速くなることもあるから最後の手としては有効．まぁ今は可能 intrinsic 使うけど．

646:デフォルトの名無しさん
08/01/23 21:06:35
割り算を掛け算とビットシフトに置き換える計算式求めるプログラムできた

#include <iostream>
using namespace std;
main(){
unsigned int N,n,k;
for(N=2; N<65000 ; N++){
for(n=0; (1<<n)<N ; n++); n+=15;
double X=(pow(2,n)/N);
unsigned int Y=(unsigned int)X;
unsigned int d=0;
if(X-Y<=Y+1-X)d=(unsigned int)(pow(2,n)- (N-1)*Y)-1; else Y++;
printf("x /%5d = ( x * %5d + %5d ) >> %2d",N,Y,d,n);
for(k=1; k<(1<<16) ; k++) if(k/N != ((k*Y+d)>>n))break;
if(k==(1<<16))printf(" OK\n"); else printf(" ERR\n");
}}

647:646
08/01/24 15:42:18
64bit機か、内部で64bitまで計算結果を保持しているなら
32bitの割り算も出来るけど646は16bit同士です

648:デフォルトの名無しさん
08/01/24 15:52:26
GCC の中見りゃあるんじゃね？

649:デフォルトの名無しさん
08/01/24 17:46:02
>>648
gcc のカオス・スパゲッティ状態を知らぬようだな。

勧めるならせめて Small-C くらいにしとけ。
このルーチンなら工学社から出ていた
Small-C ハンドブックにもちゃんと説明されていたんだし。

650:デフォルトの名無しさん
08/02/04 20:42:37
ハッカーの楽しみ買ってきました～
これから読みますﾉｼ

651:デフォルトの名無しさん
08/02/05 23:53:51
Hacker's Delight やっと届いた

652:ヽ・´∀｀・,,）っ━━━━━━┓
08/02/06 01:12:31
俺もアレ訳本出る前ネットショップで買ったわ

653:デフォルトの名無しさん
08/02/22 06:50:56
a

654:デフォルトの名無しさん
08/02/28 07:49:51
a

655:デフォルトの名無しさん
08/03/01 13:50:55
a　<<　1

656:デフォルトの名無しさん
08/03/05 07:05:43
a

657:デフォルトの名無しさん
08/03/11 07:43:25
あげ

658:デフォルトの名無しさん
08/03/24 22:44:22
あげ

659:デフォルトの名無しさん
08/03/30 21:00:53
あげ

660:デフォルトの名無しさん
08/03/30 21:42:47
なにこのスレきもい。
でも懐かしい。

661:デフォルトの名無しさん
08/04/06 18:17:38
　　　　|
　　　　|
　　　／￣￣￣￣￣￣
　＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／

662:デフォルトの名無しさん
08/04/06 18:41:01
ダンゴさんを称えるスレというわけではありませんが、まあ、KY。

663:デフォルトの名無しさん
08/04/06 19:46:30
GCAの作者のページにビット演算が載ってたけど今いちわからん

664:デフォルトの名無しさん
08/04/07 17:04:46
ViViの作者のページにもビット演算が載ってたけどだいたい理解した
URLﾘﾝｸ(vivi.dyndns.org)

665:デフォルトの名無しさん
08/04/07 19:44:18
>配列による状態表現よりも処理が高速になる場合が多い
この表現は凶悪だな。何故なら、高速にならなかった場合にはかなり遅くなる可能性があるからだ。

666:デフォルトの名無しさん
08/04/17 06:42:52
age

667:デフォルトの名無しさん
08/05/01 06:01:45
age

668:デフォルトの名無しさん
08/05/01 08:02:29
燃料がないな

669:デフォルトの名無しさん
08/05/01 08:50:52
16bitカラーで　5：5：5 とか 5：6：5 とか　の時代なら色々やったけどな

670:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/01 18:55:25
AltiVecにも16bitカラー用の演算があったな

671:デフォルトの名無しさん
08/05/09 19:08:22
こちらのスレから誘導されて参りました。よろしくお願いします。

スレ立てるまでもない質問はここで第91刷
ｽﾚﾘﾝｸ(tech板:171番)

以下の条件で、32bit値のハミングウェイトが素数か否かを判定する
出来るだけ高速な方法を探しています

・入力はランダム
・（最悪ではなく）平均速度が速いことが望ましい
・0、1は素数ではない（偽になって欲しい）
・ハミングウェイトそのものの値は必要ない
・64bit拡張などは必要ない。32bit決め打ちで良い
・外部メモリはあまり使いたくない

皆様のお知恵を貸していただけませんでしょうか

672:デフォルトの名無しさん
08/05/09 19:25:44
一応、今はこんな感じです
ベタな実装で恥ずかしいですが…

int hw_is_prime(unsigned long x)
{
　　x = ( (x & 0xAAAAAAAA) >> 1 ) + (x & 0x55555555) ;
　　x = ( (x & 0xCCCCCCCC) >> 2 ) + (x & 0x33333333) ;
　　x = ( (x & 0xF0F0F0F0) >> 4 ) + (x & 0x0F0F0F0F) ;
　　x = ( (x & 0xFF00FF00) >> 8 ) + (x & 0x00FF00FF) ;
　　x = ( (x & 0xFFFF0000) >> 16) + (x & 0x0000FFFF) ;

　　return (1 << x) & 0xA08A28AC;
}

673:デフォルトの名無しさん
08/05/09 21:56:14
1 << 32 の結果って決まってたっけ

674:デフォルトの名無しさん
08/05/12 10:32:41
処理系定義かな。0ビットシフトになる場合と32ビットシフトになる場合が一般的だと思う。

675:デフォルトの名無しさん
08/05/12 18:51:02
まぁ 8bit, 16bit, 32bit が int の場合と、
64bit が int の場合では結果は明らかに異なるよな

676:デフォルトの名無しさん
08/05/12 20:19:59
8bitがintになることってありえるっけ

677:デフォルトの名無しさん
08/05/12 20:51:31
規格は一応-32767～32767だからないんじゃね？

678:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/12 21:34:45
1ビットマシンとか4ビットマシンとかってCでプログラミング可能なの？

679:デフォルトの名無しさん
08/05/12 21:44:21
CHAR_BIT >= 8 だけど、
別に変数１つをレジスタ１つで扱えないといけないわけじゃないし
問題ないんじゃね？

680:デフォルトの名無しさん
08/05/12 21:47:55
ダンゴさんのカキコでスレが加熱したな

681:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/12 21:59:19
レス番飛んでるな

682:デフォルトの名無しさん
08/05/13 11:50:54
ダとかンとかゴとか入ると飛ぶんだよな。

683:デフォルトの名無しさん
08/05/13 11:56:23
実は見えてる

684:デフォルトの名無しさん
08/05/13 12:39:16
ダンゴって名前を嫌がるのは、
体型が肉団子だからだよな。

685:ヽ・´∀｀・,,）っ-○◎●
08/05/13 12:47:46
だんごはこれだろ

━━━┓がどうみたらだんごに見えるねん

あたまわるいんとちゃうか

686:ヽ・´∀｀・,,）っ鹵～＜巛巛巛
08/05/13 12:50:40
虫除けのようなものだよ

687:デフォルトの名無しさん
08/05/13 14:33:31
ダンゴさんってどんな仕事してるの?

688:デフォルトの名無しさん
08/05/13 16:51:03
名無しさんの書き込みでスレがヒートアップしたな。

689:デフォルトの名無しさん
08/05/13 18:15:31
他愛もない雑談だけどな。
と、だけ書くのもなんだから、ちょこっとマジレス。

ANSI C での int の定義は処理系依存で、CPUのレジスタ幅によるらしい。
なので、Z80 なら 8bit の筈だけど、
大体のZ80 C処理系では char=8bit, int=16bit と扱う。
なんで int は 16bit より大きいという誤解があるんだろうなぁ。
その昔は char=7bit なんで処理系もあったというので、
油断は出来ないように思うんだよ。

690:デフォルトの名無しさん
08/05/13 18:38:03
INT_MINは-32767以下、INT_MAXは+32767以上じゃないといけないと決まってる
昔の話は知らん

691:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/13 19:01:17
1ビットCPUは実際にあった
URLﾘﾝｸ(www.d1.dion.ne.jp)

692:デフォルトの名無しさん
08/05/13 21:12:11
昔はやりたい放題だったかも知れないが、
今は規格に準拠した処理系であれば int >= 16 bits なのは真理。
あと、int のサイズの定義は CPU のレジスタ幅にして欲しそうな定義ではあるけど、
そう断言している訳じゃない。
実際最近でも 64-bit マシンで int = 32-bit のことがある。

693: ◆0uxK91AxII
08/05/14 01:14:15
>>689
＞その昔は char=7bit なんで処理系もあったというので、
無い。

694: ◆0uxK91AxII
08/05/14 01:21:20
ごめん、間違い。

695:デフォルトの名無しさん
08/05/14 03:04:09
uartと間違えたんだな

696:デフォルトの名無しさん
08/05/14 23:42:41
ハネウェルの昔のマシンとかは 6bit 単位のマシンとかがあったから、
それとの勘違いだろ。(7bit があったかどうかは知らん。)

まあ単位が 6bit なのは uart と同じ理由だが。

697:デフォルトの名無しさん
08/05/15 02:07:52
>>691
それはCPUと言うよりリレーの置き換えみたいなもの
Connection Machineのはまともな1bit CPUだけどbit sliceだから何bitにでも
化ける

698:デフォルトの名無しさん
08/05/28 00:29:01
あげ

699:デフォルトの名無しさん
08/05/30 00:17:23
11100111

こんなビットがあったとき、0が4と5ビット目に
存在するってどうやって調べるのが効率いいのかな？

個数はわかるけど位置はどうすりゃいいんだろう

700:デフォルトの名無しさん
08/05/30 00:34:24
Hacker's Delight 嫁

701:デフォルトの名無しさん
08/05/30 02:40:11
>>699
11100111 and 00011000

702:デフォルトの名無しさん
08/05/30 02:41:22
8bitなら256個のﾃｰﾌﾞﾙ持てば最速じゃね？　16bit以上なら、シフトして端のbitの0/1と
シフト回数で判別。

703:デフォルトの名無しさん
08/05/30 02:50:48
>>699
ループ

704:デフォルトの名無しさん
08/05/30 09:37:40
>>703
>>701

aビット目とbビット目が動的に変わるなら、マスク作ってandとった方が良いかもしれない。

705:デフォルトの名無しさん
08/05/30 09:47:01
>>699
問題文は正確に

706:デフォルトの名無しさん
08/05/30 11:48:47
>>699
４、５ビット目というのは変わりうるのよね？
あと個数が２個というのも変わりうるのよね？

707:デフォルトの名無しさん
08/05/30 11:51:01
>>699
ああ、あと、いつもがそんな風に左右対称とは限らないのよね？

708:デフォルトの名無しさん
08/05/30 12:36:25

一番下の0のビットだけを１にするのなら

y := ( not x ) and ( x +1)

で出来るから、ビットが1の個数が判る命令BitCount があるんなら
BitCount( y-1 ) で求まるよ

で x:= x or y; として一番下の0だったビットを1にしてから $FF になるまで繰り返せばいい

709:デフォルトの名無しさん
08/06/11 00:25:23
>>708
それって並列にできないですかね
無理ですよね.....

710:デフォルトの名無しさん
08/06/11 00:30:28
bit演算で128、64、32bitを扱う場合
みんなどんなふうに宣言しますか？
C/C++でのバターな方法が解りません

711:デフォルトの名無しさん
08/06/11 00:34:46
まずトラを数匹用意します。

712:デフォルトの名無しさん
08/06/11 00:41:57
あるプログラムで実際にあったコード。
普通ループではカウンタを＋＋していくと思うけど、
（iを1,2,3・・・と加算）
一回処理するごとに左に1ビットシフトしていた。
（iを1,2,4,8・・・とシフト）

普通こういうコード書きます？仕事で。

713:デフォルトの名無しさん
08/06/11 00:49:43
>>712
1989年ぐらいに見た記憶があるｗ

714:デフォルトの名無しさん
08/06/11 01:15:51
グレイコードを扱うような貧弱なCPUに対するコードなら在り得る。

715:デフォルトの名無しさん
08/06/11 01:26:18
１ビットずつスキャンしていく場合には使う。

716:デフォルトの名無しさん
08/06/11 01:27:14
>>712
普通にあるし、速度面だけでなく、その方が可読性があるものもある。

717:デフォルトの名無しさん
08/06/11 01:28:54
終了条件でいつも悩むんだけどね。

718:デフォルトの名無しさん
08/06/11 07:07:30
for( bit=1 ; bit ; bit<<=1 ) cnt += ( ( data & bit) >0 );

こういうの？

719:デフォルトの名無しさん
08/06/12 22:51:52
アセンブラで１～８回のループをシフト+キャリーでやることはあったな。

720:デフォルトの名無しさん
08/06/12 23:56:44
もしかしたらループ回数が３２かいを超えたら・・・
どうするの？

721:デフォルトの名無しさん
08/06/13 08:21:14
>>720
普通にカウントしろよｗ

722:デフォルトの名無しさん
08/06/13 11:54:06
正直別にどうでもいい
泣くしかない

723:デフォルトの名無しさん
08/06/25 13:20:16
0xC89664
の１バイト目・２バイト目の値を求める方法をお願いします。

724:デフォルトの名無しさん
08/06/25 13:24:45
>>723
貴方の小人は頭から食べるのですか？　お尻から食べるのですか？
URLﾘﾝｸ(www.aozora.gr.jp)

725:デフォルトの名無しさん
08/06/25 19:29:14
囲碁（9路盤）のbitboardを作ろうとしています。
9x9なのでSSE2使えば128ビットレジスタ一個に収まるのでかなりの高速化が出来ると思っています。

囲碁のルールに上下左右を全て囲まれた石の塊は盤から取り除かれるというのがありますが、
これを高速に行うにはどうしたらよいでしょうか。

問題はSSE2は128ビットを一塊としたシフトが行えないことで、これのせいでどうしたらよいかわからなくなっています。
よろしくお願いします。

726:デフォルトの名無しさん
08/06/25 19:48:23
モンテカルロ木の実験ですか?

727:デフォルトの名無しさん
08/06/25 20:02:15
>>726
そうです。
モンテカルロはスピード命らしいので、SSEを使えないかと思っています。

728:デフォルトの名無しさん
08/06/25 21:11:08
左シフトなら paddq である程度代用出来るだろ

729:デフォルトの名無しさん
08/06/25 21:49:09
paddqって64ビットの境目で切れ目が出来てしまいませんか。

730:デフォルトの名無しさん
08/06/25 21:53:24
128ビット丸々だとバイト単位の命令しかないからねぇ。
x64環境を使っていいのならビット単位をやめてバイト単位にして
16本のXMMレジスタを9本使って9x9にした方がいいんじゃないかな？

731:デフォルトの名無しさん
08/06/25 22:23:24
それならビット単位でshort[9]でもよさそうですが、
バイト単位にしたほうが有利なんですか？

732:デフォルトの名無しさん
08/06/25 23:18:33
ビット単位で操作できないから困ってたんじゃなかったの？

733:デフォルトの名無しさん
08/06/26 06:48:29
レジスタを9本も使うなら32ビットのレジスタでも9x9の盤は収まってしまいます。
その場合、ビット単位の操作は可能です。

x64でレジスタが16本あったとしても通常のレジスタを9本も占めるというのは考えにくいですが、
ＸＭＭレジスタなら9本使っても支障ないということでしょうか？

734:デフォルトの名無しさん
08/06/26 09:01:44
>>729
最大9bitしかシフトしないでしょ？　なら　境界にデータを置かなければいいでしょ

あるいは16bitを１列にしてレジスタ２つにしたらどう？

735:デフォルトの名無しさん
08/06/26 10:08:36
>>733
x64で汎用レジスタが増えたとはいえ9本も使えばループや分岐に支障が出ると思うよ。
その点XMMレジスタなら浮動小数点演算しなければ基本的に空いてる。

736:725
08/06/26 19:15:01
725です。

すいません。
皆さんにレスしていただいておいて申し訳ないのですが、
高速化について調べていたらGPGPUというのが見つかりました。

グラボに計算をさせるというものなのですが、上手くツボにはまれば
CPUの何十倍もの速度がでるそうです。

囲碁がはたしてグラボに計算させるのに向いてるのかどうかわかりませんが、
SSEは一旦忘れて、GPGPUについて調べてみようと思います。
グラボも３～４万だせば結構いいのが買えるみたいです。

とりあえずGPGPUスレとCUDAスレにいって雰囲気つかんできます。

皆さんのレスには感謝しています。
失礼しました。

737:デフォルトの名無しさん
08/06/26 19:47:50
そっち行ってもいいならFPGAっていうテもあるかもしれん。

738:デフォルトの名無しさん
08/06/26 21:47:07
5年ほど前にFPGAでオセロの石を返す部分を作ったが
普通にCPUで計算するより遅かった

739:デフォルトの名無しさん
08/06/26 22:43:05
>>736
CUDAするなら前もって、GPUに計算させたい部分
設計しておけ
わしは今日から3日でモンテカルロをCUDAで解けるように
勉強する

740:725
08/06/27 00:03:02
>>739
どもです。

ところで最新ハイエンドGPUはピーク性能1TFLOPS超えるらしいですね。
ＨＤＤもテラバイトの物が出てるし、時代はもうテラなんですねぇ。

741:デフォルトの名無しさん
08/06/27 00:18:19
>>740
Radeon HD3870とGeforce9800GTXもってるけど
両方とも労せず2000スレッド以上生成して並列に計算できるよ

742:デフォルトの名無しさん
08/06/27 00:32:16
>>725
一命令ではできないが，シフトしたいビット数を n として n/8 と n%8
とに分けてシフト命令使って後で合成すれば可能

743:デフォルトの名無しさん
08/06/27 04:00:39
>>738
enumの様に贅沢にintを丸々一つ石に配分した方が良かったかもしれないね。

744:デフォルトの名無しさん
08/06/27 07:18:19
ベクトル演算を利用するなら　閉曲線の内側か外側の判定で巻付判定法を応用するといいように思うな

ビット演算じゃないけど

745:デフォルトの名無しさん
08/07/11 01:01:51
あげ

746:デフォルトの名無しさん
08/07/20 15:56:27
う

747:デフォルトの名無しさん
08/07/20 20:41:05
今どきビット演算で高速化とかｗ

748:デフォルトの名無しさん
08/07/20 23:07:22
プログラミングマニュアル1・基本仕様ガイド
の
・式

ってとこに詳しく書いてるだろ...読みもしないで不思議とか言うな

749:デフォルトの名無しさん
08/07/20 23:07:59
誤爆すいません

750:デフォルトの名無しさん
08/07/22 10:17:23
こやつめ!

751:デフォルトの名無しさん
08/08/01 03:07:44
2^a　を渡されたときaを求める方法で何かいい物はありませんか？
なるべくループやlogを使わない物がいいです

752:750
08/08/01 03:26:58
>>751
追記、1≦a≦9

753:デフォルトの名無しさん
08/08/01 03:27:44
>>752
自分の名前間違えた>>750じゃなくて>>751

754:デフォルトの名無しさん
08/08/01 04:04:46
５１３個の配列持って、その中に１～９を入れておく。[1]=なし、[2]=1、[3]=なし、[4]=2、・・・
[512]=9　演算はこれが最速。

755:デフォルトの名無しさん
08/08/01 04:06:47
サイズが問題なら、
if( n & 0x200 ) return 9;
if( n & 0x100 ) return 8;
・・・
if( n & 0x002 ) return 1;

756:デフォルトの名無しさん
08/08/01 04:15:16
x86ならBSF

757:デフォルトの名無しさん
08/08/01 04:39:50
char bit[256] = {1,2,0,3,0,0,0,4, 略 };

bsf(int n) {
int r;
if ((r = bit[n&255])) return r;
n >>= 8;
if ((r = bit[n&255])) return r + 8;
n >>= 8;
if ((r = bit[n&255])) return r + 16;
n >>= 8;
if ((r = bit[n&255])) return r + 24;
return 0; //解なし
}

758:デフォルトの名無しさん
08/08/01 04:41:33
こんなのどうよ?
bsf(bits){
bits-=1;
int num;
num = (bits >> 1) & 03333333333;
num = bits - num - ((num >> 1) & 03333333333);
num = ((num + (num >> 3)) & 0707070707) % 077;
return num;
}

759:デフォルトの名無しさん
08/08/01 04:52:26
>>754-758
ありがとうございます。みんなカッコイイ

760:デフォルトの名無しさん
08/08/01 05:52:52
>>757は
char bit[256] = { 0,1,2,0,3,0,0,0, 4,0,0,0,0,0,0,0, 略 };
の間違いだった。
んで結果を-1すれば合うんじゃないかな。

761:デフォルトの名無しさん
08/08/01 06:23:57
こんなんでどよ
int f(unsigned n){
　　 int a=1;
　　 unsigned b;
　　 n>>=2;
　　 b = n>>4;if(b)a+=4,n=b;
　　 b = n>>2;if(b)a+=2,n=b;
　　 return a+n;
}

762:デフォルトの名無しさん
08/08/01 10:45:43
"_\0\5\1\10\6\2__\4\7_\3"[n*0xCA030FF>>28];

763:デフォルトの名無しさん
08/08/01 14:50:59
お前頭いいなー、でも
"_\1\6\2\011\7\3__\5\010_\4"
じゃないか

もう少し小さいハッシュもあった
"\1\2\3\010\6\4\011__\7\5"[n*0x5300000>>28];

764:762
08/08/01 16:32:34
あー間違えてたーthx
そしてそっちのハッシュのほうが優れているね。

765:デフォルトの名無しさん
08/08/01 16:55:45
なるほど、ハッシュってそういう使い方するんだ。

766:デフォルトの名無しさん
08/08/01 17:47:48
>>762-763
異次元過ぎてついて行けないのだが解説頼む

767:デフォルトの名無しさん
08/08/01 21:25:31
俺もわかってないが
gperfとかで完全ハッシュ関数を作るのと同じように
(文字列ではなく)特定の数字から対応する特定の数値への完全ハッシュ関数を作っているんだと思う。
どうやって導いたかなんて知らん。

768:デフォルトの名無しさん
08/08/02 01:40:13
へええ
左シフトしたときに
あるビット範囲（この例だと28ビット目から31ビット目）が
シフト回数ごとにバラけるようにしているのか

シフト回数　　(n*0x5300000)のbit28～31の値
　　1　　　　　　　　0
　　2　　　　　　　　1
　　3　　　　　　　　2
　　4　　　　　　　　5
　　5　　　　　　　　10
　　6　　　　　　　　4
　　7　　　　　　　　9
　　8　　　　　　　　3
　　9　　　　　　　　6

んで配列テーブルをlookupすると。

完全ハッシュ関数って、元が異なれば必ず先が異なる関数のことだっけ。
じゃないとこれ使えないよな。

小さいというのは先の範囲、つまり今回は28～31の４ビットのことか。
確かに小さいほうがメモリとキャッシュに優しいですな。

という感じであってますか。

>どうやって導いたかなんて知らん。

俺も知りたい。

769:デフォルトの名無しさん
08/08/02 01:52:05
頭良すぎる

770:デフォルトの名無しさん
08/08/02 01:56:27
2chってすげーな

771:デフォルトの名無しさん
08/08/02 10:03:58
ビット演算ってたしかにすごいけど、
ソースに組み込むときは、その演算の意味とメリットなど
ビット演算を導入した経緯や思想も書いてほしい・・・

ソース理解に時間がかかったり、修正が大変・・・
まあ、俺がお馬鹿なのかもしれないけど。

あと、763って751からの流れなんですか？
それとも別の流れ？

772:デフォルトの名無しさん
08/08/02 10:14:13
最後の2行から見ても明らかに

>まあ、俺がお馬鹿なのかもしれないけど。

が正解。

773:デフォルトの名無しさん
08/08/02 10:17:05
このスレって頭のいい奴もいるけど、
771みたいなバカもいる。
バカはROMっていろ！死ね771！！

774:それは俺か (w
08/08/02 10:59:13
まあ、バカにレスする奴はもっとバカだけどな。

775:デフォルトの名無しさん
08/08/02 11:02:09
1、2、4、8、16、32、64、128、256、512の完全最小ハッシュ値を作る。
URLﾘﾝｸ(www.ic-net.or.jp)
これか？
>>762は本当に頭がいい。>>763の書き込みがなかったら
意味も解らずスルーするところだった。

776:デフォルトの名無しさん
08/08/02 12:58:48
512の完全ハッシュを作ってそれを1～9のテーブルに掛けるって事？
分かった気がする。

777:デフォルトの名無しさん
08/08/02 13:59:12
>>775
でも、保守する奴が >>762 みたいに頭いいとは限らんから、
仕事のプログラムなら >>754-755 あたりのほうがいいと思う。

778:デフォルトの名無しさん
08/08/02 14:04:14
当たり前。こんなのは所詮パズル。商用コードでこんなの書けない。
>>762みたいなのが許されるのは趣味のプログラミングだけだよ。

779:デフォルトの名無しさん
08/08/02 16:19:14
後は極端に処理速度がネックになってるところとか、
ビックリするほど容量が無いプラットフォームとか、
コンパイラが準備されてなくてアセンブラで書かなきゃいけないような場合、
更にRISCみたいに見た目と実行順が違うような環境だと
読む量が少ない短いコードが逆に役に立つ。
自慢を理由に書くと間違いなく死を招く。

780:デフォルトの名無しさん
08/08/02 16:20:19
コメントで書いておけば十分じゃないかな。
今でもまだまだ、速度やサイズ重視の分野はあるし。だいぶ少なくはなっているけど。

781:デフォルトの名無しさん
08/08/02 16:32:12
現状、用途として大きそうなのはシェーダー周りか。

782:デフォルトの名無しさん
08/08/02 16:36:45
画像処理ならいくらでも速度欲しいけどな

783:デフォルトの名無しさん
08/08/02 16:49:03
昔、VUアセンブラの実装をしたが、ライブラリの増加により俺の約700byteのプログラムが
入らなくなり削りに削って「400byteだけ下さい！」と上司に嘆願したのは懐かしい思い出。

784:デフォルトの名無しさん
08/08/02 18:57:37
>>777
それは同意だけど、 >>762 のエッセンスを抜き出して、わかりやすくすれば
いいんじゃないかな

おそらく、2^a を掛けると aビット左シフトする、というのは誰にも自明だけど
１～９の値にマップするマジック定数がややトリッキーかと

なら、見た目にわかりやすいようシフト数を４倍にして、（ついでに右シフトにして）
こんな感じでどうだろうかね(64ビット整数が使えることが前提だけど＾＾）

/* assume that n is 2^a (1<=a<=9) */
　return (0x9876543210LL / ( n * n * n * n )) & 0xf;

785:デフォルトの名無しさん
08/08/03 02:24:01
一番右の1を探すとき~a&(a-1)でできますよね、じゃあ一番左の1を探すときは何かありませんか?

786:デフォルトの名無しさん
08/08/03 02:37:33
掛け算が４回・割り算が１回ってのが、演算量的に・・・　俺が8bitに慣れてるからかな？
64bit整数があるにしても、nが32bitならn*nで64bitでしょ。中間結果でbitが失われるんじゃ？

787:デフォルトの名無しさん
08/08/03 02:40:55
>>785 754とか755じゃダメなの？もっと速い／小さいのってこと？

788:デフォルトの名無しさん
08/08/03 02:55:56
>>785
関係ないがa&(-a)で右端の一ビットを得られるぞ、左端は無理じゃないか

789:デフォルトの名無しさん
08/08/03 03:17:47
URLﾘﾝｸ(www.nminoru.jp)

790:デフォルトの名無しさん
08/08/03 03:41:51
>>787-789
どうもです、今見た資料に左端を操作する命令列は存在しないって書いてあったorz

791:デフォルトの名無しさん
08/08/03 03:56:21
左右反転するビット演算子でもあればね

792:デフォルトの名無しさん
08/08/03 03:59:50
a = ( ( a >> 16 ) & 0x0000ffff ) | ( ( a << 16 ) & 0xffff0000 );
a = ( ( a >> 8 ) & 0x00ff00ff ) | ( ( a << 8 ) & 0xff00ff00 );
a = ( ( a >> 4 ) & 0x0f0f0f0f ) | ( ( a << 4 ) & 0xf0f0f0f0 );
a = ( ( a >> 2 ) & 0x33333333 ) | ( ( a << 2 ) & 0xCCCCCCCC );
a = ( ( a >> 1 ) & 0x55555555 ) | ( ( a << 1 ) & 0xAAAAAAAA );

793:784
08/08/03 17:00:12
>>786
もちろん変数n は64ビット長
LP64なら long型だと思ってもらえばいいです

演算量については、いまどきの投機実行するCPUなら
下手に条件判定入るよりは速いと思うけど、・・・まあ状況次第ですね

794:デフォルトの名無しさん
08/08/03 17:25:07
ｎが64bitでも、n*n*n*n の中間結果はbit失われるでそ。

795:デフォルトの名無しさん
08/08/03 18:31:31
でも、仕事に使うとなると、
「シンプルにしようや」
で終わってしまうんですよね～
そうすると、754や755に落ち着くのかな・・・

796:デフォルトの名無しさん
08/08/03 19:39:21
そりゃそうだよ。

よほど特段の理由が無い限り、シンプルが一番。

797:デフォルトの名無しさん
08/08/03 19:51:28
裸が一番いいのと一緒だ

798:デフォルトの名無しさん
08/08/03 21:10:39
>>794
2^9まででしょ？

799:デフォルトの名無しさん
08/08/03 21:12:54
は？

800:デフォルトの名無しさん
08/08/03 21:51:46
0x1 * 0x1 => 1
0x3 * 0x3 => 9
0x7 * 0x7 => 0x31
0xf * 0xf => 0xe1
0xff * 0xff => 0xfe01
0xfff * 0xfff => 0xffe001
0xffff * 0xffff => 0xfffe0001
0xfffff * 0xfffff => 0xffffe00001

これに規則性みたいなものを感じるんですが、
何か法則があるんでしょうか？

801:デフォルトの名無しさん
08/08/03 21:54:51
初めの3つはともかく、
9*9=81
99*99=9801
999*999=998001
と同じようなもんだろ

802:デフォルトの名無しさん
08/08/03 22:06:41
よくわからんが、ビット演算とかって、日本人よりも
インド人のほうが面白い発想しそうだね

803:デフォルトの名無しさん
08/08/03 22:09:36
>>800-801
２進数に考えれば、最初から綺麗に並ぶよ。

1 * 1 = 1
11 * 11 = 1001
111 * 111 = 11001
1111 * 1111 = 11100001
11111 * 1111 = 1111000001

804:デフォルトの名無しさん
08/08/03 22:16:49
0xffff * 0x10000 => 0xffff0000
0xffff0000 - 0xffff => 0xfffe0001
特に面白い事実はなさそうだが

805:デフォルトの名無しさん
08/08/03 22:21:59
99*99=9801
これが国民機ナンバーの正体かー
すると8801は？
93.8136 * 93.8136 = 8800.99
収束しないのか

806:デフォルトの名無しさん
08/08/03 22:22:36
収束？

807:デフォルトの名無しさん
08/08/03 22:25:25
ごめん適当言った

808:デフォルトの名無しさん
08/08/03 22:34:48
無理数ね。

809:デフォルトの名無しさん
08/08/03 23:10:51
λ... PC-8001, PC8201, PC-6001, &c. ...

810:デフォルトの名無しさん
08/08/03 23:48:03
獣の数字にまつわる屁理屈と同じようなもんだな
あえて8801に意味を見出すなら99*99-1100とかなんとか

811:デフォルトの名無しさん
08/08/03 23:49:53
9801-1100 = 8701だな
俺頭大丈夫ｋ

812:デフォルトの名無しさん
08/08/04 00:08:26
PC9801が長いこと繁栄したのは99*99=9801
こういった力(ちから)を持つ数字が隠されていた影響に違いない。
その証拠に型番が9821に変わろうとしたとたん没落した。
きっと9801のままなら永遠の存在だったんだよ。

813:デフォルトの名無しさん
08/08/04 00:11:55
>>798 そうか、9bitのハッシュのエレガントな解法だったのね。ごめん。
ハッシュって、必要の都度、bit数見極めて作らなきゃいけないんだな・・・

814:デフォルトの名無しさん
08/08/04 01:24:27
実際に仕事でも使用可能な、
1.実用性がある
2.比較的わかりやすい
ビット演算のアルゴリズムって何だろうね・・・

815:デフォルトの名無しさん
08/08/04 01:50:11
名前がつくぐらい有名になればいいんじゃないかな。
例えばコメントに
// 762氏ハッシュ
とか書けるぐらいに。

816:デフォルトの名無しさん
08/08/04 01:56:23
すみません、
＞"\1\2\3\010\6\4\011__\7\5"[n*0x5300000>>28];
の頭の"\1\2\3\010\6\4\011__\7\5"がいまいち良くわかりません。

817:デフォルトの名無しさん
08/08/04 02:06:28
ただの文字列リテラルだよ

次ページ