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

新しいコメント
 
Roman:

おそらく、このノートに

そうそう、それならディスクの過負荷を心配する必要はありませんね。
私が驚いたのは、大きなデータセットの保存にターミナルのグローバル変数（そういうものであれば）を使っていることです。
気持ち悪い松葉杖ですよね。

さて、変数自体が、また格納する必要があり、まだこの変数へのアクセスのための文字列検索を行うたびに、唯一のタイプdoubleはもちろんのこと、格納することができます彼らの文字列の名前が、そこにある。確かに、ユニオンは使えますが、使うのはタダではありません。

ディスクへの自動保存やdeinitイベント発生時に、データアレイのリソースを通じて独立に保存する実装の方が、より正しい。

 
Nikolai Semko:

変数そのものはいいのですが、文字列名があり、これも保存しなければならず、なおかつこの変数にアクセスするために文字列検索を毎回行わなければならず、保存できるのはdouble型だけなのは言うまでもありません。組合を利用できることは明らかですが、その利用もタダではありません。

グローバル変数を使いたいというアイデアと願望はありましたが、特に今、ちゃんとコードを書き始めたので、昔の方法でディスクに保存することにしました - データは構造体に保存され、ワンクリックでディスクに構造体をダンプできます - FileWriteStruct().



だから、グローバル変数は、 "正確に他の方法を使用する必要があります" - データは、グローバル変数名に格納する必要があります。そして、Base64とダブルでチェックサム - すべてがCryptEncode（）の準備ができて、理想的にはBase85（Ascii85）でなければなりませんまたはgithab Base128でどこかソースコードを見て

Base64の効率は60%強（サイズ）、他のコーディング方法はもっと効率が良い - 1つのグローバル 変数に160-180バイトを格納することができる

プレフィックスを使用してデータを決定する必要がありますが、一般的には動作します - グローバル変数はほとんど使用されないのでなおさらです - すべての名前は基本的に自由です

 
Igor Makanu:

私はグローバル変数を使いたいというアイデアと願望を持っていましたが、特に今、コードをできるだけ正しく書くようになったので、昔の方法でディスクに保存することにしました - 私はデータを構造体に保存し、ワンクリックで構造体をディスクにダンプできます - FileWriteStruct().



だから、グローバル変数は、 "正確に他の方法を使用する必要があります" - データは、グローバル変数名に格納する必要があります。そして、Base64とダブルでチェックサム - すべてがCryptEncode（）の準備ができて、理想的にはBase85（Ascii85）でなければなりませんまたはgithab Base128上のどこかソースコードを見て

Base64の効率は60%強（サイズ）、他のコーディング方法はもっと効率が良い - 1つのグローバル 変数に160-180バイトを格納することができる

プレフィックスを使用してデータを決定する必要がありますが、一般的に、それはすべて動作します - より多くのように、グローバル変数はほとんど使用されていない - すべての名前は基本的に自由である。

それでも、ある変数にアクセスするためには、正しいものを見つけるまでチェックサムを調べなければならない。変数が多い場合はどうするか？
また、変数の並びを追跡し、インデックスを割り当てることもできます。しかし、これでは全く意味がない。なぜなら、データを保存するためのクラスを書く方が簡単だからだ
 
Nikolai Semko:
データ保存クラスを書く方が簡単

クラスは例題を含めてレイアウトされています。開発者は、リソースの周りにラッパーを書くことなく、すでにデータを転送することができる新しい機能を紹介します。

フラグにはグローバル変数 が使用されます。また、その値を常に確認できるのも便利です - F3.

 
fxsaber:

クラスは例題を含めてレイアウトされています。開発者は、リソースの周りにラッパーを書くことなく、すでにデータを転送することができる新しい機能を紹介します。

フラグにはグローバル変数 が使用されます。また、その値を常に確認できるのも便利です - F3.

はい、そうです。だから、びっくりしたんです。
価値観のコントロールには賛成、ではジャストフィット。
 
Georgiy Merts:

ビジュアルテストモードでは、SymbolInfoTick()は 1つの値を返しますが、Close[0]の時系列は異なる値を持っていることがわかりました。

私の勘違いでしょうか？私は何か間違ったことをしているのでしょうか？

同じ値であるべきだと思われます。

通常は1〜2ポイントの差ですが、鋭い動きではそれ以上になることもあります。

私だけでしょうか？

今のところ、時系列を「より正しい」としていますが、SymbolInfoTick()がClose[0]と異なる値を返すことが判明したら、正しい値はClose[0]だと仮定し、SymbolInfoTick()が返したままのスプレッドにしておくことにしています。

しかし、どの価格が正しいのか、DC - SymbolInfoTick() や Close[0] でどの価格が "Look" されているのかを理解するのは興味深いことです。

ビルドナンバーは何ですか？

Build 2155はもう修正されているはずです - このバグは先週修正されました。

 
Slava:

ビルドナンバーは？

Build 2155はもう修正されているはずです - 先週、そのバグを修正しました。

そうですね。そして、私は2085を持っています。

了解しました、更新中です。

P.S. そう、今の価値観は同じです。
 
Slava:

ビルドナンバーは何ですか？

Build 2155はもう修正されているはずです - このバグは先週修正されました。

何かご存知ですか？
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021
 
Aleksei Beliakov:
何かご存知ですか？
https://www.mql5.com/ru/forum/1111/page2571#comment_13285021

再現するための詳細が示されていない

 
Slava:

再生するための詳細な情報はありません

これらの関数の結果をontickで表示するとバナル、それは時間1970.01.01価格0のためのものです。
昔はバータイムやプライスタイムだったんですけどね。
だから、今はそうなっている。
iHigh(NULL,PERIOD_W1,0) в журнале будет 0
iTime(NULL,PERIOD_W1,0) в журнале будет 1970.01.01
1...256625672568256925702571257225732574257525762577257825792580...3185
新しいコメント