スレ立てるまでもない質問はここで 165匹目

[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

294: (ﾜｯﾁｮｲ 8701-OYus) 2023/11/29(水)23:43 ID:5e0Dum8b0(1) AAS
powershellでやれ

295: (ﾜｯﾁｮｲ c777-2qxF) 2023/11/29(水)23:57 ID:9Fs/PVQH0(2/2) AAS
>>293
やっと解決できました
ありがとうございました
画像ﾘﾝｸ

296(1): (ｽﾌｯ Sd7f-1fOb) 2023/12/01(金)13:56 ID:x4GTgSrOd(1) AAS
C言語において-3が、unsigned int で4294967293になる理屈を教えてください

297(1): (ﾜｯﾁｮｲ 7fd6-WSLN) 2023/12/01(金)14:58 ID:2riclQL00(1) AAS
外部ﾘﾝｸ:en.cppreference.com

otherwise, if the target type is unsigned, the value 2^b
, where b is the number of value bits in the target type, is repeatedly subtracted or added to the source value until the result fits in the target type. In other words, unsigned integers implement modulo arithmetic.

298: (ｽﾌﾟﾌﾟ Sd7f-1fOb) 2023/12/01(金)15:09 ID:FXqwQW8Dd(1/2) AAS
>>297 モジュロ演算の意味が分かりません

299(1): (ｽｯｯﾌﾟ Sd7f-O0Dn) 2023/12/01(金)15:19 ID:1ihFKBOzd(1) AAS
>>296
CPUの整数表現として負数を2の補数で表現するから

32ビットはめんどいので末尾8ビットだけ書くとして3は00000011
3の1の補数はビット反転して11111100（4294967292）
3の2の補数は1の補数に1を足して11111101（4294967293）

2の補数を使う理由はググれ

300: (ｽﾌﾟﾌﾟ Sd7f-1fOb) 2023/12/01(金)15:25 ID:FXqwQW8Dd(2/2) AAS
>>299 やはりそうでしたか。納得しました。

301: (ｽﾌｯ Sdbf-WaQs) 2023/12/09(土)16:25 ID:ZNOr2kH7d(1/2) AAS
C言語でオーバーフローするのは、signed だけですか？それとも、unsigned もですか？
AIに聞いても、意見が分かれていて、どっちかわかりません。

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は複合インデックスの先頭列の値の種類が少ない場合じゃないと非効率

上下前次 1-新書関写板覧索設栞歴

あと 679 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.012s