[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
302(1): (ｽｯｯﾌﾟ Sdbf-WfBz) 2023/12/09(土)16:44 ID:ETXxeT5Ld(1/2) AAS
符号なし整数はmod 2^n(nはビット数)で計算します。
これをオーバーフローと表現したりしなかったりする気がします。
303(1): (ｽﾌｯ Sdbf-WaQs) 2023/12/09(土)16:54 ID:ZNOr2kH7d(2/2) AAS
>>302 ありがとうございます。規格では、unsigned はオーバーフローしないときめられているようですが、コンパイラの警告が,
unsignedの場合でないですね。
304: (ｽｯｯﾌﾟ Sdbf-WfBz) 2023/12/09(土)17:01 ID:ETXxeT5Ld(2/2) AAS
規格では符号なし整数はオーバーフローしないと書かれていて、正確な文言としてはこれが正しいようです。
305: (ｽｯﾌﾟ Sd3f-Rtb0) 2023/12/09(土)17:31 ID:qyzy7PA2d(1) AAS
キャリービットが立つ＝オーバーフロー
306: (ﾜｯﾁｮｲ 97f2-RTrI) 2023/12/09(土)18:36 ID:p0kpDF0H0(1/2) AAS
wrapping overflowのことをCの規格では「規定された動作でUBじゃないからオーバーフローとは呼ばないｷﾘｯ! wraparoundと呼べ」と言ってるだけ
一般に言うところの算術オーバーフローは発生するが規格に定められた動作なので警告は出ない
307: (ﾜｯﾁｮｲ d7da-noSv) 2023/12/09(土)19:47 ID:dajCtWdt0(1) AAS
>>303
オーバーフローって演算結果の話なのでコンパイラでは警告でないんじゃね
308: (ﾜｯﾁｮｲ 97f2-RTrI) 2023/12/09(土)21:12 ID:p0kpDF0H0(2/2) AAS
実行時にしかチェックできないものとコンパイル時にチェックできるものとある
309: (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)10:57 ID:o2TNvwaPM(1/3) AAS
SQLITEなどのDBMSで、2つ以上のカラムに
まとめてindex (B-Tree)を用意するところの
「Multicolumn indexes(Composite indexes)」
を用いる場合、select の where 節で
2つのカラムa, b に対して、
where a=値1 and b=値2
とした場合、高速化されるそうです。
しかし、b については条件を指定せずに
where a=値1
とだけ書いた場合や、
a については条件を指定せずに
where b=値2
とだけ書いた場合の速度も高速化されますか？
310: (ﾜｯﾁｮｲ 7716-pmcO) 2023/12/10(日)11:57 ID:PVGCDu/Y0(1/2) AAS
はい、2つ以上のカラムにまとめてindexを作成すると、それらのカラムを組み合わせて検索条件を指定する場合だけでなく、個々のカラムに対する検索条件も高速化されます。具体的には、次のような場合にも高速化が期待されます。
1. `where a=値1` の場合: もし `(a, b)` の複合インデックスがあるなら、この条件も高速に検索できます。
2. `where b=値2` の場合: 同様に、`(a, b)` の複合インデックスがあるなら、この条件も高速に検索できます。
これは複合インデックスがB-Treeなどの構造を持ち、検索がその構造を活かして行われるためです。複合インデックスが使えると、各カラムに対する条件検索も高速に行えます。
311: (ﾜｯﾁｮｲ 7716-pmcO) 2023/12/10(日)11:58 ID:PVGCDu/Y0(2/2) AAS
なぜbだけの条件でも高速されるのか説明します。
複合インデックスが `(a, b)` の形をしている場合、このインデックスはB-Treeなどのデータ構造を持ち、最初のカラム `a` によってソートされています。このようなインデックスがあると、`where b=値2` という条件も高速化されます。
原因はB-Treeの特性にあります。B-Treeは最初のカラムに基づいてツリーを構築し、各ノードはそのカラムの値でソートされています。したがって、`where b=値2` のクエリでも、インデックスを利用して B-Tree の探索を効率的に行えるのです。
ただし、この場合でも、`a` に関する条件が `where a=値1` と組み合わさると、最初のカラムが条件になっているため、より効果的にインデックスが使用されることが期待されます。
312(2): (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)12:13 ID:o2TNvwaPM(2/3) AAS
>>1
`where b=値2`
の条件だけ書いた場合になぜ高速化されるか
について、もう少し詳しくお願いできませんか。
2文字のひらがなの辞書で考えて、
1文字目をa, ２文字目をb として、
ああ
あい
あう
いあ
いい
いう
のようにならびますが、b=いを検索したい
場合、1文字目が あい と、いい の２か所
に分かれて格納されてしまい、B-Treeだと
全く別の場所になってしまいそうですが。
313(1): (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)12:18 ID:o2TNvwaPM(3/3) AAS
>>312
まず、複合カラムでない場合に限定すれば、
N文字のキーが入っている B-Treeの場合、
深さは、大体 O(log(N))になります。
検索する際、どのあたりにキーがあるかは、
一意的に深い方向に探索をすれば済むので、
大体、O(log(N)) 回程度に「進めれば」検索が
終了できます。
しかし、複合カラムの場合、条件にaを指定せずに
bだけを指定した場合、
キーは、様々な場所に分散されて格納されます
ので、この例のひらがな50音の辞書の場合なら
50か所に分かれてしまうため、
log(N) * 50 回程度の時間がかかってしまうのでは
ないでしょうか。
314: (ﾜｯﾁｮｲ ff84-pmcO) 2023/12/10(日)14:06 ID:Ne0vvx410(1/2) AAS
>>312
申し訳ありません、誤解が生じました。確かに、私の前回の説明は一般的な場合に当てはまりますが、特に文字列の場合、`where b=値2` のクエリが効率的になるかどうかはデータの具体的な並びに依存します。
文字列の場合、B-Treeの挙動が通常の数値とは異なります。例えば、`ああ`、`あい`、`あう`などが順序通りに格納されることで、`where b='い'` のクエリは特に高速になります。これはB-Treeが文字列においても順序を保ちながらデータを格納するためです。
ただし、文字列の場合でも、全くの一般性があるわけではありません。文字列のソートは、通常の辞書順ではなく、各文字のバイトレベルの比較に基づいていることも考慮する必要があります。
そのため、データの実際の配置や使用しているデータベースシステムによっては、特定のクエリの性能が異なることがあります。文字列データにおいても最適なインデックス戦略は、具体的なデータとクエリによって変わることがあるので、実際のデータや使用状況を元に検討することが重要です。
315: (ﾜｯﾁｮｲ ff84-pmcO) 2023/12/10(日)14:08 ID:Ne0vvx410(2/2) AAS
>>313
おっしゃる通り、複合カラムの場合、特に「条件にaを指定せずにbだけを指定した場合」、B-Treeの探索が効率的でない場合があります。
複合カラム `(a, b)` のB-Treeでは、`a` でソートされ、同じ `a` の中で `b` がソートされている状態です。そのため、`where b=値2` のようなクエリが効率的になるのは、同じ `a` 内において `b` の値が連続的に格納されている場合に限られます。
しかし、もし `a` の値が異なる場合、`b` の値も異なる箇所に格納され、深さが増加し、効率が損なわれる可能性があります。したがって、複合インデックスの効果はデータの分布に強く依存します。
一般的に、複合インデックスが効果的なのは、クエリで指定された条件が複合インデックスの順序に合致する場合です。もし `a` を指定せずに `b` だけを指定するケースでデータが分散して格納される場合、B-Treeの探索が非効率的になる可能性があります。その際は、単独の `b` に対する単一カラムインデックスを検討することが適している場合があります。
316: (ﾜｯﾁｮｲ 37ec-RTrI) 2023/12/10(日)14:17 ID:+Ev0uxFD0(1) AAS
ChatGPT使ってないとGPT回答を見分けられないのか
チューリングテストクリアだな
317(1): (ﾜｯﾁｮｲ 9f4b-7MMK) 2023/12/10(日)16:08 ID:oYKusLHl0(1) AAS
SQLITEやOracleではINDEX SKIP SCANを使うので左端列を指定しなくてもインデックスが採用される
もちろん左端列のみを指定するより性能は劣る
SQLServerあたりだと左端列を指定しないケースではインデックスは使われない
318(2): (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)18:25 ID:V/86XK6XM(1) AAS
[1] あ、い、う の三文字を2個並べた組み合わせを
キーに持つとして、3*3=9 個のキーを持つと
すると、B-Tree は、木の根が1つで、
1文字目で3つに枝が分かれ、別れた先
の2文字目でさらに3つに枝が分かれます。
1文字目をa, 2文字目をbとします。
図が書けないので、フォルダのように表すと、
/あ/あ (1)
/あ/い (2)
/あ/う (3)
/い/あ (4)
/い/い (5)
/い/う (6)
/う/あ (7)
/う/い (8)
/う/う (9)
となります。
[2] where a=あ and b=い
とした場合、たった一度の探索で(2)
に辿り着けます。
[3] where a=い
とした場合は、(4),(5),(6)ですが、それらは、「第一関節」の
同じ一本の枝「い」に属すのでとても効率的に探せます。
[4] where b=い
とした場合、(2),(5),(8)の三か所を探索する必要がありますが、
第一関節レベルから異なる枝に属しているので、
第二関節に行った後で第一関節まで「戻る」ような動作が必要になります。
[まとめ]
実際の探索では、「戻る」わけではないんでしょうが、
aだけを指定した場合と、bだけを指定した場合とでは、探索回数が3倍の違いが
出てきますよね？
319: (ﾜｯﾁｮｲ 979f-g9yR) 2023/12/10(日)18:55 ID:szFLrNg10(1) AAS
INDEX RANGE SCANだな
320(1): (ﾜｯﾁｮｲ 9f79-1KRD) 2023/12/10(日)21:44 ID:yZwJDRXW0(1/2) AAS
>>318
B木って部分探索のアルゴリズムじゃないけど
トライ木辺りと勘違いしてないか
321: (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)22:38 ID:sxH1jiAFM(1) AAS
>>320
本当はこうではないんですが、これとよく似た
事が起きていると思うんです。
322: (ﾜｯﾁｮｲ 9f79-1KRD) 2023/12/10(日)23:36 ID:yZwJDRXW0(2/2) AAS
長ったらしいから3行で質問をまとめる努力をして欲しい
さもなくばお前が思うんならそうなんだろうお前ん中ではなという感想を述べさせてもらう
323(1): (ﾜｯﾁｮｲ 7f01-a+/s) 2023/12/10(日)23:59 ID:p7J4kGbi0(1) AAS
>>318
B-Treeはそういうのじゃない
ページサイズの一定割合に収まるだけのレコードがルートを含めたインデックスノードにも詰められていく
page 1 [ああ〜いい]
/
いう
\
page 2 [いう〜うう]
>>317の書いてるINDEX SKIP SCANがDBMSやデータの状況によって採用されるケースなら
インデックスがあったほうが速いということになるが採用されなければテーブルスキャンなのでインデックスなくても同じ
INDEX SKIP SCANは複合インデックスの先頭列の値の種類が少ない場合じゃないと非効率
324: (ﾜｯﾁｮｲ 7f01-a+/s) 2023/12/11(月)00:02 ID:+qYlbChh0(1) AAS
全角スペースにした
page 1 [ああ〜いい]
/
いう
\
page 2 [いう〜うう]
325: (ﾜｯﾁｮｲ d701-7tbx) 2023/12/11(月)00:14 ID:JY+EfkBo0(1) AAS
bカラムだけのパターンでも効くことあるんだ
sql serverしか知らないからダメだと思ってた
でも基本はbカラムだけで高速化を狙うならbカラム単体でもインデックス張るべきだと思うけど
326: (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/11(月)10:45 ID:TsCEY1+2M(1) AAS
>>323
あなたはB-Treeを理解できてない。
俺は天才だからわかる。
327: (ﾜｯﾁｮｲ 1f9e-C3j7) 2023/12/12(火)00:59 ID:C12JHku00(1) AAS
確か、Ruby on Rails で見た
X, Y, Z 列にインデックスを付ける場合、
複合インデックス、XYZ, YZ, Z を付けるとか
文字列は先頭か末尾指定でしか、インデックスが使われないとか。
つまり、文字列の中ほどに含むと言うのがダメ
328: (ｽｯﾌﾟ Sd3f-v3qT) 2023/12/12(火)01:12 ID:HomtdY1ed(1) AAS
馬鹿の妄言
Ruby
329: (ﾜｯﾁｮｲ 1701-1GQ9) 2023/12/12(火)20:38 ID:nNQd25Q50(1) AAS
githubの中身はRailsなんだね
330: (ﾜｯﾁｮｲ 17c7-C3j7) 2023/12/13(水)00:02 ID:eFIo8YKe0(1) AAS
Github は、Rails からGo へ移行していると聞いた
YouTube で有名な雑食系エンジニア・KENTA が、
初心者のキャリアパスは、Rails → Go のみと言ってる
Ruby/Goの神・HashiCorp のMitchell Hashimoto もそう。
Ruby製のVagrant → Go製のTerraform。
今は、Goプログラマーしか求めていない
一方、Shopify, Gitlab は、Goへ移行しない
331: (ｽｯﾌﾟ Sd3f-v3qT) 2023/12/13(水)01:13 ID:Z8G46vVkd(1) AAS
初心者は関わってはいけない
上下前次1-新書関写板覧索設栞歴
あと 671 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s