"ダミー "からの質問 - ページ 125 1...118119120121122123124125126127128129130131132...277 新しいコメント Renat Fatkhullin 2012.04.02 15:02 #1241 MetaDriver:ああ、今わかったよ。Renat、私は長い間提案をしてきましたが、まさにその通りです。 少なくとも静的配列には名前付き型付けをしてください(他のすべての型にはすでにあります)。例えば、typedef Int8 = int[8]; と宣言することが可能です。 構造物を通して簡単に行うことができます。こじつけは一切しません。struct Int8 { int arr[8]; }; Vladimir Gomonov 2012.04.02 15:52 #1242 Renat:これは、構造物によって簡単に実現できる。複雑に考えすぎないようにしよう。いいぞ、簡単だ、それでいいんだ! でも、何が必要なんだ?簡単な ことですか?あなたのカミソリ「 オカム」と、私たち(ユーザー)のカミソリ「 オカム」は、まったく別のカミソリだと思いませんか?あなたの ミニマリズムは、ユーザーに 余剰を生み出しがちなので、そろそろオカムを近くのフェンスに吊るしておく必要がありそうですね。そんなにシンプルさが大事なら、通常のサブアレイを関数に渡せるようにしてください! みんながハッピーになるし、ミニマリストもハッピーになりますよ。// ちなみに、F4でも問題なく動作します - ダイナミックなものでも。:) Yedelkin 2012.04.02 15:56 #1243 Renat: もちろん、静止画です。 さて、これでよしとしましょう。チェックするのが遅すぎました :/。 Renat Fatkhullin 2012.04.02 17:22 #1244 MetaDriver:すごいな、簡単だ、それでいいんだ! でも、何が必要なんだ?水平に ?私が提案する構造は、新しいエンティティを作成するための標準的な方法です。 何も興奮する必要はない。 Renat Fatkhullin 2012.04.02 17:29 #1245 MetaDriver: 現在、mql5では、関数にサブアレイを 渡すことができないため、多くの余分なステップと曲がったコードを書かなければなりません。制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。配列の一部を渡す必要がある場合は、配列自身とその位置への参照を渡す必要があります。これにより、アレイ自体を完全に制御することができます。 Vladimir Gomonov 2012.04.02 17:55 #1246 Renat:制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。2.配列の一部を渡す場合は、配列自体への参照と配列内の位置を渡して使用します。これは、アレイ自体を完全に制御するために有効です。しかも、ネーミングが実装されていないのはここだけなので、言語実体の普遍化というイデオロギーにうまく合致している。2.すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1)不必要な書き換えや構造体へのラップなしで、2次元のmql-arrayをOpenCLバッファにコピーする方法、または(2)一様でない配列に対してあなた自身の関数ArrayCopy(...)を(速度のために)使用する方法を提案してください。// 前回は突然の投稿で申し訳ありませんでした。本当に不要。ややこしいことはやめよう」で盛り上がりました。ただ複雑になるだけなので。2a. ArrayCopy()のような関数に対するあなたの「一次元性の制約」は、コメント中の1つの基本的な節で、多くの場合、苦痛なく和らげることができると思います。"この関数は、多次元配列 がまるごとコピー される限り、多次元配列でも 動作します。"多くの問題が解消されるでしょう。// もちろん、すべてではありません。 Документация по MQL5: Основы языка / Переменные www.mql5.com Основы языка / Переменные - Документация по MQL5 Renat Fatkhullin 2012.04.02 18:10 #1247 MetaDriver:1.私が提案したのは、ネーミングの導入とそれによる厳密な型付けであり、特にここだけはネーミングでカバーされていないので、言語実体の普遍化というイデオロギーによく合致する。描写の偶然性に気づきたくなかったのでしょう。typedef Int8 = int[8]; struct Int8 { int arr[8]; };2つ目の方法は、よりクリーンでパワフル、そしてコントロールしやすい方法です。既存の方式で、さらに弱いものを発明する理由はまったくない。2.同じことをすること。すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1) 二次元の mql-array を、不必要な書き換えや構造体へのラップなしに OpenCL バッファにコピーする方法、または(2) 無次元配列のためにあなた自身の関数 ArrayCopy(...) を(速度のために)使用する方法を提案してください。まず、曲がっていないこと。第二に、制御されないメモリへの直接アクセスというスタイルで、どの最適化手法よりも高い安全性を実現しています。つまり、「バイナリブロックを制御された実体に直接流し込むにはどうしたらいいか」という問題は、すべての言語にとって一般的かつ基本的な(解決可能性の低い)問題なのである。異なるシステム間で配列転送を行う場合(OpenCLの場合)、シンプルで直接的に互換性のあるデータ 構造を考えることが重要です。 データ転送を簡単にするための最もシンプルなCLBufferWriteのマルチタイプ関数バインドクラスを見てください。 ファイル: OpenCLSimple.mqh 13 kb Vladimir Gomonov 2012.04.02 18:15 #1248 Renat:MQL5では完全に禁止されている、制御されていないメモリの一部へのポインタの話をしているのですね。ついでに言うと、凝縮していますね。コンパイラは、パラメータが 渡される時点で、渡される配列のサイズを知っています。 しようとするとエラーになるくらいです。:)もうひとつは、関数呼び出しのたびに暗黙のパラメータ化を追加で導入しなければならないことです(おおよそ、あなたが明示的に行うようアドバイスしているように)。しかし、あなた側の解決策はもっと普遍的なものでしょう。例えば、関数やオブジェクトの独自の標準ライブラリを使用することです。同じArrayCopy()やFileWriteArray()であれば問題なく動作します。 Документация по MQL5: Основы языка / Функции / Передача параметров www.mql5.com Основы языка / Функции / Передача параметров - Документация по MQL5 Renat Fatkhullin 2012.04.02 18:21 #1249 papaklass: 私のような人間のために、簡単な例を添えて発言することができるのです。MetaDriverは理解してくれるが、私のような人間は例もなく何を言っているのか理解できない?そして、何が起こっているのかを意識したいものです。ドキュメント代わりになりそうで怖いです。検索で調べてみてください。情報は山ほどあります。一部のアレイメンバに安全にアクセスできる。void MyFunc(double& array[],uint pos,uint size) { while(size>0) { Print("[",pos,"] = ",array[pos]); pos++; size--; } }コンパイラがインライン関数に対して非常にシャープになっていることを考慮すると、実際、関数は呼び出し場所に完全に組み込まれ、すべてのオーバーヘッドがゼロになる可能性がある。つまり、MQL5では、小さな「正しい」関数を書くことを恐れず、適切な最適化を施した標準的なフルインラインの運命を持つことができるのです。つまり、パラメータ転送や インデックス作成にかかるコストを削減することができるのです。 Renat Fatkhullin 2012.04.02 18:27 #1250 MetaDriver:ついでに言うと、凝縮していますね。コンパイラはパラメータを 渡す時点で渡される配列のサイズを知っています。 いつから全ての配列が静止画になり、インデックスやサイズも全て静止画になったのでしょうか? 配列はほぼ常に動的であり、インデックスは変数であるため、呼び出しの瞬間に本格的な静的チェックを 行うことはできない。メタ/ルチチェックを するだけなので、メモリの一部を適当に作業するのではなく、オブジェクト/ディスクリプション全体にアクセスできることがとても重要です。同じArrayCopy()やFileWriteArray()であれば問題なく動作します。心配しないでください、すべてはずっと前から考えられていたことなんです。 私たちがよく知っているセキュリティの原則を破った結果は、「4月にさらに12の重大なバグを修正して、仮想マシンから抜け出してシステムを制御する」という方法です。 1...118119120121122123124125126127128129130131132...277 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ああ、今わかったよ。
Renat、私は長い間提案をしてきましたが、まさにその通りです。 少なくとも静的配列には名前付き型付けをしてください(他のすべての型にはすでにあります)。
例えば、typedef Int8 = int[8]; と宣言することが可能です。
構造物を通して簡単に行うことができます。こじつけは一切しません。
これは、構造物によって簡単に実現できる。複雑に考えすぎないようにしよう。
いいぞ、簡単だ、それでいいんだ! でも、何が必要なんだ?簡単な ことですか?
あなたのカミソリ「 オカム」と、私たち(ユーザー)のカミソリ「 オカム」は、まったく別のカミソリだと思いませんか?あなたの ミニマリズムは、ユーザーに 余剰を生み出しがちなので、そろそろオカムを近くのフェンスに吊るしておく必要がありそうですね。
そんなにシンプルさが大事なら、通常のサブアレイを関数に渡せるようにしてください! みんながハッピーになるし、ミニマリストもハッピーになりますよ。
// ちなみに、F4でも問題なく動作します - ダイナミックなものでも。:)
もちろん、静止画です。
すごいな、簡単だ、それでいいんだ! でも、何が必要なんだ?水平に ?
私が提案する構造は、新しいエンティティを作成するための標準的な方法です。
何も興奮する必要はない。
現在、mql5では、関数にサブアレイを 渡すことができないため、多くの余分なステップと曲がったコードを書かなければなりません。
制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。
MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。
配列の一部を渡す必要がある場合は、配列自身とその位置への参照を渡す必要があります。これにより、アレイ自体を完全に制御することができます。
制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。
MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。
2.配列の一部を渡す場合は、配列自体への参照と配列内の位置を渡して使用します。これは、アレイ自体を完全に制御するために有効です。
しかも、ネーミングが実装されていないのはここだけなので、言語実体の普遍化というイデオロギーにうまく合致している。
2.すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1)不必要な書き換えや構造体へのラップなしで、2次元のmql-arrayをOpenCLバッファにコピーする方法、または(2)一様でない配列に対してあなた自身の関数ArrayCopy(...)を(速度のために)使用する方法を提案してください。
// 前回は突然の投稿で申し訳ありませんでした。本当に不要。ややこしいことはやめよう」で盛り上がりました。ただ複雑になるだけなので。
2a. ArrayCopy()のような関数に対するあなたの「一次元性の制約」は、コメント中の1つの基本的な節で、多くの場合、苦痛なく和らげることができると思います。"この関数は、多次元配列 がまるごとコピー される限り、多次元配列でも 動作します。"
多くの問題が解消されるでしょう。// もちろん、すべてではありません。
1.私が提案したのは、ネーミングの導入とそれによる厳密な型付けであり、特にここだけはネーミングでカバーされていないので、言語実体の普遍化というイデオロギーによく合致する。
描写の偶然性に気づきたくなかったのでしょう。
2つ目の方法は、よりクリーンでパワフル、そしてコントロールしやすい方法です。既存の方式で、さらに弱いものを発明する理由はまったくない。
2.同じことをすること。すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1) 二次元の mql-array を、不必要な書き換えや構造体へのラップなしに OpenCL バッファにコピーする方法、または(2) 無次元配列のためにあなた自身の関数 ArrayCopy(...) を(速度のために)使用する方法を提案してください。
まず、曲がっていないこと。第二に、制御されないメモリへの直接アクセスというスタイルで、どの最適化手法よりも高い安全性を実現しています。つまり、「バイナリブロックを制御された実体に直接流し込むにはどうしたらいいか」という問題は、すべての言語にとって一般的かつ基本的な(解決可能性の低い)問題なのである。
異なるシステム間で配列転送を行う場合(OpenCLの場合)、シンプルで直接的に互換性のあるデータ 構造を考えることが重要です。
データ転送を簡単にするための最もシンプルなCLBufferWriteのマルチタイプ関数バインドクラスを見てください。
MQL5では完全に禁止されている、制御されていないメモリの一部へのポインタの話をしているのですね。
ついでに言うと、凝縮していますね。コンパイラは、パラメータが 渡される時点で、渡される配列のサイズを知っています。
しようとするとエラーになるくらいです。:)もうひとつは、関数呼び出しのたびに暗黙のパラメータ化を追加で導入しなければならないことです(おおよそ、あなたが明示的に行うようアドバイスしているように)。しかし、あなた側の解決策はもっと普遍的なものでしょう。例えば、関数やオブジェクトの独自の標準ライブラリを使用することです。同じArrayCopy()やFileWriteArray()であれば問題なく動作します。
私のような人間のために、簡単な例を添えて発言することができるのです。MetaDriverは理解してくれるが、私のような人間は例もなく何を言っているのか理解できない?そして、何が起こっているのかを意識したいものです。
ドキュメント代わりになりそうで怖いです。検索で調べてみてください。情報は山ほどあります。
一部のアレイメンバに安全にアクセスできる。
コンパイラがインライン関数に対して非常にシャープになっていることを考慮すると、実際、関数は呼び出し場所に完全に組み込まれ、すべてのオーバーヘッドがゼロになる可能性がある。
つまり、MQL5では、小さな「正しい」関数を書くことを恐れず、適切な最適化を施した標準的なフルインラインの運命を持つことができるのです。
つまり、パラメータ転送や インデックス作成にかかるコストを削減することができるのです。
ついでに言うと、凝縮していますね。コンパイラはパラメータを 渡す時点で渡される配列のサイズを知っています。
いつから全ての配列が静止画になり、インデックスやサイズも全て静止画になったのでしょうか?
配列はほぼ常に動的であり、インデックスは変数であるため、呼び出しの瞬間に本格的な静的チェックを 行うことはできない。メタ/ルチチェックを するだけなので、メモリの一部を適当に作業するのではなく、オブジェクト/ディスクリプション全体にアクセスできることがとても重要です。
同じArrayCopy()やFileWriteArray()であれば問題なく動作します。
心配しないでください、すべてはずっと前から考えられていたことなんです。
私たちがよく知っているセキュリティの原則を破った結果は、「4月にさらに12の重大なバグを修正して、仮想マシンから抜け出してシステムを制御する」という方法です。