MQLによる非同期・マルチスレッドプログラミング - ページ 16

 
Roman:

すでに書きましたが、NSを作ろうとしているのですね、この場合非同期は必要ないのでしょうか?
しかし、あなたは単純な活性化関数でNSを構築しているので、並行性の欠如に遭遇していません。
しかし、NSのグローバルモデルを構築するようになれば、非同期の素晴らしさを理解できるようになるはずです。

悪い例-必要ない!

すでに@Roffildは スレッドで「今日の世界では、プログラマーは特定のタスクに適したツールを選択するために、いくつかの言語を知っていなければ なりません。"

然うは斯くの如し

MQLでは、MQL用のパッケージの選択肢はありません - AlgLibのみです - Hubraで見つけた例を考えてみたいと思います、私はC#やPythonをMQLに接続します - それだけです、私は自分のやりたいことをやるだけで、MQLにコードを移植するわけではありません

最近のプログラミング言語は、その機能ではなく、既成のフレームワークが面白いのです- MQLに新しいMQLパッケージが登場すれば、別のタスクや問題も出てくるでしょう

ZS: もう一度言いますが、あなたはクロスプラットフォーム言語のPythonやJavaから発展した「fxのアイデア」に固執していますね。

 
Igor Makanu:

悪い例-必要ない!

すでに@Roffildは スレッドで「今日の世界では、プログラマーは特定のタスクに適したツールを選択するために、いくつかの言語を知っていなければ なりません。"

然うは斯くの如し

MQLでは、MQL用のパッケージの選択肢はありません - AlgLibのみです - Hubraで見つけた例を考えてみたいと思います、私はC#やPythonをMQLに接続します - それだけです、私は自分のやりたいことをやるだけで、MQLにコードを移植するわけではありません

最近のプログラミング言語は、その機能ではなく、既成のフレームワークが面白いのです- MQLに新しいMQLパッケージが登場すれば、別のタスクや問題も出てくるでしょう

ZS: もう一度言いますが、あなたは、クロスプラットフォーム言語のPythonやJavaから発展した「fxのアイデア」に固執していますね。

次のようなことを常に無視していますね。

1.外部接続を使用するプログラムの配布は、Market経由では行えません。

2.外部接続を利用するプログラムは、ユーザーが「教授」になって、すべてを正しく接続することが必要です。このようなプログラムの使い方は、説明書がぐちゃぐちゃです。

3.外部接続を利用したプログラムは、個人的な使用にしか適さないため、その作成感覚は大きく制限されます。

4. 個人で使うプログラムは、販売されているものより品質が 劣ります。5カ国語目から10カ国語目まで知っている言語もあり、製品のクオリティに影響します。

5.非同期やマルチスレッドを必要とするタスクはたくさんあります。MQL-Programはまだこれらの課題に到達していませんが、それを目指してはいけないということではありません。

 
Roman:

...
1つのストリームで非同期を実現するもの。

いや、まあ、マルチスレッドなしの非同期は本当にナンセンスで、少なくとも1つのスレッドを追加する必要があります。EventLoopはローダブルインジケーターを介して行うことができると思います。ソケットを介したエキスパートインジケータ間の通信など。タスクの作成、インジケータの接続、タスクの送信、インジケータによる実行の報告、Expert Advisor からのタスクのステータスの要求、インジケータの削除を行いました。松葉杖をついて、でもマルチスレッドで。

 
Roman:

そうですね、あの記事はとても良いですね。一つの解決策に対して、考えてみると、もしかしたらこの方法から他の何かを絞り出すことができるかもしれません。
私の問題の方向性が決まりました。ヒントをくれたアンドレイに感謝します。

一つの記事を読んだということは、良いことだと思います。

ローマン

スレッドではなく、EventLoopで制御されたColback関数によるノンブロッキングの呼び出しです。
これにより、1つのスレッドで非同期を実現する。

どうしてドキュメントで見つからなかったのですか?

読んでみてはいかがでしょうか?

 
Реter Konow:

次のようなことを常に無視していますね。

あなたと私ではタスクが違います。あなたは、ソフトウェアを書くには、ソフトウェア開発と実装そのものという2つの大きなステップがあることを考慮していません。

ソフトウェア開発には、既製のソリューションが必要であり、時間がかかる。開発中に、ソフトウェアが計画通りに機能しないことが判明した場合、それはゴミ箱行きとなる。そして、実装そのものは、特定のプラットフォームの能力に合わせた機械的な作業となります。


レテグ・コノウ

5.非同期やマルチスレッドを必要とするタスクはたくさんあります。MQLプログラムはまだこれらの課題に到達していませんが、これは努力してはいけないということではありません。

よし、では一緒に行ってみよう。

なぜ取引端末が 必要なのか、という問いに答える。

 
Koldun Zloy:

一つの記事を読んだということは、良いことだと思います。

どうしてドキュメントで見つからなかったのですか?

読んでみてはいかがでしょうか?

見つからないことを想像してください。
callbackとeventloopで検索しても、ドキュメントにそれらしいものは出てきません。
差し支えなければ、嫌味のない程度にリンクを貼ってください。

 
Igor Makanu:

1.あなたと私の仕事は違う。あなたは、ソフトウェアを書くには、ソフトウェア開発と実装という2つの大きな段階があることを考慮していない。

ソフトウエアの開発には既成のソリューションが必要で、これには時間がかかる。開発中に、ソフトウエアが計画通りに動作しないことが判明すれば、それは無駄になってしまう。そして、実装そのものは、特定のプラットフォームの能力に合わせた機械的な作業となります。


よし、では一緒に行きましょう。

2.取引端末に なぜ必要なのか、という問いに答える。

1.私は開発ばかりしています。ハード6年連続開発......なんだかよくわからない。))他のプログラムの文脈から引き裂かれた、あるいは他のいくつかのプログラムから抽象化された既製の外部ソリューションは、専門性の高いコードの構造への統合がうまくいかず、非常に面倒なことになると思うのです。この場合、独自のソリューションを開発するよりも労働投入量が多くなり、コードの最終的な品質も低くなってしまいます。開発の可能性は言うまでもありません。これが開発の現実です。しかし、これは我々の質問とは関係ない。実際、これと何の関係があるのでしょうか?

2.質問が間違っています。要は「なぜエンドユーザーがそれを必要とするのか」ということです。なぜなら、ユーザーは常に提供される機能に不足を感じているからです。そのため、興味を失わないように追加していく必要があるのです。可能性がなくなり、技術的な制約で新しいものを追加できない場合、ユーザーは終了します。ユーザーを端末に留める機会が必要であり、そのためにソフトウェアの配布が必要である。 したがって、配布できないプログラムは、どんな言語を使っていても、コミュニティにとっては無意味なのです。


実は、自分のニーズだけを見て、他のユーザーのニーズを考慮しないのです。この地域で商売をしない、したくない、市場で儲けようという動機だけを放送する。そして、ソフトを全く使わずにマーケットで儲けることができるのです。

 
Igor Makanu:

悪い例-必要ない!

すでに@Roffildは スレッドで「今日の世界では、プログラマーは特定のタスクに適したツールを選択するために、いくつかの言語を知っていなければ なりません。"

然うは斯くの如し

MQLでは、MQL用のパッケージの選択肢はなく、AlgLibのみです。Habraで見つけた例を考えてみると、私はC#やPythonをMQLに接続します - それだけです。

最近のプログラミング言語は、その機能ではなく、既成のフレームワークが面白いのです- MQLに新しいMQLパッケージが登場すれば、別のタスクや問題も出てくるでしょう

ZS: もう一度あなたの指に、あなたはクロスプラットフォーム言語であるPythonとJavaから発展した「修正のアイデア」にしがみついている、言語の移植性と柔軟性のための犠牲は、パフォーマンスの損失だった、今これらの言語は、パフォーマンスを向上させるさまざまな方法で囲まれるようになった、しかしC言語のような言語で開発者は常に最大のパフォーマンスを達成し、別のスレッドにタスクを分割する必要はありません(クライアント - サーバータスクは含まれません、問題は、データ交換速度とこれは別の特異性です)。

イゴール、君は時々矛盾しているね。
前回、mqlの計算速度はC++に匹敵すると書かれていましたが
なるほど、これは確かにそうで、多くの人が知っている。
しかし、その後にサードパーティのフレームワークを接続して、遅れている言語での計算をそのまま移植する例を挙げていますね。
そして、サードパーティーのパッケージ接続を提唱していますね。つまり、既成のフレームワークのためにスピードを犠牲にしているのですか?
こうして、Peterが書いているように、プログラムの移植性を完全に失ってしまうのです。
良い解決策とは言えません。個人で使う分にはそうですが、大量に使う分にはそうではありません。

 
Roman:

見つからないことを想像してください。
callbackとeventloopで検索しても、このようなものはドキュメントにはありません。
差し支えなければ、余計な皮肉は抜きにして、リンクを教えてください。

検索するんじゃなくて、全部読まないとダメなんです。きっと、そこにはあなたにとってたくさんの驚きがあるはずです。

リンクはないでしょう。

少なくとも自分で何かをしようとした人を、ここで何度も助けたことがある。

そして、何をしたのですか?

掲示板で口だけ見てるのか?

まあ、それは私が手伝ってるんですけどね。


 
MKLでは、マーケットベンダーのみがストリームを必要とする場合があります。それ以外の人には、すでにストリームがあります。複雑な処理が必要な場合- イベントをDLLに渡し、ストリームを生成してデタッチし、端末のストリームを解放すれば、永遠に処理できるようになります)。
ほとんどがスレッドに対応できないと言わざるを得ず、全ICLユーザーのうち100人、200人が必要とすることになる。MKLは、Marketで取引したい100人のプログラマーのために悩むでしょうか?