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

新しいコメント
 
Anton:

端末で提供されます。

はい、そうです。

Antonは、MAX_BARSパラメータに関係なく、すべてのM1（M1のみ）をキャッシュやディスクへのデータ保存なしで取得する別の関数が非常に不足しています。これにより、プログラマーは独自のヒストリカルデータ構造を 形成する新しい機会を得ることができる。
MAX_BARS != Unlimited の場合、すべてのティックにアクセスされますが、M1 はアクセスされません。すべてのティックがM1の全歴史をカバーしていれば問題は発生しないのですが、そうではありません。
 
Nikolai Semko:
Antonは、MAX_BARSパラメータに関係なく、すべてのM1（M1のみ）をキャッシュやディスクへのデータ保存なしで取得する別の関数が本当に不足しています。これにより、プログラマーは独自の履歴データの構造を 形成する新しい可能性を手に入れることができる。
MAX_BARS != Unlimited の場合、すべてのティックにアクセスされますが、M1 はアクセスされません。すべてのティックがM1の歴史をすべて網羅していれば問題は生じないのですが、そうではありません。

どれだけのユーザーやプログラマーがこれを使うかは未知数だが。- 端末の設定でUnlimited chartのプロパティをONにし

今のところ、「新しいプラスを作らないなら、開発者が来てアンリミテッド設定をオンにしてくれ」という感じです。

 
Igor Makanu:

あとは、どれだけのユーザーやプログラマーが使ってくれるのか？- 端末の設定でUnlimited chartのプロパティをONにし

今のところ、「新しいぬいぐるみを作らないなら、開発者が来てアンリミテッド設定をONにしてくれ」という感じです。

無制限は、端末全体では非常に高価なオプション です。すぐにディスク容量とトラフィックの消費量が巨大に増加します。しかし、1つのツールに1回だけアンリミテッドが必要だとしたら？
私のヒストリカルデータファイルは、通常のものと比べてディスク容量が5倍少なく、同時に情報量も多く、高値・安値の時間やすでに計算済みのTFが含まれているので、その場で毎回計算する必要がないからです。
こ のようなライブラリをBEで公開すれば、多くのプログラマがその有効性を見て使い始めたり、似たようなものを作ったりすると、イゴールさん、私は断 言しますよ。
また、マーケットプレイスの商品であれば？
このアンリミテッドを 有効にするよう、全員にお願いしなければならないのでしょうか？そうすることで、トラフィックやディスク容量に非常に大きな 負担をかけることになると分かっているのに。

私の要求は完全に適切であり、すべてがすでにそのまま存在するため、実装に多くのリソースを必要としないと考えています。10～15分程度のことです。
 結局のところ、max_bars = 1000でW1バーを1000本要求した場合、とにかくM1ヒストリー全体がロードされ、W1はすでにそこから計算されていますが、M1だけはファイルに保存されません。

 
Nikolai Semko:

なぜなら、max_bars = 1000で、W1バーを1000本要求した場合、M1の履歴はすべて読み込まれ、W1はすでにそこから計算されていますが、M1だけがファイルに保存されないからです。

どうですか？ロードされたが、保存されていない？

 
Andrey Khatimlianskii:

どうですか？ロードされたが、保存されていない？


プログラムやユーザがTF選択で要求したTFのうち、max_bars以上のものはディスクに保存されない。
1000 bars W1は約20年分のデータ、つまりM1のほぼ全履歴が読み込まれることになる。
アンドレイは、私の言葉を確認してください。マーケット概要で新しいシンボルを開き、そのウィンドウを開いて、すぐに月足TFをオンにします。そして、データのダウンロードの速さもおわかりいただけると思います。
でも、...MetaQuotesTerminalにある小さなファイルが見えるはずだ。
そして、面白いことに、hccファイルはすべての年数にわたって生成され、すでに半分のギガバイトまで重くなるのです。
だから、あなたもダウンロードする必要はありません。
また、MqlRates構造 体のサイズ=60バイトから判断すると、hccファイルは全くパックされていません。非常にもったいない

HZがより注意深く実験したところ、任意の期間のデータを要求した場合、その期間のデータはhccファイル（分バー）に保存され、データは端末シャットダウン時にのみRAMからキャッシュカタログに解凍されることがわかった。
つまり、タイムフレームはメモリ上で形成・計算され、端末シャットダウン時にファイルキャッシュに保存されるのである。それは、実は論理的なことなのです。hccファイルを解凍した状態で保管し、プログラマーがアクセスできるようにしないのは非論理的としか言いようがない。

 
Nikolai Semko:

まあ、待たされるなら待たされるで、開発者が納得してくれればいいのですが......。までお待ちください。演算子のオーバーロードについて質問したら、管理者に不要な機能だと言われ、それから5年間MQLを扱っていなかったのに、今ではすべてがここにあるのです。))))

 
Igor Makanu:

まあ、待たされるなら待たされるで、開発者が納得してくれればいいのですが......。までお待ちください。演算子のオーバーロードについて質問したら、管理者に不要な機能だと言われ、それから5年間MQLを扱っていなかったのに、今ではすべてがここにあるのです。))))

そう、それは悲しい光景です。私もそう思います。
その理由は、先ほども言ったように、マニュアルによる管理 である。

 
Anton:

端末で提供されます。

はい、そうです。

Nikolai Semko:
Anton、とても足りないのは、MAX_BARSパラメータに関係なく、すべてのM1（M1のみ）をキャッシュやディスクへのデータ保存なしに取得する別の関数です。これにより、プログラマーは独自の履歴データの構造を 形成する新しい可能性を手に入れることができる。
MAX_BARS != Unlimited の場合、すべてのティックにアクセスされますが、M1 はアクセスされません。すべてのティックがM1の歴史をすべて網羅していれば問題は生じないのですが、そうではありません。


hccファイルにある（ダウンロードされた）既存のM1バーにプログラム的にアクセスできるようにする。
もし、max_barsを超える分単位のバーが必要なら、MNまたはW1バーのダウンロードを開始するだけで、必要なhccファイルがすでに生成されていることを確認できます。

 
つまり、社内の制約を回避する能力を内在させたいのか？)
 
Andrei Trukhanovich:
つまり、固有の制限を回避するための固有の能力が欲しいということですか？)
制限ではありません。
制限する意味がない。
セキュリティには影響ありません。また、何らかのリソースに影響を与えるわけでもなく、逆にプログラマーにとってはリソースを節約するチャンスでもある。
これは単純な非論理主義であり、私はこれを正すことを提案する。
データはあるが、アクセスできない。

1...302930303031303230333034303530363037303830393040304130423043...3185
新しいコメント