より少ないコード、より多くのアクション...EAを書く - ページ 2

新しいコメント
 
Maxim Kuznetsov:

は、基本的に手続き型であり、最も一般的です。潜在的なユーザー（初級プログラマー）は、このように書きます。

つまり、あなたのスタイルは、本質的にプロシージャルであるということです。つまり、内側も外側も手続き的であり、その結果生じるすべての問題を含んでいるのです。ユーザーレベルでは、原則的に実装の詳細を開示することはできません。そして、ユーザーレベルのコードで非常に特殊なことが起こっているのですね。

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

条件付きコンパイルマクロ、特定のMA関数実装の呼び出し、などなど。つまり、OOPでもFPでもなく、このようなマットな手続き型プログラミングです。そして、ケーキの上の桜のように：ea.Symbol、すなわち形式的に、それはまだOOPである。

 
Maxim Kuznetsov:

EAの根拠となるものを作ってみる（興味があればやってみる）。

その結果は、このスレッドで紹介されているすべてのものと同様に（ほとんどの人にとって）役に立たないものになるでしょう。

というのも、あなたはすぐに自分流に書こうとするからです。

 
Vasiliy Sokolov:

つまり、あなたの作風はプロシージャルであるということです。つまり、内部的にも外部的にも手続き的であり、それに付随するすべての問題を含んでいる。ユーザーレベルでは、原則的に実装の詳細を開示することはできません。そして、ユーザーレベルのコードで非常に特殊なことが起こっているのですね。

条件付きコンパイルマクロ、特定のMA関数実装の呼び出し、などなど。つまり、OOPでもFPでもなく、このようなマットな手続き型プログラミングです。そして、ea.Symbolは、つまり形式的にはまだOOPなのです。

ここでも、ユースケースは潜在的なユーザーの視点から想定して書かれています。

しかし、ユースケースそのものには手をつけずにライブラリを進めることができる程度のものです。

4と5の両方がフォーラムにあるので、条件付きコンパイルを使わなければなりません。

 
Maxim Kuznetsov:

ここでも、ユースケースは潜在的なユーザーの視点から書かれています。

言い換えると、iMA(...)のような特定のプラットフォームに依存する関数の呼び出しを挿入する手続き型の要件はどこにあるのでしょうか。

マキシム・クズネツォフ

しかし、ユースケースそのものに触れることなく、図書館に進むことができるほどの量である。

ユースケースは、プラットフォーム依存の関数の特定の呼び出しでいっぱいなのに、どうしたらいいのでしょう？

マキシム・クズネツォフ

フォーラムには4と5の両方があるので、条件付きコンパイルを使う必要があります。

では、ユーザーケースレベルの「ユニバーサルコード」は、プラットフォームに依存することもできないのでしょうか？

 
Maxim Kuznetsov:

...

ユーザーケースについて語るなら、第一の戒めは、このレベルでは具体的な実装をしない ことです。しかし、ユーザーケースのレベルでは、すでに1）プラットフォーム、2）端末のAPIに完全に依存しています。つまり、提案されている実装は、記載されているコンセプトと全く矛盾しているのです。

 
Vasiliy Sokolov:

ユーザーケースについて語るなら、第一の戒めは、このレベルでは具体的な実装をしない ことです。ユーザーケースのレベルでは、すでに1）プラットフォーム、2）端末APIに完全に依存しています。つまり、提案された実装は、記載されたコンセプトに完全に対応していないのです。

一般に、開発者はMQLで記述し、取引端末 MT4, MT5のAPI用 :-) ですから、API端末の利用が普通です。

ユースケースは、その地域の典型的なものを示す/行う必要があります。ただ数字を並べるだけでなく、ユーザーにとってわかりやすい目的、実現したい目的があること。Expert Advisorの最小限の可能な目的は取引です :-) 私が考える最もシンプルなExpert Advisorは、クロスオーバー平均で取引することです。ソース記事で全文が紹介されています。

ちなみに、効果はあります。今この瞬間も、取引関数のスタブやチェックマークを描く代わりに、データを書いたりデバッグしたりしています。粗削りではありますが、データのある部分が議論できるようになり次第、掲載します。

 
Maxim Kuznetsov:

一般的にMT4,MT5取引端末の MQLやAPIで書かれているので:-)、API端末を参照するのは普通だと思います。

ユースケースは、その分野の典型的なものを示す/行う必要があります。ただ数字を並べるだけでなく、ユーザーが理解しやすい目標、達成したい目標を持つことです。Expert Advisorの最小限の可能な目的は取引です :-) 私が考える最もシンプルなExpert Advisorは、クロスオーバーの平均値で取引することです。ソース記事に全文が掲載されています

そして、その方法によって今のところ、私は取引関数やティックの描画の代わりに、データの書き込み/デバッグを行っています :-)。できるだけ早くデータを持つ部分は、生ですが、議論のために準備される - 私はまた、それを投稿します。

ちゃんと書いてますね。しかし、ユーザーはそのような疑似コードの方がずっとよく理解できる。

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

もうひとつは、このような形（プロシージャル、注）で動作させるのは非常に難しいのですが、それでも可能であることです。これは、ユーザーレベルの指示をできるだけシンプルかつ抽象的にすることを目指すべきものです。しかし、あなたのコードでは、ユーザーは条件付きコンパイルマクロ、平均を計算するための特定の関数、その他単に彼が扱うことのできない技術的な詳細を指定しなければならないのです。

 
Vasiliy Sokolov:

言い換えると、手続き型スタイルでは、iMA(...)のようなプラットフォーム固有の関数呼び出しを挿入する必要がどこにあるのでしょうか。

プラットフォーム依存の関数呼び出しが多いユースケースは、いかにアンタッチャブルか？

では、ユーザーケースレベルの「ユニバーサルコード」は、プラットフォームに依存することもできないのでしょうか？

4/5プラットフォームはAPIが異なるので、たまたまそうなっただけです。

何でもかんでも別のレイヤーで互換性を持たせるとか、ユニバーサルなライブラリーを書くわけではありません。そうしたくないのは山々ですが :-)

は、EAの基礎に過ぎません。

 
Vasiliy Sokolov:

まあ、ちゃんと書いてますね。しかし、ユーザーはそのような疑似コードの方がずっとよく理解できる。

もうひとつは、この特殊な形（プロシージャルのことですね）で動作させるのはもっと難しいのですが、それでも可能だということです。これは、ユーザーレベルの指示をできるだけシンプルかつ抽象的にすることを目指すべきものです。しかし、あなたのコードでは、ユーザーは条件付きコンパイルマクロ、平均を計算するための特定の関数、その他単に彼が扱うことのできない技術的な詳細を指定する必要があります。

原理的には、GetData OnCrossSignalの内部で引用したようなエントリーを使用することができます。潜在的には、スクリプトを書くこともできます :-)しかし、すべては順調・・・。データの取り扱いは電子卓として構築されています。

 
Maxim Kuznetsov:

4/5プラットフォームはAPIが異なる、それは仕方ないこと。

私は、すべてのものに別の互換性レイヤーを書いたり、ユニバーサルなライブラリを書いたりしているわけではありません。そうしたくないのは山々ですが :-)

は、EAの基礎に過ぎません。

アルテムのコードを見て ください。彼のコードは、ターゲットプラットフォームに依存しない単一のAPIを持っています。だから、「そういう仕組みになっている」という論調は聞いていて違和感があるのです。

12345678910
新しいコメント