おまえにハートブレイク☆オーバードライブ - 小粋な数学入試問題 より
......って引用しようと思ったけど数式が画像とか引用がめんどくさいので元記事読んでください。
んでこれの設問の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で画像ファイルにフィルタなどの処理で たくさんのピクセルの値を変更したい場合(set|get)Pixelメソッドを 使用するとめちゃくちゃ遅いです。これはBitmapオブジェクトが 単なる画像のコンテナじゃなくて他のいろんなものとの調停とか があるからかな ?
とりあえず遅いです
そこで.Net Framework的にはBitmapデータの 画像データをロックして自由にいじっても大丈夫なようにし、 いじってアンロックするというのが作法みたいです。
System.Runtime.InteropServices.Marshal.copy(bitmapdata.Scan0, (Byte[] buffer, (int)開始点, (int)長さ)
System.Runtime.InteropServices.Marshal.copy(Byte[] buffer, (int)開始点, bitmapData.Scan0, (int)長さ)
改行を含んだデータを1セルに入れるため、 ダブルクォーテーションで囲んだのですが、 中に入っている改行コードがCSV行末の改行と認識されてしまい 列がめちゃくちゃになってしまいました。
何が原因だったかと言うと、 自分はいつもCSVファイルを書く時カンマの後ろにスペースを入れるのですが、 (そのため以下のように文字列前後のスペースを取り除く) Excel的にはそういうのはだめでスペースから始まる文字列と みなされてしまいました。
で、おまけにExcelは先頭にないダブルクォーテーションは制御記号ではなく ただの文字として扱ってしまい、結局ダブルクォーテーションで囲まれた改行は CSV的にエスケープされることなく行の終端記号として扱われてしまいました。
row = line.split(',').map {|elm| elm.strip}
Excelはセル内の改行にはLFを行の終端にはCR + LFを使っていました。 これは、さすがにExcelがよきに計らってくれるかな。 とりあえず動くので検証はめんどい。 エディタでちょいちょいといかないかしら。
行終端がCR + LFなのは RFC4180的に妥当なのですが、 なんでセル内の改行はLFだけなんだろう。 同じように出力しようとするとちょっとめんどい
とりあえず、Excelで使うためのCSVファイルを作成する上での注意点を Excelとは直接関係ない(RFCで定められたCSVファイル一般のことも含めて) まとめると。
ちなみに使ったExcelはExcel2000 for Windows。 最新のExcelならUTF-8は使えるかな ?
今日初めてCSVファイルフォーマットのRFCを読みました。 いろいろ、細かい点が知らなくてためになりました。
でもですよ、カンマの後ろにスペースは付けたいし、 人間に見やすいようにカンマの位置というか文字列の開始位置を そろえたいじゃないですか。 まぁ、そんな理由でmustでなくshould not be ignoredなのだと思います。
だからといって、自分一人で使うからいいやと自由な形式で プログラムを書いたりするとあとではまることになるんだな。きっと。
]]>プロバイダのメールアドレスがsmtp認証になったんです。
で、そのための設定をしなければならなかったのですが まったく設定の必要はなかったです。 (popサーバのアドレスの変更とかは必要だった)
すごいですねMew
]]>プログラムの内容は親(?)ファイルに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のデフォルト値を使ったので条件分岐がなくなったのがちょっとした利点です。
]]>きっと末尾再帰っぽいことがようやくできて舞い上がっていたんだろう。黒歴史として早く葬りたい。
解読してみる。
--- begin 本文 ---
末尾再帰の最適化に関するメモ
本プログラムには変数のフレームのスタックと継続のスタックが存在します。
Lexical scopeのクロージャなので、クロージャの再帰呼出しではフレームの
スタックが積まれることはありません。
(その呼出しへの参照が残っていた場合、そこに保持されている。)
クロージャの呼出し時に
フレームの退避 --> クロージャの実行 --> フレームの復帰
と行うと、クロージャの実行時に末尾再帰呼出しがあった場合
フレームの退避 --> クロージャの実行 -->
フレームの退避 --> クロージャの実行 --> フレームの復帰 --> フレームの復帰
となります。
ここで、フレームの退避はlexical scopeクロージャの場合フレームの
新規作製であり、作製されたフレームはクロージャの実行の終了とともに
GCによって回収されるようになります。
結局クロージャの実行時にフレームの復帰の継続がどんどん増えていくことに
なります。
フレームの復帰は最後のものだけ行えばよく、
末尾再帰の場合、フレームの復帰の継続を作製する場合、次の継続に
フレームの復帰があった場合継続の作製は行う必要はありません。
以上のことから、フレーム復帰の継続の作製を抑制すれば末尾再帰の
最適化になることになります。
--- end 本文 ---
--- 本プログラムには変数のフレームのスタックと継続のスタックが存在します。
これは単なる事実。ここでいう継続のスタックで保持されているものには次の関数呼び出しで使われる引数の保持先(return valueの戻し先)等様々なものがある。(わかりにくくてすみません。あとで整理する。) なので厳密な「継続のスタック」ではないかも知れない。
--- Lexical scopeのクロージャなので、クロージャの再帰呼出しではフレームのスタックが積まれることはありません。
「クロージャの再帰呼び出し」ではなく「クロージャの呼び出し」。ちなみに現在の実装ではフレームを積んでおきながら、呼び出しと同時にクロージャ定義時のフレームの参照に変更している。あとでなおす。
--- (その呼出しへの参照が残っていた場合、そこに保持されている。)
「その」と「そこ」が何を指しているかわからない。
--- クロージャの呼出し時にフレームの退避 --> クロージャの実行 --> フレームの復帰と行うと、クロージャの実行時に末尾再帰呼出しがあった場合フレームの退避 --> クロージャの実行 -->フレームの退避 --> クロージャの実行 --> フレームの復帰 --> フレームの復帰となります。
ここで、フレームの退避はlexical scopeクロージャの場合フレームの新規作製であり、作製されたフレームはクロージャの実行の終了とともにGCによって回収されるようになります。
ここでいう「フレームの退避」はフレームチェインに新しいフレームを作成すること。(新しいフレームは既存のフレームチェインにつなげられる) なんで「退避」と言う言葉を使ったのかわからない。 今考えると「フレームの退避」「フレームの復帰」は必要ないっぽい。(現在見えている変数フレームは継続スタックに保持されているじゃん) あとでなおす。
--- 結局クロージャの実行時にフレームの復帰の継続がどんどん増えていくことになります。フレームの復帰は最後のものだけ行えばよく、末尾再帰の場合、フレームの復帰の継続を作製する場合、次の継続にフレームの復帰があった場合継続の作製は行う必要はありません。
--- 以上のことから、フレーム復帰の継続の作製を抑制すれば末尾再帰の最適化になることになります。
現在の実装ではフレームの復帰が連続する場合その継続の作成を抑制しているがフレームの復帰は必要ないっぽい。あとでなおす。
ところでこれって字体 ?(グリフ ?)の変更というので正しいのでしょうか。変換は一対一で出来るのでしょうか。葛城市の問題は ? 高と髙はどうなるの ? 今回の変更はそこまでの問題は扱わず単純にグリフの変更で対応できるもののみ扱うの ? 文字コードは難しいです(> <;)
ところで初めてのトラックバックなんだけどこれでいいのかな ? 引用元に迷惑掛けてないかな ?
]]>この一年何もしてないように見えていろいろやってたんですよ。エイトクィーンの記事を書こうと悪戦苦闘してたのですがなかなかうまく書けなくって。人にわかる文章書くのって難しいですね。
ほんとは一周年のときにエイトクィーンの記事くらいは書きたかったのですが、あきらめて中途半端ですが順列の作成プログラムをアップするだけにしました。(一応エイトクィーンのプログラムも出来てたはずなのですがどっかいっちゃった。)
今後ともよろしくお願いします。
]]>