エラー、バグ、質問 - ページ 2221

[SEM]

合成工具です。分単位のバーをインポート すると、各分単位のバーが1ポイント（5桁）ずつ異なる。

シンボルのあるウィンドウを閉じてから、このウィンドウを再び開き、前回のロードから分単位のバーを要求すると、次のような結果が得られます。

記号は全日程共通です。エラーは何ですか？

[Koldun Zloy]

elibrarius:

Alglibパッケージのコードに目を通す。こういう構文がいっぱいあって、コードを読み にくくしているんです。

こっちの方がシンプルでしょう？

実行速度がさらに上がるような気がします。

なぜ、あんなに複雑なコードにしたのでしょうか？それとも、他の言語から何も手を加えずに移植したのでしょうか？しかし、やはり原文ではなぜそんなこじつけをしたのだろうか？

これは、スピードアップのために、オリジナルのコードで正確に行われた可能性が高いです。

MQLで速くなるかどうかは測定する必要があり、ここでは「らしい」は通用しない。

[Nikolai Semko]

Koldun Zloy:

これは、加速のためにオリジナルで行っている可能性が 高いです。

MQLで速くなるかどうかは測定する必要があり、ここでは「らしい」は通用しない。

"Most likely "も通用しない。
このような形が、どうして速く機能するのでしょうか？何を言っているんだ！？

2つの余分なループと、1つの変数の代わりに余分な配列があります。

[Koldun Zloy]

Nikolai Semko:

2つの余分なループと、1つの変数の代わりに余分な配列があります。

このような原始的な推論は、現代のプロセッサーには適さない。

[Nikolai Semko]

Koldun Zloy:

このような原始的な推論は、現代のプロセッサーには適さない。

よくご存じですね。もっと経験を 積んで...

[Nikolai Semko]

Koldun Zloy:

このような原始的な推論は、現代のプロセッサーには適さない。

要するに、申し訳ないが、妄想なのだ。

現在存在するどのプロセッサーも、決して

for(i=0;i<=npoints-1;i++)

に比べれば早い

for(i=0;i<npoints;i++)

であり、配列への アクセスが単純な変数へのアクセスより高速になることはない。

3つの同じループが1つの組み合わせのループより速くなることはない。

私は怠惰なされていないと、根拠のないように、元のALGLIBで直接2つの異なるバリアントの速度をテストしている 。

      e=0;
      double tmp1;
      ulong t=GetMicrosecondCount();
      for(i=0;i<npoints;i++)
        {
         v=0.0;
         for(i_=0;i_<nvars;i_++)
           {
            tmp1=xy[i][i_]-ct[xyc[i]][i_];
            v+=tmp1*tmp1;
           }
         e=e+v;
        }
      t=GetMicrosecondCount()-t;
      Print("fast = "+(string)t+" микросекунд, e = "+DoubleToString(e) + " , npoints = " + (string)npoints+" , nvars = " + (string)nvars );



      e=0;
      t=GetMicrosecondCount();
      for(i=0;i<=npoints-1;i++)
        {
         for(i_=0;i_<=nvars-1;i_++)
            tmp[i_]=xy[i][i_];
         for(i_=0;i_<=nvars-1;i_++)
            tmp[i_]=tmp[i_]-ct[xyc[i]][i_];
         //--- calculation
         v=0.0;
         for(i_=0;i_<=nvars-1;i_++)
            v+=tmp[i_]*tmp[i_];
         e=e+v;
        }
      t=GetMicrosecondCount()-t;
      Print("slow = "+(string)t+" микросекунд, e = "+DoubleToString(e) + " , npoints = " + (string)npoints+" , nvars = " + (string)nvars );

の結果です。

2018.06.27 04:36:50.265 TestClasses (GBPUSD,M6) fast = 571 микросекунд, e = 534.47773777 , npoints = 1500 , nvars = 40
2018.06.27 04:36:50.266 TestClasses (GBPUSD,M6) slow = 841 микросекунд, e = 534.47773777 , npoints = 1500 , nvars = 40
2018.06.27 04:36:50.630 TestClasses (GBPUSD,M6) fast = 577 микросекунд, e = 531.85904819 , npoints = 1500 , nvars = 40
2018.06.27 04:36:50.631 TestClasses (GBPUSD,M6) slow = 812 микросекунд, e = 531.85904819 , npoints = 1500 , nvars = 40
2018.06.27 04:36:51.143 TestClasses (GBPUSD,M6) fast = 599 микросекунд, e = 537.42685690 , npoints = 1500 , nvars = 40
2018.06.27 04:36:51.144 TestClasses (GBPUSD,M6) slow = 853 микросекунд, e = 537.42685690 , npoints = 1500 , nvars = 40
2018.06.27 04:36:51.955 TestClasses (GBPUSD,M6) fast = 600 микросекунд, e = 531.17444713 , npoints = 1500 , nvars = 40
2018.06.27 04:36:51.956 TestClasses (GBPUSD,M6) slow = 809 микросекунд, e = 531.17444713 , npoints = 1500 , nvars = 40
2018.06.27 04:36:52.344 TestClasses (GBPUSD,M6) fast = 567 микросекунд, e = 540.39509565 , npoints = 1500 , nvars = 40
2018.06.27 04:36:52.344 TestClasses (GBPUSD,M6) slow = 813 микросекунд, e = 540.39509565 , npoints = 1500 , nvars = 40
2018.06.27 04:36:52.857 TestClasses (GBPUSD,M6) fast = 690 микросекунд, e = 550.68494369 , npoints = 1500 , nvars = 40
2018.06.27 04:36:52.858 TestClasses (GBPUSD,M6) slow = 820 микросекунд, e = 550.68494369 , npoints = 1500 , nvars = 40
2018.06.27 04:36:53.229 TestClasses (GBPUSD,M6) fast = 585 микросекунд, e = 547.94313745 , npoints = 1500 , nvars = 40
2018.06.27 04:36:53.230 TestClasses (GBPUSD,M6) slow = 811 микросекунд, e = 547.94313745 , npoints = 1500 , nvars = 40
2018.06.27 04:36:53.736 TestClasses (GBPUSD,M6) fast = 560 микросекунд, e = 568.39404456 , npoints = 1500 , nvars = 40
2018.06.27 04:36:53.737 TestClasses (GBPUSD,M6) slow = 813 микросекунд, e = 568.39404456 , npoints = 1500 , nvars = 40

つまり、40％以上の速度向上が確認できます。

[Forester]

Nikolai Semko:

まあ要するに、申し訳ないけど妄想なんだよね。

現在存在するどのプロセッサーも、決して

に比べれば早い

であり、配列への アクセスが単純な変数へのアクセスより高速になることはない。

3つの同じループが1つの組み合わせのループより速くなることはない。

私は怠惰なされていないと、根拠のないように、元のALGLIBで直接2つの異なるバリアントの速度をテストしている 。

の結果です。

つまり、40％以上の速度向上が確認できます。

テストありがとうございましたMQLだけでなく、すべての言語で高速に動作するようになると思います。

私が考えていた理由は、それを書いたプログラマーは、プログラムが動いただけでなく、行数に対して報酬をもらっていたことです。なぜなら、500行のプログラムと5000行のプログラムでは、お客様にとってあまり印象が良くないからです。そのために、コードのスピードや読みやすさが損なわれてしまったのは残念です。

[Nikolai Semko]

elibrarius:
MQLだけでなく、すべての言語で高速に動作するようになると思います。

もちろんです。

[ruslan]

MQLにログインする際にエラーが発生し、ブラウザのステータスにFacebookからの長い回答（おそらく認証）があることに気づきました。

[Alexander]

SEM:

合成工具です。分単位のバーをインポートすると、各分単位のバーが1ポイント（5桁）ずつ異なる。

シンボルのあるウィンドウを閉じてから、このウィンドウを再び開き、前回のロードから分単位のバーを要求すると、次のような結果が得られます。

記号は全日程共通です。エラーは何ですか？

安定した再生ができていますか？ビルドとは？