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