Option型のmapとflatMap

「Option型＝コレクション」と考えてみると、
　謎なのがmapとflatMapですの。

　結論から言うと、flatMapの挙動が斜め上なんですの。

　コード
　val list = List(List(1,2), List(1,2))
　val opt = Option(list)
　println(opt.flatMap(n => Option(n)))
　println(opt.map(n => n))

　結果
　Some(List(List(1, 2), List(1, 2)))
　Some(List(List(1, 2), List(1, 2)))

　なんとなく、flatMapなら「Some(List(1, 2, 1, 2))」となりそうなものですけど、mapの結果と一緒なのですの。

　Option型のmapとflatMapの違いはたぶん、関数の定義が微妙に違うだけなんですの。

　map 　　[B] (f: (A) ⇒ B　　　　): Option[B]
　flatMap [B] (f: (A) ⇒ Option[B]): Option[B]

　Scala API(*)の説明もこんな口ぶりですの。

　原文：Slightly different from map in that f is expected to return an Option (which could be None).
　意訳：fがOption（Noneの可能性も有り）を返すことになっているという点でmapとわずかに異なる

　その微妙な引数の差を、あえてmapとflatMapという名前で区別する意味がわかりませんの。ぷんすかぷん


*)Optionのページ (2.9.1 final)

Option型のコレクション操作メソッド

たとえばmap。これって、よくコレクションにつかうメソッドですの。
　でも、そういうメソッドが、実はOption型にも付いてるんですの。（たくさん！）

　Option型を使う場合、基本的にはmatchを使って中身を調べるのですけど、それをさぼる方法もいっぱい用意されてますの。きっと、コレクション操作メソッドもその一つですの。
　これを使うと、Option型の処理をコレクション操作の中に自然に織り込めるという点で、とっても素敵なのですの。

　よく見かけるのは、foreachを使う方法ですの。でも、mapなら値が返ってくるので、より関数型ちっくな書き方ができますの。この辺の選択基準は、コレクションを扱うときと同じですの。

　mapやforeachの他にも、filterやcollectなんかもあって、果てはイテレータまで取れるので、もうコレクションの一種だと思ってしまってもいいくらいですの。

　ただ、実際のところ、コレクションとは継承関係の繋がりは一切無くて、あくまで同名の専用メソッドを用意しているだけのようなので、全く同じように使えるわけでは無いのですの。ちょっと注意ですの。

　それがハッキリわかるのが、mapとflatMapの動作で、次回はそれについてですの。

変数を固めたクラス vs Map

　変数をまとめて構造体ちっくにしたクラスと、Map。

　どっちが速いか試してみましたの。

　まずはMap。

　キーは'a～jの10種類、値はそれぞれ0～9ですの。

　'aと'jの値を参照する処理を100万回を１セットとして、１０回計測。

　結果は、

　187, 177, 176, 177, 177, 177, 177, 178, 178, 177（ミリ秒）

　次に構造体なクラス。

　a～jという10個の変数を用意して、値はそれぞれ0～9ですの。

　aとjの値を参照する処理を以下同文ですの。

　結果は、

　7, 2, 4, 4, 4, 4, 4, 3, 4, 4（ミリ秒）

　うーん。土台、勝負になってませんの。

　Mapのほうが便利そうだと思ったのですけど、もし固定キーで決め打つのなら、あえてMapにしない手もあるかもですの。

　・おまけ

　定数に名前を付けたら、それはもうキーですの！

　と思いこむことにして、

　他のコレクションを添字(0番と9番)で参照してみましたの。

　List

　236, 233, 233, 232, 229, 229, 228, 230, 227, 228（ミリ秒）

　ArrayBuffer

　48, 47, 47, 47, 45, 46, 46, 47, 47, 47（ミリ秒）

　Array(配列)

　6, 5, 5, 4, 5, 4, 5, 5, 4, 3

　意外にも、Scalaでも配列はかなり低レベルな概念のようですの。

　ArrayBufferも相当速いと思うのですけど、さすがに内部処理の有無という壁は厚いですの。

　Listは…末尾参照が苦手とはいえ、10項目しか無いのにMapより遅いとは思わなかったですの。。でもまぁ、見方を変えれば、それだけMapが高速ということかも知れませんの。

Scala de 仮引数

Scalaは全ての値がオブジェクトなので、

ほかの関数に値を渡すときは必然的に参照渡しになるはずですの。

でも参照渡しだと、引数をつたって元の値をいじれてしまうような…。

それって、わざわざ不変リストとか用意してる意味あるんですの？？

と思ったので、試してみましたの。

object Sample {

　def main(args: Array[String]){

　　var list = List(1,2,3)

　　update(list)

　}

　def update(obj:List[Int]){

　　obj = list.updated(1,999)

　}

}

へぇぇー。これを動かそうとすると、

代入するところで「reassignment to val」って出て、コンパイル出来ませんの。

なるほどー、仮引数（obj）はvalで宣言してるのと同じ扱いみたいですの。

これなら安心して不変リストを投げ回せますの。ぶんぶーん

お風呂せっけん 元の職業柄、的な…

　お風呂のせっけんが切れましたの。

　詰替用のがあったので、詰め替えたのですの。

　それはいいのですけど、母上様。うちにあるのはバウンシア リッチモイストのボトルなので、ダヴ ボディウォッシュ ビューティモイスチャーの詰替用を買ってきてはダメなのですの。

　特に、まだバウンシア リッチモイストが底に少し残っていますの。このまま入れたら混ざりますの。さっき、わらわがポンプを1秒間16連射したり振り回したりすくったりして頑張って使ってもなお、使い切れずに残ったバウンシア リッチモイストが、新しいダヴ ボディウォッシュ ビューティモイスチャーに混ざってしまいますの。

　混ぜたらダメって説明書きに書いてありますの。

　そういうことすると何かあったときに、問題の切り分けが出来ないから保証外にされてしまうんですの。電話口で、あーそれやっちゃいましたかーそれやっちゃうとウチでは責任取れないんですよねーとか言われてしまうんですの。言われたことはないけど、きっとそうですの。

　すべてはメーカーさんの保証範囲内でやらないと後で責任が取れないのですの。酸っぱいお口でたくさん言われたのですの。ぶくぶくばーなのですの。怖いのですの。

　でも、うちにはダヴ ボディウォッシュ ビューティモイスチャーのボトルは無いのですの。だいぶ汚れていたので、こないだお掃除したときに、わらわが捨てたのですの。でも、母上様もそれは知っていたはずですの。なのに、なぜ…　なぜなのですのっ

　だけれど、詰換用のためにボトルを買いに行く世の中は何かおかしいですの。そんな世の中はわらわが許さないのですの。

　仕方が無いので、ボトルを全部水洗いして綺麗に乾燥させて、詰替用パックの裏面の保証書番号を切ってボトルに貼っておいたり、はしないで容赦無くダヴ ボディウォッシュ ビューティモイスチャーを投入して詰め替え完了ですの。おしまい！めでたしめでたし！

メモリ食い過ぎ

　Steam!　おーまーえーのーことですのーー。

　メモリを8GB積んでいても、32bit Windows7では3GBちょっとしか認識しないというのは散々言ってきたんですの。ただ、認識外のメモリに仮想メモリを置いたときの効果の薄さが、最近ひどいんですの。

　かくなる上はもうしょうがないので、使用量の方を見なおすのですの。

　以下、処刑リストですの

　・Steam

　　ゲームしてない時でも100MBも占有の罪により、
　　スタートアップからの削除、および、ゲームしてないときは起動させない刑に処す。

　・DropBox

　　同期中でもないのに30MBは使い過ぎ罪により、
　　アンインストールの刑（執行猶予付き）に処す。

　・wmpnetwk (Windows Media Player Network Sharing Service)

　　ほぼオマケ機能のくせに11MBも占有する罪により、
　　サービス停止の刑に処す。

　・EveryThing

　　ファイルの中身で検索出来ない割に、常に23MB(*)は使い過ぎ罪により、
　　アンインストールの刑に処す。

　以上

　本当は…なによりEclipseとChromeが、それはもう死ぬほどメモリを食っていくのですの。でも、その二つを使うためにPCを起動していると言っても過言ではないので、泣き寝入りなのですの。


　*) GoogleDesktopで5MBくらい

いろいろ壊れ中

　Wish(ほしいもの)リストならぬ、華麗なる今はもう動かないおじいさんの古時計リストをご照覧あれですの。

　１．AirMacベースステーション(無線LAN親機)
　　症状：一日一回から二回のペースで、不定期に止まる。
　　　　　ときどき電波強度が極端に落ちる。
　　対処：祈って、待つ。

　２．マウス（左クリック）
　　症状：押しっぱなしにすると、途切れて連続クリックになる。
　　　　　(＝D&Dができない)
　　対処：長距離移動は避けて、短距離の高速D&Dを連発してがんばる。

　３．マウス（ホイール）
　　症状：不定期で、さわってもないのに、高速で回転入力を入れ続ける。
　　対処：泣きながら待つ。

　以上ですの。

　実はリストにするほど数は無いんですけど、全部致命傷なので何の問題もありませんの。

　特にホイールの件は、マウスを変えても起きるので意味が分かりませんの。常に上方向に高速スクロール状態なので、まともにWebページも見れないし、プルダウンメニューみたいなのも全然選択できないのですの。

　はわー…　不便ですの。

おろかなにんげんどもめー

　ボーカロイド禁止とはいい度胸ですの。

　「学校の放送でボカロ曲かける事が禁止された」　ツイッターのつぶやきに賛否
　http://news.nicovideo.jp/watch/nw85871

　まぁ、ボーカロイドだけじゃなくて、エロゲのアレな曲とか、電波ソングとかも同じ理由でダメってことなんでしょうけれど。

　こういう問題は、基準の決め方と、運用の仕方ですごく揉めますの。
　でも、いちいちあらかじめ決めておくのは不可能なので、必ず揉めるのですの。すてき！

　もうこういうのは究極的には運営サイドの好みで裁くしか無いので、それこそニッチな人種は「は、迫害だー」とかいって諦めるがいいのですの。

　ただ、流行りの頭悪い曲を聞いていると頭痛と吐き気が収まらないんですうって人を尻目に、ボーカロイドの曲だけを禁止するからには「機械だから」「歌詞がわからないから」なんて寝ぼけたこと言ってないで、もうちょっとシラフな理由(*)をひねり出すべきなのですの。

　そもそも、先生が「ボーカロイドの曲が禁止である理由を答えなさい」っていうテストを出したとして、生徒が回答欄に「歌詞がわからないから」なんて、ふんわりしたこと書こうものなら、いかにもペケ付けられそうじゃありませんの。

　まぁ、一方の学生のついーとしか見てないので、話そのものが、どこまで合ってるのかわからないのですけど。


*) 丁寧に不気味の谷の話とかしてあげてもいいですし、事実を反映しているなら「嫌がる人が多いからダメなんだよ」とかだって立派な理由にはなりますの。

メモリがやすい。

　ドスパラで8GB(4GB×2枚)のメモリが3,470円で売ってましたの。。

　2GB×2枚を5,000～6,000円くらいで買ってから、まだ一年も経っていないというのに。すごごー。

　4GBメモリいいなぁ。

　でも、スロットが4つ全部埋まっているので、まだちょっともったいない。なにかこう、メインPCを買い換えるとか、予備PCを作るのに今のメモリを流用するとか言うときまでお預けなのですの。

iTMS探検 - 私的めも

　しばらく見ないうちに、iTMSで扱ってる曲がずいぶん増えてたので、探検してきましたの。

　めぼしい曲をウィッシュリスト* にぽこぽこ放り込んでるのですけど、「アルバムのみ」の曲がウィッシュリストに登録できないのが不便なのですの。

　「そうか！ウィッシュリストに登録できないなら、買ってしまえばいいんですの！むきーっ」と凶行に及びかけるも、「アルバムのみ」なので、（当たり前だけど）単体で買えないという二重の罠が張られていたので断念。。

　ウィッシュリスト以外のブックマーク的な機能が欲しいところですの。

　というわけで、メモ。

　Neal Morse の Help Me The Spirit And The Flesh が素敵でしたの。

*いわゆる、ほしい物リスト

シャア…きさま！

　JavaでStringBuffer作るときにchar値をぶちこんだら、あらぬことになりましたの。

　・上手くいかなかった書き方

　　char c = 'a';

　　piyo = new StringBuffer(c);

　　（piyoの中身：""）

　・正しいの

　　char c = 'a';

　　piyo= new StringBuffer(Character.toString(c));

　　（piyoの中身："a"）

　ダメな例も素知らぬ顔で動いちゃうんですけど！　なぜに！

　Java6のAPI仕様書を見たら、StringBufferのコンストラクタの引数にcharなんて無いじゃないですか。びっくり。ええー、だったら例外の一つも出せですの。このやろぉぉー。

　有効な引数にintがあったので、たぶん、charを整数値として受け取ったんでしょうかしら。。

　文字を入れるためのcharが、裏技的に符合無しshortとして使えるのは有名な話ですが、こういう時に、まさかStringを差し置いてint側に倒れるとは予想外でしたの。。

らーめんらーめん

　わらわですわー、お久しぶりですのー。

　放置してから久しいですの。まったくもう。

　お友達とごはん食べに行ってきたら奢ってもらってしまいましたの。出世払い。はわん無職。

　出世するぞー　おー

　何をするにも、まずは勉強ですの。。そしてそして研究成果があどばんてーじとなり、おかねを生み出すがいいのですの。

　IT土方はいやなのですの。そうもっとうつくしくエレガントに。

　たとえ舞うような薄給も辞さず、されどうつくしく、らくに生きるのですの。

大地震ですの

　とりあえず、いまのところ無事ですの。

　大きな余震が直撃どかーんするとか、原発爆発＼(^o^)／しない限りは。

　どちらにせよ、パワーがケタ違い過ぎて、大事なデータを海の向こうに退避させておこう…なんて意欲も沸かないですの。

　データが消えるときは、たぶん私も消滅しているでしょうから。

　おなかすいたー、なんか食べてこよう(｀・ω・´)

砲身の二つの意味

　銃や大砲のお話ですの。

　弾丸を真っ直ぐ発射するためには、砲身が必要ですよね。要するに筒の部分です。この砲身が長いほど弾丸は真っ直ぐ飛びます。拳銃は短く、狙撃銃は長いですよね。

　というわけで、わらわは、砲身っていうのは命中精度向上のためだけにあるんだと思い込んでいたのですが、実は威力や速度の向上にも一役買っていたらしいのですの。

　どういうことかというと、そもそも火薬で弾丸を発射するっていうのは、火薬の爆発で発生した高圧ガスが弾丸を押し出すことで実現してますの。

　一箇所しか無いガスの出口を弾丸が塞いでいるので、ガスが顔真っ赤にして弾丸を押すわけですね。

　ヽ(｀Д´#)ﾉ ﾑｷｰ!!　←高圧ガス

　つまり、砲身が長ければ、それだけ弾丸は長く加速を続けられるのですの。弾丸の威力は、速度×質量なので、威力向上にもつながりますの。