"New Neural "は、MetaTrader 5プラットフォーム用のオープンソース・ニューラルネットワークエンジンプロジェクトです。 - ページ 63 1...565758596061626364656667686970...100 新しいコメント Mykola Demko 2011.11.25 01:41 #621 TheXpert です。...ちなみに、xmlはバイナリ表現よりも妥当性のチェックがしやすい。また、保存・復元は基本的にタイムクリティカルではありません。リンクの2値表現でのチェックの難しさはどのようなところにあるとお考えですか？どんなときに難しいのか、例を挙げてください。ZZZ リンクをバイナリテーブルで表現すると、どのリンクの正当性を確認するのが難しいというのは、例が思いつかないどころか、どんなトポロジーなのか想像もつきませんね。 TheXpert 2011.11.25 11:26 #622 ウラン です。どんなときに難しいのか、例を挙げてください。見てください。ストレージのフォーマットを少し変えたか、データが混乱して、配列のサイズの 代わりにデュブルの底辺部分、つまり巨大なサイズの配列が表示されたとします。そして、xmlでは、サイズがタグに包まれています。 TheXpert 2011.11.25 11:33 #623 MetaDriver。1. なぜダメな のかなぜなら、普遍的なベースが存在 しないからです。それは、私が覚えていた3つのグリッドだけです。 Mykola Demko 2011.11.25 17:31 #624 TheXpert です。見てください。保存形式を少し変えたか、データが混乱して、配列のサイズの代わりにダブりの底、つまり巨大なサイズの配列が表示されたとします。そして、xmlでは、サイズをタグで囲んでいます。"保存形式を少し変えた "というのは、xmlをaviに変えても気づかないような感じですね。フォーマットの変更は、両方のフォーマットに精通した者が対応する。また、フォーマット変更時のデバッグやテストは避けられない。ですから、保存形式が少し変わったくらいでは、論外です。誤って配置されたデータについては、（よく、私は落胆と訂正一緒にダブルとサンロングを格納する）、データが迷子に行くことができるときに読み取ったファイルの正しさを検証するためにハッシュサムを書いて、他のオプションが予見されていないことを避けるために。ということで、グリッド情報を持つフローティング配列を格納するためのフォーマットができました。[ハッシュサム] [レイヤー数]です。[レイヤーの種類] [ニューロン数]。[レイヤーの種類] [ニューロン数]。 [レイヤーの種類] [ニューロン数]。 [レイヤーの種類] [ニューロン数]。 [レイヤーの種類] [ニューロン数]。 バイナリテーブルを定義するulongをファイルの末尾にさらに追加します。ulongを[64]boolean文字配列に変換する方法 関数を用意したのですが、どのように変換すればよいですか？ Mykola Demko 2011.11.25 17:32 #625 TheXpert です。なぜなら、普遍的なベースが存在 しないからです。それは、私が覚えていた3つのグリッドだけです。納得できないが、今は反論しない、後日（1～2日後）、事実関係を把握してから回答する。同時に私の説を爆撃しようとするのでしょう :) TheXpert 2011.11.25 17:38 #626 ウラン です。 くそ...たぶん、私にはわからない。なぜ、面倒なものを作るのか？ Vladimir Kustikov 2011.11.25 20:00 #627 TheXpert: Shit...たぶん、私にはわからない。なんで自作自演で痛い目みるの？わかっていないのはあなただけではありませんよ :)バイナリ形式は、データを実装に束縛する足かせであり、有能な設計 者ならできるだけ早く取り除くべきものです。バイナリ形式はデータのパッキングに適しています。例えば、MT4ではこのようにデータが保存されていました。しかし、そこはネットワークの負荷を軽減するために合理的に行われたもので、ライター・リーダーは社内開発です。 しかし、なぜわざわざそのような凝ったことをするのか。このフォーマットのための独自のエディタを記述し、それ以上の問題を持っているために？xml、json、またはiniがあればより良い。 Mykola Demko 2011.11.25 20:17 #628 Vladix:誤解しているのはあなただけではありませんよ :)バイナリ形式は、データと実装をつなぐ足かせであり、有能な設計者であればできるだけ早く取り除くべきものです。バイナリ形式はデータのパッキングに適しており、例えばMT4ではこの方法でデータを保存していました。しかし、そこはネットワークの負荷を軽減するために合理的に行われており、ライター・リーダーは社内開発です。 そして、なぜわざわざそのような凝ったことをするのか。このフォーマットのための独自のエディタを記述し、それ以上の問題を持っているために？xml、json、あるいはiniの方がよいでしょう。 他の実装を提案してください、私は反対しません、議論して、比較して、より良いものを決めましょう。今のところ、このスレッドでは1つの提案（私のもの）があり、他のものは「xml、json、iniをやりましょう」と言っているだけで、この中でグリッドロードをどう実装するのかは誰も言っていません。バイナリリンク表は非常にわかりやすく、列で行くと送信先がわかり、行で行くと送信先がわかる（逆も同様、表は正方形なので、そのとらえ方を合意すればよい）。そして、他のフォーマットでどのように実装されるかは、誰も何も言いません。声を出してください。 михаил потапыч 2011.11.25 20:25 #629 このままでは、あなたの子供たちが同意し、XMLで停止し、孫が実装を開始します。長老を 投票または選択する。 Mykola Demko 2011.11.25 20:33 #630 ミシェックこのままでは、あなたの子供たちが同意し、XMLで停止し、孫が実装を開始します。投票する、または長老を 選ぶ.代替案がない場合に何を投票するかですが、私はグリッドロードアルゴリズムの一般的な考え方の説明、このアルゴリズムをbinに格納するための最適なフォーマットを持っています。アルゴリズムのロードに関する他の提案は、ストレージフォーマットの提案だけを見て、ストレージフォーマット自体はロードするアルゴリズムに基づいて選択されるべきである、あるアルゴリズムのために1つのフォーマットは別のために優れています。アルゴリズムの提案もありますし、何をどのような形式で保存するのがベストなのか、実質的な議論も行われることでしょう。 1...565758596061626364656667686970...100 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
...
ちなみに、xmlはバイナリ表現よりも妥当性のチェックがしやすい。また、保存・復元は基本的にタイムクリティカルではありません。
リンクの2値表現でのチェックの難しさはどのようなところにあるとお考えですか？
どんなときに難しいのか、例を挙げてください。
ZZZ リンクをバイナリテーブルで表現すると、どのリンクの正当性を確認するのが難しいというのは、例が思いつかないどころか、どんなトポロジーなのか想像もつきませんね。
どんなときに難しいのか、例を挙げてください。
見てください。ストレージのフォーマットを少し変えたか、データが混乱して、配列のサイズの 代わりにデュブルの底辺部分、つまり巨大なサイズの配列が表示されたとします。
そして、xmlでは、サイズがタグに包まれています。
1. なぜダメな のか
なぜなら、普遍的なベースが存在 しないからです。それは、私が覚えていた3つのグリッドだけです。
見てください。保存形式を少し変えたか、データが混乱して、配列のサイズの代わりにダブりの底、つまり巨大なサイズの配列が表示されたとします。
そして、xmlでは、サイズをタグで囲んでいます。
"保存形式を少し変えた "というのは、xmlをaviに変えても気づかないような感じですね。
フォーマットの変更は、両方のフォーマットに精通した者が対応する。また、フォーマット変更時のデバッグやテストは避けられない。
ですから、保存形式が少し変わったくらいでは、論外です。
誤って配置されたデータについては、（よく、私は落胆と訂正一緒にダブルとサンロングを格納する）、データが迷子に行くことができるときに読み取ったファイルの正しさを検証するためにハッシュサムを書いて、他のオプションが予見されていないことを避けるために。
ということで、グリッド情報を持つフローティング配列を格納するためのフォーマットができました。
[ハッシュサム] [レイヤー数]です。
[レイヤーの種類] [ニューロン数]。
[レイヤーの種類] [ニューロン数]。
[レイヤーの種類] [ニューロン数]。
[レイヤーの種類] [ニューロン数]。
[レイヤーの種類] [ニューロン数]。バイナリテーブルを定義するulongをファイルの末尾にさらに追加します。
ulongを[64]boolean文字配列に変換する方法 関数を用意したのですが、どのように変換すればよいですか？
なぜなら、普遍的なベースが存在 しないからです。それは、私が覚えていた3つのグリッドだけです。
納得できないが、今は反論しない、後日（1～2日後）、事実関係を把握してから回答する。
同時に私の説を爆撃しようとするのでしょう :)
Shit...たぶん、私にはわからない。なんで自作自演で痛い目みるの？
わかっていないのはあなただけではありませんよ :)
バイナリ形式は、データを実装に束縛する足かせであり、有能な設計 者ならできるだけ早く取り除くべきものです。バイナリ形式はデータのパッキングに適しています。例えば、MT4ではこのようにデータが保存されていました。しかし、そこはネットワークの負荷を軽減するために合理的に行われたもので、ライター・リーダーは社内開発です。
しかし、なぜわざわざそのような凝ったことをするのか。このフォーマットのための独自のエディタを記述し、それ以上の問題を持っているために？xml、json、またはiniがあればより良い。
誤解しているのはあなただけではありませんよ :)
バイナリ形式は、データと実装をつなぐ足かせであり、有能な設計者であればできるだけ早く取り除くべきものです。バイナリ形式はデータのパッキングに適しており、例えばMT4ではこの方法でデータを保存していました。しかし、そこはネットワークの負荷を軽減するために合理的に行われており、ライター・リーダーは社内開発です。
そして、なぜわざわざそのような凝ったことをするのか。このフォーマットのための独自のエディタを記述し、それ以上の問題を持っているために？xml、json、あるいはiniの方がよいでしょう。
他の実装を提案してください、私は反対しません、議論して、比較して、より良いものを決めましょう。
今のところ、このスレッドでは1つの提案（私のもの）があり、他のものは「xml、json、iniをやりましょう」と言っているだけで、この中でグリッドロードをどう実装するのかは誰も言っていません。
バイナリリンク表は非常にわかりやすく、列で行くと送信先がわかり、行で行くと送信先がわかる（逆も同様、表は正方形なので、そのとらえ方を合意すればよい）。
そして、他のフォーマットでどのように実装されるかは、誰も何も言いません。
声を出してください。
このままでは、あなたの子供たちが同意し、XMLで停止し、孫が実装を開始します。
長老を 投票または選択する。
このままでは、あなたの子供たちが同意し、XMLで停止し、孫が実装を開始します。
投票する、または長老を 選ぶ.
代替案がない場合に何を投票するかですが、私はグリッドロードアルゴリズムの一般的な考え方の説明、このアルゴリズムをbinに格納するための最適なフォーマットを持っています。
アルゴリズムのロードに関する他の提案は、ストレージフォーマットの提案だけを見て、ストレージフォーマット自体はロードするアルゴリズムに基づいて選択されるべきである、あるアルゴリズムのために1つのフォーマットは別のために優れています。
アルゴリズムの提案もありますし、何をどのような形式で保存するのがベストなのか、実質的な議論も行われることでしょう。