MQL5言語をゼロから独学で学ぶ - ページ 48 1...414243444546474849505152535455...84 新しいコメント Реter Konow 2020.10.11 08:05 #471 もし当面の目的が単純なトレーリングストップの実装であれば、forとwhileループを追加してスクリプトを書き続ける必要があります。忍耐力十分」のスクリプトは、論理的な拡張性があるとは思えませんね。持つことが必要な新しいアイデアに移行した方が良いのでしょう。1.if-elseの条件ツリー。2.計算機能。3.サイクルです。アルゴリズム取引の分野で仕事をすることになるので、スクリプトは取引戦略に関連したものであれば、より便利です。考えてみてください。 Реter Konow 2020.10.11 08:14 #472 ループの理解を深めるためにループは、その本体で閉じたコードの一部を何度も何度も渡すことができます。各パスで変数/呼び出される関数の値が異なる可能性があるため、各パスの結果は他のパスの結果と異なることになります。ループの反復回数は、プログラマが設定する変数や関数の値 - 特定のコードに依存します。 Aleksey Masterov 2020.10.11 08:15 #473 MrBrooklin:アレクセイ、冗談だろう?そうですね、まずは基本をしっかり学びたいと思いますウラジミールさん、謹んで申し上げます。あまりないですね。力学とあなたのベース、理論と実践から判断して、最初から最後まであなたのプロフィールです。では、なぜ...今じゃなくて、後で...。コツを掴んで、コードとファーストネームで会話できるようになったら MrBrooklin 2020.10.11 08:15 #474 Реter Konow: もし、直近の目的が単純なトレーリングストップの実装であれば、forとwhileループを追加してスクリプトを書き続けてください。 忍耐力十分」のスクリプトは、論理的な拡張性があるとは思えませんね。持つことが必要な新しいアイデアに移行した方が良いのでしょう。 1.if-elseの条件ツリー。 2.計算機能。 3.サイクルです。 アルゴリズム取引の分野で仕事をすることになるので、スクリプトは取引戦略に関連したものであれば、より便利です。考えてみてください。 Peterさん、New7.mq5スクリプトにトレーリングストップを装備するという私の意図をサポートしていただき、特にサイクルを勉強し始めた今、ありがとうございます。ちなみに、スクリプトのSleep 機能はすでに試しています。トレーリングストップを書くときは、この機能を使うことが推奨されました。何から始めればいいのか?おそらく、まずトレーリングストップのアルゴリズム 全体を言葉で説明し、それからコードを書いていく方が良いのではないでしょうか? 敬具 ウラジミール MrBrooklin 2020.10.11 08:17 #475 Aleksey Masterov: あまりないですね。力学とあなたのベースと理論と実践から判断すると、これは最初から最後まであなたのプロフィールです。では、なぜ...後略コツをつかんでファーストネームになったら、 。 アレクセイ、私を信じてくれてありがとう。あとは、ポンプを使わないことです 敬具 ウラジミール Реter Konow 2020.10.11 08:34 #476 MrBrooklin:Peterさん、New7.mq5スクリプトにトレーリングストップを装備したい、特にサイクルの勉強を始めた今、私の思いをサポートしてくれてありがとうございました。ちなみに、スクリプトのSleep 機能はすでに試しています。トレーリングストップを書くときは、この機能を使うことが推奨されました。何から始めればいいのか?おそらく、まずトレーリングストップのアルゴリズム 全体を言葉で説明し、それからコードを書いていく方が良いのではないでしょうか?敬具 ウラジミール 客観的に見れば、単純なトレーリングストップはスクリプトに書けないのです。トレーリングストップはそれ自体では存在せず、オープンポジションと「結びついて」おり、そのオープンポジションはストラテジーと「結びついて」おり、ストラテジーはEAにのみ実装されているのです。スクリプトでのトレーリングの問題点と複雑さは、ループ内でオープンポジションとその注文に関する情報を収集し、必要なシンボルで必要な注文を選択し、その修正を計算する必要があるという事実にあります。複雑で分かりにくいですが、EAならすべてが簡単です。第一に、どの順番で修正すればいいのかが既に分かっていること、第二に、OnTickイベントが来るので、いつ修正すればいいのかが分かることです。つまり、スクリプトに「注文待ち」を入れておけば、それがトリガーとなってポジションが建ち、ストップをトレールすることができる......というわけです。そのために必要なもの1.スクリプトをループさせるため。2.価格変動イベント固定の機能を文字記号に書き込む。3.ストップオーダーの変更機能の書き込み。4.ポジションクローズ時にスクリプトのアンロード(ループレスサイクルからの抜け出し)の条件を書き込む。脚本のアウトラインはおおよそスケッチしましたが、もっと真剣に考える必要がありそうです。追伸:スリープ機能は、必要なときにコードの実行を遅延させるために使用します。例えば、サーバーへのリクエスト時やイベント待ちの時などです。末尾のスクリプトでは、この関数は必ず必要になります。 Vladimir Simakov 2020.10.11 08:47 #477 Реter Konow: グローバル変数の値を変更するとエラーが発生するため、プログラマはグローバル変数の使用を恐れています。そのため、各機能によってエラーが変わる可能性があり、エラーの特定が困難な状況が生まれます。もちろん、グローバルスコープに存在するのは、すべてのプログラム関数が参照しなければならない変数だけでなければなりません。そうでなければならないのです。 私は、グローバル変数を使うのが好きです。なぜなら、グローバル変数は、機能を急速に成長させ、プログラムが巨大で活発な建設現場と化すからです。コードの書き方でよく批判されるのですが、だから建設現場なんです。基本的な建築作業が終わってから片付け、家が建ったらタイルを貼ったり、塗装したり、掃除に取りかかったりする。それまでは、型枠を組み立ててコンクリートを流し込むことが最優先です)。 しかし、プログラマーの考え方は違う。彼らは、たとえ2.5行であっても、コードを「きれいに」「こすり」ます。二行半のコードであってもスクラップしてくれますが、新品のコインのように輝きます(笑)。このようなコードに対する姿勢は、彼らが生きている職業上、正当化されるのですが、クリエイティブな観点からは、硬直的で稚拙なものです。そういうことなんだ...。 アドバイスとしては、きちんとした文章を書くことを学びつつ、時にはルールから離れ、より多様な経験を積むために実験することを許容することです。勉強になるし、覚えも早くなる。 一度松葉杖をつき始めるとなかなかやめられず、結果的にプロジェクトのコードがドレ...コードと呼ばれるものに変わってしまうという観察があります。 説明しよう。 あなたは、中間的な動作のソリューションを持つプロジェクトを持っており、実装された機能の数はカウント=0です。 私たちの課題は、「++count」機能の実装です。 必要な機能を追加するために オブジェクトツリーのメソッドを書き、それらをすべてイベントハンドラにロジックで接続する(推定時間3時間 *count; count=0)。 グローバル変数の 形で松葉杖を書き、それをいくつかのメソッドで必要なところに使う(推定時間15分 *count.) オートナンバリングのバグ (これはメタクォートに関するバグレポートです)。 当然、松葉杖を選んでいます(この場合、自分たちを働かせるのは本当に大変なんです) if (we did it) goto 2 を叫んで、そんなことをするのは間違っているという愉快なコメントを読んで、すべてが地獄に落ちるのです。 実装された機能のカウンターは、次の機能を実装するまでの時間を増加させますが、正しく実装されるとゼロにリセットされるという事実に注目されましたか? これは非常に大げさな考えですが、現実にはそういうものなのです。 どういうことかというと、すべての機能を実装した後にプロジェクトを書き直さなければ、読めないネタバレのまま製品化されてしまうということです。そして、どんなプロジェクトでも、そのライフサイクルは、経営者にとって頭痛の種となる。紡がれたものすべてのグローバル・リファクタリングにチーム全体を投入するか(競合他社は眠らず、彼ら、悪人たちは新しい機能を書く)、松葉杖を書き続け、激流で漏れるバグにパッチを当て続けるか、だ。 MrBrooklin 2020.10.11 08:59 #478 Реter Konow: 客観的に見れば、単純なトレーリングストップはスクリプトでは機能しない。トレーリングストップはそれ自体では存在せず、オープンポジションに「拘束」され、ストラテジーに「拘束」され、ストラテジーはExpert Advisorの中でのみ実装されます。 スクリプトにトレーリングを実装することの問題点と複雑さは、ループ内でオープンポジションとその注文に関する情報を収集し、正しいシンボルでの正しい注文を選択し、それを修正する方法を計算する必要がある点です。複雑で分かりにくいですが、EAならすべてが簡単です。第一に、どの順番で修正すればいいのかが既に分かっていること、第二に、OnTickイベントが来るので、いつ修正すればいいのかが分かることです。 つまり、スクリプトに「注文待ち」を入れておけば、それがトリガーとなってポジションが建ち、ストップをトレールすることができる...というわけだ。そのために必要なもの 1.スクリプトをループさせるため。 2.シンボルに対する価格変動イベントの固定化機能。 3.ストップオーダー変更時の書き込み機能。 4.ポジションクローズ時にスクリプトをアンロード(ループから抜ける)する条件を書いてください。 脚本のアウトラインはおおよそスケッチしましたが、もっと真剣に考える必要がありそうです。 追伸:スリープ機能は、必要なときにコードの実行を遅延させるために使用します。例えば、サーバーへのリクエスト時やイベント待ちの時などです。末尾のスクリプトでは、この関数は必ず必要になります。 Peterさん、スクリプトの中に末尾のコードを作成するのでしょうか?完璧だ!あとは、基本的な部分として挙げていただいたものを、言葉で説明し始めると、後で関数やループなどをどう書けばいいのかが明確になりますね。これでよいのでしょうか? ウラジミールさん、ありがとうございます。 Реter Konow 2020.10.11 09:06 #479 MrBrooklin:Peter では、スクリプトで末尾のコードを作成するのですね。素晴らしいこのように、リストアップされたものを基本セクションとして、関数やループなどの書き方を明確にするために、言葉で説明するようになりました。これでよいのでしょうか?ウラジミールさん、ありがとうございます。 はい、正解です。 MrBrooklin 2020.10.11 09:07 #480 Vladimir Simakov:一度カリカリし始めるとなかなか止まらないという観測があり、結果としてプロジェクトコードはいわゆるD.C.と呼ばれるものに変化していく。説明しよう。 あなたは、中間的な動作のソリューションを持つプロジェクトを持っており、実装された機能の数はカウント=0です。 私たちの課題は、「++count」機能の実装です。 必要な機能を追加するために オブジェクトツリーのメソッドを書き、イベントハンドラでロジックにつなげる(想定時間3時間 *count; count=0). グローバル変数の 形で松葉杖を書き、それをいくつかのメソッドで必要なところに使う(推定時間15分 *count.) オートナンバリングのバグ (これはメタクォートに関するバグレポートです)。 当然、松葉杖を選んでいます(この場合、自分たちを働かせるのは本当に大変なんです) if (we did it) goto 2 を叫んで、そんなことをするのは間違っているという愉快なコメントを読んで、すべてが地獄に落ちるのです。 実装された機能のカウンターは、次の機能を実装するまでの時間を増加させますが、正しく実装されるとゼロにリセットされるという事実に注目されましたか? これは非常に大げさな話ですが、現実にはそういうものなのです。 どういうことかというと、すべての機能を実装した後にプロジェクトを書き直さなければ、読めないネタバレのまま製品化されてしまうということです。そして、どんなプロジェクトのライフサイクルも、経営陣にとっては頭痛の種となる。チーム全体を、自分たちが紡いできたものすべてのグローバル・リファクタリングに投入するか(競合他社は目を覚まし、彼ら、悪人たちは新機能を書いている)、松葉杖を書き続け、激流で漏れるバグにパッチを当て続けるかだ。 このメッセージは主にピーターに宛てたものですが、皆さんのメッセージを十分に理解するために、スラングは一切使わず、ゼロからの初心者向けのテーマなので、プログラミングスクールの1年生が理解できる言葉で書いてくださいますようお願いします。 ウラジミールさん、ありがとうございます。 1...414243444546474849505152535455...84 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
アレクセイ、冗談だろう?そうですね、まずは基本をしっかり学びたいと思います
ウラジミールさん、謹んで申し上げます。
もし、直近の目的が単純なトレーリングストップの実装であれば、forとwhileループを追加してスクリプトを書き続けてください。
Peterさん、New7.mq5スクリプトにトレーリングストップを装備するという私の意図をサポートしていただき、特にサイクルを勉強し始めた今、ありがとうございます。ちなみに、スクリプトのSleep 機能はすでに試しています。トレーリングストップを書くときは、この機能を使うことが推奨されました。何から始めればいいのか?おそらく、まずトレーリングストップのアルゴリズム 全体を言葉で説明し、それからコードを書いていく方が良いのではないでしょうか?
敬具 ウラジミール
。
アレクセイ、私を信じてくれてありがとう。あとは、ポンプを使わないことです
敬具 ウラジミール
Peterさん、New7.mq5スクリプトにトレーリングストップを装備したい、特にサイクルの勉強を始めた今、私の思いをサポートしてくれてありがとうございました。ちなみに、スクリプトのSleep 機能はすでに試しています。トレーリングストップを書くときは、この機能を使うことが推奨されました。何から始めればいいのか?おそらく、まずトレーリングストップのアルゴリズム 全体を言葉で説明し、それからコードを書いていく方が良いのではないでしょうか?
敬具 ウラジミール
グローバル変数の値を変更するとエラーが発生するため、プログラマはグローバル変数の使用を恐れています。そのため、各機能によってエラーが変わる可能性があり、エラーの特定が困難な状況が生まれます。もちろん、グローバルスコープに存在するのは、すべてのプログラム関数が参照しなければならない変数だけでなければなりません。そうでなければならないのです。
一度松葉杖をつき始めるとなかなかやめられず、結果的にプロジェクトのコードがドレ...コードと呼ばれるものに変わってしまうという観察があります。
説明しよう。
実装された機能のカウンターは、次の機能を実装するまでの時間を増加させますが、正しく実装されるとゼロにリセットされるという事実に注目されましたか?
これは非常に大げさな考えですが、現実にはそういうものなのです。
どういうことかというと、すべての機能を実装した後にプロジェクトを書き直さなければ、読めないネタバレのまま製品化されてしまうということです。そして、どんなプロジェクトでも、そのライフサイクルは、経営者にとって頭痛の種となる。紡がれたものすべてのグローバル・リファクタリングにチーム全体を投入するか(競合他社は眠らず、彼ら、悪人たちは新しい機能を書く)、松葉杖を書き続け、激流で漏れるバグにパッチを当て続けるか、だ。
客観的に見れば、単純なトレーリングストップはスクリプトでは機能しない。トレーリングストップはそれ自体では存在せず、オープンポジションに「拘束」され、ストラテジーに「拘束」され、ストラテジーはExpert Advisorの中でのみ実装されます。
Peterさん、スクリプトの中に末尾のコードを作成するのでしょうか?完璧だ!あとは、基本的な部分として挙げていただいたものを、言葉で説明し始めると、後で関数やループなどをどう書けばいいのかが明確になりますね。これでよいのでしょうか?
ウラジミールさん、ありがとうございます。
Peter では、スクリプトで末尾のコードを作成するのですね。素晴らしいこのように、リストアップされたものを基本セクションとして、関数やループなどの書き方を明確にするために、言葉で説明するようになりました。これでよいのでしょうか?
ウラジミールさん、ありがとうございます。
一度カリカリし始めるとなかなか止まらないという観測があり、結果としてプロジェクトコードはいわゆるD.C.と呼ばれるものに変化していく。
説明しよう。
実装された機能のカウンターは、次の機能を実装するまでの時間を増加させますが、正しく実装されるとゼロにリセットされるという事実に注目されましたか?
これは非常に大げさな話ですが、現実にはそういうものなのです。
どういうことかというと、すべての機能を実装した後にプロジェクトを書き直さなければ、読めないネタバレのまま製品化されてしまうということです。そして、どんなプロジェクトのライフサイクルも、経営陣にとっては頭痛の種となる。チーム全体を、自分たちが紡いできたものすべてのグローバル・リファクタリングに投入するか(競合他社は目を覚まし、彼ら、悪人たちは新機能を書いている)、松葉杖を書き続け、激流で漏れるバグにパッチを当て続けるかだ。
このメッセージは主にピーターに宛てたものですが、皆さんのメッセージを十分に理解するために、スラングは一切使わず、ゼロからの初心者向けのテーマなので、プログラミングスクールの1年生が理解できる言葉で書いてくださいますようお願いします。
ウラジミールさん、ありがとうございます。