Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Yukitoshi Suzuki
    @yukitos
    1880年当時、10年間のUS国勢調査結果を分析するには8年かかっていた、と。
    pantograph punchはパンタグラフ式のパンチカードかな
    1890年に国勢調査局に登用されたHerman Hollerith氏によってpantograph punchが導入されると1年で終わるようになった。
    それでも1年。
    しかし最近では国勢調査だけでなく、WorldBankなどの膨大なデータがネットで公開されていて、それらの分析は実に数秒で終わる。素晴らしい。
    というわけで物理的なツールからプログラム的なツールを必要とするようになりました。
    Yukitoshi Suzuki
    @yukitos
    それではF#と型プロバイダーを使ってデータ分析する方法を見ていきましょう。というのが導入部。

    データサイエンスのワークフローは

    1. データへのアクセス
    2. データの分析
    3. データの可視化

    の3つ。

    データサイエンティストに言わせると、1が一番大変。
    CSVをダウンロードしたら、各列が何を表すのか特定して、値が抜けている部分はどう扱うのか決めないといけない。
    REST形式のサービスで取ってくるのであれば、JSONの形式を確認して、対象にすべきデータを抽出しないといけない。
    Yukitoshi Suzuki
    @yukitos
    でもF#なら型プロバイダーを使えばOK。素敵。
    じゃ何故F#を使うのか。理由は4つ。
    1. データへのアクセスが簡単にできる。 型プロバイダーで。
    2. 間違いが少ない。F#の型システムとかコードが簡潔に書けるとか。
    3. 便利でスケールしやすい。Pythonの簡潔さとJITベースの言語のいいとこどり。MBraceとか使うとクラウド上に展開できる。
    4. 連携性。型プロバイダーでR言語と連携できる。FORTRANとかC言語とかとも簡単に連携できる。
    Yukitoshi Suzuki
    @yukitos
    早速World BankとOpen Weather Mapからデータを取ってくるコードの紹介。
    (昼休みここまで。)
    Matsushima, Kazuhiro
    @Gab-km
    本書、TypeProviderの勉強に役立つ感じなんでしょうか?(まだ読んでない
    Yukitoshi Suzuki
    @yukitos
    TypeProviderを作る話はあまり出てこないんじゃないかという気がします
    使う方の話がメインなのではないかと。
    Matsushima, Kazuhiro
    @Gab-km
    なるほど、純粋に「F# で(ビッグ)データ分析やってみた」という感じでしょうかね。
    Yukitoshi Suzuki
    @yukitos
    ですねー
    pocketberserker
    @pocketberserker
    ざっと見た感じ、作るはなさそうですね
    Yukitoshi Suzuki
    @yukitos
    なるほどなるほど
    omanuke
    @omanuke
    自分でTypeProviderを作るメリットってなんすかね。元のデータを型付きにできるとして、それパースして所定の型に変換するのと何が違ってくるのかいまいち把握してナイス(´・_・`)
    あ、静的な方を動的に作れるのか(´・_・`)
    bleis-tift
    @bleis-tift
    パースする方法で得られるのは、(抽象構文木のような)汎用的なデータ構造なので、そこから欲しいデータを取り出すためにインデックスによる指定やら、キー名による指定やらしなければならない。それに対して、TypeProviderはそれを隠蔽し、メンバーとして見せてくれる。
    メタ情報からのコード生成でも同じことが実現出来るため、コード生成で問題ない場合はコード生成でいいと思う。
    細かいこと言うと、消去型の場合はTypeProviderによって目的の情報へのアクセスコードがインライン展開されるので、もしかしたらコード生成よりも効率がいいかも?
    生成型の場合はアセンブリを分ける必要があるため、コード生成よりも効率が悪いかも?
    bleis-tift
    @bleis-tift
    メンバーの遅延生成とかよくわかってないけど、ここら辺を活用すると更に違いがでてくるかもしれず
    あとは、コード生成で大量のコードを生成するとビルドが重くなるけど、TypeProviderだとパースフェーズをすっ飛ばせるからもしかしたらビルド時間をおさえられるかもしれない。この辺りで遅延生成がきいてくるのか?
    omanuke
    @omanuke
    隠蔽はパースするところでアクセスを隠蔽したものを返せば同じですよね?遅延生成とか内部の構造効率化できるかもというのは同意です(´・_・`)
    bleis-tift
    @bleis-tift
    パースでそこまで隠ぺいしたものを返せるかどうかじゃないでしょうか?
    例えば、XMLという汎用的なデータをパースしてXElement等のオブジェクトにしたとしても、必要な各要素へのアクセスにはXPath等、文字列による指定が必要になります
    当然、ある特定の形式(例えばSchemaによって与えられる)のみをパースする専用のパーサーを書けば話は別ですが、それをするよりもSchemaを与えたらその構造を写し取った型を生成してくれるTypeProviderを作った方がより広範囲に適用できます
    omanuke
    @omanuke
    中のデータに応じて型のプロパティやメソッドを生成できるっとこですよね。そこが自分が最初言ってた動的に静的な型を生成できるの意味なんですが、言葉足らずですみません(´Д` )
    bleis-tift
    @bleis-tift
    動的・・・一応コンパイル時なので、動的ではないような?
    omanuke
    @omanuke
    ああ、そこも型を生成する時点で内容に応じてゴニョゴニョできるって意味の動的です…(´Д` )
    pocketberserker
    @pocketberserker
    .NETライブラリを指定して機械的にnullチェックを付加したラッパー型を生成する、とかは考えたりします
    (この書籍でのTypeProviderとは趣が異なるのでこれ以上はここで言及時ませんが)
    Yukitoshi Suzuki
    @yukitos
    コードの最初の方はFsLab basic templateと同じでした。

    そしてこのtemplateは最新のバージョンだと

    // Use Deedle to get time-series with school enrollment data
    let czschool = series cz.``Gross enrolment ratio, tertiary, both sexes (%)``
    let euschool = series eu.``Gross enrolment ratio, tertiary, both sexes (%)``

    という風にプロパティ名が変わっているのでそのままでは動かないということに気がつきました

    Yukitoshi Suzuki
    @yukitos
    openweathermapのapiを読んでJsonProviderに食わせるにはapi keyが必要なのかな。面倒だ。。。