私のアプローチコアはエンジンです。 - ページ 38

新しいコメント
 
Georgiy Merts:

さて、さて...頑張れ、ピーター。

劣化」についてはその通りですが、「ユーザーを引っ張る」ことについてはおこがましいと思います。

でも、どうぞ。プログラミングができる人がいるかもしれませんが、「ハンズオフ」をトレードしています。

思っているのですが、アメリカの有名な手動売買のプラットフォームがあるんです。プラットフォーム内のアクションを部分的に自動化する可能性もありますが、その方法を知っている必要があります。また、APIもあります。しかし、どれだけの人がそれを管理できるでしょうか。

手軽なセミ・オートマティックを書いて、クライアントに提供することができます。そして、彼らだけではありません。手動で取引するすべてのトレーダーは、アクションの部分的な自動化、テーブルからの市場の監視、およびダイアログウィンドウを 使用してプログラムとの対話が提供される場合があります。マーケットイベント時のメッセージ表示まあ、知らないこと、わからないことがあるかもしれませんが、理論的には？

 
Реter Konow:

一方、私たちは手軽なセミ・オートマティックを書いて、お客様に提供することができます。そして、彼らだけではありません。手動で取引しているすべてのトレーダーに、行動の部分的な自動化、テーブルからの市場の観察、ダイアログウィンドウを通じたプログラムとの対話を提供することができます。マーケットイベント時のメッセージ表示まあ、知らないこと、わからないことがあるかもしれませんが、理論的には？

それを知る方法はただひとつ。

最後に、せめて何か発表して ください。

理想的でない、ぬいぐるみなし（必要なら後で追加）にして、すぐに需要＋ユーザーからのフィードバックを見て、次にどういう方向で掘ればいいのかが明確になるはずです。

早くやればやるほど、時間の節約になる（というか、時間のロスが少なくなる...）。:(

私の時代なら、このようなアドバイスに多くを捧げたことでしょう :)

 
Georgiy Merts:

さて、さて...頑張れ、ピーター。

劣化」についてはその通りですが、「ユーザーを引っ張る」についてはおこがましいと思います。

でも、どうぞ。プログラミングはできるけど、"手を動かす "というトレードをする人がいるかもしれない。

ありえません。プログラミングができる人は、必ずMQL5でアシスタントを作り、1～2週間程度でMQL5の取引 操作を勉強することができます。

セミオートマチックロボットについては、数時間後にビデオを作成し、エキスパートアドバイザーとしてセミオートマチックモードで動作する最新の自動化ロボットがどのように見えるかをお見せする予定です。

そして、そのために複雑なパネルを発明する必要はなく、誰にでもわかりやすいようにごく簡単なものを作ってください。

 
Реter Konow:

今のユーザーはテスターのグラで劣化してるんだよ。彼らは少し複雑な方向に引っ張られ、自分の行動に責任を持つ必要があるのです。そうでなければ、アルゴトレーディングの完全な劣化。

アルゴトレーディングというニッチな分野には、これ以外の未来はないと思っています。正直なところ、私は...

悲痛な思いで手を挙げている姿が目に浮かぶようです ;)))

ペーチャ君は、本当にメシアの役が好きなんだね。
みんな劣化してる...世界はどうなるんだ...。あなたの使命は、あなたの運命は、退化した人類をアルゴトレーディングの明るい未来に導くことです。ここには、すでに診断結果があります。思いつくままに...

ペーチャ、ふざけるな。

 
mqlのためのguiは重要で必要です（メタ言語も必要かも）。しかし、もしそれがOOPなしで行われているとしたら、それはメソッドの問題ではなく、その作者の心のありようを物語っているのではないでしょうか。4日で38ページとは、かっこいいですね。どうやら、みんなこの状態が好きなようだ。
 
悲しい話だ、本当に...。
 

mql oopは個人的に好きでないところがあります。空のオブジェクトは16バイトを必要とします。さらにそのポインタは8バイト必要で、データを除いて1項目あたり合計24バイトです。 代わりにプロパティマトリックスを使えば、「空の」オブジェクトを6つのintで置き換えることができ、それぞれが文字列以外のほとんどのものを格納できます（時間や価格については99%のケースでintで十分です）。

また、dynamic_castによる型変換 操作は、スピードの面でも安くない。だから、トピックスターターの方法（もちろん見たことはないが、理論的には）は、OOPによるアナログよりも高速に動作し、メモリも少なくて済むかもしれない。

 

Ilya Malev:

だから、topikstarterの方法（もちろん見たことはないが、理論的には）は、OOPの類似品よりも速く動作し、より少ないメモリですむかもしれない のだ。

トピックスターターの「カーネル」は膨大なサイズの文字列の配列であり、そのようなアプローチの効率性について語ることは、理論的にも非現実的です。

 
Ilya Malev:

また、dynamic_castによる型変換 操作は、速度の面でも決して安くはない。だから、トピックスターターの方法（もちろん見たことはないが、理論的には）は、そのOOPアナログよりも速く動作し、より少ないメモリを占有する可能性があるのだ。

だから、巨大なグローバル配列に直接アクセスする方が、こうしたインターフェイスの工夫や型変換よりも高速であることを主張する人はいない。また、デザインパターンについても、例えばダブルディスパッチによるVisitorのように、そこには膨大なオーバーヘッドが存在すると考えることができます。

しかし、それを補って余りあるのが、サポートや改造の利便性です。残念ながら、あらゆる思考力を最大限にコンピュータに反映させることが、長い間プログラミング開発の主流でした。その結果、よく知られている和の公式を使わず、ループによって等差数列の和を計算するところまで到達した。その意味で、人が「劣化する」というのは、ピーターと同意見です。

しかし、残念ながら選択肢はありません。みんなと一緒に「デグレード」して、あまり早くしないようにするか、絶望的に遅れてしまうか、どちらかです。そして、あなたのプログラムが効果的でないことは、ほとんど重要ではありません。

オオカミから逃げるウサギは、実はオオカミとではなく、他のウサギと競争しているのです。彼は狼から一刻も早く逃げる必要はないのだ。狼から逃れるには、最後になるよりもずっと重要なのです。なぜなら、最後に逃げれば--食べられてしまうが、誰よりも早く逃げれば--必要以上のエネルギーを使うことになり、その分、もっと有用な方向に使うことができるからだ。

それは、さまざまなプログラミング技術も同様で......。アセンブラでプログラミングするのが最も効率的な方法ですが、あまりにも多くの労力を必要とするため、意味がありません。そのエネルギーは、たとえコードがそれほど効率的でないとしても、より生産的に使ったほうがよいのです。Peterのグローバルアクセス可能な配列も同じようなものです。アクセスするのは効率的ですが、どこに何があって、どうアクセスするかを覚えるのは手間がかかりすぎます。

 
Yury Kulikov:

トピックスターターの「コア」は、膨大なサイズの文字列の配列であり、そのようなアプローチの有効性を語ることは、理論的にも非現実的です。

本当に文字列の配列なのか、それとも言葉のあやなのか？データがmql（string）文字列で表現されている場合、本当にチャンスはないのか...。

ゲオルギー・メルツ

アクセスするのは効率的ですが、どこに何があって、どうアクセスするかを覚えておくのは大変です。

カーネル」が出来上がれば、そこに比較的小さな労力を費やして、「不器用な」プレゼンテーションや情報へのアクセスの問題をすべて解決する便利なインターフェイスを貼り付けることができます。これはたわいのない話ですが、私の理解では、TCは彼のコードを公開していませんし、それが自然界にあるかどうかは全くわかりません :) 。それとも投稿しているのでしょうか？正直なところ、38ページすべてを読み切ることはできませんでした。

また、「セミ・オートマチック」だけに限定した手法は、定義上、何の価値もありません。製品やフリーランスの市場において、局所的で限定されたニッチを占めるのに役立つが
1...313233343536373839404142434445...184
新しいコメント