アルゴリズム、解法、性能比較 - ページ 15

新しいコメント
 
fxsaber:

地域社会に対する無礼な行為を繰り返し、挑発するパターンが明らかである。

それを（様々な建設的なスレッドにおけるその人の書き込みを）読まないというのは、発展して忘れるというのは、必ずしもそうではありません - さらにそうではありません。

ヘルプの手にトローリングとスピッティング、その数はこのリソースをプラス面と大きく差別化する。


間違っているかもしれない。

感情を制御してください。他人の意見を受け入れない場合は、議論に参加しないという選択肢もあります。誰も強制はしていません。

 
Vladimir Karputov:

訂正しますが、文字列の長さは 有限ではありませんか？

https://msdn.microsoft.com/ru-ru/library/sx08afx2.aspx

MQL5ではこの制限が見当たらないのですが...。

文字列は基本的にuchar配列で、自動的な再分割など独自の特殊機能を持つ。そのため、少なくとも明示的に文字列の長さが制限されることはありませんし、配列のサイズも制限されることはありません。ERR_STRING_RESIZE_ERROR (Insufficient memory to reallocate string) のような特定のエラーコードが示すように、非常に長い文字列はメモリ不足になる可能性があります。


 
Vasiliy Sokolov:

文字列は基本的にuchar配列であり、自動的な再分割などの利点がある。したがって、少なくとも明示的に文字列の長さが制限されることはなく、配列のサイズも制限されません。ERR_STRING_RESIZE_ERROR (Insufficient memory to reallocate string) のような特定のエラーコードが示すように、非常に長い文字列はメモリ不足になる可能性があります。


私にとっても貴重な情報です。ありがとうございます。
 
fxsaber:

メモリ制限のみ

INT_MAX の次に明らかに長さの制限がある。
 
Реter Konow:

1. つまり、アルゴリズムの速度は重要ではありません。解決策は「発想力」、それで十分です。オッケーです。

2.プラグイン経由で接続して終わりなんですね。オッケーです。

//--------------------------------------------------------------------

アルゴリズムを評価する主な基準が「コンセプトが しっかりしていること」だとしたら、私の負けです。

アルゴリズムの主な判断基準である「シンプルさ」「スピード」「利便性」が高ければ、私の勝ちです。

この時点で話題を終了することができます。


文字列を同じ大きさの2つのint[]に置き換えて、一方にトランザクションの数を格納し、もう一方にマジックを格納して、トランザクションの配列の対応する検索でマジックの必要なインデックスを探せば、まだ「あなたのアルゴリズム」を高速化し簡素化できます（それについて常に言われます）。より速くなります。もちろん、これはあなたの例から導かれる特殊なケースです。

ピーターは配列を学び、それが普遍的で強力なツールであることを理解し、次に文字列を学び始めました...彼が構造について学ぶとき、何が起こるか想像できますか？）

ピョートルは、これらの関数を例に代用した。

struct SDealMagic {int deal,magic;} array[];
//
void Trading()
{
   Random_orders_of_strategy=MathRand();
   ArrayResize(array,Random_orders_of_strategy);
   for(int i=0; i<Random_orders_of_strategy; i++)
   {
      array[i].deal=i;
      array[i].magic=MathRand()
   }
}
//
int Get_magic(int deal_number)
{
   for(int i=0; i<Random_orders_of_strategy; i++)
      if(array[i].deal==deal_number) return(array[i].magic);
   return(-1);
}

そして、スピードはパターンを取る :)

 
Реter Konow:

1. つまり、アルゴリズムの速度は重要ではありません。解決策は「発想力」、それで十分です。オッケーです。

2.プラグイン経由で接続して終わりなんですね。オッケーです。

//--------------------------------------------------------------------

アルゴリズムを評価する主な基準が「コンセプトが しっかりしていること」だとしたら、私の負けです。

アルゴリズムの評価基準である「シンプルさ、スピード、利便 性」がメインであれば、私の勝ちです。

この時点で、このテーマを終了することができます。


ちょうど例は、最も一般的なを示しています - それは、余分な情報の多くは、少なくともデバッグハンドラと印刷上の定義が存在しない - またはそれ以外の場合は、別の300行を追加しているであろう。

少なくとも、コード全体は完全に...。

ライブラリを通してコードを追加し、呼び出す必要がある部分は、より便利で、より少ないコードで、より読みやすくなります。

 
Alexandr Andreev:

ティッカーにマジックを付属させる場合-保存しておけば、便利な形でティッカーやマジックに送れるはずです。

実際、構造体にすべての情報を格納することが最速の解決策となる。ただし、アクセスは順序付けられた参照インデックスsammivaを介して 行われます。

これは真正面から解決するため、最短距離ではありません。HashMapで行うのがよいでしょう。しかし、現在の実装では構造体は必要なく、あるインターフェイスを継承したクラスで、そのオーダーのフィールドを記述することになる。

 
Yury Kulikov:

文字列を同じ大きさの2つのint[]に置き換えて、一方にトランザクション番号を、もう一方にmagikを格納し、トランザクションの配列の対応する列挙によってmagikの必要なインデックスを検索すれば、「あなたのアルゴリズム」（と彼らはあなたに言い続けている）は高速化・単純化できるのです。より高速になります。もちろん、これはあなたの例から導かれる特殊なケースです。


これは興味深く、有用な提案です。並行記録の維持他の解答でもやりました。

ただ、EAが最初に出す注文の 数がわからないということです。int配列のサイズはどのように設定すればよいのでしょうか？

そのため、文字列を使うことにしたのです。

 
fxsaber:

これは真正面から解決するため、最短距離ではありません。HashMapで行うのがよいでしょう。しかし、現在の実装では、構造体ではなく、あるインターフェースを継承したクラスで、そのオーダーのフィールドを記述する必要があります。


Genericファイルが見つからないのですが、古いビルドのよう です。では、ナビゲーションの原理はどのように提供されるのでしょうか。ソースコードはどうなっているのでしょうか。

 
Реter Konow:

面白く、スマートな提案だと思います。並行記録の維持他のソリューションでもやっています。

ただ、Expert Advisorが発注 する注文の数は不明です。int配列のサイズはどのように設定すればよいのでしょうか？

そこで、紐を取ることにしました。

Peterさん、ArrayResize()という素晴らしい関数があるんですよ。プログラム実行の瞬間に配列のサイズを大きくすることができます。

1...891011121314151617181920212223
新しいコメント