多くの人にとって興味深いトピック：MetaTrader 4とMQL4の新機能 - 大きな変更が控えています。 - ページ 9 12345678910111213141516...75 新しいコメント Vladislav Andruschenko 2013.07.25 12:45 #81 Urain:さて、市場に触れたところで、ひとつのテーマについてご意見を伺いたいのですが......。MQL5の哲学によれば、指標は数えるべきで、EAは取引すべきなのです。しかし、マーケットは、いわばオールインワンのレディメイドソリューションを販売しているのです。指標をリソースとしてEAに格納 するようにコンパイラを改良してはどうでしょうか。そうでなければ、インジケータのコードを、適切な環境のないExpert Advisorに転送しなければなりません。ここでも、"indicator from indicator "というスキームにより、Expert Advisorにコードを転送するのは全くのエポックメイキングとなる。私もそう思います。今のMarketにFILESというタブを追加して、セットや説明書などを入れられるようにすると便利だと思います。セットやインストラクションなどを保存できるFILESというタブを追加すると便利だと思います。 Rashid Umarov 2013.07.25 12:46 #82 Urain:コンパイラを改良して、EAに指標をリソースとして格納 できないか？そうでなければ、インジケータのコードを適切な環境のないExpert Advisorに移動させなければなりません。繰り返しになりますが、「インジケータからインジケータ」というスキームにより、Expert Advisorにコードを移動させることが全体的に叙事詩的になっています。2012年11月24日の MetaTrader 5 Client Terminal build 730を 参照してください。8.MQL5：EX5リソースにインジケーターを保存するためのサポートを追加しました。同時に、リソースにおける指標は、自分たちのリソースでは動かなくなる。 Vladislav Andruschenko 2013.07.25 12:47 #83 Rosh:2012年11月24 日付ニュースリリース「MetaTrader 5 Client Terminal build 730」をご覧ください。 mt4とはどういう意味ですか？ Mykola Demko 2013.07.25 12:53 #84 Laryx:これはまさに私がやっていることです。また、Expert Advisorにカスタムヒストリーを渡すクラスも作成しましたが、私のアイデアを完全に実現するには、Expert Advisorがターミナルの関数を直接使用するべきではありません。同じOrderSend()と言ってください。これは「ラッパー」を通してのみ動作するはずで、その役割は標準ライブラリが 素晴らしく果たすことができる。派生クラスを作成し、Expert Advisor に組み込むと、ヒストリカルデータで動作するようになります。 Expert Advisor がターミナル関数を直接使用する場合、ヒストリカルを使用することはできません。まあ、おそらく、私が非常に満足し、多くの類似点を見つけたMFCライブラリとの長い仕事のせいでしょう。標準ライブラリの開発者も、きっとMFCのことをよくご存じなのでしょう。標準ライブラリの主な利点は、OOP思想の優れたサポートであり、Expert Advisorにカスタムヒストリを渡すことで、何の変更もせずに正しく動作させることができます。標準ライブラリのどこが嫌いなのでしょうか？ただ、そんなデメリットはなく、私はSBをよく知っていますし、その知識があるからこそ、すべてが面倒で非効率的であることを理解できるのです。注文を送るのではなく、おじいさんにはおじいさん、カブにはカブで始めるのです。 しかし、（トレードによれば）最大の欠点は、実行のコントロールが全くできないことです。サーバーに注文を出すだけで、草を生やしておく。でも、センドは万能のように10通りに包むのですが、ケースは100通りになってしまったんです。イデオロギーについては、2世代以上の継承は間違いであり、それ以上は理解も柔軟性も失われる。ほとんどのクラスは（あなたの言うとおり）発明されたのではなく、MFCから再発明されただけですが、それは欠点ではなく、なぜ車輪の再発明をするのかです。でも、頼れないのが一番の欠点かな（笑)。SBのあるところとないところと両方書きました。それがないと、より速く、より透明になる。汎用性が高すぎて、カーブで伸び悩んでしまう。 Vasiliy Smirnov 2013.07.25 12:54 #85 例えばDelphiでは、プロジェクトという 概念があり、これは共同編集を意味する。そして、3つのタイプにプログラムの分割は、一般的に少し疑わしいです、なぜならコンパイラは、理論的には、プログラムが何をするかを自分自身で決定することができますが、それは力によってのみ指標の取引、およびEAのためにあなたが内部にコードを実装する必要があることを行くので、我々は唯一の開発者の心は今まで溶かすと、彼らはプロジェクトを作ることを許可するだろうことを期待することができます）。 削除済み 2013.07.25 12:55 #86 Vladon:を出向させた。例えば、マーケットプレイスでセットやインストラクションなどを保存するためのFILESタブを追加すると便利だと思うのですが。は、Discussionタブで可能ですが、やはり違います。+++ Mykola Demko 2013.07.25 12:57 #87 Rosh:2012年11月24 日付のMetaTrader 5 Client Terminal build 730を 参照してください。素晴らしい、どうしてこれを見逃したのだろう、あぁ......休日前のビルドだ。8.MQL5：EX5リソースにインジケーターを保存するためのサポートを追加しました。同時にリソースにおける指標も、自分たちのリソースでは動かなくなる。投稿の横断は、すでにできているということでしょうか？ Georgiy Merts 2013.07.25 13:17 #88 Urain:それこそがデメリットで、私はSBをよく知っていますし、その知識があるからこそ、すべてが面倒で非効率的であることを理解できるのです。包括的なご回答をありがとうございました。私は、あなたの発言に何ら断固たる異議を唱えるものではありません。ちょっと...しょけん注文を送るのではなく、おじいさんにはおじいさんの、カブにはカブの。 しかし、その分システムに柔軟性があり、EAにカスタムヒストリーやサーバーエミュレーションを送ることができるのです。もし、OrderSend() で直接注文が送られてきたら、この「おばあちゃんからおじいちゃんへ、おじいちゃんからおばあちゃんへ」を自分たちで書かなければならない......。どちらが良いかは不明ですが...。しかし、最大の欠点は（トレード社によれば）強制力のあるコントロールが全くないことです。サーバーに注文を「ぶつけて」、どうでもよくなってしまったら。でも、センドは万能のように10通りに包むのですが、ケースは100通りになってしまったんです。私はここで十分な経験を積んでいないので、理論的にしか説明できないかもしれません。私自身、リターンコードの解析を行っていますが、ほとんど経験がありません。SB自体の実行制御が十分でないことは同意する。イデオロギーについては、2世代以上の相続は間違いだと考えていますし、理解も柔軟性も失われます。そうですね、確かに、深すぎる継承は理解を深めるのに非常に不利です。しかし、柔軟性については......納得しがたいものがありますね。4～5世代継承のケースをいくつも持っていますが、特に問題はないようです。しかし、これは私の場合であって、他の人にとってはこの継承の深さが大きな障害になるのだろうと納得できる。ただ、一番のデメリットは、当てにならない、何か書いても作り直しになることだと思います :)はい、まったく同感です。SBのあるところとないところと両方書きました。SBで書いたが、SBなしでも速く、透明になった。汎用性が高すぎるから、曲がるときに不器用なんです。SBは、TCテンプレートを作成し、そこに入力、メンテナンス、出力を記述したオブジェクトクラスのみを接続することができる点が気に入りました。SBがなければそのような思想は、同じでも独自のSBを作ることになると思うのですが。より速く、より透明性の高い」ということについてですが、どのようなTSでも全体として扱わせる場合には、そのようなイデオロギーがあっても良いように思います。しかし、これはアルゴトレーディングの重大な誤りであると思われる。TSは、入力ジェネレータ、入力TP-SLの決定式、入力ロットの決定式、トレーリングコントローラなど、「キューブ」の集合としてのみ捉えるべき...。この思想は、私たちが「より速く、より透明性の高い」いくつかのTSバリエーションを持つだけであるところ、非常に迅速に何百もの異なるTSバリエーションを得ることを可能にします。 例えば、テンプレートなしで5種類のTSを書いたとして、6種類目を書くには、その5種類のシステムの一部を使ってでもやり直す必要がある。 テンプレートを書いたとして、その中に5種類のシステムを部分的にだけ入力し、結果として、最大5つの入力ジェネレータ、入力フィルタ、TP-SL決定式などを作成することになる。それらを組み合わせると、簡単に100のTSができ、その中から最も安定的で収益性の高いものを選ぶことができます。ですから、SBの遅さはまさに「諸刃の剣」であり、その適用・非適用は個々のケースで判断すべきものだと私は考えています。 Rashid Umarov 2013.07.25 13:33 #89 Urain:スーパー、どうして見逃したんだろう、あああああああああああああああああああああああああああああああああああああああああああああああああああ新年前のビルドです。あなたの投稿にある消し込みは、すでにできるということでしょうか？ 最新のビルドに関するニュースをご覧いただき、実際にお試しください。 Igor Konyashin 2013.07.25 13:34 #90 Urain:素晴らしい！どうして見逃したんだ！あ～お正月前のビルドだ。こちらでも話題になっていますねhttps://www.mql5.com/ru/forum/3409#comment_408123 Обсуждение статьи "Использование ресурсов в MQL5" www.mql5.com Программы на MQL5 позволяют не только автоматизировать рутинные вычисления, но и создавать полноценную графическую оболочку. 12345678910111213141516...75 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
さて、市場に触れたところで、ひとつのテーマについてご意見を伺いたいのですが......。
MQL5の哲学によれば、指標は数えるべきで、EAは取引すべきなのです。
しかし、マーケットは、いわばオールインワンのレディメイドソリューションを販売しているのです。
指標をリソースとしてEAに格納 するようにコンパイラを改良してはどうでしょうか。
そうでなければ、インジケータのコードを、適切な環境のないExpert Advisorに転送しなければなりません。ここでも、"indicator from indicator "というスキームにより、Expert Advisorにコードを転送するのは全くのエポックメイキングとなる。
私もそう思います。
今のMarketにFILESというタブを追加して、セットや説明書などを入れられるようにすると便利だと思います。
セットやインストラクションなどを保存できるFILESというタブを追加すると便利だと思います。
コンパイラを改良して、EAに指標をリソースとして格納 できないか？
そうでなければ、インジケータのコードを適切な環境のないExpert Advisorに移動させなければなりません。繰り返しになりますが、「インジケータからインジケータ」というスキームにより、Expert Advisorにコードを移動させることが全体的に叙事詩的になっています。
2012年11月24日の MetaTrader 5 Client Terminal build 730を 参照してください。
8.MQL5：EX5リソースにインジケーターを保存するためのサポートを追加しました。同時に、リソースにおける指標は、自分たちのリソースでは動かなくなる。
2012年11月24 日付ニュースリリース「MetaTrader 5 Client Terminal build 730」をご覧ください。
これはまさに私がやっていることです。また、Expert Advisorにカスタムヒストリーを渡すクラスも作成しましたが、私のアイデアを完全に実現するには、Expert Advisorがターミナルの関数を直接使用するべきではありません。同じOrderSend()と言ってください。これは「ラッパー」を通してのみ動作するはずで、その役割は標準ライブラリが 素晴らしく果たすことができる。派生クラスを作成し、Expert Advisor に組み込むと、ヒストリカルデータで動作するようになります。 Expert Advisor がターミナル関数を直接使用する場合、ヒストリカルを使用することはできません。
まあ、おそらく、私が非常に満足し、多くの類似点を見つけたMFCライブラリとの長い仕事のせいでしょう。標準ライブラリの開発者も、きっとMFCのことをよくご存じなのでしょう。
標準ライブラリの主な利点は、OOP思想の優れたサポートであり、Expert Advisorにカスタムヒストリを渡すことで、何の変更もせずに正しく動作させることができます。
標準ライブラリのどこが嫌いなのでしょうか？
ただ、そんなデメリットはなく、私はSBをよく知っていますし、その知識があるからこそ、すべてが面倒で非効率的であることを理解できるのです。
注文を送るのではなく、おじいさんにはおじいさん、カブにはカブで始めるのです。
しかし、（トレードによれば）最大の欠点は、実行のコントロールが全くできないことです。サーバーに注文を出すだけで、草を生やしておく。でも、センドは万能のように10通りに包むのですが、ケースは100通りになってしまったんです。
イデオロギーについては、2世代以上の継承は間違いであり、それ以上は理解も柔軟性も失われる。
ほとんどのクラスは（あなたの言うとおり）発明されたのではなく、MFCから再発明されただけですが、それは欠点ではなく、なぜ車輪の再発明をするのかです。
でも、頼れないのが一番の欠点かな（笑)。
SBのあるところとないところと両方書きました。それがないと、より速く、より透明になる。汎用性が高すぎて、カーブで伸び悩んでしまう。
例えばDelphiでは、プロジェクトという 概念があり、これは共同編集を意味する。そして、3つのタイプにプログラムの分割は、一般的に少し疑わしいです、なぜならコンパイラは、理論的には、プログラムが何をするかを自分自身で決定することができますが、それは力によってのみ指標の取引、およびEAのためにあなたが内部にコードを実装する必要があることを行くので、我々は唯一の開発者の心は今まで溶かすと、彼らはプロジェクトを作ることを許可するだろうことを期待することができます）。
を出向させた。
例えば、マーケットプレイスでセットやインストラクションなどを保存するためのFILESタブを追加すると便利だと思うのですが。
は、Discussionタブで可能ですが、やはり違います。
2012年11月24 日付のMetaTrader 5 Client Terminal build 730を 参照してください。
素晴らしい、どうしてこれを見逃したのだろう、あぁ......休日前のビルドだ。
投稿の横断は、すでにできているということでしょうか？
それこそがデメリットで、私はSBをよく知っていますし、その知識があるからこそ、すべてが面倒で非効率的であることを理解できるのです。
包括的なご回答をありがとうございました。私は、あなたの発言に何ら断固たる異議を唱えるものではありません。ちょっと...しょけん
注文を送るのではなく、おじいさんにはおじいさんの、カブにはカブの。
しかし、その分システムに柔軟性があり、EAにカスタムヒストリーやサーバーエミュレーションを送ることができるのです。もし、OrderSend() で直接注文が送られてきたら、この「おばあちゃんからおじいちゃんへ、おじいちゃんからおばあちゃんへ」を自分たちで書かなければならない......。どちらが良いかは不明ですが...。
しかし、最大の欠点は（トレード社によれば）強制力のあるコントロールが全くないことです。サーバーに注文を「ぶつけて」、どうでもよくなってしまったら。でも、センドは万能のように10通りに包むのですが、ケースは100通りになってしまったんです。
私はここで十分な経験を積んでいないので、理論的にしか説明できないかもしれません。私自身、リターンコードの解析を行っていますが、ほとんど経験がありません。SB自体の実行制御が十分でないことは同意する。
イデオロギーについては、2世代以上の相続は間違いだと考えていますし、理解も柔軟性も失われます。
そうですね、確かに、深すぎる継承は理解を深めるのに非常に不利です。しかし、柔軟性については......納得しがたいものがありますね。4～5世代継承のケースをいくつも持っていますが、特に問題はないようです。しかし、これは私の場合であって、他の人にとってはこの継承の深さが大きな障害になるのだろうと納得できる。
ただ、一番のデメリットは、当てにならない、何か書いても作り直しになることだと思います :)
はい、まったく同感です。
SBのあるところとないところと両方書きました。SBで書いたが、SBなしでも速く、透明になった。汎用性が高すぎるから、曲がるときに不器用なんです。
SBは、TCテンプレートを作成し、そこに入力、メンテナンス、出力を記述したオブジェクトクラスのみを接続することができる点が気に入りました。SBがなければそのような思想は、同じでも独自のSBを作ることになると思うのですが。
より速く、より透明性の高い」ということについてですが、どのようなTSでも全体として扱わせる場合には、そのようなイデオロギーがあっても良いように思います。しかし、これはアルゴトレーディングの重大な誤りであると思われる。TSは、入力ジェネレータ、入力TP-SLの決定式、入力ロットの決定式、トレーリングコントローラなど、「キューブ」の集合としてのみ捉えるべき...。この思想は、私たちが「より速く、より透明性の高い」いくつかのTSバリエーションを持つだけであるところ、非常に迅速に何百もの異なるTSバリエーションを得ることを可能にします。
例えば、テンプレートなしで5種類のTSを書いたとして、6種類目を書くには、その5種類のシステムの一部を使ってでもやり直す必要がある。 テンプレートを書いたとして、その中に5種類のシステムを部分的にだけ入力し、結果として、最大5つの入力ジェネレータ、入力フィルタ、TP-SL決定式などを作成することになる。それらを組み合わせると、簡単に100のTSができ、その中から最も安定的で収益性の高いものを選ぶことができます。
ですから、SBの遅さはまさに「諸刃の剣」であり、その適用・非適用は個々のケースで判断すべきものだと私は考えています。
スーパー、どうして見逃したんだろう、あああああああああああああああああああああああああああああああああああああああああああああああああああ新年前のビルドです。
あなたの投稿にある消し込みは、すでにできるということでしょうか？
素晴らしい！どうして見逃したんだ！あ～お正月前のビルドだ。
こちらでも話題になっていますねhttps://www.mql5.com/ru/forum/3409#comment_408123