トレーディングにおける機械学習：理論、モデル、実践、アルゴトレーディング - ページ 3151

[Aleksey Nikolayev]

mytarmailS #:

履歴ウィンドウのサイズは、表形式のデータを扱う古典的なMOにとっては大きな制限でしかない。

AS(asoc.ルール)はそのような病気に悩まされることはなく、 非構造化データを 完璧に消化し、さらに各観測は任意の大き さにすることができる。

そして、"視野の窓"（履歴の窓）そのものは、計算能力によってのみ制限される。

だから、履歴ウィンドウのサイズ に関するあなたの例は、ACに賛成し、MOに反対しているに過ぎない。

私が本当に何かを見逃しているのかどうか気になる。

そしてもうひとつ質問なんだが、君はどのくらいauに入れ込んでいるんだい？

ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の適用に至った。確率文法で構築された価格を見ていたのですが、その面倒くささゆえにこのアプローチを断念しました。

今は重いモデルは避けている。私にとっての主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだということだ。

あなたのモデルは本格的な価格モデルには十分重いですが、私たちが持っている実際の価格のサンプルは（他の情報を加えたとしても）そのようなモデルには十分ではありません。

当然、IMHOは

[mytarmailS]

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]

Aleksey Nikolayev #:

ところで、ニシキヘビの研究はどうなっている？

[Aleksey Nikolayev]

mytarmailS #:

ところで、ニシキヘビの研究はどうなっている？

Pythonはいい言語だが、あるレベルから見ると、ノンプログラマーには複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。numpyのテーブルはとても気に入りました。

[СанСаныч Фоменко]

Aleksey Nikolayev #:

ルールに飛び込んだわけではない。すでに書いたように、私は反対側から形式文法の応用に取り組んだ。 私がこのアプローチをあきらめたのは、まさにその面倒くささのせいである。

今は重いモデルは避けている。私の主な非公式ルールは、モデルの重さはサンプルの情報の重さに対応すべきだというものだ。

あなたのモデルは本格的な価格モデルになるには十分重いが、我々が持っている実際の価格のサンプルは（他の情報を加えたとしても）そのようなモデルには十分ではない。

当然、IMHOは

100%

[Aleksey Vyazmikin]

mytarmailS #:

また、重要なイベントが昨日200ローソク足前であった場合、同じイベントが今日すでに1555ローソク足前であったり、例えば12本前であったり...と、インデックスへのリンクがないことにも注意が必要だ。

ーACはーAMOはーこのー

AMOは、各機能が常に同じインデックスでトリガーされるように、テーブル内に同じカラムを持つ必要があります。

、、ーあるいはー、ー

、ー約半年前にったな。

私は、あなたのルールがどのようにインデックスを参照せずに縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。

[mytarmailS]

Aleksey Vyazmikin #:

好奇心旺盛で、半年ほど前に説明したこととまったく同じことをしている。

私は、あなたのルールがどのようにインデックスを参照することなく縦方向に特徴の値を検索するのか理解できません - 私の概念では、許容可能な検索範囲があるはずです - あなたの実装を理解していません。

通常の連想ルールのアルゴリズムでは、タスクによって異なります。

その時（半年前）、私はあなたの問題に対する解決策（コード）を提示しました。

[mytarmailS]

Aleksey Nikolayev #:

C言語は良い言語だが、ノンプログラマーにとっては複雑すぎる。例えば、C言語で拡張機能を書くのはR言語よりもずっと難しい。私はnumpyのテーブルが本当に好きだった。

聖なる質問)

市場調査にはRかパイソンか？

[Aleksey Nikolayev]

mytarmailS #:

ホリバー問題)

市場調査のために - RまたはPython？

私が市場調査を行う場合、現時点では - R。今後、他の人や私自身を保証する準備はできていません）。

[Aleksey Vyazmikin]

mytarmailS #:
通常の連想ルールのアルゴリズムで、問題によって異なる。

その時（半年前）、私はあなたの問題に対する解決策（コード）を教えたはずだが、もう忘れたのか？

何のコードのことを言っているのかさえわからない。どうやら何かが実行に失敗したようだ。何のコードについて話しているのか？

あなたは、深さは時間的に重要なイベントではないと主張している。