FXシステムトレード Googleによる株価予測的中率70%は本当か？
更新日：2016年6月1日 Googleの以下のレポート Machine Learning with Financial Time Series Data on Google Cloud Platform によると、ディープラーニングの手法を用いてS&P500の騰落を予測し、的中率が70%を超えたらしい。 私がこの話を聞いてレポートを読んだのは2、3ヶ月前だろうか。 私がこの話を聞いて第一に思ったことは「うそつけ」である。 私は個人的には60%を超えるのでも相当難しいと考えている。 いくら最近話題の人工知能といえども、簡単に70%を超えられるものだろうか、そう思ったのである。 私がバックテストでもしそのようなパフォーマンスを得られたら、先ず計算ミスを疑う。 Googleも何か勘違いしているのではないかと思ったが、同時に天下のGoogleがそんなミスを犯すとも思えない。 半信半疑ながら、レポ
Stackを使って楽しくHaskellスクリプティング - Qiita
今までいまいちモチベが上がらなかったHaskellでスクリプトを書くというのが、急に現実的になってしまったので、紹介します。 Haskellでスクリプティングする上での問題点 Haskellはもともと簡単なテキスト処理を書きやすいプログラミング言語ではあるのですが、標準で提供されているライブラリはあまり多くないので、必要に応じてコミュニティーパッケージを導入しなければその力を存分に発揮することができません。 通常のパッケージなら、cabalに依存関係を書けばパッケージマネージャで自動的に（コケることもありますが、理想的には）管理できるのですが、シェルスクリプトやPerl、あるいは最近ならPythonでやるような、コードを直接インタプリタで実行するような形のコードでは、そのような依存関係を自動で解決することは難しく、その上、仮にやろうとしたところで、いつまでもその依存パッケージが新しいコンパ
Java 入門 | JVM のメモリ構造
Revised: 2nd/Nov./2003; Since: 26th/Jan./2003 データ・エリア JVM のメモリ構造は、スタックとヒープに大別されます。ヒープ (Heap) は GC の対象で、JVM 起動時に割り当てられる広大な領域です。Java 仮想マシン・スタック (Java Virtual MAchine Stack) はスレッドごとに割り当てられる、メソッド起動ごとにフレーム (Frame) と呼ばれるデータを出し入れする線形のデータ構造です。クラスのインスタンスなどはヒープに格納しますが、インスタンスのような GC 対象となる動的なデータと、クラス構造などの静的なデータは、別の領域に保持し、静的な構造を保持する領域をメソッド・エリア (Method Area) と呼びます。 図：JVM のメモリ構造 Java 仮想マシン・スタック JVM はプロセスの一つとして、O
Tomcatの最大使用可能スレッド数の見積 - 銀の鍵 (The Silver Key)
我等が働き者、Tomcat。君は一体、どの程度まで多くのスレッドを作成してリクエストをさばく事が出来るんだい？ まず最初にLinuxのスレッドライブラリについて軽く言及しておかねばなるまい。Linuxのスレッドライブラリには二種類ある。 まず、昨今のLinux（Kernel 2.6及びそれ以降）で用いられているNTPL（Native POSIX Thread Library）。これは1:1モデルのスレッドライブラリで、スレッドをプロセスとして実装してある。SolarisなどではいわゆるLWP(Light Weight Process)をしてスレッドを実装してあるのだけれども、Linuxではスレッドもプロセスも同じtask_struct構造体として扱い、COE（Context Of Execution、実行コンテキスト）をそれぞれ用に割り当てて用いているようだ。各プロセスは独立した仮想メモリ
Tomcatの実際のスレッドスタックサイズの推定 - 銀の鍵 (The Silver Key)
Tomcatの最大使用可能スレッド数の見積 にて述べたとおり、Javaバージョンによって、Tomcat/javaが使用することが出来る（最大）スタックサイズが決まっている。しかし、スタックサイズ分だけ仮想メモリがいきなり全部割り当てられるわけでなく、実際はより小さな値が割り当てられていることが多い。スタックサイズを気にせずにスレッド数を決めても、多くの場合は逼迫した状態にはならないものだ。 では実際のところ、Tomcat/Javaはどの程度のスタックを割り当てて稼動しているのであろうか。 一つの例として、以下のようなTomcatを見てみる。 root@server# ps -ef|grep java tomcat 7559 1 0 Mar17 ? 00:07:38 /usr/local/java/bin/java -Djava.util.logging.ma
スタックオーバーフローのハンドリング (Stack Overflow Handling)
作成日：2004.04.12 更新日：2006.02.19 更新記録 (2004.04.12) 3/6、 3/11、 3/13 の日記をまとめて作成。 (2004.05.07) 文章を修正。サンプルコードを追加。 (2005.01.20) alternative → alterante に修正。 (2005.02.13) 追記を記述。 (2006.02.17) linux_stack_info.cpp の実装に誤りがあったので修正。 (2006.02.19) BSD 系OS でのスタック領域情報の取得の仕方を追加 初めに C/C++ でプログラムをしているとつい忘れてしまうのがスレッドのスタックオーバーフローの問題。 最近の OS はスレッド当たり 2〜8MB のスタック領域を持っているため、よほどのことがない限りスタックが溢れてしまうことはない。 だが、再帰や alloca を積極的に使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
