/ 最近 .rdf 追記 設定 本棚

脳log[2019-02-05~]



2019年02月05日 (火) バーコードを無効化するというとき、ついバーを横切るように線を引きたくなるけど、たぶん人間が判断するならそれがひと目でわかる印だと思うけど、機械による読み取りを妨害するならバーを隠すかバーの間を埋めるかする方が効果があるはず。■今日長細い白テープでバーが隠してあるのを見た。初めてのパターン。


2019年02月02日 (土) returns the length in characters というとき、NULL 文字は文字にカウントされていない雰囲気(1)。GetWindowTextLength は(常にではないが) WM_GETTEXTLENGTH を生成すると書かれていて、WM_GETTEXTLENGTH の説明では NULL 文字を含まないと明記されている(2)。テキストがないとき 0 を返すということは、NULL 文字が勘定に入っていないことを示している(3)。1、2、3 のどれをとっても NULL 文字が数に入っていると考える理由にならない。厳密に言えば数に入っていることを否定する理由にもならないけども、傾きはある。■仕様は「確保するのに十分なサイズ」だとは言っていない。場合により実際より大きい長さが返ることがあるけど小さくなることはないので、この数字を当てにしてバッファのサイズを決めても良いと言っているだけ。NULL 末端文字配列を作りたい者が +1 するのは当人の都合であり責務である。■■■WM_GETTEXT メッセージのパラメータと戻り値における "including the terminating null character." と "not including the terminating null character." の混在は、一見すると注意力を試しミスを誘うようだけど、バッファとテキストの違いで理解できる。バッファのサイズを指定するとき、NULL 文字が勘定に入る。テキストの長さを指定するとき、NULL 文字が勘定に入らない。これが Windows API 全体で徹底されているかは知らないが、GetWindowTextLength には入っていないだろう。


2019年01月30日 (水)

最終更新: 2019-04-12T22:44+0900

[ProjectEuler] Problem 158

「解けなくて飛ばした問題の中で一番最初の問題」シリーズ。今は Problem 66 なんだけど……解けない。気を取り直してテキトーに興味の持てる問題に取りかかってみたのが Problem 158。Difficulty Rating は Problem 66 が 25 % で、Problem 158 が 55 %。100 % に近い方が難しいっぽい。

#!rubyw
# coding: utf-8

# Classified identity
#
# * p-value.
# * the number of characters that will increment p-value.
# ・ the number of characters that will not increment p-value. (can be calculated)
# ・ length. (counted externally)
# ・ string value and its rightmost character. (no use)

p1, p0 = [0] * 26, [0] * 26
("a".."z").each{|ch|
	p0["z".ord - ch.ord] += 1
}

2.upto(26){|length|
	q1, q0 = [0] * (27 - length), [0] * (27 - length)

	# increment
	p0.each.with_index{|sum, number|
		number.times{|n|
			q1[n] += sum
		}
	}

	# not increment
	p0.each.with_index{|sum, number|
		not_number = 27 - length - number
		not_number.times{|n|
			q0[n + number] += sum
		}
	}
	p1.each.with_index{|sum, number|
		not_number = 27 - length - number
		not_number.times{|n|
			q1[n + number] += sum
		}
	}

	puts "p(%2d) = %12d"%[length, q1.inject(&:+)]
	p1, p0 = q1, q0
}

過去に Problem 191 を解いた経験が生きている。ちなみに Problem 191 の Difficulty Rating は 35 %。


2019年01月25日 (金) [SakuraEditor] #765 #766 PR 本文の不備くらいって言われたけども、それは他者への最低限の礼儀であり必要条件だ。形式や枝葉ではなく核心(PR の目的)がないって言ってんだから当然だ。■内容を判断すればコードを費やすほどの価値がないという結論になる。そもそも価値を示す証拠が提出されていない。1.そこが問題(ホットスポット。ボトルネック)であること。2.アプリケーションで効果を実測すること。3.マイクロベンチマークに基づいて机上の空論を通すとしても、(ExtTextOut への)適用箇所が実験の条件に合致するという言質なり証拠なりがなければ論理がつながらない。そのどれかをクリアするのが必要条件で、でもマージするのに十分な条件ではない。でも必要から十分への間には主観的価値(「多少のペナルティに目をつぶっても記述は少ないほうがいい。API、ライブラリ、コンパイラに仕事をさせるほうがいい」)が含まれるから問わなかった。体裁ぐらい、ではなく、体裁だけでも、だった。ちまちましたことに血道をあげるモチベーションを削ぐこともないと思ったから。■自分にとっての最適化、リファクタリングのひとつは MyFillRect のような無駄を取り除くことにある。既存の道具を使わない理由がない。だって FillRect はボトルネックでも使ってはいけない罠 API でもないでしょう? そうして非本質的なコード、絡み合って生じた無駄な処理を省いていけばエディタとしての本質、不可欠な処理に集中できるし、コードサイズ(メモリフットプリント)が減れば、コードパスが短くなれば、一般に速度の向上が期待できる。頭を悩ませるトレードオフは存在しない。■■■CGraphics クラスのチューニングとしての MyFillRect はやって悪くないのかもしれない。グローバル名前空間に FillRect と併存するものでなく、CGraphics::FillMyRect の実装の工夫としてなら。CGraphics 利用者と実装者の間では関心の分離がなされているし、CGraphics のような間接クラスには利用に当たってオーバーヘッドが最小限となるような非機能要件があるだろうから、速度を追う理由がある。■でもこういう大枠で合意することはできないだろうな。だって未だに「速度は(主たる)理由ではない」って言うんだもんな。たしかに最初から「速度は障害にならない」というような言い方をしてるんだけど、でも、だったら何なのかをさっぱり語らない。「悪くならない」「障害ではない」「再考する」「置き換える」は変更の理由ではない。満足できる理由ではないってんではない。行動を説明する理由や目的としての体をなしてないってんだ。でも筋が通らないままマージされた。これが誤算。無理が通るなら俺は狂って死ぬ。


2019年01月24日 (木) 病気を自認して都合のいい言い訳とすることは警戒すべき傾向だけど、でも、面白いことが書いてあるんだよなあ。「自閉症 - Wikipedia」 あれもこれもそれもどれも、誰にでも当てはまることが症状として書かれてるんじゃないかなあ。そりゃオレオレアスペが流行るはずだ。


2019年01月23日 (水) Firefox ESR 52.9.0 に続いて Vivaldi 1.0 でも GitHub のスクリプトが機能しなくなった。Files Chenged, Checking mergeability, Show all checks, Labels, Preview, Edit など、コメントの新規投稿以外ほぼ壊滅。どうしようかな。■@2019-02-12 スタイルシートを切ったらすべてのフォームが予め HTML の形で用意されていたことがわかった。スクリプトがやっていたことはそれらを出し入れするだけ。じゃあまあなんとかなる。


2019年01月22日 (火) auかんたん決済というのは、au が「パートナーサイト(アマゾンなど)」とユーザー(自分)との間のゲートウェイになるものではないらしい。一度パートナー登録すれば以後はパートナーに財布の紐を預けっぱなし。au の側ではユーザーになんのコントロールも提供しない。パートナーサイトと連絡が取れなくて継続課金が発生してるときは連絡してね、ってだけの放置プレイ。他人の財布を何だと思っているのか。口座振替の目的外転用に同意するのではなかった。口座振替にしたって銀行には承認プロセスをいちいち踏んでほしいと思ってる。移動通信端末が行き渡った今ならそれができるはずだ。もともと au に無制限に財布の紐を預けることすら不本意だったということ。それが au を通してアマゾンその他へも行き渡るのが auかんたん決済。もうやめた。


2019年01月20日 (日) わかりやすさ」について、過去にこんなふうに書いていた。「~するところの解読がまだ。プログラム全体としては無駄がなくて、そういう意味ではわかりやすいんだけど。」■必然によって編み上げられたコードはすべての要素が目的に向かって整列していて、すべての要素が不可欠に機能しているから、論理を追うのに迷わせる無駄なものがない。どこにいても目的への途上だし、どこからでも目的に向かっていける。馬鹿者が付け加えた無駄に対して「なんでこれが必要? なんで無駄な回り道をする? そうしなければいけない理由を(自分が)見落としている?」と惑わされることがない。■プロ棋士という存在について想像すると、底の浅い論理ほど御しやすいものはないのではないか。人間同士の駆け引きでは、論理や必然から外れた遊びが意外に有効なことがあるのではないか。それは「わかりにくさ」につながり、惑わせるから。■3月のライオン第4巻の宗谷名人の台詞「君は僕を信用し過ぎだ」は、名人の落ち度を必然と信じて自分の見落としを疑うような心理を指していると理解してる。必然だから付け入る隙はないと最初から諦めてしまうことか。


2019年01月19日 (土) 5冊の本が、わたしを自己正当化から自由にしてくれた|Dain(スゴ本の中の人) | Dybe!」■『[単行本(ソフトカバー)] アービンジャー インスティチュート, 金森 重樹, 冨永 星【自分の小さな「箱」から脱出する方法】 大和書房』と同時に『[文庫] アガサ・クリスティー【春にして君を離れ (ハヤカワ文庫―クリスティー文庫)】 早川書房』が紹介されているのが嬉しかった。20160229で一緒に読み直したうちの2冊だったから。


2019年01月18日 (金) 今日見ていたアニメ「シュヴァルツェスマーケン」で初めて知ったこと。「出色の~」は「シュッショクノ~」と読むんだってこと。他のアニメで聞いた「ミズヲエタサカナ」の類だと思ったら、自分の方が間違っていたでござる。


2019年01月17日 (木) 本の虫: Possibility of writing English C++ textbooks」■印象だけど、タイトルの「English C++ textnooks」から筆者の意図とはおそらく異なる意味を読み取ってしまった。本来の意図は「write ... in English」ではないかと思った。■「3 [限定] 英語の an ~ text|英語の本文.(ジーニアス英和辞典)」「2 relating to the language used in Britain, the US, Australia and some other countries: English grammar(ロングマン現代英英辞典)」という意味があるのは知ってる。でもスッと入ってこなかった。それぞれの辞典で最後となる3番目や2番目に挙げられた意味だということもあるし、イングランド方言の C++ について書かれたテキストである可能性が否定できないあたりが迂遠な表現だなと。■このブログの筆者が自分より英語力があるのは普段の記事を読んでいて間違いのないところではある。


2019年01月16日 (水) 小学校の国語の時間に、理由を聞かれているときの答えは「~から」のような形になるということを仕込まれたと思う。大人だからってそれができるとは期待できないかもしれないとは『[単行本] 新井 紀子【AI vs. 教科書が読めない子どもたち】 東洋経済新報社』が警告している。そのレベルで話が通じないと自分が自殺する精神科医になった気分になる。正常と異常は裏表であって一対一で向き合うと取り込まれて頭が狂ってしまうのではないか。ひょっとしたら正常になってしまったのかもしれない。結果をなんと表現してもそれまでの自分は死んでいる。


2019年01月15日 (火)

最終更新: 2019-01-15T14:13+0900

[ProjectEuler] Problem 29

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

普通に手続き的に書けば一瞬で答えが出る問題だったのに、前回も今回も(同じ)プログラムのバグのために答えが出なくて、でも素因数分解して漏れなく重複なく数えることもできなくて困っていた。バグが取れたので答えを出すのはコンピュータに任せる。

#!rubyw
# coding: utf-8

h = {}
(2..100).each{|b|
	(2..100).inject(b){|_,|
		_ *= b
		h[_] = _
	}
}
p h.size

最終更新: 2019-01-16T18:40+0900

[ProjectEuler] Problem 32

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

(そういえば以前も何度となく同じことを書いていたなと思い出しながら)泥臭く手を動かしただけ。

#!rubyw
# coding: utf-8

Digits = *1..9
found = {}
(1..2).each{|_|
	Digits.combination(_){|l_cmb|
		l_cmb.permutation{|l| l = l.join('').to_i
			Digits.combination(5-_){|r_cmb|
				r_cmb.permutation{|r| r = r.join('').to_i
					p = l * r
					found[p] = "#{l} * #{r} = #{p}" if /^(?:([1-9])(?!.*\1)){9}$/ =~ "#{l}#{r}#{p}"
				}
			}
		}
	}
}
p found.keys.inject(&:+)

最終更新: 2019-01-15T16:36+0900

[ProjectEuler] Problem 33

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

ただ手を動かしただけ。

#!rubyw
# coding: utf-8
require 'mathn'

found = []
(1..9).each{|numer|
(1..9).each{|denom|
	frac = numer / denom
	(numer+1..9).each{|cancel/|
		found.push("#{numer}#{cancel/}/#{cancel/}#{denom}") if frac == (numer*10 + cancel/) / (cancel/*10 + denom)
	(1..denom-1).each{|cancel\|
		found.push("#{cancel\}#{numer}/#{denom}#{cancel\}") if frac == (cancel\*10 + numer) / (denom*10 + cancel\)
	}}
}}
p found
p found.map(&:to_r).inject(&:*).denominator

最終更新: 2019-01-15T17:32+0900

[ProjectEuler] Problem 35

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

以前は require 'prime' を避けてた気がするけど、今回は使ってる。そうすると、ただコードに落とすだけ。

#!rubyw
# coding: utf-8
require 'prime'
require 'set'

primes = Prime.each(1_000_000).to_set
primes = primes.select{|p|
	s = "#{p}#{p}"
	l = s.length/2
	(1..l-1).all?{|i|
		primes.include? s[i, l].to_i(10)
	}
}
p primes
p primes.size

最終更新: 2019-01-15T21:09+0900

[ProjectEuler] Problem 36

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

例によって手を動かしただけ。

#!rubyw
# coding: utf-8

PalindromeGen = lambda{|digits|
	return Enumerator.new{|y|
		_next = lambda{|a|
			return digits.map{|_|
				a.map{|p10|
					"#{_}#{p10}#{_}"
				}
			}.flatten
		}
		odd  = *digits
		even = digits.zip(digits).map{|_| _.join('') }
		yielder = lambda{|p| y << p}
		loop {
			odd = _next[odd.each(&yielder)]
			even = _next[even.each(&yielder)]
		}
	}
}
p10gen = PalindromeNGen["0".."9"]
p2gen  = PalindromeNGen["0".."1"]
found = {}
loop {
	p10 = p10gen.next.to_i(10)
	break if 1_000_000 < p10
	p2gen.next    while p2gen.peek.to_i(2) <  p10
	found[p10] = p10 if p2gen.peek.to_i(2) == p10
}
p found.keys.map{|_| [_.to_s(10), _.to_s(2)] }
p found.keys.inject(&:+)

最終更新: 2019-01-15T23:54+0900

[ProjectEuler] Problem 37

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

手を動かしただけ。

#!rubyw
# coding: utf-8
require 'prime'
require 'set'

primes = Set.new
found = {}
Prime.each{|p| p = p.to_s(10)
	primes << p
	next if p.length == 1
	next unless (1..(p.length-1)).all?{|w| primes.include? p[0,w] }
	next unless (1..(p.length-1)).all?{|i| primes.include? p[i,p.length-i] }
	p found[p] = p
	break if found.size == 11
}
p found.keys.map(&:to_i).inject(&:+)

最終更新: 2019-01-16T18:01+0900

[ProjectEuler] Problem 38

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

手を動かしただけ。

#!rubyw
# coding: utf-8

found = {}
i = 1
9.downto(2){|n|
	loop {
		s = (1..n).map{|_| _*i }.join('')
		break if 9 < s.length
		i += 1
		next if s.length < 9
		next if s.index "0"
		found[s.to_i] = [i-1, 1..n] unless /(.).*\1/ =~ s
	}
}
p found
p found.keys.sort.reverse

最終更新: 2019-01-16T00:54+0900

[ProjectEuler] Problem 41

解けなくて飛ばした問題の中で一番最初の問題に再チャレンジ。

素数って実はありふれてるので9桁までの素数を列挙するだけで許容時間(1分間)をオーバーしてしまう。9桁の順列(362880通り)を列挙して素数判定する方が早い。

#!rubyw
# coding: utf-8
require 'prime'

found = ("1".."9").map{|n|
	("1"..n).to_a.permutation.map{|_| _.join('').to_i }.select(&:prime?)
}.flatten
p found.sort.reverse

最終更新: 2019-01-16T03:47+0900

[ProjectEuler] Problem 54

面倒くさくて飛ばした問題にチャレンジ。

poker.txt の内容は本当にランダムなのか3番目までの高い役が1個も入ってなくて、コーディングの苦労が報われない。

#!rubyw
# coding: utf-8

Order = "23456789TJQKA"
flush = lambda{|cards|
#	p ["flush", cards] if (cards.match(/^ .(.)(?: .\1){4}/)||[])[1]
	(cards.match(/^ .(.)(?: .\1){4}/)||[])[1]
}
straight = lambda{|cards|
#	p ["straignt", cards] if cards.scan(/ (.)/).map{|_,| Order.index _ }.sort.tap{|_| break _ == (_[0].._[0]+4).to_a ? Order[0] : nil }
	cards.scan(/ (.)/).map{|_,| Order.index _ }.sort.tap{|_| break _ == (_[0].._[0]+4).to_a ? Order[0] : nil }
}
four = lambda{|cards|
	p ["four", cards] if cards.scan(/ (.)/).sort.join('').scan(/(.)\1{3}/).map{|_,| _ }[0]
	cards.scan(/ (.)/).sort.join('').scan(/(.)\1{3}/).map{|_,| _ }[0]
}
three = lambda{|cards|
#	p ["three", cards] if cards.scan(/ (.)/).sort.join('').scan(/(.)\1{2}/).map{|_,| _ }[0]
	cards.scan(/ (.)/).sort.join('').scan(/(.)\1{2}/).map{|_,| _ }[0]
}
pairs = lambda{|cards|
#	p ["pairs", cards] unless cards.scan(/ (.)/).sort_by{|_,| - Order.index(_) }.join('').scan(/(.)\1/).map{|_,| _ }.empty?
	cards.scan(/ (.)/).sort_by{|_,| - Order.index(_) }.join('').scan(/(.)\1/).map{|_,| _ }
}
highcards = lambda{|cards|
#	p ["highcards", cards]
	cards.scan(/ (.)/).sort.join('').gsub(/(.)\1+/, '').split(//).sort_by{|_| - Order.index(_) }
}
fullhouse = lambda{|cards|
#	p ["fullhouse", cards] if pairs[cards].length == 2 and three[cards]
	pairs[cards].length == 2 and three[cards]
}
straightflush = lambda{|cards|
	suit = flush[cards]
	first = straight[cards]
	p ["straightflush", cards] if suit and first
	suit and first
}
royalflush = lambda{|cards|
	first = straightflush[cards]
	p ["royalflush", cards] if first and first == 'T'
	first and first == 'T'
}

compare = lambda{|h|
	h.map{|_| Array(_).map{|_| _ ? Order.index(_)||-1 : -2 } }.tap{|h| break h.first.length != h.last.length ? h.first.length <=> h.last.length : h.first <=> h.last }
}

contest = lambda{|c|
	[royalflush, straightflush, four, fullhouse,
	 flush, straight, three, pairs, highcards
	].each{|ranktest|
		h = c.map(&ranktest)
		return compare[h] if h.any?{|_| _ and not _.empty? }
	}
	raise "no contest"
}

p DATA.lines.map{|ln|
	p1 = " " + ln[0, 15]
	p2 = ln[14, 15] + " "
	contest[[p1, p2]]
}.count(1)

__END__
content of poker.txt here.