新しいものを表示

つまり逆の問題だと思い込んで「逆じゃないの???><」ってなってた><;
そりゃ逆になるでしょ感・・・><;

ていうかつまり、全てのカラスは白いか?(だっけ?><;)の話みたいな話なのに、オレンジはそこを理解できず「どういう事?><;」ってなった上に、そもそも元々の問題を(論理的に)正反対にとらえて逆の論理の問題と思い込んで「trueだと危ないんじゃね?><」ってなったって事だよね?><;

なんか変なこと言ってたら具体的に鉞投げて欲しい><;

がんばって元の主張に反するパターンを考えたら、むしろ元の主張に沿ったパターンに思いいたり「そういうことか!><;」ってなったパターン><;

これって、論理を反転させて見ると「条件に反する項目があれば実行しない(し、なければ実行する)」になるわけで、それってつまり数学好きな人がしてる主張と同じになるし、
・・・つまりオレンジは数学界隈の人にごめんなさいしないといけない><;

スレッドを表示

つまりオレンジのさっきの条件勘違いでの発想は「空配列の時にカバー出来なくなるバグの可能性がひとつ増える><」ので、安全側ではないって主張だったわけだけど、なるほどしたあとの例は「そもそも『全て揃っているか?』を判断するコードがなければならず、それが欠けていれば空配列だろうがそうじゃなかろうが同じバグになる><」ので、危険性は増えてないかもって><

それはそうだけど、バグとフールプルーフ的な意味で・・・><

orange さんがブースト

「全ての入力がパスしているか」を見たいなら全ての入力(空も含む)を入れる方が筋では?と思ったりした

とりあえず納得した気がする><;

お手間をとらせて申し訳ない気持ち><;

オレンジ流に「trueでよい」で考えるなら、「配列の中身が全部そうである」は「その配列に判断に必要な要素が全て入っていることは保証していない」ので、つまり「その配列に必要なものが揃ってないかもしれない可能性」は常にあるので、trueを返すことによって増える危険性は無視できるほど小さいのかも><
かも?><;

例えば、『チェック済み項目と「それをパスしているか?」の組み合わせ』が入ってる配列で「全部おkだったらtrue」って仕様だと、チェック済み項目が空(まだひとつもチェック終わってない)でもtrueになっちゃうけど、
でも、それは全部チェックし終わってなくてもtrueになっちゃうわけだからそもそもバグってる><

という事はtrueでおk?><;

・・・・なるほどではあるけど、でも直感的には、まだ「(でも、それってほんとに安全側になる?><;)」って疑問が><;

畳み込みの視点から見たforall(every)とexists(some): 空集合に対するforallは常にtrueになる - Lambdaカクテル blog.3qe.us/entry/2023/05/30/2

"・「配列のすべての要素が条件を満たすならtrueを返す」関数を空集合に対して適用すると、常にtrueになる
・「配列の要素が1つでも条件を満たすならtrueを返す」関数を空集合に対して適用すると、常にfalseになる"

なるほど!><;

orange さんがブースト

畳み込みの視点から見たforall(every)とexists(some): 空集合に対するforallは常にtrueになる - Lambdaカクテル
https://blog.3qe.us/entry/2023/05/30/213713

orange さんがブースト

includes/exists/some/anyは存在するとかいずれかが一致するとかだから、空なら存在・一致しないのでfalse。

orange さんがブースト

Re:オーストラリア市場撤退って事? srad.jp/comments.pl?sid=860395

なんとなく返信書いておいた

orange さんがブースト

配列内に条件付きの項目がひとつでもあるかを返す関数が、空配列に対してtrueを返すのって、実用上でそれがバグの原因になりにくい場面なんてあるの?><
例えば、飲食店で「お客の残りの注文の中にうどんがひとつでも含まれてたら、うどん茹でマシンの電源をいれる」って処理があるとしたら、残りの注文はもうないって時に、予め空配列を除外するコードを書き忘れてたら、うどんを茹でる必要がないのに電源が入っちゃうじゃん?><

古いものを表示
:realtek:

思考の /dev/null