はじめに --- DP は役に立つ はじめまして。NTTデータ数理システムでアルゴリズムを探求している大槻 (通称、けんちょん) です。 好きなアルゴリズムは最小カットやマッチングですが、会社ではなぜか「DP が好きな人」と呼ばれています。 巷ではよく「DP なんて実務では使わない」といった言説が定期的に流れますが、そんなことはないです。僕自身この 2 年間で DP が使える実務案件に 3 件くらい関わりました！ それはともかくとして、DP を学び立ての方がよく抱く悩みとして「バリエーションが多すぎて混乱するし、統一的なフレームワークがほしい」というのがあります。確かに DP のバリエーションは非常に多岐にわたるのですが、そのほとんどが以下の 3 つのフレームワークで説明できると思います: ナップサック DP 区間 DP bit DP 今回はこのうちのナップサック DP について、とにかく

厳しい。年始早々厳しさを感じている。自分のプログラミング力にだ。伸び悩んでいる。 端的に言って、数学力のなさが自分のプログラミング能力に制限をかけている。例えばこの問題。 560. Subarray Sum Equals K 入力として与えられる配列 nums のうち、合計が k となる部分配列の個数を数え上げよ。どうも有名な問題らしいが… まず大前提として、部分配列なので i, j の2重ループで始点・終点を定めて sum(nums[i, j]) = k になるものを数え上げれば必ず答えが得られる。最悪計算量は O(N^3) ただし i < nums.length < 20000 という制約があるので N^3 では遅すぎるから何か考えてくださいというのがスタート地点。 ここで、結果の変わらない累積和を何度も求めているので nums[i, j] = k を求めたい場合、 nums[0, j

情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。

概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token

こんにちは。「家族アルバム みてね」の開発チームに所属している黒川と申します。今回は、その「みてね」の機能の1つで、写真や動画をDVDにして注文できる機能を動的計画法を使って改善した話をします。 「みてね」では家族の写真や動画をアップロードし、アプリ上で月ごとに振り返ることが可能になっています。一方、たとえば自宅のテレビやパソコンでまとめて振り返りたいという要望もあり、「みてね」では最長過去1年間の写真や動画をDVDにまとめて注文することができます。 このときに問題となるのがDVDのディスク分割です。1年分の写真や動画はともすると1枚のディスクに収まりきらず、複数のディスクに分割する必要があります。いままでは、動画を月ごとに分けて各ディスクに入れていく、というシンプルなアルゴリズムで分割を行っていました。しかし、ユーザーさんからは「1枚のディスクにすこしの動画しかないがどうなっているのか」

はじめに 皆さんはGoogleドキュメントやHackMDを使ったことはあるでしょうか。これらのツールは「ネット越しに同時に複数の人で1つのドキュメントを編集できる」という特徴を持っています。お互いの編集がリアルタイムに反映されるので、相手が何を書くのかを意識することなく、簡単にドキュメントを複数人で編集することができます。これを実現するためには、同時編集に参加しているユーザ全員の編集内容がネットワークの延滞に影響されることなく、それぞれの編集内容をうまい具合にマージして反映してくれるような賢いアルゴリズムが必要になります。今回はこのアルゴリズムに関して書きます。 編集内容のマージとは 編集内容をうまい具合にマージしなければいけないケースを考えてみます。 AさんとBさんが次のドキュメントを同時編集するとします。最初は、お互いブラウザ上では次のように見えています。当然、この状態ではお互いに見え

2019年11月11日追記 ただのタイトルで煽ってるだけの記事に半年経っても未だに大量のアクセスがあるので追記しておきます。 ここで言いたいことは、「プログラマならコンピュータサイエンスを勉強してると役に立つよね」、ということ だけ です。 この一文以上に有用な言葉は以降の文章では出てきません。みなさんの時間を無駄にしないために注意書きをしました。 それでも良いという人は読んでみてください。 Twitterで「〇〇ができるという人が面接に来たけど、『じゃあXXXやYYYって知ってます？』というと知らないという人が多いんだよねぇ」とかいうツイートを見かけて、私はXXXやYYYってのを知らなかったので調べた見たところ、常識とまでは言えない概念だったり、名前は知らなくても誰もが知ってる概念だったり、むしろもっと良いアプローチがあるのではという思想だったりでなんだかなぁと思っていたところ、半日くら

2019年新卒研修で使った資料です。 内部実装の雰囲気を感じとりながら、Redisについて理解を深める研修を行いました。 以下の内容について学びました。 1. Redisの概要 2. 社内での利用方法 3. 正しい用法用量 Redis についての前提知識は必要としていません。…

個人的に、一番面白いデータ構造であり探索アルゴリズムです。 ここで言うグラフは円グラフや、棒グラフのことではないです。プログラミングで扱うのは、図のように、点と線を繋げたものです。 ズバリ、人と人の繋がりを表現できます。 今回もJavascriptで実装します。 グラフ理論は、SNSだったり、レコメンドだったり、地図の経路だったり　ルーティングだったり、点と点の繋がりを可視化します。繋がりを表現するデータ構造です。 巨大なインターネットもそうです。 そいう意味で、すごく身近なアルゴリズムですよ。 グラフの基本は次の２点で構成されています。 ・ノード：node(vertex) -  点（人、物、場所） ・エッジ：edge  - 辺(繋がり、経路) 上の図を見ると一目瞭然ですね。ノードを人だとしたら、エッジが関係性です。まずは、これだけ理解できれば大丈夫です。 ちなみに、方向がない辺を無向グラ

レコメンド（推薦システム）に関して素晴らしい記事があったので訳してみました。訳に難があるが、そこはご勘弁ください。 プログラム実行してみると理解できると思います。入門者に打って付けの記事です。 以下、本文。 インターネットの世界はレコメンドで溢れていますね。 Amazonのように商品を購入するeコマース・サイト、Facebookのようなソーシャルネットワーク、YoutubeやNetflixのようなビデオ/映画サイトなど。これらのサイトに共通するのは、あなたに新しいものを推薦するために、映画、商品と友人などの過去のデータを使うことです。 この記事では、レコメンド機能がJavaScriptで、どのように動くか簡単に紹介します。推薦システムを実現するための、異なるアプローチも見ていきます。最終的にはアルゴリズムを切り替えただけで、結果を出力できるようにします。映画評論家の小さいデータセットと、M

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

短くて一意な複数のID（short unique ids）を簡単に作りたい ユニークIDの需要はそれなりに高く、かつ出来る限りショートである方が望ましいという需要はそれなりにあります。 方法としては、UUIDを使ってるのではないでしょうか？ もしくは、MD5やSHA256等のハッシュ値をBASE64エンコードして我慢して使用しているのではないでしょうか？ 文字列長が超長いけど、ユニークなので、仕方なく、我慢しながら使ってるのではないでしょうか。 ここ最近、ショートでユニークなIDをシンプルに作れるという需要を満たす、Hashids が流行りつつあります。 詳しくは　→　http://hashids.org/ 対応してる言語は、有名どころだとC#以外の殆どの言語に対応しています。 JavaScript, Ruby, Python, Java, Scala, PHP, Perl, Swift,

CourseraのAlgorithms, Part Iというコースで、高速なRandomized Queueを実装するという話題があったので、試しに作ってみた。 高速なRandomized Queueとは Randomized Queueとは、Queueからdequeueするときに、中に入っている要素の中からランダムに一要素取り出すようなQueueである。 また「高速な」とは、enqueue、dequeue、isEmpty、sizeなどの操作の実行時間が、"constant amortized time"であること、つまり何回も操作を繰り返していくと、平均的には定数時間でそれぞれの操作が終わるということである。 この二つを満たすものを高速なRandomized Queueと呼ぶ。 実装 高速なRandomized Queueを実装すると次のようになった。 import java.util.

The document describes Meta-Prod2Vec, a method for embedding products that leverages both co-occurrence information from user sessions as well as side information about products like categories and brands. It improves upon Prod2Vec, which learns embeddings from co-occurrence data alone, by incorporating side information to help address cold start problems when little co-occurrence data exists. Met

「Kyoto.なんか #2」というイベントで利用した発表資料です。新刊・蔵書管理をサポートする amakan というサービスをつくっており、その中で利用しているシリーズ判定方法の仕組みについての話をしました。 - https://amakan.net/ - https://atnd.org/ev…

私はSkienaの『Algorithm Design Manual』 (訳注：『アルゴリズム設計マニュアル』 上巻 ・ 下巻 ) を読んでいました。ところでこの本は素晴らしい本で、連結リストと配列についてこんな比較をしていました(chapter 3.1.3)。 連結リストが静的配列に勝る相対的な長所には以下のものがあります。： • メモリが本当にいっぱいにならない限り、連結構造にオーバーフローが生じない。 • 連続的な(配列)リストに比べて、挿入と削除が単純である。 • 大きなレコードを扱う場合、要素自体を動かすよりもポインタを動かすほうが容易かつ高速である。 一方で、配列の相対的な長所には以下のものがあります。 • 連結構造には、ポインタのフィールドを格納するための余計な領域が必要となる。 • 連結リストでは、要素に対する効率的なランダムアクセスができない。 • 配列は、ランダムなポイン