問題タブ [variance]

今回は分散に関する少し異なる質問です。

実験から、C# では仮想関数を反変関数でオーバーライドできないことがわかりました。もしそうなら、「適切なメソッドのオーバーロードが見つかりません」というメッセージが表示され続けるので、どうすればよいですか。そうでない場合、なぜですか？基本クラスが int の値が常に int になるように指定し、サブクラスがオブジェクトを取ることができる場合、どこに問題がありますか?

戻り値の型と同じで、オーバーライド シグネチャで共変でなければなりません

どの言語でこれを行うことができますか? (C++/Java 私はあなたを見ています) そして、彼らがあなたに使用させてくれるなら、どの型を変えますか? (戻り値の型/引数リストなど)

複数のオーバーライドを設定できますか? 署名が技術的に一意である限り、なぜそうしないのかわかりません。

C#/CLR がメソッド オーバーライド共分散/反分散をサポートしないのはなぜですか?

私はこれを読みましたが、どの質問にも答えがありません。私は一般的な差異について知っており、それが素晴らしいことを知っています。C# だけでなく、C# のメソッド シグネチャの分散についても知りたいです (つまり、これに限定されません)。存在しない場合は、これの確認と説明が必要です(実装の詳細ですか?私の型理論は間違っていますか?CLR/C#がたまたまこの特定の機能をサポートしていないだけですか?それは私が持っているものですか? CLR の実装に対処する必要がないため、特定の複雑な詳細がわからないため、考えたことはありませんか?)

特性を考えるとT

次のクラスA

の有効なサブタイプではありませんT。の実装は、 type の要素のみを受け入れるのに対し、 の署名ではすべての実装が typeのオブジェクトだけでなく、 type のオブジェクトを受け入れることができる必要があるA.+ため、制限が厳しすぎます。これまでのところ、とても合理的です。AT.+TA

の実装を制限的にしたい場合は、次のようにandTの宣言を変更できます。TA

これは明らかに型シグネチャを爆破します。

Tの実装が独自の型のオブジェクトと互換性があるだけでよいことを宣言する別の方法はありますか?

1st EDIT以下のLandeiの回答への返信：

自己型は実際に現在の署名を短縮しますTが、発生する他の署名を短縮しません。

C＃仕様では、引数の型を同時に共変と反変の両方にすることはできないと規定されています。

これは、共変または反変のインターフェースを作成するときに、タイプパラメーターをそれぞれ「out」または「in」で装飾するときに明らかです。両方を同時に許可するオプションはありません（「outin」）。

この制限は単に言語固有の制約ですか、それとも圏論に基づいて、タイプを共変と反変の両方にしたくないという、より深く、より根本的な理由がありますか？

編集：

私の理解では、配列は実際には共変と反変の両方でした。

の違いは何ですか

と

Scalaで？

データアクセス層に次のクラス構造があるとします。

これにより、モデルで実装できるさまざまなインターフェイスと、それらのインターフェイスを処理する再利用可能な動作を使用できます。

そして、マネージャーは、の共変性のためにこれらを喜んで受け取りますIBehavior<T>。

素晴らしい。

しかし、ここで、各動作に一連のLINQフィルターをエンティティにも適用させたいと思います。私の最初のアイデアは、このメソッドをIBehavior<T>次のように追加することでした。

...実装動作はWhere、その裁量で列挙に一連の句を適用します。

ただし、結局のところ、refパラメーターでは型のバリエーションは許可されていません。型の安全性とインターフェースの反変の性質の両方を維持しながら、この種の機能を実装する方法を見つけるのに苦労しています。どんなアイデアでも大歓迎です。

@ジェリーコフィン

ロジックを取得しますが、while（File >> value）//ファイルから取得した入力がtrueである間....計算を行います。しかし、これを実装したとき、カウンターは1になり、その値は非常に高かった。時々間違っていますが、私には何がわかりません。ファイルは有効です

ここで私は "TEXT.TXT" 23244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 1486415241250586205864104818638684840823244564 14864152412505862058641048186386848408を使用しています入力ファイルの内容です

格納するオブジェクトに基づいて異なる実装を持つ次のクラスがあるとします。

そして、次のようなことをして、上記のクラスで別のバージョンのいずれかを使用したいと思います。

もちろん、最初のクラスには型制約があり、2 番目のクラスには型制約がないため、上記はコンパイルされません。私ができる方法はありますか: この特定のケース ( list = new ListOfPersistent<T>()) の制約をチェックしないようにコンパイラーに伝えるか、コードが問題なくコンパイルされるように、共分散/反分散マジックを実行しますか?

資産運用で発生する問題があります。私は、このフォーラムがそれを検討するのに十分な興味深い質問を提起すると思います (そして望んでいます)。私たちは文献をかなり広範囲に検索し、この問題について語っていることを見つけましたが、この問題を直接扱っているものは何もありませんでした.

バックグラウンド

資産の時系列データがあり、そこから相関行列を計算します。Mathematica を使用した 5 つのアセットの場合、次のようになります。

資産運用では分散が必要です。ポートフォリオ内の 2 つ以上の資産の相関が高すぎる場合、リスクを分散させるのではなく、集中させてしまいます。

私たちが欲しいもの

ポートフォリオの「集中」リスクを最小限に抑えながら、常にすべての商品である程度のポジションを保持する資産ポートフォリオを構築するためのアプローチまたは方法が必要です。

以下のいくつかの例で集中リスクを説明しますが、最初に...

なぜこれが興味深い問題や質問なのですか?

いくつかの理由で、これは興味深く挑戦的な質問になっています。

「効率的なフロンティア」に関連していますが、使用する個々の手段の将来のパフォーマンスについては想定していません。

分散を最小限に抑えることで答えが得られますが、直感的に満足できるものでも有用なものでもありません。

主成分分析はこれを調べる自然な方法のように思えますが、必要なものが得られないようにも見えます。

エントロピー最大化の使用を検討しましたが、離散エントロピーに精通している担当者の 1 人が有望だと考えていましたが、これを連続エントロピーの観点から考えてみると、行き止まりであることがわかりました。次のコードは、私たちが見たもののアイデアを示しています (実際に実行されるかどうかはわかりません)。

Attilio Meucci は論文「Managing Diversification」と有望に見えるいくつかの MatLab コードを持っています。

http://www.symmys.com/AttilioMeucci/Research/PublFinance/PublFinance.html

しかし、私の同僚の一人がそれを見た後、次のようにコメントしました：

彼は私がやりたかったのとほぼ同じことをしているようです (アイデアを破棄する前に)、彼は少しごまかしています。連続エントロピーを実際に計算する代わりに、彼は各主成分を個別の賭けとして扱っているだけです。しかし、基本的に、彼の論文は、複数の相関するコインフリップで行った計算の改良版です。これにより、現在の変数の余分な桁からではなく、他の変数からエントロピーを取得する必要があります。

彼が行っていることを非正規分布に対して行うのは、よりトリッキーかもしれませんが、「95% 標準正規分布、5% は本当に悪いもの」という形の状況に生成モデルを使用できると思います。

集中リスクの例

集中リスクを説明する簡単な例

思考実験で 3 つの資産のポートフォリオを見ると、達成したいことを最も簡単に理解できます。2 つの商品の相関が 1 (100%) で、3 つ目の商品の相関が 0 であると仮定すると、その相関行列は次のようになります。

この場合の私たちの観点からは、2 つの相関する株式のそれぞれに 25% を配置し、相関しない株式に 50% を配置することは理にかなっています。

これにより、相関する商品に集中するリスクが相殺されますが、100% 相関する資産は実際にはまだ異なる商品であり、その相関は将来変化する可能性があります。

100% の相関関係を持つ 2 つの資産が同じように動く場合、可能な配分の広い範囲が等しく目的を果たすことができると主張する人もいるかもしれません。

...またはそのようなテーマのバリエーション。

しかし、それらの将来の相関関係がどのように進化するかわからないため、最良かつ最も直感的な解決策は次のとおりであると考えています。

もう一つの例

100% の相関を持つ 4 つの資産と 0% の相関を持つ 1 つの資産を含む 5 つの資産のポートフォリオでは、相関行列は次のようになります。

そして、私たちが望むポートフォリオの割り当ては、次の比率になります。

12.5%、12.5%、12.5%、12.5%、50%

もちろん、現実世界はさらに複雑です。

私たちが試したこと

分散の最小化 (有望だが機能しない)

これを行うために分散を最小限に抑えることを誰かが提案しましたが、ご覧のとおり、直感的な解決策は得られません。

これを説明するいくつかの Mathematica コードは次のとおりです。

これは良さそうです。それは私たちに与えます：

25%、25%、50%

しかし...

5 つのアセットの場合:

それが私たちに与えるほど良くはありません：

したがって、分散を最小限に抑えることは、より現実的なものは言うまでもなく、この単純な (人為的である場合) ケースでも機能しません。

有望なソリューション

私たちの議論への貢献者の 1 人は、有望なアプローチを提案しました - 少なくとも負の相関関係がないケースでは。おそらく、誰かがより完全な解決策を提案するようになるでしょう。

再び Mathematica コードで：

まさに私たちが望むものです。注: Mathematica のコードに慣れていない方のために説明すると、「Tr」は行列のトレースを検出し、「/@」は関数をリストまたは行列にマップします。残りはおそらく理にかなっています。

4 つのアセットの別の例:

繰り返しますが、まさに私たちが望んでいるものです。

これは、分散を最小化するよりもうまく機能しますが、より現実的な例 (投稿で説明されている最初の例) では、うまくいかないことがあります。

この場合、4 番目のアセットに負の割り当て (-0.0541658) が設定されていますが、これは達成したいことには意味がありません。

結論

したがって、一種の MinimizeVarianceIntuitively 関数が必要です。これらすべてが、私たちが達成したいことを十分に明確に説明していることを願っています. この問題をまったく異なる方法で攻撃するための提案やアイデア、または私たちがすでに試したことを拡張するためのアイデアは非常に高く評価されています。

これをさりげなく見ている人は、CAPM (Capital Asset Pricing Model) がこれを行っていると常に示唆しています。そうではありません。上記の相関関係は、各資産を「市場」に関連付けるのではなく、資産と資産を関連付けているため、使用できる「ベータ」がないことを考慮してください。また、記述された問題は、リスクフリーレートまたは価格の正規分布のリターンまたは使用のいずれについても仮定していません。CAPM がこれを行う方法のように見えることはわかりますが、それがどのように適用されるかはわかりません。

どうもありがとう、

アルン・ガラパタ

このようなクラス階層があります

次のさまざまなメソッドに割り当てることができる CalendarEventBase 型のジェネリック型パラメーターを持つアクション Action ラムダを作成したかったのです。

次の違法な割り当てを作成しました:

コンパイラは、署名として void(CalendarEventBase) を持つメソッドを予期していたと不平を言います。より派生した型を受け入れると思っていたので、これには驚きました。

これを回避するために、タスクを完了できる次のデリゲートを作成しました。

私の質問は、追加の代理人を作成せずにタスクを完了できたでしょうか? Action インスタンスを作成するだけでよいと思いました。

任意のヘルプまたはポインタ、大歓迎です。

ローリング分散 (たとえば、20 期間のローリング ウィンドウにわたる分散) を計算するための効率的で数値的に安定したアルゴリズムを見つけようとしています。一連の数値の連続分散を効率的に計算するWelford アルゴリズムは知っていますが (必要なパスは 1 つだけです)、ローリング ウィンドウに適用できるかどうかはわかりません。また、この記事の冒頭でJohn D. Cookが説明した精度の問題を回避するためのソリューションも希望しています。どの言語でのソリューションでも問題ありません。