アカウント名:
パスワード:
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
単純でも悪いコードはあるだろ。
year % 4 == 0
で閏年を判定するとかさ。
普通比較するのはロジックが当たっている前提でしょ。
では、それを前提に反例を一つ示してみよう。例えば、ソートを実装するのに、
def sort(array) <<クイックソートを実装>>end
というコードがあったとしよう。<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。これに対して、次のようなコードを考える。
def sort(array) if array.size < m <<バブルソートを実装>> else <<クイックソートを実装>> endend
定数mは、実行速度が最適になるよう定める。このコードでも同様に<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
この二つのコードに関して言えば、どちらも正しい。後
まさにこれは> 複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?という例では?
複雑なコードが悪いコードであるとは限らない。の方の。
なにがやりたかったのか分からん。
そうだね。なおかつ、「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
複雑なコードは悪いコードである。と悪いコードは複雑なコードである。とでは意味が違うってわかってるのかな…。
「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
君は
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである
みたいな言い回しについて、ちゃんと理解出来てないんじゃないか?
ちゃんと理解出来てないんじゃないか?
あなたの理解を聞かせてください。
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりませんので、ご自分で勉強してください。
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりません
そう思い込んでいるだけでは? 説明してみれば明らかになりますよ。さあ、どうぞ。
それと、「悪いコードは複雑である」とは限らないことの実例にもなってるかを、理由も合わせてお答えください。
件の例は、良いコードの例なので、悪いコードが~~であるということに対しては否定の材料にも肯定の材料にもならないのよ。
件の例は、良いコードの例なので
悪いコードも例示しましたが。要するに、まともな反論はできないということですね。
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
どちらもソートプログラムとして正しいですよ。プログラミングできないのなら、そう言ってください。素人にも解るように説明しますから。いずれにせよ、まともに反論できないということですね。
私が言った「正しくないコード」
> 単純でも悪いコードはあるだろ。> year % 4 == 0>で閏年を判定するとかさ。
です。
で、そちらのソートプログラムの片方ですが、普通のプログラムが単純だった例です。ですから、悪いコードは複雑という例にはなりません。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
もしかしてプログラムは悪いプログラムと良いプログラムしかないと思ってますか?
既に言及した通り、立場の違いでしかないね。
既に言及した通り、「良い・悪い」の測り方による。君はRyo.Fが提示した枠組から一歩も踏み出していない。まったくもって君にはがっかりだよ。
反論するならば、「良い・悪い」の測り方を明示したまえ。ほとんどの場合、反例は作れるだろう。
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけで、そこに個人的な解釈などナンセンスですね。
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけ
原典を持ち出せば何かが誤魔化せると思っているようですが、それは間違いです。
原典では、「良い・悪い」の測り方は完全には定義されていません。
一方、「単純・複雑」の測り方は定義されています。コードの表面上の複雑さだけで測るのではなく、元も問題の持つ複雑さを考慮して測るべき、としていますね。
その定義に基づいて、私の例示した二つの例 [srad.jp]を考えてみましょう。コードの表面上の複雑さは、前者が単純で、後者が複雑。一方、前者・後者とも同じ問題(ソート)を扱っています。従って、元の問題の持つ複雑さは同じ。したがって、原典の定義に基づいても、前者が単純で、後者が複雑と言えます。
一方、実行速度に差がありますので、前者が悪く、後者が良い。
つまり、前者が単純で悪く、後者が複雑で良い、となりますね。
そこに個人的な解釈などナンセンスですね。
そうですか? そんなことはないと思うけどなあ。
しかし、もしそうだったら、私と同じ結論になることになりますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
必要条件なんじゃないの? (スコア:0)
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
Re: (スコア:1)
単純でも悪いコードはあるだろ。
で閏年を判定するとかさ。
Re: (スコア:0)
普通比較するのはロジックが当たっている前提でしょ。
Re: (スコア:0)
では、それを前提に反例を一つ示してみよう。例えば、ソートを実装するのに、
というコードがあったとしよう。<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
これに対して、次のようなコードを考える。
定数mは、実行速度が最適になるよう定める。このコードでも同様に<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
この二つのコードに関して言えば、どちらも正しい。後
Re: (スコア:0)
まさにこれは
> 複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
という例では?
複雑なコードが悪いコードであるとは限らない。の方の。
なにがやりたかったのか分からん。
Re: (スコア:0)
複雑なコードが悪いコードであるとは限らない。の方の。
そうだね。
なおかつ、「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
Re: (スコア:0)
複雑なコードは悪いコードである。
と
悪いコードは複雑なコードである。
とでは意味が違うってわかってるのかな…。
Re: (スコア:0)
「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
Re: (スコア:0)
君は
みたいな言い回しについて、ちゃんと理解出来てないんじゃないか?
Re: (スコア:0)
ちゃんと理解出来てないんじゃないか?
あなたの理解を聞かせてください。
Re: (スコア:0)
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりませんので、ご自分で勉強してください。
Re: (スコア:1)
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりません
そう思い込んでいるだけでは? 説明してみれば明らかになりますよ。さあ、どうぞ。
それと、「悪いコードは複雑である」とは限らないことの実例にもなってるかを、理由も合わせてお答えください。
Re: (スコア:0)
件の例は、良いコードの例なので、
悪いコードが~~であるということに対しては否定の材料にも肯定の材料にもならないのよ。
Re: (スコア:1)
件の例は、良いコードの例なので
悪いコードも例示しましたが。
要するに、まともな反論はできないということですね。
Re: (スコア:0)
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
Re: (スコア:1)
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
どちらもソートプログラムとして正しいですよ。
プログラミングできないのなら、そう言ってください。素人にも解るように説明しますから。
いずれにせよ、まともに反論できないということですね。
Re: (スコア:0)
私が言った「正しくないコード」
> 単純でも悪いコードはあるだろ。
> year % 4 == 0
>で閏年を判定するとかさ。
です。
で、そちらのソートプログラムの片方ですが、
普通のプログラムが単純だった例です。
ですから、悪いコードは複雑という例にはなりません。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
もしかしてプログラムは悪いプログラムと良いプログラムしかないと思ってますか?
Re: (スコア:1)
私が言った「正しくないコード」
既に言及した通り、立場の違いでしかないね。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
既に言及した通り、「良い・悪い」の測り方による。君はRyo.Fが提示した枠組から一歩も踏み出していない。まったくもって君にはがっかりだよ。
反論するならば、「良い・悪い」の測り方を明示したまえ。ほとんどの場合、反例は作れるだろう。
Re:必要条件なんじゃないの? (スコア:0)
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけで、そこに個人的な解釈などナンセンスですね。
Re:必要条件なんじゃないの? (スコア:1)
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけ
原典を持ち出せば何かが誤魔化せると思っているようですが、それは間違いです。
原典では、「良い・悪い」の測り方は完全には定義されていません。
一方、「単純・複雑」の測り方は定義されています。コードの表面上の複雑さだけで測るのではなく、元も問題の持つ複雑さを考慮して測るべき、としていますね。
その定義に基づいて、私の例示した二つの例 [srad.jp]を考えてみましょう。コードの表面上の複雑さは、前者が単純で、後者が複雑。一方、前者・後者とも同じ問題(ソート)を扱っています。従って、元の問題の持つ複雑さは同じ。したがって、原典の定義に基づいても、前者が単純で、後者が複雑と言えます。
一方、実行速度に差がありますので、前者が悪く、後者が良い。
つまり、前者が単純で悪く、後者が複雑で良い、となりますね。
そこに個人的な解釈などナンセンスですね。
そうですか? そんなことはないと思うけどなあ。
しかし、もしそうだったら、私と同じ結論になることになりますね。