記事"MQL4からMQL5への移植"についてのディスカッション - ページ 2

新しいコメント
 
興味深い記事だ。
 
Quantum:

材料がかなり大きいので、間違いが起こる可能性がある。

移植のトピック（より正確には、MQL4のメソッドでエミュレーター・クラスを書くというトピック）は別の記事で扱いました（完成することを期待しています）。 資料を読む過程で、私たちは著者にリファレンス・ブックの形で記事を書くよう依頼し、MQL4のすべての関数（トレーディングを除く-近日中に解決策の1つをご覧いただけるでしょう）をカバーし、MQL5でそれぞれの関数のアナローグを提供し、一般的に、MQL4のプログラムを書き直す人たちがすぐにアナローグを見つけられるようにすべてをまとめました。自由奔放な欲望について、考慮したセクションの数について言えば、私たちはすべての関数をカバーすることにこだわった（250以上になった）。

いくつかのセクションの機能の比較については、正確には比較ではなかった。たとえ同じであっても、アナログを与える必要があった。すべての関数について。だから、比較はしているようだが、たとえば数学の関数が同じであることは比較からわかる。ちなみに、推奨事項として、各セクションの冒頭でこのことに言及することは、おそらく何かと便利だろう。

この理由（エミュレータ関数のアーキテクチャ）のために、著者は実装の中でいくつかの明白でないもの（例えば、iLowest/iHighestのグローバルOpen[]...High[]...は、あらかじめグローバルに宣言され、OnInitでAsSeriesにされた）を持っていた。

テクニカル・インジケータの 操作に関しては、多くの疑問があるかもしれませんが、MQL4のようにテクニカル・インジケータを 操作するべきではありません。しかし、ターミナルがインジケータを即座に破棄しないため、著者の提案するアプローチも機能する。というわけで、微妙なところがたくさんある。

重要なのは、もしあなたが（提案された関数の構造に起因するものも含めて）間違いを見つけたら、あなたの変形を提案してください。

これが参考書であるならば、参考書であってほしい！

でなければ、魚や肉ではない


グローバル配列が中間計算に使われる理由！

関数の内部でそのような計算のためのスペースを確保することは可能です。

いくつかの関数では、それらはあなたのアタを修正します。

関数内でグローバル・バッファを変更するのはアタスだ！

まあ、私が書いている間にすでに修正されましたが、私はこのスタイルが記事全体にトレースされることを確信しています。

mcl4価格コンストラクトがこれらの配列にアクセスすると......。


次に、比較の6つのセクションがある！

mcl4へのmcl4関数

に対するmcl4関数は単なる比較である。


そしていきなり

関数の置換テーブル。

2セクション


そしてまた比較

3セクション


そして置換

関数

そしてまた...。

表の最初にμl4関数があり、次に2種類のセルがある。

をmcl5に書き換えたものが含まれている。

あるいは、2種類のセルがある。

ということは、これはμl4への移籍なのか、それとも参考書なのか。

一つのことは放っておいてほしい！


動かない状態になる欠陥もたくさんある。

というのも、μl5の配列にデータを格納する際の特殊性については、すでに多くのことを学んでいるからだ。

そして多くの関数では、配列のサイズを決定することが必要である、

また、インデックスの方向を決めなければならない関数もあります。

というのも、mcl4とmcl5の環境におけるデータ処理の違いからだ。

というのも、コンパイルはできるのだが、起動しないという感触がすでにあるからだ。


もちろん、このようなガイドがあれば非常に便利です。

記事には興味深い点がいくつかあります。

しかし、それは魚でも肉でもない。


mql5上の関数とその類似品だけを置き換えずに残しておく。

これは、mql4のインジケーターをmql5に完全に書き換えるのに役立つだろう。

すべてのドキュメントへの参照を含む！

このような粗雑な代用品はクソ食らえだ。


もちろん、このような厳しい批評は申し訳ないが、最も期待されているときにこのような生々しい記事を発表するのはどうかと思う。

もちろん、このような厳しい批判は申し訳ない。

そこから何が学べるというのか...。

明らかに異端である。


そして最後に、なぜ添付ファイルがないのか？

多くの機能が移されたのに、なぜ.mqhファイルがないのか？

すべての機能が集められた...特に250個...mqh4を転送するために1つずつコピーする....

また、作者が意図的に何かを隠そうとしていることを示唆している。


バシリー、ありがとう。

 
CoreWinTT:
...

というのも、すでにコンパイル中の匂いがするのだが、起動しないのだ。

...

確かに、エラーなしでコンパイルできる関数を書いたからといって、それを安全にコードに組み込めるとは限らない。最大の問題は、プログラムのロジックを翻訳することだ。これは詩を翻訳するようなもので、逐語的に翻訳しても韻を踏んでいない。だから関数を翻訳するだけでは不十分なのだ。ある言語から別の言語への変換作業は、見た目ほど単純ではない。

私は、インジケーター、スクリプト、エキスパート・アドバイザーをMQL5に転送 するためのシンプルで明確なメカニズムを備えたエミュレーターという形で解決策を考えている。私は現在それに取り組んでいます。

 
うん、クールなエミュールだね。）
 
CoreWinTT:

ガイドブックならガイドブックらしくしてくれ！！」！

フィッシュ＆チップスじゃないんだから。

....

Vasily、建設的な批評をありがとう。著者が希望を汲み取り、グローバル配列を使用しない自己充足的な関数のバリエーションを提供してくれることを期待している。

この記事は、MQL4とMQL5の関数の対応関係を提供する、リファレンスとなることを意図していました。

最小限の説明、多くの表、完全な使用例など、著者が何かを隠そうとしているような印象を受けるのは、おそらくこれが原因だろう。しかし、これはこのジャンルの特殊性である。

関数の扱いには多くの微妙な点があり、詳細については例とともに詳細に検討されるべきだが、これらは他の記事のテーマである。MQL4からの移行の話題は、この記事だけではまだまだ尽きない。興味深い資料がたくさん準備中で、近々公開される予定だ。
。

 
DC2008:

この実装は複雑すぎるし、正当化もできない。結局のところ、目標はMQL4関数を完全に放棄することなのだ。

その通りだ。重要なのは、システム・アーキテクチャのどのような変更によって、今どのような（他の）ツールを使うべきかを説明することである。この資料は参考書として提供されるのだから、その中のすべてのセルを「解決策」で埋めることが重要だ。アナログがなければ、別のアプローチがある。
 
marketeer:
その通りだ。ポイントは、システム・アーキテクチャのどのような変化によって、今どのような（他の）手段を使うべきかを説明することである。この資料は参考書の形で与えられているので、その中のすべてのセルを「解決策」で埋めることが重要である。アナログがなければ、別のアプローチがある。

少なくとも各指標の本を読むのは難しい。

私でも自慢できない。

 
marketeer:
...すべてのボックスを "解決策 "で埋めることが重要だ。アナログがないということは、別のアプローチがあるということだ。

第17項には「解決策」への言及が追加されている。

アナログなし」の特徴のどれに最初に注意を払うべきか、提案してください。変更してみる。

 

17番はいい。最初のターンについては、私が判断することではない。mql4をmql5に変換する人は、みんな自分のキューを持っている。見落としがないように、単純に上から順に、AccountFreeMarginCheck、AccountFreeMarginMode、ArrayCopyRates、ArrayDimensionなど（残り9つしかない）。

削除済み  
Quantum:

親愛なるバシリー！

コメントありがとうございます。第18節の機能が更新されました。現在のバージョンを確認してください。

作者は多くの作業を行っており、エラーがあるかもしれません。

TFMigrate(int tf)関数は、MQL5のタイムフレームの 正しい値を 代入するために必要です。例えば、MQL4ではPERIOD_H1定数の数値は60ですが、MQL5ではPERIOD_H1の数値は16385、つまりTFMigrate(60)=16385となります。

私の意見では、マイグレーション条件下でTFを扱うには2つの関数が必要である：

1.1.秒数をTFに変換する -ENUM_TIMEFRAMES SecondToPeriod (int Value)とする；

2.2.期間を秒に変換する -int PeriodToSecond(ENUM_TIMEFRAMES Value)とする。


これは、私のマイグレーション・モジュールの一番最初のところで成功しました（DLLオプションもあります）。


追記

MQL4への準拠を最大化するため、私は個人的にピリオドの非標準をすべて取り除きました。

123456789...13
新しいコメント