libpq反省事項備忘

投稿日:

 自作の株式売買システムの改修で、反省事項があった。

 このシステムは各種言語の混成で書いてある。株価データをネットからタダでいただいてくる「スクレイピング部」はPerlで、その株価データを使って様々な指標を片っ端から売買試行する「シミュレーション部」はCで、売買指示を閲覧する「ユーザインタフェイス部」はPHPで、それぞれ書いた。株価データを格納するDBにはPostgreSQLを使用している。

 Cで書いた「シミュレーション部」をPostgreSQLにアクセスさせるのには、「libpq」を使っている。

 先日、取り扱い銘柄を増やすため、2500銘柄ほどのシミュレーションを行った。ところがその際、1000銘柄の処理を過ぎるあたりで、メモリリークのために異常終了してしまう現象に悩まされた。それまでは最大でも300銘柄くらいのシミュレーションしかしていなかったので、不具合が伏在したまま、わからなかったのである。銘柄数を一挙に増やしたために不具合が顕在化したわけだ。

 malloc()しているメモリは必ず開放しているし、ループ脱出などで未開放のままどこかへ飛ぶなんてこともしていない。

 だが、すぐに、libpqで大きなメモリオブジェクトを返すselectの後、PQClear()をしていないこと、つまり

PGresult *res;
sprintf(sqlstr, "select * from table where key='%s' order by col;", key);
res = PQexec(con, sqlstr);

などというくだりの後、処理が終わっても

PQClear(res);

……をしていないのが原因っぽいことには気づいた。早速処理の後にPQClear(res)を書き加え、

PGresult *res;
sprintf(sqlstr, "select * from table where key='%s' order by col;", key);
res = PQexec(con, sqlstr);
・
・(処理)
・
PQClear(res);

というふうにした。

 しかし、異常終了が1500銘柄のあたりまで伸びただけで、やはりメモリリークする。

 1か月ばかりも悩んだ後、deleteやinsertのような、いわば「かけ捨て」のsqlも、メモリオブジェクトを返していることに気づいた。そういう部分は、例えば次のように書いて済ませていたのだ。

sprintf(sqlstr, "delete from table where key='%s';", key);
PQexec(con, sqlstr);

 そこで、メモリオブジェクトを取っておいて、終わったらクリアするようにした。

sprintf(sqlstr, "delete from table where key='%s';", key);
res = PQexec(con, sqlstr);
PQClear(res);

 同様に、insertしているところもupdateしているところも、全部そうした。そうしたら、たちどころにメモリリークはなくなり、異常終了直前に起こっていたスラッシングらしい現象による速度の低下もなくなった。

 次に試したいのは、これを

sprintf(sqlstr, "delete from table where key='%s';", key);
PQClear(PQexec(con, sqlstr));

というふうに簡略に書いたらどうだろう、ということである。

時事漠視

投稿日:
結局は地獄の沙汰も金次第

 ああ、醜い、醜いねえ。昔から、「薬九層倍、百姓百層倍、坊主丸儲け」などと言ったもので、薬もこうなってみると九層倍どころの話ではない。……ま、「丸儲け」まではいってないからマシと言えばマシだけれどもさ。無論、今回だけの話をしてるんじゃない、今回を取ってみれば九層倍(9倍)なんてのは言い過ぎで、まずまず良心的ではあろうけれども、抗癌剤での暴利ぶりを見て見ろよコイツら。九層倍どころの騒ぎじゃないだろ。

根性試し相場(笑)

 いよいよヒリヒリヒリヒリ、導火線がチリチリと火花を上げてはじけ縮んでいく爆弾を最後まで持っているのは果たして誰か、テストされるような根性相場になった。おっそろしい。

 私は、今回は「全力売り」の方なんで、まあ、ガタンと力尽きてほしいと思ってますが、それはそれとして、皆様の幸福を祈っていることは確かです、ええ、ええ(謎)。どうかお幸せに(増々謎)。

イギリス人の(かい)(ぎゃく)はさすが年季が入っている

 イギリスの猫官僚。笑ってしまった。

 お堅い我が国政府にも、この程度の諧謔を楽しむ余裕があれば気分もほぐれて楽しいだろうなと思うが、まあ、我々日本人は糞真面目な上に()真面目と来ているから、もしこんなことがあったとしても「税金で猫なんか飼いやがって!」くらいしか言わないんだろうなあ。

【6238】フリュー

投稿日:

 自作の株式売買システムの指示に従い、4日前(8月13日(木))、「フリュー」というアーケードゲーム機等の会社の株を買ったら、今日はこれが非常に高騰している。現在値952円で、1割以上の儲けだ。

 表でご覧の通り、過去5年以内に15回取引して1回も損をしていないわけであるから、まず安心な指標パラメータに基づくものの、さすがにたったの2営業日でこんなにリターンが来るのは、ちょっと嬉しいことである。

扱う銘柄を増やす

投稿日:

 東証の時価総額上位300社と、自分の気に入った銘柄70社あまりを売買シミュレーションにかけてみていたが、ふと気づいてスクリーニングしてみると、私が採用している「過去5年で10回以上の売買実績があり、その勝率が95%以上であるもの」が70社そこいらしかないことがわかった。

 そこで意を決し、東証の時価総額上位1000社の株価データを持ってきて、計算機の性能が激速になったのを生かしてシミュレーション、その中から残ったものを日常シミュレーションにかけることにした。

 昨夜18時51分に株価の取得をはじめて、今13時間あまり。残り2百数十社だ。普段は差分だけをダウンロードする仕組みなのでこんなにはかからないのだが、さすがに初回はものすごく時間がかかる。シミュレーションと違って、株価のダウンロードはデータ提供元である「Yahoo!ファイナンス」の性能に依存しているからである。

 シミュレーションは3時間強ほどで終わるだろうと見積もっている。

SSLと株

投稿日:

 もう10年以上くらいにもなるだろうか、株式売買の指標表示を自動化し、「小魚を釣る」ようにして株を売買している。ところが、先週頃から、その自動化システムが動かなくなってしまった。

 私の株式売買は、夜に自作の株式売買シミュレータを作動させ、そのシミュレーション結果に従って手動で翌日の注文を出すという方法だ。注文そのものの自動化もやればできるだろうが、証券会社がAPIを公開してでもくれない限り、多少技術的な敷居が高いので、そこまではしていない。

 株式売買にはいろいろな指標があるが、その指標を使うのに必要な日数などのパラメータは、銘柄ごとに違う。また、指標ごとにも違うので、色々な組み合わせが出てくる。サラリーマンの場合、何十もの銘柄について、銘柄ごとに手作業でそんな組み合わせ作業を毎日している時間など、あるはずがない。

 そこで、色々なパラメータを組み合わせて、過去のデータを使って売買のシミュレーションを行うのだ。トレーディング用語では「バックテスト」と言う。私のシミュレータでは、現在は1銘柄につき約1万通り程度の組み合わせで売買を試す。

 そのシミュレーション結果で、「90%~100%成功するパラメータの組み合わせ」を抽出して表示するのである。実際のところ、そのパラメータの組み合わせで売買サインが出た時に売買すれば、まず9割は儲かる。1割の確率で損をするのだが、これは10銘柄を束にして注文しておけば、「1銘柄はハズレでも、残り9銘柄は当たり」になる。つまり、期待値として「9割は儲かる」理屈になるわけである。

 だが、私が最も工夫した点は実はそこではない。

 私は勤めており、職務に専念する義務がある。これはサラリーマンなら誰でも同じだと思う。仕事中に株式の売買などすれば、免職になってしまう。そこで、このシミュレーションは、売買サインをリアルタイムの株価で出すのではなく、「前日までの株価でシミュレーションし、翌日約定の注文を出した場合で最適なパラメータの組み合わせ」をシミュレーションにより求める。こうすることで、「前日の夜から当日の朝にかけて、自宅で注文しておく」ことができる。つまり、「サラリーマンが職務外の余暇に自宅で自分の金融資産の管理をしているだけ」という形を整えることができるのだ。

 多くのサラリーマンは株で損をするが、それは、株式の必勝本などには、「今の株価」で売買しなければならないような方法しか書かれていないからだ。これだと、例えば、ある日の経済ニュースなどでその日の株価について知り、夜帰宅して、翌日の注文などを出しても、もう手遅れなのだ。だが、私のシミュレータは翌日の注文で十分なように計算するので、サラリーマン向けなのだ。

 シミュレーションに必要な日々の時系列データは、「Yahoo!ファイナンス」から無料で拝借してくる仕組みである。夜にその日の終値が確定した頃、自動的に株価をダウンロードしてくる。無料で済ませるため、生のhtmlを持ってきて株価データをその中から切り取り、データベースに格納する仕組みだ。

 システムはLinux上で動作する3層クライアントサーバシステムである。ユーザインターフェイスはphpで書かれており、Webサービスだ。株価データは、Perlで書かれたスクリプトを定期起動して、前述のようにしてネットから無料で持って来る。データベースはPostgreSQLを使用している。シミュレーションは高速化を図るためCで書いてある。

 ここ数年、何ら不調なく快調に作動していた。ところが、先週から急に動かなくなってしまった。

 短期の株式売買は毎日の値動きに注意していなければならない。私はこの値段の監視を自動化していたわけだ。ところがこれが動かなくなるとお手上げだ。自分で毎日株価を見なければならなくなってしまう。私もそれなりに忙しいので、何十銘柄もの株価チェックを自分でするなんて馬鹿々々しいことは御免である。

 早く原因を調べなければならなかったが、春の人事異動で職場が変わったりして、手が付けられないでいた。ようやく、今日になって原因を調べることができた。

 調べてみると、どうやら、株価データの拝借先である「Yahoo!ファイナンス」の仕様が変わったようだ。これまで非SSLでもサービスしていたのだが、先週頃完全にSSLに改まったらしい。他方、私の「株価データ拝借スクリプト」はPerlで書いてあり、内部で「wget」を呼び出し、これを用いて「時系列株価ページ」を持って来て、その中からデータを切り出す仕組みなのだが、ハードコーディングしてあるURLのスキームは「http」なのである。

 なるほどよしきた、とばかり、これを「https」に変えて試したが、wgetはブラウザのように簡単にはSSL証明書を扱うことができない。

 ググッてみると、「そういう時にはwgetのオプションに『––no-check-certificate』って書いとけ!」と、どなたかが既に調べて書いておられる。ありがたや。

 そこで、作動させるwgetのコマンドラインは次のようになるわけだ。

$ wget --no-check-certificate -q -O - https://info.finance.yahoo.co.jp/history/?sy=1983&sm=1&sd=1&tm=d&code=銘柄コード&p=1 | nkf -w 

 URLのスキーム部分を「https」にし、「––no-check-certificate」にするだけである。

 株価時系列データのページの作りが変わってしまっているとこれだけでは駄目なのだが、どうやらページの作りは同じらしく、今のところうまく行っているようだ。

売り専業

投稿日:

%e8%b6%85%e9%95%b7%e6%9c%9f%e3%83%81%e3%83%a3%e3%83%bc%e3%83%8828-10-10 まあ、こういう感じの相場だと、一般に売り基本なんでしょうね、普通に考えて。


%e3%83%9d%e3%83%bc%e3%83%88%e3%83%95%e3%82%a9%e3%83%aa%e3%82%aa28-10-10 売っちゃえ売っちゃえ、はっはっは~w。

取り返せ取り返せ

投稿日:

 先月、イギリスのEU離脱国民投票で、持ってた買い玉が暴落し、えっらい目にあったが、先週の参院選がらみがまた、これは波乱万丈と言うか、モノスゴイ腕前の冴えでしたよ私ァ(笑)。

日経平均先週あたりチャート

 こういう状況だったんだけど、私の作ったシステムの指示は……

日産自動車280711ごろ

 いやもう、呵々大笑、っつーか、イギリスEU離脱の損全部取り返してまだ余りある勢い、っつーか、参院選万歳っていうか、アベノミクス様々っつーか。キッシッシッシ……。

EUイギリスああああああ

投稿日:

 いやもう、参った、「細工は流々(りゅうりゅう)……」どころの騒ぎじゃない。大失敗。

 うーん、ちょっと反発したところで早めに切らなくっちゃな……。

 しかし、この中でも救いは、8031「物産」を、予定の利益が出てたから、イギリス投票日の朝の「寄り成り」で売っ払っちまってたことだ。

買い転

投稿日:

 さあ、勝負どころ。一斉に買いのドテン。週末のイギリスの投票でどう出るか、……てところだな。

平成28年6月20日(月)朝の株式

げふぉあっ!!

投稿日:

 このところ好調だったんだけど、えっらい損。

ベネッセ20160510

ベネッセ20160510自作ユーティリティ

 ベネッセコーポレーション、マイナス20%。

 うっわ~っ……。

 無情に損切り。さいなら。