MT5ターミナルが本日アップデートされ、テスト中に「最適化」ウィンドウが表示されなくなりました。 - ページ 13

新しいコメント
 
Сергей Таболин:
1755ビルドのダウンロード先と、この（現在の）誤解を解くために自動更新しないようにする方法を教えていただけませんか？

1795も 問題なかったようです。

1755も 必要ならいいんだけどね。

To block updates, close write access to C:\Usersyour_name ◇AppData ◇Roaming ◇MetaQuotes ◇WebInstall ◇...
 
Texnolog:
端末は「 利食い」ボタン1つで構成されているのが理想的です。
しかし、マウスを乗せると、ボタンが「Drain deposit」に変化します。
 
最適化グラフが チラつくようになったのが気になる...。
 
最適化テーブルを復活させよう
 

開発者は皆、最適化の 結果を見た後、最初の行から続けることに意味があるかどうかを判断するのです。だからこそ、最適化の終了前に、中断することなく結果を確認できるようにすべきなのです。

最適化結果」タブを復活させ、表の上部に 「表を更新」 ボタンを追加することが考えられます。

これなら、もっと意味がある。

 
Petros Shatakhtsyan:

開発者は皆、最適化の 結果を見た後、最初の行から続けることに意味があるかどうかを判断するのです。だからこそ、最適化の終了前に、中断することなく結果を確認できるようにすべきなのです。

最適化結果」というタブを復活させ、表の上部に 「表を更新」 ボタンを追加することが考えられます。

その方が意味がある。

+1

 
Petros Shatakhtsyan:

開発者は皆、最適化の 結果を見た後、最初の行から続けることに意味があるかどうかを判断するのです。だからこそ、最適化の終了前に、中断することなく結果を確認できるようにすべきなのです。

最適化結果」というタブを復活させ、表の上部に 「表を更新」 ボタンを追加することが考えられます。

その方が意味がある。

枝の上で正しく指摘されているように、たとえボタンを追加する必要はありません、ちょうど最適化の間にテーブルのデータを強制的にソートする必要はありません、そして、ユーザーは、以前のように、彼が合うと思うときに、テーブルのヘッダーで自分自身が目的の列をクリックすることができ、テーブルはそれぞれそれでソートされます、PCユーザーの貴重なリソースを費やしています。

しかし、@Renat Fatkhullinは、人間の目では1億件のエントリーなどを処理しきれず、途中で表示する意味がないことを訴えたという。
そして、この点に関して知りたいのは、最適化の際に1億パス、あるいは5千万パス、少なくとも1千万パスを行う人がいるのか、そして、そのような最適化にどれだけの時間とお金をかけているのか、そして、最も重要なことは、どの（原始）オプティマイザを実行すれば、1/5/1億パスを数分の1で計算することができるのか、妥当な時間内に計算できるのか・・・ということです。

 
Aleksandr Volotko:

上の枝で正しく指摘されているように、ボタンを追加する必要もなく、最適化の際にテーブルデータをソートする必要がないだけで、ユーザーは従来通り、必要と思われるときにテーブルヘッダの必要な列を自分でクリックすれば、テーブルはそれぞれその列でソートされ、ユーザーPCの貴重な資源を費やすことになります。

しかし、@Renat Fatkhullinは、人間の目では1億件のエントリーなどを処理しきれず、途中で表示する意味がないことを訴えたという。
そして、この点に関して知りたいのは、最適化の際に1億パス、あるいは5千万パス、少なくとも1千万パスを行う人がいるのか、そして、そのような最適化にどれだけの時間とお金をかけているのか、そして、最も重要なことは、どの（原始）オプティマイザを実行すれば、1/5/1億パスを数分の1で計算することができるのか、妥当な時間内に計算できるのか・・・ということです。

納品から1年、すべてのパラメータを試して、標準的なミューリングエキスパートが、少なくともgoogleのバリアントを得るのは簡単です。:-)
 
Aleksandr Volotko:

スレッドの上で正しく指摘されているように、最適化の際にテーブルデータを強制的にソートする必要がないだけで、ユーザーは従来通り、必要と思われるときにテーブルヘッダの必要な列を自分でクリックすれば、それに応じてテーブルがソートされ、ユーザーのPCの貴重なリソースを費やすことになります。

しかし、@Renat Fatkhullinは、人間の目では1億件のレコードなどを処理できないことをアピールし、途中で見せる意味がない、という。
そして、この関連で知りたいのは、最適化の際に1億パス、あるいは5千万パス、少なくとも1千万パスを行う人がいるのか、そして、そのような最適化にどれだけの時間とお金をかけているのか、そして、最も重要なことは、1/5/1億パスを1秒単位で計算し、妥当な時間で行うためには、どのような（原始）最適化装置がその中で実行されるべきなのか...ということです。

だから、レナートの言うニーズが理解できないのか...。MQはそういうもので、自分たちのためにやって、あとは楽しむだけというのが、すべての歴史が示していることです。レナートには同情します。最初の投稿から判断すると、彼はベストを尽くしたかったし、熱心に業績について話していました。一般に、国民は善意を評価することはできなかった。「じゃあ、何かしてあげてよ」とレナートは思っているのか、もうこのスレッドでは答えない。

私自身は、MQが製品を発展させるために多くの努力を続けていることをとても嬉しく思っています。しかし、時にはユーザーの意見に耳を傾けることも必要でしょう...。
 
Aleksandr Volotko:

上の枝で正しく指摘されているように、最適化の際にテーブルデータのソートを強制する必要がないだけで、ユーザーは従来通り、必要と思われるときにテーブルヘッダの必要な列を自分でクリックすれば、それに応じてテーブルがソートされ、ユーザーのPCの貴重なリソースを費やすことになります。

しかし、@Renat Fatkhullin 氏は、人間の目では1億件のレコードなどを処理できず、途中で表示する意味がないことを訴えたという。
そして、この関連で知りたいのは、最適化中に1億パス、あるいは5千万パス、少なくとも1千万パスを行う人がいるのか、そのような最適化のためにどれだけの時間とお金を費やしているのか、そして最も重要なことは、オプティマイザで何を実行すれば、1/5/1億パスを妥当な時間で計算でき、1秒に1回計算できるようになるのか...ということです。


>1日の時間、1エージェントあたり20ドル（最適化を止めた後、70％以上の結果がNULLでしたが！） - すぐに結果がゼロになった場合、テストを止めて原因を突き止めたと思います。

最適化するのに半年かかりました。コード内のすべてのものは、最適化のために可能な限り圧縮されています。

100万円、100倍ですね...。

1...67891011121314151617181920...25
新しいコメント