if( IsSignal(iCustom(NULL,0,"fsbIndicator1", SLOT_TYPE_LC, Param2, Param3,...,0,0))&& IsSignal(iCustom(NULL,0,"fsbIndicator2", SLOT_TYPE_LC, Param2, Param3,...,0,0))&& IsSignal(iCustom(NULL,0,"fsbIndicator3", SLOT_TYPE_LC, Param2, Param3,...,0,0))){// Открываем длинную позицию (предпоследний 0 в значениях индикаторов - указатель на буфер логики длинных позиций (1, соотв. - на буфер логики коротких))// Если у нас значение POP берется из еще одного индикатора, то это значение берется аналогично, только меняется логика поведения индикатора:// iCustom(NULL, 0, "fsbIndicator", SLOT_TYPE_POP, Param2, Param3, ..., 0, 0)}
2. protected static float fMicron = 0.000075f; // 2つの浮動小数点を比較するときに使用されるCoef
3.インジケータ・ベース・コンストラクタ。
4.基本価格。
6.NET <-> MTブリッジが動作するようになりました。MTでFSBを作るのは時間がかかる。もちろん、"rock solid "になるまでは、デモ口座 に限りますが。
Aroonのインジケータは、bIsDescreteValues = trueしか使っていないと思うので。
RSIについてですが、計算式が気になったのを覚えています。5~6年前の話です。人気のあるTAの本に載っていたこの数式を使ったのだと思います。どれかはよく覚えていない。
"前のバーの値を使用する"
個人的には、これがFSBの最も重要な 特徴のひとつだと思っています。
チャートウィンドウでF12キーを押すと、インジケータの値が完全な精度で表示されます。
もう一つの方法は、「コマンドコンソール」を使うことです。 ind xxxxは 、バー xxxxのインジケータを表示します。
MTの数式を深く掘り下げることはしない。おそらく、あまり大きな違いはないでしょう。ここでは、デフォルトのFSB RSIとMT RSIを紹介します。
___________________--
編集する。
この追加平滑化なしでRSIを計算してみました。
しかし、この場合、2009.3.24のRSI値は74.800に跳ね上がります。
----------------------
Stellarator様、良いお言葉をありがとうございます。
私はフォレックス・ストラテジー・ビルダーを見捨てません、あなたのような人がいるからというだけです。FSbをより強固でユーザーフレンドリーなものにするために、反対であっても私は議論を歓迎します。
その方向で、FSBでMTのインジケータを追加することができると思います。MT互換モード みたいなもの :)
mt_macd, mt_rsi, ...これらは、MT標準のものと同じパラメータであること。
バー・オープニングとバー・クロージングのエントリー/エグジット・ポイントを 解決しなければならない。FSB→MTの統合に不可欠なものです。
.................................それら(2つのバッファ)を1つにまとめる(と思ったが1/0(ビットマスク化できる)だけでなく、値札もあるかもしれない)。もっとも、インジケーターの値そのものをどうにかしないといけないのでしょうが......。今に見てろ...このままでは...
なんでうまくいかないんだろう(?)
長い間、私は異なるインジケータ・バッファから複数の値を取得するために単一のicustomコールを使用してきました。コード内でこの関数を何度も使用するのは無駄が多すぎます。実際、必要なのは(せいぜい)トレードの方向とSLとTPのレベルを得ることだけです・・・問題は単純な算数で解決されます。
以下は、バッファ(Signal)を1つだけ追加したインジケーターコードの断片です。
そして、Expert Advisorのコードでの逆変換は以下の通りです。
このように、1回のインジケータの呼び出しで3つの値(方向、TP、SL)を得ることができます。得られた結果は、さらに思い通りに操作することができます :)
その原理を理解してほしい。
皆さん、おはようございます。
Miroslav_Popov писал(а) >>
1.floatをdoubleに置き換えるために、インジケータを書き換えることができます。
ミロスラフ - これは重要です!私はすでに私の記事で理由のいくつかを述べています。しかし、その労力も十分承知しているのですが...。そして、今は(おそらく)求めているブリッジや実質的な何かに取り組んでいるということです。
しかし、時間は捻出しなければならない。私の予想では、何時間以内(1日以内)だと思います。なぜなら、変数を宣言するときに一方を他方に置き換えるだけでは済まないからです(少なくとも「美化のための」目視確認と目視修正も伴います(変数がタブで記述されている場合など)) : 。- はないものの)。
まず、意図的に(無理やり精度を落とすために)フロートを 使うケースは十分にあり得ます。ここにあるコード全体を見る必要があります。
第二に、このような(「新しい」)数字とFSBとの対応付けの問題がある(これについては、以下の2節で説明する)。
より短く - すべてのコードを慎重に実行し、少なくとも実数から倍数への移行に伴う欠点の可能性について考える必要があります。
Miroslav_Popov さんが書き込みました(a) >>。
2. protected static float fMicron = 0.000075f; // 2つの浮動小数点を比較するときに使用されるCoef
(以下同じ)。
チャートウィンドウでF12キーを押すと、インジケータの値を完全な精度で見ることができます。
そして、これが問題の1つです なぜ0.000075なのか?0.00005でもない?それとも0.000001?(私がそうであるように)。
拡張問題(興味のある方)と質問です。
ご存知のように、2つの実数が等しいかどうかの比較は、このような構文では決して行ってはならないのです。
これは、ある計算の結果(特に乗除算のバリエーション)、これらの変数の値が見た目には似ていても(例えば1.0と1.0)、実際には同じでない ことがあるためです。(実際には、1.000001と1.000000)。この性質は、コンピュータにおける実数の表現のある種の離散性と、計算のある種の(有限の)離散性(精度)に由来している。一般に、平等を求める比較は、古典的なテーマの変奏によって行われる(ちなみにミロスラフもこれを用いている)。
これは、2つの実数が等しいかどうかを、fMicronで定義されたある有限の精度で比較する「古典的」なものです。
そして、ここに潜在的な問題のひとつがある。このまさにfMicronの価値を、誰が、どのようなケースで、どのように判断すべきなのか。ミロスラフのように常に良い定数なのでしょうか(どの値かという問題もまだ議論中です)。
一般的に、陰謀を加えるためでなければ、私は次の説に賛成です。
1.一般に、このような変数の比較には、等質と 不等質の 2種類がある(<、>)。
2.変数自体には、一定の精度が保証されて いる変数(価格やロットなど)と、明確な精度を持たない 抽象的な値(指標値など)が あります。
不等号の場合、(どんなタイプの)変数も(一般的には)「頭から」比較される(if (Value1 < Value2) { ...})。精度を制限する必要がある場合(かなり稀ですが)、ミロスラフのような構造を使用することができます。
4.ただし、等質性については、対象データによって(通常は)異なるアプローチがとられる。
4.1 固定精度で2つの数値を比較する必要がある場合(たとえば、注文を修正するかどうか(「No Result」にならないように)を決めるための2つの価格値)、通常はその方法で行います(「classic」でも同様です)。
私たちの場合、この関数は冗長ですが、それは問題ではありません。その中で重要な構成要素は「Point / 2.0」です。 必要な、正しい、十分な計算精度を与えてくれるのは、このfMicronなのです...。というわけで、今回は 2つの価格を比較する場合(同じ桁数で、結果としてPointも 同じ )、例えば(Point = 0.0001)の場合
fMicron = 0.00005
で、1.2345(注文価格)と1.23451(指標値)を比較すると等しくなり、1.2345と1.23456を比較すると不等式になります...。最後にfMicron = 0.000075の場合、どうなると思いますか?;)もちろん、ある(より低い)精度であらかじめ変数を正規化することもできます。でも、それは私たちの方法ではないんです :D...
繰り返しになりますが、このパラメータの選択は重要であり、それぞれのケースで「少し独特」なのです :)1
私は、次のようなパラダイムを提案 します。
1.固定精度の変数は計算されたfMicron値と比較されます(Point / 2、例えば価格ケースの場合)
2.インジケータの値やその他の「限りなく正確な些細なこと」 :) は、使用する測定器のPointの最小値を10で割ったfMicron定数と比較されます。例えば,Digits が 4 を超えない計器の場合,fMicron = 0.00001,Digits = 5 の場合,fMicron = 0.000001 となり,同様である。
Miroslav - 専門家の意見が必要 :)?
では、一般の方に質問です。
各種DataWindow(MTまたはFSB(Indicator Charts))でWHY。- インジケーター値は常に一定の精度(Digits = 4)で表示されるのですか?なぜ小数点以下3桁ではないのか?あるいは5、6、7、......?:)?!いや、本当に?
ミロスラフには "隠し味 "があったのか(笑))- つまり、F12!また、MTでは何を押せばいいのでしょうか?
そして、一般的には、まあ、この定数を誰が定義したのか?(小数点以下4桁)。
私の推測では、ほとんどの商品で、受信クォートの次元(1.2345)にほぼ直接関連している(誰かがちょうどそれを記入した)。しかし、多くの証券会社がより大きな値(例えば5)にパスすることは周知の事実である。そこで、計測器の気配値次元(Digits)と一致する次元で指標値を表示するのはどうでしょうか。
あるいは、私はこのテーマで原則的に何かを「理解」していないのかもしれません(お願い - 誰か説明してください、多分それは「必要」だから...)!
Miroslav_Popov さんが書き込みました(a) >>。
3.インジケータ・ベース・コンストラクタ。
4.基本価格。
Miroslavさん、ソースページのコードはよく 理解できました :).protectedstatic float[] Price( BasePrice price) が何をするのか、 よく 理解できました。 もしこれが私のコードの扱いにくさのヒントであるなら - 私は意図的にストレージに追加のバッファを使用することを拒否したと答えます(一般的な場合 - 価格バッファのコピーまたはそれらの計算コピー(典型的な、など)のいずれか)。そして、スペースが節約され、様々なTypicalsがあるところでは、常に計算する必要があるのです。
ここで、FSBとMTの指標値算出のアプローチの決定的な違いに 言及する必要がある。
1.まず、少なくとも現時点では - FSBにロードされた相場は静的であり、それは一度それらをロードし、バーの全範囲のために必要な指標の値をONE時間を計算し、その後、単に取引ロボットの動作をエミュレートし、それらによって "ドライブ "しています。もう一度言いますが、指標値は取引ロボットの仮想化を実行する前に、一度だけ 計算されます。特に、売買取引のエミュレーションの速さを説明します。しかし、MTの相場は常にやってくるし、ネイティブのストラテジーテスターは未来が見えない、つまり、毎回インジケーターの値を計算しなければならない。そして、ミロシュラフさんの考え方(全バッファ計算)を単純に適用すると・・・。腐った卵を投げつけられる :)。したがって、IndicatorCounted()の使用には特別な注意が必要です!指標は、それぞれのケースでほぼ最大限の速度で計算されます(すべてのバーをカウントする必要がある場合、または1つだけカウントする場合)。どこかで、まだ最適化できるものもありますが、気の向くままに......。
2.そのため、毎回(新しいティックが来たとき)、追加のバッファに価格値を生成することは冗長である。どうせ全部計算しないといけないんだから、関数(同じMovingAverageなど)に自分でやらせればいい。スペースの節約、ロジックの簡素化(どのバーがこれらのバッファで再計算されるべきかを毎回分析する必要がない)、速度の節約(一般的なケースでは、さらにどこか高くなる)です。"私にはそう見える"(c)くまのプーさん
私のインジケータ変換について改めて議論するならば、おそらく重要なのは、関数(およびインジケータ自体)のロジックを完全に保持しつつ、MTの特定のユースケースに合わせて若干修正することです。また、インジケータ自体を制御するためのパラメータの順番や名前も保存しています。
みんな、ソースコードを見てくれよ。いいね!」をするようにしました :) 。
私の変換の最終的な考え方は次の通りです。例えば、ポジションのOpening Pointと、追加ロジックのための3つのインジケータを用意します。発注のためのコードはこんな感じになります(まあ、もちろん大雑把ですが)。
こんな感じ。iCustomにパラメータ値を入力し、それらがすべてシグナルを出すまで待ちます。以上です。指標値そのものの分析がない...。何のために?
いい感じ...かどうか?)
指標について
について(AroonとbIsDescreteValues = true;)が考慮されている。
RSIについて...
Miroslav - あなたが探している構造は、あなたを混乱させました :) 。もう一度コメントをつけて、CORRECTLY WORKED インジケータを使って「一致する」値を得ることを怠らないでください :) 。思い出してください - RSIの古典的な計算式は、MA(特に平滑化)の指数 変化をベースにしています。そこで、このスムージングモード(smoothed)をインジケータパラメータで指定 すると...。と、"嬉しい驚き "を感じていただけるはずです :)(デフォルトでは、Simpleが使用されているため、クラシックとの齟齬が生じることを覚えておいてください)!上記の手順は自分ではできないのですが......100%間違いないです。Convince me :)?
テストの結果、RSIを使用するすべてのインディケータ(およびRSI自体)において、必要なコードを削除し、SmoothedのmaMethodパラメータのデフォルト値を作成 することを次のように提案 します。デフォルトでは、ユーザーがそのような質問をすることはないだろうと。しかし、そうすることで、指標でこのパラメータを選択することが可能になるのです。(例えば、私はRSIの計算の結果に基づいて、また、RSI自体の現在の動作と、RSI MA Oscillatorを変換している - それは適切なパラメータで指定されているかは問題ではありません)。
"前のバーの値を使用する"
個人的には、これがFSBの最も重要な特徴のひとつだと思っています。
OH、YES!
これはまさにFSBの大きな特徴の一つです。また、この機能を考慮して、インジケーターのロジックが正しいかどうかをテストすることにも、きちんと気を配るようにしました。
デフォルト」値の計算を表示するコードをありがとうございますそれを考慮に入れて...
うまくいかない理由(?)
長い間、私は異なる指標バッファから複数の値を取得するために単一のicustomコールを使用してきました。コード内でこの関数を何度も使用するのは無駄が多すぎます。特に最適化中、そして「重い」指標でさえ。実際、必要なのは(せいぜい)売買の方向とSLとTPだけである...問題は単純な算数で解決される。
...
原理は、はっきりしているかと思います。
(意図的に粗く表現しています)また、複数の値を1つのパラメータにまとめる際の問題点についても知っています。)また、引用したコードをありがとうございました(簡単な質問ですが、元の値と「その後拡張」した値に違いがあったことはありますか?すべて同じ倍率ですが...)。
重要なのは...は、この特定のケースで必要なのでしょうか?
理由は2つあると思われます。
1.1...追加バッファ利用の目的(私にとって重要です) - インジケータはそれほど多く持っていません。今のところBUTで十分です(もう石墨を使う必要があるようです-そうすれば全てが明らかになります :)))
2.そのコードからインジケータを呼び出す速度(あなたの例)。私の答えは、「本質的ではない」です。すべての責任をもって宣言します。モチベーションを高める。
新しいティックごとに - とにかくインジケータを調べなければならない(have to)でしょう。そうだろ?(例えば - 値段を取るためとか) 毎回でなくとも、必要な時に。主なヒントは、おそらく、EAの1回の繰り返し内でiCustomを複数回呼び出すと、インジケータの再計算が複数回行われることでしょうか。説得を余儀なくされる!ポイントは「Expert Advisorの繰り返し回数が1回まで」という点です。つまり、この範囲内では、インジケータは1回(最初の呼び出し時)しか計算されないということです100%の自信をもって宣言します。その後のすべての呼び出しは、それをまったく開始()せず、必要なバッファから必要な値を取るだけである。入力パラメータが変更されない場合(バッファとオフセットを除く)は100%である。このルールは、1つのツールの範囲内で計算する場合に有効である。しかし、iCustomが他のTFやツールを参照する場合でも、その原理は成り立つと思います。
とにかく、今晩イシモクを見て、ロジックに2つのバッファを使うかどうか、はっきり決めたいと思います...。または1つ :)
とにかく、今夜またお会いしましょう(仕事に行きました)。
問題点について
考えておくよ。
しかし、おそらく(このトピックに関するMTからのシグナルがないことから)、上記のコード(前ページのテンプレート)は多かれ少なかれ最適です(少し微調整が必要かもしれませんが...)。夜には問題を "深化 "させてみる)