トレーディングにおける機械学習:理論、モデル、実践、アルゴトレーディング - ページ 3151 1...314431453146314731483149315031513152315331543155315631573158...3399 新しいコメント Aleksey Nikolayev 2023.07.21 08:53 #31501 mytarmailS #:履歴ウィンドウのサイズは、表形式のデータを扱う古典的なMOにとっては大きな制限でしかない。AS(asoc.ルール)はそのような病気に悩まされることはなく、 非構造化データを 完璧に消化し、さらに各観測は任意の大き さにすることができる。そして、"視野の窓"(履歴の窓)そのものは、計算能力によってのみ制限される。だから、履歴ウィンドウのサイズ に関するあなたの例は、ACに賛成し、MOに反対しているに過ぎない。私が本当に何かを見逃しているのかどうか気になる。そしてもうひとつ質問なんだが、君はどのくらいauに入れ込んでいるんだい? ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の適用に至った。確率文法で構築された価格を見ていたのですが、その面倒くささゆえにこのアプローチを断念しました。 今は重いモデルは避けている。私にとっての主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだということだ。 あなたのモデルは本格的な価格モデルには十分重いですが、私たちが持っている実際の価格のサンプルは(他の情報を加えたとしても)そのようなモデルには十分ではありません。 当然、IMHOは mytarmailS 2023.07.21 09:29 #31502 mytarmailS #:では、AMOはどうやって例からパターンを見つけるのだろうか? わかりやすくするために控えめに説明しましたが、実際はもっとこうです。 そして、あなたのモデルはこれだけを見ている:(最後の5本の1時間ごとのローソク足)。 また、インデックスへのリンクがないことに注意してください、重要なイベントが昨日200ローソク足前であった場合、今日は同じイベントがすでに1555ローソク足前または例えば12かもしれない.... ACはそのようなパターンを見つけることができますが、AMOは見つけることができません! AMOは、各フィーチャーが常にテーブルの同じカラムを持ち、常に同じインデックスの下でトリガーされるようにする必要があります。 あるいはこのように、かなり視覚的です。 [[1]] [1] ".....A...............................................................B........C..............SELL" [[2]] [1] ".......A........B...........C...........SELL" [[3]] [1] "........................................A........B.........................C.............SELL" [[4]] [1] "..A.............................................................B..............C...SELL" [[5]] [1] ".......A..........................................B...C...SELL" 、、フレンドリーなフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリー [[1]] [1] ".....A...............................................................B........C.............. SELL" [[2]] [1] ".......A........B...........C........... SELL" [[3]] [1] "........................................A........B.........................C............. SELL" [[4]] [1] "..A.............................................................B..............C... SELL" [[5]] [1] ".......A..........................................B...C... SELL" とにかく、私の言いたいことは伝わっただろうか。 mytarmailS 2023.07.21 09:57 #31503 Aleksey Nikolayev #: ところで、ニシキヘビの研究はどうなっている? Aleksey Nikolayev 2023.07.21 11:11 #31504 mytarmailS #:ところで、ニシキヘビの研究はどうなっている? Pythonはいい言語だが、あるレベルから見ると、ノンプログラマーには複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。numpyのテーブルはとても気に入りました。 СанСаныч Фоменко 2023.07.21 11:12 #31505 Aleksey Nikolayev #:ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の応用に取り組んだ。 私がこのアプローチをあきらめたのは、まさにその面倒くささのせいである。今は重いモデルは避けている。私の主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだというものだ。あなたのモデルは本格的な価格モデルになるには十分重いが、我々が持っている実際の価格のサンプルは(他の情報を加えたとしても)そのようなモデルには十分ではない。当然、IMHOは 100% Aleksey Vyazmikin 2023.07.21 11:28 #31506 mytarmailS #:また、重要なイベントが昨日200ローソク足前であった場合、同じイベントが今日すでに1555ローソク足前であったり、例えば12本前であったり...と、インデックスへのリンクがないことにも注意が必要だ。ーACはーAMOはーこのーAMOは、各機能が常に同じインデックスでトリガーされるように、テーブル内に同じカラムを持つ必要があります。、、ーあるいはー、ー 、ー約半年前にったな。 私は、あなたのルールがどのようにインデックスを参照せずに縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。 mytarmailS 2023.07.21 12:12 #31507 Aleksey Vyazmikin #:好奇心旺盛で、半年ほど前に説明したこととまったく同じことをしている。私は、あなたのルールがどのようにインデックスを参照することなく縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。 通常の連想ルールのアルゴリズムでは、タスクによって異なります。その時(半年前)、私はあなたの問題に対する解決策(コード)を提示しました。 mytarmailS 2023.07.21 12:48 #31508 Aleksey Nikolayev #:C言語は良い言語だが、ノンプログラマーにとっては複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。私はnumpyのテーブルが本当に好きだった。 聖なる質問) 市場調査にはRかパイソンか? Aleksey Nikolayev 2023.07.21 12:54 #31509 mytarmailS #:ホリバー問題) 市場調査のために - RまたはPython? 私が市場調査を行う場合、現時点では - R。今後、他の人や私自身を保証する準備はできていません)。 Aleksey Vyazmikin 2023.07.21 14:23 #31510 mytarmailS #: 通常の連想ルールのアルゴリズムで、問題によって異なる。 その時(半年前)、私はあなたの問題に対する解決策(コード)を教えたはずだが、もう忘れたのか? 何のコードのことを言っているのかさえわからない。どうやら何かが実行に失敗したようだ。何のコードについて話しているのか? あなたは、深さは時間的に重要なイベントではないと主張している。 1...314431453146314731483149315031513152315331543155315631573158...3399 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
履歴ウィンドウのサイズは、表形式のデータを扱う古典的なMOにとっては大きな制限でしかない。
AS(asoc.ルール)はそのような病気に悩まされることはなく、 非構造化データを 完璧に消化し、さらに各観測は任意の大き さにすることができる。
そして、"視野の窓"(履歴の窓)そのものは、計算能力によってのみ制限される。
だから、履歴ウィンドウのサイズ に関するあなたの例は、ACに賛成し、MOに反対しているに過ぎない。
私が本当に何かを見逃しているのかどうか気になる。
そしてもうひとつ質問なんだが、君はどのくらいauに入れ込んでいるんだい?
ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の適用に至った。確率文法で構築された価格を見ていたのですが、その面倒くささゆえにこのアプローチを断念しました。
今は重いモデルは避けている。私にとっての主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだということだ。
あなたのモデルは本格的な価格モデルには十分重いですが、私たちが持っている実際の価格のサンプルは(他の情報を加えたとしても)そのようなモデルには十分ではありません。
当然、IMHOは
では、AMOはどうやって例からパターンを見つけるのだろうか?
わかりやすくするために控えめに説明しましたが、実際はもっとこうです。
そして、あなたのモデルはこれだけを見ている:(最後の5本の1時間ごとのローソク足)。
また、インデックスへのリンクがないことに注意してください、重要なイベントが昨日200ローソク足前であった場合、今日は同じイベントがすでに1555ローソク足前または例えば12かもしれない....
ACはそのようなパターンを見つけることができますが、AMOは見つけることができません!
AMOは、各フィーチャーが常にテーブルの同じカラムを持ち、常に同じインデックスの下でトリガーされるようにする必要があります。
あるいはこのように、かなり視覚的です。
、、フレンドリーなフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリーフレンドリー
とにかく、私の言いたいことは伝わっただろうか。
ところで、ニシキヘビの研究はどうなっている?
ところで、ニシキヘビの研究はどうなっている?
Pythonはいい言語だが、あるレベルから見ると、ノンプログラマーには複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。numpyのテーブルはとても気に入りました。
ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の応用に取り組んだ。 私がこのアプローチをあきらめたのは、まさにその面倒くささのせいである。
今は重いモデルは避けている。私の主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだというものだ。
あなたのモデルは本格的な価格モデルになるには十分重いが、我々が持っている実際の価格のサンプルは(他の情報を加えたとしても)そのようなモデルには十分ではない。
当然、IMHOは
100%
また、重要なイベントが昨日200ローソク足前であった場合、同じイベントが今日すでに1555ローソク足前であったり、例えば12本前であったり...と、インデックスへのリンクがないことにも注意が必要だ。
ーACはーAMOはーこのー
AMOは、各機能が常に同じインデックスでトリガーされるように、テーブル内に同じカラムを持つ必要があります。
、、ーあるいはー、ー
、ー約半年前にったな。
私は、あなたのルールがどのようにインデックスを参照せずに縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。
好奇心旺盛で、半年ほど前に説明したこととまったく同じことをしている。
私は、あなたのルールがどのようにインデックスを参照することなく縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。
C言語は良い言語だが、ノンプログラマーにとっては複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。私はnumpyのテーブルが本当に好きだった。
聖なる質問)
市場調査にはRかパイソンか?
ホリバー問題)
市場調査のために - RまたはPython?
私が市場調査を行う場合、現時点では - R。今後、他の人や私自身を保証する準備はできていません)。
通常の連想ルールのアルゴリズムで、問題によって異なる。
何のコードのことを言っているのかさえわからない。どうやら何かが実行に失敗したようだ。何のコードについて話しているのか?
あなたは、深さは時間的に重要なイベントではないと主張している。