アカウント名:
パスワード:
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
単純でも悪いコードはあるだろ。
year % 4 == 0
で閏年を判定するとかさ。
普通比較するのはロジックが当たっている前提でしょ。
では、それを前提に反例を一つ示してみよう。例えば、ソートを実装するのに、
def sort(array) <<クイックソートを実装>>end
というコードがあったとしよう。<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。これに対して、次のようなコードを考える。
def sort(array) if array.size < m <<バブルソートを実装>> else <<クイックソートを実装>> endend
定数mは、実行速度が最適になるよう定める。このコードでも同様に<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
この二つのコードに関して言えば、どちらも正しい。後
まさにこれは> 複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?という例では?
複雑なコードが悪いコードであるとは限らない。の方の。
なにがやりたかったのか分からん。
そうだね。なおかつ、「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
複雑なコードは悪いコードである。と悪いコードは複雑なコードである。とでは意味が違うってわかってるのかな…。
「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
君は
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである
みたいな言い回しについて、ちゃんと理解出来てないんじゃないか?
ちゃんと理解出来てないんじゃないか?
あなたの理解を聞かせてください。
今日もRyo.Fは平常運転だなw
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりませんので、ご自分で勉強してください。
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりません
そう思い込んでいるだけでは? 説明してみれば明らかになりますよ。さあ、どうぞ。
それと、「悪いコードは複雑である」とは限らないことの実例にもなってるかを、理由も合わせてお答えください。
稀にいるよねw 言い回しとか慣用句みたいなのを理解できないで、言葉通りに読もうとする奴って。
この手の言い回し、そこに込められた「行間」を常識的に補足すれば
複雑なコードが悪いコードであるとは限らないが、(俗に)悪いコード(として槍玉に挙げられる類いのコード)は(大概が)複雑なコードである
みたいなもんだよね。
前段で既にその存在を許されている「複雑だけれど正しいコード」を今更いくら例示しても、そもそもそれは後段で言及されている「コード」とは、概念としてリンクしていないわけで。
ま、そもそも初っ端に「悪いコード=間違ったコード」という勘違いっつうか、赤っ恥を晒したしたことへの失地回復を図って、こうしてネチネチ粘着してるんだろうけど、ドツボっていうかさ、また更に理解力のないことを晒してるよね。
件の例は、良いコードの例なので、悪いコードが~~であるということに対しては否定の材料にも肯定の材料にもならないのよ。
件の例は、良いコードの例なので
悪いコードも例示しましたが。要するに、まともな反論はできないということですね。
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
どちらもソートプログラムとして正しいですよ。プログラミングできないのなら、そう言ってください。素人にも解るように説明しますから。いずれにせよ、まともに反論できないということですね。
一般的な解釈については別の方が説明下さっていますので、そちらを参照されることですね。
#2414301 [srad.jp]
所詮は「立場が違う」以外の回答を得られそうにないあなたに対し、私がわざわざ一般教養レベルの説明をして差し上げる意義など感じません。
所詮は「立場が違う」以外の回答を得られそうにないあなたに対し
相手との立場の違いを認められないのですか?それでは話になりませんね。
私がわざわざ一般教養レベルの説明をして差し上げる意義など感じません。
私もその意義を認められません。それでぜんぜん構いませんよ。さっさと別の相手を探してください。
あなたがRyo.F大好きなのは、良く解りました(笑)。
私が言った「正しくないコード」
> 単純でも悪いコードはあるだろ。> year % 4 == 0>で閏年を判定するとかさ。
です。
で、そちらのソートプログラムの片方ですが、普通のプログラムが単純だった例です。ですから、悪いコードは複雑という例にはなりません。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
もしかしてプログラムは悪いプログラムと良いプログラムしかないと思ってますか?
既に言及した通り、立場の違いでしかないね。
既に言及した通り、「良い・悪い」の測り方による。君はRyo.Fが提示した枠組から一歩も踏み出していない。まったくもって君にはがっかりだよ。
反論するならば、「良い・悪い」の測り方を明示したまえ。ほとんどの場合、反例は作れるだろう。
そこに込められた「行間」を常識的に補足すれば
論理に行き詰まると常識を持ち出すやつが多いね。困ったもんだ。
そこまで行間を読んじゃうのは、妄想に近いよ(笑)。もしそうなら、「複雑なコードが悪いコードであるとは限らないし、悪いコードが複雑なコードであるとは限らない」だよね。前半で例外を強調しているなら、後半の断定は、例外を含まないと読むことも十分ありうるね。
「複雑だけれど正しいコード」を今更いくら例示しても
正しくて単純だけど悪いコードと、正しくて複雑だけど良いコードを例示してるのが読めない? そりゃまた困ったもんだ。
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけで、そこに個人的な解釈などナンセンスですね。
良い悪いの判断は、正しい正しくないの判断のあとにやってくるって話さえ理解してくれればそれでいいのですが、理解できてなさそうですね。
なにを言ったところで「立場の違いでしかないね」で逃げる気満々だしなぁ。#この手の死んだことに気がつかないゾンビってたち悪い。
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけ
原典を持ち出せば何かが誤魔化せると思っているようですが、それは間違いです。
原典では、「良い・悪い」の測り方は完全には定義されていません。
一方、「単純・複雑」の測り方は定義されています。コードの表面上の複雑さだけで測るのではなく、元も問題の持つ複雑さを考慮して測るべき、としていますね。
その定義に基づいて、私の例示した二つの例 [srad.jp]を考えてみましょう。コードの表面上の複雑さは、前者が単純で、後者が複雑。一方、前者・後者とも同じ問題(ソート)を扱っています。従って、元の問題の持つ複雑さは同じ。したがって、原典の定義に基づいても、前者が単純で、後者が複雑と言えます。
一方、実行速度に差がありますので、前者が悪く、後者が良い。
つまり、前者が単純で悪く、後者が複雑で良い、となりますね。
そこに個人的な解釈などナンセンスですね。
そうですか? そんなことはないと思うけどなあ。
しかし、もしそうだったら、私と同じ結論になることになりますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
必要条件なんじゃないの? (スコア: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)
今日もRyo.Fは平常運転だなw
Re: (スコア:0)
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりませんので、ご自分で勉強してください。
Re:必要条件なんじゃないの? (スコア:1)
私の理解はこの手のよくある言い回しに対する世間一般的な解釈と変わりません
そう思い込んでいるだけでは? 説明してみれば明らかになりますよ。さあ、どうぞ。
それと、「悪いコードは複雑である」とは限らないことの実例にもなってるかを、理由も合わせてお答えください。
Re: (スコア:0)
稀にいるよねw 言い回しとか慣用句みたいなのを理解できないで、言葉通りに読もうとする奴って。
この手の言い回し、そこに込められた「行間」を常識的に補足すれば
みたいなもんだよね。
前段で既にその存在を許されている「複雑だけれど正しいコード」を今更いくら例示しても、
そもそもそれは後段で言及されている「コード」とは、概念としてリンクしていないわけで。
ま、そもそも初っ端に「悪いコード=間違ったコード」という勘違いっつうか、
赤っ恥を晒したしたことへの失地回復を図って、こうしてネチネチ粘着してるんだろうけど、
ドツボっていうかさ、また更に理解力のないことを晒してるよね。
Re: (スコア:0)
件の例は、良いコードの例なので、
悪いコードが~~であるということに対しては否定の材料にも肯定の材料にもならないのよ。
Re:必要条件なんじゃないの? (スコア:1)
件の例は、良いコードの例なので
悪いコードも例示しましたが。
要するに、まともな反論はできないということですね。
Re: (スコア:0)
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
Re:必要条件なんじゃないの? (スコア:1)
そちらは悪いコードではなく、正しくないコードなので、悪いコードは複雑の例にはなりません。
どちらもソートプログラムとして正しいですよ。
プログラミングできないのなら、そう言ってください。素人にも解るように説明しますから。
いずれにせよ、まともに反論できないということですね。
Re: (スコア:0)
一般的な解釈については別の方が説明下さっていますので、そちらを参照されることですね。
#2414301 [srad.jp]
所詮は「立場が違う」以外の回答を得られそうにないあなたに対し、私がわざわざ一般教養レベルの説明をして差し上げる意義など感じません。
Re:必要条件なんじゃないの? (スコア:1)
所詮は「立場が違う」以外の回答を得られそうにないあなたに対し
相手との立場の違いを認められないのですか?
それでは話になりませんね。
私がわざわざ一般教養レベルの説明をして差し上げる意義など感じません。
私もその意義を認められません。それでぜんぜん構いませんよ。さっさと別の相手を探してください。
あなたがRyo.F大好きなのは、良く解りました(笑)。
Re: (スコア:0)
私が言った「正しくないコード」
> 単純でも悪いコードはあるだろ。
> year % 4 == 0
>で閏年を判定するとかさ。
です。
で、そちらのソートプログラムの片方ですが、
普通のプログラムが単純だった例です。
ですから、悪いコードは複雑という例にはなりません。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
もしかしてプログラムは悪いプログラムと良いプログラムしかないと思ってますか?
Re:必要条件なんじゃないの? (スコア:1)
私が言った「正しくないコード」
既に言及した通り、立場の違いでしかないね。
閾値なしにクイックソートするだけのプログラムですがこれは悪いというほどの物ではありません。
既に言及した通り、「良い・悪い」の測り方による。君はRyo.Fが提示した枠組から一歩も踏み出していない。まったくもって君にはがっかりだよ。
反論するならば、「良い・悪い」の測り方を明示したまえ。ほとんどの場合、反例は作れるだろう。
Re:必要条件なんじゃないの? (スコア:1)
そこに込められた「行間」を常識的に補足すれば
論理に行き詰まると常識を持ち出すやつが多いね。困ったもんだ。
複雑なコードが悪いコードであるとは限らないが、
(俗に)悪いコード(として槍玉に挙げられる類いのコード)は
(大概が)複雑なコードである
そこまで行間を読んじゃうのは、妄想に近いよ(笑)。
もしそうなら、「複雑なコードが悪いコードであるとは限らないし、悪いコードが複雑なコードであるとは限らない」だよね。前半で例外を強調しているなら、後半の断定は、例外を含まないと読むことも十分ありうるね。
「複雑だけれど正しいコード」を今更いくら例示しても
正しくて単純だけど悪いコードと、正しくて複雑だけど良いコードを例示してるのが読めない? そりゃまた困ったもんだ。
Re: (スコア:0)
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけで、そこに個人的な解釈などナンセンスですね。
Re: (スコア:0)
良い悪いの判断は、正しい正しくないの判断のあとにやってくるって話さえ理解してくれればそれでいいのですが、理解できてなさそうですね。
Re: (スコア:0)
なにを言ったところで「立場の違いでしかないね」で逃げる気満々だしなぁ。
#この手の死んだことに気がつかないゾンビってたち悪い。
Re:必要条件なんじゃないの? (スコア:1)
各人の「良い・悪い」の測り方や、「立場の違い」にて逃れようとしているようですが、もともとその定義は原典 [drdobbs.com]にて提示された定義に則ってるわけ
原典を持ち出せば何かが誤魔化せると思っているようですが、それは間違いです。
原典では、「良い・悪い」の測り方は完全には定義されていません。
一方、「単純・複雑」の測り方は定義されています。コードの表面上の複雑さだけで測るのではなく、元も問題の持つ複雑さを考慮して測るべき、としていますね。
その定義に基づいて、私の例示した二つの例 [srad.jp]を考えてみましょう。コードの表面上の複雑さは、前者が単純で、後者が複雑。一方、前者・後者とも同じ問題(ソート)を扱っています。従って、元の問題の持つ複雑さは同じ。したがって、原典の定義に基づいても、前者が単純で、後者が複雑と言えます。
一方、実行速度に差がありますので、前者が悪く、後者が良い。
つまり、前者が単純で悪く、後者が複雑で良い、となりますね。
そこに個人的な解釈などナンセンスですね。
そうですか? そんなことはないと思うけどなあ。
しかし、もしそうだったら、私と同じ結論になることになりますね。