RealWorldHaskell pp102(2) Answer

なぜかオーバーフローに対応したものが見当たらなかったので晒し上げ。

import Data.Char(digitToInt, isNumber)

asInt_fold :: String -> Int 
asInt_fold [] = error "error"
asInt_fold ('-':xs) =  -1 * asInt_fold xs
asInt_fold xs = foldl step 0 xs
        where step acc x   
                | isNumber x = 
                    let acc' =  toInteger acc 
                        x'   =  toInteger (digitToInt x)
                        ans =   acc' * 10 + x'
                    in if ans < (toInteger (minBound::Int)) || ans > (toInteger 
                       else fromInteger ans 
                | otherwise = error "error"

Integerに変換しては戻しとやっているので割とひどい。
これならasInteger_foldでも作った方がましだとは思うが、練習なので。

Scala IDE for Eclipseの2.8.0用がでたので使ってみた

先日Scala IDE for EclipseScala 2.8.0用がでていました.ちょこっと感想等

まともに使えるようになった

何よりも非常に大きいことは,コード作成→ビルド→実行がまともにできるようになったことです.Scala 2.7.0用のプラグインはこの一連の動作もろくにできていなかった恐ろしいツールでしたが,今のバージョンは普通に動いてます.素晴らしい.

mainメソッドを複数作成した際に正しく実行できるようになった

これは私の勘違いかもしれませんが,前のバージョンではmainメソッドを一つのプロジェクト内に複数作成した際に正しく動いてくれないことが多かったように思います.これも直って,目的のコードを表示している状態でRunなりDebugなりのボタンを押すだけで正しく動いてくれます.やったね :D

インテリセンスも動く

少なくともScalaのパッケージを参照する際には正しく動くようです.JavaDocを参照する際はさすがに正しく動いてくれないらしいので,そこは残念.

総括

ようやくEclipse上でScalaがまともに開発できるようになったという印象があります.これでEclipse + Javaの環境からようやく脱出できるかも.

大規模データ取り扱いの注意

ここ最近延々と大規模な数のファイルを扱い続けてきたので,その時学んだことなど.

1フォルダ内のファイル数は一万程度に

現行のファイルシステムは大規模な数のファイルを扱うには,使い物になりません.10万を超えるようなファイルを入れた途端ディレクトリ内のファイル構造の取得だけでシステムががが.

xargsのPオブションは超重要

Pオプションはxargsでマルチプロセスで実行するためのオプションです.CPUを効率的に使うためには並列化が重要です.

ストリームエディタは必須

大規模ファイル集合と言えば,大規模データ.(例えば大規模ファイル集合のファイルリストとか)大規模データを扱うにはストリームエディタが必須です.WindowsではQXエディタ,Shell上ではhead,tail,moreなどがおすすめです.

やっぱり最後はデータベース

大規模ファイル集合に対する操作の出力をどう扱うかは本当に難しいですが,多いのは結果に対する統計処理等だと思われます.大規模データを扱う際のメモリの問題,検索速度の問題を一挙に解決してくれるのがデータベースです.データベースに格納できるデータはがんがんデータベースに入れることをおすすめします.おすすめのデータベースは組み込みDBとしてもサーバ用途のDBとしても使えるH2データベース.

TAで学んだこと

実験のTAなるものをやったので,その際に学んだことを記録.
実験の内容は,FPGAの演習で,私はその補助をやったと.
以下学んだこと.

生徒の言うことを信用するな

いやもう,本当に.本人が誤解してたり,こっちの知識不足もあったりするので
ちゃんとマニュアル読んだり,デバッガ使って実測したりしないとね.

実測せよ

生徒からは「動作がおかしい!」と言われます.
具体的にどうおかしいかは,コード眺めても全くわからんので実測しないとどうしようもない.

説明させる

我々は経験があるが,生徒のプログラムについての経験があるわけでもなく,生徒本人のプログラムの専門家でもない.
そもそも生徒がどういう意図でコードを書いたのかきちんと説明させないと何もわからん.

必ず失敗した理由を教える

同じ失敗をしてまた呼ばれてはたまりませんし,対処法を「おまじない」として教えても意味が無いと思う.
自分が楽をするためにも失敗した理由をなるたけきっちり教えるようにする.

修正するより修正の方法を見せてやる

特に最初の方はそもそもエラーに対してどう対処していいのかわからない人が多かった.
エラー検出の方法や,マニュアルの読み方を教えてやることで以降の苦労を減らすことができる(はず)

設計エラーを未然に防げ

今回経験した実験は,アセンブラによるプログラミングが必要でした.そのため,最初の段階で設計エラーを起こすと,エラーを小手先に修正して,最終的にえらいことになっている人間がちらほら・・・.直接プログラムを書く前にデータ構造の設計だけでもさせておくべきだったのでしょう.そこら辺は授業の実験という小規模なものでも,ソフトウェア工学が適用できそう.

マニュアルに当たる癖を付けさせる

なんとかして,生徒にマニュアルに当たる癖を付けさせてやりたいところです.まあ,マニュアルは非常に読みづらいものでしたが,正確な記述がされているものはマニュアルだけなわけですから,読んで欲しかった・・・.「Q.○○がわかりません A.マニュアルの第○章を読みましょう」 という感じのQA表用意しておければ良かったのかも.

以上.