もし「c = a + b」という行を書くなら、これは学校の授業でしか通用しない理論的なプログラミングである。しかし、実際の工業プラントをプログラミングする場合、"c = a + b "のような1つの便利な操作には、1つの入力が本当に "a "であり、もう1つの入力が本当に "b "であることを確認するために100500回のチェック操作が必要であり、さらに "a "と "b "が加算中に変化していないことを確認しなければならない。現実の世界へようこそ ))))
もしあなたが「c = a + b」という行を書いたとしたら、これは学校の授業でしか通用しない理論的なプログラミングである。しかし、実際の工業プラントのプログラミングでは、"c = a + b "のような1つの便利な操作でも、1つの入力が本当に "a "であり、もう1つの入力が本当に "b "であることを確認するために、さらに100500回のチェック操作が必要になる。また、"a "と "b "が加算中に変化していないことも確認しなければならない。現実の世界へようこそ ))))。
この記事では、スイッチがあるということ以外はまったく取り上げられていない。存在するかどうかは問題ではなく、ifで切り替えることができる。
あるEAを書いていたとき、注文のある非常に複雑なシステムがあった。私はそれを真剣に分析し、注文なし、1つの未決注文、1つの成行注文、2つの未決注文、1つの未決注文と1つの成行注文などの状態のリストを作らなければなりませんでした。こうすることで、なんとか克服することができた。しかし、このように普遍的で、すぐにプログラムし直せるものであることが判明した。記事にするにはかなりのトピックだ。
それなら記事を書いてもいいんじゃない？ 多くの人が興味を持って読んでくれると思うよ。
わかりました。
また、普通のifを使うのもいい。一般的には、ifの助けを借りる方法と、スイッチの状態切り替えによって呼び出される特別な関数の助けを借りる方法の2つのアプローチがある。問題は、どちらのアプローチがより良いのか、より簡単なのかということである。
対象を見てみる必要があるが、カウンターの方が解を選択するのが早いが、ifの方が呼び出しやすい。
ネストされたカウンターがたくさんある場合は、ifの方が速く動作する。なぜなら、ifを1回呼び出す方がswitchを1回呼び出すよりも安いからだ。
しかし、各レベルに複数の解決策がある場合は、switchの方が適切である。
これは新しいことだ。どんなTSも（例外なく）分析とTSの状態の明確な理解に基づいている。最も単純な状態：注文の新規/決済/変更のためのシグナルの処理などなど。
もし「エキスパートアドバイザーの現在の状態がわからない」のであれば、それは間違いなくエキスパートアドバイザーではなく、間違いなくプログラムでもない。
マーケット情報は遅れて入ってくるし、サーバーやコンピュータのソフトウェアにエラーが発生することもある（おそらくある）。不確定要素は十分すぎるほどある。そして、エキスパート・アドバイザーやアルゴリズムは、そのすべてを考慮に入れなければならない。サーバー、ソフトウェア、通信、市場、オペレーター、電力が完璧に機能することを当てにすることは不可能です。
そのため、現在の注文、市場、通信、電気の状態はエキスパートアドバイザーには決してわかりません。エキスパートアドバイザーやアルゴリズムは、あいまいな状態でも正しく機能しなければなりません。
マーケット情報は遅れて入ってくるし、サーバーやコンピュータのソフトウェアにエラーがあるかもしれない（そしておそらくある）し、注文は100万通りの理由で執行されないかもしれないし、ネットワーク（プロバイダーとの接続）は点滅するかもしれないし、電気はいつ遮断されるかもしれない（チャンピオンシップでの故障と再起動を思い出してほしい）。不確定要素は十分すぎるほどある。そして、エキスパート・アドバイザーやアルゴリズムは、そのすべてを考慮に入れなければならない。サーバー、ソフトウェア、通信、市場、オペレーター、電力が完璧に機能することを当てにすることは不可能です。
つまり、現在の注文、市場、通信、電気の状態は、エキスパートアドバイザーには決してわからないのであり、エキスパートアドバイザーやアルゴリズムは、あいまいな状態でも正しく機能しなければならない。
ナンセンスだ。すべてを1つの大きな山に混ぜる。
- ブローカーが注文の執行を拒否した場合、EAが異常再起動した場合、これらはEAの明確で明確な状態です。
- ある可能性のある状態に対してある機能が提供されない場合、それは「ファジーな動作状態」を意味するのではなく、単にEAがその状態を（明確かつ一義的なアルゴリズムに従って）分析しないことを意味します。
どのようなプログラム（Expert Advisorを含む）も、明確な所定のアルゴリズムに従って動作します。そして、どのようなプログラムの作業においても、あいまいで未定義のアクションはありません。そうでなければ、それは「フリーズ」状態となる。そして、プログラムの「フリーズ」は、ご存知のように、アルゴリズムのエラーであり、エーテル的な曖昧さの結果ではない。
実際のExpert Advisorでは、状態を一義的に定義することは不可能です。内部状態は一義的に決定されますが、サーバー上のポジションの状態は不明であったり、遅延して判明したり、不明確な状態であったりします（ある注文やリクエストは実行され、ある注文やリクエストは実行されない、そしてその理由は誰も知らない）。
不確実要素は十分すぎるほどある。そして、Expert Advisorやアルゴリズムは、そのすべてを考慮に入れる必要があります。サーバー、ソフトウェア、通信、市場、オペレーター、電気などの完璧な働きをあてにすることは不可能です。したがって、注文、市場、通信、電気の現在の状態は、一般的に、エキスパート-アドバイザーには決して知られていない
不確実性はありません。あるのは、何かを考慮しなかったプログラマーのミスである。
「不明」「不明確な状態」は、他のすべての状態と同様に、本格的な状態です。もちろん、それらを考慮しなければならない。
もし「c = a + b」という行を書くなら、これは学校の授業でしか通用しない理論的なプログラミングである。しかし、実際の工業プラントをプログラミングする場合、"c = a + b "のような1つの便利な操作には、1つの入力が本当に "a "であり、もう1つの入力が本当に "b "であることを確認するために100500回のチェック操作が必要であり、さらに "a "と "b "が加算中に変化していないことを確認しなければならない。現実の世界へようこそ ))))
不確実性はない。あるのは、何かを考慮しなかったプログラマーのエラーだ。
不明」「不明確な状態」--これらは他のものと同様、れっきとした「状態」である。もちろん、それらを考慮しなければならない。
もしあなたが「c = a + b」という行を書いたとしたら、これは学校の授業でしか通用しない理論的なプログラミングである。しかし、実際の工業プラントのプログラミングでは、"c = a + b "のような1つの便利な操作でも、1つの入力が本当に "a "であり、もう1つの入力が本当に "b "であることを確認するために、さらに100500回のチェック操作が必要になる。また、"a "と "b "が加算中に変化していないことも確認しなければならない。現実の世界へようこそ ))))。
いい例えだね。))しかし、いずれにしてもすべてを説明することは不可能であることを忘れてはならない。自然だって間違いを犯すし、突然変異という形でその間違いを見逃すこともある。もちろん、完璧を目指すべきだが。))
自然は間違いを犯さない。我々はそれを正当化する理論を考え出す。
そして、自然は無意識のものであり、誰が正しくて誰が罪なのかには従わない。
...
そして自然は無意識で あり、それゆえに...