テスターの聖杯とは? - ページ 15 1...8910111213141516171819202122...26 新しいコメント Andrey Kisselyov 2017.08.21 12:47 #141 George Merts:そして、どこまでもどこまでも仮想化について...。 ...しかも、これが実際に存在するかどうかもわからない。あるいは、受け取った「unchat」でのすべての行動が、まったく別の存在によってコントロールされているとしたら。カッコいいと思うんです。 仮想化を不条理なまでに進める必要はないし、ましてや、あらゆる場所で仮想化を奨励する必要はない。 ここでは、あなたの仮想化を実生活に置き換えた例を紹介します。 マーシャに会いたいから電話すると、マーシャのふりをしてパシャがやってくる。 これがあなたの仮想化です。 さて、あなたはそれがクールであるかどうかを尋ねます。 敬意を込めて。 Georgiy Merts 2017.08.21 13:00 #142 Andrey Kisselyov: ここに、あなたの仮想化を実生活に置き換えた例があります。 あなたは少女マーシャに会いたいと思い、電話すると、マーシャのふりをしてパシャがやってきます。 ここにあなたの仮想化を実生活に置き換えた例があります。さて、これはクールだと思いますか?そうなんだ!その典型的な例です。もし、「経理部のマーシャに会いたい、なぜ会計ソフトがクソなのか教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、マーシャが来たとしても、私は嬉しくなります。もしかしたら、もっとかもしれません。 もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマーパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。 そして、もしあなたがモノに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして、マーシャを迎えに来た配偶者から、顔を覗かせることができるのです。 仮想化することで、特定の場所で特定の行動をするために必要なものに限定して要求することができます。それ以外はすべてカットされます。私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計 するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。 Andrey Kisselyov 2017.08.21 13:10 #143 George Merts:私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計するための「オーバーヘッド」です。シンプルなインジケータのアイデアを「素早く」確認したいのであれば、これだけOOP的に複雑なものを作るのは不合理です。 これは、最適化の際にテスター環境でどんなEAでも作業を遅くする 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。どんな仮想化(OOPであれ、CPUコアのスレッドの分割であれ)も実行時間を 長くし、パソコンの性能を低下させると私は言ってきましたし、これからも言うでしょうから。 OOPはプログラマーの利便性だけを追求し、コンピュータの性能を犠牲にして設計されています。 謹んで申し上げます。 ivan12347777 2017.08.21 13:18 #144 Stefan Stoyanov:2つの製品を無償で提供する ロックダウン保護常に役立つとは限りません。とか、作業的な戦略とか、ないんですか? Alexey Volchanskiy 2017.08.21 13:34 #145 Andrey Kisselyov:これはテスター環境での最適化でどんなEAでも遅くなる 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。 以前も言ったしこれからも言うつもりですが、どんな仮想化(OOPであれCPUコアでのスレッド分割であれ)も実行時間を 長くし、パソコンの性能を低下させることになるのです。 OOPは、コンピュータの性能を犠牲にして、純粋にプログラマーの利便性のために作られたものです。 謹んで申し上げます。遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。そして、今度はキラー・クエスチョン、つまり何%なのか?結局、誰もテストを作ろうとせず、何年も続けてフォーラムでやんややんや言うだけでした)) 削除済み 2017.08.21 13:35 #146 George Merts:そうなんです。 ベースラインが必要なら......それが前段階のEquityなのです。確かに、変動する非固定的な価値。現実離れしている」とは思えない。逆に、バランスに意味があると考える人は、現実離れしていると思う。資本が1000 であれば、残高が100でも10Kでも 変わりません。重要なのは、前のステップの資本で、それが900であろうが1100であろうがです。 不条理なところまで持っていくこと。仮想化による不条理化のようなもの。;)))))周りを見渡して、仮想の雲から地上に降りてきてください。 削除済み 2017.08.21 13:41 #147 George Merts:そうなんだ!その典型的な例です。もし、「経理部のマーシャに会いたい、なぜ私の会計ソフトがデタラメなのかを教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、私はマーシャが来てくれたらそれだけでうれしいです。もしかしたら、もっとかもしれません。 もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。 そして、もしあなたがオブジェクトに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして--マーシャを迎えに来た配偶者から、顔に入れることができます。 仮想化 - そして、特定の場所で特定のアクションを行うために必要なものだけにリクエストを限定することができます。それ以外はすべてカットされます。私が思うに、唯一の制限は、すべての仮想インターフェイスを設計するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。 どうやら、OOPにハマる可能性があるようです。その症状は、極端な仮想化、現実からの逃避、現実を仮想に置き換えることです。;))) Stefan Stoyanov 2017.08.21 13:49 #148 ivan12347777: バプラタグレイルはないのか)、作業的な戦略はないのか。いいえ お客様を混乱させないために、マーケットプレイスからGrailsを 削除しました。人を騙すようなことはしたくない。 Andrey Kisselyov 2017.08.21 14:01 #149 Alexey Volchanskiy: 遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。そして、今度はキラー・クエスチョン、つまり何%なのか?結局、誰もテストを作ろうとせず、何年も続けてフォーラムでボヤボヤしているだけでした ))仮想化愛好家自身にもよるだろうが、クラス数が多ければラグも大きくなるだろうし、1機能しか仮想化されていなければラグも小さくなるだろう。 敬意を込めて。 Stefan Stoyanov 2017.08.21 14:02 #150 George Merts:О !せめて、ロックと再開の違いくらいは教えてほしい。 スワップがなく、Expert Advisorが取引している場合、ロックと再ロックの間に違いはないと私は思います。知られざる違いがある - それはセカンドチャンス ロック+メインポジションをクローズすることで、オープニングとクロージングオーダーの良い戦略を持っていれば、利益を 得るチャンスが増えるストップロスで 決済する場合、チャンスはない のですが、時にはこれがベストです。一般的に 、 トレンドと横ばいを 明確に区別する場合 、ロックが 有効な場合が あります。 1...8910111213141516171819202122...26 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
そして、どこまでもどこまでも仮想化について...。
...しかも、これが実際に存在するかどうかもわからない。あるいは、受け取った「unchat」でのすべての行動が、まったく別の存在によってコントロールされているとしたら。カッコいいと思うんです。仮想化を不条理なまでに進める必要はないし、ましてや、あらゆる場所で仮想化を奨励する必要はない。
ここでは、あなたの仮想化を実生活に置き換えた例を紹介します。
マーシャに会いたいから電話すると、マーシャのふりをしてパシャがやってくる。
これがあなたの仮想化です。 さて、あなたはそれがクールであるかどうかを尋ねます。
敬意を込めて。
ここに、あなたの仮想化を実生活に置き換えた例があります。
あなたは少女マーシャに会いたいと思い、電話すると、マーシャのふりをしてパシャがやってきます。
ここにあなたの仮想化を実生活に置き換えた例があります。さて、これはクールだと思いますか?
そうなんだ!その典型的な例です。
もし、「経理部のマーシャに会いたい、なぜ会計ソフトがクソなのか教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、マーシャが来たとしても、私は嬉しくなります。もしかしたら、もっとかもしれません。
もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマーパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。
そして、もしあなたがモノに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして、マーシャを迎えに来た配偶者から、顔を覗かせることができるのです。
仮想化することで、特定の場所で特定の行動をするために必要なものに限定して要求することができます。それ以外はすべてカットされます。私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計 するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。
私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計するための「オーバーヘッド」です。シンプルなインジケータのアイデアを「素早く」確認したいのであれば、これだけOOP的に複雑なものを作るのは不合理です。
これは、最適化の際にテスター環境でどんなEAでも作業を遅くする 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。どんな仮想化(OOPであれ、CPUコアのスレッドの分割であれ)も実行時間を 長くし、パソコンの性能を低下させると私は言ってきましたし、これからも言うでしょうから。
OOPはプログラマーの利便性だけを追求し、コンピュータの性能を犠牲にして設計されています。
謹んで申し上げます。
2つの製品を無償で提供する
ロックダウン保護
常に役立つとは限りません。
とか、作業的な戦略とか、ないんですか?
これはテスター環境での最適化でどんなEAでも遅くなる 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。 以前も言ったしこれからも言うつもりですが、どんな仮想化(OOPであれCPUコアでのスレッド分割であれ)も実行時間を 長くし、パソコンの性能を低下させることになるのです。
OOPは、コンピュータの性能を犠牲にして、純粋にプログラマーの利便性のために作られたものです。
謹んで申し上げます。
遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。
そして、今度はキラー・クエスチョン、つまり何%なのか?結局、誰もテストを作ろうとせず、何年も続けてフォーラムでやんややんや言うだけでした))
そうなんです。
ベースラインが必要なら......それが前段階のEquityなのです。確かに、変動する非固定的な価値。現実離れしている」とは思えない。逆に、バランスに意味があると考える人は、現実離れしていると思う。資本が1000 であれば、残高が100でも10Kでも 変わりません。重要なのは、前のステップの資本で、それが900であろうが1100であろうがです。
不条理なところまで持っていくこと。仮想化による不条理化のようなもの。;)))))
周りを見渡して、仮想の雲から地上に降りてきてください。
そうなんだ!その典型的な例です。
もし、「経理部のマーシャに会いたい、なぜ私の会計ソフトがデタラメなのかを教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、私はマーシャが来てくれたらそれだけでうれしいです。もしかしたら、もっとかもしれません。
もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。
そして、もしあなたがオブジェクトに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして--マーシャを迎えに来た配偶者から、顔に入れることができます。
仮想化 - そして、特定の場所で特定のアクションを行うために必要なものだけにリクエストを限定することができます。それ以外はすべてカットされます。私が思うに、唯一の制限は、すべての仮想インターフェイスを設計するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。
どうやら、OOPにハマる可能性があるようです。その症状は、極端な仮想化、現実からの逃避、現実を仮想に置き換えることです。
;)))
バプラタグレイルはないのか)、作業的な戦略はないのか。
いいえ
お客様を混乱させないために、マーケットプレイスからGrailsを 削除しました。
人を騙すようなことはしたくない。
遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。
そして、今度はキラー・クエスチョン、つまり何%なのか?結局、誰もテストを作ろうとせず、何年も続けてフォーラムでボヤボヤしているだけでした ))
仮想化愛好家自身にもよるだろうが、クラス数が多ければラグも大きくなるだろうし、1機能しか仮想化されていなければラグも小さくなるだろう。
敬意を込めて。
О !せめて、ロックと再開の違いくらいは教えてほしい。
スワップがなく、Expert Advisorが取引している場合、ロックと再ロックの間に違いはないと私は思います。
知られざる違いがある - それはセカンドチャンス
ロック+メインポジションをクローズすることで、オープニングとクロージングオーダーの良い戦略を持っていれば、利益を 得るチャンスが増える
ストップロスで 決済する場合、チャンスはない のですが、時にはこれがベストです。
一般的に 、 トレンドと横ばいを 明確に区別する場合 、ロックが 有効な場合が あります。