defineの専門家に質問 - ページ 9 123456789101112 新しいコメント Roman 2020.11.03 01:04 #81 Alexandr Andreev:これは必ずしもうまくいくとは限りません。 ループ体が異なるため、正しいテストではありません。 2体目にはより多くの指示がある cnt-- だから、これは私の正しいテストではないのです。 PIでは、より正しいと思います。 Alexandr Andreev 2020.11.03 01:07 #82 Roman:ループ体が異なるため、正しいテストではありません。 2体目にも指示cnt-- これは私の正しいテストではありません。 PIでは、より正しいと思います。 というのは、このテストは、使い方も常識も限りなく正しいのです。配列自体のサイズを変更するループでは、全く同じコードが存在することになります。この例は、まさにその通りです。 しかし、PIはそこにあり、結果は明らかに一方通行ではありません、確認してみてください。 Roman 2020.11.03 01:22 #83 Alexandr Andreev:まさに生き方、使い方や常識が正しくないテストです。 配列自体のサイズを変更するループでは、全く同じコードが存在することになります。この例は、まさにその通りです。しかし、PIは存在し、その結果は明らかに一方向ではありません。 しかし、どうすれば正しいのでしょうか? ループ本体内の命令が多い場合、反復中に実行されるコードが増え、余分な命令がインクリメントされる。 実行時間が増加する。論理的である。 また、ボディが同じ場合は、ループ条件への参照を評価しても、もう大丈夫なんです。 Alexandr Andreev 2020.11.03 01:30 #84 Roman:どのように正しいのか? ループ本体の命令が多ければ、反復中に実行されるコードが増え、余分な命令がインクリメントされる。 実行時間が増加する。論理的である。 そして、ボディが同じであれば、もう安全にループ条件の呼び出しを推定することができる。 )))) すべての規範で正しいわけではありません。ランの間がある(ランの回数が多い、コンパイル回数が多い-一方通行)ので、一方通行の計算の差は、計算する値より大きくなります。その差は、システムからの現在のタスクによるものです。つまり、検査値のシェアが小さすぎる、増やすためには、この体の機能の数を増やさなければならない......ということです。で、一番安いオペレーションを取る。そして、これが掛け算!・・・。まだ他には見つかっていません。例えば、私の例では除算を1回行っていますが、これはπの計算方法と比べると何倍も少なく、タイプゴーストも使われています(かなり高価な処理です)。 Roman 2020.11.03 01:37 #85 Alexandr Andreev:))))すべての規範で正しいわけではありません。ランの間(より頻繁に実行し、より多くのランをコンパイルする-一方通行)があるので、公言された値よりも一方通行のためのランの間の計算の違いがあります。その差は、システムからの現在のタスクによるものです。つまり、検査値のシェアが小さすぎる、増やすためには、この体の機能の数を増やさなければならない......ということです。で、一番安いオペレーションを取る。そして、これが掛け算!・・・。まだ他には見つかっていません。例えば、私の例では除算を1回行っていますが、これはπの計算方法よりも何倍も少ないものです。また、タイプゴーストも使われています(かなり高価な処理)。 もう一度言います。テストされるのは、ループ本体ではなく、ループの条件です。 ループの本体が同じでなければ、条件の成立を測定できない。 そうでない場合は、本体が異なる時間で実行されるため、測定時間が異なってきます。 この場合、余分な命令 cnt があるため、このような結果になりました。 Alexandr Andreev 2020.11.03 01:38 #86 void OnStart() { int mas[]; int mas1[300]; int mas2[300]; int mas3[300]; int mas4[300]; int mas5[300]; int mas6[300]; int z=300; int size=1000000000; ArrayResize(mas,size); int r=0; int r1=0; int r2=0; int random; ulong max=100; int t=0; int tr=0; MathSrand(10); int num_steps=ArraySize(mas); double x, pi, sum=0.0; double step = 1.0/(double)num_steps; int v=size; ulong t1 = GetMicrosecondCount(); // for(ulong z=0; z<max; z++) { for(int i=0; i<ArraySize(mas); i++) { r2+=ArraySize(mas); r2<<=3; } } ulong t2=GetMicrosecondCount(); //for(ulong z=0; z<max; z++) int sizem=ArraySize(mas); { for(int i=0; i<sizem; i++) { r2+=sizem; r2<<=3; } } ulong t3=GetMicrosecondCount(); Print(t2-t1," ",t3-t2," ",r2," ",r1); // Templ(); } 一般に、許しや2進シフト(これは最も安価な操作の1つである)を交互に行うと、計算にも影響が出ることが判明した...。まあ違いはない、それが評決だ。 Alexandr Andreev 2020.11.03 01:45 #87 Roman:もう一度言います。テストされるのはループ本体ではなく、ループの条件です。 条件を測定するためには、ループ体が同じである必要があります。 そうでない場合は、ボディが異なる時間で実行されるため、測定時間が異なります。 この場合、余分な命令 cnt があるため、このような結果になりました。 実は私の文章は、まさにπの方法についてでした。 Алексей Тарабанов 2020.11.03 01:51 #88 defineについて聞くのも怖いです Roman 2020.11.03 01:57 #89 Алексей Тарабанов: defineについて聞くのも怖いです ディファインについて、もう少し詳しくお話ししましょう。 私の理解では、実行ファイルにランタイムブーストを与えることはありません。 Алексей Тарабанов 2020.11.03 02:10 #90 Roman:ディファインについて、もう少し詳しくお話ししましょう。 私の理解では、実行ファイルでの実行回数が増えることはないです。 なるほど。まず定義、次に実行ファイル、そして実行ファイルの実行です。 123456789101112 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
これは必ずしもうまくいくとは限りません。
ループ体が異なるため、正しいテストではありません。
2体目にはより多くの指示がある cnt--
だから、これは私の正しいテストではないのです。
PIでは、より正しいと思います。
ループ体が異なるため、正しいテストではありません。
2体目にも指示cnt--
これは私の正しいテストではありません。
PIでは、より正しいと思います。
というのは、このテストは、使い方も常識も限りなく正しいのです。配列自体のサイズを変更するループでは、全く同じコードが存在することになります。この例は、まさにその通りです。
しかし、PIはそこにあり、結果は明らかに一方通行ではありません、確認してみてください。
まさに生き方、使い方や常識が正しくないテストです。
配列自体のサイズを変更するループでは、全く同じコードが存在することになります。この例は、まさにその通りです。
しかし、PIは存在し、その結果は明らかに一方向ではありません。
しかし、どうすれば正しいのでしょうか?
ループ本体内の命令が多い場合、反復中に実行されるコードが増え、余分な命令がインクリメントされる。
実行時間が増加する。論理的である。
また、ボディが同じ場合は、ループ条件への参照を評価しても、もう大丈夫なんです。
どのように正しいのか?
ループ本体の命令が多ければ、反復中に実行されるコードが増え、余分な命令がインクリメントされる。
実行時間が増加する。論理的である。
そして、ボディが同じであれば、もう安全にループ条件の呼び出しを推定することができる。
))))
すべての規範で正しいわけではありません。ランの間がある(ランの回数が多い、コンパイル回数が多い-一方通行)ので、一方通行の計算の差は、計算する値より大きくなります。その差は、システムからの現在のタスクによるものです。つまり、検査値のシェアが小さすぎる、増やすためには、この体の機能の数を増やさなければならない......ということです。で、一番安いオペレーションを取る。そして、これが掛け算!・・・。まだ他には見つかっていません。例えば、私の例では除算を1回行っていますが、これはπの計算方法と比べると何倍も少なく、タイプゴーストも使われています(かなり高価な処理です)。
))))
すべての規範で正しいわけではありません。ランの間(より頻繁に実行し、より多くのランをコンパイルする-一方通行)があるので、公言された値よりも一方通行のためのランの間の計算の違いがあります。その差は、システムからの現在のタスクによるものです。つまり、検査値のシェアが小さすぎる、増やすためには、この体の機能の数を増やさなければならない......ということです。で、一番安いオペレーションを取る。そして、これが掛け算!・・・。まだ他には見つかっていません。例えば、私の例では除算を1回行っていますが、これはπの計算方法よりも何倍も少ないものです。また、タイプゴーストも使われています(かなり高価な処理)。
もう一度言います。テストされるのは、ループ本体ではなく、ループの条件です。
ループの本体が同じでなければ、条件の成立を測定できない。
そうでない場合は、本体が異なる時間で実行されるため、測定時間が異なってきます。
この場合、余分な命令 cnt があるため、このような結果になりました。
一般に、許しや2進シフト(これは最も安価な操作の1つである)を交互に行うと、計算にも影響が出ることが判明した...。まあ違いはない、それが評決だ。
もう一度言います。テストされるのはループ本体ではなく、ループの条件です。
条件を測定するためには、ループ体が同じである必要があります。
そうでない場合は、ボディが異なる時間で実行されるため、測定時間が異なります。
この場合、余分な命令 cnt があるため、このような結果になりました。
実は私の文章は、まさにπの方法についてでした。
defineについて聞くのも怖いです
ディファインについて、もう少し詳しくお話ししましょう。
私の理解では、実行ファイルにランタイムブーストを与えることはありません。
ディファインについて、もう少し詳しくお話ししましょう。
私の理解では、実行ファイルでの実行回数が増えることはないです。
なるほど。まず定義、次に実行ファイル、そして実行ファイルの実行です。