はてなブックマーク

かつて、Streaming APIで大量のつぶやきをリアルタイムに「保存する方法」を紹介しました（cURL編・Python編）。つぶやきはJSON形式で保存していましたが、そこから何かを見出すためにはまず、JSON形式のデータを処理できなければなりません。ここではその方法を確認します。 Pythonで簡単に処理する方法を、@nokunoさんが紹介しています（Twitter Streaming APIの使い方）。cURLで取得したつぶやきは、1行に1つずつファイルに格納されるので、次のように1行ずつ取り出してJSONデータをパースすればいいようです（ここではtweet['text']、つまりつぶやきの本文だけを取り出しています）。 #!/usr/bin/env python import sys, json for line in sys.stdin: tweet = json.loads(

ファインマンがギャフンとなったという「10の100乗のタンジェント」。Windows 7, 8のcalc.exeでは計算できたが，Windows 10の電卓ではできない。Androidの電卓はOK。OS XとiOSの計算機は当然ながらNG。 — Taro Yabuki (@yabuki) April 16, 2016 使っているのは整数の加算と乗算だけで、オーバーフローしているわけでもないのに正しく計算できない例を先日紹介しました（フェルマーの最終定理の「反例」（電卓編））。 文明が発達しすぎた果てに電卓を作れなくなってしまうというのはSFでよくありそうな話ですが、時代の先を行っているというAppleの主張は確かに正しいのかもしれません。（参考：ロストテクノロジー(Wikipedia)） 小数が出てくればいろいろ問題があるのは知っていても、電卓を使った整数の計算を疑う人は少ないのではないで

「3以上の整数nについて、aのn乗+bのn乗=cのn乗を満たすような整数a, b, cは存在しない」というフェルマーの最終定理（フェルマー・ワイルズの定理）は、1995年にアンドリュー・ワイルズによって証明されました。「証明された」とは言っても、その証明を読んで納得できるのは、ごく一部の数学が得意な人に限られる残念なことです。 数学は苦手だからちょっと計算して雰囲気を味わおうと思っても、今度は計算が得意じゃななければなりません。たとえばこんなことになります。 a=139, b=954, c=2115, n=3 C言語 Java a=25165824, b=33554432, c=37748736, n=3 Bash a=5999856, b=99992800, c=100000000, n=3 Google (WolframAlpha) Perl AWK JavaScript (Schem

Swarmについてのメモ SwarmはSanta Fe Institureを中心に開発されたマルチエージェント・システム・シミュレーションのためのライブラリである。このライブラリはObjective-CまたはJavaで利用することができる。 ここではSwarmの利用方法を解説する。インストール方法はWindowsに特化したものだが、それ以外は利用プラットホームによらない内容になっている。 Swarmについて知るためにはまず、Swarm Development GroupのTutorialにあるスライド（1,2）をみるのがいいだろう。ただし、この資料はObjective-C用に書かれたものである。Java用に修正したものはこちら（1, 2）。 このサイトにある資料 links 開発の際に役に立つと思われるインターネット・リソースへのリンク install 開発環境のインストール方法（Wind

Windows上のLaTeXでヒラギノ（和文・欧文）を使う方法を紹介します。TeX Liveを前提にしています。 和文フォントを使うだけの場合 kanji-config-updmap statusとしてヒラギノがインストールされていることを確認してから、 kanji-config-updmap -user hiragino-pron（フォントを埋め込まない場合はkanji-config-updmap nofont） ヒラギノ従属フォントを欧文フォントとして使う場合 上の作業に加えて，コンソールで以下を実行します。 tlmgr update --self tlmgr repository add http://texlive.texjp.org/current/tltexjp tltexjp tlmgr pinning add tltexjp hiraprop tlmgr install h

自分のコードを出力するプログラム 「プログラミング言語なんて何でも同じ」っていうのはチューリングの意味では正しいのかもしれないけど。 数年前、スタンフォード大学の学生たちは、自分自身を印刷する最短のFORTRANプログラムを見つけようと張り切ったこともあります。（中略）こうしたことは時間の浪費ではないと私は考えます。さきほど引用したベンサムも、こうした遊びのもつ｢有用性｣を肯定しております。彼は次のように述べています：「それどころか、これ以上に明白な有用性は何もない。もし喜びの源となるのでなければ、有用性の特徴は何に基づいたらよいのであろうか。」—Donald E. Knuth, ACM Turing Award Lecture アイディア プログラムは2つの部分A,Bからなる。Aのコードを<A>、Bのコードを<B>とする。 Aは<B>を記録する。 BはAの記録から<B>を知り、 <B>を

不完全性定理のLisp, Mathematicaによる記述 Lisp code / Mathematica notebook プログラミング言語なんてどれも同じと思っている人は下の3つをJavaやC++で書いてみてほしい 不完全性定理についてのゲーデルの証明の一部 停止問題の解決不可能性についてのチューリングの証明 LISP式がエレガントであることを証明できないというチャイティンの証明 ライプニッツ「役に立たないパラドックスは無い」（チャイティン「知の限界」） ミンスキー「ゲーデルはLispを思いついておくべきだった。もし彼がLispを思いついていたならば彼の不完全性定理の証明はもっと簡単なものになっただろう」（ホフスタッター「メタマジック・ゲーム」） 次の2冊の本はLispといってもSchemeのようなオリジナル言語が使われている。ここではCommon LispとEmacs Lisp、M