定義された要素の配列をクリアする。 - ページ 12

新しいコメント
 
Alexey Viktorov:

そのため、注文が終了した場合は、配列から「クロスアウト」する必要があります。そんな時は、以前は配列を「自分の中に」コピーして、サイズを1つ減らしていました。

このような場合、配列-1に存在しないチケットを書き込み、すべての注文が終了するまで待ち、配列全体を削除します（配列のサイズを1に設定する必要があります）。

この方法では，チケットの配列の要素（順番がない場合）を，if(ArrayOfTicket[i] > 0) という一つの条件だけでチェックします．

常にアレイを "シェイクアウト "するよりも、より高速になります。

 
Igor Makanu:

その場合、配列-1に存在しないチケットを書き込み、すべての注文が終了するまで待ち、配列全体を削除します（配列サイズ＝1）。

この方法では，チケットの配列の要素（順番がない場合）を，if(ArrayOfTicket[i] > 0) という一つの条件だけでチェックします．

常にアレイを "シェイクアウト "するよりも、より高速になります。

意味がわからない...。要素ごとに削除するか、存在しない命令のインデックスをチェックするかで、何が変わるのか...とにかく配列は揺れます...。

とにかく、今日のニュースでも言っていましたが、フレーバーの特許は不可能なんです。フルーレは色が違うだけで、味はどれも同じです。

 
Alexey Viktorov:

意味がわからない...。項目を一つずつ削除するのも、存在しないオーダーのインデックスをチェックするのも、どっちも同じ...どうせ配列はオーバーランするんだし...。

とにかく、今日のニュースでも言っていましたが、フレーバーの特許は不可能なんです。フルーレは色が違うだけで、味はどれも同じです。

要素を削除すると配列の残りの要素をコピーしてしまうので、配列の要素は削除せず、存在しない要素（チケット）を値-1でマークし、成行注文がないときにチケットの配列を削除しています

フローテーションマーカーについては、確かに問題によって異なりますが、原理的には最適化の際に2つの解が存在するのが普通です。

- アルゴリズムが複雑になるが、PCのメモリや計算機資源を 節約できる。

- またはアルゴリズムを簡略化して計算資源を節約するが、メモリを浪費する

 

チェックサムが正しくありません。配列に0がある場合、エラーが発生する可能性があります。

Nikitinの変種は、まさにそのようなエラーに対して機能します。

ファイル:
456.mq5  20 kb
 
Vladimir Pastushak:

チェックサムが正しくありません。配列に0がある場合、エラーが発生する可能性があります。

Nikitinの変種は、このようなエラーに対してだけ機能します。

はい、おっしゃるとおりです。ニキーチンだけが、さらにゼロエレメントを投じた。だから、彼のコードはまるで欠陥があるかのように見えたのだ。実は、最初に設定した課題を解決していたんですね。
NULL要素のチェックを文書化しても、結果は同じです。

2018.11.14 13:50:34.481 ArrayDeleteValue (BTCUSD,M15)   вариант Pastushak: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 133765 микросекунд
2018.11.14 13:50:34.486 ArrayDeleteValue (BTCUSD,M15)   вариант Korotky:   Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2330 микросекунд
2018.11.14 13:50:34.489 ArrayDeleteValue (BTCUSD,M15)   вариант Fedoseev:  Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 1840 микросекунд
2018.11.14 13:50:34.492 ArrayDeleteValue (BTCUSD,M15)   вариант Semko:     Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 777 микросекунд
2018.11.14 13:50:34.497 ArrayDeleteValue (BTCUSD,M15)   вариант Pavlov:    Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2818 микросекунд
2018.11.14 13:50:34.503 ArrayDeleteValue (BTCUSD,M15)   вариант Nikitin:   Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 3922 микросекунд
2018.11.14 13:50:34.510 ArrayDeleteValue (BTCUSD,M15)   вариант Vladimir:  Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 4239 микросекунд
2018.11.14 13:50:34.519 ArrayDeleteValue (BTCUSD,M15)   вариант Peter:     Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 7307 микросекунд
2018.11.14 13:50:34.522 ArrayDeleteValue (BTCUSD,M15)   вариант Kuznetsov: Контрольная сумма = 7185.677992388435; элементов - 998993; время выполнения = 683 микросекунд

この場合も、チェックサムには要素の順番が考慮されるようになり、以前は考慮されなかった。

ファイル:
ArrayDeleteValue.mq5  18 kb
 
あ、忘れてください。ビールを飲み干すところです。大晦日までに～25リットル用意します。今のは、そういうことなんですね。
 
Nikolai Semko:

はい、おっしゃるとおりです。ニキーチンだけは、さらにヌルい要素も投げかけていた。だから、彼のコードがまるで間違っているように見えたのだ。実は、最初に設定した課題を解決していたんですね。
もし、彼がNULL項目をチェックすることを文書化しても、結果は同じである。

繰り返しになりますが、チェックサムには要素の順番が考慮されるようになり、以前は考慮されませんでした。

ちなみに、もし順番がとても重要なら、私のバリアントの最後にArraySortを追加して、ArraySortの効果が全くないことを確認することができます。

 

私は今、もう一つの質問に興味を持っているのですが、その答えが見つからないのです。
なぜ、Kuznetsovのコードからこのように変化したのか、誰か説明してくれるかもしれません。

    for(;;)
     {
      while(arr[i]!=x && i<j) i++;
      while(arr[j]==x && i<j) j--;
      if(i<j)
        {
         arr[i++]=arr[j--];
        }
      else break;
     }

は、まったく同じことをするこの製品の2倍以上の速さで動作します。

   while(i<j)
     {
      if(arr[i]==x)
         if(arr[j]!=x) arr[i++]=arr[j--];
      else j--;
      else i++;
     }

コンパイラのすばらしさとは？
このようなデザインに対して、可能なのでしょうか。

while(arr[i]!=x && i<j) i++;

コンパイラは、プロセッサに対応した特別なアセンブラのルックアップ・コマンドを見つけているのでしょうか？
モダンプロセッサーのコマンドに強い人はいますか？

 
Maxim Kuznetsov:

ちなみに、順番が非常に重要な場合は、私のバージョンの最後にArraySortを追加することができますが、同時にArraySortが全く効果的でないかを見てみましょう。

試してみました。かなりコストのかかる機能です。後から捨てるのは楽ですけどね。必要なものはすべて一列に並べます。

ニコライ・セムコ

はい、おっしゃるとおりです。ニキーチンだけが、さらにNULLアイテムを投げていた。だから、彼のコードがおかしく見えたのだ。実は、一番最初に決めた課題だったんですね。
もし、彼がNULL項目をチェックすることを文書化しても、結果は同じである。

ほとんどすべての機能を適応させることができます。これが私の最後の1枚です（純粋に実験的なものですが、最も安価なものの1つであるようです）。
template<typename T>
int arrayFilter(T &data[],const T value=NULL)
  {
     int s, _s = s = ArraySize(data);
     bool result = false;
     
     for(int i=0, j=0; i<_s; i++)
     {
          if( data[i] == value || data[i] == NULL )
          {
               result = true;
               s--;
               continue;
          }
          if( result )
               data[j] = data[i];
          j++;
     }
     
     if(s < _s)
          ArrayResize(data, s);
     
     return s;
  }
 
Nikolai Semko:

:

は、まったく同じことをするのに比べ、2倍以上の速さで動作します。


オプティマイザは関係ない。比較対象が半分になる...

1...5678910111213141516171819...30
新しいコメント