HonokaBlog

Last battles

2chより。ガンダムラストバトル集

678 名前：そら(熊本県)[sage] 投稿日：2008/05/04(日) 18:03:33.28 ID:Kp5IFPry0
youtubeで見られるラストバトル集

Z http://www.youtube.com/watch?v=tCRUTQt_vfM
ZZ http://www.youtube.com/watch?v=z-sUvZF-ZEw
逆襲のシャア http://www.youtube.com/watch?v=30fZrYxxVpo
F91 http://www.youtube.com/watch?v=sXY_fBnGvkw
G（東方不敗） http://www.youtube.com/watch?v=xHSSDFBQ2Co
G http://www.youtube.com/watch?v=wi9f_IbAvIQ
X http://www.youtube.com/watch?v=D6EKSLHcEcY
∀ http://www.youtube.com/watch?v=SeWACe1FaSM
00 http://www.youtube.com/watch?v=kgGURs5b_q4

萌香を使えば京大にも入れるの巻

萌香で京大の入試問題を力技の巻

おまえにハートブレイク☆オーバードライブ - 小粋な数学入試問題より

......って引用しようと思ったけど数式が画像とか引用がめんどくさいので元記事読んでください。

んでこれの設問の2。これが萌香があれば解けちゃうんです。ソースはこちら

「レンジ を 「(開始 終点)
      「もし (開始 終点 >)
              '()
             「開始 「(開始 1.0 +) 終点 の レンジ」 の コンス」」
           の 仕事」 と 定義」


「階乗 を 「(a b)
        「もし (b 0.1 <=)   ;; たぶん無いけど丸め誤差とかがあったときのため
              1.0
             「(a (b 1.0 -) の 階乗) a *」」
       の 仕事」 と 定義」


「f を 「(n)
     「n の 7 の 剰余」
    の 仕事」 と 定義」


「g を 「(n)
        (3 に
           ((+
             0
             (「(num) 「num の n の 階乗」 の 仕事」 に
              「1 7 の レンジ」 を マップ)
          の 右畳み込み) の f)
           を かける)  仕事」 と 定義」



「「(n) 「n と 表示」
        「":" と 表示」
        「(n の g) と 表示」
        「改行」              の 仕事」 に
  「1 15 の レンジ」 を マップ」

これを実行すると6と12のところで18点ゲット。 fの性質よりmaxの点が18なので答案用紙に6と書けば、この問題はパーヘクツですよあなた !!

なんで中途半端な15までなのかって ?..........

萌香は数値をすべてRubyのFloatで保持しているため Cのdouble型の精度となります。そうすると仮数部が53 bitなため2^53を超えるところ 10^16のところで正確な計算ができなくなってしまい、 20のところで7^20が出て、これが10^16を超えるので正確な計算ができなくなりおかしな数字が出てしまう結果となります。これはここ(遥か彼方の彼方から - 小粋な数学入試問題をcodepadで組んでみた) のプログラムもおんなじ原因じゃないかと思ってたらすでに指摘があった.....

ちなみにRuby版が

#!/usr/local/bin/ruby


def pow(x, y)
  result = 1
  (1..y).each do |dummy|
    result = result * x
  end

  return result
end


def f(n)
  return n % 7
end


def g(n)
  return 3 * (f((1..7).map{|num| pow(num, n)}.inject(0){|sum, num| sum + num}))
end



(1..100).each do |num|
  puts "#{num}:#{g(num)}"
end

Scheme(Gauche)版が

#!/usr/local/bin/gosh

(use srfi-1)

(define pow
  (lambda (x y)
    (if (= 1 y)
	x
	(* x (pow x (- y 1))))))

(define f
  (lambda (n)
    (modulo n 7)))

(define g
  (lambda (n)
    (* 3 
       (f (fold + 0 (map (lambda (num) (pow num n))
			 (iota 7 1)))))))


(map (lambda (num)
       (format #t "~a: ~a\n" num (g num)))
     (iota 100 1))

となります。

どちらも100程度まではなんの問題もなく動きます。 Bignumなんかいらね、とか思ってたのですが、この程度でも必要になってくるのですね。

.Net Frameworkで画像を扱うときの基本

Bitmap#(set|get)Pixelは遅い

.Net Frameworkで画像ファイルにフィルタなどの処理でたくさんのピクセルの値を変更したい場合(set|get)Pixelメソッドを使用するとめちゃくちゃ遅いです。これはBitmapオブジェクトが単なる画像のコンテナじゃなくて他のいろんなものとの調停とかがあるからかな ?

とりあえず遅いです

そこで.Net Framework的にはBitmapデータの画像データをロックして自由にいじっても大丈夫なようにし、いじってアンロックするというのが作法みたいです。

手順

Bitmap#LockBitsメソッドを使いBitmapDataオブジェクトを獲得する。

得られたBitmapDataオブジェクトから画像データをコピー。具体的には

System.Runtime.InteropServices.Marshal.copy(bitmapdata.Scan0, (Byte[] buffer, (int)開始点, (int)長さ)

(Byte[])bufferを適当にいじる

いじった画像データを元のBitmapDataオブジェクトにコピー。具体的には

System.Runtime.InteropServices.Marshal.copy(Byte[] buffer, (int)開始点, bitmapData.Scan0, (int)長さ)

bitmapImage.UnlockBits(bitmapData) とかやって元のbitmap imageに変更を適用

See MemoNyanDum - Bitmap の内部色データにアクセスする

Microsoft Excel用CSVファイルの作成

Microsoft Excelで使用するためのCSV形式のファイルを作成しようとしたらはまりました。

現象

改行を含んだデータを1セルに入れるため、ダブルクォーテーションで囲んだのですが、中に入っている改行コードがCSV行末の改行と認識されてしまい列がめちゃくちゃになってしまいました。

ダブルクォーテーションに関わるExcelの挙動

何が原因だったかと言うと、自分はいつもCSVファイルを書く時カンマの後ろにスペースを入れるのですが、 (そのため以下のように文字列前後のスペースを取り除く) Excel的にはそういうのはだめでスペースから始まる文字列とみなされてしまいました。

で、おまけにExcelは先頭にないダブルクォーテーションは制御記号ではなくただの文字として扱ってしまい、結局ダブルクォーテーションで囲まれた改行は CSV的にエスケープされることなく行の終端記号として扱われてしまいました。

普段書いてたプログラム(in Ruby)

row = line.split(',').map {|elm| elm.strip}

ExcelのCSVファイル中の改行

Excelはセル内の改行にはLFを行の終端にはCR + LFを使っていました。これは、さすがにExcelがよきに計らってくれるかな。とりあえず動くので検証はめんどい。エディタでちょいちょいといかないかしら。

行終端がCR + LFなのは RFC4180的に妥当なのですが、なんでセル内の改行はLFだけなんだろう。同じように出力しようとするとちょっとめんどい

まとめ

とりあえず、Excelで使うためのCSVファイルを作成する上での注意点を Excelとは直接関係ない(RFCで定められたCSVファイル一般のことも含めて) まとめると。

カンマの前後にスペースを入れてはいけない。
漢字コードはShift JIS
改行コードはCR + LF。ただし、セル内の改行はLF

ちなみに使ったExcelはExcel2000 for Windows。最新のExcelならUTF-8は使えるかな ?

リンク

RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files

RFC4180日本語訳

雑感

今日初めてCSVファイルフォーマットのRFCを読みました。いろいろ、細かい点が知らなくてためになりました。

でもですよ、カンマの後ろにスペースは付けたいし、人間に見やすいようにカンマの位置というか文字列の開始位置をそろえたいじゃないですか。まぁ、そんな理由でmustでなくshould not be ignoredなのだと思います。

だからといって、自分一人で使うからいいやと自由な形式でプログラムを書いたりするとあとではまることになるんだな。きっと。

Mewでのsmtp認証

smtp認証

プロバイダのメールアドレスがsmtp認証になったんです。

で、そのための設定をしなければならなかったのですがまったく設定の必要はなかったです。 (popサーバのアドレスの変更とかは必要だった)

すごいですねMew

「Rubyで習作」の添削達

ユメのチカラ Rubyで習作に吉岡弘隆さんのRubyプログラムが掲載されていていろんな人が添削しています。

プログラムの内容は親(?)ファイルにLinuxディストリビューションのパッケージ情報が入っていて、 (複数の)子(?)ファイルにそれが入っている場合"include"と、入っていない場合"not-include"と表示するものです。 (各行がパッケージ名、各列が各ディストリビューションのテーブルとなる)

個人的には Tociyuki::Diary - 吉岡弘隆さんの「Rubyで習作」を添削が非常に参考になりました。

特にArrayの最初の要素とそれ以外の要素を分けるために

asianux, *dists = ARGV.collect do |filename|

とやるとこなんかは自分のイディオムに入ってなかったので大変参考になりました。

自分は最初

mother   = ARGV[0]
children = ARGV[1..-1]

なんてのを考えていました。

自分でやるなら結果をCSV形式にしてこんなかんじにしますでしょうか。

#!/usr/local/bin/ruby

mother_name, *child_names = ARGV

children = child_names.map {|name|
                aHash = Hash.new("not-include")
                IO.foreach(name) {|package_name|
                    aHash[package_name] = "include"
                }
                aHash
            }

IO.foreach(mother) {|package_name|
    tArray = [package_name] \
           + children.map {|child|
                 child[package_name]
             }
    puts tArray.join(", ")
}

テストデータがないためデバッグができないのでぜんぜん動かなかったらすみません。

とりあえずHashのデフォルト値を使ったので条件分岐がなくなったのがちょっとした利点です。

プログラム中の末尾再帰に関するメモ

「萌香」のコードを整理しようと思ってコードを読んだんですが、「末尾再起の最適化に関するメモ」というコメントがなにを書いてるんだかさっぱりわからない。ポルナレフAAを貼りたくなるぐらい何がなんだかわからない。なんか悪い薬でもやってたんだろうか。

きっと末尾再帰っぽいことがようやくできて舞い上がっていたんだろう。黒歴史として早く葬りたい。

解読してみる。

--- begin 本文 ---
末尾再帰の最適化に関するメモ

本プログラムには変数のフレームのスタックと継続のスタックが存在します。
Lexical scopeのクロージャなので、クロージャの再帰呼出しではフレームの
スタックが積まれることはありません。
(その呼出しへの参照が残っていた場合、そこに保持されている。)

クロージャの呼出し時に
フレームの退避 --> クロージャの実行 --> フレームの復帰
と行うと、クロージャの実行時に末尾再帰呼出しがあった場合
フレームの退避 --> クロージャの実行 -->
フレームの退避 --> クロージャの実行 --> フレームの復帰 --> フレームの復帰
となります。
ここで、フレームの退避はlexical scopeクロージャの場合フレームの
新規作製であり、作製されたフレームはクロージャの実行の終了とともに
GCによって回収されるようになります。

結局クロージャの実行時にフレームの復帰の継続がどんどん増えていくことに
なります。
フレームの復帰は最後のものだけ行えばよく、
末尾再帰の場合、フレームの復帰の継続を作製する場合、次の継続に
フレームの復帰があった場合継続の作製は行う必要はありません。

以上のことから、フレーム復帰の継続の作製を抑制すれば末尾再帰の
最適化になることになります。
--- end 本文 ---

--- 本プログラムには変数のフレームのスタックと継続のスタックが存在します。
これは単なる事実。ここでいう継続のスタックで保持されているものには次の関数呼び出しで使われる引数の保持先(return valueの戻し先)等様々なものがある。(わかりにくくてすみません。あとで整理する。)　なので厳密な「継続のスタック」ではないかも知れない。

--- Lexical scopeのクロージャなので、クロージャの再帰呼出しではフレームのスタックが積まれることはありません。
「クロージャの再帰呼び出し」ではなく「クロージャの呼び出し」。ちなみに現在の実装ではフレームを積んでおきながら、呼び出しと同時にクロージャ定義時のフレームの参照に変更している。あとでなおす。

--- (その呼出しへの参照が残っていた場合、そこに保持されている。)
「その」と「そこ」が何を指しているかわからない。

--- クロージャの呼出し時にフレームの退避 --> クロージャの実行 --> フレームの復帰と行うと、クロージャの実行時に末尾再帰呼出しがあった場合フレームの退避 --> クロージャの実行 -->フレームの退避 --> クロージャの実行 --> フレームの復帰 --> フレームの復帰となります。
ここで、フレームの退避はlexical scopeクロージャの場合フレームの新規作製であり、作製されたフレームはクロージャの実行の終了とともにGCによって回収されるようになります。
ここでいう「フレームの退避」はフレームチェインに新しいフレームを作成すること。(新しいフレームは既存のフレームチェインにつなげられる) なんで「退避」と言う言葉を使ったのかわからない。今考えると「フレームの退避」「フレームの復帰」は必要ないっぽい。(現在見えている変数フレームは継続スタックに保持されているじゃん) あとでなおす。

--- 結局クロージャの実行時にフレームの復帰の継続がどんどん増えていくことになります。フレームの復帰は最後のものだけ行えばよく、末尾再帰の場合、フレームの復帰の継続を作製する場合、次の継続にフレームの復帰があった場合継続の作製は行う必要はありません。

--- 以上のことから、フレーム復帰の継続の作製を抑制すれば末尾再帰の最適化になることになります。
現在の実装ではフレームの復帰が連続する場合その継続の作成を抑制しているがフレームの復帰は必要ないっぽい。あとでなおす。

朝日新聞の字体?の変更

今まで簡略化されていた文字を元の文字?の表記に戻すらしい。d.hatena.ne.jp/NAOI/20070109/1168334642

ところでこれって字体 ?(グリフ ?)の変更というので正しいのでしょうか。変換は一対一で出来るのでしょうか。葛城市の問題は ? 高と髙はどうなるの ? 今回の変更はそこまでの問題は扱わず単純にグリフの変更で対応できるもののみ扱うの ? 文字コードは難しいです(> <;)

ところで初めてのトラックバックなんだけどこれでいいのかな ? 引用元に迷惑掛けてないかな ?

Blog作りました

萌え指向プログラミング言語「萌香」を公開してから１年経ちました。

この一年何もしてないように見えていろいろやってたんですよ。エイトクィーンの記事を書こうと悪戦苦闘してたのですがなかなかうまく書けなくって。人にわかる文章書くのって難しいですね。

ほんとは一周年のときにエイトクィーンの記事くらいは書きたかったのですが、あきらめて中途半端ですが順列の作成プログラムをアップするだけにしました。(一応エイトクィーンのプログラムも出来てたはずなのですがどっかいっちゃった。)

今後ともよろしくお願いします。