テスターの聖杯とは？ - ページ 15

新しいコメント
 
George Merts:

そして、どこまでもどこまでも仮想化について...。

...しかも、これが実際に存在するかどうかもわからない。あるいは、受け取った「unchat」でのすべての行動が、まったく別の存在によってコントロールされているとしたら。カッコいいと思うんです。

仮想化を不条理なまでに進める必要はないし、ましてや、あらゆる場所で仮想化を奨励する必要はない。

ここでは、あなたの仮想化を実生活に置き換えた例を紹介します。

マーシャに会いたいから電話すると、マーシャのふりをしてパシャがやってくる。

これがあなたの仮想化です。 さて、あなたはそれがクールであるかどうかを尋ねます。

敬意を込めて。

 
Andrey Kisselyov:



ここに、あなたの仮想化を実生活に置き換えた例があります。

あなたは少女マーシャに会いたいと思い、電話すると、マーシャのふりをしてパシャがやってきます。

ここにあなたの仮想化を実生活に置き換えた例があります。さて、これはクールだと思いますか?

そうなんだ！その典型的な例です。

もし、「経理部のマーシャに会いたい、なぜ会計ソフトがクソなのか教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、マーシャが来たとしても、私は嬉しくなります。もしかしたら、もっとかもしれません。

もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマーパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。

そして、もしあなたがモノに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして、マーシャを迎えに来た配偶者から、顔を覗かせることができるのです。

仮想化することで、特定の場所で特定の行動をするために必要なものに限定して要求することができます。それ以外はすべてカットされます。私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計 するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。

 
George Merts:

私が思うに、唯一の制約は、これらすべての仮想インターフェイスを設計するための「オーバーヘッド」です。シンプルなインジケータのアイデアを「素早く」確認したいのであれば、これだけOOP的に複雑なものを作るのは不合理です。

これは、最適化の際にテスター環境でどんなEAでも作業を遅くする 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。どんな仮想化（OOPであれ、CPUコアのスレッドの分割であれ）も実行時間を 長くし、パソコンの性能を低下させると私は言ってきましたし、これからも言うでしょうから。

OOPはプログラマーの利便性だけを追求し、コンピュータの性能を犠牲にして設計されています。

謹んで申し上げます。

 
Stefan Stoyanov:

2つの製品を無償で提供する

ロックダウン保護

常に役立つとは限りません。


とか、作業的な戦略とか、ないんですか？

 
Andrey Kisselyov:

これはテスター環境での最適化でどんなEAでも遅くなる 主な制限 だと思います。 EAの最適化を断行すれば、当然最適化時間は長くなります。 以前も言ったしこれからも言うつもりですが、どんな仮想化（OOPであれCPUコアでのスレッド分割であれ）も実行時間を 長くし、パソコンの性能を低下させることになるのです。

OOPは、コンピュータの性能を犠牲にして、純粋にプログラマーの利便性のために作られたものです。

謹んで申し上げます。


遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。

そして、今度はキラー・クエスチョン、つまり何％なのか？結局、誰もテストを作ろうとせず、何年も続けてフォーラムでやんややんや言うだけでした))

 
George Merts:

そうなんです。

ベースラインが必要なら......それが前段階のEquityなのです。確かに、変動する非固定的な価値。現実離れしている」とは思えない。逆に、バランスに意味があると考える人は、現実離れしていると思う。資本が1000 であれば、残高が100でも10Kでも 変わりません。重要なのは、前のステップの資本で、それが900であろうが1100であろうがです。


不条理なところまで持っていくこと。仮想化による不条理化のようなもの。;)))))

周りを見渡して、仮想の雲から地上に降りてきてください。

 
George Merts:

そうなんだ！その典型的な例です。

もし、「経理部のマーシャに会いたい、なぜ私の会計ソフトがデタラメなのかを教えてほしい」というリクエストがあったとして、プログラマーのパシャが来て何が問題なのかを説明してくれたら、私はマーシャが来てくれたらそれだけでうれしいです。もしかしたら、もっとかもしれません。

もうひとつは、必要なインターフェイスを正確に求めることです。もちろん、あなたがセックスを必要とし、マーシャの代わりにプログラマパシャを来た場合 - あなたは幸せになることはありません。しかし、すぐにその矛盾に気づき、なおかつ「コンパイル時に」ミスをなくすことができるのです。

そして、もしあなたがオブジェクトに直接アクセスできるのであれば、マーシャにセックスを要求した後、マーシャ自身から、そして--マーシャを迎えに来た配偶者から、顔に入れることができます。

仮想化 - そして、特定の場所で特定のアクションを行うために必要なものだけにリクエストを限定することができます。それ以外はすべてカットされます。私が思うに、唯一の制限は、すべての仮想インターフェイスを設計するための「オーバーヘッド」です。単純なインジケータのアイデアを「素早く」確認したいのであれば、このようなOOPの複雑さを全て作るのは無理があります。


どうやら、OOPにハマる可能性があるようです。その症状は、極端な仮想化、現実からの逃避、現実を仮想に置き換えることです。

;)))

 
ivan12347777:

バプラタグレイルはないのか）、作業的な戦略はないのか。

いいえ

お客様を混乱させないために、マーケットプレイスからGrailsを 削除しました。

人を騙すようなことはしたくない。

 
Alexey Volchanskiy:

遅らせる」という言葉は、なぜかOOP反対派を怖がらせる )))遅延を導入する」という表現を使うのがよいでしょう。

そして、今度はキラー・クエスチョン、つまり何％なのか？結局、誰もテストを作ろうとせず、何年も続けてフォーラムでボヤボヤしているだけでした ))

仮想化愛好家自身にもよるだろうが、クラス数が多ければラグも大きくなるだろうし、1機能しか仮想化されていなければラグも小さくなるだろう。

敬意を込めて。

 
George Merts:

О !せめて、ロックと再開の違いくらいは教えてほしい。

スワップがなく、Expert Advisorが取引している場合、ロックと再ロックの間に違いはないと私は思います。

知られざる違いがある - それはセカンドチャンス

ロック＋メインポジションをクローズすることで、オープニングとクロージングオーダーの良い戦略を持っていれば、利益を 得るチャンスが増える

ストップロスで 決済する場合、チャンスはない のですが、時にはこれがベストです。

一般的に 、 トレンドと横ばいを 明確に区別する場合 、ロックが 有効な場合が あります。

1...8910111213141516171819202122...26
新しいコメント