タグ付けされた質問 「complexity」

私が正しく知っている場合、サブセット合計問題はNP完全です。ここにn個の整数の配列があり、ターゲット合計tが与えられた場合、ターゲットから合計できる配列から数値を返す必要があります（可能な場合）。 しかし、この問題は、多項式時間でテーブルを構築するダイナミックプログラミング法では解決できません。nX tテーブルで、最後の数が出力に確実に含まれ、ターゲットがt- a [n]になる場合などです。その他の場合、最後の数は含まれず、ターゲットは同じtのままですが、配列のサイズはn-1になります。したがって、この方法で問題のサイズを小さくし続けます。 このアプローチが正しい場合、このn * tの複雑さは多項式ではありませんか？そして、これがPに属し、（私が聞いたことから）NP完全である場合、P = NP 確かに、私はここで何かを見逃しています。この推論の抜け穴はどこですか？ おかげで、

8 algorithms  efficiency  complexity 

一般に、保守性インデックスは多くの要因に依存しています。たとえば、Visual Studioでは、循環的複雑度、継承の深さ、クラス結合、コード行に依存しています。これらの4つの値はできるだけ低くする必要があります。 同時に、コードメトリックツールでも、書籍でも、循環的複雑度（CC）とコード行（LC）のみの比較を見たことはありません。 そのような比率を計算することは意味がありますか？コードについてどのような情報が提供されますか？言い換えると、LCを下げるよりもLCを下げる方が良いでしょうか？ 私が気づくのは、小規模なプロジェクトの場合、CC / LCの比率が低い（1/2以下）ことです。つまり、LCは高く、CCは低くなります。大規模なプロジェクトでは、CC / LCはほとんどの場合thanより大きくなります。どうして？

8 complexity  maintainability  code-metrics  cyclomatic-complexity