サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
レイングッズ
karino2.github.io
全くプログラムを知らないが、プラグインなどでJavaScriptを使いたい人向けの入門ページです。 序盤 第一回: はじめてのJavaScriptプログラム 第二回: 文字の表示とコメント 第三回: 変数で名前をつけよう 中盤 第四回: ifで分岐しよう 第4.5回: 質問に答えよう! 第五回: 配列で並べよう 第六回: 辞書って何? 100本ノック ちょっと練習量が足りないなぁ、という事で、ひたすら練習する回を作りました。新しい話は出てきません。 第6.1回: 配列100本ノック! 第6.2回: 辞書100本ノック! 第6.3回: 辞書と配列混合、100本ノック! 終盤 第七回: 関数その1 関数を作る事、呼び出す事 第八回: 関数その2 関数からもらうもの 第九回: 関数その3 関数に渡すもの 第十回: 辞書に関数を入れる 第十一回: 同じ事のいろいろな書き方 おまけ おまけ第一回:
数学が出来る人と出来ない人の一番の違いは、自身の分からないにどれだけ敏感かなんじゃないか、と昔から思っている。 それは数学以外でも大切な事はあるよな、と思ったのでブログに書いてみる。 数学ではどの分野でも、最初のうちはなんだかどうって事無い事を定義しているように見える。 定義というのは基本的には凄く単純なので、最初の頃の一つ一つが凄く簡単なのは当たり前だ。 で、ずんずん進むと、ある時ふと自分が全く分かってない事に気づく。 はて?と前のページを見ると、それもさっぱり分かってない事に気づく。 どんどん戻ると凄く最初の方まで戻ってきてしまう。 戻ってみると、最初の方はまた凄く単純で当たり前の、良くありがたみの分からない事を定義しているだけに見えて、全くそんな事をしている理由は分からない。 まぁいいか、とずんずん進むと、前と同じあたりでさっぱり自分が分かってない事にもう一度気づく。 これを二回か三
月一でやってるPRMLの勉強会に出ていて、来週末は10章の変分ベイズ、という事で予習している。 そこで結構数学的にいろいろ詳しくなったなぁ、と思ったという話。 変分ベイズは結構いろんな要素が出て来る。 まずEM法のLが出て来る。 EM法自体がカルバックライブラーのダイバージェンスがバンバン出てくるし、変分ベイズ自体は名前のとおり変分が出てくる。 変分は使うだけならそんな難しい事は要らないはずだが、どこかである程度関数空間を操作する練習の経験が要ると思う。 ちゃんとやろうとするなら、やはり関数解析を触ってる方が良い。 自分はこの前頑張って以下のyoutubeを全部見たりしてようやく関数空間を扱う経験を多少は積めた。 Functional Analysis 変分ベイズはfactorizeの近似を入れるのが一般的と思うが、この時には独立な潜在変数での期待値の計算が入る。 期待値の計算も、基本的に
twitter上の有名な院生アカウントで、なんでもディープラーニングでなんとかする事に定評のあるstudio_graph2氏が、ちょっと数学でもやってみようかな、と思っていると言っていたのでディープラーニングでなんとかする人向けの数学のオススメをしてみようのコーナー。 前提 微積、線形代数に加えて、フーリエ解析とベクトル解析と複素関数論と微分方程式をちょっとかじったくらい(本人談) 普段からChainerとかLightGBMとかでブイブイ言わせてて論文とかも普通に読んでいる優秀な修士くらいをイメージ なるべく数学なしで済ますにはどうしたらいいか?という話じゃなくて、ちゃんとやるならどこからやっていくか?という話。 当然最終的には私よりもちゃんとやる子になる予定なので、私に出来るのは最初の方だけ。 ではいってみよう。 入門数理統計学 (ホーエル) まずは確率のちゃんとした入門から。最終的には
自分が考えるちゃんとしたTensorflowの入門を作りたい、と考えたので作ってみました。 Tensorflow入門ページ この中に練習問題として、koanが2つ入っています。 これらは既存の入門とは少し違った角度で、自分でモデルを考えて作る必要がある形になっています。 環境設定はノーヒントですが、Dockerfileは入ってるので分かる人は勝手に使って頂けたらと。 また、分かりにくい概念や全体的な構造などは動画にしました。 上記ページ内にリンクがありますが、こちらにもリンクを貼っておきます。 ゆるふわTensorflow入門 全五回 ちょっとよそでは見ない入門になっているけれど、これが一番分かりやすいと自負しております。
機械学習の記事や本をちょこちょこ見たりしていると、どうも自分の認識とは結構違う。 そこで一度自分の認識をまとめておこう、と思う。 データ分析を用いたサービス開発とは、データと問題の、自分たちの間違いを理解する過程である 一番認識が違う、と思う所が、問題とデータを理解する過程を重視しない所にある。 一方でこれが本質だと自分は思っていて、そのために用いるのがモデルだ、と思っている。 これは科学分野のモデルでは一般的な話だが、プログラマはこれをブラックボックスとして呼ぶだけのその他のライブラリ達と同じ物にしたい、という気持ちが強い為、現実から目をそらしがち。 そこを少し説明してみたい。 途中で設計する問題は、全て間違えている 普通のサービス開発との比喩で考える。 サービス開発が、顧客やユーザーの本当に欲しい物を探る過程である、というのは、自分のブログを読むような人間なら同意してくれるだろう。ここ
既存のTensorflow入門が気に食わないので自分で動画の説明を作ろうと思い、そのための補助教材置き場です。 少し触ってみたけど良く分からない、という人向けに、エッセンスを話すのを目的とします。 このサイト以前の入門 このサイト自体は「Tensorflowを少し触ってみたが良く分からなかった」という人向けのつもりなので、 インストールした事が無い、とか、Pythonを全く知らない、という人は対象にしていません。 そこで「とりあえずこの位知っている事を前提に話をします」というような前提をここに記しておきます。 自分に不足しているな、と思う所があれば、以下を適当に参考にしてください。 これだけ知っていれば大丈夫、という自己診断 「https://github.com/karino2/tensorflow-introduction/ をgit cloneしてsourcesの中を見て」と言われて
河津のセブンに21時ころ到着。なんかナビの予定より1.5時間くらい早いんだが?なんかこのナビ、伊豆縦貫道のデータとかが古いんだよなぁ。
先日、USの方がチャンスがあるって本当か?という話をちょろっと書いた所、反応を幾つか頂いたが、そのやり取りの過程で自分と結構認識が違うなぁ、と感じた。Kazuyoshi Katoと違うのはまぁいいとしても、ゲームプログラマの偉い人とも結構違う感じだったので、補足のエントリを書いておこう、という気になる。 自分で言うのもなんだが、自分はこんにちでは、まぁ機械学習の時代にうまく適応出来た、と思っている。 二年前くらいまでは結構ひーこらいいながら頑張ってたのでそう言い切る事は出来ない感じだったが、最近は「あー、これ数年前にやった奴の続きか。こう進歩したのね」みたいに思うような研究に多く当たるようになり、大分この分野の周辺で、専門性みたいな物を構築出来つつある気がしている。 自分の興味のある領域なら、2015年くらいまでの主要な研究なら、まぁまぁキャッチアップ出来ている。 2年遅れじゃん!というの
Kazuyoshi Katoが、USの方がチャンスはあるのは当たり前じゃないか、的なツイートをしてた(という訳でも無いが) https://twitter.com/kzys/status/942775362437627904 ツイートの主旨はおいといて、USの方がチャンスがあるってそんな当たり前だろうか?と思ったという話。 自分は2010年ころ、USに行くか会社辞めるかで悩んでた事がある。 当時は日本にあまり魅力あるプログラマの仕事が見えず、USで働くか旅人になるかのどっちかかなぁ、と思っていた。 あの頃はVSとかDevDivのチームに移ろうかなぁ、と思ってた気がする。 それに相当する仕事は、まぁ日本には無かろう。 ただ、そういうドメイン的な事を置いておいても、そろそろさらなる自身の成長の為には、もっとチーム自体のレベルが高い所に行く必要はあるな、と思っていた。 で、それは、日本でも探せば
お仕事紹介 この夏にやってた仕事が、その後の皆様の努力もあって無事リリースされたようで、手元のアプリにも降ってきたし、ちょこちょこ表でも話が出ているのでその紹介を。 https://speakerdeck.com/diracdiego/20171029-kantocv-kikuta ここで紹介されているカテゴリ分類、というのが自分がやってた物です。 写真を、料理の名前ごとにフォルダ分けしたかのようなビューを作る、という機能で、そのうちモデルの所だけを担当していました。 UIやサービスとしてはいろいろ難しさもあるにせよ、モデルとしては画像からどの料理か当てる、なんていう、いかにも普通の画像認識問題となっている。 マルチラベルにするかシングルラベルにするか、とか、細かい所で選択肢はいろあろあるにせよ、データセットもラベル付けされてるのが既にあるし、そう難しい事は無いだろう、と思っていた(それは
フリーランスの経験が浅かった時、フリーランスのプログラマとしての欠点として、チームやチーム開発的な事に口や手を出しづらくなる、という事があると思ってた。 そしてそういう傾向は実際にあると思う。 だが、これは欠点、とも言いきれない部分がある。 逆にこれは、プログラマとしての誤魔化しや惰性で乗り切れる部分を自分から封じる事で、より良いプログラマになる為の経験を積めるという利点がある、と思うようになった。 チーム的な仕事に進みがちな正規雇用 ある程度の歳のプログラマは、シニアなプログラマとして、新人とは違うアウトプットを期待される傾向は強いと思う。 そして普通にサービスなどを実装出来る、いわゆる出来る新人と比較すると、ただコードを書くだけで優位を示すのはそう楽では無い。 そこでシニアなプログラマは、個人のコーディングよりも、もっと多くの人に影響を与えるような仕事に手を出す傾向にあると思う。 具体
ここではkotlinのリファレンス和訳を公開しています。 リファレンス ツアー Kotlinの基礎を短時間で試してみたい人向けのツアー 基本的な構文 Kotlinの文法の概要、リファレンスを読む最初の一歩はこちら ソース on github 原文 原文リファレンスホーム 原文のソース
このページを最初にブックマークしてみませんか?
『なーんだ、ただの水たまりじゃないか』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く