「リテラル」を含む日記 RSS

はてなキーワード: リテラルとは

2018-02-25

pythonって一貫性なさすぎじゃない?

いや、実用的で素晴らしい言語だと思うよ。

でもさ、なんか一貫性が無いように感じるんだよね。

まず、言語の大半の部分がオブジェクト指向言語っぽいデザインになってるのに、listの要素数を測る手段len()って*関数*なのはどうなの?

(しか略語って...)

a = [1, 2, 3]
len(a)  # 3

他にもあるよ! pythonくんのアレな所

俺は、sortとsortedって言う命名からこの挙動をまったく予測できなかった。

  • 破壊的変更をする list.sort()
a = [1, 3, 2]
a.sort()  # None
a  # [1, 2, 3]
sorted([1, 3, 2])  # [1, 2, 3]

しかもsortedにdictを渡すとkeyがlistに変換されてソートされて返ってくる。

コードリーダビティに関する本を開けば、どの本にだって「良い名前選択する」ことの重要性が書かれていると思う。

「sort()が破壊的で、sorted()が非破壊的、sorted()にdictを渡すとkeyのlistがソートされて返ってくる」これって良い命名なのかな?

pythonくんってこう言う所あるよね

配列の要素を文字列連結

", ".join(['1', '2', '4', '8', '16'])  # "1, 2, 4, 8, 16"

えーっ、join()のレシーバー区切り文字って…引くわー

しかも、これに対する「文字列リテラル (文字列定数) のメソッドを使うのは*醜すぎる*」という意見に対しての公式の返答が、これってのも凄い。

かにそうかも知れませんが*文字列リテラルは単なる固定された値に過ぎないというのが答えです。文字列に束縛された名前メソッドが許されるなら、リテラルに使えないようにする論理的理由はないでしょう。

https://docs.python.jp/3/faq/design.html#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

The Zen of Pythonで「醜いより美しい方がいい」って言ってましたやん。

そもそもリテラルかどうかに関係なくstrインスタンスにこのメソッドがある事がおかしいと思った。

なんでpythonくんって一貫性ないの? pythonくん「歴史です」

pythonmap関数として実装されている。(まただよ...)

list(map(lambda x: x*x, [1, 2, 3]))  # [1, 4, 9]

なんでメソッドにしなかったの? って質問に対して公式がこう答えてる。

主な理由歴史です。複数の型に対しての総称的な操作で、対象オブジェクトメソッドを全く持っていなかった (例えば、タプル) としても働くよう意図したもの関数は使われました。

(中略)

個々のケースについては粗探しのしようがありますが、Python の一部であるし、根本的な変更をするには遅すぎます

https://docs.python.jp/3/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list

うわー、信じられねぇ…

歴史的経緯があるから一貫性が無いのは仕方ないみたいなこの感じ。

これが設計思想に「醜いより美しい方がいい」を掲げるpython実装なんだねぇ…

pythonくんの良い所

散々pythonの事を悪く言ったけど、おれ実はpythonくんの良い所もいっぱい知ってるんだ。

pythonくんの良い所:

ライブラリが超充実してる!
インデントコードブロック表現する文法クール!
PEP8という規約であるべきコードフォーマットを明示したのが良いよね。
Cythonで高速化楽ちん!
namespaceが使いやすい! デコレーター便利!

美しくない、それゆえに強いプログラミング言語python

The Zen of PythonPython設計思想が色々書いてある。

「醜いより美しいほうがいい」という指針があることはさっき紹介した通りだ。

pythonがそれを体現してるとは、僕にはどうも思えない。

でもThe Zen of Pythonには「Although practicality beats purity.(実用性を求めると純粋さが失われることがある。)」とも書いてある。

pythonはこの設計思想を他の言語には無い高いレベル体現してるとは思う。

pythonは、

節操に色々取り入れた上で、「tupleからメソッドはやせないから、map関数にする」とか、メチャクチャ方法でそれらを統合した言語だ。

だが、そういう言語からこそ、pythonで書いたコードを育てていく中で様々なパラダイムへとシームレスに変化させていく事ができる。

そういう「不純であるがゆえに柔軟性を持ったプログラミング言語pythonだと思う。

ruby純粋性はすごいよ。イカれたくらい徹底されたオブジェクト指向

BaseObjectをrootとする継承のツリーの中に世界のすべてが収まっている。

haskell純粋性も凄い。「代入が無い」プログラミング言語に初めてであった時の衝撃。

でも、そういう純粋性をかなぐり捨てたpythonにはタブーが無い。

不純で醜い、それゆえに強い言語python.

から僕はrubyとの思い出を反芻し、haskellに焦がれながら、明日pythonを選び、書いていく。

2017-12-01

素数判定の話

最近記事面白すぎるRuiさんに書かれる前に概要だけ書く。

人類最速の素数判定プログラムを書く場合最初素数は全部リテラルで埋め込むのが良いらしい。

2017-06-21

プログラミングセンスの有無

http://gothedistance.hatenadiary.jp/entry/2017/06/20/103000

練習以前の話として。

例えば、

y = x;

という代入文1行でいいところを、しか最初はこう書いていたのに動かないからといって、よりによってこの箇所を

if (x == 0) {
    y = 0;
} else if (x == 1) {
    y = 1;
} else if (x == 2) {
<以下略

と、考えられる値すべてについての条件文に書き直してしまって、さらコピペ後の書き換えをミスってバグを仕込んでしまった例を見たときは「こいつはセンスがないな」と思った。

逆に、最初からif文の羅列を書いてしまうような人が、「これは正解ではないと思うが、どう書いていいかからない」と言ってたときは「こいつはセンスがあるな」と思った。

(if文の羅列自体がどうかという向きもあるかもしれないが、学習段階によっては代入文の右辺にリテラルしか置けないと思ってしまっていることはあり得るので、特段変なことではない)

2014-04-09

http://anond.hatelabo.jp/20140409110204

Java文字列連結は+を使えばStringBuilder()に最適化されるから、+を使っておけばよい

いやいや、最適化されるのってリテラルの連結だけだろ?

使い分ける必要もない。

+禁止、StringBuilderのみ、でいいだろ?

2013-06-29

http://anond.hatelabo.jp/20130629071534

架空アカウント使ってのランキング操作ぐらいお手のものだと思うが。

からさまにやり過ぎるとすぐバレるので火付けぐらいの個数にしておいて

うまくいけばランキング入り。

それにランキングに乗るようにネタタイトルもかなり考えてあると思う。

こうなるともうリテラルシーとかのレベルではない。

2013-05-14

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき、女はどう答えたらいいの?

あ、まず前提として、

貴女プログラミング大好き男を夢中にさせることが、

はたして貴女幸福にするかどうか、それはまた別問題だけれど。

はいえ、プログラミング大好き男たちは玉石混交ながら、

IT系の超かしこい男なども多く、

多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこ学生まぁこれは有望株)か研究者系なんか、

あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます(キリッ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、

したがって、釣り師たる女たちにとっては、

なかなかあなどれない釣り場です。

では、プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女は、どう答えれば理想的でしょう?

まず最初に、その男COBOLのようなタイプレガシーコード

あとはC/C++、そして(TechEdに参加するほどではないけれど)VisualBasicが大好きな、

そんなタイプ場合は、

貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、

「わたしが、仕様書を作ってあげる♪」

これこそまさに必殺の答えです。

そこでプログラミング大好き男が、えへへ、とやにさがったならば、

貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを

ひそかに練習しておきましょう。これで成功まちがいなしです。

しかし、ここでは、もう少しハイブロウな(?)いわゆるプログラミング好きの男の

落とし方をお伝えしましょう。

この場合貴女は、こう答えましょう、

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

もしも貴女がそう答えたならば、

その瞬間、プログラミング大好き男の目はきらりと輝き、

かれの貴女への恋心は、

20%増量になるでしょう。

なぜって、Scalaは、

ちょっぴりお洒落Ruby風味に記述できて、

Maybeモナド差し込んで、

コンパイルは遅いながらも、そこがまた

ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。

しか関数型言語としての不変変数・不変Listを実装して

質高くふるまっていて、なおかつ、

JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド型推論を実装した功績もあって。

したがってScalaこそは、

本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、

インタプリタ言語大好きな綺麗系OLと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、

この世界で唯一(いいえ、JVM系列のJRubyClojure と並んで唯三)遭遇しうる場所です。


では、参考までに、危険な回答を挙げておきましょう。

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女がこう答えたとしましょう、

MicrosoftVisual Basic for Applicationが好き♪ 週3回は Excelコーディングするの。」

その瞬間、プログラミング大好き男の貴女への恋心は消えます、

なるほどMicrosoftは、世界最大のOS供給メーカー

特にOfficeは平凡ながら、ま、無難にまとめてあるものの、

しかし、「新UIのリボンUI!」「メトロUI対応!」とかなんとか無意味な自慢を吹聴し、

VBAはさらプログラミングについての謬見を撒き散らした罪がありますからプログラミング大好き男にとっては天敵なんです。

ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど

社内SESIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。

また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに7件あるよ♪」

と答えたとしても、同様の効果をもたらすでしょう、

なぜって、PHPは、1990年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、

しかし2000年代うそうからセキュリティ関係の問題で転落し、

いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。

(注1)

またもしもたとえあなたプログラミング言語が大好きで、

「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、

最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」

と、答えたとしたらどうでしょう

なるほど、貴女の趣味は高く、

しか.NET Frameworkは、C# が cool であるのみならず、

.NET Framework上で動く F# や IronPythonIronRubyマネーJScriptも最高においしいんですけれど、

しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、

(なんだよ、MS信者な女だな、カネかかりそう)って。

(注2)

貴女が、プログラミングが大好きで、言語の名を挙げるにしても、

たとえば、JavaScript(node.js)ならば安心でしょう、

なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、

貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたプログラミング言語おた宣言をしているとは受け取られないでしょう。

しろへぇ。ちゃんとprototypeは使ってる?」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。

男は嬉々として、30個くらいのnode.jsフレームワークを教えてくれることでしょう。(まぁどれもどれで帯に短し襷に長しなんですが)

あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。

しかし、たとえば、世界が(つーか竹内先生ポール・グレアムが)誇る超絶関数型言語の名作、Common Lispにせよ、

selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、

バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすRubyにせよ、

まったく読めない$_だらけで頭悪い仕様リセットしてPerl6にする(そしてまた全く読めない)Perlにせよ、

気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語ひまわりなでしこにせよ、

基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、

そういう言語名前をいきなり挙げるのは、ちょっぴり微妙。

ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクトオイラーの問題もうほとんどHaskellで、解いちゃった♪」

と答えたならば、どうでしょう

これはかなり博打な答え方で、

なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、

あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、

へぇ、やっぱりHaskellなら大抵の問題は4行以内くらいで解いちゃった?」とか言いながら

鼻の下がだら~んと伸びちゃう可能性もあるにはありますが、

しかし、逆に、(なんだよ、この女、プログラミングおたくかよ)とおもわれて、どん引きされる可能性もまた大です、

なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから

しかも、この答えには、もうひとつ問題があって、

男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、

もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、

そこにはもはや、男が貴女圏論モナド教育する余地がまったく残されていません、

したがって貴女のその答えは、

プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。

ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが

しかし、ああ見せて、プログラマープログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数名前一つにも気を使い、女と自分の将来に夢を持っています、

貴女の答え方ひとつで、プログラマー貴女への夢は大きくふくらみもすれば、

一瞬で、しぼんでしまいもするでしょう。


では、スキットを繰り返しましょう。

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、

貴女はこう重ねましょう、

それからね、いま、わたしが使ってみたいWebアーキテクチャは、

Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。

あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」

これでもう完璧です。

PlayFrameworkと、Play(遊ぶ・じゃれる)のダブルミーニングでかれの股間も刺激しちゃえます。

そうなったらこっちのもの

デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて(注3)、

github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね!ボタンがムネのところにあるTシャツ、 あるいは初音ミク(ないし彼のお気に入りアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど)のコスプレを着てゆきましょう。

その日からプログラミング大好き男は貴女の虜になるでしょう。

では、釣り師としての貴女の、愛の幸運幸福をお祈りします!

注1:

(と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった)

(あと、マジで機能とかTwitter連携とか診断メーカー的なのでもPHPで7つも作ってる女子居たら付き合いたい)

注2:

もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。

注3:

プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。

半数くらいのプログラマーしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ(ただしキャラ絵のは除く)とか、

過度でないていどにフリルがついたものオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう(だってそれはコンパイルエラーときの色だ)ので、薄ピンクホワイト、薄ブルー、せめて黒(に差し色でピンクとか)あたりに留めたい。

補記:

 元ネタhttp://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/

補記2:

  「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。

補記3:

 言うまでも無いけど、ネタです。 

 また、COBOLとVB、C++ではまったくもって難易度が違うことも分かっています。後者になるほど圧倒的に難しい。

2011-09-15

コンピュータ基礎理論ハンドブック2 形式的モデル意味論」の目次

第1章  有限オートマトン
	D.Perrin:橋口攻三郎
1. 序論
2. 有限オートマトン認識可能集合
3. 有理表現
4. Kleeneの定理
5. 星の高さ
6. 星自由集合
7. 特殊なオートマトン
8. 数の認識可能集合


第2章  文脈自由言語
	J.Berstel and L.Boasson:富田 悦次

1. 序論
2. 言語
	2.1 記法と例
	2.2 Hotz 群
	2.3 曖昧性と超越性
3. 反復
	3.1 反復補題
	3.2 交換補題
	3.3 退化
4. 非生成元の探求
	4.1 準備
	4.2 生成元
	4.3 非生成元と代入
	4.4 非生成元と決定性
	4.5 主錐の共通部分
5. 文脈自由群
	5.1 文脈自由群
	5.2 Cayleyグラフ
	5.3 終端


第3章  形式言語とべき級数
	A.Salomaa:河原 康雄

1. 序論
2. 準備
3. 書換え系と文法
4. Post正準系
5. Markov系
6. 並列書換え系
7. 射と言語
8. 有理べき級数
9. 代数的べき級数
10. べき級数の応用


第4章  無限の対象上のオートマトン
	W.Thomas:山崎 秀記

序論
Ⅰ部  無限語上のオートマトン
	記法
1. Buchiオートマトン
2. 合同関係と補集合演算
3. 列計算
4. 決定性とMcNaughtonの定理
5. 受理条件とBorelクラス
6. スター自由ω言語と時制論理
7. 文脈自由ω言語
Ⅱ部  無限木上のオートマトン
	記法
8. 木オートマトン
9. 空問題と正則木
10. 補集合演算ゲームの決定性
11. 木の単項理論と決定問題
12. Rabin認識可能な集合の分類
	12.1 制限された単項2階論理
	12.2 Rabin木オートマトンにおける制限
	12.3 不動点計算


第5章  グラフ書換え:代数的・論理アプローチ
	B.Courcelle:會澤 邦夫

1. 序論
2. 論理言語グラフの性質
	2.1 単純有向グラフの類S
	2.2 グラフの類D(A)
	2.3 グラフの性質
	2.4 1階のグラフの性質
	2.5 単項2階のグラフの性質
	2.6 2階のグラフの性質
	2.7 定理
3. グラフ演算グラフ表現
	3.1 源点付きグラフ
	3.2 源点付き超グラフ
	3.3 超グラフ上の演算
	3.4 超グラフの幅
	3.5 導来演算
	3.6 超辺置換
	3.7 圏における書換え規則
	3.8 超グラフ書換え規則
4. 超グラフの文脈自由集合
	4.1 超辺置換文法
	4.2 HR文法に伴う正規木文法
	4.3 超グラフの等式集合
	4.4 超グラフの文脈自由集合の性質
5. 超グラフの文脈自由集合の論理的性質
	5.1 述語の帰納的集合
	5.2 論理構造としての超グラフ
	5.3 有限超グラフの可認識集合
6. 禁止小グラフ定義される有限グラフの集合
	6.1 小グラフ包含
	6.2 木幅と木分解
	6.3 比較図
7. 計算量の問題
8. 無限グラフ
	8.1 無限グラフ表現
	8.2 無限グラフの単項性質
	8.3 超グラフにおける等式系
	8.4 関手の初期不動点
	8.5 超グラフにおける等式系の初期解
	8.6 等式的超グラフの単項性質


第6章  書換え系
	N.Dershowitz and J.-P.Jouannaud:稲垣 康善,直井 徹

1. 序論
2. 構文論
	2.1 項
	2.2 等式
	2.3 書換え規則
	2.4 決定手続き
	2.5 書換え系の拡張
3. 意味論
	3.1 代数
	3.2 始代数
	3.3 計算能代数
4. Church-Rosser性
	4.1 合流性
	4.2 調和性
5. 停止性
	5.1 簡約順序
	5.2 単純化順序
	5.3 経路順序
	5.4 書換え系の組合せ
6. 充足可能性
	6.1 構文論的単一化
	6.2 意味論的単一化
	6.3 ナローイング
7. 危険対
	7.1 項書換え
	7.2 直交書換え系
	7.3 類書換え
	7.4 順序付き書換え
	7.5 既約な書換え系
8. 完備化
	8.1 抽象完備化
	8.2 公平性
	8.3 完備化の拡張
	8.4 順序付き書換え
	8.5 機能定理証明
	8.6 1階述語論理定理証明
9. 書換え概念拡張
	9.1 順序ソート書換え
	9.2 条件付き書換え
	9.3 優先度付き書換え
	9.4 グラフ書換え


第7章  関数型プログラミングラムダ計算
	H.P.Barendregt:横内 寛文

1. 関数計算モデル
2. ラムダ計算
	2.1 変換
	2.2 計算可能関数表現
3. 意味論
	3.1 操作意味論:簡約と戦略
	3.2 表示的意味論ラムモデル
4. 言語拡張
	4.1 デルタ規則
	4.2 型
5. 組合せ子論理と実装手法
	5.1 組合せ子論理
	5.2 実装の問題


第8章  プログラミング言語における型理論
	J.C.Mitchell:林 晋

1. 序論
	1.1 概論
	1.2 純粋および応用ラムダ計算
2. 関数の型をもつ型付きラムダ計算
	2.1 型
	2.2 項
	2.3 証明系
	2.4 意味論健全性
	2.5 再帰関数論的モデル
	2.6 領域理論モデル
	2.7 カルテシアン閉圏
	2.8 Kripkeラムモデル
3. 論理的関係
	3.1 はじめに
	3.2 作用構造上の論理的関係
	3.3 論理的部分関数論理同値関係
	3.4 証明論的応用
	3.5 表現独立性
	3.6 論理的関係の変種
4. 多相型入門
	4.1 引数としての型
	4.2 可述的な多相的計算系
	4.3 非可述的な多相型
	4.4 データ抽象存在型
	4.5 型推論入門
	4.6 型変数をもつλ→の型推論
	4.7 多相的宣言の型推論
	4.8 他の型概念


第9章  帰納的な関数プログラム図式
	B.Courcelle:深澤 良彰

1. 序論
2. 準備としての例
3. 基本的な定義
	3.1 多ソート代数
	3.2 帰納的な関数プログラム図式
	3.3 同値な図式
4. 離散的解釈における操作意味論
	4.1 部分関数と平板な半順序
	4.2 離散的解釈
	4.3 書換えによる評価
	4.4 意味写像
	4.5 計算規則
5. 連続解釈における操作意味論
	5.1 連続代数としての解釈
	5.2 有限の極大要素と停止した計算
6. 解釈クラス
	6.1 汎用の解釈
	6.2 代表解釈
	6.3 解釈方程式クラス
	6.4 解釈代数クラス
7. 最小不動点意味論
	7.1 最小で唯一の解を得る不動点理論
	7.2 Scottの帰納原理
	7.3 Kleeneの列と打切り帰納法
8. プログラム図式の変換
	8.1 プログラム図式における同値性の推論
	8.2 畳込み,展開,書換え
	8.3 制限された畳込み展開
9. 研究歴史,他の形式のプログラム図式,文献ガイド
	9.1 流れ図
	9.2 固定された条件をもつ一様な帰納的関数プログラム図式
	9.3 多様な帰納的関数プログラム図式
	9.4 代数理論
	9.5 プログラムの生成と検証に対する応用


第10論理プログラミング
	K.R.Apt:筧 捷彦

1. 序論
	1.1 背景
	1.2 論文の構成
2. 構文と証明論
	2.1 1階言語
	2.2 論理プログラム
	2.3 代入
	2.4 単一化子
	2.5 計算過程―SLD溶融
	2.6 例
	2.7 SLD導出の特性
	2.8 反駁手続き―SLD木
3. 意味論
	3.1 1階論理意味論
	3.2 SLD溶融の安全性
	3.3 Herbrand模型
	3.4 直接帰結演算子
	3.5 演算子とその不動点
	3.6 最小Herbrand模型
	3.7 SLD溶融の完全性
	3.8 正解代入
	3.9 SLD溶融の強安全性
	3.10 手続き的解釈と宣言的解釈
4. 計算力
	4.1 計算力と定義力
	4.2 ULの枚挙可能性
	4.3 帰納的関数
	4.4 帰納的関数計算力
	4.5 TFの閉包順序数
5. 否定情報
	5.1 非単調推論
	5.2 閉世界仮説
	5.3 失敗即否定規則
	5.4 有限的失敗の特徴付け
	5.5 プログラムの完備化
	5.6 完備化の模型
	5.7 失敗即否定規則の安全性
	5.8 失敗即否定規則の完全性
	5.9 等号公理と恒等
	5.10 まとめ
6. 一般目標
	6.1 SLDNF-溶融
	6.2 SLDNF-導出の安全性
	6.3 はまり
	6.4 SLDNF-溶融の限定的な完全性
	6.5 許容性
7. 層状プログラム
	7.1 準備
	7.2 層別
	7.3 非単調演算子とその不動点
	7.4 層状プログラム意味論
	7.5 完全模型意味論
8. 関連事項
	8.1 一般プログラム
	8.2 他の方法
	8.3 演繹データベース
	8.4 PROLOG
	8.5 論理プログラミング関数プログラミング統合
	8.6 人工知能への応用


第11章  表示的意味論
	P.D.Mosses:山田 眞市

1. 序論
2. 構文論
	2.1 具象構文論
	2.2 抽象構文
	2.3 文脈依存構文
3. 意味論
	3.1 表示的意味論
	3.2 意味関数
	3.3 記法の慣例
4. 領域
	4.1 領域の構造
	4.2 領域の記法
	4.3 記法上の約束事
5. 意味記述法
	5.1 リテラル
	5.2 式
	5.3 定数宣言
	5.4 関数抽象
	5.5 変数宣言
	5.6 文
	5.7 手続抽象
	5.8 プログラム
	5.9 非決定性
	5.10 並行性
6. 文献ノート
	6.1 発展
	6.2 解説
	6.3 変形


第12意味領域
	C.A.Gunter and D.S.Scott:山田 眞市

1. 序論
2. 関数帰納定義
	2.1 cpoと不動点定理
	2.2 不動点定理の応用
	2.3 一様性
3. エフェクティブに表現した領域
	3.1 正規部分posetと射影
	3.2 エフェクティブに表現した領域
4. 作用素関数
	4.1 積
	4.2 Churchのラム記法
	4.3 破砕積
	4.4 和と引上げ
	4.5 同形と閉包性
5. べき領域
	5.1 直観的説明
	5.2 形式的定義
	5.3 普遍性と閉包性
6. 双有限領域
	6.1 Poltkin順序
	6.2 閉包性
7. 領域の帰納定義
	7.1 閉包を使う領域方程式の解法
	7.2 無型ラム記法モデル
	7.3 射影を使う領域方程式の解法
	7.4 双有限領域上の作用素表現


第13章  代数仕様
	M.Wirsing:稲垣 康善,坂部 俊樹

1. 序論
2. 抽象データ型
	2.1 シグニチャと項
	2.2 代数計算構造
	2.3 抽象データ型
	2.4 抽象データ型の計算可能性
3. 代数仕様
	3.1 論理式と理論
	3.2 代数仕様とその意味論
	3.3 他の意味論的理解
4. 単純仕様
	4.1 束と存在定理
	4.2 単純仕様表現能力
5. 隠蔽関数と構成子をもつ仕様
	5.1 構文と意味論
	5.2 束と存在定理
	5.3 隠蔽記号と構成子をもつ仕様表現能力
	5.4 階層仕様
6. 構造仕様
	6.1 構造仕様意味論
	6.2 隠蔽関数のない構造仕様
	6.3 構成演算
	6.4 拡張
	6.5 観測的抽象化
	6.6 構造仕様代数
7. パラメータ仕様
	7.1 型付きラムダ計算によるアプローチ
	7.2 プッシュアウトアプローチ
8. 実現
	8.1 詳細化による実現
	8.2 他の実現概念
	8.3 パラメータ化された構成子実現と抽象化子実現
	8.4 実行可能仕様
9. 仕様記述言語
	9.1 CLEAR
	9.2 OBJ2
	9.3 ASL
	9.4 Larch
	9.5 その他の仕様記述言語


第14章  プログラム論理
	D.Kozen and J.Tiuryn:西村 泰一,近藤 通朗

1. 序論
	1.1 状態,入出力関係,軌跡
	1.2 外的論理,内的論理
	1.3 歴史ノート
2. 命題動的論理
	2.1 基本的定義
	2.2 PDLに対する演繹体系
	2.3 基本的性質
	2.4 有限モデル特性
	2.5 演繹的完全性
	2.6 PDLの充足可能性問題の計算量
	2.7 PDLの変形種
3. 1階の動的論理
	3.1 構文論
	3.2 意味論
	3.3 計算量
	3.4 演繹体系
	3.5 表現力
	3.6 操作的vs.公理意味論
	3.7 他のプログラミング言語
4. 他のアプローチ
	4.1 超準動的論理
	4.2 アルゴリズム論理
	4.3 有効的定義論理
	4.4 時制論理


第15章  プログラム証明のための手法論理
	P.Cousot:細野 千春,富田 康治

1. 序論
	1.1 Hoareの萌芽的な論文の解説
	1.2 C.A.R.HoareによるHoare論理のその後の研究
	1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究
	1.4 Hoare論理概観
	1.5 要約
	1.6 この概観を読むためのヒント
2. 論理的,集合論的,順序論的記法
3. プログラミング言語の構文論と意味論
	3.1 構文論
	3.2 操作意味論
	3.3 関係的意味論
4. 命令の部分正当性
5. Floyd-Naurの部分正当性証明手法とその同値な変形
	5.1 Floyd-Naurの手法による部分正当性証明の例
	5.2 段階的なFloyd-Naurの部分正当性証明手法
	5.3 合成的なFloyd-Naurの部分正当性証明手法
	5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明同値性
	5.5 Floyd-Naurの部分正当性証明手法の変形
6. ライブネス証明手法
	6.1 実行トレース
	6.2 全正当性
	6.3 整礎関係,整列集合,順序数
	6.4 Floydの整礎集合法による停止性の証明
	6.5 ライブネス
	6.6 Floydの全正当性証明手法からライブネスへの一般化
	6.7 Burstallの全正当性証明手法とその一般化
7. Hoare論理
	7.1 意味論的な観点から見たHoare論理
	7.2 構文論的な観点から見たHoare論理
	7.3 Hoare論理意味論
	7.4 構文論と意味論の間の関係:Hoare論理健全性と完全性の問題
8. Hoare論理の補足
	8.1 データ構造
	8.2 手続き
	8.3 未定義
	8.4 別名と副作用
	8.5 ブロック構造局所変数
	8.6 goto文
	8.7 (副作用のある)関数と式
	8.8 コルーチン
	8.9 並行プログラム
	8.10正当性
	8.11 プログラム検証の例
	8.12 プログラムに対して1階論理拡張した他の論理


第16章  様相論理時間論理
	E.A.Emerson:志村 立矢

1. 序論
2. 時間論理の分類
	2.1 命題論理 対 1階述語論理
	2.2 大域的と合成的
	2.3 分岐的 対 線形
	2.4 時点と時区間
	2.5 離散 対 連続
	2.6 過去時制 対 未来時制
3. 線形時間論理技術的基礎
	3.1 タイムライン
	3.2 命題線形時間論理
	3.3 1階の線形時間論理
4. 分岐的時間論理技術的基礎
	4.1 樹状構造
	4.2 命題分岐的時間論理
	4.3 1階の分岐的時間論理
5. 並行計算:その基礎
	5.1 非決定性と公平性による並列性のモデル化
	5.2 並列計算抽象モデル
	5.3 並列計算の具体的なモデル
	5.4 並列計算の枠組みと時間論理の結び付き
6. 理論見地から時間論理
	6.1 表現可能性
	6.2 命題時間論理の決定手続き
	6.3 演繹体系
	6.4 モデル性の判定
	6.5 無限の対象の上のオートマトン
7. 時間論理プログラム検証への応用
	7.1 並行プログラム正当性に関する性質
	7.2 並行プログラム検証証明論的方法
	7.3 時間論理による仕様からの並行プログラム機械合成
	7.4 有限状態並行システム自動検証
8. 計算機科学における他の様相論理時間論理
	8.1 古典様相論理
	8.2 命題動的論理
	8.3 確率論理
	8.4 不動点論理
	8.5 知識


第17章  関係データベース理論の構成要素
	P.C.Kanellakis:鈴木 晋

1. 序論
	1.1 動機と歴史
	1.2 内容についての案内
2. 関係データモデル
	2.1 関係代数と関係従属性
	2.2 なぜ関係代数か
	2.3 なぜ関係従属性か
	2.4 超グラフデータベーススキーマの構文について
	2.5 論理データベース意味について
3. 従属性データベーススキーマ設計
	3.1 従属性の分類
	3.2 データベーススキーマ設計
4. 問合わせデータベース論理プログラム
	4.1 問合わせの分類
	4.2 データベース論理プログラム
	4.3 問合わせ言語と複合オブジェクトデータモデル
5. 議論:関係データベース理論のその他の話題
	5.1 不完全情報の問題
	5.2 データベース更新の問題
6. 結論


第18章  分散計算モデル手法
	L.Lamport and N.Lynch:山下 雅史

1. 分散計算とは何か
2. 分散システムモデル
	2.1 メッセージ伝達モデル
	2.2 それ以外のモデル
	2.3 基礎的概念
3. 分散アルゴリズムの理解
	3.1 挙動の集合としてのシステム
	3.2 安全性と活性
	3.3 システム記述
	3.4 主張に基づく理解
	3.5 アルゴリズムの導出
	3.6 仕様記述
4. 典型的な分散アルゴリズム
	4.1 共有変数アルゴリズム
	4.2 分散合意
	4.3 ネットワークアルゴリズム
	4.4 データベースにおける並行性制御


第19章  並行プロセス操作的および代数意味論
	R.Milner:稲垣 康善,結縁 祥治

1. 序論
2. 基本言語
	2.1 構文および記法
	2.2 操作意味論
	2.3 導出木と遷移グラフ
	2.4 ソート
	2.5 フローグラフ
	2.6 拡張言語
	2.7 その他の動作式の構成
3. プロセスの強合同関係
	3.1 議論
	3.2 強双模倣関係
	3.3 等式による強合同関係の性質
	3.4 強合同関係における置換え可能性
	3.5 強等価関係上での不動点の唯一性
4. プロセスの観測合同関係
	4.1 観測等価性
	4.2 双模倣関係
	4.3 観測合同関係
	4.4 プロセス等価性上での不動点の唯一性
	4.5 等式規則の完全性
	4.6 プロセス等価性に対するその他の概念
5. 双模倣等価関係の解析
	5.1 等価性の階層構造
	5.2 階層構造論理的特性化
6. 合流性をもつプロセス
	6.1 決定性
	6.2 合流性
	6.3 合流性を保存する構成子
7. 関連する重要な文献

2011-07-16

[] Symbolについて

RubyのSymbolと文字列の違いを研究室輪講用に書いたのですが,折角なので公開したいと思います

元々学部生に対する輪講用に書いた物なので,若干上から目線ですがご了承ください.

Symbolの意義は何か

文字列とSymbolはよく似ていますプログラマから見ればどちらも文字列です.違いを一言で説明すると『プログラムが扱う』文字列か,『プログラマが見る』文字列かの違いです.例えば変数名は『文字列ですが,rubyオブジェクトである文字列』ではないですよね?

例えば,今あなたC言語お絵描きライブラリを作っているとしましょう.その中に,色で塗りつぶすfillという関数があり,色を青・赤・緑の3色から選べ,fillの引数でそれを指定できるとしましょう.

fillの引数の設定方法として一番単純なのが,0を青,1を赤,2を緑として,0〜2で選択させる方法でしょう.しかし,それでは,どの数値が何色か覚えないといけないし,fill関数を知らない人から見れば,どういう意味引数かすらさっぱり分かりません.

ではどうするかと言えば,普通BLUE = 0, RED = 1, GREEN = 2と適当に定数を設定して,その定数を引数で指定させますよね.

こうして,fill関数引数意味の無い数値から意味のある文字列に変わったことによってプログラムが分かりやすい物となります.さて,ここで注意してほしいのは,ここで言う文字列プログラムが扱うオブジェクトとしての文字列では無いということです.fill関数引数として,"BLUE","RED", "GREEN"などとC言語文字列を渡すということは普通しませんよね.それは,ここで言う文字列は,あくまでプログラマプログラムコードを分かりやすくするために必要な文字列であって,プログラムオブジェクトとして扱う(例えば,長さを求めるとかする)文字列ではないかです

分かってきたでしょうか?

プログラムコード上では(つまりプログラマから見れば)どちらも同じ文字列(文字の列という意味で)ですが,実際に動くプログラムから見れば単なる数値と本物の文字列という大きな違いです.結局,fill関数引数の具体的な値は何でもいいわけですプログラマから見て文字列であればそれだけでよく,プログラムが動くときの実際のその中身は何でもいいわけです.これのために存在するのが,Symbolであり,:fooとひとたびSymbolを作成すれば:fooの実態は適当な数値となります.(この数値がいくらかなんていうことはもちろん気にする必要はありません)

そして,もちろん同じプログラム上では:foo == :fooはちゃんと成り立ちます.もうここまでくれば,Hashのkeyとして文字列でなくSymbolを使う理由が分かりますね.Hashのkeyはあくまで,プログラマが見る(プログラムコードを分かりやすくするための)文字列であってプログラムが扱うオブジェクトとしての文字列では無くて,keyの実際の値は何でもいい,からですね.(特別な場合を除いて)Hashのkeyに対してrubyStringメソッドを使うなんてことは無いですよね.

なぜrubyにはSymbolが存在するのか

しかし,他の軽量言語ではSymbolなどなくHashのkeyとして普通に文字列を使うことが多いです.では,なぜrubyだけSymbolを使うのでしょうか.

その答えは一言でいうと,rubyの(プログラムコード上に直接書かれた,つまりリテラルの)文字列は他の言語と違いimmutable(不変)でない,からです.実際,pythonjavascript文字列(リテラル)は破壊的に変更することはできませんが,ruby文字列破壊的に変更することができます. ('abc'.concat('d')の様に)

これがどういう違いを生むかというと,コード上に直接現れる文字列がimmutable(不変)であるならば,実行時に一つだけそのオブジェクト作成し,後はそれを使いまわすという最適化ができます

そうした時,Hashのkeyの様なプログラマから見た文字列というのは,プログラムコード上のリテラルとして現れるわけですが,これらは実行時に一つだけオブジェクト作成され(特にコード上に現れる同じ文字列は全て一つのオブジェクトにまとめると),それらの比較はそれらに対する参照(そしてこれは大抵メモリアドレスなど単なる数値)の比較で済むので,結局Symbolと同じ様な働きをするわけです

本当はプログラマが見るためだけの文字列だけど,それをオブジェクトとしての文字列としても,Symbolと同じ様な働き,パフォーマンスが得られるならば,別にオブジェクトとしての文字列であってもいいわけです

繰り返しになりますが,プログラマが見るためだけの文字列は,その中身・実態は何でもいいわけですが,その実態がオブジェクトとしての文字列でも十分なパフォーマンスが得られるならば,別にオブジェクトとしての文字列でもいいわけです

さて,rubyに話を戻しますと,rubyコード上に現れる文字列であっても,実行時にそのコードを通る度に毎回新たな文字列オブジェクト作成します.

(以下のプログラムを動かすことで確認できる.)

def foo
  'foo'.object_id
end
p foo, foo

まりrubyでは文字列が可変であるため,先に述べたような最適化ができない(または難しい)ので毎回新たな文字列オブジェクト作成されるのです

こうなると,先ほどの話とはうってかわって,プログラマが見る文字列はその実態は何でもいいのに,それを文字列リテラルrubyオブジェクトとしての文字列)にしてしまうと,毎回毎回文字列オブジェクト作成されてしまうという非常にばかばかしい状況になってしまます.我々はそれらの文字列オブジェクト文字列としての操作は一切施さないのにも関わらず,です

こういうわけで,rubyではプログラマが見るためだけの文字列にSymbolというruby特有のものを使うのです

もちろん,プログラマが見るためだけの文字列を全て定数として(そしてもちろん中身は適当な値で)定義しても構わないわけですが,Hashのkeyとかで数多くのプログラマが見るためだけの文字列が現れることを考えると,とてもじゃないですけどそんなことは面倒でやってられないですよね.ですので,実行時に自動適当な値にしてくれるSymbolというもの存在するのです

以上で,Symbolについての説明を終えます.以下は蛇足です

おまけ

最初の方で出てきたfill関数rubyで実装しようとしたとき,青・赤・緑の各色はその実際の値はなんでもいいのでrubyのSymbolを使って:blue, :red, :greenとしてもいいのですが,ライブラリとかでは大抵ちゃんと定数として定義されていることが多いです

これは恐らく,定数として明示的に定義することで値の存在を明示でき,ドキュメント化の際にも役立つことによっているのでしょう.

Symbolだと,良くも悪くも定義がいりませんから

しかし,あくまでこれは外部に公開するようなライブラリでの話であって,自分が使うちょっとしたプログラムならこういう場面でも精力的にSymbolを使っていってもいいと思います.ちなみに,僕ならSymbolを使います

Symbolだと定義もいりませんし,定数は大文字ですからつのが面倒ですし,あまりソース大文字が入ると見た目がすっきりしません(主観).

Symbolは非常に便利なものですので,その意義・用途を十分に理解して,Hashのkeyにとどまらず様々な所で使えるようになりましょう.

2010-08-08

概念上の「処女」と、実在の処女は区別しなければならない。

処女とは言っても、いろいろいるのではないか、と思う。

増田なので信じてもらえるかどうかわからないが書いてみる。

////////////////////////////////////////////

俺の友人の、ある女の子は、20代も半ばで、今まで10人以上と付き合ったことがあるらしいのだが、いまだに処女だそうだ。

理由は、セックスに拒否反応があるから、というか単に「こわい」ということらしい。

「どこらへんがこわいの?」と聞いてみたら、「だっていたい。血が出るし」などと言う。

本人が言う理由をリテラルに受け取ってしまってもいいのか悩むが、いまのところそのまま受け取るしかない。

なので彼女処女だ。(おそらく。確認のしようがない)

で、彼女は、いわゆる「処女」のイメージどおりなのかといったら、そうでもない。

たしかに黒髪のストレートだが、おとなしいというわけでもなく、かなりの社交好きだ。

おしゃべりも大好きだし、ふつうクラブにも行くそうだ。(俺は行かないので驚いた)

だからオクテというわけでもなく、自分から告白に行くようだ。

いままで付き合ったのは、ほとんど自分からの告白がきっかけだったらしい。

なので、処女とはいっても、そのような女の子なのだ。

しかしやっぱり、セックスを拒否することは、なかなか相手の男には受け入れてもらえない、と言う。

いままでそれが原因で別れたことは、少なくないそうだ。

だから、付き合った人数が増えた、という側面もあるようだ。

たとえば、相手がシャワーを浴びているあいだにホテルから逃げる、などをして、相手がキレるということがよくあったそうだ。

また、相手の男から、強引に迫られることもあったらしい。

たとえば、ある元カレなんかは、別れたあとに彼女を呼び出して、「おまえ、させないんだったら、口でやってよ」と、ほとんど脅すようなかんじで迫ったそうだ。彼女は、「こわかったから、くわえた」と言っていた。

「あたし処女だけど、フェラチオは体験済み!」などと、笑い話っぽく話してくれたよ。

////////////////////////////////////////////

まあ、そういうわけで、俺も世の中にどのような処女がいるかはわからないけど、こんな女の子もいるということで、なにかの参考になればと思い、書いてみました。

http://anond.hatelabo.jp/20100808042134

2008-10-31

広島の空で原爆アートやった集団の関係者はてダ愚痴ってた(笑

広島の空で原爆アートやって各所から突き上げ食らって結局信念貫き通す覚悟もなく最後には泣いて詫びたアート(笑)集団「Chim↑Pom」の関係者と思しき人のはてダにこんなのがあった

2008-10-27 リテラルネスと嗤い

例えば、レノン&ヨーコの" WAR IS OVER! (if you want it) "。反語的な表現というものが効力を持ち得ない、リテラシーが欠如してしまっているのが今この場所、ということなのか。だとしたら、戦争温暖化核兵器もなくならない。しかも、それでいて、「嘲笑(=ネタ)」ばかりが渦巻いている。下品だ。不快だ。吐き気がする。

http://d.hatena.ne.jp/sakurah/

ふーん

2008-09-23

正規表現の機能の覚書き

はじめに

「はじめての正規表現」ホッテントリ入りしていますが、

導入としては、何に使うのかがわかりやすくて良いのではないかと思います。

あれを見て、基本機能をまとめてみたくなったので、正規表現の基本的な機能について書いてみます。

正規表現が初めてという人は「はじめての正規表現」を先に見たほうがいいと思います。)

例では「検索」か「置換」をするものとして話を進めていきます。

「はじめての正規表現」が実例を中心にしたのに対して、こちらは機能を中心に書きます)

正規表現は、プログラミング言語やその他のツールなど、それぞれで微妙な違い(方言)があるので、その点には注意が必要です。

(表記法が違ったり、ここに紹介する機能がサポートされていなかったり、逆に紹介していない機能をサポートしていたりする場合があります)

メタ文字とリテラル文字

正規表現には、メタ文字とリテラル文字というものがあります。

メタ文字とは機能を持つ文字で、『.』『*』『*?』といったものが当てはまります。

リテラル文字は「文字それ自体」と解釈される文字で、『 』『a』『<』といったものです。

アルファベットや数字はリテラル文字なので、

「検索する文字列:『egg』 置換する文字列:『chicken』」

などとすれば、正規表現を使わない置換と同じ効果になります。

なお、検索して検索文字列が当てはまることを「マッチする」と言います。

メタ文字に使われている文字を検索したい場合は、直前に『\』を置きます。(これを「エスケープ」と呼びます。)

.*?^$()[]{}』などがメタ文字です。

$100』を検索したければ、『\$100』とすればいいということになります。

(『\』は環境によって、半角の『¥』『\』のどちらかになります。)

言語、ツール、モードなどによっては『@/#』もエスケープが必要です。

また、『\』自体は常にエスケープが必要です。

繰り返しについて

メタ文字意味
?直前の文字を0回または1回繰り返す
*直前の文字を0回以上繰り返す
+直前の文字を1回以上繰り返す
{n}直前の文字をn回繰り返す
{n,}直前の文字をn回以上繰り返す
{n,m}直前の文字をn〜m回繰り返す

これらのメタ文字は「量指定子」といって、直前の文字の繰り返しを意味します。

*』は「任意の文字を0回以上繰り返す」とありますが、

「0回以上繰り返す」とは、「全く何もなくてもいいし、いくらあってもいい」という意味です。

よって、『?』は「あってもなくてもいい」、『+』は「1つ以上あればいい」と解釈できます。

colou?r』は『u』があってもなくてもいいので「colorかcolour」ということになります。

{n}』は、たとえば『-{15}』なら、「ハイフン(-)が15個続くもの」となります。

-{10,}』なら「ハイフン(-)が少なくともは10個続くもの(多いのはいくらでも)」、

-{10,15}』なら「ハイフン(-)が10〜15個続くもの」となります。

また、複数の文字を繰り返したい場合は括弧で囲みます。

(Gang){2}Dance』は『GangGangDance』と同じ意味になります。

欲張りと非欲張り

メタ文字意味
?直前の文字を0回または1回繰り返す(欲張り)
*直前の文字を0回以上繰り返す(欲張り)
+直前の文字を1回以上繰り返す(欲張り)
??直前の文字を0回または1回繰り返す(非欲張り)
*?直前の文字を0回以上繰り返す(非欲張り)
+?直前の文字を1回以上繰り返す(非欲張り)

「欲張り」とは、「なるべく多くの文字に適用しようとする」、

「非欲張り」とは、「なるべく少ない文字に適用しようとする」という意味です。

対象文字列が『aaa bbb ccc』だとします。

すると、検索する文字列が『a+』なら『aaa bbb ccc』、

検索する文字列が『a+?』なら『aaa bbb ccc』が置換対象となります。

(「すべてを検索/置換」する場合は当てはまりません)

「『a』を1回以上繰り返す」ということは、『a』でも『aa』でも『aaa』でもマッチすることになりますが、

「欲張り」かそうでないかで実際のマッチは変わってくるわけです。

文字クラス

文字クラス意味
[abc]a、b、cのいずれか
[a-z]a〜zのいずれか
[^a]a以外の文字(改行文字を含めaを除いた全て)
[^a-z]a〜z以外の文字(改行文字を含めa〜zを除いた全て)

文字クラスは『a』や『<』などの代わりに文字の種類を指定するものです。

a〜eのどれかの1文字という指定をしたい場合に『[abcde]』や『[a-e]』といった指定ができます。

また、文字クラス内の最初に『^』をつけて『[^abc]』などとすれば、

「a、b、c以外の何の文字でもいい」とすることができます。

間違いやすいのが「そこにaもbもcも存在しなければいい」という意味ではないということです。

文字クラスは「なんらかの1文字の身代わり」なので、それは何か1文字を表しています。

-』は範囲を表すのに使用します。そのため、『[;-%]』で「; - %のどれか」を表現することはできません。

-』を含める場合は必ず最初に持ってきます。すると『[-;%]』という風になります。

「; - %以外の文字」としたいならば『[^-;%]』とします。

[』や『]』、『\』を文字クラスに含めたい場合は直前に『\』を置いてエスケープします。

「『[』または『]』」であれば『[\[\]]』となります。

^』やその他の記号は先頭に置かなければいいので、エスケープの必要はありません。

.』は「改行以外のすべての文字」を表しています。

改行は『\n』で表されるため、『.』は『[^\n]』と等価です。

(ただし、正規表現モードによっては「改行も含めすべての文字」を表す場合もあります)

文字クラスにはいくつかの略記法があります。

文字クラス意味同等の表記
\w記号や空白ではない文字すべて[a-zA-Z0-9_]
\W記号や空白ではない文字以外[^a-zA-Z0-9_]
\d数字[0-9]
\D数字以外[^0-9]
\sタブや改行など、空白類とされる文字[ \t\n\r\f\v]
\Sタブや改行など、空白類とされる文字以外[^ \t\n\r\f\v]

(*間違って『\s』の同等の表記にも『^』がついていたのを修正しました)

(『\t』はタブ、『\v』は垂直タブ、『\r』はキャリッジリターン(CR、改行の一種)、『\f』は改ページ)

これらは『[a-fA-F\d]』のようにすることで、文字クラスブラケット角括弧)内に含めることができます。

「同等の表記」と書きましたが、文字をユニコードして扱うツールの場合は、上記が同等の表記にはならず、

たとえば『\d』であれば漢数字が含まれてしまったりするので注意が必要です。

選択

(A|B)』は「AまたはB」という意味です。(これを「選択」と呼びます)

(A|B|C)』なら「A、B、Cのどれか」という意味になります。

(gray|grey)』は『gr[ae]y』とほぼ等価となります。

[ae]』は「1文字のaまたはb」という意味になるので結果的に、ほぼ同じ効果が得られるわけです。

(ただし、これはgrayとgreyの違いが1文字だけだったためで、そうでない場合はこうはなりません)

気をつけなければならないのは、その順番です。

(Java|JavaScript)』で検索すると、対象文字列内に存在する『Java』と『JavaScript』すべてマッチするように思えますが、

JavaScript』は選択肢の前(左)のほうにある『Java』が当てはまってしまうため、

Script』部分にはマッチせず、『JavaScript』というマッチになってしまいます。

選択では左側が優先されるので、『(JavaScript|Java)』とすることでこの問題は防げます。

言語、ツールによっては、この問題が起こらない=順番関係なく長いほうを適用しようとするものもあります)

アンカー

メタ文字意味
^行頭
$行末
\b単語境界
\B単語境界以外

リテラル文字や文字クラスが「文字自体」にマッチするのと違い、アンカーは「位置」にマッチします。

検索する文字列が『^』、置換する文字列が『>』なら、「行頭に『>』を挿入する」という意味になります。

単語境界とは、「単語を構成する文字=『\w』に相当する文字」と「単語を構成しない文字=『\W』に相当する文字」の間の位置のことです。

regular expression.』なら『^regular^ ^expression^.』の4ヶ所に当てはまります。

\b.*?\b』とすれば単語すべてにマッチさせることができます。

しかし、「単語構成文字」が基準なので、『JavaScript』は1単語でも、『L?K?O』は1単語とは見なされません。

アンカーは位置にマッチするので、文字クラス内に含めることはできません。

^』や『$』を文字クラスに含めても、その文字自体という意味になります。

つまり、『[^$]』なら「行頭または行末」ではなくて、「『$』文字以外」ということになります。

また、『\b』は文字クラス内のみ、バックスペース文字を表す場合が多いようです。

大文字と小文字

正規表現には、大抵「大文字と小文字を無視する」というオプションがあります。

これが入っていないと「『to:』で検索しても『To:』にマッチしない」といったことが起こります。

言語、ツールによっては、正規表現の一部にのみ大文字と小文字を無視する機能があるものもあります。

例えばRubyでは『(?i:foo)』という形式を使用できます。

(?i:Ruby) Python』という表現なら、『ruby Python』や『RuBy Python』にはマッチしますが、

RUBY PYTHON』にはマッチしない、ということになります。


キャプチャと後方参照

括弧内に入れた文字列は、ある場所に記憶されます。(「キャプチャ」と呼びます)

これは『\n』という表記を使って呼び出すことができます。(nは数字)

同じ単語が2連続で出てくるもの(『merry merry』みたいなもの)を探すという場合、

\b(\w+)\b \1』とすることができます。(ここで使った『\1』を「後方参照」と呼びます)

こうすると、『\1』の部分は、『(\w+)』を使ってマッチしたものと同じものがあるものとして解釈されることになります。

括弧を何個も使う場合は、左の括弧から順に『\1』、『\2』、『\3』となります。

また、後方参照は置換文字列にも使うことができます。

つまり置換文字列内に『\1』と書けば1番目の括弧、

\2』と書けば2番目の括弧でキャプチャされたものがそこに入ることになります。

この場合、言語、ツールによっては『\n』ではなく『$n』を使う場合もあるようです。

括弧は『(foo|bar)』という選択や、『(humbert){2}』というグループ化など、キャプチャ以外にも使われます。

そのため、キャプチャに使われた数字をわかりやすくするために、キャプチャしない括弧もあります。

それには『(?:foo)』という表記を使います。

前の例であれば『(?:foo|bar)』と『(?:humbert){2}』になります。

先読みと否定先読み

「その位置の続くものを確認する」というのが「先読み」です。

対象文字列を『JavaScript Java Applet』として考えてみましょう。

Java(?=Script)』は「『Script』が後に続く『Java』」にマッチします。

(?=Script)』の部分が、「『Script』が後に続くかどうか」をチェックしているので、

後ろに『Script』が続かない単なる『Java』にはマッチしません。

(?=Script)』の部分は「後に『Script』が続く位置」にマッチしていることになります。

この例のマッチは『JavaScript Java Applet』となります。

逆に、『Java(?!Script)』とすれば、「『Script』が後に続かないかどうか」をチェックするので、

後ろに『Script』が続かない単なる『Java』にマッチさせることができます。

こちらは「否定先読み」と呼びます。

この例のマッチは『JavaScript Java Applet』となります。

言語、ツールによっては、「その位置の前にあるものを確認する」という「戻り読み」「否定戻り読み」がサポートされているものもあります。

(これは『(?<=foo)』『(?<!=bar)』という形で使います)

先読みや否定先読み、戻り読みなどをまとめて「前後読み」と呼びますが、

前後読みは位置にマッチするため、戻り読みは先読みとは通常書くべき位置が逆になります。

(?<Mozilla )Firefox』とすれば、『Mozilla 』に続く『Firefox』のみにマッチします。

強欲な量指定子とアトミックなグループ

メタ文字意味
?+直前の文字を0回または1回繰り返す(強欲)
*+直前の文字を0回以上繰り返す(強欲)
++直前の文字を1回以上繰り返す(強欲)

上のほうで?、*、+は「欲張り」だと書きましたが、「欲張り」な量指定子も“ゆずる”ことがあります。

対象文字列が『"something"』だとして、検索文字列".*"』はこれにマッチします。

しかし、強欲な量指定子*+』に置き換えて『".*+"』とするとマッチしません。

これはなぜかというと、「欲張り」な量指定子を使った『.*』の部分は、

最後の『"がなければ『something"』にマッチすることになりますが、

正規表現の最後に『"』があるために、対象文字列の最後の『"』をゆずっているのです。

しかし、強欲な量指定子*+』はゆずることがないため、

.*+』の部分が『something"』にマッチしてしまい、

正規表現の最後の『"』にはマッチできなくなるのです。

強欲な量指定子サポートしていない言語、ツールでも、「アトミックなグループ」というものが使える場合があります。

アトミックなグループでは『(?>foo)』という表記を使います。

\w?+』なら『(?>w+)』、『\w*+』なら『(?>w*)』、『\w++』なら『(?>w+)』で代替できます。

意図しないマッチに気をつける

*』の「直前の文字の0回以上の繰り返し」はよく気をつけないと、間違ったものにまでマッチしてしまいます。

リテラル文字と文字クラスは「文字自体」にマッチすると書きましたが、

-*』というような表現は、『-』や『--------』だけでなく、

『』つまり、空文字列にもマッチしてしまうのです。

なぜそうなるかというと、「0回以上」ということは「なくてもいい」ということだからです。

文字列へのマッチは、実質上「位置」へのマッチと似たようなものになります。

検索文字列を『-*』として一括置換すると、

-』や『--------』が置換されるだけでなく、

-』が存在しないすべての場所に置換文字列が挿入されてしまうことになります。

正しい正規表現を書くためには、「どう書けばマッチするか」だけでなく、

「どういう場合にマッチしなければいいか」についても考えてみる必要があります。

ワイルドカードの『*』≒正規表現の『.*

「はじめての正規表現」で、

ワイルドカードの『*』=正規表現の『.*

とありますが、これは厳密には微妙に違います。

ファイルグロブでは《*》は「任意の文字を1回以上繰り返す」

つまり、1文字以上あればなんでもいいということになります。

この意味だと、《*.*》は "foo." や ".bar" は当てはまりません。

しかし、「0回以上」であればマッチすることになります。

正規表現では「1回以上繰り返す」は、《+》なので、

「任意の文字を1回以上繰り返す」は『.+』となります。

よって、《*.*》とほぼ等価な表現は『.+\..+』となります。

これは私の勘違いでした。miauさんご指摘ありがとうございます。

「*.*」は foo. にマッチするはずだし、.barマッチしないのは、「*」がドットファイルマッチしないっていう特殊ルールがあるから・・・ですよね?

ワイルドカード(ファイルグロブ)の「*」って - miau's blog


ファイルグロブの《*》は、「0回以上繰り返す(ただし例外として、一番最初のドットは表せない)」ということのようです。

*.*》とほぼ等価な表現は、正しくは『(?!\.).*\..*』となります。


最後に

正規表現を使うにあたっては、検索対象がどのようなものか知っておくことが重要です。

\d{4}[-/]\d{1,2}[-/]\d{1,2}』で日付と思われる文字列を検索することができますが、

これは『00-0000-00-00』というものにもマッチしてしまいます。(『00-0000-00-00』)

かしこれを厳密にしようと思えばかなり複雑な正規表現になってしまうので、

どの程度の厳密さが必要かを把握しておくことが肝要と言えるでしょう。

冒頭にも書きましたが、正規表現は、言語やツールによって微妙な違いがあるので、

その辺りについては各言語、ツールの説明を参照してください。

本格的に学びたい場合はオライリー「詳説 正規表現」おすすめです。

(ただ、この本はプログラミングのことを多少は知らないと難しいかもしれません)

また、PHP正規表現チェッカーですぐに試せるようです。

関連リンク



反応への応答

b:id:K-Onoさんの

なぜ増田? これでidデビューしてもいいんじゃないのか?

について。

実ははてなダイアリーもある(d:id:sleepwlk)んですが、長いこと書いてなかったので、

匿名ダイアリーのほうが多くの人に見てもらえるのではないかと思ってこちらに書いてみました。

*2008-09-23 誤記の修正と、一部加筆しました。

*2008-09-24 ワイルドカード記述を修正しました。

*2008-09-24 文字クラス記述の間違いを修正しました。b:id:FunnyBunnyDizzyさんご指摘ありがとうございます。

*2008-09-24 「意図しないマッチに気をつける」を追加しました。

2007-04-28

http://anond.hatelabo.jp/20070428010214

オタクは自分の本能に従っている。

博学というのは理性に従っている。

オタク/博学」「本能/理性」の二分法がテキトーすぎる。だから、

社会性というのは他人とのコネクションのことを指すので、

必然的にオタク社会性が無くなっていく。

ただし、オタク社会の中だけで通用する社会性というのもある。

そして、そこには理性的な努力が必要だったりする。

例えば、コミュニティーサイトの運営などは、苦痛がともなうはず。

の部分で論旨が混乱してる。理性的な努力が必要な領域に関わっているオタクがいるのであれば、「理性に従ったオタク」と「博学」の差はどうなるの? 今書かれている文章だけだと、リテラルには破綻しているようにしか読めない。さらにいえば、そもそも「社会性」と「オタク社会の中だけで通用する社会性」を分けるためには、「社会」と「オタク社会」の差を明確に指摘できないとダメなんだけど、そこはどう考えてるの? 分析的な文章が書きたいのであれば、イメージに頼らないようにすべきだと思う。たとえ匿名で緩く書き込める場であっても。

以前「オタクルサンチマンで説明できる」とかなんとか言って、ボコボコにされながら粘着していた天然クンを思わせる……。

ついで。

http://anond.hatelabo.jp/20070428012327

(東浩紀しかそんなこと言っていない)

東浩紀も言ってない(笑)

http://anond.hatelabo.jp/20070428015502

(このレスをしてるのが元エントリ増田かどうか確証はないが)なんだ、無知かと思って反応してみたらただの馬鹿なのか。がっかり。

世の中、大と小だけじゃないけど、

大と小で表現するわけだ。

なんで? 大と小で表現する必然性ないじゃん。

それどころか、分析対象に中間領域があるってわかっているなら最低でも大・中・小に分けて分析して表現するべきじゃないのかね。

複雑さの度合いが「現実>分析」なんてのは当たり前の話。その中でどこまで分析の精度上げていけるかが大事。その努力を怠る奴が、知った風なことをほざく権利はないね。たとえ増田でも。

しっかし釣りにしてもツマランなぁ。以前の天然クンはなかなかにアジがあったのに。

http://anond.hatelabo.jp/20070428012327 の追記3

理性ってなんなんですかね。人間の本能の一部じゃないのかな。

生物学的な意味での「人間」に、何の教育も与えずに孤独放置しておいても「理性的」な振る舞いができるようになるんだったら「人間の本能の一部」だろね。一時期、認知科学方面でそういう発想に基いた研究流行ったけど、今どうなってんだろうなぁ。まあ、きっちりと証明されていない以上、フツーに「(人間の)理性とは後天的に身につけることができる論理思考能力のことで、対比物は『悟性』」とか考えたら良いんじゃないのかなあ。俺も哲学シロート同然なのでなんともいえんとこだけど。

2007-04-02

特定しますた

恋人ふつけるプレゼントする Schemer の俺が来ましたよ。

# 鬼の首をとったかのように書いてごめんよ。

Lisp とカッコの不揃い

CommonLisp はよく知らないんだけれど、 Scheme だと #\( と書けば ( という文字を示すことになるし、マルチバイト処理系だと ((((((( というようなシンボルも問題なく使えたりする(開きカッコが全角であることに注意)。

処理系によっては半角のカッコでさえシンボルに使える、かもしれない。実際、ある処理系では SRFI-17 に関係したコードに半角空白を含むシンボルがあったりする。

そういうわけで

(define ((((( xs)
 (if (null? xs)
  '()
  (cons (map (lambda (c) (if (eqv? #\( c) #t #f))
         '(#\( #\( #\( #\( #\( |setter of hogehoge|)))
        ((((( (cdr xs)))))

というようにカッコが不揃い(に見える)コードも可能。まあ、デモ以外でマルチバイト文字をシンボルに使うことなんてないだろうし、文字リテラルたまに目視でカッコをチェックしていて「あれ?」と思うぐらいだし、そもそも上のコード意味のある処理をしていないんだけど。

そういえば Emacs は閉じカッコを打った時、対応する開きカッコを強調表示してくれますよ。

結論

Lisp なんてやってないで HSP とかやるといいよマジで。 Lisper になるには最初に HSP を学ぶのが最も近道なんじゃないかと最近気付いたんだ。

増田に思うこと

super pre 記法ないのかよ! Web2.0 っぽいインターフェースブクマコメント表示したりする暇があるならこういう基本的なところやれよなマジで(いや、コメント表示も便利だけど)。そもそも増田システムなんてほとんどはてブと共通かと思ってたよ。増田が出た当初、「適当に組替えただけで、うまいことやったなぁ」と感心していただけに残念だ。

2007-02-28

【コラム】そろそろきっちりJavaScript 第1回 "Firebug"の導入〜関数リテラルとは? (MYCOMジャーナル)

多彩な演出効果カンタンに導入できる事で脚光を浴びたprototype.jsの登場を皮切りに

のっけから間違ってて読む気なくす。冒頭くらいちゃんと調べて書こうよ。prototype.jsのどこを読めば多彩な演出効果なんて出てくるんだ。使ったことないだろ。多彩な演出効果はたぶんprototype.jsベースScript.aculo.usのことだ。prototype.js流行ったのはいろいろあるけど、主としてAjax.*の存在が大きい。

function mtof(x) { return x*3.2808399 }

mtof(3)

;書こうよ。そりゃなくても動くけど、初学者向けの解説としてはダメだろう。タイトルも「きっちり」なんだし、Rubyで;ないのとは意味が違う。思わぬところでハマったりするよたぶん試したことないけど。

ちなみに仕様的には、「セミコロンを補完可能なら補完する」なので、補完不可なら補完できずエラー、そもそも補完ってことはセミコロンついてるのが正規の状態って意味だろう。何にしろ;なしで改行してるの見ると気持ち悪い。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん