キャンバスがカッコいい! - ページ 17

 
Алексей Тарабанов:

形態分析 - 殺菌された細胞の分析。まず殺して、顕微鏡で観察するんです。

モルフォメトリックス

それだけです。もういい加減にしてくれ、この話題は。

 
fxsaber:


ダブルintはダブルの2倍の速度

規模に気づかず、30個のアセンブリ関数ではなく、5万~10万個の命令の配列を実行する意味を考えず、マイクロシンセティックで正しくテストをしていないのです。

上記の私の最初の返信で指摘したすべての点について反論してください。

 
Renat Fatkhullin:

30個のアセンブラ関数ではなく、5万~10万個の命令の配列を実行した場合の結果を考慮せず、規模を認識せず、マイクロシンセティックでテストを実行するのは間違っています。

最初の返信で、上記の私の指摘にそれぞれ反論してください。

その指摘に反論(ティック毎のプリミティブアクションとはいえ)。

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

キャンバスってすごい

レナート・ファットフーリン, 2019.01.15 22:37

64ビットコードとコンパイラを考慮すると、二重計算に基づくタスククラスの整数を忘れる必要があります。

テスターは二重計算を基本としています。しかも、1ティックごとに数が多いので、空走でも1秒間に700万ティックで 進みます。


各ティックでより複雑な動作をするシミュレータを書くことができます。しかし、テスターの基本は、現在のティック価格と注文価格を比較することで、コードを高くすることです。この主張は、決して空虚なものではありません。再現性のある測定値や計算代替案を公開しています。

 
fxsaber:

この点を(各ティックでのプリミティブアクションによってではあるが)証明した。

テスターは二重計算を基本としています。しかも、1回のティックあたりの数が非常に多く、空走でも1秒間に700万 回の速度で進む。


もっと複雑な動作を1ティックごとに行うシミュレータを書くことも可能です。しかし、Testerの基本は、現在のティック価格と注文価格を比較することで、コードをおおまかに高くしているのです。

これに反論してください。

  1. すべてintsに変換する必要があります。
  2. データ変換時のラグが大きい
  3. メモリ消費を抑える
  4. 各操作で100%の確率でオーバーフローが発生し、システムが完全に死亡する。
  5. インジケータを読ませてくれるという開発者を無視し、ダブりなくintで動くようになる
  6. そして、ダブとイントの速度の差はもうありません。信じがたいが、そうだ。

一点一点、お願いします。

4や5が1つでもあれば、整数加速の考えを融合させることができることを心に留めておいてください。

テスターが for(i=0;i<limit;i++ ) { } でないことを話しているのではありません。

しかし、整数演算において、ローカルマイクロコードの最適化の結果を保持することは望めないことも指摘できる。ループに無害な文字列を追加するだけで、何十パーセントも速度が落ちることがあります。そして、コードが膨れ上がった時に実作業に目を向けると、そこで全ての比較は地獄に落ちるのです。

 
Renat Fatkhullin:

これに反論してください。

  1. すべてintsに変換する必要があります。
  2. データ変換時のラグが大きい
  3. メモリ消費量がハンパない
  4. 各操作で100%の確率でオーバーフローが発生し、システム全体が死んでしまう。
  5. インジケータを読ませてくれるという開発者を無視し、ダブりなくintで動くようになる。
  6. そして、ダブとイントの速度の差はもうありません。信じがたいが、そうだ。

一点一点、お願いします。

4や5が1つでもあれば、整数加速の考え方が融合されることを心に留めておいてください。

スピードアップのために、まだ整数で解ける問題があることを示すことが目的だった。このようなテスターは、少なくともポイント5には当てはまらないので、ユニバーサルではないのです。


最初の4点については、問題点が遠回しに言われています。テスターの速度は最適化の時だけ必要なのですから。パスの束を1回だけカチカチと変換しているだけです。

 
fxsaber:

スピードアップのために、整数でも解ける問題があることを示すことが目的だった。このようなテスターは、少なくともポイント5には当てはまらないので、ユニバーサルではないのです。


最初の4点については、問題点が遠回しに言われています。テスターの速度は、最適化の時だけ必要だからです。パスの束に対して1回だけカチカチと変換します。

つまり、4点目も5点目も反論になっていない。

また、保存したい変換でも、すぐに時間コストが数倍になってしまいます。はい、変換用のメモリも含めて、その時々に。変換をなくすために、プラットフォーム全体をint64にしろということかと。

理論上も、すでに10年前からintに移行しても利益はない。
 
Renat Fatkhullin:

テスターがどうのこうのという話ではない for(i=0;i<limit;i++ ) { }.

タイマーのないテスターのことなら、テスターは刻みで使うものだと証明 されている。

 
fxsaber:

タイマーのないテスターのことなら、テスターは刻みのためのものだと証明 されたことになりますね。

これはテスターではなく、ニセモノです。指標もなく、利益も何もかもが全くない。しかし、整数のオーバーフローのリスクが常に付きまとう。

議論する意味すらありません。

そして、もう一度。

しかし、整数演算でローカルのマイクロコードの最適化結果を保存することは望めないことも指摘できる。

ループに無害な文字列を追加するだけで、数十パーセントの速度が失われることもあるのです。そして、コードが膨らんできたときに実作業に目を向けると、そこではすべての比較が地獄になります。

20個のアセンブラコマンドと数百、数千の実ブロックの最適化を行うと、サンプルが死んでしまうことを理解していますか?
 
Renat Fatkhullin:

そのため、論点4も5も反論になっていません。

しかも、その変換を保存したいとまで思うのだから、途端に費やした時間が倍増する。はい、変換メモリも含めて何倍も。変換をなくすために、プラットフォームごとint64価格に変えようという話かと思ったのですが。

どうやら誤解されているようです。私が話したのは、プライベートテスターの問題の例で、整数価格がある状況下で利得を与えることがあるというものです。ユニバーサルケースは念頭になかった。そのため、上にリンクを貼った私のテスターは、普遍的なものなので、ダブりにも実装しています。

理論上でも10年前からintに行くのは得策ではありません。

100%同意できない。

 
Renat Fatkhullin:

テスターではなく、模造品です。指標も利益も何もない状態でしかし、整数のオーバーフローのリスクが常に付きまとう。

これは、すべてのExpert Advisor(任意の指標を持つ)のコードを変更することなく、すべての取引と利益で完全なパスを作る、あなたのテスターのためのアドオンです。しかし、通常のテスターよりも高速に実行されます。再現性のある証明はすべて行っています。これらの主張は、資源の関係者が検証しています。

理由: