カテゴリー別アーカイブ: よもやま

パーセプトロンによる分岐予測

PC Watchの後藤氏によるアーティクル “AMDの次世代CPUコア「ZEN」のニューラルネットワーク分岐予測機能“。注意すべきはCPUの分岐予測関連は完全に秘密のベールに包まれており、AMDが先行しているかどうかはよくわからないということに尽きる。AMDにしても殆どの情報は非公開でありほとんど情報はない。

恐らく、単層のパーセプトロンだろうってことぐらいしか、恐らくほとんど情報はないのではないか。ただ、実用上はいわゆるオンライン学習になっているだろうとも考えられる。ただ、そうすると学習したモデルの揮発からの保護はどうなっているのかという問題も生じる。一旦、学習させ尽くしてしまってコールドスタート時からはファクトリープリセットのモデルに戻すというのならばこの問題は生じないが。

ただ、パーセプトロンでも通常、過学習の問題は生じるので、コールドスタート時はファクトリープリセットのモデルに戻すというのも悪い発想ではないとも考えられる。

 

AIの「よくある誤解」10個、ガートナーが見解

さて、クリスマスです。細かい話をするのもないので、この発表から。

ガートナーの発表した、AIのよくある誤解はすごくわかりやすいです。

  1. すごく賢いAIが既に存在する。
  2. IBM Watsonのようなものや機械学習、深層学習を導入すれば、誰でもすぐに「すごいこと」ができる。
  3. AIと呼ばれる単一のテクノロジが存在する。
  4. AIを導入するとすぐに効果が出る。
  5. 「教師なし学習」は教えなくてよいため「教師あり学習」よりも優れている。
  6. ディープ・ラーニングが最強である。
  7. アルゴリズムをコンピュータ言語のように選べる。
  8. 誰でもがすぐに使えるAIがある。
  9. AIとはソフトウェア技術である。
  10. 結局、AIは使い物にならないため意味がない。

1.と3.はものすごく関連があり、機械学習という単一の物があるわけではなく、機械学習というのは複数の技術を括る一つの目線に過ぎないのだと思います。従って、機械学習と称する技術は複数の学問分野にまたがっています。

当然ながら、深層学習は最強でもなんでもなく、適切な分野を選べば力を発揮するアルゴリズムの一つです。選択を誤れば深層学習で何も得ることはかないません。

まあ、ガートナーと契約しているわけでもないので、全文は未見ですが、9はソフトウェア技術と限定してしまうとひどいことになるでしょうね。確かに。

 

Visual Studio Code で Stan 拡張を作ってみようとする

今日はVisual Studio Code Advent Calendar 24日目のはずです。さて、Visual Studio Codeを使っていて、はたと困ったのはStanの機能拡張がなかったことです。ないのならば作ってしまえホトドギスで作ってみようとしました。まず、開発環境を用意しようとしました、それほど長時間使うわけでもないし困ったらサクサク作り直したいので、Microsoft AzureからA1v2を1インスタンス用立てて作ります。Linux環境を作らないのは手っ取り早くリモートデスクトップでつなぎたいからです。

とりあえず、必要なものを考えてみます。まず、StanのテストはR上で行うことにして、RStanをベースにします。RのVisual Studio Codeの機能拡張は既にあるし、まあ、Visual StudioのR拡張でとりあえずなんとかなるだろうと。そして、qiitaのVisual Studio Code はじめての拡張機能開発を参考にして、以下の物を。

  • Windows Server 2016
  • Visual Studio 2017RC
  • Microsoft R Open
  • Visual Studio Code
  • node.js
  • git

さしあたり、コードのレポジトリをgithubに作って作業開始。

と思っていたら、以下の記述がLanguage Extension Guidelinesに。

Syntax highlighting, snippets, and smart bracket matching can be implemented declaratively with configuration files and don’t require writing any extension code.

どうやら、コードを書かずに目的を達成できそうである。今回は拡張機能を作るのが目的ではなく、あくまでStanのためのよりよい環境がほしいだけなので、楽ができるのは歓迎である。

さて、先ほどから語っているStanについて、少々触れておく。Stanはベイズ統計モデリングをするための一種のドメイン特化言語である。Rなどとことなり、ベイズ統計モデリングのためにあるので汎用の言語ではない。R用のStanパッケージであるRStanやPython用のPyStanと用いられることが多い。言語自体は最終的にCのコードになりコンパイルされる。

とりあえず、yeomanで雛形を出力させると、必要なファイルが入っているようなので無駄にはならなかった感じですね。あとは、ちまちまと予約語とかを整備していけばある程度使える形にできるのかな?

と、思ったら、Ivan Bocharov氏のstan-vscodeが。脱力感、漲る。

地味に便利なAzure DevTest Labs由来の自動シャットダウン

先日のMicrosoft Azureの機能拡張でDevTest Labs由来の自動シャットダウン機能が仮想マシンにつきました。この機能のリリース前はAzureの機能の一つであるAzure Automationを使って自動シャットダウンを実施する必要がありました。特に単価の高い、Hadoopなどのクラスターなどは確実にシャットダウンしないと金銭的に破滅しますので重要です。

この機能の設定はとても簡単です、管理支援機能であるAzure Automationの設定と比較しても簡単です。勿論、できることは限定されますが、自動シャットダウンというものを実現するには十分です。

インターフェイス上は仮想マシンのスケジュールのところにあります。

Screen shot of Azure Portal

分析者目線でF#なAzure Notebookにトライしてみる

この記事はF# Advent Calendarの19日目と推定されます。さてさて、F#の話です。

先日、Azure NotebooksがAzure Machine Learningから独立するような形でアップデートし、F#がAzure Notebooksで使えるようになりました。Azure NotebooksはJupyter Notebookベースの環境で現在、R、Python 2/3、F#が使えます。従って、F#環境をいろいろいじって色々確かめようと考えたわけです。主に、分析者目線で。

さて、この環境がどのような形でホストされているのか気になります。特に、分析者として使うならF# DataとかMath.NETとか使ってみたいですしね。環境の方は意外な形でわかりました。

#Rと参照を打った時に出た候補で環境に関してはもろばれと言ってよいかと思います。おそらく、.NET Coreとかで実現された.NET環境を何らかのLinux上に構築しているかと思います。

もともと、分析者目線でと始めたのですが、今のところ、F# Dataとか、Math.Net とかを参照設定するのに成功していないので、今のところはF#のテストコードを手軽に試すといったことしかできていません。

ただ、Azure Notebooks特にF#はまだ初期のプレビューにありますので、これからガンガンとリクエストを出していこうかと思います。

それでは。

追記

2017/01/13

Paket を使ってF#にライブラリを組み込むことが可能なようです。

 

Jubatus Client for .NETを実装中

オンライン学習フレームワークとして知られる、Jubatusの.NET用のクライアントを実装中です。MessagePack RPC for CLIで楽ができるかと思ったのですが、どうも更新されていないようでMessagePackのシリアライザとの間でバージョンが厳しいことになっているようでRPCから再実装中です。ただ、現在作っているコードはJubatusとの通信しか想定していないのでクライアントライブラリにべったりと実装されています。現在は、プライベートなレポジトリでせこせこといっています。

とりあえず、get_configの実装はできているのでエビデンス代わりにぽとぺたと。もう少し、作ったらパブリックなレポジトリに展開します。

{
  "method": "PA",
  "converter": {
    "string_filter_types": {
      "detag": { "method": "regexp", "pattern": "<[^>]*>", "replace": "" }
    },
    "string_filter_rules": [
      { "key": "message", "type": "detag", "suffix": "-detagged" }
    ],
    "num_filter_types": {},
    "num_filter_rules": [],
    "string_types": {},
    "string_rules": [
      { "key": "message-detagged", "type": "space", "sample_weight": "bin", "global_weight": "bin"}
    ],
    "num_types": {},
    "num_rules": []
  },
  "parameter": {}
}

MySQLの怖い話

MySQLのSQLにはGROUP BY に特殊な特性があります。大多数のSQLではGROUP BY に指定されていない列をSELECT文で直接射影することは許されていません。

例えば、SELECT NAME FROM CUSTOMERS GROUP BY USER_IDのようなSQLはSQL Serverなどでは実行できません。なぜなら、USER_IDでグループ化しているためNAMEは確定しないためです。

ところが、MySQLではUSER_IDでグループ化して、それ以外の列をなんとなく取得できてしまいます。もし、NAMEがUSER_IDで一意に定まる場合には何らかの結果が得られる可能性はありますが一意に定まらないケースのほうが圧倒的に多いと考えられるので十分に書いている内容に注意してください。