v0.9がリリースされています。NetworkモデルのClassifierを扱うときに便利なDNNClassifier周辺で罠が多いことが分かったので備忘録としてメモを残しておきます。Learn)ベースのものです。いろいろな罠の話をしていますが、TensorFlow本体の話では無いのでご注意ください。結論からいうとv0.9は実用段階では無さそうです。v0.9はmodelをsave/restoreできないいきなり致命的な問題です。要するに学習したmodelを使いまわせないというもの。当然のように、IssueやStackOverflowでは同様の質問が乱立しています。workこれはv0.8まであったTensorFlowDNNClassifierがv0.9からDeprecatedになってDNNClassifierの利用を推奨される流れで入ったバグのようです。restoreをする必要がある場合、2016/07/18時点ではv0.8の利用が必要になります。いろんなIssueで話題になってるので、この問題は近いうちに修正されるでしょう。restoreはおいといて、ひとまずコードをTensorFlowDNNClassifierからDNNClassifierに移そうか、、と思うのですが、v0.9のDNNClassifierはパフォーマンスがかなり悪いです。TensorFlowClassifierで学習とテストデータ、およびstepを固定し、fitにかかる時間とclassification_reportを計測してみると以下のような結果に。[sec]まず、DNNClassifierはTensorFlowDNNClassifierと比較してprecisionが10%ほど向上。デフォルトのハイパーパラメータが一部異なるのでしょう。原因は不明確ですが、ひとまず結果が良くなる分はまだ良いです。問題は、elapsed_timeが68秒から7359秒とハチャメチャに長くなってる点。これだと使い物にならなさすぎるので、Stackoverflowに投げてみたものの、2016/07/18時点ではまだ回答はありません。TensorFlowDNNClassifier?このとおり、TensorFlowDNNClassifierは近い将来DNNClassifierに乗り換える必要があるものの、このパフォーマンス差はだと乗り換えは辛いです。何もいいことが無い印象です。v0.8のTensorFlowDNNClassifierはv0.9と比較すると遅いこれまでの通り、v0.9は辛い状態かつmodelをsaveできない状態なので、v0.9でチューニングしたハイパーパラメータでv0.8を利用してmodelをsaveさせることにします。v0.9では実はTensorFlowDNNClassifierはDeprecatedになりながらも内部では全体的にパフォーマンスが向上してるようですね。ここまでくるとDeprecaedにするのもやめてくれ、、、と思い始めます。detected")が出てコケます。ちなみにsaveを呼び出さない場合はコケないのでこれも地味に辛いです。回避方法としては、「Optimizerは使わない」を選ぶしか無いのかな。rateを調整できないのが辛いですね。steps=steps)ちなみにv0.9ではOptimizerを指定したTensorFlowDNNClassifierでsaveを呼び出してもエラーにはなりません。modelデータの保存もできてないので、このバグが修正されたときにOptimizerのバグも治っているかどうかは不明です。利用save/restoreのバグが修正されるであろう、v0.9.1相当のリリースを待つDNNClassifierのパフォーマンスが上がってたらTensorFlowDNNClassifierから乗り換える。上がってなかったらしばらく使うのような感じでしょうか。TensorFlowの知識は少ないので、誤った情報がある場合はぜひ教えていただきたいです。00:35ruby唐突の約1年ぶりのエントリーになりますが、itunes-clientの親戚みたいなかんじのkeynote-clientを作ってみました。GithubRubyGemこれは何?itunes-clientと同様、高レベル(のはず)なAPIでKeynoteを操作できます。保存doc.saveスライドを追加するあたりのAPIがかなり微妙なんですけど、Keynoteのマスタースライドを一意に指定する方法が名前しか無く、これも言語環境によって名前が同じドキュメントでも変わってしまうという、かなり辛い仕様なので対応方法が結構難しい感じです。頑張ればどうにかできそうか。本当はシンボルを指定したい。あとスライドはappendするとき、またはappendした後にタイトルや本文を更新できるようにすれば、シンプルなスライドであればひと通りの自動生成できそうかな。背景@k0kubunがLTのスライド作らずにスライドを作るツールを夜な夜な作ってるのを見てゲラゲラ笑ってたのですが、AppleScriptで疲弊してそうな印象が強かったので、itunes-clientの知見をどうにか活かせないかなーと思ったのと、JXAを一度使ってみたいなーと思ってたので、その練習がてらがっと書いてみました。JXA、謎仕様が依然多いですが、少なくともAppleScriptよりだいぶ書きやすいので、感覚つかむまでの速度はだいぶ速くいけました。md2keyもJXAに切り替えちゃってもいい気もしますね。今後スライドのタイトル、本文くらはいじれるようになると実用段階になると思うので、そうしたらmd2keyの下地をいい感じにしてあげられないかなーと企んでます。18:24AppleScriptたまに社内のイベントなんかでBGM担当になることがあって、後日「こういう曲をかけたよ」を伝えるのに毎回丁寧にエディタで書いてたのですが、さすがに2時間分のプレイリストなんかを作ると写経が面倒くさくなったのでAutomatorで整形データを作れるようにしてみました。サービス化したので、iTunesから実行できる。いいけど、Automatorいじったの初めて。アーティスト名」のフォーマットでクリップボードに追加してくれます。あとは、エディタなり何なりにペーストしてよしなにやればOK。playlist」でいけるようにしたかったけど、Automatorで実現する方法がよくわからなかった。FISHMANSのサイトで使ってるmiddlemanのバージョンは、長らく3.2.0を使っていたのですが、いい加減そろそろ最新のバージョンにあげておくか。思ったところ、結構ハマったのでメモ。updateすると、基本的にはOK。Gemfileのdiff的にはこんなかんじ。0.2.3'renderされるページの内容を確認していたところ、基本的に問題ないように見えつつ、blogページだけ何も出力されません。(bodyがカラ)何か仕様が変わったんだろうと思いつつ、ChangeLog見てもよくわからないな。途方に暮れて検索検索。wrap_layoutの、ところ気になるIssueを発見。3.3.2見事これでした。...にしないとダメな模様。これで手元でも正常にbodyが出力されるようになりました。=.って、書いてるのが該当する話の模様。01:12rubytravis-blink1これは何?blink(1)という、USB接続で発光するガジェットをhmskさんからいただいたので、遊びでつくってみたgemです。指定したgithubのプロジェクトについて、TravisCIの結果を発光して通知してくれるものです。CIが実行中のときは黄色で点滅、テストに失敗したときは赤色で点滅、テストが通ったときは緑で発光します。動作の様子はこんなかんじ。テスト失敗時テスト成功時blink(1)がおもしろいのは、プログラマブルに発光できること。色や点滅時間など、ことこまかく調整できるので、任意のイベントの通知として発光させることが可能になります。いろんな言語からblink(1)のAPIを叩くクライアントがあるのですが、rubyだとrb-blink1がひとまずよさそう。travis-blink1でも内部で利用しています。させるには、これだけでOK。remoteの結果から、TravisCIの状態を監視。katsuma/itunes-clientなんかのように「ユーザ名/プロジェクト名」を指定すればOKです。雑感blink(1)は、できることがシンプルなので、すぐに試せるのはいいですね。天井からぶら下げるなどして、hueみたいに照明代わりにしみても楽しそうです。entriesHomeAboutこのBlogはクックパッドに勤めるWebエンジニアがLLネタや情報技術について直感で思ったことを何も考えず発信するサイトです。コメントやお問い合わせ、執筆依頼などは@ryo_katsuma宛のmention、またはメールなどでお待ちしています。