なぜ95%のケースでアルゴリズムを書くのか、そしてコードバイクの開発を続ける

これは、 「プログラマーのアルゴリズムを知る必要がありますか?」という出版物に対する回答です



では、なぜ95%のケースでアルゴリズムを書くのですか?さらに書くのでしょうか?



簡潔にするために、私はすぐに私のケースの詳細を説明します(非常にエキゾチックです)が、多くの類似したケースがあることに注意します。 実際にケースアナログがない場合は、おめでとうございます。自転車に煩わされる必要はありません。 棚からケーキを取ります...既製のコードを取ります。これはRADにとって本当に素晴らしいオプションであり、時間はお金であり、特別な要件はありません。



私は実験的な有翼ドローン制御システムの開発者です。



1.コードに「ブラックボックス」が含まれていないこと



コンパイルされたライブラリについても話していません(最初はタブーです。非効率で汚いコードは非常に可能性が高く、その中の「ブックマーク」は潜在的に可能です)。 インターネットで見つかったコードフラグメントについて話しているが、私は完全には理解していない。 私のシステムは、第一に、開発者としての仕事のアルゴリズムを完全に明確にする必要があります。 問題箇所を見つけて修正する必要があります。



2.合計160メガヘルツと300 kbのRAMがあります



そもそもメガヘルツを費やす余裕はありませんが、2キロバイトです。



「大きなマシン」の下での現代の開発者は、豊富なリソースに甘やかされています。 彼らはコードを最適化せず、「そしてそれは賢く動作する/コンパイラはすべてを最適化する」というスタイルで冗長な構築をする傾向がある。 これにより、大規模なコンピューターのコードが多少なりとも正常になり、奇妙なエコシステム(マイクロコントローラー(MK)など)で実行不可能になることがよくあります。



したがって、MKのコードは、コードで2回以上使用されるすべてを完全に開示および計算する必要があります。 非常にグローバルな最適化のようなもの。 したがって、「フォーラムとスタックオーバーフローから」ソリューションが採用された場合でも、それがチェックおよび最適化されます(このような最適化の最も簡単な例は、通常の三角関数を表形式の計算関数に置き換えることです)。



私のコードでは、多くの絶対的なgoto遷移が使用されており、すべての不要な計算は可能な限り削減されています。 通常、優れたエイリアンコードは遅く、不器用です。 たとえば、テクニカルサポート。 素晴らしいOpenCVライブラリ-しかし、どこに押し込めばいいですか? これはコードモンスターです! 豊富なテクニカルビジョン機能から、移動するオブジェクトとその境界までの距離を判断するだけです。 また、高頻度で。 他の人の経験を学びますが、自分で書いてください。



3.私のコードは、論理エラーの観点から高速で安全でなければなりません



他の人のコードのセキュリティと安定性を確認することは非常に困難です。 そして、あらゆる種類のcppcheckは役に立ちません。 これらは優れたツールですが、技術的なエラーのみを検出しますが、他の人のコードで発生するアルゴリズムエラーは検出しません。 多くの場合、他の人の要件を調整して書き換えるよりも、アイデアとソリューションを理解して最初から書く方が簡単です。 はい、時間がかかりますが、出力は非常に効率的で安全なコードです。 目的のタスクに合わせて正確にシャープにします。



そして、研究中のトピックに関する個人的な経験に少し。



4.自転車を扱うもう1つの理由は、純粋に産業的なものです



私の業界には、オープンソースの自動操縦のbeat折した道から逃れるとすぐに、既製の(オープンな)ソリューションはありません。 たとえば、低レベルでの飛行制御の問題(軌道がどうあるべきかが既にわかっていて、ボードの位置をそれに合わせる必要がある場合)は、理論的な作品で通常のPIDチェーンとして説明されています。 一般的にすべてが単純ですが、エルディアブロは詳細にあります。 何百もの小さな部品で。 エンジンが故障したらどうしますか? GPS側が+ -150mで散歩に出かけた場合は? 振動により慣性ホライズンセンサーが極星の領域でホライズンへの方向を示している場合は? などなど。 あなたは言うことができます:PIDはどこですか? これは範囲を超えています! そして、あなたは正しいでしょうが、異なるアルゴリズムとその要素を異なる機能に混在させるため、最終的なタスクは制御です。 したがって、すべてのアルゴリズムはゼロから作成され、洗練され、自動UAV制御のコンテキストで特定のタスク専用に理想化されています。 変更が非常に困難ですが、問題を解決するのに非常に効果的なコードのかなり活発なスパゲッティ混合物が判明します。



よく忘れられている(または覚えるのが面倒)よく知られている真実:効率/速度は普遍化の反対です。 直接的なコントラストではありませんが、同じスケールではありません。 比economical的に言えば、非常に経済的なエコシステムのためにソフトウェアが作成されると、すべての副鼻腔が重要になります。 さらに、遅延()を使用すると、一部のライブラリ作成者は、この同じ遅延()で「撮影」(創造的なeg話)してプロセスを拡張する必要があります。 したがって、すべての高速関数は、その場で作成され、汎用性が制限されており、既製の汎用とは見なされません。



同僚、自転車を自由に作成してください。 これにより、脳は良好な状態に保たれ、多くの場合、自明ではない解決策を得ることができます。



PS:著者の意見はあなたの意見と一致しないかもしれません。



All Articles