只今記号操作中

 

2010-02-06

[] 05:03

ClojureREPLをいじりながら、プログラミングClojureを最後まで読んだ。

Clojureは本気だ。すごかった。本腰を入れて使ってみようと思う。

とりあえず会社のみんなにも読んでもらう為に貸し出した。

とりあえずリモートサーバjreインストールした。


あとwindows mobileでもClojure使えたらうれしいと思って、Mysaifu JVM上で動かそうとしてみたが駄目だった。残念。

Gauchewindows mobile上で動かないか試したけど、tgz内のwinntディレクトリに入っているプロジェクトファイルはeMbedded VC++ 4.0で読める形式でなかった。

prjconverterで無理矢理dswにしてみたけど、

Windows デスクトップ開発のために生成されました。Windows CE 開発のためには使用できません。」

と言われてしまった。

とりあえずeMbedded VC++は一旦諦めて、あとでgccでクロスコンパイルを試す。


一年前ぐらいに買ったp17nを、最近になってやっと全員分クリアした。

自分としてはかなり楽しんだ。他人には全く勧められないとは思いつつ。

T-01A上のFPSEceで動かして遊んでいたが、動作相性は良い方だったようだ。

(音にプチノイズが入ったり、画面の縦横比がおかしかったりで、完璧とは言えないが)

また、ゲームのジャンル的にも相性が良かったと思う。

2009-09-09

[] 00:57

サンレッドがまたネット配信をやっている。

前回は見逃したので、今回は全部見たいところ。

2009-08-23

[] 19:25

なんか最近スパムコメントが多いので、はてなユーザのみコメント可能な設定にした。

2009-08-16

[] 22:50

T-01Aを買った。

新しい番号は、古い番号からハイフンを抜いた数字に「947718337」を足した番号です。


いつのまにか、さくらのレンタル領域にインストールしていたwiliki類が動かなくなっていた。

gauche自体は動くようなので調べたところ、wilikiのdbmとして使っているGauche-qdbmが動かなくなっていた。

更に調べたところ、Gauche-qdbmが要求するlibzのsoがなくなっていた(おそらく、セキュリティfixによりlibzがバージョンアップされ、以前のバージョンのlibzは脆弱なので削除されたのだろう)。

とりあえずqdbmとGauche-qdbmを再インストールすれば直るだろうと思っていたが、Gauche-qdbmをmakeしようとすると、スレッド回りでエラーが出る。

どうやら、スレッド回りでも以前と変化が出たようだ。

適当に、スレッド無しでgaucheを構築し直して、Gauche-qdbmも再インストールしたら、普通に動くように戻った。

2009-08-07

[][][] LOL(日本語版)読了 07:46

面白かった。

全体の1/3ぐらいの最初の方は目新しい点はあまりなかったが、「アナフォラの閉鎖」から「パンドラのマクロ」にかけての辺りが凄かった。

レキシカルな環境を、こんな風に開く事ができるとは、これを読むまでは思ってもなかった。

S式(もしくはS式類似の、データとプログラムコードを同一のものとして扱える書式)の強力さを再認識した。

歴史的な経緯を考慮したり、なるべく自然言語風になるように無駄な努力をしているような、「腐った構文」持ち言語など、とても使ってはいられない。

(haskellのような、言語の強力さを目的とした「腐っていない構文」を持つ言語は一応例外として)


しかし、仕事では「腐った構文」持ち言語を使わなくてはならない。

S式言語ならマクロ定義して三文字ですむところを、何度も何度も複数行足さないといけないというのは、普通に苦痛だ。

それを修正するには、言語処理系自体にパッチを入れるしかないというのも、どうしようもない。

つまり、(少なくともこの点に関しては)「業務効率の改善」はできない。


----


他にLOLを読んでいて考えさせられたのは「簡潔理論」と「二重性理論」のところ。

「簡潔理論」の方はPaul Grahamがよく言ってたり実践してたりするので知っていたが、「二重性理論」の方は知らなかった。

これはインクリメンタル開発(もしくは単に「開発」)で重要だと思うので、定義と二重性理論だけ、記号をちょっと変えて引用しとこう(本書では「B」だったのを「A'」に変更した)。

Lをプログラミング言語、Fをその言語の機能、そしてAとA'をLで書いた任意のプログラムとする。

AからA'への変更に必要な改変作業が、Fを持たないLによって書かれた場合よりも少なくなるのなら、Fは構文の二重性という機能を提供する。

プログラムを構築するのに要する労力は、使われるプログラミング言語が提供する二重構文の総量に反比例する。

ただ、これを「構文の二重性」と呼ぶべきかどうかはかなり疑問に感じる。

本書のケースでは確かに「構文の二重性」ではあるものの、もう少し抽象度を高めて、より一般化できそうな気がするので。

名前の事はともかく、開発サイクルの高速化は、仕事でも非仕事でも重要な関心事なので、今後はもう少しこの辺も意識したい。

2008-09-15

[] 00:04

土日はNHKホールに行ってきた。アツかった。

やっぱり音楽は重要だ。

「桃と牛乳」と言おうとして無意識の内に「胡瓜と牛乳」と言ってしまった。

自分の頭の中では胡瓜の優先順位はかなり高いようだ。少なくとも桃よりは大幅に。

2008-08-31

[] 19:45

さっきの続き。

よく考えたら、 http://www.din.or.jp/~ohzaki/perl.htm#File_Random と同じアルゴリズムで、保存領域を複数にして、更新される保存領域もランダムに選ぶようにすれば、nの数が異様に大きい時は早くなる事に気付いた。

とりあえず、「そういう手もある」と気付いた時点で満足してしまったので、コードは省略。


[][] 19:31

今日の結論: あんまり役に立たない。


某所で「特定範囲内の乱数を重複せずにn個取得する」のに、「重複したらもう一回乱数を取得する」以外にスマートな方法は無いのか、という話が出てたので、なんとなくGaucheでやってみた。

(尚、「結果の乱数リストの順番もランダム」という条件を勝手に追加した)

;; 乱数取得手続きを用意
(use srfi-1)
(use math.mt-random)
(define m (make <mersenne-twister> :seed (sys-time)))
(define (get-random max-num)
  (mt-random-integer m max-num))

;; 重複しない、最大値がmax-numの乱数をlist-num個取得する
(define (get-uniq-random-int-list list-num max-num)
  ;; まず、基本となる乱数listを生成する
  (let1 rand-list (map
                    (lambda (adjust)
                      (get-random (- max-num adjust)))
                    (iota list-num))
    ;; 一つずつ補正していく
    (let next ((result '())
               (rest rand-list))
      (if (null? rest)
        result
        (next (cons (increment-check (car rest) (sort result))
                    result)
              (cdr rest))))))

;; TODO: ここはfoldを使った方が素直に書ける気がする
(define (increment-check num checklist)
  ;; (※ソート済の)checklistを先頭からチェックしていき、
  ;; numがchecklistと同じかそれ以上なら1ずつ増やす
  ;; (事で、結果としてunique性を確保する)
  (if (null? checklist)
    num
    (let1 true-num (if (<= (car checklist) num)
                     (+ 1 num)
                     num)
      ;; 順番に、checklist全部に対して繰り返す
      ;; (この為に、checklistは事前にソート済である必要がある)
      (increment-check true-num (cdr checklist)))))

;; 実行してみる
(get-uniq-random-int-list 8 10)
;; => (5 1 7 6 8 2 9 3)

(今回は副作用無し風味で書いたが、これに限っては、副作用バリバリで書いた方が効率は良くなると思う。)

要は、高校の確率統計とかでよくある、「数値の書かれた玉」の入った袋から一個ずつ取り出すような感じのアルゴリズム(ここでは仮に玉アルゴリズムと呼ぶ事にする)。

rand-listの要素の各数値は、「玉に書かれた数値そのもの」ではなく、「袋に残ってる玉に便宜上割り振ったインデクス値」という扱い。

この数値を「玉に書かれた数値そのもの」に戻すのがincrement-check手続き(名前はそれっぽくないが)。


問題は、これが「重複したらもう一回乱数取得しなおす」アルゴリズムよりも効率が良いのかどうかという点。

書いた当初は「いちいち一個ずつsortかけてるし、1ずつ足してるし、これ無茶苦茶遅いんじゃないか?役に立たないな」と思った。

しかし、よく考えると、

  1. 「特定範囲内の乱数を重複せずにn個取得する」のnが3とか5なら、sortや1ずつ足すのにかかるコストはたかが知れているので、「もう一回取得」アルゴリズムよりは遅いが、致命的に遅いという程ではない。
  2. 「特定範囲内の乱数を重複せずにn個取得する」のnが1000とかになると、sortや1ずつ足すコストは莫迦にならないが、「もう一回取得」アルゴリズムの場合、「今乱数取得した数値が、既に拾った乱数の中にあるかどうか」のチェックは線形検索せざるをえないので、どっちもどっち。
    • ……と言いたいが、実際のところは謎。ベンチ取るのは面倒なのでパス。
    • 尚、一応、線形検索を避けるようにも出来る筈。
  3. 例えば、「特定範囲内の乱数を重複せずにn個取得する」のnが1000で、更に「特定範囲」が0〜1200とかの場合、「もう一回取得」アルゴリズムでは重複率が高くなり、rand()実行回数が異様に多くなってしまう為、玉アルゴリズムの方が効率が良くなる。

と、状況によってどっちが良いかは変わってくるようなので、とりあえず、メモとして残しておく事にする。

尚、「結果の乱数リストの順番はソート済でよい」という条件なら、もう少しスマートな方法がありそうな気はする。

が、面倒なので今日はこれだけ。