Qiita 7 - キータぞ、来たぞ、キータだぞー (484ﾚｽ)
上下前次1-新
64(4): 09/22(月)11:19 ID:XiCaSJNI(1) AAS
記述や可読性の差が大きい
start..endの個数
【Rust】 end-start個
【Pascal】 end-start+1個
startからn個
【Rust】 start..(start+n)
【Pascal】 start..(start+n-1)
このように間違えやすく見にくい+1や-1が
半開区間を採用のRustでは不要となる
65: 09/22(月)11:35 ID:0o6m1dEB(1) AAS
Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。
66(1): 09/22(月)23:00 ID:AxN4Bvca(1) AAS
>>59
..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。
右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で
.が1個余分なのは良くないが。
閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、
互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。
67: 09/22(月)23:50 ID:ci9fXj6N(1) AAS
前例に倣ったままにしとけめんどくせえ
68: 09/23(火)00:57 ID:0DVfn//v(1) AAS
>>64
Rustの方式が優れてるね
69(1): 09/23(火)08:21 ID:ptEtOTO9(1/2) AAS
半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。
..では「あれ? どっちだっけ?」と思ってしまう可能性がある。
70: 09/23(火)09:39 ID:BqTZOz5k(1) AAS
コード内に使われる記号列として許容できるのは .. と ... までかなぁ（ただし、両方を採用すると、ぱっと見では見分けがつきにくいという問題がある）。..= とか ..< は、もちろんそれなりに合理的な考慮の上で採用されたんだろうけど、もう見た目で受け付けないわ。
Rustも基本的には .. を使えってことなんじゃない？ 一応、..= も用意してあるけど、どうしても必要なケースがあるなら使ってねくらいの位置付けに過ぎないと思う。
71: 09/23(火)10:03 ID:U5/crNyE(1) AAS
範囲を表すのは .. だけにして、含まれない端点にはマーカー文字をつけるという方法もありそうだけど、目立つ採用例がないってことはたぶん問題があるんだろうね。
1 .. 5 → 1から5まで
1 .. 5^ → 1から4まで
72: 09/23(火)15:33 ID:rmbzdEQk(1) AAS
>>64
一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな
プログラミング言語としては半開区間が最適だ
73: 09/23(火)17:38 ID:ptEtOTO9(2/2) AAS
IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。
74(1): 09/23(火)19:08 ID:zU/q7UQ3(1/2) AAS
>>60
半開区間イテレータはゼロコスト抽象化が可能だけど、
閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、
データサイズの増大とコード実行が遅くなってしまうからね。
閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。
75: 09/23(火)19:13 ID:zU/q7UQ3(2/2) AAS
>>69
Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。
動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。
速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。
76: 09/24(水)04:44 ID:NxVT75eJ(1) AAS
歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。
77(1): 09/24(水)09:37 ID:iLsvaA+I(1) AAS
古い言語は仕方ないね
新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう
①プログラムを書く上で便利 理由>>64
②実行効率も良い 理由>>74
78: 09/25(木)07:39 ID:rGEl0fht(1) AAS
Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ
79: 09/25(木)08:04 ID:+zec6Qog(1) AAS
半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな
80: 09/25(木)10:55 ID:qSe6mg1h(1/2) AAS
Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに
81(1): 09/25(木)11:16 ID:Wia1VUCr(1) AAS
要らない..=をサポートしてしまった為に糞化してしまったRust哀れ
82(2): 09/25(木)11:29 ID:qSe6mg1h(2/2) AAS
>>81
糞化って何？
意味がわからない
83: 09/26(金)10:22 ID:UkFmEBgM(1) AAS
確かに元から糞なものが糞化とは腹が痛い
84: 09/26(金)12:42 ID:X9xxY5lJ(1) AAS
>>82
「糞化って何？」って何？
意味がわからない
元から糞なものが糞になって糞化したと言っても意味が通る
85: 09/26(金)16:46 ID:IX+dZCHo(1) AAS
>>82
ウンコになったってことだよ
86: 09/26(金)20:33 ID:/tXGYc/j(1) AAS
>>64
それよりもっと重要なことが抜けてるぞ
Pascal方式で避けられないそれら+1や-1がRust方式では不要となるだけでなく
Rust方式では長さ0を特別扱いせずに自然に扱えることが最大の特徴
Rust方式は長さnがstart..(start + n)であるため
長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
Pascal方式は長さnがstart..(start + n -1)であるため
長さ0はstart..(start -1)になり左右逆転してしまう
そのためこの不格好な逆転状態を長さ0とみなして扱うか
場合分けして長さ0を扱わないようにするか
場合分けして長さ0の時にnullとかnilとか空リストなど特別扱いする形になる
87(2): 09/27(土)00:25 ID:XX0uOJLH(1/4) AAS
＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈?
88(1): 09/27(土)00:31 ID:lQv27qFK(1) AAS
>>87
長さ1や長さ2がstart違ってあちこちにあるように
長さ0もstart違ってあちこちに存在する
89: 09/27(土)00:43 ID:XX0uOJLH(2/4) AAS
>>88
Pascalでstartの違う長さ0表して便利な例挙げてみて
90(2): 09/27(土)00:55 ID:B/IRYC2K(1/4) AAS
>>87
Rustの..は性質の良い半開区間なので、
例えばstart..endを途中のmiddleの位置で分割すると、start..middleとmiddle..endの二つに綺麗に分かれる性質も持っているよ。
そしてそのmiddleの決定算出結果が処理内容や処理状況によっては、たまたまstartと一致することも出てくる。
その時、start..middleとmiddle..endの二つは、start..startとstart..endの二つに分かれて前者は長さ0になるね。
Rustでのプログラミングでも実際にこれはよく起きるよ。
91(2): 09/27(土)01:43 ID:XX0uOJLH(3/4) AAS
>>90
区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
92(1): 09/27(土)01:48 ID:XX0uOJLH(4/4) AAS
閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。
93: 09/27(土)02:17 ID:B/IRYC2K(2/4) AAS
>>91
区間には必ずスタート位置を伴いますね。
そこから長さが2だったり長さが1だったり長さが0だったりするわけです。
長さ0の時だけスタート位置が無いのは不自然でしょう。
>>92
良い性質を備えていてメリットがあるのは半開区間でしょう。
Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。
上下前次1-新書関写板覧索設栞歴
あと 391 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 1.032s*