エラー、バグ、質問 - ページ 257 1...250251252253254255256257258259260261262263264...3185 新しいコメント 削除済み 2011.01.06 12:27 #2561 alexvd:そうは見えませんね。その結果、負けトレードは2回（45回中）だけで、いずれも買いであったことが判明した。もしかしたら、見る場所を間違えているのかも？赤色表示：ショートポジションは45件中5件。仮に40が95％だとしよう。質問 - なぜ5＝100％なのか、-5％とするのが論理的である。この場合、5（11.11％）と40（88.89％）であるべきだと思われるが。 alexvd:キャッシュのクリアをお試しください。別のオプション、別のブラウザで試したところ、追加に成功しました。アタシじゃなくて、コメントに直接画像を挿入 してるんでしょ？ はい、本文中にあります。このフォーラムには問題なく追加されましたが、試してみます...。:) Alexey Da 2011.01.06 12:39 #2562 Interesting:赤色表示：ショートポジションは45件中5件。40が95％だとしよう。疑問点 - なぜ5＝100％なのか、5％とするのが論理的である。とはいえ、5回（11.11％）と40回（88.89％）のトレードがあってもよさそうなものだが。合計45トレード。 販売時5個、購入時40個不採算2（買い取り2）、採算43（合計）。ここでは、次のような結果が得られています。売り案件-5件で、100％利益が出た（負けていない）（＝すべての案件で利益が出た）。買い取引 - 40、そのうちの38は利益を上げている、つまり38*100%/40=95%です。さらに収益性の高い取引 - 45件中43件、すなわち43*100%/45=95.56%。損失トレード - 45回中2回、つまり2*100%/45 = 4.44%。 削除済み 2011.01.06 12:50 #2563 alexvd:合計45トレード。 販売時5個、購入時40個負けトレード2回（買いトレード2回）、儲けトレード43回（合計）当社が保有する案件の総数売り案件 - 5件、そのうち勝ち（負け）案件 - 100％（つまり、すべて利益が出た）。買い取引 - 40、そのうちの38は利益を上げている、つまり38*100%/40=95%です。さらに収益性の高い取引 - 45件中43件、すなわち43*100%/45=95.56%。損失トレード - 45回中2回、すなわち2*100%/45=4.44%。 ありがとうございます。これで何が何だかわかりました...。 削除済み 2011.01.06 13:35 #2564 この効果は実感しています。インジケータをチャートに 追加すると（別ウィンドウで）、メインのローソク足チャートが更新されなくなります（価格がフリーズします）。一方のシンボルのウィンドウにのみインジケータが追加されていますが、もう一方のウィンドウでも価格がフリーズしてしまいます。インジケータの初期化と計算は本体内部で行っています： if(prev_calculated==0).前日から始まっていない終値が計算に含まれる（現在の終値は含まれない）。インジケーターの計算が完了すると、ウィンドウと同期して価格が動き出し、変化します。 写真で見ることができます。 Alexey Da 2011.01.06 14:29 #2565 -Alexey-:この効果は実感しています。インジケータをチャートに 追加すると（別ウィンドウで）、メインのローソク足チャートは更新が止まり（価格がフリーズ）、一方、気配値のウィンドウではすべて問題なく、価格は赤から緑に変化します。一方のシンボルのウィンドウにのみインジケータが追加されていますが、もう一方のウィンドウでも価格がフリーズしてしまいます。インジケータの初期化と計算は本体内部で行っています： if(prev_calculated==0).前日から始まっていない終値が計算に含まれる（現在の終値は含まれない）。インジケーターの計算が完了すると、ウィンドウと同期して価格が動き出し、変化します。 写真で見ることができます。最初の計算では、非常に多くのリソースを消費することが判明しました。もしかしたら、インジケーターのコードが最適な方法で書かれていないかもしれませんので、確認してみてください。 削除済み 2011.01.06 15:31 #2566 alexvd:最初の計算では、非常に多くのリソースを必要とすることが判明しました。インジケーターコードが最適な方法で書かれていないか確認する。 alexvd様、残念ながらIndicatorは現在20以上のクラスで3000行以上のコードがあり、コードの最適化が難しく（ループで数千億の演算処理）、この数はざっと10000まで増える可能性があるそうです。ローソク足チャートの気配値の更新を別のプログラムスレッドに、インジケータの計算の読み込みを別のスレッドに、なんとか分離できないかということです。正直なところ、仕事を始めた当初は、小型のノートパソコンも使いたいのに、デスクトップパソコンでこれほど緊急にパフォーマンスの問題が発生するとは思ってもいませんでした。 Anton 2011.01.06 16:22 #2567 -Alexey-: ローソク足チャートの気配値の更新を別のプログラムフローに、インジケーターの計算の 読み込みを別のフローに分離することが可能という意味です。 チャートの相場更新は、あくまで端末のベースデータを表示するものであり、その上で指標も計算されます。資源節約のため、端末のベースデータはインプットデータとしてインジケータに渡され、インジケータの計算が完了するまで変更できないようになっています。 削除済み 2011.01.06 16:43 #2568 antt: チャート上の気配値の更新は、端末のデータベースデータを表示するだけであり、指標の計算にも使用されます。資源節約のため、端末のベースデータは入力データとしてインジケータに渡される。つまり、インジケータが計算さ れるまでは変更できない。 了解です、ありがとうございます 削除済み 2011.01.06 17:49 #2569 -Alexey-: alexvd様 残念ながら現在Indicatorは約20以上のクラスからなる3000行以上のコードがあり、コードの最適化はかなり難しく（ループで数千億の演算処理）、この数はざっと10000まで増える可能性があるそうです。ローソク足チャートの気配値の更新を別プログラムスレッドに、インジケータの計算の読み込みを別スレッドに、なんとか分離できないかということです。正直なところ、仕事を始めた当初は、小型のノートパソコンも使いたいのに、デスクトップパソコンでここまでパフォーマンスの問題が深刻になるとは思ってもみなかったんです。オブジェクトや線の数は重要ではなく、インジケータを最適化するようにしてください。既存のインジケータ（3000行）を必要な速度で動作させることは可能だと思われます。興味深いのは、リソースを大量に消費する計算をすべてタイマーに入れ（可能であれば）、これらの計算を毎回のティックで実行しないようにすることである。そして、電卓の箱はできるだけ最適化したい（合理的な範囲で）。 削除済み 2011.01.06 18:19 #2570 Interesting:オブジェクトや線の数は重要ではなく、インジケータを最適化するようにしてください。既存のインジケータ（3000行）を必要な速度で動作させることは可能だと思われます。興味深いのは、リソースを大量に消費する計算を（可能であれば）すべてタイマーに入れると、これらの計算が毎ティック実行されなくなるという点です。そして、電卓ブロックは可能な限り（合理的な範囲内で）最適化する必要があります。原理的には、同じデータが異なるクラスのオブジェクトで計算されるため、作業を少し最適化することが可能です（つまり、一度だけではありません）。しかし、ここで我々は別の問題に直面して、すなわち - 多くのブラックボックスの概念から離れて、それぞれがデバッグすることができ、それに自信を持っている（すなわち、各オブジェクトは完全に自律ユニットであり、異なるオブジェクトで同一であるいくつかの中間データの計算は、オブジェクトの外に移動した場合、自律性が失われ、個別に各クラスをデバッグすることができます。この場合、プログラムの構造化が失われる。つまり、自分が書いたものが理解できなくなり、わずかなエラーも捕らえられなくなるのだ。また、アルゴリズムの一部だけでなく、全体を実行する必要があるので、デバッグのスピードも飛躍的に向上します。このように、オブジェクトの数が速度に影響するのです。ですから、同様の最適化は、インジケータが完全に作成され、デバッグされ、テストされる最終段階で試されるのではないかと思いますが、残念ながらまだ先の話です（ようやく気がついたので、4ヶ月ほど初期段階の作業をしています）。計量経済学や数学の本では、すべてが断片的に別の本に散らばっている（細部の資料が実質的に統一されていない）、用語やアルゴリズムに誤りや齟齬があり、初心者が百科事典を引いて初めて分かる、理論情報とその実用化の可能性、すなわち数値手法としての実現が衝突し、数値手法自体がソフトウェア環境の機能を要求する）、プロセスが長く退屈で粘っこい、などがあげられるでしょう。計算のロジック上、各ローソク足の形成後に発生しなければならないので、本来は関数「is new bar」の本体に配置するはずでしたが、その時間がこの間隔を超えることもあるということで、デバッグの段階で一度だけ発生するように関数 if(prev_calculated==0) の本体に配置することにしました。タイマーの提案、考えてみます。ありがとうございます。 Документация по MQL5: Основы языка / Функции www.mql5.com Основы языка / Функции - Документация по MQL5 1...250251252253254255256257258259260261262263264...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そうは見えませんね。
その結果、負けトレードは2回（45回中）だけで、いずれも買いであったことが判明した。
もしかしたら、見る場所を間違えているのかも？
赤色表示：ショートポジションは45件中5件。仮に40が95％だとしよう。質問 - なぜ5＝100％なのか、-5％とするのが論理的である。
この場合、5（11.11％）と40（88.89％）であるべきだと思われるが。
キャッシュのクリアをお試しください。別のオプション、別のブラウザで試したところ、追加に成功しました。
アタシじゃなくて、コメントに直接画像を挿入 してるんでしょ？
赤色表示：ショートポジションは45件中5件。40が95％だとしよう。疑問点 - なぜ5＝100％なのか、5％とするのが論理的である。
とはいえ、5回（11.11％）と40回（88.89％）のトレードがあってもよさそうなものだが。
合計45トレード。
ここでは、次のような結果が得られています。
売り案件-5件で、100％利益が出た（負けていない）（＝すべての案件で利益が出た）。
買い取引 - 40、そのうちの38は利益を上げている、つまり38*100%/40=95%です。
さらに
収益性の高い取引 - 45件中43件、すなわち43*100%/45=95.56%。
損失トレード - 45回中2回、つまり2*100%/45 = 4.44%。
合計45トレード。
当社が保有する案件の総数
売り案件 - 5件、そのうち勝ち（負け）案件 - 100％（つまり、すべて利益が出た）。
買い取引 - 40、そのうちの38は利益を上げている、つまり38*100%/40=95%です。
さらに
収益性の高い取引 - 45件中43件、すなわち43*100%/45=95.56%。
損失トレード - 45回中2回、すなわち2*100%/45=4.44%。
この効果は実感しています。インジケータをチャートに 追加すると（別ウィンドウで）、メインのローソク足チャートが更新されなくなります（価格がフリーズします）。一方のシンボルのウィンドウにのみインジケータが追加されていますが、もう一方のウィンドウでも価格がフリーズしてしまいます。インジケータの初期化と計算は本体内部で行っています： if(prev_calculated==0).前日から始まっていない終値が計算に含まれる（現在の終値は含まれない）。インジケーターの計算が完了すると、ウィンドウと同期して価格が動き出し、変化します。
写真で見ることができます。
この効果は実感しています。インジケータをチャートに 追加すると（別ウィンドウで）、メインのローソク足チャートは更新が止まり（価格がフリーズ）、一方、気配値のウィンドウではすべて問題なく、価格は赤から緑に変化します。一方のシンボルのウィンドウにのみインジケータが追加されていますが、もう一方のウィンドウでも価格がフリーズしてしまいます。インジケータの初期化と計算は本体内部で行っています： if(prev_calculated==0).前日から始まっていない終値が計算に含まれる（現在の終値は含まれない）。インジケーターの計算が完了すると、ウィンドウと同期して価格が動き出し、変化します。
写真で見ることができます。
最初の計算では、非常に多くのリソースを消費することが判明しました。もしかしたら、インジケーターのコードが最適な方法で書かれていないかもしれませんので、確認してみてください。
最初の計算では、非常に多くのリソースを必要とすることが判明しました。インジケーターコードが最適な方法で書かれていないか確認する。
ローソク足チャートの気配値の更新を別のプログラムフローに、インジケーターの計算の 読み込みを別のフローに分離することが可能という意味です。
チャート上の気配値の更新は、端末のデータベースデータを表示するだけであり、指標の計算にも使用されます。資源節約のため、端末のベースデータは入力データとしてインジケータに渡される。つまり、インジケータが計算さ れるまでは変更できない。
alexvd様 残念ながら現在Indicatorは約20以上のクラスからなる3000行以上のコードがあり、コードの最適化はかなり難しく（ループで数千億の演算処理）、この数はざっと10000まで増える可能性があるそうです。ローソク足チャートの気配値の更新を別プログラムスレッドに、インジケータの計算の読み込みを別スレッドに、なんとか分離できないかということです。正直なところ、仕事を始めた当初は、小型のノートパソコンも使いたいのに、デスクトップパソコンでここまでパフォーマンスの問題が深刻になるとは思ってもみなかったんです。
オブジェクトや線の数は重要ではなく、インジケータを最適化するようにしてください。既存のインジケータ（3000行）を必要な速度で動作させることは可能だと思われます。
興味深いのは、リソースを大量に消費する計算をすべてタイマーに入れ（可能であれば）、これらの計算を毎回のティックで実行しないようにすることである。
そして、電卓の箱はできるだけ最適化したい（合理的な範囲で）。
オブジェクトや線の数は重要ではなく、インジケータを最適化するようにしてください。既存のインジケータ（3000行）を必要な速度で動作させることは可能だと思われます。
興味深いのは、リソースを大量に消費する計算を（可能であれば）すべてタイマーに入れると、これらの計算が毎ティック実行されなくなるという点です。
そして、電卓ブロックは可能な限り（合理的な範囲内で）最適化する必要があります。
原理的には、同じデータが異なるクラスのオブジェクトで計算されるため、作業を少し最適化することが可能です（つまり、一度だけではありません）。しかし、ここで我々は別の問題に直面して、すなわち - 多くのブラックボックスの概念から離れて、それぞれがデバッグすることができ、それに自信を持っている（すなわち、各オブジェクトは完全に自律ユニットであり、異なるオブジェクトで同一であるいくつかの中間データの計算は、オブジェクトの外に移動した場合、自律性が失われ、個別に各クラスをデバッグすることができます。この場合、プログラムの構造化が失われる。つまり、自分が書いたものが理解できなくなり、わずかなエラーも捕らえられなくなるのだ。また、アルゴリズムの一部だけでなく、全体を実行する必要があるので、デバッグのスピードも飛躍的に向上します。このように、オブジェクトの数が速度に影響するのです。
ですから、同様の最適化は、インジケータが完全に作成され、デバッグされ、テストされる最終段階で試されるのではないかと思いますが、残念ながらまだ先の話です（ようやく気がついたので、4ヶ月ほど初期段階の作業をしています）。計量経済学や数学の本では、すべてが断片的に別の本に散らばっている（細部の資料が実質的に統一されていない）、用語やアルゴリズムに誤りや齟齬があり、初心者が百科事典を引いて初めて分かる、理論情報とその実用化の可能性、すなわち数値手法としての実現が衝突し、数値手法自体がソフトウェア環境の機能を要求する）、プロセスが長く退屈で粘っこい、などがあげられるでしょう。
計算のロジック上、各ローソク足の形成後に発生しなければならないので、本来は関数「is new bar」の本体に配置するはずでしたが、その時間がこの間隔を超えることもあるということで、デバッグの段階で一度だけ発生するように関数 if(prev_calculated==0) の本体に配置することにしました。タイマーの提案、考えてみます。ありがとうございます。