そろそろ

プログラミングネタをマジで始めようかと思う。ボクシングネタばかりじゃ「こいつ本当にプログラマか?」と思われるし、いい機会かな?但しプログラミングネタがあまり続くと、ただでさえ少ない読者が限定されてしまうから3連くらいでやっとこかな。

まず、僕は一応未熟ながらプログラミングでお金を貰っています。言わばプロです。なので当然知っておかなければいけない知識がいくつかあります。現在の開発言語がC++なため、オブジェクト指向についてわかっていなければなりません。で、とりあえず、

①デザインパターンその他イディオム
②事前条件事後条件
③メモリとか、スタック、デック、キューとか

を、さらっと、浅く書いてみることにします。以下は序文ってな感じで

最近デザインパターンに関する理解が少し変わりました。少し前まではプログラミングを助けるためのもの(この理解も正しいとは思うけど)だと思っていましたが、今は少し違っていて、ライブラリ(別にlibじゃなくても普通のソースでもいい)開発者がクライアント(利用者)に楽させるものだと思っています。つまり、クライアントが楽にならなければ、デザインパターンを使用する意味が薄いと認識しています。だからライブラリ側のプログラミングは必ずしも楽にはならないと言うこと、むしろクライアントのために頭を使わなければならないわけです。あたりまえなんですけどね。

事前条件事後条件については、恥ずかしながらつい最近までその存在すらあんまり知りませんでした。逆にいえば知らなくてもプログラマにはなれますが、知らないと恥ずかしいものですし、事前条件事後条件を考えずにクラス、関数を作りまくっているとワケワカランことになります。はい、現状ワケワカリマセン。とりあえず最初は小難しく考えずに、doxygenのpre,post,invariantを書いて遊んでればいいのではないかと思います。ボクシングでもそうだけど、仕事も楽しまないと持たないっす。仕事だからって小難しくやってたらつぶれますって。楽しくプログラミングしてればセンスは後からついてくると思う。考えが甘いかな?でもそういう感覚で仕事できない人は絶対つぶれると思う。

まぁ、話が脱線しちゃったけど。

最後にメモリの話。苦手ッす。正直言って。ただ自前プログラミング言語を作るときには、ガベコレとか考えなきゃいけないし、もちろんC++であってもOSがどのようにメモリを管理しているのかを知っておけば、確保の順番や、クラスの定義などについてのアイディアがいろいろ出てくると思います。とにかく基本からいこうと思います。

ふぅ…。じゃあまずはデザインパターンからか…次までにネタを考えておきます。

| | コメント (0) | トラックバック (0)

仕事がもうちょっと暇になったら

わんくま同盟とかで活動してみたいなぁ…とか思っている今日この頃。

最近、仕事の効率が非常に悪いため、本気で勉強しています…マルチスレッドだの、テンプレートだのSTLだの。

あとまぁ、言語全般…特にスクリプトを利用する機会が多いため、ゆる言語をどう活用しようか…などなど。

まぁー、忙しさを言い訳にしている状態ではまずダメだなぁ。

情熱に火をつけないと…だな。

| | コメント (0) | トラックバック (0)

関数プログラミング

関数プログラミングに興味を持ってしまいました。
そこで、haskell,scheme,ocamlで遊んでいます。

もともと、Luaやjavascript,actionscriptなどのまた~りゆる~い言語が好きなのですが、

たまにはそうゆー言語もいじってみたくなった。

しかしocaml流行ってるんだな。図書館でも最近貸し出し中だったり
予約が入りまくりだったりする。

ついでにいうとF#にも手を出している。まぁ、名前みてわかるが
.net framework的なものだ。pythonやら、rubyやらが.net frameworkで
動くようになってきているので、これも当然の流れかな…なんて思う。

余談だけれど、うちのパソコンはmsiをダブルクリックすると桜エディタで開いてしまう…関連付けしてないのになあ…。

あと、F#の日本語情報が少なすぎ…まぁ、英語の勉強だと思って頑張るか…。

| | コメント (0) | トラックバック (0)

CEDEC2日目

今僕はCEDEC2007のレポートを書いている最中です。
ただ内容は外に出してはいけない(少なくとも会社ではそう言われた。)
なので(まぁ1人5万円だからな)詳しくはかけません。ただ2日目の最後の授業の
流体力学の先生(バンダイナムコの馬場先生)は「もっとオープンに!」って
言ってたしなぁ…。

流体力学ではなんかラグランジェだのナビエストークスだのオイラーとか
ルンゲクッター法だの、ルジャンドル陪関数だの…。

ただ、船が海面を切っていく時の方程式が出せたのには感動した。

ま、どのみち俺が説明したってわかんねーよっ。

というわけでレポート書いても無駄な気がするけど、これは俺自身の
復習になっているので喜んで書いております。

ノートは勿論「マインドマップ」で書いています。絵が多いため人に見られるのが
恥ずいのだが、ガンガン書く→眺める→わかったつもりになる→ウマー(゚Д゚)

である。「わかったつもり」が大事。とりあえずそうなってれば後からでも
勉強するから。「チンプンカンプン」だと一生勉強しないからね。俺の場合。

2日受けて
「数学と物理はまるで違う」
と思った。

数学は証明がある、ある複雑式を簡単式に変換することができる、抽象的である、現実世界とは違う。
物理は証明がない場合が多い。その式が現象をほぼ一般的に表現できるかどうかが重要。

プログラミングは証明が必ずしも必要ない。現象を近似的に表現するのが目的。速度が重要なため
簡単な式に直す必要がある。

というわけで、僕らの仕事は数学でも物理でもないけど、どちらも必要という感じだろうか。

まぁ、「数学と物理はまるで違う」けど、物理式に複素数が出てきたりして、二つは密接に
絡み合っているともいえる。

そしてプログラミングは、この二つと絡み合いながらも独特の問題を生み出す。
マルチコアプログラミングの講義を受けたが、こんな問題はコンピュータでしか聞いたことない
と思った。人工知能もしかり…だ。

勉強してナンボの職業についていることを改めて実感。
そして勉強量・レベルが全然足りていないことも実感。

数学がなぁ…フーリエと行列・ベクトルがわかっていたらOKだと思ってたんだけど…。
ヒルベルト空間だの最尤推定法だのラグランジェの未定乗数法だの最小二乗法だの

聞いたことなかった…。果たして俺はこの業界でやっていけるんだろうか…。

| | コメント (0) | トラックバック (0)

備忘録

ここんところ暑くてパソコンを立ち上げたくなかったので、ブログサボってました。

まあ、今日もリバーシの備忘録書いたらパソコン落とすけど…暑い。

自分の石がある地点(x,y)に設置可能かどうかを調べる手順。
①:ある方向を調べる。その方向に自分の石の反対色(相手の石)が連なるだけ探索する。
disc{x,y,col}//colは石の色(白なら1、黒なら-1、石がないところ、及び壁の向こうは0)
settableDir = 0;
//例(上方向への探索)
x = disc.x;
y = disc.y;
while( Board[x][y].col == -disc.col ) do
  --y;
end
if( y!=disc.y )
  settableDir += UPPER;
②:①の探索を8方向全てに行う。結果は保持しておく。
(理由は、あとでひっくり返すときに調べる手間が省けるから。)
③8方向調べた結果、置くことができる(settableDir!=0)ならば設置候補とする。

評価例
自由度=70
確定石=200
X=-650
C=-550
角=1200
全滅=-10000

かなりフィーリングです。

あと、『α-β』は評価関数と直接関係ないです。
α-βがなくても、リバーシの思考ルーチンを作ることはできます。
ただそれだと、序盤の手数が指数関数的に増加しまくって、遅くなるので、
α-βを使用します。だからα-β刈りとかよく言いますね。

はい、もはやチラシの裏と化してますね。しばらくこんな感じなので勘弁してください。

| | コメント (0) | トラックバック (0)

Luaのリファレンスについて

Luaの話も書いておくか…。Google先生で調べても、luaL_refについてきっちり書いている
ページは少ないように思える。多分使う機会がないのだろうけど…。僕はこのようなときに使っている。
ひとつは、luaのスレッドを分ける場合に、スタックがガベコレにより破棄されるのを防ぐために使用する。つまり
スレッドを作った際には、スタックトップにあるので、ついでに
luaL_ref(L,LUA_REGISTRYINDEX,r);
とすると、常にレジストリインデックスから参照される状態となるので、そのスレッドは消えないのである。
逆にいうと、あるスレッドを使わずに放置(保持して使いたいけど)していると、そのうちガベージコレクションされる。
もちろん、lua_gcで調整すればいいのだが、あれでは、特定のスレッドの保持はできないのである。
つまり、スレッドは保持したいがメモリを節約したいときに使う。いらなくなったらluaL_unrefすれば
そのうちガベコレで消される。

もうひとつは、何らかのオブジェクトを示す値をほしい場合(関数やテーブル)。もちろんlua_topointerで
指し示すことはできるのだけれども、void*ポインタは使いたくないという場合に使えます。
元の値を復元するにはlua_rawgetiを使用して復元します。この場合も使用後はluaL_unrefしなければ
ならない。

| | コメント (0) | トラックバック (0)

実力の差

最近は、家に帰ってからもプログラミング三昧です。とはいえボクシングが終わって料理して、食べた後なので1時間弱ですが。

C++以外の言語をよくいじっています。仕事ではC++とLuaがメインなので家ではHaskellとRuby、Pythonをいじっています。

ツールメインは仕事でもプライベートでもAwkです。時代遅れと言われようと使いやすいんだい!!

とまあ、結構プログラムで遊んでいますが、うちのチーフプログラマーにはかないませんでした。
Luaは俺のほうが勝っていますが、彼のテンプレートテクはすごい。ModernC++Designを理解しているようなので、読むと眠くなる俺とは大違いだ。
また、HLSL(シェーダー言語?)もテクニカルだ。また、彼はXMLパーサを自前で作っていたりと、まあ半端じゃない。

分野的に得手不得手はあるとは思うけど、プログラミングで重要なのはアルゴリズムよりむしろデータの持ち方だったりする。

現状はデータフォーマットを考えているのは僕なのだが、どうしても手詰まりになる。
最近は結構ボスを頼るようにしたのだが、彼の助言が極めて的確である。助言前と助言後では、エントロピーおよび実行効率がけた違いだ。

さすがにここまで実力が離れていると張り合う気にならないなぁ…。とはいえ、努力はしてないと、年齢も年齢だし首になりたくないしね。

うわー、めっちゃナマナマしいはなしになっちゃったよ。次回はボクシングの話書こうっと。

| | コメント (0) | トラックバック (0)