私のアプローチコアはエンジンです。 - ページ 84 1...777879808182838485868788899091...184 新しいコメント Nikolai Semko 2018.12.17 21:37 #831 Maxim Kuznetsov:そうそう、MQLでテキストをパースするのはとても楽しいですよ :-)まあ、テキストパース用に設計されたものではありませんからね。できるけど、残念なことに......。 配列と命令 - これがMQLのすべてだそういうことなんだ...。:) Реter Konow 2018.12.17 21:39 #832 Nikolai Semko:汎用性というのは、往々にして鈍重さと同義であり、文字列であればなおさらです。 一つ例を挙げましょう。以前、暗号取引所から受け取った文字列をWebRequestでパースしたことがあります。そして、「高速C++ライブラリ」から移植したSergeev氏のJSONライブラリを使って パースしています。そして、速度が非常に不満足であることに気づかされました。そこでは、すべてが「ユニバーサル」な文字列で行われていたのです。低速の原因は文字列だと理解し、文字列関数の使用を避けたいと思い、uchar配列から直接パースする関数を書きました。その結果、かなり驚きました。私の解析速度は...。(ドラムロール）800倍の速さです。JSONで文字列全体をパースするのに0.3秒かかるとしたら、私の関数は半分の1ミリ秒以下でパースしています。以下は、uchar配列でパースした例です。ご提案の骨子は以下の通りです。 文字列（640文字）を受け取り、StringToChar()関数に送ります。配列を取得し、リソースに格納します。ResourceReadImage()を用いて2つ目の側のリソースの内容を2つ目の配列に取得する。2番目の配列をCharArrayToString()に送り、最終的な文字列を取得します。次に、文字列をデリミタで分割し、パラメータ値をカーネルに書き込む。もともと、MTオブジェクトを使って文字列を転送したかったんです。 文字列（640文字）を、64文字ずつに分割する。通信オブジェクトのループを行い、その記述に文字列の部分を書き込んでいくのです。もう一方は、通信オブジェクトのループを行い、文字列の一部を取得し、各部をデリミタで分割して、パラメータ番号と値を抽出します。カーネルにパラメータ値を書き込む。最初は2つ目のバリエーションの方が速く感じました。 私のように多くの課題を抱えている場合、解決策を選択する際には直感に頼らざるを得ません。すべてを徹底的にチェックするには、寿命が足りなくなる。正しい方向を選択するためには、チームか、優れた直感が必要です。もちろん、プロ意識を犠牲にして、知識のギャップを我慢することも必要です。そうでなければ、（プロとはいえ）落書きをすることになり、メガプロジェクトを完成させることはできないでしょう。これが現実です。 Nikolai Semko 2018.12.17 21:43 #833 Реter Konow:ご提案の骨子は以下の通りです。 文字列(640文字)を受け取り、StringToChar()に送ります。配列を取得して、リソースに格納します。ResourceReadImage()を用いて2つ目の側のリソースの内容を2つ目の配列に取得する。2番目の配列をCharArrayToString()に送り、最終的な文字列を取得します。次に、文字列をセパレータで分割し、パラメータ値をカーネルに書き込む。 全然、こんなもんじゃない。 今、忙しいんです。説明する時間がないんです。 私のコードを 空白部分がないように細かく分解してみると、自分自身で多くの発見があるはずです。 ZS.ただ、デバッガがなければ、それを理解するのはもっと難しいでしょう。使い始めたのか、まだこの重要なツールを使っていないのか分かりませんが。 Реter Konow 2018.12.17 21:54 #834 Nikolai Semko:... 私のコードを 空白にせず詳細に調べれば、新しい発見がたくさんあるはずです。 ZS.ただ、デバッガを使わないと、もっとわかりにくいですね。使い始めたのか、まだこの重要なツールを使っていないのか分かりませんが。明日、あなたのコードを詳しく見てみるわ。(タイムゾーンをお忘れなく）。 もしかしたら、本当に、新しい発見があるかもしれません。)) Алексей Тарабанов 2018.12.17 22:11 #835 構造体はすべて文字列である。構造体の配列は、その形式を記述した文字列の配列である。クラス - 構造とメソッド、クラスの実装 - 実装の配列（フランス語で失礼）。 最後の瞬間まで変換する必要はありません。どこにでも糸が絡んでいるだけです。単純に、2バイト、4バイトのものもあれば、1バイトのものもあるので、アライメントをとる必要がある、という正規化です。 私が初めてこの方法を使ったのは、1993年頃のClarion DBMSです。とても早く効果が出ました。 Maxim Kuznetsov 2018.12.17 22:24 #836 Алексей Тарабанов:構造体はすべて文字列である。構造体の配列は、その形式を記述した文字列の配列である。クラス - 構造とメソッド、クラスの実装 - 実装の配列（フランス語で失礼）。 最後の瞬間まで変換する必要はありません。どこにでも糸が絡んでいるだけです。単純に、2バイト、4バイトのものもあれば、1バイトのものもあるので、アライメントをとる必要がある、という正規化です。 私が初めてこの方法を使ったのは、1993年頃のClarion DBMS です。すべてにおいて、非常に迅速に作業が進みました。ほぼ同時期に同じものを:-)ある学校...ちなみにDBMSは悪くなく、いろいろな意味で時代を先取りしていた。 PS/「すべてが文字列/テキスト」というコンセプトレベルの後付けで、時に熱く愛されるチカラがあるんです。スピードは本当にpythonのレベルです。 Nikolai Semko 2018.12.17 23:50 #837 Реter Konow:明日、あなたのコードを詳しく見てみるわ。(タイムゾーンをお忘れなく）。 もしかしたら、本当に新しい発見があるかもしれない。))役に立つかもしれない ダブル例でリソース変数を使用し、TF変更時に値を再初期化しないインジケータの例です。ターミナルのグローバル変数 に代わる、より便利な機能です。同様に、異なるデータ構造およびその配列もグローバルなものとして使用することができます。 ファイル: Variable.mqh 7 kb TestResVar.mq5 3 kb Алексей Тарабанов 2018.12.18 00:04 #838 Nikolai Semko:まだ使えるかもしれません。) Vasiliy Sokolov 2018.12.18 08:44 #839 Реter Konow: 興味本位で、unionを使ったバリアントを試してみることにします。また、CharArrayToStringとStringToCharArrayで。直感的には、МТオブジェクトの記述によるコミュニケーションより速いとは思えないのですが。しかし、私は間違っているかもしれない。えーと...ピーター 最初からワイルドカードを作っておいて、そのワイルドカードの中でメッセージング性能について議論しているんですね。文字列はただの便利な○○であって、それ以上ではないのだ。どんなデータも、実際はメモリ上のバイトの集まりに過ぎない。だからバイトを直接扱えということなのだが、同じ文字列が同じバイト配列であることを理解していないのは、相変わらず頑固だ。そのため、文字列からuchar配列への変換では何も失われませんが、文字列をパースする際にパフォーマンスが著しく低下します。だから、直感がすべて欠落しているだけなのです。 Реter Konow 2018.12.18 09:16 #840 Vasiliy Sokolov:1.Peterさん、あなたはもともとゲームをやっていて、今、ゲーム内のメッセージングパフォーマンスについて議論していますね。 2.わかるか：文字列はただの便利な○○であり、それ以上のものではありません。どんなデータも、実際はメモリ上のバイトの集まりに過ぎない。だから、バイトを直接扱うようにとアドバイスされるのですが、同じ文字列が同じバイト配列であることを理解できないのは、相変わらず頑固なんですね。そのため、文字列からuchar配列への変換では何も失われません。 しかし、文字列をパースする際には、パフォーマンスが大きく低下してしまいます。 3.だから、あなたの直感はすべて外れただけなのです。 1."ワイルドネス" - この場合、あなたの理解であって、私がしたことではありません。何のためのエンジンなのか、75ページで 理解できましたね。理解する：欠陥やエラーは、実体を特徴づける ものではない。 エッセンスの形がエッセンスそのものを特徴づけることはない。服装でその人がどんな人なのかが決まらないのと同じように。全体を特定で判断するのは、間違った考え方だけです。 2.そのままでもわかりやすい。StringToChar関数を使って、本当に速度が上がるのか、今日確認してみます。 3.毎日、自分の直感を確認する。毎日、疑っています。そして、当然ながら、その通りです。もし失敗したら、Reasonに導かれるはずです。しかし、理性はあまりにも限定的で、傲慢で、愚かなので、いつも頼りにしているわけではありません。だから、直感が唯一の選択肢なのです。もし、私の言っていることがわかるなら... 1...777879808182838485868788899091...184 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そうそう、MQLでテキストをパースするのはとても楽しいですよ :-)まあ、テキストパース用に設計されたものではありませんからね。できるけど、残念なことに......。
配列と命令 - これがMQLのすべてだ
そういうことなんだ...。:)
汎用性というのは、往々にして鈍重さと同義であり、文字列であればなおさらです。
一つ例を挙げましょう。
以前、暗号取引所から受け取った文字列をWebRequestでパースしたことがあります。そして、「高速C++ライブラリ」から移植したSergeev氏のJSONライブラリを使って パースしています。そして、速度が非常に不満足であることに気づかされました。そこでは、すべてが「ユニバーサル」な文字列で行われていたのです。
低速の原因は文字列だと理解し、文字列関数の使用を避けたいと思い、uchar配列から直接パースする関数を書きました。その結果、かなり驚きました。私の解析速度は...。(ドラムロール）800倍の速さです。JSONで文字列全体をパースするのに0.3秒かかるとしたら、私の関数は半分の1ミリ秒以下でパースしています。
以下は、uchar配列でパースした例です。
ご提案の骨子は以下の通りです。
もともと、MTオブジェクトを使って文字列を転送したかったんです。
最初は2つ目のバリエーションの方が速く感じました。
私のように多くの課題を抱えている場合、解決策を選択する際には直感に頼らざるを得ません。すべてを徹底的にチェックするには、寿命が足りなくなる。正しい方向を選択するためには、チームか、優れた直感が必要です。もちろん、プロ意識を犠牲にして、知識のギャップを我慢することも必要です。そうでなければ、（プロとはいえ）落書きをすることになり、メガプロジェクトを完成させることはできないでしょう。これが現実です。
ご提案の骨子は以下の通りです。
全然、こんなもんじゃない。
今、忙しいんです。説明する時間がないんです。
私のコードを 空白部分がないように細かく分解してみると、自分自身で多くの発見があるはずです。
ZS.ただ、デバッガがなければ、それを理解するのはもっと難しいでしょう。使い始めたのか、まだこの重要なツールを使っていないのか分かりませんが。
...
私のコードを 空白にせず詳細に調べれば、新しい発見がたくさんあるはずです。
ZS.ただ、デバッガを使わないと、もっとわかりにくいですね。使い始めたのか、まだこの重要なツールを使っていないのか分かりませんが。
明日、あなたのコードを詳しく見てみるわ。(タイムゾーンをお忘れなく）。
もしかしたら、本当に、新しい発見があるかもしれません。))
構造体はすべて文字列である。構造体の配列は、その形式を記述した文字列の配列である。クラス - 構造とメソッド、クラスの実装 - 実装の配列（フランス語で失礼）。
最後の瞬間まで変換する必要はありません。どこにでも糸が絡んでいるだけです。単純に、2バイト、4バイトのものもあれば、1バイトのものもあるので、アライメントをとる必要がある、という正規化です。
私が初めてこの方法を使ったのは、1993年頃のClarion DBMSです。とても早く効果が出ました。
構造体はすべて文字列である。構造体の配列は、その形式を記述した文字列の配列である。クラス - 構造とメソッド、クラスの実装 - 実装の配列（フランス語で失礼）。
最後の瞬間まで変換する必要はありません。どこにでも糸が絡んでいるだけです。単純に、2バイト、4バイトのものもあれば、1バイトのものもあるので、アライメントをとる必要がある、という正規化です。
私が初めてこの方法を使ったのは、1993年頃のClarion DBMS です。すべてにおいて、非常に迅速に作業が進みました。
ほぼ同時期に同じものを:-)ある学校...ちなみにDBMSは悪くなく、いろいろな意味で時代を先取りしていた。
PS/「すべてが文字列/テキスト」というコンセプトレベルの後付けで、時に熱く愛されるチカラがあるんです。スピードは本当にpythonのレベルです。
明日、あなたのコードを詳しく見てみるわ。(タイムゾーンをお忘れなく）。
もしかしたら、本当に新しい発見があるかもしれない。))
役に立つかもしれない
ダブル例でリソース変数を使用し、TF変更時に値を再初期化しないインジケータの例です。ターミナルのグローバル変数 に代わる、より便利な機能です。同様に、異なるデータ構造およびその配列もグローバルなものとして使用することができます。
まだ使えるかもしれません。
)
興味本位で、unionを使ったバリアントを試してみることにします。また、CharArrayToStringとStringToCharArrayで。直感的には、МТオブジェクトの記述によるコミュニケーションより速いとは思えないのですが。しかし、私は間違っているかもしれない。えーと...
ピーター 最初からワイルドカードを作っておいて、そのワイルドカードの中でメッセージング性能について議論しているんですね。文字列はただの便利な○○であって、それ以上ではないのだ。どんなデータも、実際はメモリ上のバイトの集まりに過ぎない。だからバイトを直接扱えということなのだが、同じ文字列が同じバイト配列であることを理解していないのは、相変わらず頑固だ。そのため、文字列からuchar配列への変換では何も失われませんが、文字列をパースする際にパフォーマンスが著しく低下します。だから、直感がすべて欠落しているだけなのです。
1.Peterさん、あなたはもともとゲームをやっていて、今、ゲーム内のメッセージングパフォーマンスについて議論していますね。
2.わかるか：文字列はただの便利な○○であり、それ以上のものではありません。どんなデータも、実際はメモリ上のバイトの集まりに過ぎない。だから、バイトを直接扱うようにとアドバイスされるのですが、同じ文字列が同じバイト配列であることを理解できないのは、相変わらず頑固なんですね。そのため、文字列からuchar配列への変換では何も失われません。 しかし、文字列をパースする際には、パフォーマンスが大きく低下してしまいます。
3.だから、あなたの直感はすべて外れただけなのです。
1."ワイルドネス" - この場合、あなたの理解であって、私がしたことではありません。何のためのエンジンなのか、75ページで 理解できましたね。理解する：欠陥やエラーは、実体を特徴づける ものではない。 エッセンスの形がエッセンスそのものを特徴づけることはない。服装でその人がどんな人なのかが決まらないのと同じように。全体を特定で判断するのは、間違った考え方だけです。
2.そのままでもわかりやすい。StringToChar関数を使って、本当に速度が上がるのか、今日確認してみます。
3.毎日、自分の直感を確認する。毎日、疑っています。そして、当然ながら、その通りです。もし失敗したら、Reasonに導かれるはずです。しかし、理性はあまりにも限定的で、傲慢で、愚かなので、いつも頼りにしているわけではありません。だから、直感が唯一の選択肢なのです。もし、私の言っていることがわかるなら...