表現の種類

おねーさんです。
今日も昨日も行き帰りの電車の中では”すごいHaskell”を読み、速やかに昏睡状態へと移行する動作を続けております。Haskellはすごい。

ここ数日で最もいらいらするのは畳み込みです。
foldl。そうか。foldl1。ちょっとちがう内容だから数字つけたのね。そうか。いや、これは看過できぬ。
きっと深淵で無駄のない洗練された理由があるんだとは思いますけど、いまのあたしはこう思う。
「ほんとに頭の良い人が作ったの?センス悪くない?あまりにも場当たり過ぎじゃない?」
こういうところでガックリきて、はーまじかーなえるわーってなって寝るんだわ。
#foldlというのは左畳込みとかいう処理をする関数さんであるらしいです。なるほどわからん。

tnomura9さんの「tnomuraのブログ」というサイトをこないだ見つけて、たまに読んでいます。
Haskell 記事リスト」というカテゴリがまとめられていて、まだ最初の方だけしか読めてないけれど、書き口がわかりやすくて読みやすい。
すごいHaskellとともにこのサイトを副読本として読んでいこうと思います。ありがたいなあ、こういう記事を置いてくれる人がいて。

いろんな表現があるのだな

その、tnomura9さんのページに例題が出ているので、それをちょいちょいやってみる。

「1から10までの数の2倍の数のリストを出す」

あたし:
Prelude> [x*2 | x <-  [1..10]]

リスト内包表記だ。Pythonで覚えたんだワイルドだろう。

上記のページ:
Prelude> map (* 2) [1..10]

オ-ゥ。
もうここで違う。結果は同じよ?同じなんだけど、map関数を使うこと、「(*2)って関数」を与えること、このへんの発想があたしに欠落しているということがよくわかる。
はーなるほど。次。

「1から10までの数の平方数はどうだろうか。」
次の行を読まずにまず自分で書く。わかってんだよmapだろmap。

あたし:
Prelude> map (^2) [1..10]

で、

上記のページ:
Prelude> map (\n -> n * n) [1..10]

む、むめいかんすう。。。
むろんやってることは同じではございますが、そういう表現もあることを知った上で、どっちの書き方を選択するか、といったふうにしておきたいものです。

Prelude> :t \n -> n*n
\n -> n*n :: Num a => a -> a
Prelude> :t (^2)
(^2) :: Num a => a -> a

Python覚えたての頃、何をやってたかを書き残しておけばよかったなあ。言語ってどうやって覚えるんだっけなー。

中種仕込中

週末にパンを作ろうと思い、木曜の夜に中種を仕込みました。はやかったかなー。
リンゴジュースをのませている我が家の屁こきピザデブどもですが、ビン底で寝てばかりの連中がかなり増えました。一般にオリと呼ばれているやつです。
上澄みは綺麗にあたくしが飲んで(素晴らしいシードルでした!)、下にたまったオリの一部を小麦粉に混ぜ、就寝。
20時間後には3倍近くに膨れてました。寒いのに元気良すぎだ。
ちょっと予想外に発酵ペースが早いので、冷蔵庫にしまうことにしました。こやつらは後日、追加のコナとか色々混ぜてコッペパンなどになる予定。
寒い台所に放置してなお、かなりのペースで膨らんじゃってたので、過発酵がこわいです。
もしダメだったらこねなおしてピザ生地にしてしまおう。

あたしのつくるパン

主食といえばコメ、パン、パスタや麺類くらいですかね。
あたし大抵のものは食べられるデブに適した食の趣向を持っておりますが、やっぱりいちばんは米がいい。雑穀米でも白いのでも、押し麦混じっていても餅米でも、お米が好きでございます。
一方の代表格はパンでしょうが、かつて、あたしそれほどパンに強い興味をいだいてはおりませんでした。
空気だらけでスカスカだから。
あんなスカスカのもんでなく米がいいわ、といって生きてきました。
こんな自分がまさかパン作りを面白がってやるようになるとは予想もしとりませんでしたよ。菌と糖類、温度や水分の絶妙な按配が出来を左右するメカニズムに惚れたんだと思います。
#パスタ・そば・うどんも大好き。クスクスも大好き。

自分でパンを焼くようになってこっち、どっかで外食をするたびに、食べる機会があるものならパンを頼むようになりました。ファミレスでなんちゃらセットを頼んで、ライスでなくパン。一年前のあたしが見たら目をひん剥いているであろうと思います。
ココスでもロイホでもいいんですが、頻繁ではないにしろあちこちでパンを食べますと、目の前にある、このよくできたパンと、あたしの焼いた「あたしがやったにしては」よくできたパンを比べることになるわけです。
「けっこう今回はいい出来じゃないかなー」
とか言っていたのが一転、
「嫁よすまぬ。あれはパンでなく泥だ」
と頭を垂れるといった具合。厳しい現実の前には、謙虚でなくてはなりません。ふわっと焼けたなーと思っても、それ焼いた直後だけなんだよね。翌朝は硬くなってしまう。
先週末はパンを焼かずに過ごしました。まだ在庫があるからですが、水分に関する巨大な勘違いを修正すべく、今週末はなんとかパンを焼く時間をこさえたいものだと思っております。金曜日が帰社日、土曜日が会議。日曜日に頑張るしかないお(´・ω・`)

また、いちどツヤツヤのパンを作ることができて満足したっぽくて、こんどはドリュールなしのパンを焼きたいなーなどと考えるようになりました。さらさらぱりっとした皮の素朴なパンもいいよね。
はー。パン教室いきたい。

瓶の底にいる連中がかなりの量になってきたので、そろそろ小麦粉を食わせる頃合い。
葡萄酒用の酵母買っちゃったんだけど出番ないなあ。

ドットつなぎ記法

あたくしにとってドット(.)というのは、文字列結合を指すものにほかなりませんでした。後にいろんな世界で色んな意味をもつ記号であることを知るにいたり、言語ごとの思想の違いであるとかに目がクラクラした次第であり、し続けている次第であります。
ほんでHaskell。
ドットつなぎは、関数合成です(キリ
あー、そっすか。関数の、合成っすか。失敗すると外道スライムが沸いたりするっすか?

すごいHaskellのp99。

import Data.Char
import Data.List

digitSum :: Int -> Int
digitSum = sum . map digitToInt . show

数字列を受け取り文字列に変換して、各文字(数字)の合計をするというサンプル。本にある例文です。
1234と入れたら、1+2+3+4で10を返すと。
で、これがまたわからない。ドットが関数合成なるものであることは見ました本で。
で、これ、えーと、引数どこいった。
これはえーと、あまりにも引数が自明なあまり省略しましたみたいな話ですか?
で、色々こねくり回していると、どうも、

digitSum 1234

は、

(sum (map digitToInt (show 1234)))

と等しいようだということがわかりました。

  1. showは受け取った値を文字列にする、
    1234→”1234”
  2. digitToIntは文字0-fを数値にする、
    “1”→1
  3. mapはdigitToIntを各桁に対して行う、
    [“1″,”2″,”3″,”4”]→[1,2,3,4]
  4. sumで合計する
    1+2+3+4

とすると、

digitSum = sum . map digitToInt . show

の右端から順に読んでいくと同じことになるわけだー?
なんで右から読むのと左から読むのとあるんだ。読む向きがわかんなくて目がチカチカする。。。
リスト内包表記もPythonさん経由で慣れてるというのは大きいにしろ、やはり視線が左右に泳ぐ傾向があり、さくっとわかりやすく、左から右へ、流れるように読みたいものだと思う昨今です。
どちらを先に学んだかでしかないんだろうけど、

Haskell:
sum . map digitToInt . show

これと、

jQueryなど:
uu().yaa().taa()

みたいなのがこう、頭のなかで混ざってですね、マーブル模様になるんすよ。
関数の合成とメソッドチェーンとは違うものか?きっと違うな?少なくとも読む方向は逆だな?
そんなかんじでモヤモヤしております。
違う思想、哲学、体系を学ぶというのは、ほんとうに大変なことだなあ。

このままじゃ脳が外道スライムになるっすよー。

りんごとはちみつ

日々、瓶の底にたまった屁こきピザデブ共(オリ)を確認しては、
「起きろ」
とばかりにシャッフルしてやり、ジュースの糖分を食わすことに血道を上げております。
うちの子たちはだいぶ数が増えた感がありまして、この趣味をはじめたばかりの頃に比べると、ジュースを食っていくスピードがだいぶ違います。発酵の過程そのものへの不安がなくなってきました。
むろんこれは寒い時期だからの話で、春以降気温が上がり、発酵スピードが上がり、一方で管理も忙しくなるという流れが待っています。部屋の中で普通に放置とかがリスクを負うようになるわけで、注意したいところ。
そういう季節を経験してみないとわからんことでもありますが、発泡スチロールのケースでも用意してやろうかなと考えています。夏場の気温とかほんとうに危険。誰も居ない間にビンが爆発しましたとか目も当てられない。ヨメにも怒られます。

先日、クリアタイプのりんごジュースを食わせた発酵液を菌どもから取り上げ、飲んでみました。
発酵で連中が盛り上がっているときは液が濁ってるんですが、だいたい食い尽くしてやる気がなくなると、連中はそこに沈んでじーっとするんですね。混濁タイプのりんごジュースかと思うほど濁っていた発酵液が綺麗に晴れ上がる。上澄みだけいただいて、オリには別途砂糖を食わせ、次回作へ備えさせたり、小麦粉を食わせてパンの種にしたりしています。
リンゴは非常に良い出来で、簡単に仕上がりました。家庭用で飲むならいいなーコレ。
雑味の少ない、キリッとした飲み物になってました。小岩井やるな。

りんごジュースは小さい瓶にあと幾分か残るだけなので、また仕込もうと思っています。
同時に進めていて、出来上がりが楽しみなのが蜂蜜。
SKYRIMプレイヤーなら一度は飲んでみたい「ミード」を作っています。作るといってもこれまた簡単な話で、蜂蜜を食わせて終わり。
調べて納得しましたが、ミードを作るには蜂蜜を水で薄めたものを醸すんですね。
蜂蜜は糖度が高すぎて、3000年経とうが腐らないので、水で薄めて糖度を下げ、菌が繁殖できる状態にしてやる必要があると。
蜂蜜って花粉集めて色々アレしたあとで、ちっこいハチどもが羽で風を送り、水分を飛ばして保存しているわけです。せっかく水分飛ばしたのにニンゲンは水で薄めちゃうわけだ。酷い話ですね。
このミードはちょこちょこ味見してますが、まだまだかかりそうです。糖度高すぎて発酵の進みが悪いのかも。

鬼憑鉄

鬼憑鉄といえばトラウマもののクエスト「鬼に金棒」のアレですが、さいきんそれをやることもなくなったみたいです。
「クソゆとりがうるさいんで一日一回だけできる簡単なの用意してやったから」
的佇まいのなんともご親切なクエストが用意されておるわけです。
ゴリゴリ強気だった姿勢が軟化してきたつうことはなにかね、接続者数減ってるのかね。
FF11を手本にしたとしか思えない変な日々の積み重ねアイテム実装とかに疲れた人たちが消えてるんでしょう。おねーさんがおもうに「猟団の自動解散」とかいう誰得システムを殺さないで放置してるのが問題なんじゃないのと思うんですけどね。帰る場所をさくさく消して回ってんだから帰ってくるわけないじゃんね。んで末期症状のお約束、重課金オンラインだ。

んでそんなわけだから鬼憑鉄をあつめてんの。鬼神シリーズつくんのよ。何で使うんだったかはよく覚えてないが、対ルコ用ハンマー装備とかで多分使うんだよ。性能そのものが極めて優秀で、何探すにもぽんぽん引っかかってくる。特に腕。
じゃあつくるか、ラージャン大嫌いだが仕方ない、位に思ってたんです。
鬼憑鉄は毎日「凄腕防具!鉄と骨の極意」をやる。顎ばっかり出てくる。気のせい。
ティガは苦手だけどまだ話の通じる相手なので大丈夫、尖爪と鋭牙ねハイハイ、とおもいきやこれが集まらない。全然でないわけじゃないしイメージ的にポンポン集まる(だって爪と牙ですよ)と思ってたんですが手こずります。結構な数の要求されてるんですが。
調べます。

轟竜の尖爪 via 狩リブ海
基本報酬10%*1
部位破壊20%
剥ぎ取り17%

轟竜の鋭牙 via 狩リブ海
基本報酬10%*1
部位破壊15%
落とし物5%

出るなあコレなら。
いつものあれか、妙に引きが悪いというだけの話か。
困るんですけど。これ4部位作ろうとしてるんですけど。
できればガンナー用に腕も作ろうと思ってるんですけど;;

関心の範囲とでもいうの?

使う用語はテキトウで思いつき任せです。
そもそもこの「hogeFunc x y」という書き方自体、あたしはイライラしているんだ。
カッコで括るとかしないと見分けつかなくないのか。なんなんだ。
なーんでhogeFunc(x y)って書かないんだろう。Shiftキー押すの嫌だから?

これは毎日イライライしている問題の中でもとりわけ大きなテーマで、面倒くさいのか何なのかしらないが、なぜ関数名も仮引数も、一緒くたに並べて視認性を下げてるんだろう設計者は阿呆なのだろうかと思っているわけ。

書いてるうちに氷解し始めてはいるんだけど、そういうモヤモヤも今後のために書く。

Prelude> let hogeFunc x y = x + y
Prelude> hogeFunc 2 3
5

うん。

Prelude> let subHoge = hogeFunc 2
Prelude> subHoge 1
3
Prelude> subHoge 4
6

これを知ったときは驚いた。「hogeFunc x y」のxまで代入済の関数を返すのね。「すごいHaskell」を電車で読んでて、このくだりを目にした時、驚いたあまりヘンな声でて恥ずかしかった。

Prelude> :t hogeFunc
hogeFunc :: Num a => a -> a -> a
Prelude> :t subHoge
subHoge :: Integer -> Integer

はー。

で、よくわかってないのは相変わらずだけど、もしかするとHaskellさんというのは、右隣りにいる誰かにしか興味を持ってなくて、右隣りと何かをしたあと、まだ右隣に何かがいる場合、「ああ、いたの」とばかりに何かをするといったような人なのかしらと思い始めているわけです。
むろん加減乗除の優先順みたいなところで、常に右を一個ずつ食っていくわけじゃないよとは思うんですけど、

x:xs

にしろ、

Prelude> let subHoge = hogeFunc 2

にしろ、先頭(左端)の何かにしか興味を持っていないといった佇まいに見えるわけです。

で、

hogeFunc x y

コレにおけるhogeFunc氏はyさんなんぞ知らんの体であって、興味の対象はxさんだけなんであると読みますと、
hogeFunc xの結果の何か(機能的にはsubHoge)が初めてyを認識し、subHoge yを評価すると。結果、hogeFunc x y全体の評価が終わって、xとyの和が得られてよかったねという流れなんでないか。
あたくしの理解のためのこじつけですが、つまり、つまり、

((hogeFunc x) y)

という感じ?なんじゃこりゃw
まあそのなんだ、カッコあっても意味ないからカッコ書いてないんだよということなのか。hogeFunc氏にとって、yさんは興味の範囲の外にいる人だから。
こう読むとなんとなく読める気がしてくる。勘違いだった場合に突き進んで、あとで勘違いをとくハメになるのも痛いなあ。
「こういうかんじなのかもしれん」
くらいで読み進めていこうか。

焼いたパンが翌日固い

先日、わりと高得点の出来であると自負したパンをですね、ヨメがお弁当に持ってったんですね。
朝あっためて、バター塗って、黒ごまペースト塗って持たせたの。
どんなもんだかなあと思っていたんですが、彼女の帰宅後にパンの感想を聞いてみますと、
「あれ?と思うくらい固かったー」
オブラートに包んだ表現をしないあたり、察するにかなりの固さだったようです。
これはいかん、ということで調べてみます。
同じ内容で悩んでる人が山ほどいたことにまず唖然。こりゃ解決の目処がつくのは早そう。

で、大体わかりました。

焼いたパンは冷めきる前に袋詰めする

なるほどこれかー。勘違いしてた。冷め切ってから袋にいれるものだとばかり思ってた。
そういえばーと思いだしたんだよ。
パン屋さんで焼きたてを買うじゃない。袋に入れてくれたりするけど、パンがまだわずかに熱持ってて、袋の中が蒸気で曇ったりするんだよ。
「この蒸気でパンがべちゃっとしたらやだなあ」
って思ってたんですよ、今まで。
逆だった。これが正解だった。あたしが冷めるまで放置してたのは、つまり、パンの水分をひたすらに失わせることをしてたのね。そりゃーかわいて堅くもなるよねー。

焼きあがったら5分冷まして、タッパーや袋に詰めちゃうのがよいとのこと。
気をつけよう。

低温で長時間焼いてると水分が抜ける

オーブンレンジで焼いてる以上は、ある程度そういうもんだと思うほかないのかもしれないなー。
水分が抜ける分を補うってのが可能なのかは考えたい。

もともと水分少ない

Q: 全体に固くてボリュームがでないのはなぜでしょう?
A: 水不足の場合。水が少ないと生地が固くなり、伸展性がなくなります。生地の固さは耳たぶぐらいと言われていますが、実際にはもう少し柔らかめに仕上げたほうがいいでしょう。それには水をやや多めにすることです。

よくあるご質問@日本製粉

うわー。耳たぶって。うちのは水そのものも足りてなかったー。

小麦粉がそもそものところ、どのくらいまで水分を許容するのか(形を保つ程度のかたさを保てるか)を知らずに今までやってました。粉と水を少しずつムダにするかもだけど、どのくらいの比率までOKなのかを見極める実験とかするといいかもしれないな。

ほか参考にした記事

まず、吸水ですが、砂糖分が10%以下の生地の場合、粉に対して68%前後が適切です。
小麦粉の重量が書いていませんが、250g仕込みでしょうか?(砂糖は25g、塩5g見当で考えますと)この場合、水は170gが適正な量といえます。
卵や牛乳は水と総量で置き換えるのではなく、簡単な計算で80%の水分と置き換えると良いでしょう。

手作りパンが硬い理由はなんですか?

あたし水足りてなかったんだなーということを痛感しております。

Haskellコードの読み方

#Haskellコードの読み方を教える記事じゃないので、そういうのが必要な人は他のとこ行ってほしい。これはあたし用のメモだ。それも、理解したので書く記事ではなく、わかんないから書く記事なので、役に立たないす。
書きだして眺めるための記事であります。

Hakell読んでてイライラさせられるというか、他の言語をちょっとでもかじった人はたいてい苦しむんじゃないかと思う点が、「=」だ。

php:
$a = 1 + 2;

Python:
a = 1 + 2

Haskell:
a = 1 + 2

うん。ここまではいい。というかここで既に転んでたらアンインストールしとるわ。
このとき、あたしの頭は
「1+2をaに代入/バインド/ホニャララする」と読んでいます。右辺から左辺、という方向です。「←」です。
ではこれはどうか。

Haskell:
hogeFunc x y = x + y

こんくらい簡単な例なら、一瞬フリーズするものの何とかならんでもないんですが、一瞬フリーズするのは確かなんですよ。どっち方向に読むのコレ。
hogeFuncという名前の関数の定義らしきものだなと読み、えーと引数がxとyで、そんでx+yしたものを左辺にー、えっ?左辺どうすんの?……みたいなかんじです。

phpなりPythonなりJavaScriptなり、あたしの知っている言語は、関数を定義するときに関数名の定義と中身をイコールでつないだりしていない。
ブラケットやインデントで隔離された領域があって、(Haskellのように副作用を認めない、絶対に値を返すというルールでいうならば)returnで値を返す、

php:
function wee($a){
    return $a+1;
}

返された値は左辺の何かに放り込まれるか、

$b = wee(10);

その場で展開されて値になる(といった感じに読んでいる)

$b = wee(10) + 5;
→ $b = 11 + 5;
→ $b = 16;

そんなかんじであると思っているわけです。
これはHaskellであってphpでもPythonでもねえんだよということは重々承知ではあるが、10年かそこら読んできたクセが染み付いててなかなかスイッチを切り替えることができません。

Haskell:
hogeFunc x y = x + y

さっきのこれの例でいくと、x+yされた何かを左辺に返すと読みたいんだけど、左辺にあるのは関数名と引数の羅列であって、振り上げた拳を下ろす場所を見つけられないような、ぐにゃりとした、もやもやした、行き場のない感じを感じてしまうわけであります。
左辺右辺で言えば、あたしはこれを左辺を見て右辺を見て、右辺からどっかにいくはずなんだけど行き先がよくわからん、といった趣。
左辺と右辺は等しいよ、という読み方をするほうがいいのかなあ。考え方というか読解のためのコツがわかってない感じ。

何が何でも絶対に”return”するから、わざわざreturnとか書かないよ~みたいな話なのかなー。
そのうち慣れて、そういうもんだよーって思えるようになるのかなー。

ほんとに慣れるのか?

uu (x:xs) = x+1:uu xs

先日書いたコード断片。
こういう、再帰的に処理の続きが発生している記述がすごく苦手です。読み解こうとするときに、どこをどんな形で脳に教えてやったらいいのかわからず、混乱するわけです。
1. uuさんにリストを渡すんだよ~
2. リストの先頭のxに+1するんだよ~
ここで思考停止。残りの「:uu xs」部分を、脳にどう教えたらいいのかわからない。
あたしにとって右辺は左辺に値を戻すもののはずなのに、右辺の端っこでまだ処理が続こうとしている上、行き先がよくわからない。
頑張って読む。xsの先頭に対して+1する処理をして、xsの残りに対してuu xsして……。
はあ、なるほど、わからん。
その際限のなさそうな、ふかーいループというか、やたら積み上がっていくスタックというか、それどこまで覚えてたらいいの、あたしそんなたくさんのこと一度に覚えられないんだけど、ああ頭痛が眠気が。再帰こわい。つらい。
そんな酷で際限のないつらいことを強要する言語設計なんぞするわけがない。すると読解のコツがあるはずだ。
むしろあれか、際限ねえんだから今は気にするなということなのであろうか。遅延評価というのはそういうことなのだろうか。
わからぬ。

パターンマッチング

x:xs問題が脳に染み込みはじめたことで、急にHaskellが読みやすくなりました。進歩です。
読める気になり始めたという方が真実に近いかもしれない。
むろんまだまだイライラの種は尽きないので、このへん一個ずつやっつけないと進めそうにないです。

すごいHaskellのp.38に「リストのパターンマッチとリスト内包表記」という項目があります。

let xs = [(1,3),(4,3),(2,4),(5,3),(5,6),(3,1)]
[a+b | (a,b) <- xs]
[4,7,6,8,11,4]

うん、「<-」にイラっとこないわけじゃないが、ここはわかる。Pythonやってて良かった。phpだけだったらきっと未だに読めてなかった。 びっくりしたのはつぎの例文で、

[x*100+3 | (x,3) <- xs]
[103,403,503]

面妖な。いや、これはすごい。利用シーンちょっと思いつかないし、必要なときにこのやり方を思い出せる自信は全然無いけど、

[x*100+3 | (x,y) <- xs, y==3]
[103,403,503]

これと同じ結果をパターンマッチングで得るってことなわけだ。どっちがよりHaskellらしいとかは知らないし、さしあたり考えないけれど、あたしが不機嫌になり続けた「Haskellのリストとは先頭と何かである」問題と同様に、パターンマッチングというものが随所に染み込んでいるのだなということはわかってきました。

仕掛けはわかってきたが

取り扱うデータに対して、パターンマッチングを適用することで上手に利用できますね、とか、これは違うやり方が必要ですね、とか、そういった見極めの按配がわかってないんです。
「ふーん、いつつかうの?」
という、実際の利用に即した風景が見えてないもんだから、しばらくイライラし続けることにはなりそうです。