【Java】特定のフォルダをexplorerで開く

https://www.google.com/search?q=os%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89+%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E3%82%92%E9%96%8B%E3%81%8F&oq=os%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89+%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E3%82%92%E9%96%8B%E3%81%8F&aqs=chrome..69i57.46314j0j7&sourceid=chrome&ie=UTF-8

OSコマンドの確認
https://technical-knowledge-info.hatenablog.com/entries/2010/03/12

Javaで外部プロセスの呼び出し
https://qiita.com/suzuki_y/items/212ae68059a2c340b79c

http://www.ne.jp/asahi/hishidama/home/tech/java/process.html

結果

import java.io.IOException;

public class test {

public static void main(String[] args) {

String dir = “explorer C:\\eclipse”;
String[] Command = { “cmd”, “/c”, dir}; // 起動コマンドを指定する
Runtime runtime = Runtime.getRuntime(); // ランタイムオブジェクトを取得する
try {
runtime.exec(Command,null,null);
} catch (IOException e) {
System.out.println(e);
}

}

}

【Java】 マルチアップロード 検証

https://www.google.com/search?ei=Z7I7XZHgNoO7mAWK2rHgDw&q=java+%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89+%E3%83%89%E3%83%A9%E3%83%83%E3%82%B0+%E8%A4%87%E6%95%B0&oq=java+%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89+%E3%83%89%E3%83%A9%E3%83%83%E3%82%B0+%E8%A4%87%E6%95%B0&gs_l=psy-ab.3..33i21.2614.9188..9682…6.0..0.157.2062.6j13……0….1..gws-wiz…….0i30j33i160j35i39._PNvYgaOSrg&ved=0ahUKEwjRr4e4gtTjAhWDHaYKHQptDPwQ4dUDCAo&uact=5


https://blog.goo.ne.jp/xmldtp/e/9cc8e7b3bdfa2725fbc560904571b042
https://teratail.com/questions/50488

PL/pgSQl

A5で実行してみる

下記のサイトを参考に

https://db.just4fun.biz/?PL/pgSQL%E3%81%A8%E3%81%AF%EF%BC%9F

・どの言語が使えるようになっているかを確認

select * from pg_language;

・作成済みのファンクションを調べる

SELECT * FROM pg_proc;

または

SELECT proname,prosrc FROM pg_proc WHERE proname = 'update_w_blnc_slip_mgt_hist'

prosrcの値が実行される内容

・ストアドプロシージャの作成
[ORACLE]

CREATE [ OR REPLACE ] PROCEDURE ストアドプロシージャ名
[ (引数名 データ型),... ]
IS [ 変数名 データ型,... ]
BEGIN
処理内容
END ;

例:

 CREATE PROCEDURE pro_200
 IS
 BEGIN
     SELECT DISTINCT KK.顧客名 FROM 受注表 JJ,顧客表 KK
         WHERE JJ.顧客コード = KK.顧客コード
               AND JJ.受注個数 >= 200 ;
 END ;

[PostgreSQL]

CREATE FUNCTION 関数名 ( [ 引数のデータ型,... ] )
RETURNS [ SETOF ] 返り値のデータ型
AS
'
[ラベル]
[ DECLARE 変数名 データ型 ... ]
BEGIN
処理内容
END ;
'
LANGUAGE 'sql' ;

例:

 CREATE FUNCTION func_200()
 RETURNS SETOF CHAR(20)
 AS
 '
 BEGIN
     SELECT DISTINCT KK.顧客名 FROM 受注表 JJ,顧客表 KK
         WHERE JJ.顧客コード = KK.顧客コード
               AND JJ.受注個数 >= 200 ;
 END ;
 '
 LANGUAGE 'sql' ;

・ストアドプロシージャの実行と削除

<<ORACLE>>

BEGIN
[ EXECUTE ] ストアドプロシージャ名 [(引数,...)]
END ;

例:

 BEGIN
       pro_200
 END ;

参考URL

https://www.postgresql.jp/document/7.2/programmer/plpgsql.html

https://www.postgresql.jp/document/9.2/html/catalog-pg-proc.html

https://www.techscore.com/tech/sql/SQL13/13_02.html/

https://www.postgresql.jp/document/8.1/html/plpgsql-trigger.html

SQL

・サブクエリーを引数に取る場合、IN述語よりもEXISTS述語を使え

IN[NOT IN]とEXISTS[NOT EXISTS]は、たいていの場合、全く等しい結果集合を返します。しかし、この両者でサブクエリーを作る場合は、EXISTSの方が圧倒的に速い。例えば、有名人の誰かと同じ誕生日に生まれた社員を全て探すためのSQLを考えます。以下の2つのSQLは、同じ結果を返しますが、2番目の方が速いです。

使用テーブル:
Personnel(社員テーブル)
Celebrities(有名人テーブル)

1.INを使った場合(遅い)

SELECT name
FROM Personnel
WHERE birthday IN (SELECT birthday
FROM Celebrities); 

2.EXISTSを使った場合(速い)

SELECT P.name
FROM Personnel AS P
WHERE EXISTS (SELECT
FROM Clelebrities AS C
WHERE P.birthday = C.birthday);
 

なぜ、EXISTSの方が速いか?その理由は以下の2点です。

もし結合キー(この場合はbirthday)にインデックスが張られていれば、Celebritiesテーブルの実表は見に行かず、インデックスのみを参照する。
もしCelebritiesテーブルがインデックスを持っていなくても、優れたオプティマイザならば、birthday列をソートした一時テーブルを作り、2分探索することで、全表走査よりも効率的に検索を行なう。

繰り返す。サブクエリーを引数に取る場合、IN述語を使うな

EXISTSで代用でき、しかもたいてい、その方が圧倒的に速いからです。
INの引数にサブクエリーを取る場合、DBは、まずサブクエリーから実行し、その結果を一時的な作業テーブル上に格納します。つまりインライン・ビューを作るのです。その後に、その作業テーブルを全件走査します。これは、多くの場合、非常にコストがかかります。EXISTSを使えば、既に見たように、一時テーブルなど作成されません。
ただし、ソースコードの可読性という点において、IN述語はEXISTS述語に勝ります。要するに、IN述語で書いた方がぱっと見て意味が分かりやすいコードになります。従って、IN述語を使っても十分短い応答時間が確保されているなら、そのSQL文を敢えてEXISTS述語で書き直す必要はありません。

・IN述語の引数リストには、最もありそうなキーを左寄せしろ

なぜなら、INは、左から右へ引数を評価し、見つかった時点でtrueを返しそれより右の引数は見ないからです。以下の2つのSQLを比較してください。

1.遅い(かもしれない)

SELECT *
FROM Address
WHERE prefecture IN ('鳥取', '徳島', '東京', '大阪');

2.速い(かもしれない)

SELECT *
FROM Address
WHERE prefecture IN ('東京', '大阪', '鳥取', '徳島');

・EXISTS述語のサブクエリー内では、SELECT * を使え

サブクエリーのSELECT句を書くには、以下の3つの選択肢があります。

①EXISTS (SELECT * FROM …)
②EXISTS (SELECT カラム名 FROM …)
③EXISTS (SELECT 定数 FROM …)

このうち、最も良いのは①です。この書き方は、オプティマイザにどのカラムを使うべきかの選択を委ねることになります。そして、カラムにインデックスが張られていれば、実表を走査する必要はありません。
ただし、例外的に②や③の方が①よりも高速な場合もあります。古いSQL製品の場合は②のように列名を指定した方が速いこともあります。また、Oracleその他の製品では、③のように「SELECT 1 FROM …」など、定数を指定すると高速になります。この書き方は、行へのポインタさえ得られれば、実際の行を読む必要がないことを、DBMSに指摘するからです。
しかし、②は、もはや使う機会はないでしょうし、③の書き方は意味的な混乱を招くので、①を採用するべきです。

・3つ以上のテーブルを結合させる時は冗長な結合条件を書け

Table1:小さい
Table2:大きい
Table3:大きい

上記のようなサイズの3つのテーブルがあるとします。共通のカラムで3つのテーブルを結合するとき、次のように書けます。

SELECT *
FROM Table1, Table2, Table3
WHERE Table1.common = Table2.common
AND Table1.common = Table3.common;

あるいは、次のようにも書けます。しかし、こちらの方が遅くて非効率です。

SELECT *
FROM Table1, Table2, Table3
WHERE Table2.common = Table3.common
AND Table1.common = Table3.common;

なぜなら、2番目のSQLは、最初にTable2とTable3という大きなテーブルを結合した大きな結果集合と、Table1とTable3を結合した小さな結果集合でマッチングを行なうからです。だから、結合条件は、小さなテーブルを最初に書くべきです。
最も良い書き方は、テーブルのサイズが変わっても大丈夫なように、オプティマイザ自身にテーブルのサイズを決定させる書き方です。そのためには、次のように結合条件に冗長性を持たせます。

SELECT *
FROM Table1, Table2, Table3
WHERE Table1.common = Table2.common
AND Table2.common = Table3.common;
AND Table3.common = Table1.common;

もちろん、テーブルのサイズにあまり変化がない場合は、あえて結合条件に冗長性を持たせる必要はありません。

・行数を数えるときはCOUNT(*)よりもCOUNT(カラム名)を使え

このトリックは、インデックスを使います。したがって、これがうまく働くためには、COUNT関数の引数となるカラムにインデックスが張られている必要があります。例えば、

SELECT COUNT(*)
FROM Sales;

よりは、次のSQLの方が速いかもしれない。

SELECT COUNT(sale_id)
FROM Sales;

ここで、sale_idがSalesテーブルの主キーだとすれば、当然、sale_idにはユニークなインデックスが存在します。それを利用するのが、このトリックです。

・WHERE句の抽出条件は、最も制限の強いものから並べろ

抽出条件がANDでつながっている場合は、制限の強いもの、つまりそれによって選択される行数が少ないものから順に並べる方が、効率がよいです。例えば、以下の通り。

1.遅い

SELECT *
FROM Student
WHERE sex = 'male'
AND grade = 'A';

2.速い

SELECT *
FROM Student
WHERE grade = 'A'
AND sex = 'male';

なぜなら、評価がAの生徒の方が、男子学生よりも少ないから。この学校がハーレムのごとき場所なら話は別ですが。

・UNIONは使うな。UNION ALLを使え。

UNIONは、二つの結果集合をマージします。しかし、重複行を排除するためのソート処理にコストがかかります。もし重複を気にしなくてよい場合なら、UNIONの代わりにUNION ALLを使ってください。そうすればソートは発生しません。

・実はインデックスが使用されていないという罠。

皆さんが検索するテーブルには、きっとインデックスが張られているでしょう。インデックスは、行数や列数の多い表を短時間で検索するためのテクニックとしては非常にポピュラーです。その原理は、C言語のポインタ配列と同じです。サイズの大きなオブジェクト配列を検索するよりも、サイズの小さなポインタ配列を検索した方が効率がいい、というわけです。しかも、2分探索による高速検索が可能なよう工夫されています。
さて、Aという列にインデックスが張られているとします。以下のSQLはそのインデックスを使うつもりで、実のところテーブルXXを全件検索してしまっています。

①検索条件の左側で式を用いている

SELECT A
FROM XX
WHERE A * 1.1 > 100

検索条件の右側で式を用いれば、インデックスが使用されます。従って、代わりに

WHERE A > 100/1.1

という条件を使えばいいわけです。あるいは、関数索引を使うという方法もありますが、トリッキーなので推奨しません。

②NULLを指定している

SELECT A
FROM XX
WHERE A IS NULL

なぜなら、インデックスの中にはNULLは存在しないから。NULLは値ではないのです。

③否定形を用いている

SELECT A
FROM XX
WHERE A <> 100

否定形(NOT EQUAL, NOT IN)はインデックスを使用できません。

④ORを用いている

SELECT A
FROM XX
WHERE A > 100 OR B = 'abc'

理由は知らない。とにかくORを使うな。どうしても使いたいならビットマップ索引を張りましょう。

⑤LIKE述語を用いている

SELECT A
FROM XX
WHERE A LIKE '%a'

理由は知らない。とにかくLIKEを使うな。

・結局のところROWIDによるアクセスが最速

もしあなたがROWIDの存在を知らなければ、今すぐに

SELECT rowid
FROM 適当なテーブル名;

というSQLを実行してください。

ROWID
——————
AAAF+OAAIAAABmMABI
AAAF+OAAIAAABmMABK
AAAF+OAAIAAABmMABL

などといった列が選択されるはずです。 ROWIDはどのテーブルでも必ず持っている擬似列であり、そこに格納されている値はレコードの物理アドレスです。つまりROWIDはポインタの役割を果たす。インデックスもROWIDを使用しています。 ROWIDは、セッションが終了すると変化するかもしれませんが、ユーザセッション中は不変であり、Oracleでは常に最速のアクセスが保証されます。

http://mickindex.sakura.ne.jp/database/db_optimize.html

モンティ・ホールの検証

今回はモンティ・ホールをエクセルを使って検証してみたいと思います。

モンティ・ホール問題とは?

モンティ・ホール問題とは以下の様な問題です。
(ウィキペディアを分かりやすい様にアレンジしています。)
■ゲームのルール
①3つのドア(1,2,3)に当たりが1つだけランダムで入っている
②あなたは必ず最初に1番のドアを選択する
③そのあと、司会者が残りのドアのうち1つを開ける
④③で司会者が開けるドアは、必ずハズレのドアである
⑤司会者はあなたにドアを選び直してもよいと言う
Q:あなたは最初に選択した1番のドアから、残りのドアに選び直しますか?
というのがモンティ・ホール問題です。

モンティ・ホール問題の当たり確率を計算

表を使うと直感でも確率が分かり易くなります。モンティ・ホール問題で起こりうるパターンは以下のA・B・Cの3パターンとなります。(○=当たり ×=ハズレ)
ドア番号⇒
1
2
3
パターンA
×
×
パターンB
×
×
パターンC
×
×
最初の選択(1番のドア)で当たりを引ける確率は、パターンA・B・CのうちパターンAのみですので、1/3(33.3%)となります。
一方、残りのドアに選び直した場合、当たりを引ける確率は、パターンA・B・CのうちパターンB・Cの2つですので、2/3(66.7%)となります。
よって残りのドアに選び直した方が当選しやすい(期待値が高い)事が分かります。

エクセルで大数の法則を検証する

それではエクセルで大数の法則を検証してみたいと思います。
最初の選択は1番のドアで固定して、当たりドア番号はエクセルのランダム関数を使って1~3をランダムに選択します。エクセルのセルに”=INT(RAND()*3)+1“と入力すると、1~3の整数をランダムに発生させることが出来ます。

コインを投げて、表が出る確率をグラフにします。(試行回数500回)

試行回数が200回を超えたあたりから、確率が理論値付近で収束している事が分かります。

試行回数200回未満の場合とくに100回未満の場合の確率というのは理論確率から遠く離れている事が分かります。

このように、試行回数が多くなればなるほど理論確率に収束していく事を大数の法則と呼びます。

扉を選び直すべきなのか?

試行回数が少ない内の結果というのは偶然(運)で支配されています。ですのでモンティ・ホール問題に何回チャレンジ出来るかが肝になってきます。
200回以上チャレンジ出来るのであれば、扉を選び直すべきなのは明らかなのですが、問題なのは試行回数が少ない場合、例えば1回しかチャレンジできないような場合、扉を選び直すべきか?というのが難しいところです。
システムトレーダーとしては、たとえ試行回数が少なくて運の要素が強く支配していたとしても、期待値の高い方を選択するべきであると思います。つまり扉を選び直すべきだと思います。
たとえ扉を選び直して外れてしまったとしても(表のパターンAで選び直してしまった場合)、それは結果論なので気にする必要は無く、常に期待値の高い方を選択するという習慣を身につける事の方が遥かに重要だと思います。

偶然の無い世界

 今回は偶然の無い世界について考えてみたいと思います。
この世は偶然の出来事に満ち満ちています。自分の方が実力が上なのに運が悪ければ、自分より実力が下の人に敗れる事も多々あります。とても不条理で不合理な世界です。
ではこの世から偶然という概念が無くなったらどうなるのでしょうか?
偶然の要素が無くなった世界を想像してみたいと思います。

偶然の無い世界

実力のある人は必ず実力の劣る人に勝つ世界。逆にいえば実力の劣る人は絶対に実力のある人に勝てない世界。
どうでしょうか。偶然の無い世界は、とても退屈な世界だと私は思いました。
偶然の出来事があるからこそ、人々はそれに希望を抱き、希望を糧にして目標に向かって努力出来るのです。あるいは偶然起こった奇跡を皆で喜びそれを共有する事が出来るのです。
偶然の無い世界というのは希望を抱く事の出来ない何の面白味も無い世界だと私は思います。

偶然による実力のブレ

では具体的に偶然による実力のブレを見てみたいと思います。想像しやすい様に各実力をスポーツ戦における各チームの実力と想定してみて下さい。

実力平均0.0チームの偶然による実力のブレ

ダウンロード1

こちらが実力0.0のチームが偶然によって起こりうる実力のブレとなっています。
(平均0.0 標準偏差1 の正規分布)
実力は0.0ですが、運が悪ければ-4.0しか力が出せない事もあるし、逆に運が良ければ+4.0という力を出す事ができます。
この-4.0~+4.0の違いは何なのでしょうか?これがまさに偶然(運)なのです。
つまり実力は0.0なのですが、偶然の要素によってのこチームの実力は-4.0~+4.0の間にあると言えます。偶然の要素とはチームの士気であったり、選手の体調がこれにあたるでしょう。
この偶然(運)があるからこそ決着がつくともいえます。もし偶然(運)が無い場合、実力が0.0同士のチームが戦った場合永遠に決着がつかない事になります。
では次に実力平均2.0のチームの偶然による実力のブレを見てみたいと思います。

実力平均2.0チームの偶然による実力のブレ

ダウンロード2

こちらが実力2.0のチームが偶然によって起こりうる実力のブレとなっています。
(平均2.0 標準偏差1 の正規分布)
実力は2.0ですが、運が悪ければ-2.0しか力が出せない事もあるし、逆に運が良ければ+6.0という力を出すことが出来るというのが分かります。
では実力0.0のチームと実力2.0のチームが試合をした場合どうなるか見てみましょう。

実力0.0のチームが実力2.0のチームに偶然勝てる範囲

ダウンロード3

縦線がひいてある範囲が、実力0.0のチームが実力2.0のチームに偶然勝てる範囲となっています。
つまりこの範囲においては、どちらのチームが勝つか分からない実力の拮抗した状態という事になります。
通常、野球でもサッカーでもバレーでも勝負事において白熱するのはこのような実力が拮抗した状態であり、観客はこれを見たいが為に現地に足を運んでいるわけです。
チームの実力が違うのにこのようにどちらが勝つか分からない拮抗した状態になるのは、偶然という概念がある事の恩恵そのものです。
もし偶然という概念がなければ実力2.0のチームが必ず勝つ試合になるわけですから、面白味の全くない試合であり、誰も結果が分かっている試合を見たいとは思わないはずです。
それでは最後に奇跡という偶然を確認してみましょう

実力0.0のチームが実力6.0のチームに偶然勝てる範囲

ダウンロード4

縦線がひいてある範囲が、実力0.0のチームが実力6.0のチームに偶然勝てる範囲となっています。
まさに奇跡的な確率ではありますが、実力0.0のチームが実力6.0のチームに勝てる可能性があります。このようにお互いの実力が離れれば離れるほど偶然勝てる範囲も狭くなってきます。
おそらくこの試合を見ている人のほとんどが実力6.0のチームが勝つであろうと思って試合を観戦しているはずです。
例えば実力0.0のチームを高校生野球チーム、実力6.0のチームをプロ野球チームと置き換えると分かり易いかと思います。
誰も高校生野球チームが勝てるとは思っていないわけです。しかし、偶然が起こりうる確率が低ければ低い程それが実現した時の感動というのは大きくなります。つまり高校生野球チームが奇跡的に勝った場合、観客が大いに盛り上がる事が想像できます。

偶然の恩恵まとめ

偶然というのは時には不条理かつ不合理な側面もありますが、この様に人々に感動や喜びを与える上で非常に重要な概念である事が分かりました。
システムトレードにおいても同様で、システム本来の実力以上に運よく偶然勝つ事もあれば、運悪く偶然負けることもあります。
偶然というのは避けることの出来ない普遍的な事だということを理解したうえで、もし偶然運よく実力以上に勝てた場合は大いに喜べば宜しいかと思います。
逆に運悪く実力以上に負けた場合、悲しむ必要はありません。偶然負けただけなのですから気にしてもしょうがないです。切り替えていきましょう。
偶然という普遍的な概念を理解したうえで、自分の都合の良い方に解釈すればいいということになります。ポジティブシンキングで行きましょう。

体感価値や確率を定量化するプロスペクト理論

今回はプロスペクト理論について解説させて頂きます。プロスペクト理論を一言でいうと人間が感じる価値や確率(体感価値・確率)を定量的に表現するために使う理論です。
プロスペクト理論はカーネマン博士によってノーベル経済学賞を受賞されております。

プロスペクト理論の重要な概念2つ

  • 価値関数
  • 確率加重関数
プロスペクト理論には価値関数と確率加重関数という2つの重要な概念があります。難しそうな言葉ですが、内容はいたって簡単です。百聞は一見にしかずという事で早速下記グラフをご覧ください。

価値関数

こちらのグラフが価値関数というグラフで、価値について人間が感じる体感価値と実際の価値との関係を表したものです。
横軸が客観的価値(実際の価値)を表しており、縦軸が主観的価値(体感価値)を表しております。
客観的価値(実際の価値)が+1.0の場合の主観的価値(体感価値)は+1.0という事が分かりますが、客観的価値(実際の価値)が-1.0の場合の主観的価値(体感価値)は-2.25となっています。
この主観的価値(体感価値)の不均衡が何を意味しているのかと言うと、人間は得したときの体感よりも、損をしたときの心理的(体感的)ダメージの方が大きいという事が定量的に表わされています。
つまり、客観的には±1.0の価値でも、体感ではプラスの場合は+1.0ですがマイナスの場合は-2.25というプラスの場合の2.25倍の心理的(体感的)ダメージがあるという事です。
例えば、100万円利益を出したあとに100万円損しても実収支は±0円なのですが、心理的(体感的)には-125万円損した気分だという事です。(100万×1倍 + -100万×2.25倍 = -125万)

価値関数の計算式

出所⇒wiki
上記グラフでは α=0.88、β=0.88、λ=2.25 の推定値を使用
出所⇒Kahneman and Tversky(1992) のレポートの311p参照

確率加重関数

こちらのグラフが確率加重関数というグラフで、確率について人間が感じる体感確率と実際の確率をの関係を表したものです。
横軸が客観的確率(実際の確率)を表しており、縦軸が主観的確率(体感確率)を表しております。
赤い点線が本来の確率です。ここで注目して頂きたいのが、青い矢印の部分と黄色い矢印の部分です。
青い矢印の部分は本来の確率よりも体感的に過大評価してしまう部分で、逆に黄色い矢印の部分は本来の確率より体感的に過小評価してしまう部分です。
つまり、確率が低い場合人間は体感的に過大評価する傾向にあり、確率が高い場合人間は体感的に過小評価してしまうということです。
例えば、宝くじに当選する事(当選確率1/2000万)には期待するが(過大評価)、交通事故にあう(交通事故確率=1/195)なんて考えていない(過小評価)といった感じです。

確率加重関数の計算式

出所⇒wiki
上記グラフでは γ=0.61、δ=0.69 の推定値を使用
出所⇒Kahneman and Tversky(1992) のレポートの312p参照

プロスペクト理論から導かれる答え

一つ目のグラフ(価値関数)も二つ目のグラフ(確率加重関数)も共に、客観的価値・確率(実際の価値・確率)と主観的価値・確率(体感価値・確率)の関係を表したものです。
この体感価値・確率(心理)という漠然としたものを定量的に表す事ができる点でプロスペクト理論というのは非常に面白いと思います。流石ノーベル経済学賞を受賞された理論だけの事はあります。
価値関数によって、価値に関して人間は利益より損失を苦痛と感じるという事が分かりました。これは損失を苦痛と感じるがゆえに損切り出来ずに損大利小のトレードになってしまう心理、又は利益がでるとすぐに利確してしまう心理を証明しています。
確率加重関数によって、確率に関して人間は低確率のものを高く見積もる傾向にある事が分かりました。これは勝率30%のシステムを運用しているのに、毎回利益を期待してしまう心理の証明であります。実際勝率30%というのはほとんどが損切りです。システムを開発した自分でさえも嫌になる程に損切りばかりします。
システムトレーダーの場合、価値関数に関してはシステムが自動で売買を執行しますので特に関係ありませんが、確率加重関数の点については理解しておく必要があります。
自分の運用しているシステムの勝率がいくらで、どのぐらい連敗する可能性があるか把握していても、頭で分かっていてもいざ実際連敗するとガッカリしてしまうものです。
そういう時は私たちがシステムトレードで自動売買している理由を思い出してください。相場は自動売買に任せて、この有限で貴重な時間を相場以外に使えるというのがシステムトレーダーの最大の強みなハズです。
折角自動売買しているのに、取引の度に一喜一憂していては本末転倒です。システムが正常に稼働しているかのチェックだけしてトレード結果は無視する位が丁度いいです。
たとえ米国雇用統計が不利な方に3円飛ぼうとそれだけで一発退場するようなリスクは取っていませんから、どんと構えていきましょう。その為に統計分析してリスク管理している訳ですから。

おまけ:心理テスト

最後に、wikiをアレンジした質問をしてみたいと思います。
Q:あなたは以下の選択肢 aと b のどちらを選びますか?
・a ⇒ 100万円が無条件で手に入る。
・b ⇒ コインを投げ表が出たら300万円手に入るが、裏が出たらハズレ。
こいう問題がでたらとりあえず期待値を計算してみましょう。
aの期待値 = 100% × 100万円 = 100万円
bの期待値 = 50% × 300万円 + 50% × 0円 = 150万円
以上の事よりbの方が期待値が高い事が分かりました。では期待値が高いという理由一点のみでbを選択するべきなのでしょうか?
正解は、プレイできる回数によるです。aの場合外れるリスクはありませんが、bの場合は50%あります。つまり50%に収束するまでの試行回数をプレイできるかどうかが重要となります。
もしこのゲームに1回しか挑戦出来ないのであれば、私は迷わずにaを選択して無リスクで100万円を貰います。
1回しか挑戦出来ないのに、例えばあなたがbの方が期待値が高いからbに決まってるやん!(ドヤァ)と選択してコインが外れた場合、仕方ないと諦められますか?
価値関数によると、150万円 × 2.25 ≒ 338万円を失った心理的(体感的)ダメージを受けることになります。
むろんこのゲームに400プレイ程度挑戦できるのであれば、迷わずbを選ぶべきですが。
確率別の収束速度
つまり、期待値が高いからという1つの理由のみで判断するのは危険だということです。ゲームに参加するにはまず期待値がプラスであることは当然ですが、確率が収束するだけの試行回数プレイできるかを確認してからそのゲームに参加するか判断する必要があります。