FAQ（よくある質問）を埋めるためのサブワークショップ。同志を助けよう! - ページ 14

新しいコメント
 
TheXpert:
そして、正しいのは、常に最新の情報を端末に問い合わせることだと思います。 。

注文の状態（配列）は、処理が必要な時に正確に照会される。

別になくてもいいし、事前にマシューを用意する必要もない、というのが私の主張です。また、OrderSelect後のオンデマンドオーダーの状態を即座に分析し、マジシャンやシンボルなどで不要なものをフィルタリングします。

しかし、チケットの配列はUGであると主張していますね。その理由を説明してください。

-------------

Tarasは、注文に関するすべての情報を配列に書き込む "ultra "オプションを提案しました。これだけの情報は必要ない、という立場でしか賛同できない。そして簡易版では、ほとんどの場合、チケットだけが必要です。

 
TheXpert:
私はお勧めしません。チケットの配列は全く必要ないことの方が多い。そして、正しいことは、可能な限り最新の情報を常に端末に問い合わせることだと思います。
配列では、条件付きで1刻みで生きている情報を得ることができます。これ以上「新鮮」な情報はないでしょう？私は、多通貨のアカウント（デモのことです）を2-4個持っていて、「余計なことでサーバーを邪魔する」ことを許さない場合に、自分なりに工夫して使っています。

そして一般的には、これはあなたや私の個人的な見解です。そして、ユーザーには常に、どちらの主張がより理にかなっているか--を選ぶ権利が与えられていなければなりません。;)

P.S.そして、FAQで出された質問に対して、私は自分の答えを出しただけです。:)

 

OK、IMHO UGは最新のオーダー情報を持つことが正しいので。そしてIMHOは、95％の時間、オーダーの配列はなくても大丈夫だと考えています。

私は自分の意見を言っただけです。

 

こう言ってはどうだろう。

- 利便性とモデルの抽象化という点では、配列を使うのがよいでしょう。
- 作業のスピードアップのために-アレイを使わないで

情報の関連 性は関係ない。アレイの有無にかかわらず、関連性は100％ です。

 
sergeev:

-------------

Tarasは、注文に関するすべての情報を配列に書き込む「ultra」オプションを提案しました。これだけの情報が必要ないという立場でしか賛成できない。 そして、簡易型バリエーションでは、ほとんどの場合、チケットだけが必要です。

Alexey！私はFAQでこの質問を紹介することによって（「自分の」注文のチケットの配列を取得する）、あなたは「すべてのこれらの情報は必要ないという立場」について意味すると考えることから遠いです - 周りを再生するように！？
それとも何か誤解があったのでしょうか？
 
TarasBY:
アレクセイ！私は、FAQにこの質問を導入することによって（「自分の」注文のチケットの配列を取得する）、あなたは「すべてのこれらの情報は必要ないという立場」を意味すると考えることから遠いです - と遊ぶように！私は、「自分の」注文のチケットの配列を取得することによって、あなたは「すべてのこれらの情報は必要ないという立場」を意味します。それとも何か勘違いしていたのでしょうか？


なぜか、チケットの他に「自分のチケット」という概念で、すべてのプロパティを含んでいますね。

しかし、「ジャスト・チケット」機能の延長線上に、あなたの提案があることは間違いありません。

特に過去の 注文データを 分析・比較する際にも、頻繁にニーズがあります。

 
sergeev:


こう言ってはどうだろう。

- 利便性とモデルの抽象化という点では、配列を使うのがよいでしょう。
- 作業のスピードアップのために-アレイを使わないで

情報の関連 性は関係ない。アレイの有無にかかわらず、関連性は100％ です。

2つ目（「作業のスピードアップのために～配列なしで～」）については、あまり性急なことはしないほうがいいと思います。
単純に考えれば、「新鮮な情報」を得るためにサーバーに余計にアクセスすれば、余計な時間がかかるということです。また、同じ情報を配列から取り出すのとは時間的に勝負にならない。
コードスピードの専門家であるVictor（Vinin）氏の意見は興味深いですね。
 
TarasBY:
2つ目の「作業のスピードアップのための配列がない」については、あまり急いで断定することはないでしょう。単純に考えれば、「新鮮な情報」を得るためにサーバーに余計にアクセスすれば、余計な時間がかかるということです。また、同じ情報を配列から取り出すのとは時間的に勝負にならない。コードパフォーマンスの専門家であるVictor（Vinin）がいるので、彼の意見も面白いかもしれません！



もう一度言いますが、オーダープロパティで 作業する場合、コンタクトするサーバーはありません

取引において、最も重要なルールは関連性です（TheXpertが書いていたUGにならないように）。
そのため、各関数でオーダーリストを参照し、新たに配列を作成すると、確実に速度低下の原因となります。アレイフィルが発生します。

そのため、配列の実写化とOrdeSelectの繰り返し（すでにチケットに記載されています）のコストを削減することができます。

1～2台の作業オーダーなら配列は重要ではありませんが、50～100台となると、もう相当なものです。

 
先に述べた「サーバー負荷の軽減」（正確には「コードスピードの最適化」）というコンセプトに基づいて、Start()の冒頭で（複数のツールで必要な場合は）価格をすべて別の配列で取得することにしています。そして、取引 操作が必要な場合は、RefreshRates()を行っています。
。

私はこの方法を誰かに押し付けているわけではなく、その背後にある合理性を理解し、自分のデザインにこの原則を利用しているだけです。

P.S. この話題で論争を始めるつもりはなく、単に上記に対する反論です。

 
sergeev:

そのため、各関数でオーダーリストを参照し、新たに配列を作り直すと、間違いなく速度低下につながる。配列充填のため。

そんなこと言ったっけ？EAが毎ティックで 動作している場合、tickの配列は毎ティックごとに満たされます。そして、通常のサンプリングではなく、
。 
    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }

から選択します。 
for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

または、
    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
この機能があれば、もっと快適になるのにと思うことがあります。
このアプローチの合理性は、少数派である多通貨システムにおいて顕著であることは認めざるを得ません。
1...789101112131415161718192021...24
新しいコメント