アカウント名:
パスワード:
「配列のすべての要素が条件を満たすならtrueを返す」と書かれているということは、前提としてはfalseであり、「条件を満たさない限りtrueにはならない」のである。簡単に言えばホワイトリスト式ということだ。よって、空配列を渡すと条件を満たすことがないのでfalseになるのが正解である。
対して、これが「配列のいずれかの要素が条件を満たさないならfalseを返す」だった場合、ブラックリスト式なので、前提としてtrueであり、「条件を満たさない要素があった場合のみfalseになる」ので、空配列を渡すと、条件を満たさないことがないので「true」になる。
いいプログラマは、こういう論理の落とし穴を理解してうまく対処できるプログラマである。
関数の仕様は空集合の入力においてvacuously trueの原則に従います。・JavaScriptのarrayのanyメソッドは、空の配列に対してはあらゆる条件でtrueを戻す。・Pythonのall関数は、空のリストに対してはあらゆる条件でtrueを戻す。・RustのIterator::all関数は、ゼロ要素の場合あらゆるpredicatorでtrueを戻す。
空の配列を入力してfalseを戻す関数というのは、一般的な常識から考えて全く予想外の動作であり、無用な混乱を呼ぶので避けた方が良いと思う。
その原則は明示的な仕様がない場合の話で、明確に定義されてるんだから、そこに従わざるを得ない。
「配列のすべての要素が条件を満たすならtrueを返す」という条件なら、空の配列を渡せば数学的には疑問の余地なくTrueになる。空集合はすべての集合の部分集合であると定義されているので、仮に空集合がFalseになるなら、どのような集合を入力する場合でもFalseになってしまうので。
あとはプログラミング言語の方言というか、経験的な物がどうかという点だが、その点でも普通はTrueだというのが前のコメント。
> 空集合はすべての集合の部分集合であると定義されているので、
勝手に仕様を書き足してんじゃねえよクソが。
俺はゼロで割ってはいけないなんて知らなかった！仕様に書いとけクソが！なんてプログラマにとっての常識を持ち合わせてませんってな自己アピールして良いことありそう？
> プログラマにとって違います。数字を扱うすべての人にとって、です。仕様書に1+1=2と書いとけ！みんなが判ると思うな！というぐらいに情けない話でしょう。数字を扱わないならまあ……知らなくてもいいですかね。
明示的な仕様を決める人がこういった背景を理解しているのならば、この関数(関数Fとする)を必ず空集合の入力にtrueを戻す設計にするでしょう。それが常識的な動作であり、当然そうなると皆が期待している。
計算機は本質的に数学の問題を解く機械であり、数学の法則に従った設計が最も効率が良くなる。たとえば、関数Fを実装するとき中でライブラリ関数を呼び出すとしたら、空配列の場合の特別な分岐処理は不要で、中でそのままライブラリ関数を呼び出すだけで良くなる。もしも関数Fを呼び出す関数(関数G)が、関数Fが空の配列の場合にtrueが戻すのが都合が悪い場合、関数GはFを呼ぶ前にその特別な処理に移行すればよい。関数Gが、関数Fが空の配列の場合にtrueを戻す動作が都合が良い場合そのままFを呼び出せばよい。Fの中で例外をthrowし、Gがそれをcatchする設計は、全体として一般的なやり方ではないから読みにくいし、動作効率の面で問題が起きる場合がある。
書いてないことを勝手に読み取ると、多くの人が迷惑する。仕様が間違ってるとしても、それに依拠している人がいるんだから、それに従わないと。
「コンテナに対してboolを問う処理」は集合論に準拠するのがセオリーですね。実在する要素が大事な場合はtrue/falseでなく「その要素(群)」が返り値になるはずで、(find(...) != null) や (filter(...).length > 0) のほうが可読性も良くなります。
案の定コメント欄もこれだけ伸びましたが、それらのコメントを眺めていても返り値true/falseでそのドメインに至るかどうかの話に帰結している気がします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
迷う余地などなく「false」を返すのが正しい。 (スコア:0)
「配列のすべての要素が条件を満たすならtrueを返す」と書かれているということは、
前提としてはfalseであり、「条件を満たさない限りtrueにはならない」のである。
簡単に言えばホワイトリスト式ということだ。よって、空配列を渡すと条件を満たす
ことがないのでfalseになるのが正解である。
対して、これが「配列のいずれかの要素が条件を満たさないならfalseを返す」
だった場合、ブラックリスト式なので、前提としてtrueであり、「条件を満たさない
要素があった場合のみfalseになる」ので、空配列を渡すと、条件を満たさないことが
ないので「true」になる。
いいプログラマは、こういう論理の落とし穴を理解してうまく対処できるプログラマ
である。
Re:迷う余地などなく「false」を返すのが正しい。 (スコア:0)
関数の仕様は空集合の入力においてvacuously trueの原則に従います。
・JavaScriptのarrayのanyメソッドは、空の配列に対してはあらゆる条件でtrueを戻す。
・Pythonのall関数は、空のリストに対してはあらゆる条件でtrueを戻す。
・RustのIterator::all関数は、ゼロ要素の場合あらゆるpredicatorでtrueを戻す。
空の配列を入力してfalseを戻す関数というのは、一般的な常識から考えて全く予想外の動作であり、
無用な混乱を呼ぶので避けた方が良いと思う。
Re: (スコア:0)
その原則は明示的な仕様がない場合の話で、明確に定義されてるんだから、そこに従わざるを得ない。
Re: (スコア:0)
「配列のすべての要素が条件を満たすならtrueを返す」という条件なら、空の配列を渡せば数学的には疑問の余地なくTrueになる。
空集合はすべての集合の部分集合であると定義されているので、仮に空集合がFalseになるなら、どのような集合を入力する場合でもFalseになってしまうので。
あとはプログラミング言語の方言というか、経験的な物がどうかという点だが、その点でも普通はTrueだというのが前のコメント。
Re: (スコア:0)
> 空集合はすべての集合の部分集合であると定義されているので、
勝手に仕様を書き足してんじゃねえよクソが。
Re: (スコア:0)
俺はゼロで割ってはいけないなんて知らなかった！仕様に書いとけクソが！
なんてプログラマにとっての常識を持ち合わせてませんってな自己アピールして良いことありそう？
Re: (スコア:0)
> プログラマにとって
違います。数字を扱うすべての人にとって、です。
仕様書に1+1=2と書いとけ！みんなが判ると思うな！というぐらいに情けない話でしょう。
数字を扱わないならまあ……知らなくてもいいですかね。
Re:迷う余地などなく「false」を返すのが正しい。 (スコア:1)
// 数学からすると 1+1 = 0か1か2か
Re: (スコア:0)
明示的な仕様を決める人がこういった背景を理解しているのならば、この関数(関数Fとする)を必ず空集合の入力にtrueを戻す設計にするでしょう。それが常識的な動作であり、当然そうなると皆が期待している。
計算機は本質的に数学の問題を解く機械であり、数学の法則に従った設計が最も効率が良くなる。たとえば、関数Fを実装するとき中でライブラリ関数を呼び出すとしたら、空配列の場合の特別な分岐処理は不要で、中でそのままライブラリ関数を呼び出すだけで良くなる。
もしも関数Fを呼び出す関数(関数G)が、関数Fが空の配列の場合にtrueが戻すのが都合が悪い場合、関数GはFを呼ぶ前にその特別な処理に移行すればよい。関数Gが、関数Fが空の配列の場合にtrueを戻す動作が都合が良い場合そのままFを呼び出せばよい。Fの中で例外をthrowし、Gがそれをcatchする設計は、全体として一般的なやり方ではないから読みにくいし、動作効率の面で問題が起きる場合がある。
Re: (スコア:0)
書いてないことを勝手に読み取ると、多くの人が迷惑する。仕様が間違ってるとしても、それに依拠している人がいるんだから、それに従わないと。
Re: (スコア:0)
「コンテナに対してboolを問う処理」は集合論に準拠するのがセオリーですね。
実在する要素が大事な場合はtrue/falseでなく「その要素(群)」が返り値になるはずで、
(find(...) != null) や (filter(...).length > 0) のほうが可読性も良くなります。
案の定コメント欄もこれだけ伸びましたが、それらのコメントを眺めていても
返り値true/falseでそのドメインに至るかどうかの話に帰結している気がします。