コンピューティングの基礎と処理の高速化入門 #1 at connpass で発表したスライドです。 https://liberal-arts-for-tech.connpass.com/event/123273/
コンピューティングの基礎と処理の高速化入門 #1 at connpass で発表したスライドです。 https://liberal-arts-for-tech.connpass.com/event/123273/
動的計画法（ナップサック問題） 動的計画法とナップサック問題について解説します。 動的計画法とは 直接計算すると大きな時間がかかってしまう問題に対し、途中の計算結果をうまく再利用することで計算効率を上げる手法のこと。 「途中の計算結果を再利用」＝「同じ計算をしない」ということ 難しいように見えて考え方自体は単純 ICPC国内予選でもC問題～F問題くらいに何かしらの形で2,3題ほどでます 英語では「Dynamic Programming」と呼び、略して「DP」と呼ぶことが多いです。 動的計画法で効率的に解ける問題の一つに、ナップサック問題というものがあります。 ナップサック問題 ナップサック問題は、価値と重さが決まっている複数の品物を容量が一定のナップサックに詰め込むとき、ナップサックに詰め込める品物の価値の和の最大値は何であるか？ という問題です。 具体的には、以下の図のようになります。ナ
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山（@fushiroyama）と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか？ 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
こんばんは、夜中たわしです。 先日ニンテンドースイッチで配信開始された『ヒューマン・リソース・マシーン』というゲームが非常に面白かったので全力で紹介します。クリア済みです。 『ヒューマン・リソース・マシーン』 直訳すると「人的資源機械」。 そのタイトルが示す通り、プログラミングに従って人間（プレイヤーキャラ）が馬車馬のように働くゲームです。 なにげなくニンテンドースイッチのストアを見ていたところ見つけました。掘り出し物です。こういうのすごく好み。 本作はビジュアルプログラミングツールとパズルゲームの中間の存在です。プログラミング要素はゲームだからと言って子供だましではなく、大人でも頭を悩まされる問題も。なかなか完成度が高いです。 と言ってもプログラミングの知識はまったく必要なく、小学生でもプレイできることでしょう。そしてプログラミングの考え方がある程度身につきます。 しかも安い（1000円
KISSの原則 (キスのげんそく、英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。 この言葉は、ロッキードスカンクワークスの技術者のケリー・ジョンソン（1910-1990）によって造られた。 この言葉は、一般には Keep it simple, stupid.（シンプルにしておけ！この間抜け） と解釈されるが、ジョンソン自身は「simple」
「コーディングがはかどる」かもしれないプログラマーの皆さん向けの音楽サイトがあるそうです。ちょっと試してみました。 今、BGMは流れていますか？ 家で、電車で、会社で──。「NO MUSIC, NO LIFE」までではないにしても、“ながら音楽”の習慣がある人は多いでしょう。特に論理的な思考を必要とするプログラマーの皆さんは、良いコードを効率よく書くためにどんな環境が必要か、どんな音楽だとはかどるか、それぞれ自身の方法論を持っていると思います。 例えば、アマゾンの定額制音楽配信サービス「Prime Music」には、「～～のための音楽」といった、あるテーマに沿った楽曲を集めたプレイリストがたくさん登録されています。「ドライブに最適なJ-POP」「お休み前に聴くピアノソロ」「恋がしたくなるJ-POP」などの他に、「仕事がはかどるジャズ」「残業を乗り越えるサントラ」「満員電車でイライラしないポ
作成中の自動絵画プログラム。どうやら、みんなは「フォトショのフィルター的なモノ」を想像してるみたい。実はこのお絵かきロボ、一筆づつ丁寧に色を乗せていったりする。むっちゃ時間かかる。 アルゴ的には、遺伝アルゴリズムとA/Bテストの中間のようなロジックで動いてます。無数のパターンを一筆ごとに総当たりし、うまい感じに色がのった場合のみ採用みたいな。そんなわけで800px程度の大きさでも、1毎仕上げるのに2-6時間ぐらいかかります。 先にざっくり全体を下塗りしていくようにチューニング。 こちらが最新バージョン。ついに「主題でない部分に塗り残しや、筆跡などを多めに残す：チューニングが完成。 静物画の写真を、油絵に変換したもの。油絵っぽい写真を変換すれば、油絵になる。 ニワトリ。ちょっと目のコントラストが薄くて検出できなかった・・・失敗。それ以外はいい感じ。 サル。毛の質感はもう文句がない。あとは粗密
Processingで、自動絵画化してみるテクニカルスタディ。 最近だと、ディープラーニング系でやるのが流行りだけど、あえて手動アルゴで頑張るなど。流行に逆らって、素手で戦うのが美学だと思う！！ ファーストのスタディ。アインシュタイン。ドットをボコボコ置いただけともいう。いちおう画素の標準偏差などをとって、絵としての粗密を判定しながらドットを置いていく。 基礎理論ができたところで、ブラシのスタディ。とりあえずランダムな文字で配置してみた。もっとtypographyっぽくなるはずが思った通りにいかない。 セカンドのスタディ。モナ・リザの再絵画化。文字のかわりに筆パターンをテクスチャとして利用。細部がなかなかでない。 キツネの絵画化・・・筆テクスチャの大きさを絵の密度で制御する。色のゆらぎをRGBで表現すると虹色に歪む。 カラーをHSB空間に変更。だいぶいいかんじに。エッジ境界がガラスエフェク
この投稿では、以前に TinyKeepDev が こちら で述べたランダムなダンジョンを生成する技法について説明しようと思います。元の投稿に比べて、もう少し具体的に話を進めるつもりです。まずは、以下に示したアルゴリズムの一般的な動作をご覧ください。 部屋の生成 はじめに、幅と高さを持つ部屋を円の中にランダムに配置しましょう。TKdevのアルゴリズムは、各部屋のサイズを生成するのに正規分布を用いています。これは一般的にとてもいいアイデアです。なぜかと言うと、これによってより多くのパラメータを扱うことができるようになるからです。幅/高さの平均と標準偏差間の異なる比率を選ぶと、通常は見た目の違うダンジョンとなります。 ここで実行すべき関数は getRandomPointInCircle です。 function getRandomPointInCircle(radius) local t = 2
あけましておめでとう！ 私、暮井 慧。今年もよろしくね。ところでみんな、いろいろなプログラミング言語の動向とか気になるよね？ というわけで、プログラミング言語の去年のふりかえりと今年の予定なんかを、スペシャルな人たちに聞いてきたよ！ Ruby 最初は、みんな大好きRuby！ Rubyコアコミッターの小崎資広さんに聞きにきたよ。小崎さんは、Linuxカーネルコアの開発者でもあるんだって！ Rubyの2014年はどんな年でした？ 慧 こんにちは。2014年のトピックを聞かせてください！ 小崎 まずは、Ruby 2.2のリリースでしょう。リリース直前にいろいろとトラブルが発生してやきもきさせましたが、無事12/25にリリース。クリスマスにリリースする慣例を守ることができました。 今回のリリースはガベージコレクションの改善がメインで、速度の向上に加えて、Symbolがガベージコレクトの対象になるよ
結論 まず最初に急いでる人向けに結論を先に書いておきます。2つの違いは以下の様に成っています。 yyyy 年(西暦)を出力 YYYY ある年における「最初の木曜日を含む週が、その年の第1週である」というルールで年(西暦)を出力。 例えば 2015/1/1 は木曜日なのでその週の日は日曜日〜土曜日まで全て2015年の第1週という解釈になります。この場合には2014年で有る、 2014/12/28(日曜)〜2014/12/31(水曜) の時でも YYYY では 2015 を返します。 きっかけ Podcast で Rebuild の第73回を聴いていたら日付フォーマットで yyyy ではなく、YYYY を使った為に Twitter の Android クライアントで不具合が出たという話が出てきました。 ※根本的な原因はこのルールでサーバ側が実装されていた為、 Android クライアントで正し
この記事はSwift Advent Calendar 12月23日の記事です。 アドベントカレンダーは後半ほどネタが出尽くすので不利ですね。 自分はこの2ヶ月半ほどプライベートの時間を使ってSwiftで新しくアプリを作っていたので、それについて考えていたこと、感じたことをつらつらと書き下してみたいと思います。 [2014/12/28 追記] 今朝、アプリがリリースされました！！ Rebuilt きっかけ 2014/6/3にWWDCでSwiftが発表され非常に気になっていました。 しかし、当時の自分は業務でアプリ開発から離れており、他に優先順位の高い事柄があったので積極的に勉強することを避けていました。 Xcodeベータは安定していない、Swiftの仕様もコロコロ変わる中、学習効率を重視するのであれば安定版がリリースされてから勉強したほうが良いとも思いました。 新しい技術が出てくるタイミング
とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV
With an expressive, easy-to-read syntax, Swift empowers new developers to quickly understand core programming concepts. And with resources like the Develop in Swift Tutorials, Swift Coding Clubs, and Swift Playground, it’s never been easier to get started with Swift as your first programming language. Learn more about Swift education resources from Experienced developers can also quickly dive in a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
