yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2018/09 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
これも監視社会か
2006/05/09(Tue)21:52:12
 裁判員制度に向けて、検事の取り調べを録画することになったそうで。裁判では自白が争われる例もあるため、「脅迫的な取り調べ」が存在したかどうかを調べるには適当な方法でしょう。下手すると無罪の人がとんでもない罪になったりしますから。
 ただ、これにも問題点が2つ。まず罪状が殺人など重罪に限られる点です。チカン訴訟などで自白の真偽が争われる例もあり、これではいけません。また、例えば殺人などでも、その被疑者が住居不法侵入や窃盗などを行っていれば、それで引っ張ってきてムチャな取り調べで殺人を吐かせれば、それが事実かどうかにかかわらず、録画は残りそうにありません。
 そして2つ目ですが、何といってもこの録画は警察には適用されないそうです。実際には警察の取り調べが主である日本では、ここでどれほどの拷問があっても明るみに出ないわけです。どうやらよほどやましいことがあるらしく、警察は取り調べの録画に強硬に反対しています。公認会計士も不正をする時代、警察も信用なりません。
 警察は「こういう取り調べも必要だ」と考えているのでしょうが、それについて1つ。例えば被疑者が本当に犯人だとして、厳しい取り調べによってようやく罪を認めさせたとします。それでようやく起訴されましたが、そこで突然「私は自白を強要された」と言い出しました。自白した情報は報道や想像を基にしたもの、と主張し始めるわけです。
 自白で確定的なことを話しているならともかく、そうでない情報について「報道で知った」「想像だ」と言われたり、果ては確定情報についても「取り調べ中にその事実を提示され、認めるよう強制された」と言われればオシマイです。しかも、拷問で自白を求められる場面については非常に生々しく語ることになります。これについてはありのままを話せば良いのですから。
 結果、自白の強要が認められ、証拠不十分でこの犯人はクロなのにシロとされました。最近は自白を過大評価しない流れが定着しつつありますが、時としてこういう結末を招くこともあるのです。これでは全くの逆効果であり、しかも日本では同じ罪状で何度も起訴はできませんから、事実は永久に闇の中です。
 拷問による取り調べを行わなければ、犯人が自白しなかった可能性は残るとはいえ、自白させた挙句に自白の証拠能力が否定されて無罪になるよりマシです。これなら新しい事実が出てきた後で改めて起訴することもできます。しかも自白が得られれば、その証拠能力は拷問自白よりもずっと高く評価されます。
 その後、犯人が「私は拷問されて自白させられた」と愚にもつかないことを言い出しても、ビデオを証拠に「拷問的な取り調べは認められない」と主張すれば一発です。このように、治安維持法のような活動でもしていない限り、カメラ導入は警察にとってもメリットがあります。政府の責任で検討すべきです。
 無論、無罪の人にとってもカメラ導入は歓迎すべきことです。取り調べで拷問されることはなくなりますし、仮に拷問されたとしても、ビデオを証拠としてその旨を証明できます。あるいは警察がそのビデオを隠蔽や破棄、消去したとしても、被疑者の取り調べに関する発言が生々しく、さらに「警察がなぜかビデオを出したがらない、あるいはビデオを削除・破棄した」という事実があれば、裁判官はそれを考慮します。
 さらに、取り調べ手段として最悪な「犯人しか知らない情報を取り調べ中に被疑者(無罪)に伝え、それを知っていることを理由に起訴」といったことも完全に防止できます。その上、被疑者が必死で無実を主張しているにもかかわらず、散々自白を求められた挙句に起訴されれば、やはり裁判ではそれが考慮されます。
 このように、警察に取り調べにもカメラを導入すべきであることは疑いようもありません。既得権益に切り込まれて怒るのは、談合業者もマスコミも警視庁も同じです。これを剥奪するのは政府の役目です。

 この前はクイックソートなど組みましたが、今回は他のソートでも。というわけで、基数(バケット)ソート、ヒープソート、マージソートを全部実装してしまいました。Javaの場合のソースを出しておきますが、一旦C++で書き、それを書き直してJavaに移植していますので、記述はどことなくCっぽいです。
 ヒープソートなど、実装は非常に簡単です。相当にコードを削減したクイックソートより短いですし。バケットソートはなかなか複雑でしたが、こんなものでしょう。ただ、言語仕様の性質上、今回の実装ではマイナス値をソートすることはできません。マージソートはとりあえずバケットに比べれば簡単です。
 それぞれ原理について触れておきますと、ヒープソートはまずデータをツリー構造にします。1つの根から2つの枝が出て、それがさらに2つに枝分かれ、といった具合です。そして、それぞれの枝元のデータが枝先のデータよりも数値が大きくなるように枝先からさかのぼってデータを並び替えます。そうすると、ルートのデータが最も大きくなりますから、これを除外し、残りのデータを用いて再び枝構造を作ります。これがヒープソートです。
 バケットソートは最もソートらしいソートで、例えばトランプを並び替えする場合、1〜13までの入れ物を用意した後、1枚ずつ見ていって数字別に分類するようなものです。ただ、トランプなら1〜13まででたかが知れていますが、何千何万ともなる数字の場合、入れ物を山ほど用意しなければなりません。
 というわけで、今回はまず根元の4ビットを読んでソートし、それが終わったらそこからさらに上の4ビットのデータを読む、といった具合にソートを繰り返しています(基数ソート)。今回のように32ビットのデータを読む場合は4ビット単位のソートを8回繰り返すことになります。
 仮に1ビット単位のソートを32回繰り返すとしたら、並び替える回数は32ビット単位のソートを1度行う場合の32倍前後になります。逆に、32ビット単位のソートを1回で済ませるなら、並び替え回数は前者の1/32になりますが、必要なメモリは2^31倍になります。
 つまり、「1ソートごとのデータ量を少なくして、代わりに回数を多くすることは、ソート速度と引き換えにメモリの節約を行うもの」という説明がなされますが、間違いではありませんが正しいとは言い切れません。なぜなら、2^x倍ものメモリ確保となると、そのオーバーヘッドもバカっ高いため、それよりソート回数を多くした方が高速な場合が多いのです。4ビットの8回というのは比較的効率が高い落としどころです。
 今回は比較のため、「メモリの節約を考えず、いわばトランプ52枚が入る入れ物を13個用意するバケットソート」と「最初に各枚数を計算するオーバーヘッドをあえて冒すが、その代わり枚数に応じた入れ物を用意するバケットソート」の2つを用意しました。
 マージソートはデータを素粒子レベルまで、もとい1つずつまで分解し、その後でバラしたデータを数値順に組み替えるソートです。バラしたデータを再回帰的にバラしていきますので、最大で配列長の2倍程度のメモリを必要とします。
 それでは書いてみたソースを。
class SortAlgorithms{
	public void bubbleSort(int sort[] , int start , int end){
		boolean change = true;
		while(change){
			change = false;
			for(int i = start; i < end; i++){
				if(sort[i] > sort[i + 1]){
					int s = sort[i];
					sort[i] = sort[i + 1];
					sort[i + 1] = s;
					change = true;
				}
			}
		}
	}
	public void quickSort(int sort[] , int start , int end){
		if(start >= end)
			return;

		int key = sort[start];

		int first = start;
		int last = end;

		while(first != last){
			while(sort[first] < key)
				first ++;
			while(sort[last] >= key && first < last)
				last --;

			if(first < last){
				int f = sort[first];
				sort[first] = sort[last];
				sort[last] = f;
				first ++;
			}
		}

		if(start == first)
			first ++;

		quickSort(sort , start , first - 1);
		quickSort(sort , first , end);
	}
	public void radixSort(int sort[] , int start , int end){
		int bv = 4;	// 1回のソート単位(ビット)
		int max = 8;	// ソート回数

		int len = end - start + 1;
		int bit = 1;	// ビット深度
		for(int i = 0; i < bv; i++)	// 累乗(bit = 2^bv)
			bit *= 2;

		for(int b = 0; b < max; b++){
			// バケットを用意(それぞれ配列長分のメモリを用意)
			int backet[][] = new int[bit][len];

			// バケット個数の格納配列
			int bindex[] = new int[bit];
			for(int i = 0; i < bit; i++)
				bindex[i] = 0;

			// バケット分別
			for(int i = start; i <= end; i++){
				int d = (sort[i] & ((bit - 1) << 
					(bv * b))) >> (bv * b);
				backet[d][bindex[d]] = sort[i];
				bindex[d] ++;
			}

			// ソート配列に落とす
			int index = start;
			for(int i = 0; i < backet.length; i++){
				for(int e = 0; e < bindex[i]; e++){
					sort[index] = backet[i][e];
					index ++;
				}
			}
		}
	}
	// メモリを節約する基数ソート
	public void lowMemoryRadixSort(int sort[] , int start , int end){
		int bv = 4;
		int max = 8;

		int bit = 1;
		for(int i = 0; i < bv; i++)
			bit *= 2;

		for(int b = 0; b < max; b++){
			int backet[][] = new int[bit][0];

			// 配列をどれだけ確保するかを調査
			int use[] = new int[backet.length];
			for(int i = start; i <= end; i++){
				int d = (sort[i] & ((bit - 1) << 
					(bv * b))) >> (bv * b);
				use[d] ++;
			}

			// 必要なだけ配列を確保
			for(int i = 0; i < backet.length; i++)
				backet[i] = new int[use[i]];

			int bindex[] = new int[bit];
			for(int i = 0; i < bit; i++)
				bindex[i] = 0;

			for(int i = start; i <= end; i++){
				int d = (sort[i] & ((bit - 1) << 
					(bv * b))) >> (bv * b);
				backet[d][bindex[d]] = sort[i];
				bindex[d] ++;
			}

			int index = start;
			for(int i = 0; i < backet.length; i++){
				for(int e = 0; e < backet[i].length; e++){
					sort[index] = backet[i][e];
					index ++;
				}
			}
		}
	}
	public void heapSort(int sort[] , int start , int end){
		int first = start;
		int last = end;

		while(first != last){
			// ヒープ構造を作成
			for(int i = last; i > first; i--){
				// 親の位置を求める
				int p = (i + 1 - first) / 2 - 1 + first;

				// 子の方が大きければ入れ替え
				if(sort[i] > sort[p]){
					int t = sort[i];
					sort[i] = sort[p];
					sort[p] = t;
				}
			}

			// ルートヒープを入れ替えて末尾に確定
			int t = sort[last];
			sort[last] = sort[first];
			sort[first] = t;

			last --;
		}
	}
	public void mergeSort(int sort[] , int start , int end){
		if(start >= end)
			return;
		int len = end - start + 1;

		// 分解
		int s[][] = new int[2][0];
		s[0] = new int[len / 2];
		s[1] = new int[len - s[0].length];

		// コピー
		int index = start;
		for(int x = 0; x < s.length; x++){
			for(int y = 0; y < s[x].length; y++){
				s[x][y] = sort[index];
				index ++;
			}
		}

		// 再帰的ソート
		for(int i = 0; i < s.length; i++)
			mergeSort(s[i] , 0 , s[i].length - 1);

		// 並び替え
		int pos[] = new int[2];
		for(int i = 0; i < pos.length; i++)
			pos[i] = 0;

		for(int i = start; i <= end; i++){
			int copy = 0;
			// インデックスの範囲内かチェック
			if(pos[0] >= s[0].length){
				copy = 1;
			}else if(pos[1] >= s[1].length){
				copy = 0;
			}else{	// 範囲内なら
				if(s[0][pos[0]] < s[1][pos[1]])
					copy = 0;
				else
					copy = 1;
			}
			sort[i] = s[copy][pos[copy]];
			pos[copy] ++;
		}
	}
	// 正しくソートがなされていれば true
	public boolean checkSort(int sort[] , int start , int end){
		for(int i = start; i < end; i++){
			if(sort[i] > sort[i + 1])
				return false;
		}
		return true;
	}
}
 といったところです。マージソートはまだオーバーヘッドを減らせそうですが、力尽きました。では、どのソートが優秀なのか。以下に結果を示します(結果はソート量やバラけ方によっても異なりますので、あくまで1例です)。0〜1024の範囲の数値をランダムに生成し、それを2048要素の配列に格納、それをソートしました。
 念のため、checkSort()メソッドを呼び出してソートの正当性をチェックしています。
初頭ソートチェック : false

バブル
ソートチェック : true
所要時間 : 261

クイック
ソートチェック : true
所要時間 : 10

基数
ソートチェック : true
所要時間 : 70

ヒープ
ソートチェック : true
所要時間 : 180

メモリ節約基数
ソートチェック : true
所要時間 : 30

マージ
ソートチェック : true
所要時間 : 40
 やはりクイックソートがダントツです。その次に来ているのがメモリ節約版の基数ソート。何と、メモリの所要量を計算するオーバーヘッドがあるにもかかわらず、メモリを節約しない方より倍も速いのです。これは、所要量計算のオーバーヘッドよりも、大量のメモリを確保するオーバーヘッドの方が著しく大きいためなのでしょう。
 その次がマージソートです。それなりに速いようで。ただ、メモリは結構使いそうですが。そしてかなり離れてヒープソート。これはそれほど遅いソートではないはずなのですが、実装を間違えたのでしょうか。今回はとりあえず動作テストですので、もう少し実装を続けることにします。
 そして最後がバブルソート。実装が恐ろしいほど簡単ですから、これは仕方ないでしょう。

 SQLのコーナーでも魔道士イリアスと同じく毎回登場している騎士サーラ。それはもう、主役キャラですから。魔道士イリアスは最初から最後までほとんど設定が変わっていませんが、騎士サーラの設定はかなり違っています。ということで、この人に関する設定は多いの何の。
 クラスは「デュアルナイト」です。階層は「Knight/DualKnight」ですが、敬称は一般騎士と同じく「騎士」です。というのも、「二次元騎士サーラ」ではファミコンのアクションゲームのようになってしまいますし、「次元騎士サーラ」では「ディメンジョンナイト」と変換されてしまいます。「多元騎士サーラ」では気が抜けますし、「多重騎士サーラ」では、多重債務でもあるまいし
 起こりとしましては、最近は「過剰な反フェミニスト思想」が幅を利かせています。もうこれの愚かさといったら。どうせ「昔に戻ろう」的な思想なのでしょうが、実際には女剣士の骨が出土したりしており、昔は下手すると現代よりも性差別思想が薄かった可能性があります。現代より大昔の方が社会は進んでいるようで。
 ただ、これ自体についてはあえて悪いとは言いません。というのも、退行現象というのは様々なものに見られる現象ですから。例えば企業が成長する際、1、2年ほど足踏みまたは減収となり、その後でグッと伸びることはよくあります。人間幼児の脳も、学習の途中で一旦学習レベルが下がり、その後で一気に伸びていくそうです。薬が効く際も、一旦悪くなってから回復する話はよくあります。つまり、ここのところのバカげた過剰な反フェミニズムは退行現象であり、この先は退行を補って余りある巻き返しがなされるでしょう。
 例えば日本語には「全然」という言葉があります。自称・識者によれば「全然いい、などという表現はけしからん」そうですが、これはそもそも肯定の言葉でのみ使う言葉であり、明治の文豪によって否定の意味が後付けされ、肯定に使われる機会が減っただけの話です。こういうエセ識者が日本語をぶち壊しているのは否定できない事実ですが、要するに過剰な反フェミニズムもこれと同じなわけです。そして、「全然」がもはや肯定にも否定にも用いられている通り、結末も同じになるでしょう。
 しかし、こういう時代錯誤(というより、昔の土壌から女剣士の骨が出土しており、さらにこうした意見が現代のガンでもある以上、これは退行現象に相乗りまたは悪乗りした意見に過ぎず、時代錯誤という言い方もおかしいですが)的な意見に関しては、私のテイストでチクリと一撃を加えておきたいところです。それの結果が初期設定版の騎士サーラというわけです。
 これが色々変化して、最初はそこそこ使えた魔法が使えなくなり、その代わり抜群の強さを手に入れ、少々かわいらしかったのが無粋で純粋な騎士となり、今に至ります。変わっていないのは、大剣使いという辺りだけ(というより、それが1番の特徴なのでは)。そんなこんなのSQL.35です。

騎士サーラ「これの動作速度が260km/hとして、質量が経験的統計で平均がこの程度とすれば、エネルギー量には光速を用いて演算しますから・・・1単位あたり10^4*7ジュールの・・・」
魔道士イリアス「サーラ、サーラ!」
騎士サーラ「はっ、イリアスさん、お呼びでしょうか」
魔道士イリアス「うっかり床に水こぼしたんだけど、拭いてくれる?」
騎士サーラ「はっ、今すぐに。道具を取ってまいりますゆえ、今しばらくお待ちください」
剣聖ハードゥン「おいおい、イリアス君・・・」
魔道士イリアス「冗談よ。それで本題なんだけど、外国から会食の要請があったのよ。シェリー曰く、応じようとは考えてるらしいんだけど・・・」
騎士サーラ「我が国のために必要なら、応じるべきでしょう」
魔道士イリアス「ただ、この国が政情不安定な上に治安の悪い国でねぇ・・・。会食中だって何が起きるか分からないわ。でも、私は政治とか経済なんかちっとも分からないから、サーラとシェリーは必要なのよ。問題は、シェリーって戦闘員じゃないから、もしもの時に危ないのよね」
騎士サーラ「なるほど・・・。しかし、シェリーさんは応じる構えなのでしょう?」
魔道士イリアス「そうなのよ。一応警護はあっちでもつけてくれるらしいけど、不安定なのは変わらないし、まさかないとは思うけど会食自体が相手政府のワナってこともありえるわ。我が国は新政府が樹立したばかりで、シェリーとかサーラのような主要人物がいなくなれば、大変な混乱が起きるからね」
騎士サーラ「確かに、いかなる可能性も考えておかなければなりません」
剣聖ハードゥン「会食参加者は双方6名ずつ、後はいかなる者も部屋に入ってはならない、というのが相手のお達しだ。おそらく、長方形のテーブルに6人が1列に腰掛け、向かい合う形になるだろう」
騎士サーラ「はい。となると、シェリーさんやイリアスさんをお守りするには、できるだけ隣に腰掛けるべきですね・・・」
剣聖ハードゥン「そうだ。そこで、6人が横一列に腰掛けた場合で、もっとも堅固な並びを考えて欲しい。まずこれが参加予定者6名だ。仲間を守る役割を兼任できる人間には”護衛”と注釈をつけておいた」
イリアス
サーラ(護衛)
ハードゥン(護衛)
シェリー
シェイン(護衛)
アマンダ
剣聖ハードゥン「アマンダ君も弓さえ使えれば護衛できるのだろうが、さすがに会食に弓を持ち込むわけにもいかぬから、アマンダ君はもしもの時には自分の身を守るので精一杯だろうという話だった」
魔道士イリアス「なるほどねぇ・・・。それで、並び方だけど・・・どうする?」
剣聖ハードゥン「そうだな。シェリー君は身を守るすべを持たぬから、左右両隣を護衛で固めた方が良いだろう」
魔道士イリアス「護衛っていうと、ハードゥンとかを隣に配置すればいいのね」
剣聖ハードゥン「うむ。だが、私のような老いぼれに護衛役などがつとまるか、少々不安ではあるが・・・」
騎士サーラ「それでは私がハードゥンさんの隣に座りましょう」
剣聖ハードゥン「そうしてもらえると助かる」
魔道士イリアス「サーラ、私の隣にも座ってもらえる?あなたがいれば安心だから」
騎士サーラ「はっ」
剣聖ハードゥン「それからアマンダ君だが、自分は一応戦士であるから、護衛ができる人は他の人を守って欲しいとのことだ。そこで、アマンダ君の隣に護衛は置かないことになった」
魔道士イリアス「分かったわ。ところで、その会食なんだけど、相手の長はどこに座るの?」
剣聖ハードゥン「そこまでは聞いておらぬ。だが、相手方の椅子の中に1つだけ少々豪華なものが混ざっていた。そこに座るのだとすれば、我々の側から見てやや右寄りの位置になろう」
魔道士イリアス「じゃあ、サーラは中央よりも右側に配置して。サーラはメンバーの中でもシェリーと同じくらい頭がいいし、それに目立つから、相手の首脳に近い位置がいいわ」

 さあ、これらすべての条件を満たす席順は存在するのでしょうか。

模範解答
 会食に弓を持っていくのはダメでも、剣は大丈夫なのでしょうか。いや、相手国は治安が悪いのです。しかも、相手も護衛をつけてくるでしょうし、そもそも騎士は剣を持つものですから、これで良いのです。ということで、テーブルを作ります。
CREATE TABLE n(n INT) ENGINE=HEAP;
INSERT INTO n VALUES(0) , (1) , (2) , (3) , (4) , (5);
 便宜上、席に左から0〜5の番号をつけました。ということは、キャラはカラム軸になるわけです。というのも、カラムを席順にしてレコードをキャラにする場合、「隣に何々が座っている必要がある」のような計算をしようとすると、なかなか大変なことになってしまうのです。
 とはいえ、この方法でも護衛の計算がなかなか大変なことになってしまうのですが。ここは好みの問題でしょうか。ということで、まずは護衛の計算を考えず、個人指定だけを考えて打ってみます。
SELECT ilias.n , sara.n , harden.n , shein.n , shelley.n , amanda.n 
FROM n ilias , n sara , n harden , n shein , n shelley , n amanda 
WHERE ABS(sara.n - harden.n) = 1 AND ABS(ilias.n - sara.n) = 1 AND 
sara.n >= 3 AND 
BIT_COUNT(1 << ilias.n | 1 << sara.n | 1 << harden.n | 1 << shein.n | 
1 << shelley.n | 1 << amanda.n) = 6;

// Result
...
24 rows in set
 これだけでもかなり絞れています。しかし、シェリーさんの両側には護衛が必要ですし、弓兵アマンダの好意も受け取りたいところです。ということで、クエリを書き換えます。
SELECT ilias.n AS 'Ilias' , sara.n AS 'Sara' , harden.n AS 'Harden' , 
shein.n AS 'Shein' , shelley.n AS 'Shelley' , amanda.n AS 'Amanda' 
FROM n ilias , n sara , n harden , n shein , n shelley , n amanda 
WHERE ABS(sara.n - harden.n) = 1 AND ABS(ilias.n - sara.n) = 1 AND 
sara.n >= 3 AND 
shelley.n + 1 IN(sara.n , harden.n , shein.n) AND 
shelley.n - 1 IN(sara.n , harden.n , shein.n) AND 
!(amanda.n + 1 IN(sara.n , harden.n , shein.n)) AND 
!(amanda.n - 1 IN(sara.n , harden.n , shein.n)) AND 
BIT_COUNT(1 << ilias.n | 1 << sara.n | 1 << harden.n | 1 << shein.n | 
1 << shelley.n | 1 << amanda.n) = 6;

// Result
Ilias	Sara	Harden	Shein	Shelley	Amanda
4	3	2	0	1	5
 といったところでしょうか。見ての通り、か弱いシェリーさんは護衛にはさまれていますし、騎士サーラは魔道士イリアスと剣聖ハードゥンを守ることができます。

騎士サーラ「・・・国内の対外貿易高によれば、為替影響力は・・・」
魔道士イリアス「サーラ!」
騎士サーラ「はっ、お呼びでしょうか」
魔道士イリアス「ガラス割れたんだけど。片付けてもらえる?」
騎士サーラ「はい。どちらでしょうか」
魔道士イリアス「ほら、あっちなんだけど・・・」
剣聖ハードゥン「・・・うーむ・・・」
弓兵アマンダ「団長、あれでは、騎士というより小間使いなのでは・・・」
剣聖ハードゥン「それは気にしてはならないお約束だ」

魔道士イリアス「ほら、こっちよ。急いで」
騎士サーラ「イリアスさん、こちらは廃ビルの裏路地では・・・」
魔道士イリアス「ほら、あれよ、あれ。シェリーの後ろのガラスが割れてるじゃない」
明らかにその筋のこわもて黒服数名「シェリーさんよ、俺らがこんなに頼み込んでも、あんたの社は取引に応じてくれないってのか?」
イリスのシェリー「わが社はそのような取引はいたしません」
黒服「ふーん、そうかい・・・。話しても分かる相手じゃなさそうだ・・・」
魔道士イリアス「というわけでサーラ、あんなのでケガするなんてバカバカしいから、早く片付けて」
騎士サーラ「はっ、分かっております」
魔道士イリアス(それにしても、どうしてシェリーって、いつもドジったりトラブルに巻き込まれたりなのかしら・・・。やっぱり両側に護衛が必要ね)

 このように、外相級会談にもSQLは欠かせない逸品なのです。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -