第11回 ボロノイ図の作成（前編） | gihyo.jp
はじめに 本連載では、ごく単純な直線の式からスタートし、線分、多角形とステップアップしながら計算幾何を学習してきました。その最後の締めくくりとして、今回からは、ボロノイ図の作成方法を見ていくことにします。 ボロノイ図とは まず、第1回でも簡単に触れたボロノイ図について、改めて説明します。 平面上に複数の母点が配置されているとき、それぞれの母点に最も近くなる点を集めると、母点ごとに「勢力図」のような領域が形成されます。この領域分割図をボロノイ図（voronoi diagram）といいます（図1）。 図1 ボロノイ図 ボロノイ図の各領域をボロノイ領域（voronoi region）と呼び、ボロノイ領域の境界線をボロノイ辺（voronoi edge）と呼びます。 ボロノイ辺の性質 ボロノイ図において、ボロノイ辺が持つ性質を考えてみましょう（図2）。 図2 2つの母点とボロノイ辺 母点aと
第19回 ロジスティック回帰の学習 | gihyo.jp
前回はロジスティック回帰モデルを紹介し、その負の対数尤度関数まで求めました。 今回はここからロジスティック回帰の学習手順を導きます。 確率的勾配降下法の復習 「学習」というとなにやら高尚で複雑な響きがありますが、機械学習が実際にやっているのは、適当なモデルを決めて「一番良い」パラメータを選ぶことでした。 何を「一番良い」とするかは難しいところですが、機械学習の多くのモデルでは「誤差が最も小さい」あるいは「尤度（観測された事象の確率）が最も大きい」といった指標で「一番良い」を選びます。つまり「関数を最小（または最大）とするwを求める」ところに落とし込まれるわけです。 この「関数の最小化」を「最適化」と呼びますが、これは一般にはとても困難な問題です。1次元空間上の話なら中学や高校の数学で解けますが、機械学習の問題の多くがそうであるように、何万次元もの高次元空間上で厳密解を求めるのは不可能に近い
2017年のHadoopとその仲間たち―開発コミュニティから見た動向 | gihyo.jp
あけましておめでとうございます。 例年、Apache Hadoopを中心に並列分散処理ミドルウェアの動向や展望についてご紹介していますが、今年は特に、Apache Hadoopの開発コミュニティ寄りの視点からお伝えしたいと思います。 2016年のHadoop 2016年9月にHadoop 3.0.0-alpha1がリリースされました。 このリリースは、後方互換性のない変更の影響を、HiveやHBaseのようなHadoopに依存するプロダクトの側で、早期に確認できるようにするためのものです。エンドユーザが利用することはあまり想定されていませんが、新しい機能やインタフェースを確認するために、ちょっと使ってみることはできます。 大きな機能追加としては、HDFSのErasure CodingとYARNのTimeline Service v.2があります。 Erasure Codingは、コールドデ
第2回 ベンチマークに見る仮想化のオーバーヘッド | gihyo.jp
1台の物理サーバー上で複数の仮想サーバーを立ち上げて利用できるサーバー仮想化技術は、柔軟なサーバー運用を可能にする技術として広く使われています。ただ、その一方で注意しなければならないのが、仮想化のオーバーヘッドから生じる性能の低下です。ここでは実際のベンチマーク結果を元に、仮想化技術がどの程度パフォーマンスに影響を与えるのかを検証していきます。 IaaSでスペックどおりの性能が得られない理由 仮想サーバーの作成や削除、リソースの変更といった操作がセルフサービスでいつでも行えるIaaSは、その利便性の高さからすでに多くの企業で使われています。ただ実際に利用したユーザーから不満の声を聞くことも少なくありません。その代表的な例と言えるのが「思ったよりもパフォーマンスが出ない」というものです。 多くのIaaSでは、CPUやメモリといったサーバーリソースが異なる仮想サーバーの選択肢があり、そのいずれ
第2回 memcachedのメモリストレージを理解する | gihyo.jp
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
第18回 ロジスティック回帰：機械学習 はじめよう｜gihyo.jp … 技術評論社
前回までに、分類問題のモデルの一つ「パーセプトロン」を紹介して、その実装を行いました。 パーセプトロンはとてもシンプルでわかりやすいモデルでしたが、「線形分離可能」なデータにしか適用できないという難点がありましたね。 今回は線形分離できないデータにも適用できる分類モデルとして、「ロジスティック回帰」を紹介します。 予測の信頼度 分類器を使って、実際の問題を解くときのことを考えてみます。例えば「メールのスパムフィルタ」などが想像しやすいでしょう。 一般的にスパムフィルタでは、データであるメールを「スパム（迷惑メール）」と「スパムではない（通常のメール）」のどちらかに分類します。そこで、ちょうどパーセプトロンのような2値分類器を使えば無事解決……とは、なかなかいきません。 スパムフィルタを通り抜けてしまった迷惑メールを一つ一つ消す、反対に必要なメールが間違ってスパムと判定されてしま
第16回 並列データ処理系 Apache Tez | gihyo.jp
はじめに 今回は、Apache Hadoop上で動作する並列データ処理系Apache Tezについて解説します。 MapReduceの制約 本連載第13回で述べたように、Hadoop MapReduceは、MapとReduceからなる単純なインタフェースを有し、多くのデータ処理を記述できる汎用的な並列データ処理系（フレームワーク）である反面、その単純さによりいくつかの性能的な課題が存在すると考えられます。 たとえば、複雑なジョブをMapReduceで実行する場合、MapとReduceからなるMapReduceジョブを複数段連ねて実行する必要があります（図1）。当該ケースにおいては、MapReduceジョブの間において、分散ファイルシステムを介したデータの入出力が行われてしまい、当該入出力は、性能の観点においてはオーバーヘッドであるため、ジョブの実行時間を長くする原因の1つとなりえます。
第11回 線形回帰を実装してみよう | gihyo.jp
前回の掲載からしばらく間が空いてしまいましたが、今後は中谷の方で連載を進めていくことになりました。理論編と実践編を交互に進めていくスタイルは継続していきますので、引き続きよろしくお願いします。 線形回帰の復習 今回は連載第8回と第9回で紹介した線形回帰を実装してみる実践編です。 まずは簡単に復習しましょう。 回帰とは、与えられたデータに適した（データを上手く説明できる）関数を求める手法です。点の近くを通る曲線を見つけるときにも用いられます。中でも、基本形として選んだ関数の線形和（式1）から関数を探すのが線形回帰です。 （式1） ここでφ(x)=(φm(x))を基底関数といい、何か適切な関数を選んで固定します。その選び方によってモデルの性能や得られる関数の形などが決まるので、基底関数は解きたい問題にあわせて選ぶ必要があります。 しかし今はわかりやすさを優先して、シンプルな多項式基底（式2）
大学におけるGitHub／GitHub Educationの活用事例 〜慣れることがソーシャルコーディングの道を拓く | gihyo.jp
新春特別企画 大学におけるGitHub／GitHub Educationの活用事例 〜慣れることがソーシャルコーディングの道を拓く あけましておめでとうございます。京都産業大の玉田です。旧年中は、GitHubに大変お世話になりました。みなさまの中にもそのような人が多いのではないでしょうか。 日本でもGitHubを利用する企業が増えてきており、昨年6月に、GitHub Japanが設立されました。一方で、GitHubは未来の開発者の育成についても意欲的に行っています。例えば、GitHub Patchworkという初心者向けのイベントを世界各国で実施したり、GitHub Educationという制度が整備されていたりします。 本稿では、このうちのGitHub Educationに着目し、GitHub Educationとは何か、GitHubやGitHub Educationを大学という教育現場
PHPの生みの親、ラスマス・ラードフ氏インタビュー | gihyo.jp
PHPの生みの親、ラスマス・ラードフ氏インタビュー 2015年12月に無事公開されたPHP7。その公開に先立ってPHPの生みの親であるラスマス・ラードフ氏に話を伺う機会がありました。英語で行われた一時間のインタビューは長大ですがラスマス氏の思想がよく分かる話題が多く、可能な限りそのままの形でお伝えすべく、その模様すべてをお届けします。 なお、インタビューは10月に開催されたPHPカンファレンス2015の講演終了後に行われ、リリースに関する話題などはその時点でのものです。 現在の仕事と生い立ち ―――― まずは、PHPを作ってくださってありがとうございます。今日の基調講演もすばらしかったです。 ラスマス：ありがとうございます。 ―――― いきなりですが、個人的な質問から始めてもいいでしょうか。 ラスマス：どうぞ。 ―――― Etsyではどのようなお仕事をなさっているんですか？ ラスマ
第2回 ストリーミング処理とバッチ処理によるデータ収集 ~ Fluentd編 ~ | gihyo.jp
上記のパラメータを元に生成されたログは下記のようになります。 変更後のアクセスログ time:2015-07-26 08:58:20 +0000 domain:52.69.91.201 host:153.232.253.97 server:172.31.6.70 ident:- user:- method:GET path:/index.html protocol:HTTP/1.1 status:200 size:3256 referer:- agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12 response_time:795 cookie:- set_cookie:Apache=2a4375
第1回 ビッグデータ分析を始めよう | gihyo.jp
ビッグデータ分析エンジンを比較してみると、ビッグデータを処理する一般的なインターフェースとしてSQLが提供されていることが主となっています。こうして見ると、最近流行っているビッグデータを使った分析とは、SQLによる分析が主となっていることがわかります。 さらに、他の機能を見てみると、スケジューリングや依存関係を考慮したジョブの実行、データの可視化などは分析エンジン自体は備えておらず、別途用意する利用必要があります。 このように考えてみると、以下の点が気になってきます。 ビッグデータ分析基盤で何をできるようにするのか？ ビッグデータ分析基盤と考えたときに他にどういったツールが必要になるのか？ SQLによる集計を基にした分析ではどういったことができるのか？ 本稿では、ビッグデータ分析基盤を構築するために必要な分析エンジンではなく、主にその周辺のエコシステムについてを中心に紹介し、ビッグデータ分
第1回 シンプル・軽量な構成管理ツールItamae | gihyo.jp
はじめに はじめまして。クックパッド株式会社の荒井（@ryot_a_rai）と申します。 今回から全5回、構成管理ツールであるItamaeの入門から実際の活用例までを解説していきます。今まで構成管理ツールを使ったことがなかった方から、Itamaeをすでに使っている方まで、ぜひご覧ください。 Itamaeとは Itamaeは筆者が中心となって開発を進めているオープンソースの構成管理ツールです。同様のツールとしてはPuppet、Chef、Ansibleなどが有名ですが、ItamaeはChefに影響を受けています。Chefの記述性・柔軟性を持ちながら、シンプルで導入しやすい構成管理ツールを目指して開発が進んでいます。 構成管理ツールの必要性 Itamaeの解説を始める前に、構成管理ツールを使う理由について軽く考えてみたいと思います。 サーバ構築の自動化 手動構築の手間と時間を減らす 手動構築によ
NIPS2010における発表論文に見る、機械学習最前線 | gihyo.jp
なお、劣モジュラー性についてさらに知りたい方は、チュートリアル［3］が参考になります。 昨年のNIPSでの動向 それでは、昨年のNIPSでの動向を見てみましょう。 Bach［4］は、L∞ノルムが劣モジュラー関数のロヴァース拡張から導出できることを示すことにより, 劣モジュラー性とスパース性との関係を示しました。さらに, この洞察から教師あり学習で用いることができる新しい3つのノルムを提案しました。また、勾配法や近接法が劣モジュラー関数最適化に使えることを示し, 実験によりL1,とL2ノルムを用いるより精度が良いことを示しました。 Stobbe and Krause［5］は、劣モジュラー関数を凹関数の和として分解できる新しいクラス（decomposable submodular function）を定義し, カット問題, マルコフ確率場の最適化, 集合被覆問題などがその新しいクラスの最小化問
第1回 コミュニケーション編 | gihyo.jp
YAPC::Asia Tokyoに限らず、本業の傍ら運営されているイベントの類いは、スタッフが作業できる時間や場所が必ずしも一致しない事が大きな問題の1つであると思います。 例えば同じ会社に勤める会社員であれば、毎日同じような時間に出社しかなり近い場所で一日中仕事をしているので、ちょっとした会話で問題を解決したり、進捗の確認をしたりすることができます。また、物理的にも心理的にも距離が近く、お互いの性質や仕事の進め方などもある程度は知っているでしょう。しかしイベント運営の場合、スタッフが全員別々の仕事をしつつ勤務時間や内容が合わないのでは、少し意図的に工夫しないとコミュニケーションは取れません。 それではYAPC::Asia Tokyo 2015の準備段階では、スタッフの間でどのようにコミュニケーションを行ってきたのかを少し解説してみたいと思います。 歴史 YAPC::Asia Tokyoは
第5回 蓑輪太郎―Twitter本社で働くエンジニアのキャリア | gihyo.jp
先を歩むエンジニアへのインタビューを通してエンジニアのキャリアについて考える本連載、今回はゼロからOSやScheme処理系を作り、現在はTwitter本社で働く凄腕エンジニアのhigeponこと蓑輪太郎さんにお話をお伺いしました。 ［撮影：平野正樹］ 危機感を感じた1社目 ──higeponさんはいつもさまざまなことを勉強なさっていますが、いつごろから自ら技術を学び始めたのでしょうか？ higepon（以下ひ）：2001年に入った初めての会社が大きいSI系で、技術に長けたチームに入れてもらえました。そこではモデルケースになるような優秀な先輩がいて、たとえばトラブルが起きたときに、自分で率先して原因を解明して、周りにも的確に指示を伝えていて問題を解決していたんですよ。その先輩から「しっかりプログラミングを勉強しないとまずいよ」と言われたんですよね。それで自分で実際に勉強をし始めたら、今
第1回 なぜ、Hadoopはどのように動くのか、を学ぶのか | gihyo.jp
はじめに ビッグデータ解析のためのシステム基盤として、Hadoopをはじめとするオープンソースのデータ処理ソフトウェア（データ処理系）が広く利用されつつありますが、当該データ処理系をすでに利用している、もしくは利用の検討をしている読者の方々の中には、たとえば以下のような問題を抱えている方が少なからずいらっしゃるのではないでしょうか。 データ処理系の使い方はなんとなくわかるが、その内部をあまり理解できていない。または、内部の動作原理がよくわからないので、本格的に使う気にならない。 同様の目的を達成する複数のデータ処理系において、どれを使って良いかがよくわからない。または、適切に使い分けられていない気がする。たとえば、どのような場合にHadoopを用いて、どのような場合に同類のデータ処理系であるImpalaやSparkを用いれば良いかが“明確に”わからない。 このような問題を解決するには、
第4回 浜本階生―SmartNewsを作ったエンジニアのキャリア | gihyo.jp
先を歩むエンジニアへのインタビューを通してエンジニアのキャリアについて考える本連載、今回はSmartNewsの開発者で、スマートニュース株式会社の代表取締役社長／共同CEOの浜本階生さんにお話を伺いました。 ［撮影：平野正樹］ ゲームがきっかけで始めたプログラミング ──浜本さんがプログラミングに興味を持ったきっかけをお聞かせください。 浜本：小学校のころ、ファミコン[1]がどう動いているのかにすごく興味がありました。小学校3年生のときに先生が画面の中を丸が動くプログラムを見せてくれたのですが、それで、ファミコンもきっとこうやって動いているんだと思ったんですよね。その後中学校の技術家庭科の教科書にプログラムを書こうというコーナーがあって、簡単なゲームプログラミングをしたのが始まりですね。中学校のPCはNECの古いPC-9801だったのですが、放課後に内蔵のBASIC言語で記述していました
第3回 宮川達彦―最先端のWebエンジニアのキャリア | gihyo.jp
先を歩むエンジニアへのインタビューを通してエンジニアのキャリアについて考える本連載、今回は古くからPerlコミュニティで活躍し、最近ではWebテクノロジ情報発信のポッドキャスト「Rebuild」が話題の宮川達彦さんにお話を伺いました。宮川さんは、筆者のクックパッドの同僚でもあります。 ［撮影：平野正樹］ プログラミングに興味を持ったきっかけ ──最初にプログラミングやエンジニアリングに興味を持ったのはいつでしょうか？ 宮川：父親がプログラマだったので、コンピュータは小さいころから家にあったんですけど、プログラミングはしておらず、純粋にPCユーザとしてゲームとかで遊んでいました。プログラミングのきっかけは、東京大学に通い始めて、趣味でホームページや掲示板を作っておもしろいと思ったことですね。そのあと3年次に、理学部情報科学科を選択し学びました。それと前後して、大学の友達から「オライリー・ジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITエンジニアのための機械学習理論入門 | Gihyo Digital Publishing … 技術評論社の電子書籍
