yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/11 の記事
[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
カテゴリ表示
 カテゴリ 経済・知的財産 に当てはまるもののみを表示します。

 存在する記事 150 件の中から 6-10 件を表示しています。
日本憂政
2009/10/25(Sun)13:42:17
 政権交代の影響により、日本郵政の西川氏が事実上罷免されましたが、今度はその後任人事が問題となっているようです。新社長とされるのは斉藤次郎氏ですが、氏は1995年まで大蔵省の事務次官を務めており、民主党が進める「脱官僚・天下り」との整合性が取れていないとして批判されています。また、日銀の新総裁を決定する際には、民主党は財務官僚出身であることを理由として武藤氏や田波氏を総裁とする人事に強硬に反対し、結果として副総裁になるはずの白川氏が総裁となりましたが、その一方で今回の元官僚の起用とあって、自民党新総裁の谷垣氏らは批判を強めています。
 斉藤氏が官僚を辞めてから14年が経過しており、この期間をどの程度重く考慮するかによっても評価は違ってくるはずですが、少なくともこの人事が脱官僚・天下り路線を推進するものであるとは言いがたく、その点で批判を受けるのは当然でしょう。下手をすると「脱官僚」の目標自体も頓挫しかねないほどの問題ですので、民主党が説明責任を果たさなくてはならないのは言うまでもありません。しかしながら、日銀を引き合いに出して今回の人事を批判する主張には同意しかねます。日銀の場合とはあまりに状況が違いすぎるためです。
 経済関係の問題は難解であるため、何となく「民主党が武藤・田波総裁案に反対したのは官僚出身だから」と捉えている人が多いとしても無理のないことですが、実際には単に元官僚なのが理由と捉えるのは正しくありません。日本銀行法では、日銀は政府と連絡を密にし、十分な意思疎通を図らなくてはならない旨が定められていますが、一方では独立性も必要であり、「金融と財政の分離」の観点からも問題が生じてくる恐れがあります。
 総裁と財務省とのパイプが十分残っていれば、日銀の独立性が損なわれる可能性は否定できません。以前に日銀が金融緩和政策を緩めようとした際、政府が立法権をちらつかせて日銀をけん制したことがありましたが、これなどは独立性の重要さを示す事例でしょう。政府としては、自政権の評価がかかっていたり、近日中の選挙が予想されるタイミングでは、景気の腰を折る可能性がある策を実行されては困るなど、様々な力学が絡んできます。すなわち、日銀の独立性を担保するために、元財務官僚の人間を総裁にしない行為には、ある程度の妥当性があります。
 無論、日銀同様に日本郵政にも独立性が必要であるから、元官僚を社長にすべきでないとの意見はあってもおかしくありませんし、これもまた重要なことです。しかしながら、西川氏が不公正な可能性の否定できない行為を行って問題視され、鳩山邦夫氏など自民党内の人間からも異論が出るほどであったのは周知の事実ですし、麻生氏は氏を排除しようとしたものの、小泉・竹中院政に先手を打たれて外堀を固められてしまい、逆に鳩山氏を切らざるを得なくなるなど、こちらも政治力学が非常に強く作用しています。したがって、独立性の観点を問題にするのであれば、西川氏の時点からの総括が必要でしょう。
 また、人事の透明性の面から見ても、確かに斉藤氏の起用は「脱天下り」に反するといえなくもありませんが、日銀の場合は「たすきがけ人事」という不透明な慣習が具体的に存在しており、財務官僚の起用はそれの再燃や疑念を招きかねない状況でした。具体的に存在する不透明な人事の懸念を問題視したものと考えれば、日銀の武藤氏ら起用に対する民主党の反対は、直ちに「元官僚の起用」を全否定したものであるとは言いがたく、今回の人事と日銀とではそれなりの違いがあると言わざるを得ません。
 このように、条件が違いすぎる日銀を引き合いに出して今回の人事を否定したとしても、どこかで話がかみ合わない事態に陥り、不毛な議論ともなりかねません。もし谷垣氏らがそのような批判に終始するのであれば、「自民党の野党ぶりも板についてきた」と皮肉のひとつも言いたくなるところです。
 谷垣氏がやるべきは、日銀総裁うんぬんではなく日本郵政の社長に斉藤氏が就任することに対する懸念や問題点を指摘し、ひいては連立与党の郵政の方針をただすことです。日本郵政社長としての斉藤氏の手腕は未知数ですが、亀井氏がかかわっている点からして民営化に消極的なのはほぼ間違いなく、政権時には郵政民営化を進めてきた自民党としては、日銀を引き合いに出して粗を探すより、郵政政策に関して論じるべき場面です。民主党の側も、国民新党との関係もあり、なかなか明確なスタンスが打ち出しにくいとみられますので、攻勢をかける上でも効果的でしょう。自民党や谷垣氏としても、仮に民主党が批判を容れて斉藤人事を撤回し、郵政民営化に反対で民間出身の別の人を社長につけたとしても、おそらく批判は行うはずで、「日銀」の問題が本質的なものでないことが分かります。
 確かに、政治や経済といった関係の話は難しい場合が多く、委細に渡って郵政の問題をただすより「斉藤氏の起用は天下りの官僚人事で、日銀総裁人事の対応と矛盾している」と主張した方が、何となく民主党に悪印象を抱かせることはできそうですが、それでは困ります。目立つばかりの小泉氏や麻生氏と違い、どちらかといえば政策通タイプの谷垣氏だけに、郵政についての議論が行われる希望がないとはいえません。

 ところで、次の参院選で民主党単独政権が誕生した場合はともかく、今のところは郵政民営化に消極的な立場を取っている連立与党ですが、その姿勢に対して「民営化は郵政選挙であれだけの民意を得たのだから、安易に止めるのは許されない」との意見が存在するようです。それについて少々触れておきます。
 私としては、そうした言い分自体は決して理解できないわけではありませんが、これに明確に反対します。なぜなら、郵政選挙において少なからぬ国民は、郵政民営化のデメリットをほとんど認識していなかったためです。
 はっきり言って、郵政選挙の際には調べもせずに小泉氏に賛同していながら、後になって郵便局が不便になったことに文句を言うような人間に、私は大変深く失望しています。常識的に考えて、「郵政民営化を実現すれば日本はバラ色で、その上副作用もない」などという上手い話があるわけがないのです。したがって、小泉氏不支持であったのに不便を負わされている人は気の毒と言うよりありませんが、小泉氏の郵政を支持した上で不便さに文句をつけるなど、選挙の結果責任を侮っているとしか言いようがなく、本来なら考慮する必要すらありません。
 しかしながら、小泉氏はあたかも郵政民営化が正義であるような主張を行い、デメリットどころか郵政民営化なるものが何なのかも知らぬまま支持していた人も存在するようです。スリードの低IQ戦略によるものですが、これでは後々不満が出るのも当然で、小泉氏のやり方には大いに問題があったといえるでしょう。
 結果、不便になるなどとは聞いていなかった人々が当然のごとく憤り、実際に直接被害をこうむった人、あるいは不安を覚えた人が自民党を見限り、それが民主党大勝の原因の1つとなったことは十分に考えられます。また、党内にも異論が出てくる状況が予想され、事実として麻生氏は郵政民営化を否定するかのような発言を行うなど、明らかにゆり戻しの機運が発生していました。ひとたびそうなってしまっては、いずれ郵政見直しの動きが出てくるのも必然の流れです。
 政権交代により、極端な場合は郵政民営化自体が頓挫しかねず、控えめに見ても減速するのは間違いありません。あの低IQ選挙と郵政の問題が自民敗北の遠因となったのであれば、郵政民営化が何なのかも分からぬまま支持していた連中はともかく、郵政民営化のデメリットは理解しつつも、それでも民営化は必要だから断行しなくてはならないと考え、小泉氏と郵政民営化を支持していた支持者すら裏切る結果となりました。これがあの華々しい低IQ選挙の結末です。まさに「選挙に勝って、勝負に負けた」ようなものです。勝負である郵政民営化は道半ばで阻まれてしまうのに、選挙に勝ったせいで金配りその他はことごとく通され、無賃残業合法化は通される寸前まで行くなど、何とも代償の大きい選挙でした。
 再び自民党が政権を取り、政権を競って切磋琢磨するのは大いに結構ですが、あのような選挙はもう二度とないことを望みます。

 Prologでは、例えば「アーランは人間である」「人間は生物である」といった「事実」を書くことができます。
human(ada).
human(haskell).
human(erlang).
cat(tom).
dolphine(sakila).

creature(X) :- human(X).
creature(X) :- cat(X).
creature(X) :- dolphine(X).
 これを読み込んだ後、例えば以下のような問い合わせが可能です。
% エイダは人間であるか
?- human(ada).
true.

% 誰が人間であるか
?- human(X).
X = ada ;
X = haskell ;
X = erlang.

% サキラは生物であるか
?- creature(sakila).
true.
 これが論理型言語たるPrologの特徴なのですが、果たしてPrologの派生であるErlangにこの種の機能はあるのでしょうか。
 Erlangでの類似機能は「Atom」と呼ばれており、命名規則もPrologに従っています。すなわち、先頭を小文字で記述した単語はAtomとみなされます。また、Erlangのリファレンスマニュアルによれば、文字列をシングルクォートで囲んだ場合、先頭の文字にかかわらずAtomとみなされるようです。
 したがって、以下のものはすべてAtomとなります。
atom
atom_type
atomType
'atom'
'atom type'
'Atom'
 シングルクォートで囲んでいないAtomと囲んだAtomは、両方同じものとみなされます。
1> atom == 'atom'.
true

2> atomType == 'atomType'.
true
 このAtom、平たく言えば定数のようなものなのですが、おそらくPrologから着想を得たものとみられるだけはあり、かなり色々な使い方ができそうです。他の言語でいえば、Lispのシンボルにも類似しています。
 手続き型で使用される定数の類のように、単にifなどで比較するだけでも使用できます。以下のプログラムは、1つ目の引数Xが数値、2つ目の引数SがAtomを取り、Atomの値がinclementの場合は数値に1を加算して返し、declementの場合は1を減算して返し、いずれでもない場合はそのまま返す、簡単なサンプルです。
-module(blog).
-export([num_action/2]).

num_action(X , S) -> if
	S == inclement -> X + 1;
	S == declement -> X - 1;
	true -> X
	end.
 これは以下のように呼び出せます。
1> blog:num_action(10 , inclement).
11

2> blog:num_action(5 , declement). 
4

% inclement または declement 以外のあらゆる Atom を渡した場合
3> blog:num_action(5 , any_other_atom).
5
 ただ、ErlangのAtomで面白い点は、何と言ってもパターンマッチでしょう。Prologを基にした関数型言語だけに、似たような書き方が可能となっています。
 以下のプログラムは、先ほどのPrologコードのhumanと類似しています。さすがにPrologと違って「誰が人間であるかを列挙」したりはできませんが、「アーランは人間か」を問い合わせることなら可能です。
-module(blog).
-export([human/1]).

human(ada) -> true;
human(haskell) -> true;
human(erlang) -> true.
 ただし、上記ではada、haskell、erlangのいずれかのAtomが引数として渡された場合の動作しか定義されておらず、それ以外のAtomが渡された場合の動作が存在しませんので、これら以外のAtomを渡すと例外が発生します。例外ではなくfalseを返すには、単に以下のようにするだけです。
-module(blog).
-export([human/1]).

human(ada) -> true;
human(haskell) -> true;
human(erlang) -> true;
human(_) -> false.
 もう少しPrologの真似事を行ってみます。Erlangは関数型言語ですので、論理型言語としての側面(「定義された人間をすべて列挙」するような逆引きの機能、複数経路の探索など)は持っていませんが、「サキラは生物であるか」を調べる関数程度なら簡単に作成できます。
-module(blog).
-export([human/1 , cat/1 , dolphine/1 , creature/1]).

human(ada) -> true;
human(haskell) -> true;
human(erlang) -> true;
human(_) -> false.

cat(tom) -> true;
cat(_) -> false.

dolphine(sakila) -> true;
dolphine(_) -> false.

creature(X) -> human(X) orelse cat(X) orelse dolphine(X).
 実際に問い合わせてみると、
1> blog:creature(sakila).
true

2> blog:creature(erlang).
true

3> blog:creature(plant).  
false
 サキラもアーランも生物であるとみなされているようです。植物(というより定義されていないあらゆるもの)は生物とはみなされません。
 ちなみに、Erlangではtrueもfalseもその実体はAtomです。
There is no Boolean data type in Erlang. Instead the atoms true and false are used to denote Boolean values.
 当然、以下のような式も成り立ちます。
1> true == 'true'.
true

2> false == 'false'.
true
 また、atom_to_list及びlist_to_atom関数を使用すると、Atomを文字列にしたり文字列をAtomにしたりできるようです(「Strings are enclosed in double quotes ("), but is not a data type in Erlang.」とのことで、「文字列」の呼称自体正しくないかもしれませんが)。文字列の比較と比べてパフォーマンス上の利点があるのであれば、辞書型のキーなどの使い道もありそうです。
% 追加と取得の操作しかなく、何の最適化もない非常に単純な辞書型の実装
% Erlang のタプルは丸カッコではなく {...} でくくる
-module(blog).
-export([add/3 , get/2]).

add(X , K , V) -> [{K , V} | X].
get([{K , V} | _] , K) -> V;
get([_ | XS] , K) -> get(XS , K);
get([] , _) -> throw("Not found.").

% 実際に使用
1> D_1 = blog:add([] , ada , "Ada Lovelace").    
[{ada,"Ada Lovelace"}]

2> D_2 = blog:add(D_1 , haskell , "Haskell Curry").
[{haskell,"Haskell Curry"},{ada,"Ada Lovelace"}]

3> D_3 = blog:add(D_2 , erlang , "Agner Erlang").         
[{erlang,"Agner Erlang"},
 {haskell,"Haskell Curry"},
 {ada,"Ada Lovelace"}]

4> blog:get(D_3 , haskell).
"Haskell Curry"

5> blog:get(D_3 , erlang). 
"Agner Erlang"

6> blog:get(D_3 , unknown).
** exception throw: "Not found."
     in function  blog:get/2
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

用済団体連合会
2009/10/18(Sun)19:58:38
 政権が変わったことで、国会や国政に直接関係のない部分でも様々な変化が起こりつつありますが、象徴的なのが経団連の弱体化です。選挙前に政権交代の兆しが見え始めた段階から、経団連の行動はかなり慎重なものへと変貌しつつあり、政権交代後はさらにその傾向が強くなりました。これまで献金の目安として示してきた政策の格付けも、今年は見送りに追い込まれています。
 何はともあれ、経団連が以前より政治から遠ざけられるのは非常に良いことです。勘違いしてはいけない点なのですが、経団連はあくまで「大企業の、大企業による、大企業のための政策を実現させるための組織」に過ぎず、決して正義の味方や憂国の士ではありません。経団連と蜜月の関係にあった自民党と違い、民主党が彼らと距離を置こうとしているのは、民主党の政策理念からしても、おおむね正しい方向性です。
 経団連の代表的な主張として、「消費税を上げて法人税を下げる」などといったものがありますが、私はこれを全くの逆効果と考えているものの、「企業主導の景気回復」を期待したものとも取れますので、これだけで経団連が自分のことしか考えていないと評するのは早計です。しかしながら、談合発覚時に取り立てる金額を欧米並みに引き上げる案が出た際には、経団連が頑強に抵抗し、引き上げ幅を縮小されてしまいました。また、公益通報者保護法も経団連によって骨抜きにされています。三菱や雪印偽装、ミートホープ問題などが公益通報で発覚したことを考えれば、国民の生命すら脅かしかねない行為と断じざるを得ません。無賃残業合法化が検討された際には、当時の政府が「年収900万円」を条件として、一般の人には適用しないとのアピールに腐心する一方、経団連は「年収400万円」をハードルにすることを主張しており、狙いは見えたも同然でした。ここまで徹底していると、さすがに弁護のしようもありません。
 今年は見送りとなった政策評価にしても、その実は2008年分を見れば一目瞭然です。A〜Eの5段階評価で、10項目について「合致度」「取組み」「実績」の3種類の評価がなされているのですが、以下の表は各党・各評価ごとにA〜Eの個数をまとめたものです。

評価 自由民主党 民主党
合致度 取組み 実績 合致度 取組み 実績
A 7 3 0 0 0 -
B 2 6 7 3 2 -
C 1 1 3 6 3 -
D 0 0 0 1 5 -
E 0 0 0 0 0 -

 産経新聞の「教科書の通信簿」も真っ青の恣意的評価です。民主党にAはなく、自民党にDはありません。公開は2008/9/17とされていますが、この時期にはすでに自民党は指導力を非常に失っており、同24日には福田氏が辞任してしまいます。この評価を献金の目安にしていたといいますが、どこからどう見ても「自民党に献金しなさい」という布告です。これでは当然、民主党政権下では自粛せざるを得ないでしょう。
 とはいえ、これは驚くべき評価ではありません。経団連は企業の利益のための団体であって、日本を住みよい社会にしようと考えているわけではありませんので、自己利益のために自分の意に沿う政党に献金し、懐柔しようとするのは当然です。先の格付け評価を見ても、評価を「合致度」と銘打ってある辺り、まだ正直であるともいえます。
 ともかく、この意を受けた自民党が派遣を解禁したり、法人税を下げようとしたり、無賃残業合法化を成立直前の段階まで持って行ったりと、様々な政策を行ってきたのは間違いありません。ただ、経団連の思惑と国を安定させる方策が一致しているうちは上手くいくのですが、昨今のように新自由主義経済が破綻寸前となり、世界的に疑問符がついてくると、あくまで自己利益を優先する経団連の主張にはことさら矛盾が目立ってきます。法人税減税の決まり文句「企業が海外に逃げる」はそれを端的に表していて、これはすなわち「時勢を誤った企業優先主義で日本がボロボロになり、利用価値がなくなったとしても、大企業は日本を見捨てて海外に逃げることができる」とも言い換えられます。
 今後の日本で二大政党制が定着するかはまだ分かりませんが、もし日本が定着の傾向に動いていれば、経団連の影響力が低下することはあっても、強化されることはあり得ません。しかも経団連はおそらく多くの国民に見放されており、悪印象を持たれています。かく言う私も、経団連が何らかの「国民・社会・日本に有利な」政策を提言した際には、必ず裏を疑うようになってしまいました。しかも、事実として大抵は何らかの裏があります。
 二大政党制が定着すれば、献金で政権を動かして望みの政策を実現させるというモデルは、もはや時代遅れのものとなる可能性もあります。この「金も出すが口も出す」方針もまた国民に支持されているとは言いがたく、民主党は禁止の方針さえ打ち出しています。さらに、政権交代がいつでも可能となれば、経団連が自分勝手な政策を提言したとしても、各党はそれを実現するのが困難になります。このまま行けば、いずれ「我が物顔」が通用しなくなる日が来るでしょう。
 経団連は企業の団体のはずですが、もはや信用は失うところまで失っています。もはや自己利益だけを考え、政党にすり寄っていても相手にされなくなる時代となりつつありますが、果たして時勢を読み、信用を回復することはできるのでしょうか。
 ところで、亀井氏が経団連会長の御手洗氏に「家族間の殺人事件が増えたのは、大企業が日本型経営を捨てて人間を人間として扱わなくなったから」であると発言していたことが以前に取り上げられましたが、これについても少し取り上げておきましょう。
 残念ながら断定するほどの資料は見つけられませんでしたが、亀井氏の発言はおそらくデマです。家族間の殺人がどうかは不明ですが、少なくとも殺人事件全体に関しては、戦後から1990年付近までほとんどの時期において減少を続けており、特に1985年から90年にかけては大幅に減少し、その後はほぼ一定して低い水準が続いています。すなわち、現在の水準に落ち着いた1990年付近以前には、少なくとも今より多くの殺人が起きていたことになり、もし家族間殺人の割合が今と昔でさほど変わっていないのであれば、下手すると人口比で今の4倍も家族間の殺し合いが起きていた時代があったといえます。また、昔より今の方が家族間殺人の割合が多いとしても、「殺人の件数が減ったのは、もっぱら公共性の高い殺人が減ったため」とも考えられます。さらにさかのぼれば、親が子を殺したり売り払うことなど当たり前で、罪にすらならない時代もありました。
 ちなみに、日本にはかつて「尊属殺」という罪があり、無期懲役か死刑という大変重い刑罰となっていましたが、栃木実父殺し事件で違憲判決が出され(一応補足しておくなら、この時の違憲判決は「減刑しても執行猶予にもできないほどの罪は重すぎる」というもので、必ずしも罪自体を違憲とするものではありませんでしたが)、法律自体はいつもながら自民党の意味不明な家族観による抵抗で削除されなかったものの、実際には全く運用されなくなり、しばらく後にはついに正式に削除されました。
 ついでに、私の価値観を述べておくなら、家族間の殺人より公共性の高い殺人の方が重く見られるべきと考えています。つまり、この主張自体が事実の可能性は低いものの、亀井氏が「家族間の殺人が増えている」と憂慮しているのに対し、私はむしろ家族間ではない公共性の高い殺人、すなわち見ず知らずの人をいきなり襲ったり、通り魔で多数を殺傷したりといった事件の方が重大であり、憂慮すべきものと考えています。
 「歯に衣着せぬ」のは結構ですが、根拠もなくデマを唱えられては論全体の信頼性が落ちます。経団連の身勝手さと新自由主義の失敗は多くの人が指摘するところとみられますが、いい加減な発言はこの論全体の信頼性を貶め、「同類の背中を撃つ」結果となります。厳重に謹んでいただきたいものです。

 携帯電話会社の1つに「ソニー・エリクソン」なるものがあります。
 ソニーと関係のある会社であるのは一目瞭然ですが、それでは「エリクソン」とは何か。エリクソン社はスウェーデンの会社で、主に通信機器を手がける世界的な大企業です。そして、ソニー・エリクソンは同社とソニーの合弁会社です。
 このエリクソン社が設計して社内で使用し、後に一般にも公開されたプログラム言語が、Prolog類似の関数型言語「Erlang」(アーラン)です。名前の由来は数学者アグナー・アーランらしいのですが(その他、Ada、Haskell、Pascalなども数学者らの名前を取っている)、どうも「エリクソンの言語」を意識したネーミングでもあるようです。ちなみに「アーラン」は通信量の単位としても使われています。
 以前にひとまず並列処理まで扱ってみたことがありますが、私とProlog系統の文法は相性が悪いらしく(いくら覚えようとしても絶対に覚えられないVBに比べればかなりマシですが)、基本の書き方すら忘れてしまうため、いい加減に覚書をしたためておきます。
 ひとまず、関数型のサンプルとして非常に有名な「階乗」から。大変いい加減ですが、Prologなら以下のようになります。
fact(X , R) :- in_fact(X , 1 , R).
in_fact(X , R , R) :- X =< 1 , !.
in_fact(X , Y , R) :- V is X * Y , I is X - 1 , in_fact(I , V , R).
 これは以下のように呼び出します。
?- fact(0 , R).
R = 1.

?- fact(1 , R).
R = 1.

?- fact(5 , R).
R = 120.

?- fact(10 , R).
R = 3628800.
 これはこれで面白いのですが、使い方が特徴的でとっつきづらく、実用性の点でも問題があります。「Prologがもっと実用的な関数型言語であれば」という夢物語のひとつも語りたくなるところですが、この夢をErlangがかなえてくれました
 以上のプログラムをErlangで書き直すと、以下のようになります。ファイル名はblog.erlとしました。
-module(blog).
-export([fact/1]).

fact(X) -> in_fact(X , 1).
in_fact(0 , R) -> R;
in_fact(X , R) -> in_fact(X - 1 , X * R).
 -exportでは公開する関数名のリストを指定し、ここに書かれていない関数は外部からは呼び出せません。関数の指定方法といい、つくづくPrologそっくりです。Prolog同様、通常はピリオドが区切りとなりますが、上記サンプルでいうところのin_fact/2同士はセミコロンで区切っている点に注意が必要です。
 これをErlangコンソールから呼び出します。binディレクトリのerl.exeもしくはwerl.exeがそれですが、いずれもカレントディレクトリのファイルを探す仕様となっているため、ソースを保存したディレクトリをカレントにした状態でerlやwerlを実行する必要があります。werl.exeへのショートカットを作っておいて、プロパティの「作業フォルダ」を普段使用するディレクトリにしておけば、カレントディレクトリ設定後にwerl.exeを呼び出す作業が自動的に行われるため便利です。
1> c(blog).
{ok,blog}

2> blog:fact(0).
1

3> blog:fact(10).
3628800
 Prologには独特の使いづらさがありますので、Erlangの方が割と何も考えずに書けそうです。用途が違うため一概に比較はできませんが、論理型言語に起因する冗長さや複雑さとも無縁であるため、Prologに比べてかなり効率良く記述できます。また、Lispその他の多くの関数型言語と違い、関数名の後にカッコでくくって引数を指定する形式であるため、手続き型言語に慣れ親しんでいてもそれなりに読みやすいのも特徴です。
 参考までに、OCamlまたはF#では以下のようなコードとなります(あえて型の指定は省略しています)。私が初めて関数型言語を習得しようとした際、何がどのように関数なのかが分からず、非常に戸惑った記憶があります。その際に使用したのがHaskellでしたが、果てはカリー化まで出てきて大混乱しました。関数型未経験者にとってはErlangの方が取っ付きがよさそうです。
let fact x =
	let rec in_fact x r = match x with
	| 0 -> r;
	| _ -> in_fact (x - 1) (x * r) in
	in_fact x 1;;
 関数型言語といえばリスト処理ですが、これもまたPrologに非常に類似しています。まずPrologより。
sum(X , R) :- in_sum(X , 0 , R).
in_sum([X | XS] , S , R) :- NS is X + S , in_sum(XS , NS , R).
in_sum([] , R , R).
 リストの中身をすべて足し合わせるコードです。これをErlangで書くと、
-module(blog).
-export([sum/1]).

sum(X) -> in_sum(X , 0).
in_sum([X | XS] , S) -> in_sum(XS , X + S);
in_sum([] , S) -> S.
 論理型の冗長さを除けば、記述していることはほとんど同じです。
 一方、Erlangは関数型言語だけあって、お得意の高階関数は非常に簡単に書けます。Prologでも書けるには書けますが、若干煩雑です。例によってPrologより。
filter(F , X , R) :- in_filter(F , X , [] , R).
in_filter(F , [X | XS] , R , RR) :- call(F , [X]) , ! ,
	in_filter(F , XS , [X | R] , RR).
in_filter(F , [_ | XS] , R , RR) :- ! , in_filter(F , XS , R , RR).
in_filter(_ , [] , R , RR) :- rev(R , RR).

rev(X , R) :- in_rev(X , [] , R).
in_rev([X | XS] , S , R) :- in_rev(XS , [X | S] , R).
in_rev([] , R , R).

% 条件
over5(X) :- X > 5.
 呼び出した結果は以下の通りです。
?- filter(over5 , [1 , 9 , 2 , 8 , 3 , 7] , R).
R = [9, 8, 7].
 これと同等のコードをErlangで書くなら、
-module(blog).
-export([filter/2]).

filter(F , X) -> in_filter(F , X , []).
in_filter(F , [X | XS] , R) -> E = F(X) , in_filter(F , XS ,
	(if E -> [X | R]; true -> R end));
in_filter(_ , [] , R) -> rev(R).

rev(X) -> in_rev(X , []).
in_rev([X | XS] , R) -> in_rev(XS , [X | R]);
in_rev([] , R) -> R.
 といったところでしょうか。
 ifで直接F(X)を評価するのではなく、一旦Eに代入してから評価しているのは、直接評価するとillegal guard expression呼ばわりされてしまうためです。リファレンスのGuardの項を見てみると、次のように書いてあります。
The set of valid guard expressions (sometimes called guard tests) is a subset of the set of valid Erlang expressions. The reason for restricting the set of valid expressions is that evaluation of a guard expression must be guaranteed to be free of side effects.
 確かに、ifやwhenに何らかの作用があるのは関数型言語としてはまずいのでしょうが、かなり余計なお世話です。一旦変数にしてしまえば、関数の副作用のある部分が複数回実行されることはなくなりますし、Erlangの変数は変更されない(a variable can only be bound once.)わけですから、ifやwhenから副作用を排除できる、という理屈です。そうでない場合、全く同じ条件判定を2つ並べた場合であっても、後者が実行されるような珍妙な事態に陥りかねません。ただ、いずれにしても言語側で規制すべき事柄ではない気がしてなりません。それとも最適化(メモ化など)を行う上で都合が悪いのでしょうか。
 今回書いたfilter/2は高階関数ですから、呼び出す際には関数を渡さなくてはなりませんが、関数型言語のお約束通り、Erlangもラムダをサポートしています。
1> c(blog).
{ok,blog}

2> blog:filter(fun(X) -> X > 5 end , [1 , 9 , 2 , 8 , 3 , 7]).
[9,8,7]
 ラムダの書き方も手続き型に近いので、とっつきやすいのではないでしょうか。
 なかなか面白い言語ですし、エリクソン他で使用されている実績もありますので、普及して欲しい言語の1つです。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

北朝鮮の脅威
2009/04/12(Sun)00:56:04
 北朝鮮の「衛星」問題について、私はかねてから過剰に騒ぐべきでないと考えてきました。この自称「衛星」が本当に人工衛星なのか、衛星の名を借りたミサイルなのかは判明していませんが、いずれにしても北朝鮮の狙いは技術力の誇示や恫喝とみられますので、過剰反応を避けるべきは変わりません。
 ただ、私が今回の件で最も恐れたものは、北朝鮮のミサイルや恫喝外交ではありません。北朝鮮のミサイルなどは相手にしなければ空騒ぎに終わりますし、実際に国民の多くは大して気にもしていなかったようですが、「内憂」となるとそうはいきません。恐れるに足りない北朝鮮の恫喝をダシにして、日本の軍拡や核武装、その他北朝鮮の「手助け」なしには実現が困難なことを実現しようとする勢力こそが、私が最も憂慮した存在です。
 そして、この予想は見事なばかりに的中してしまいました。自民党の坂本組織本部長が「日本も核を保有すると言ってもいい」などと発言し、さらには国連脱退にまで言及するなど、非常に典型的な主張を行ったのです。いくら予想していたとはいえ、今の自民党は発言にも多少は敏感になっているはずであり、北朝鮮をダシにするにしてももう少しひねりのある方法を使うのではないかと考えていましたので、あまりにも直接的な物言いには少々驚きましたが、いずれにしても頭が痛い問題であることに変わりはありません。なお、氏はすぐに「たとえ話」との釈明を行っていますので、少なくとも表立って核武装論を主張していくわけではなさそうです。
 かねてから、北朝鮮の卑劣な「外交カード」は、そのまま防衛族や軍拡論者の内政カードとしても使われてきました。以前に防衛庁が省に昇格したことがありましたが、これなどはまさに「北朝鮮の脅威」の賜物でしょう。北朝鮮問題があってもなくても昇格は当然との意見は尊重しますし、賛成派がそのような意見ばかりなら問題はありませんが、中には明らかに北朝鮮を利用しているとしかみられないような主張もあり、改めて「北朝鮮の脅威」の真の恐ろしさを実感させられたものでした。北朝鮮を利用して意見をごり押しし、否定する人には「北朝鮮の脅威が見えないのか」と恫喝するようなやり方は、北朝鮮の恫喝外交の内政版といえるでしょう。
 最近話題のMDシステムにしても同様です。命中率に極めて難があり、守備範囲も大変に限定されており、しかも肝心の発射情報すら当てにならないなど、ほとんど役に立たないにもかかわらず、非常に多額の費用をかけて導入されています。このようなものは往々にして利権化する危険をはらんでいますので、利権の温床になってしまう可能性も否定できません。MDは「北朝鮮の脅威」のおかげで大した議論もなく導入されてしまいましたが、実際には費用対効果の面から詳細な検討を行い、採用するにしても国民にMDの正確な情報を公開すべきでした。
 なぜこの「北朝鮮の脅威」が、上記のような軍拡論や利権に容易に利用されてしまうのかといいますと、まずは何より騒ぎ過ぎに他なりません。今回の「衛星」にしても、実際には日本に全く被害を与えておらず、単に北朝鮮が多額の費用を海に沈めただけにもかかわらず、すさまじいまでの騒ぎようでした。国民の中には冷静に問題を見ていた人も少なくないようですし、「MDは当たるわけがない」「ゴルフならファー」などののんきな発言にも現れている通り、国も全くあわてていなかったようですが、マスコミや一部の国民は派手に騒いでいたようです。
 確かに北朝鮮の行為は許されないものですし、それに怒りを持つのも当然の感情とはいえますが、それならそれで冷静に状況を見つつ、粛々と制裁などの行動を行えば済むことです。政治家や利権者の中には、本件が騒ぎになって欲しいと考えている人がいる点を忘れてはいけません。一部国民やマスコミがその思惑に乗ってしまった結果が、今回のような「核保有して国連脱退」なる主張なのです。無論、私は個人的には両方に反対するものの、核武装や国連脱退を主張するのは自由と考えていますが、それならそれで北朝鮮をダシにするのではなく、正々堂々と案の正当性を訴えるのが論客というものです。
 そして何より、北朝鮮問題にいちいち過剰反応する行為は、北朝鮮問題の解決を遠ざけかねない側面を持っています。逆説的なようですが、これこそが私が「騒ぎ過ぎ」を警戒する最大の理由です。北朝鮮問題を最大限利用したい政治家や利権者にとっては、北朝鮮には今後とも問題を起こしてもらっていた方が有利なのですから、問題の根本的解決を望むわけがありません。それはミサイルや核の問題にしてもそうですが、拉致問題もまた同様です。一見するとふざけた意見のようですが、言ってみれば軍需企業が有事を心待ちにしているのと同じです。
 また、似た概念のものとして「軍縮論」にも注意が必要です。北朝鮮の問題を利用して軍拡論を唱える人間の対角線上には、MDなり過剰反応なりを利用して軍縮を唱えようとする人間も必ず現れますが、これも北朝鮮を持論の実現のために利用している点では同じです。これは意見としては少数派ですので、軍拡論ほどの危険性はなさそうですが、当然ながら私はこの両者に賛同しません。
 逆に、北朝鮮が何らかの問題を起こしても、国民が極めて冷静に物事を見ていれば、政治家や利権者はこれを世論操作に利用できなくなり、北朝鮮を放置するうまみはなくなります。したがって、国民が物事を沈着冷静に判断し、騒ぎに乗せられないようにすれば、北朝鮮問題の解決が早まる可能性があります。
 ただし、北朝鮮問題を冷静に判断することと、北朝鮮問題を忘却することは正反対である点に注意が必要です。世論が北朝鮮問題に関心を持つのは非常に重要で、特に拉致問題の解決には世論の力が必要であると横田さんらも強調しておられました。国民が北朝鮮問題に無関心であれば拉致は解決しませんし、かといって関心を持っていても冷静さを持ち合わせていなければ、日本の一部政治家や利権者に利用されて終わりです。
 特に拉致問題は何が何でも解決しなければならず、必要なら制裁強化などもためらうべきではありません。しかし、過剰反応こそ北朝鮮及び問題解決を遅らせたい政治家・利権者の狙いであることを忘れてはいけません。

 無駄極まりない金配り政策が行われてしまって久しいですが、ここへきて追加経済政策の与党案がまとまったようです。これまでに当ブログでも数回ほど取り上げてきた贈与税減税については、住宅購入にのみ500万円の免除を認める方針です。また、企業の研究開発費の法人税控除額を拡大するなど、いくつかの減税策もセットになっています。
 贈与税については、ひとまず数千万円が無条件で、あるいは不動産などの資産に変えた上で無税で贈与される可能性がなくなっただけマシではありますが、決して賛同はできません。上限が500万円であれば、金持ち優遇色はある程度薄まったとはいえますが、所詮は需要の先食いが発生するだけであって、決して消費が拡大するわけではありません。需要先食いのために500万円を非課税にする行為が、果たしてまともな経済政策といえるのでしょうか。
 仮に需要の先食いであったとしても、どうしてもこの策を導入しなければならないというのであれば、もっと金持ち優遇要素を薄める方法はあるはずです。例えば、まず500万円を非課税とする代わりに、その額を毎年の贈与税の非課税分に充当し、充当し切れなかった分は相続税に加算する方法などが考えられます。贈与税の通常の非課税額を60万円と置くなら、特別枠で500万円の贈与を受けた翌年に1円も贈与を受けなければ、60万円をそこで贈与したものとみなし、残額を440万円とします。一方、非課税分を上回る贈与があった場合には、1円の充当も行わず、残額は500万円のままとします。このようにして毎年充当を行っていき、相続が生じた時点で残額を相続額に加算して税を計算します。この方法であれば、相続税の対象になるほどの資産はないものの、ある程度の金額の贈与を受けたい庶民には便利ですし、金持ちは相続税逃れができなくなります。
 ところで、景気回復策については多くの論者が様々な意見を主張しているようですが、このほど読売新聞のサイトでこのような意見を見つけました。日本経済研究センター理事長の深尾光洋氏の論です。新聞社の提言の中では、論説委員の論評は全く当てになりませんが、これは専門家の提言ですので、見るべきところは多そうです。
 上記は新聞社のサイトへのリンクであるため、保存期間が切れた後には見られなくなる可能性がありますので、まずは簡単な概略を載せておきましょう。まず今後の展望については、このままデフレが進行する可能性が高いとした上で、公共投資や量的緩和政策なども抜本的な対策にはなり得ないとしています。つまり、従来型の経済対策では限界があると主張されているようです。
 そこで提言されているのが、個人資産への課税です。日本の個人資産は1500兆円もあるとされていますので、現金資産に対して2%の課税を行うのだそうです。1500兆円の2%ですから、単純計算で30兆円の税収が期待できます。ただし、課税を行うのは現金と預金、国債のみで、株や不動産といった「政府によって価値が保証されていないもの」には課税を行わないとしています。これにより、株や不動産に資産が流れる効果が期待できるようです。また、銀行も手元に金を置いていると税がかかるため、貸し出しも促進できるとしています。
 ただし、これでは弱者からも2%が取り立てられてしまいますので、国内の在住者全員に定額を給付して逆進性を回避するとしています。また、預金に対して課税するのは可能としても、現金に課税するのは困難そうですが、例えば紙幣の色を変えるなどして、旧1万円紙幣には200円を足さなければ新1万円紙幣に変えられないようにすれば、これにも対応できるようです。
 しかし、これは確かに大胆ながらも面白い案なのですが、私は少々賛成しかねます。まず、記事中では個人資産1500兆円のうち2%の30兆円程度が税収となると試算されており、かつ課税を避けるために株や不動産に金が流れるともしていますが、これらは二者択一です。一部が不動産や株に流れれば、税収は確実に減少します。仮に1500兆円のうち200兆円もそちらに流れれば、税収自体は4兆円も減少します。
 それなら株や不動産に多額の資産が流れるから問題はないとの意見も出そうですが、ここで金持ちと庶民の投資可能財産の差が浮き彫りになってきます。金持ちは投資に使用できる資産が格段に多いため、それを安定的な銘柄や現金以外の資産に分散投資したり、そのような投資信託を利用したりといったことができます。確かに投資額は増えるものの、安定的な投資に流れるに過ぎないため、課税逃れ以外の効果はほとんどないと考えるべきでしょう。一方、庶民には数多くの安定的銘柄に分散投資などといった芸当は難しいため、同様の行為は困難です。したがって、課税は逃れられてしまい、市場もさほど活性化はせず、あまり効果は見込めないとみるべきでしょう。ただ、国債に課税されるのであれば、国債を含む安定的投信が国債から株に鞍替えし、それによって資産が流入する可能性はあるともいえます。
 また、現金や預金に対して課税するのであれば、企業の資金の扱いはどうなるのでしょうか。企業はある程度の資産を留保しておく必要がありますし、それが余剰資産の必要な業界ならなおさらです。ここから資産を2%も抽出しようものなら、混乱発生は見えています。まさか何も考えずに有価証券や設備投資につぎ込んで良いわけはありませんし、株価にも何らかの影響が出ると考えられます。社債償却用や配当用、設備の修理や新規購入用の引当金からも公平に2%を取ってしまえば、企業の経営計画は頓挫します。
 かといって、企業を例外としようものなら、それが課税逃れに利用されるのは見えています。金持ちが資産を企業に退避させれば、この案の有効性は大幅に下がります。また、個人事業(自営業)では「引出金」として金を引き出したり、あるいは事業に個人資産を繰り入れたりといったことが容易になっていますが、この場合の課税をどうするかも問題点の1つとなります。もし企業の資産が非課税となるのなら、個人事業の事業資金に課税されるのは不公平となるでしょう。しかし、個人事業は株式会社などと比べて個人資産と事業の資産との境界があいまいですので、その面での問題が残ります。
 個人資産課税自体は必ずしも悪いアイデアとはいえませんが、この通り問題が多すぎます。税の多くは「入口」か「出口」に課税され、保持しているもの自体には課税されない場合がほとんどであるため、このような混乱が発生するのでしょう。現実的には、これを入口または出口に置き換えた課税、例えば「10年の時点で持っていた資産には、最初に贈与または相続する際に莫大な税を課す」など、他の手法を使用するしかないでしょう。相続税と贈与税の税率を大幅に上げつつも、それらが減免される税減免付き無利子国債を、市場での売買に制限をつけた上で、莫大な率の打歩発行で作るのも良いかもしれません。これならどう転んでも課税逃れはできませんし、無利子ですので長期保有されても国は被害を受けません。

 今回はQRコードの基本構造について。
 QRコードを眺めると、まず目に付くのが左上、左下、右上にある変なマークです。これはいかなるQRコードにも存在しているようです。



 それから、QRコードによっては存在していない場合もありますが、右下にはそのマークの縮小版のようなものが見えます。ちなみに、ピクセル数が最も少ないタイプのコードには存在せず、ある程度より大きくなると複数現れるのですが、最も小さいものではデータ量が非常に限られ、ある程度以上大きいものになると携帯電話では読み取れなかったりするため、右下にこれが1つある場合が多いようです。
 後はすべてデタラメのようですが、よく目を凝らして見てみると、左または上から数えて7ピクセル目の部分から、右または下に向かってシマ模様が続いていることが分かります。
 これらはいずれもQRコードに必要なもので、コードの大きさによって位置や個数が変わるものもありますが、基本的には同じパターンが現れます。いずれも何のデータも表さない、読み取り機の利便のために作られたパターンです。したがって、同じ大きさのコードである限り、いかなるデータ内容でも必ず同じ模様が現れます。
 以下に簡単な説明を記しておきます。なお、以下で述べられている計算式は、いずれも私が実物を見比べて考えたものであり、もっと良い式がある可能性もあります。


バージョン1のコードの例


バージョン2のコードの例


バージョン7のコードの例

※QRコードは白黒のコードですが、ここでは説明のために色をつけてあります。色のついたコードの使用は推奨されていませんので、実際のコードは白黒で作成すべきです。

 QRコードの大きさは「型番」あるいは「バージョン」と呼ばれる数値で表されます。1〜40までがあり、バージョン1が21x21、バージョン2が25x25といった具合に、4x4ずつ増えていきます。1辺のピクセル数は「17 * バージョン」で求められ、バージョンが増えるごとに格納可能データ量も増えていきます。

位置検出パターン
 左上、左下、右上の7x7のパターンです。画像では青色の部分に当たります。これはすべてのQRコードに存在し、タテ・ヨコ・ナナメのどの方向から見ても1:1:3:1:1の比率であるのが重要なのだそうです。

分離パターン
 位置検出パターンの周囲には1ピクセル分の空白が必要となっています。これが分離パターンです。これもあらゆるコードで必須のパターンですので、結果的に位置検出パターンは分離を含めて8x8を占拠することになります。

位置補正パターン
 画像では緑色の、位置検出パターンを小さくしたような5x5のパターンです。個数はバージョンによって違います。私が全バージョンを見比べて計算したところでは、1辺の位置検出及び補正パターンの合計個数は「バージョン / 7 + 2」で求められます(割り算は小数点切り捨て)。ただし例外として、バージョン1のコードには位置補正パターンはありません。
 この計算式を実際に使用してみると、バージョン2〜6では「バージョン / 7 = 0」となり、0 + 2 = 2で1辺に2つ、すなわちコード全体では2 * 2 = 4の位置検出及び補正パターンがあると分かります。うち3つが位置検出パターンと決まっていますので、位置補正パターンは4 - 3 = 1個となります。バージョン7〜13では1 + 2で1辺に3つ、すなわちコード全体では3 * 3 = 9となります。うち3つが位置検出パターンですので、3を引いて補正は6個です。14〜20では4 * 4 - 3 = 13個です。
 バージョン7以降ではタイミングパターンと重なるものが出てきます(黄色部分)。

タイミングパターン
 画像では赤色の、右及び下方向に連なるシマ模様です。上述の通り、バージョン7以降では位置補正パターンと重なる部分が出てきます(黄色部分)。どちらでも同じ模様になるのが面白いところです。

形式情報
 位置検出パターンの周囲に存在する、マゼンタの部分です。データ自体は5ビットなのですが、エラー訂正に10ビットのBCH符号が使用されており、データは15ビットとなっています。15ビットの中身は左上の周囲にすべて記録されており、それと全く同じものが右上に8ビット、左下に7ビットと2つに分割して記録されています。これによって、左上のデータが破損していても、他の部分から復元できます。
 データの内訳は、エラー訂正レベル(L、M、Q、Hの4種類)とマスクパターン(8種類)の指定となっています。

固定黒パターン
 左下の水色の部分です。ここは必ず黒となります。型番情報は15ビットで、右上に8ビット、左下に7ビットを記録するとなると、左下には1ビット分の余白が出てしまいますので、ここを黒に固定しているのでしょう。

型番情報
 バージョン7以降にのみ必要です。画像ではオレンジ色の部分で、3x6の18ビットです。右上と左下に1つずつあり、内容は全く同じです。データ自体は6ビットなのですが、エラー訂正に12ビットのBCH符号が使用されています。データとしてバージョンが格納されています。

内容
 上記以外の部分に内容が格納されています。データの中身とエラー訂正符号の両方を含みます。「マスク」はこの部分にのみ適用されます。

クワイエットゾーン
 コードの周囲4ピクセル以上は、何もない白の領域としなければなりません。

 また、QRコード生成時には以下のようなデータを定めなければなりません。

バージョン
 前述の通りです。バージョンが増えるとデータ量は増えるものの、特に携帯電話ではあまり大きなバージョンには対応していませんので、ほどほどにしておく必要があります。

エラー訂正レベル
 L、M、Q、Hの4種類があります。Lは7%、Mは15%、Qは23%、Hは30%程度の破損を回復できますが、レベルを上げれば上げるほどデータ内容におけるエラー訂正部分が大きくなり、記録可能なデータ量は減少します。汚損が多い媒体ではレベルを上げるなど、印刷または表示する媒体によって使い分けるべきとされているようです。

マスク
 データの白または黒の部分が偏っていたり、位置検出パターンに似たようなパターンが出現していると、読み取りの精度が低下してしまいます。これを避けるのがマスクで、あらかじめ用意された0〜7までの8パターンのうち、いずれかのマスクを必ず適用しなければなりません。なお、どのマスクを適用すべきかは、仕様書に「失点法」による選択方法が明記されていますが、実際にはどのマスクを適用しても動きます。それぞれのマスクの計算式や形状は、仕様書に列挙されています。

 以下に各種データをまとめた表を示します。今のところは意味不明なデータの羅列ですが、後々のデータ内容生成・書き込み時、あるいはバージョン1よりも大きなQRコードを作成する際には必要な資料です。これらのほとんどのデータは仕様書にも記載されていますので、そちらを参照しても構いません。ただし、仕様書のデータには一部に誤りがあり、正誤表PDFが出されていますので、注意が必要です。以下の表は訂正後のデータを用いています。

バージョンごとのサイズ、パターンのリスト
バージョンとエラー訂正レベルごとのデータ容量・RSブロックのリスト
エラー訂正コード生成用の生成多項式一覧

 概念はこの辺りまでとして、実際にコードを作成してみましょう。ここではひとまず、データ内容の書き込みは後回しにして、パターンの部分のみを作成してみます。
 まず、バージョンとエラー訂正レベルを決定します。ここではバージョン1、エラー訂正レベルLを使用します。それから、本来マスクは後で選択するものなのですが、形式情報を作成するには必須のものですので、ここで定めておきます。0〜7までありますが、ここでは単純に0を使用するものとします。
 それでは早速作成といきたいところですが、まずはデータの表現方法を考えます。QRコードではデータを白または黒で表すため、値自体は0と1だけで表現できるのですが、ここで後々書き込むデータ内容は「必須となるパターンが配置されていない部分」に格納されることが重要になってきます。つまり、パターンを単に白または黒のいずれかとして扱ってしまうと、どこがパターンを書き込んだ部分で、どこが書き込んでいない部分かの区別がつかないのです。これでは、後々符号化するデータを書き込もうとした際に、コード内のどこにデータを書き込んで良いものか分かりません。
 そこで、単なる白黒の判断とは別に、パターンを書き込んだ部分であるか、書き込んでいない部分(いわば透明の部分)であるかを判断する必要が生じてきます。すなわち、実質的には3つの状態があると考えられます。したがって、0と1以外の「第三の値」を使用するか、ビット格納用変数とは別に管理用の変数を導入する必要があります。ここでのサンプルコードでは、透明用の値として「-1」を使用しています。
 バージョン1のQRコードを作成するには、最低限以下のような作業が必要です。ピクセル座標は左上を0,0として述べます。

0.サイズを計算する
 下準備の範疇です。これがなくては、パターンを配置すべき場所を決定できません。とはいえ、単に17にバージョン*4を足すだけです。バージョン1なら21となります。

1.位置検出パターンを作る
 これは比較的簡単です。先ほどの画像では青色の部分に当たる7x7のパターンを、左上、左下、右上に書き込むだけです。7x7のパターンを作る機能を関数化しておいて、それを3度呼び出すようにするのが簡単です。

2.分離パターンを作る
 単に上記7x7の周囲を白にするだけです。とはいえ、位置検出パターンはいずれもコード端に位置するため、例えば左上の位置検出パターンに対しては、その左側と上側へは分離パターンを書き込まないようにしなければなりません(左端のパターンはx座標が0の位置にあるわけですから、それの左側は-1になります)。それにさえ気をつければ、やや面倒ではありますが、さほど難しいものではありません。

3.位置補正パターンを作る
 バージョン1には存在しませんので、まだ実装する必要はありません。これがなかなか厄介ですので、ここで作っても混乱します。次の機会に実装するとしましょう。

4.タイミングパターンを作る
 位置が決まっているため、実装自体は難しくありません。まず横方向へのタイミングパターンを考えます。タイミングパターンの開始部分は8 , 6の部分で、黒と白を交互に横に並べた上で、size - 9 , 6の部分で終了しています。縦方向へのパターンは、これのxとyが逆転しているに過ぎません。x = 8から開始し、x < size - 8までループすれば簡単です。

5.固定黒パターンを作る
 これは完全に固定である上、1ピクセルしかないので簡単です。8 , size - 8に黒パターンを1つ打つだけです。

6.形式情報を作る
 これが今回の難関です。実装にはBCH符号が必要となります。また、ビット処理の知識も必要となります。少々厄介ですが、BCH符号さえ実装できれば、それほど難しくはありません。
 以下のような手順が必要です。

1.マスク番号とエラー訂正レベルから、元のデータ5ビットを作成する
 マスクに関しては、0〜7の値をそのまま使うだけです。エラー訂正レベルについては、以下のようにビット値が定められています。

レベル 10進表記 2進表記
L 1 01
M 0 00
Q 3 11
H 2 10

 これを、「(エラー訂正レベル << 3) | マスク」のビット演算で5ビット値とします。今回の場合、エラー訂正レベルはLですので「01」で、マスク番号は「0」、2進値3桁表記にすると「000」ですから、これをつなげて「01000」が5ビットのデータとなります。

2.ここで得られた値にBCH符号10桁を加え、15ビットのデータにする
 BCH符号については、日本中で最も数学能力が低い実装者によるQRコードBCH符号実装をご覧ください。いちいち実装するのが面倒なら、ここにある変換テーブルをそのまま使っても構いません。32個しかありませんので、それで十分です。書かれている手順に沿って「01000」のBCH符号を作るなり、表の該当部分を見てみるなりすると、値「1111010110」が得られます。
 この2つをつなぎ合わせて、値「010001111010110」を作成します。

3.マスク「101010000010010」をかける
 単なるXOR演算です。なお、マスクの値は仕様で定められているもので、特に何らかの意味があったり、バージョンによって変化したりといったことはありません。いかなる場合も必ずこのマスクを適用します。
 結果として「111011111000100」を得ます。

4.これをコード上に配置する
 15ビットのデータのうち、15ビットすべてを左上に配置し、下位8ビットを右上に、上位7ビットを左下に配置します。画像でいうマゼンタの部分です。配置方法は以下の画像のようになります。


(左上)


(右上)


(左下)

 先ほどのコード同様、青色の部分が位置検出パターン、赤色がタイミングパターン、水色が固定黒パターンです。ここまでで得られた15ビットを数字の通りの順番に配置します。ただし、0が最下位ビット、14が最上位ビットです。式に置き換えれば「(15ビットの値 >> 数字) & 1」となります。
 今回は「111011111000100」を配置するのですから、0の部分は0、1の部分も0、2の部分は1、3の部分は0といった具合になります。

 これでようやく形式情報は完成です。

7.型番情報を作る
 画像ではオレンジ色の部分です。バージョン7以降でのみ必要なものですので、今回は作る必要はありません。こちらは6ビットのデータをBCH符号にかけて18ビットのデータを作り、それを右上と左下に配置するものとされています。配置の方法自体は形式情報より簡単です。これも次の機会に取り上げましょう。

 これをすべて行って、ようやく必要なパターンが生成できます。やや大変ではありますが、実装自体は面倒なだけで難しくありません。
 以下に実装例のPHPコードを示します。あくまで実装例に過ぎませんので、最終的に同様の結果が得られるのなら、いかなる実装でも構いません。
<?php
// BCH 符号を生成するクラス
class BCHCode{
	private static $bch_5 = null;
	private static $bch_6 = null;

	private $r;
	private $len;

	function newInstance($len){
		if($len == 5){
			if(self::$bch_5 == null){
				self::$bch_5 = new BCHCode($len ,
					(1 << 10) | (1 << 8) |
					(1 << 5) | (1 << 4) |
					(1 << 2) | (1 << 1) | 1);
			}
			return self::$bch_5;
		}
		if($len == 6){
			if(self::$bch_6 == null){
				self::$bch_6 = new BCHCode($len ,
					(1 << 12) | (1 << 11) |
					(1 << 10) | (1 << 9) |
					(1 << 8) | (1 << 5) |
					(1 << 2) | 1);
			}
			return self::$bch_6;
		}
	}

	protected function __construct($len , $r){
		$this->len = $len;
		$this->r = $r;
	}
	function makeBCH($data){
		$base = $this->len * 2;
		$data <<= $base;

		for($i = $this->len - 1; $i >= 0; $i--){
			if(($data & (1 << ($i + $base))) != 0)
				$data ^= $this->r << $i;
		}

		return $data;
	}
}

// QRコードのピクセル管理用クラス
// 透明は -1 として処理している
class QRPixel{
	private $size;
	private $pixel;

	function __construct($size){
		$this->size = $size;
		$this->pixel = array_pad(array() , $size ,
			array_pad(array() , $size , -1));
	}
	function getSize(){
		return $this->size;
	}

	function getPixel($x , $y){
		if($this->pixel[$y][$x] == -1)
			return 0;
		return $this->pixel[$y][$x] & 1;
	}
	function setPixel($p , $x , $y){
		$this->pixel[$y][$x] = $p & 1;
	}
	function isExist($x , $y){
		return $this->pixel[$y][$x] != -1;
	}
}

// QR コードを生成するクラス
class QRCodeCreator{
	private $version;
	private $ecc;
	private $format;

	function __construct($ver , $ecc){
		$this->version = $ver;
		$this->ecc = $ecc;
		$this->format = new QRPixel(17 + $this->version * 4);
	}

	// 位置検出パターンと分離パターンを作成する関数
	function createFinderPatterns(){
		$size = $this->format->getSize();

		$this->createFinderPattern(0 , 0);
		$this->createFinderSeparator(0 , 0);

		$this->createFinderPattern(0 , $size - 7);
		$this->createFinderSeparator(0 , $size - 7);

		$this->createFinderPattern($size - 7 , 0);
		$this->createFinderSeparator($size - 7 , 0);
	}

	// 位置検出パターンを任意の位置に作成する関数
	function createFinderPattern($x , $y){
		$pixel = $this->format;

		for($py = 0; $py < 7; $py++){
			for($px = 0; $px < 7; $px++){
				$p = 1;
				if(($px >= 1 && $px <= 5 &&
					($py == 1 || $py == 5)) ||
					($py >= 1 && $py <= 5 &&
					($px == 1 || $px == 5))){
					$p = 0;
				}
				$pixel->setPixel($p , $x + $px , $y + $py);
			}
		}
	}

	// 分離パターンを任意の位置に作成する関数
	function createFinderSeparator($x , $y){
		$pixel = $this->format;
		$size = $pixel->getSize();

		$left = $x - 1 >= 0;
		$top = $y - 1 >= 0;
		$right = $x + 7 < $size;
		$bottom = $y + 7 < $size;

		// 辺のピクセル
		for($d = 0; $d < 7; $d++){
			if($left)
				$pixel->setPixel(0 , $x - 1 , $y + $d);
			if($right)
				$pixel->setPixel(0 , $x + 7 , $y + $d);
			if($top)
				$pixel->setPixel(0 , $x + $d , $y - 1);
			if($bottom)
				$pixel->setPixel(0 , $x + $d , $y + 7);
		}

		// 角のピクセル
		if($left && $top)
			$pixel->setPixel(0 , $x - 1 , $y - 1);
		if($left && $bottom)
			$pixel->setPixel(0 , $x - 1 , $y + 7);
		if($right && $top)
			$pixel->setPixel(0 , $x + 7 , $y - 1);
		if($right && $bottom)
			$pixel->setPixel(0 , $x + 7 , $y + 7);
	}

	// タイミングパターンを作成する関数
	function createTimingPattern(){
		$pixel = $this->format;

		$p = 1;
		for($d = 8; $d < $pixel->getSize() - 8; $d++){
			$pixel->setPixel($p , $d , 6);
			$pixel->setPixel($p , 6 , $d);
			$p ^= 1;
		}
	}

	// 固定黒パターンを作成する関数
	function createBlackPattern(){
		$pixel = $this->format;
		$pixel->setPixel(1 , 8 , $pixel->getSize() - 8);
	}

	// 渡された形式情報15ビットを書き込む関数
	function createInformation($info){
		$pixel = $this->format;
		$size = $pixel->getSize();

		$lower = $info & ((1 << 8) - 1);
		$higher = ($info >> 8) & ((1 << 7) - 1);

		$y = 0;
		for($i = 0; $i < 8; $i++){
			$p = ($lower >> $i) & 1;

			if($y == 6)
				$y ++;

			$pixel->setPixel($p , 8 , $y);	// 左上
			$pixel->setPixel($p , $size - 1 - $i , 8);	// 右上
			$y ++;
		}

		$x = 7;
		for($i = 0; $i < 7; $i++){
			$p = ($higher >> $i) & 1;

			if($x == 6)
				$x --;

			$pixel->setPixel($p , $x , 8);	// 左上
			$pixel->setPixel($p , 8 , $size - 7 + $i);	// 左下
			$x --;
		}
	}

	function getQRFormat(){
		return $this->format;
	}
}

$version = 1;	// バージョン
$mask = 0;	// マスク番号
$ecc = 1;	// エラー訂正レベル

// バーコードの作成
// バージョンとエラー訂正レベル(今回は01)を指定
$creator = new QRCodeCreator($version , $ecc);
$creator->createFinderPatterns();	// 位置検出パターンを生成
$creator->createTimingPattern();	// タイミングパターン
$creator->createBlackPattern();	// 固定黒パターン

// 形式情報15ビットを作成し、マスクをかけてから書き込み
$info = (1 << 3) | $mask;
$creator->createInformation(
	(($info << 10) |
	BCHCode::newInstance(5)->makeBCH($info)) ^
	((1 << 14) | (1 << 12) |
	(1 << 10) | (1 << 4) | (1 << 1)));

// 結果を得る
$pixel = $creator->getQRFormat($mask);

// テーブルとして表示
print '<table border="0" cellpadding="0" cellspacing="0">';
for($y = 0; $y < $pixel->getSize(); $y++){
	print '<tr>';
	for($x = 0; $x < $pixel->getSize(); $x++){
		$color = $pixel->isExist($x , $y) ?
			($pixel->getPixel($x , $y) == 0 ?
			"#FFFFFF" : "#000000") : "#CCDDFF";
		print '<td bgcolor="' . $color .
			'" width="4" height="4"></td>';
	}
	print '</tr>';
}
print '</table>';
?>
 以下のような結果が得られれば成功です。ただし、この画像では透明部分を薄い青として表示しています。



 これで原型は出来上がりです。後はこれにデータを書き込み、マスクをかければ完成です。データ書き込み以降は次の機会としましょう。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

第三の道・封建主義
2009/04/05(Sun)00:14:25
 このブログでも何度か取り上げてきた「無利子非課税国債」や「期限付き贈与税減免措置」ですが、前の段階ではせいぜい自民党議員の私案の域を出ておらず、具体的な条件もほとんど明らかになっていないなど、実現されるかどうかは微妙な状態でした。ところが、どうやら自民党はこれらを本気で検討しているらしく、本当に実現する恐れが出てきました。追加経済対策の1つとして盛り込まれる可能性があるようです。また、もしこの段階で導入が見送られたとしても、解散が次々と先延ばしにされていけば、解散までに導入されない保証はありません。
 さすがに単なる贈与税減免では景気刺激にならないとの考えか、あるいは世論の批判をかわすための手段かは定かではありませんが、贈与された財産を家や車の購入などに消費することを減免の条件とするようです。また、減免措置の適用期間がどの程度になるのかは定かではありませんが、数年以内であると考えられます。
 確かに、贈与財産の使い道を消費に限定すれば、見かけ上は消費拡大効果が得られる可能性も十分に考えられます。試算によって消費拡大効果をはじき出すのは容易でしょうし、万が一実施されてしまった場合でも、効果を有意に示すような結果が得られることは十分に考えられます。しかしながら、このようなものは単なる子どもだましに過ぎません。自民党が経済対策に同案を盛り込み、しかも消費拡大効果を示すような試算が出ていたとしても、それは金配りの経済効果の試算以上に信用ならないと見るべきです。
 まず念頭に置くべきは、庶民を救済するための贈与税減税と、金持ち優遇のための贈与税減税とでは、全く性質が違うという点です。住宅購入のために百万円単位を上限に減免するのであれば、それは庶民向けの減免措置の範疇に含まると考えて差し支えありませんが、この上限が庶民向けの何倍もの額ともなれば、それはもはや庶民向けの対策とはいえません。現在検討されている減免措置が明らかに後者に属することは以前の記事で述べましたが、いくら減免対象を消費に限ったとしても、この問題は一向に解消されません。
 家や車といった多額の買い物は、庶民にとっては実用上のものである場合がほとんどです。高級車を何台も保有していたり、住居とするには明らかに豪華すぎる家を数戸も持っている人は、到底庶民とは呼べませんし、まさに相続税に縁があるような人々でしょう。逆に言えば、非課税国債などで相続税を減免したり、多額の贈与税減免措置の恩恵にあずかれるのは、このような層のみであるといえます。
 庶民向けに住宅関連の減税を行えば、それは住居購入費用の足しとなるでしょう。しかしながら、金持ちに対して同様の措置を実行したところで、庶民の場合と同様の結果にならないのは見えています。すなわち、金持ちの固定資産が1つ増えるだけなのです。最悪の場合、そうして購入した財産を数年のうちに売却し、実質無税で贈与がなされてしまう可能性があります。仮にそれを禁じたとしても、抜け道など考え付く限り無限にありますので、抑止は不可能と見るべきです。このような優遇を行うために、本来入るはずであった相続税を捨て去り、しかも封建制を推進するなど、全くバカげた方策と言わざるを得ません。
 また、そのような事態にまでは至らなかったとしても、どのみち見かけ以上の消費拡大効果は期待できません。もとより家や車などを買うつもりであった人が、あえて贈与を利用してそれらを購入すれば、贈与額を丸々無税で受け取ったのと同等の効果が得られます。違いといえば、せいぜい家を買う時期が数年早まる程度のものでしょう。これによって一時的に効果があるように見えたとしても、単に需要を先取りするだけに過ぎませんので、最終的な消費額はほとんど変わりません。唯一の大きな違いといえば、金持ちが税を払わずに多額の資産を贈与できることだけです。
 もし何としても金持ちの個人資産を還流したいのであれば、逆のアプローチを考えるべきでしょう。すなわち、例えば相続税及び贈与税を増税する相続税法改正案を作り、それを数年後に適用するものとします。税率が10%や15%の部分は据え置きとし、40%や50%といった高額部分のみを増税するなどして、数億円以上もの個人資産を持つ金持ちのみを対象とすれば、ほとんど混乱なく導入できるでしょう。もしこのような法律が導入されれば、わざわざ無税などというニンジンをぶら下げなくても、金持ちは自主的に贈与なり消費なりを行うはずですから、消費拡大効果が期待できます。また、仮にそれが消費拡大に結びつかなかったとしても、相続税や贈与税の増加が期待できますし、下手に封建制を推進する恐れもありません。
 あるいは、需要の先食いであっても今の消費を増やしたいのであれば、流動資産のみ通常より高率の相続・贈与税率を適用するようにすれば、一時的にせよ消費が増えるでしょう。消費を増やすことだけが目的なら、単に相続・贈与税を増やして相続のメリットをなくし、一部の金持ちの老人が消費拡大を行うように仕向けるのも手です。
 いずれにせよ、相続税・贈与税を減免して一部の金持ちを焼け太らせ、格差の固定化と封建制を推進するような行為は下策中の下策であると言わなければなりません。仮に一時的に効果があるように見えたとしても、それは単なる需要の先食いに過ぎないか、あるいは流動資産を固定資産などの物品に変えただけに過ぎない可能性が高いのです。
 経済危機を免罪符にすれば、露骨な金持ち優遇でも見過ごされるなどと考えているのであれば、それは誤りというものです。自民党や政府は絶対にこのような策を実現すべきではありませんし、どうしても実現したいのであれば、政権公約に盛り込んで解散を行わなければなりません。ましてや、金配りのように再可決で実現させるような暴挙は、何がどうあっても行うべきではありません。

 以前にTBSの株を買い占め、ライブドアと似たような騒動を起こしていた楽天ですが、このほどTBSからの撤退を決定しました。楽天は買い占め当初「購入費の利子分は配当でカバーできる」と主張していましたが、TBS株の変動によって損失を抱えてしまい、TBSとの交渉が暗礁に乗り上げたこともあり、これ以上粘るのは得策でないと判断したようです。
 何にせよ、一連の攻勢が楽天に少なからぬダメージを与えたのは間違いありません。TBSとの交渉に失敗した上、ジリ貧となって不本意な撤退を迫られた点もそうですが、問題は何よりイメージです。本件は楽天のイメージを大きく傷つけたのではないでしょうか。
 楽天といえば、プロ野球騒動の際にもライブドアと並んで新球団保有に名乗りを上げたり、業種が似ていることもあって(ただしライブドアの稼ぎ頭は金融業)、ライブドアとの違いを強調しているような部分がありました。少なくない人々からひんしゅくを買い、しかも最終的には没落したライブドアとの差別化を図るのは、イメージの上でも当然の戦略ではあります。
 ライブドアといえば、まず連想するのがニッポン放送買収問題です。資金調達を引き受けたのがリーマン・ブラザーズで、時間外取引を指南した上に株を売り抜けて利益を得たのが村上ファンドと、色々と裏がある買収劇ではありましたが、結局ライブドアは没落し、恫喝して結んだ契約は解除となり、裏で暗躍していた村上氏は逮捕、資金調達元のリーマン・ブラザーズは破綻してしまいました。
 この一件をなぞるようにして発生したのが、楽天のTBS株買い占め問題でした。楽天が一体何のつもりでこのような行為に及んだのかは不明ですが、いくら理由をつけてみたところで、やっていることはライブドアとほとんど同じなのですから、良いイメージを持たれる方が無理というものです。ちなみに楽天といえば、フジサンケイグループがライブドアの買収攻撃にさらされた際、フジにホワイトナイト引き受けの連絡を入れるも、その言い分からライブドアと同じ狙いがあると見られて断られたという逸話があったよう記憶しています。
 一方、ライブドアや楽天が放送局に攻撃をかけた際には、放送業界の体質革新につながるとして、それを支持した人もいるようです。確かにマスコミの旧態依然ぶりはすさまじく、これを放置するのは日本のためにもなりません。非人間的あるいは捏造報道を行った上、それを少しでもとがめようものなら「報道の自由の侵害だ」などと言い出すのですから手がつけられませんし、コピーワンスやダビング10なる何の価値もないシステムを必死で守り抜こうとしているのもこの連中です。放送がデジタル化されたのも、もともとはデータをそのままインターネット配信できるなどのメリットを見越したもののはずなのですが、著作権処理の困難さもさることながら、放送局連中の意向に沿わないこともあって、ほとんど実施されていません。これを破壊しようとする人物がいるのであれば、支持を受けるのは当然です。
 しかしながら、ライブドアも楽天もそのような器ではありませんでした。今までの言動から察するに、両者とも結局は私利私欲で、放送を革新しようなどといった意思は二の次三の次であるとみられます。これでは買収に成功していたとしても、利権はほとんど一掃されないか、あるいは別の利権に置き換わるだけに終わっていたでしょう。ひとたび何らかの攻撃にさらされると、半ば破綻した論理や「報道の自由」を振り回してマインドコントロールを行おうとするマスコミにもあきれ果てますが、さすがにそのような世論操作には引っかからないにしても、楽天の行動にもまた評価すべき点が見当たりません。
 楽天の行動が厳密なグリーンメールに当たるかは不明ですが、少なくとも村上ファンドなどはグリーンメーラーであるとして、放送利権もグリーンメーラーも日本のためにはならないといったところでしょうか。
 ところで、本件については読売新聞が社説で総括らしきものを述べており、「「会社は株主のものだ」という米国流の考え方は、日本では支持を得にくいということだ」などと主張していますが、これもまた一方的な物の見方でしょう。米国ではポイズンピルや〜パラシュートなどの規定が用いられているところを、日本では毒薬条項すら判例がほとんどなく、発動例もブルドックソース程度しかない点を忘れてはいけません。この例では大半の株主が発動に賛成しましたが、実際にどのような条件で、どの程度の賛成があれば発動できるかは、未だにはっきりしていません。一方、先にTBSも買収防衛策を発動しようとしていましたが、こちらは「第三者」なる名目のアリバイ組織が判断するという極めて不公平なものでしたので、仮に本当に発動することが決定されたとしても、裁判でそれが認められる方が異常というものです。このように、日本は米国とは条件が違いすぎるのですから、安易に比較はできないと考えるべきでしょう。
 米国の慣習は良く分かりませんが、いくら会社は株主のものという合意があったとしても、市場でグリーンメーラーが歓迎されるものでしょうか。サブプライム問題において、ファンドまたはファンド同然の部門を持つ会社がバタバタと倒れたり、倒れかけて政府に助けを求めたりしていますが、それに対する米国民の反応がどうも芳しくない辺り、あまり歓迎されていない印象を受けますが、実際は違うのでしょうか。
 楽天が失敗した原因を総括するなら、慣習や理念以前に「グリーンメールまたは類似行為を行ったから」の一言でしょう。世界広しと言えど、おそらくどの国でも歓迎されないはずです。

 私は携帯電話というものが嫌いです。あのようなものに振り回される人、ことに若者が多いというのは、非常に深刻な問題です。若者を携帯電話漬けにしないためにも、政府も教育界も早急に手を打つべきでしょう。
 とはいえ、携帯電話の利便性についてまで否定するわけではありません。携帯電話害悪論を打ち出す気もありません。以前にチャットCGIを書いた際、通常のブラウザ用とDoCoMo/J-Phone(当時)用、それからau用のHDMLの3種類も書かなくてはならず、ひどい目にあったなどといった個人的な恨みは不問としましょう。携帯電話で害のあるコンテンツに触れられるなどというのは、携帯電話で使える害悪コンテンツなどたかが知れていますので、どうでも構いません。それより問題なのは、このようなオモチャに翻弄され、適応してしまったせいで、PCなど高度かつ応用力の高い技術の普及が妨げられかねない点です。昨今は若者の携帯電話依存が問題になっていますが、PCに比べれば携帯電話など話にならないのですから、PCの利便性を知る若者なら携帯電話ごときに依存するわけがありません。いくら性能が上がったとはいえ、所詮は狭い画面と劣悪なインターフェイスですし、性能は下手をすると「リアルモード」にすら劣ります。次世代の技術を支える若者が、携帯電話のごとき過去の遺物にすがっているようではいけません。
 余談はともかくとして、このところ「QRコード」なるものをよく目にします。以前の「数学能力の低い実装者」シリーズでも多少触れましたが、何やら怪しげな幾何学模様が描かれた、あのコードです。


バージョン3のQRコードの例

 何でも、これを携帯電話のカメラ機能で撮影すると、格納されたデータを読み出せるのだそうです。確かにあの劣悪すぎるインターフェイスでは、多少の文字列を入力するのにも相当な苦労をしなければなりませんので、重宝されるのは必然でしょう。基本的に「カメラなし、単体のインターネット機能最小限、外部機器のインターネット接続機能最大限」こそ長所と身分をわきまえた最上の携帯電話と考える私にとっては、あまり普及してほしくないものではありますが、普及してしまったものは仕方がありません。
 この「QRコード」なるものはデンソー(現デンソーウェーブ)が開発したもので、同社の特許となっていますが、同社は特許権を行使しないと明言しています。いつぞやのgif騒動のような問題が起きなければ良いのですが。ちなみにデンソーは部品製造大手で、あの景気が悪いと見れば派遣や下請けをゴミ箱に叩き込み、トヨタ出身で元経団連会長の奥田氏は「消費税を毎年1%ずつ上げて法人税は下げる」なる死の宣告プランを打ち出し、秋葉原の事件の加害者もここの派遣であったという日本が世界に誇るトヨタのグループ企業です。
 このようなものを見かけると、どうしても作ってみたくなるのが開発者の習性です。幸いにも鬼門であるRS符号及びBCH符号の作り方は分かっていますので、後はデータを作って配置する行為がメインとなります。ただ、これは決して難しい操作ではありませんが、色々と記入が必要で大変面倒ですので、今回は概念のみにとどめます。
 まずQRコードの仕様から。QRコードは最小で21x21、最大で177x177のピクセルを使用する2次元バーコードで、大量のデータを格納できるのが長所とされます。ちなみに177x177の場合、全部をデータに当てれば3916バイト分の表現が可能なのですが、実際には決まったパターンが随所に存在する他、エラー訂正用のコードを入れなければならないため、使えるコード量はこれより少なくなります。
 次に、QRコードに格納できるデータについて。通常のバーコードは数字ばかり格納しているイメージが強いのですが、QRコードはそのデータ容量も相まって、数字以外にも様々なデータを格納できます。基本的には「数字」「英数」「漢字」「8ビット」の4種類のモードが存在し、数字モードなら数字以外は使用できませんが、より限定されたモードほど圧縮率が高く、同じ大きさのコードに対してより多くの文字を格納できます。また、コードの途中でモードの切り替えもできるため、数字と漢字が混在したデータなども格納できます。
 データ変換の方法は実装時に扱うとして、以下にそれぞれのモードの簡単な説明を記しておきます。

数字モード
 0〜9のみを格納できるモードです。数字しか格納できないため、モードとしては最も自由度が低いのですが、数字3つなら000〜999の1000通りということで、これを10ビット(1024通り)で表現するため、3文字当たり10ビットという高い圧縮率が特徴です。
 以下に数字モードのデータの例を示します。
  • 0
  • 1
  • 100
  • 256
  • 1234567890
英数モード
 0〜9、A〜Z、半角スペース及び記号8種($%*+-./:)を格納できるモードです。数字モードより多くの文字種を使用できますが、その分圧縮率は劣ります。小文字のアルファベットは使用できません。数字10個、アルファベット26個、半角スペースと記号8種の9個で、使用できる文字は合計45種類となります。45通りのデータが2つで2025通りですから、これは11ビット(2048通り)で表現できます。したがって、サイズは2文字で11ビットとなります。どうにも記号の使い道に困りますが、半角スペースとパーセント記号、四則演算が使えるのは便利と考えておきましょう。
 以下に英数モードのデータの例を示します。ただし、補足部分はデータ内容に含みません。
  • 100
  • ALPHABET(アルファベットは大文字のみ使用可能)
  • I DONT LIKE SPAM(半角スペースは使用できるが、'が使えないためDON'Tとは書けない)
  • IDENTIFICATION DIVISION.
  • 50%(%記号は使用可能)
  • 100 + 100 : 200(=記号は使用できない)
  • GDP IS $100000000. AVERAGE 120%.
  • FEATURING LUMPY FLAKY SNIFFLES AND NUTTY
  • I : INTEGER
漢字モード
 Shift_JIS漢字を格納できるモードです。ひらがなやカタカナ、全角スペース、全角英数なども含みますが、半角英数や半角記号は含まれません。具体的には、Shift_JISの0x8140〜0x9FFC、0xE040〜0xEFFCの範囲の文字を使用できます。当然ながら、Shift_JISに定義されていない漢字は使用できません。2バイト文字1つにつき13ビットを使用します。
  • 漢字
  • 東南西北白発中
  • 手形裏書義務見返
  • べんけいがなぎなたをもって(ひらがなも「漢字」である)
  • アレイインデックスアウトオブバウンズエクセプション(カタカナも「漢字」である)
  • ねんがんのアイスソードをてにいれたぞ(カタカナ混在も当然可能)
  • Augusta Ada Lovelace(全角なら英数も使用可能)
  • 100+100=200(同じく記号も使用可能)
  • 「○□☆*&#」(これも範囲に含まれる)
  • 平成十三年九月十一日のアメリカ合衆国において発生したテロリストによる攻撃等に対応して行われる国際連合憲章の目的達成のための諸外国の活動に対して我が国が実施する措置及び関連する国際連合決議等に基づく人道的措置に関する特別措置法
8ビットモード
 8ビットをそのまま8ビットとして書き込む形式です。当然ながら、いかなるデータでも格納できるのですが、圧縮は一切ありません。一応漢字でも何でも格納できるはずなのですが、仕様書を見る限りでは日本語は漢字モードで格納するものとなっており、8ビットモードは半角英数及び半角カナを使用する場合に限定されているようです。これはおそらく、8ビットモードにマルチバイト文字を格納してしまうと、文字コードなどといった厄介な問題が生じる上、復元時にデータをどのように解釈すべきか不明となるため、マルチバイトの格納は避けるべきとされているのでしょう。ただし、UnicodeなどShift_JIS以外のコードを使用したり、Shift_JISにない漢字を格納したければ、実質的に8ビットモードしか方法がありません。とはいえ、基本的には小文字アルファベットのために使用するパターンが多い方式でしょう。URLは大抵が小文字であるため、8ビットモードが必要になります。
 以下のサンプルでは半角英数の場合のみ示しますが、実際にはいかなるデータも格納可能です。
  • 100
  • ALPHABET
  • Alphabet
  • 50% Gray
  • I DON'T LIKE SPAM!
  • a : array(1..10) of Integer;
  • public static void main(String args[]){}
  • $list = array(1 , 2 , 3);
 これらのモードの組み合わせによって、様々なデータを表現します。
 まだ中身に入ってはいませんが、ここから先がなかなか面倒であるため、今回はひとまずここまでとしましょう。

 付録として、JSPによる実装を置いておきます。JSPとしてはあまり良い書き方ではありませんが、クラスごとにファイルを分けるのはブログにそぐわないため、この中でクラスの定義から使用まで行っています。実際には間違ってもこのようなJSPは書かないようにしましょう。
 機能としては、構造的連接まで一通り備えています。相も変わらずいい加減な仕様書のせいで仕様を勘違いし、そのせいでモデリングを間違ってしまい、強引に書き直すこと数回といった有様ですから、手法に誤りがあってもおかしくありません。
 まず確実に間違っている点は、マスクの失点計算の実装です。マスクには0から7までの8種類があり、どれを使用しても動作はするのですが、それぞれ失点を計算して最も読み取りやすいものを使用すべきとされています。ところが、この仕様書はいつもながら極めていい加減であるため、QRコードを扱うサイト各所で仕様書の解釈が違うという状況が発生しています。仕様書には「シンボル全体」を評価するよう書いてありましたので、そのように実装しているのですが、他の人が作成した生成プログラムをいくつか試してみると、いずれも見事に結果が違ってしまいます。まさに三者三様です。どのマスクでも動きはするのでまだマシなのですが、「仕様書」なるものの新たな境地を見た気分です。
 また、特にBitCreator周りの実装には泣かされました。現在の実装では、setSource()時にバージョンを渡す必要があり、このバージョンとQRCodeMakerにセットされたバージョンが異なると、誤ったコードが生成される恐れがあります。最初はQRCodeMaker内のバージョンを使用する実装でしたが、モード自動判別のAutoBitCreatorがデータをパースするにはバージョンが必要であり、外部でパースしてからQRCodeMakerにデータを渡すという順番の関係上、QRCodeMaker内のバージョンを使えるのはパースした後ということで、三すくみが成立してしまいました(ちなみに内部でパースするようにすると、各種BitCreatorをQRCodeMakerに渡して使用するまで一部のメソッドが使えないという被害をこうむります)。また、そもそもバージョンを必要としないBitCreatorの実装型があったり、BitCreatorをインプリメントしてバージョンを要求しない独自の型を作ったりもできるため、このような仕様となっています。
 とはいえ、まとめてカプセル化してしまえば何の問題もないのではありますが。とりあえず動きますし、参考用としては多少は使えるでしょうか。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

無利子非課税国債の次の一手
2009/03/22(Sun)04:15:44
 相続税の課税を回避できる「無利子非課税国債」の上、さらには贈与税の軽減まで検討しているらしい自民党・与謝野氏。相続税の回避が金持ち優遇であるのは疑いようもありませんが、贈与税に関しては必ずしもそうであるとは言い切れない部分もあり、金持ち優遇か否かが気になっていたのですが、どうやらこの贈与税減税も金持ち優遇措置のようです。
 まずは贈与税について述べておきましょう。贈与税はその名の通り贈与された財物に対して課される税で、相続税法第二章第二節で定められています。計算は年区切りで行い、基礎控除として60万円が控除される他、常識的な額の生活費・教育費などには課税されず、同法や特別措置法などで様々な減免・控除規定が設けられています。
 相続税同様、贈与税も累進性が高い課税方法となっており、金額に応じて税率が違います。第二十一条の七の表より引用します。

二百万円以下の金額 百分の十
二百万円を超え三百万円以下の金額 百分の十五
三百万円を超え四百万円以下の金額 百分の二十
四百万円を超え六百万円以下の金額 百分の三十
六百万円を超え千万円以下の金額 百分の四十
千万円を超える金額 百分の五十

 まず贈与を受けた額から控除分を減算します。その後、200万円以下の部分には10%、200万円超で300万円以下の部分には15%、300万円超で400万円以下の部分には20%といった具合に加算を行い、それを合計した額が税額となります。
 仮に控除額を基礎控除のみの60万円とするなら、100万円の贈与には4万円、300万円の贈与には26万円、500万円なら67万円、2000万円なら745万円と、金額が増えれば税額も大幅に上がります。控除額が最低であっても6000万円が最低ラインとなる相続税と違い、贈与税はある程度の金額にも課税されますので、相続税よりは一般の人にも縁のある税といえます。ただし、最大税率となる1000万円以上の部分ともなると、1年に少なくとも1060万円の贈与が必要となります。ここまでの額になると、多くの人には縁のないものと考えられます。
 また、相続税の計算を行う際には、最近3年間に贈与を受けた分も相続財産に算入して計算する規定となっていますが、3年以上前の贈与分には相続税は課されません。したがって、相続税がかかるほどの財産を持っている人は、生前の贈与によって無税で、あるいは最低限の税率で資産を譲渡しようとする場合があるようです。特に、相続税の控除を差し引いてもなお3億円以上もの資産がある場合、1000万円の贈与であれば税は251万円となり、500万円にもなる相続税に比べて半額を回避できます。これらの点からして、贈与税の控除額の拡大、あるいは税率の軽減は、金持ちにとっては利益のあるものといえるでしょう。一方、相続しても相続税がかからない程度の資産のみを持つ一般的な人であれば、多額の生前贈与よりも相続を受ける方が有利であるため、家を買うなどまとまった費用を必要とする場合を除き、あえて多額の贈与を用いる必要性は低いといえます。
 無利子非課税国債の推進派は、1500兆円の資産のうちの大部分を60歳以上の人が持っていることを理由とし、それを借り上げて必要な人に行き渡らせるのが導入の目的であると説明しますが、贈与税減税についても似通った説明がなされています。すなわち、60歳以上が握っている多額の資産を現役世代に譲り渡しやすくする環境を整え、若い人がそれを消費に回せば消費の拡大が期待できるというのです。言うまでもありませんが、多額の税がかかるほどの資産を所有している人は一部に過ぎず、その一部以外の人の資産の贈与が容易になったとしても大した効果は期待できませんので、目的が庶民の負担軽減でないのは明らかです。
 まず最初に、庶民の負担軽減のための贈与税減税と、金持ち優遇のための減税の違いを記しておきましょう。庶民の負担軽減にしても、庶民の中でもある程度裕福な人だけが対象となりますので、必ずしも「弱者」救済とはいえない側面も持ち合わせているのですが、総合的にはおおむね中所得者層の負担軽減と考えられます。
 中でも有名なのは、住宅購入費用の贈与税減免規定でしょう。これは親などから住宅購入費用の補助を受けた場合に適用されるもので、ある程度の金額を減免する機能を持っています。この制度によって庶民は住宅を購入しやすくなり、富の還流をも実現できます。無論、これは減免手法の一例に過ぎず、新たな規定の導入が検討されたりもしているようですが、ほとんどの場合は金額や用途に条件を設け、主に中所得者層の負担を軽減する制度となっています。
 金持ち優遇制度の場合は、これとは全く違った仕組みとなります。仮に何年かの間に1000万円までの金額への課税を減免するのであれば、庶民が3000万円の家を購入するのには有用ですが、金持ちが100億円の豪邸を購入する場合にはほとんど役に立ちません。100億というのはさすがに大げさにしても、一部の金持ち高齢者に集中した資産を現役世代へと還流するなら、上限額などの条件にはそれなりの設定が必要です。すなわち、それは庶民救済とは全く別個の仕組みでなければなりません。一口に贈与税減税とはいっても、両者には大きな差が存在するため、内容が分からない限りは賛成とも反対ともいえない理由はここにあります。いずれにしても「弱者」救済ではない以上、ある程度は導入に慎重であるべきですが、庶民救済のための減税であれば導入するのも手です。
 しかしながら、導入派の主張を見る限り、現在検討されている贈与税の減税は、どうやら金持ち優遇としての減税のようです。仮に無利子非課税国債が導入され、贈与税減免規定まで導入されれば、金持ちは資産を対象者に丸々相続・贈与できるようになります。主張者の意図によれば、無利子非課税国債では多額の個人資産を国が預かって弱者救済に使用し、また贈与税減免や無利子非課税国債で手にした財産を現役世代が消費に回せば、弱者を救済できる上に消費拡大も見込めるとの算段のようですが、一体何をどう考えればそこまで都合の良い答えが出てくるのでしょうか
 まず贈与によって60歳以上から現役世代へと資産を回し、現役世代がそれを使えば消費拡大がなされるなどと主張されていますが、いくら金持ちでもそのような無計画な散財を行うでしょうか。現役世代に財産が移ったからといって、それが使用される保証はどこにもありません。後先考えずに使用する人間もいないとは言い切れませんが、それでは効果は限定的に終わります。
 そして、もし期待に反して散財が行われなければ、相続税や贈与税の対象となっていたはずの財産が、現役世代の一部の金持ちの元へと丸ごと移されるのです。これでは封建制と一体何が違うのでしょうか。そうなれば、富の分配機能は完全に麻痺し、格差はさらに拡大し、弱者救済どころではなくなります。封建制のどこが消費拡大につながるのか、私には全く理解できません。
 これが単なる財産の移し変えに終わらぬよう、例えば「不動産の購入時にのみ減免される」といった条件をつける方法も考えられますが、金持ち相手に上手く機能するとは限りません。これが庶民向けの減税であるならともかく、金持ち対象の減税にそのような小細工をしたとしても、流動資産が不動産に変わって丸々移されるだけです。したがって、条件付きにしたとしても効果があるとは限らないといえるでしょう。また、もし条件の効果がある程度現れたとしても、富の分配機能が損なわれる事実に変わりはありません。
 まだ案の詳細がはっきりしない以上、この時点ではこれ以上立ち入って論じるのは困難ですが、建前からすれば金持ちに有利な案が予想されます。相続税を免除して財産をすべて現役世代に丸ごと移せるようにし、しかも金持ちの子息が散財することを祈りつつ贈与税を減免するのと、相続税及び贈与税をしっかり取り立てて弱者に対して使うのでは、どちらの方が弱者救済かつ資産の還流が可能でしょうか。
 アインシュタインの「宇宙定数」のような理屈で無理やり結論を導き出したところで、効果が発揮できるわけがありません。何か深い考えによるのであれば、それを国民に示すのは当然です。もし無利子非課税国債や贈与税軽減が導入される運びとなったら、与謝野氏らにはしっかりお答え願いたいところです。また、民主党にも賛成派と慎重派がいるようですが、少なくとも自民党がこれを出してくる段階で、あるいは総選挙の前までには、党としてのスタンスを明確にすべきです。

 今回はひとまずoption型について。これは前回に使用した「maybe」と同等の機能を持つ標準の型です。すなわち、C#のint?などに相当する型で、nullに当たる値としてNoneを、値がある場合にはSomeを使用します。
 これについては、OCamlチュートリアルの解説が非常に秀逸です。例えばJavaの標準ライブラリを見ても、String.indexOf()などでデータが見つからなければ-1を返してきます。仮に見つからないからといって例外を投げてきたり、あるいはIntegerを使ってnullを返してきたりする実装となっていれば、非難が集中したであろうことは想像に難くありませんので、現実的には最適なやり方とみられますが、突き詰めると確かに少々変です。Adaでこれを実装してPositive型を返そうとすると、見つからない場合は例外を投げる羽目になる、などとお遊びを書いていると、再び苦言のConstraint_Errorのraiseがありそうです。やむを得ませんので、Adaに関しては次なるネタも用意していたのですが、下手なことを書くよりマシですし、むやみにお遊びを書けないのも苦痛ですから、当面AdaとOCamlは見送りましょう(OCamlに関しては、ひとまず前回の「maybe」の標準版ともいえるoptionまでは必要でしょうから、そこまでは記しておきます)。ただでさえ開発・非開発問わず難しいことが多すぎ、脳が(末尾でない)再帰を繰り返しているのに、平行して牽強付会の余地のない厳密な文章を書いたり、例外をキャッチして対応するのは、ランデヴーのできない私には不可能です。
 上記ページでは年齢の統計に使用する例が述べられていますが、確かに統計の際に「-1」のような特殊なデータがあると邪魔です。とはいえ、うっかり-1を普通に演算してしまわないように気をつければ、以下のような方法も一応取れます。
(* 平均年齢を算出するプログラム *)
type person = {
	name : string;
	age : int
};;

let avg source = 
	let fs = (List.filter ((!=) (-1)) (List.map (fun a -> a.age) source))
	in (float (List.fold_left (+) 0 fs)) /. (float (List.length fs));;

Printf.printf "平均年齢:%f"
	(avg [{name = "Larry Wall"; age = 55};
	{name = "Taro Aso"; age = 69};
	{name = "Ada Lovelace"; age = 194};
	{name = "Leonhard Euler"; age = 302};
	{name = "Xiu Liu"; age = 2015};
	{name = "Cunobelinus"; age = -1};
	{name = "Hannibal Barca"; age = 2256}]);;
 平均年齢815歳なるすさまじい結果が得られます。
 ただし、上記のページではうっかり演算してしまう危険性について述べられており、このような場合は-1を使うべきではないようです。参考までに、SQLではこうなります。
CREATE TABLE age_test(name VARCHAR(32) , age INT);

INSERT INTO age_test VALUES('Larry Wall' , 55) , ('Taro Aso' , 69) ,
('Ada Lovelace' , 194) , ('Leonhard Euler' , 302) ,
('Xiu Liu' , 2015) , ('Cunobelinus' , NULL) , ('Hannibal Barca' , 2256);

SELECT AVG(age) FROM age_test;
 SQLの統計関数は、NULLがあると自動的に無視してくれます。
 SQLでNULLを用いるのと同様に、OCamlでもoptionを使った方が確かに安全でしょう。先のレコードをoptionで書き直すと、以下のようになります。
type person = {
	name : string;
	age : int option
};;
 後は年齢が分かっているならSome、分からないならNoneを使うだけです。
(* 分かる場合 *)
{name = "Anonymous"; age = Some 30}

(* 分からない場合 *)
{name = "Anonymous"; age = None}
 後はパターンマッチで受け取るなり、お好みの方法で統計データを得るのみです。例えば「年齢不詳の人」を表示するには、以下のようになります。
type person = {
	name : string;
	age : int option
};;

List.iter (fun p -> Printf.printf "%s\n" p.name)
	(List.filter (fun p -> p.age == None)
		[{name = "Leonhard"; age = Some 302};
		{name = "Grey"; age = Some 70};
		{name = "Venus"; age = None};
		{name = "Mint"; age = None}]);;
 OCamlの第一部はここまでとして、次は意表をついてFORTRANでも。実はOCamlに続いてF#を扱おうと考えていましたが、F#はどうしましょうか。
 FORTRANは高級言語としては世界最初のものとされており、様々な手続き型言語の祖先とされています。同じく関数型言語の祖先とされるLispは、今ではほとんど使用者がいなくなってしまったようですが(子孫のCommon Lisp、Emacs Lisp、Schemeなどは現役)、FORTRANは今でもスーパーコンピュータなどで使用されているようです。ただし、初期のFORTRANと最近のものではかなり仕様が違っていますので、最近のFORTRANが昔のFORTRANの子孫であり、古いFORTRANはLisp同様にあまり使用されなくなったとも考えられます。
 FORTRANは大文字で表記されることが多いようですが、FORTRAN 77以前のものをFORTRAN、Fortran 90以降のものをFortranと呼び分ける流儀もあるようです。この定義に従えば、以下で扱うものはFortranに当たる言語となりますが、以下「FORTRAN」で統一します。
 C言語は高速な言語の代名詞とされており、速度の単位として使用される場合がしばしばあります。「OCamlはCと互角あるいは数倍の処理時間で動作」なる文章は、OCamlの長所の解説として用いられます。また、Javaはそこそこに速い言語ですが、C言語と比べれば明らかに遅く、「重い」となじられたりします。
 しかし、そのC言語をもってしても、FORTRANの速度にはかなわないとされています。正確に言えば、FORTRANはベクトル計算などの機能を使用したり、命令が高速処理に都合の良い方式になっていたりと、スーパーコンピュータの性能を引き出す仕様になっているようです。スーパーコンピュータは処理当たりのコストが非常に大きく、C言語で1億円当たり100の処理ができるところをFORTRANで1%だけ多く処理すれば、約100万円分の差が生じる結果となります。スーパーコンピュータのような機能を備えていない一般のPCでは、さすがにそこまでの性能は期待できそうにありませんが、おそらくそれなりには速いのでしょう。VBの一部構文のルーツらしきものが垣間見えたり、他の様々な言語に影響を与えたらしい部分が色々あったりと、言語としても興味深いです。
 前置きはともかく、まずはコードを書いてみましょう。FORTRANのソースの拡張子は「*.f」なのですが、これは古いバージョンのソースを表すものであるため、ここではFortran 90を使うとして「*.f90」を拡張子とします。77以前のFORTRANでは行番号なる悪夢が存在しましたが、幸いにも最近のFORTRANでは必要なくなっており、そのまま書き始められます。
 まずはHello Worldから。
PROGRAM BLOG
	PRINT * , 'Hello FORTRAN'
END PROGRAM
 余談ながら、「END PROGRAM」と書くべきところを「END (プログラム名)」と書いてしまい、しかも末尾にセミコロンをつけてしまう癖がついてしまっており、大変困っています。
 print文のアスタリスクは、デフォルトの書式で出力することを表しています。色々な書式が用意されているのですが、ここでは深く考える必要はないでしょう。また、ここでは大文字を使用していますが、大文字と小文字の区別はありません。大文字の方がFORTRANらしく見えなくもありませんが、今後は小文字を使用するものとします。
 これをFORTRAN 77で書くと、以下のようなコードとなります。
00010 PROGRAM BLOG
00020  PRINT * , 'Hello FORTRAN 77'
00030 END PROGRAM
 COBOLといい、なぜ行番号はこれほど面倒なのでしょうか。COBOLを書く場合ですらコンパイラのフリースタイル指定で行番号を回避する私には、行番号などほとんど縁のないものなのですが、最近はBASICでさえ行番号を回避する傾向にあるようです。COBOL使いがJavaでとんでもないコード(おそらく変数が全部インスタンス変数として宣言されているようなものと推測される)を書いたといった話は聞いたことがありますが、GOTOに慣れきったBASIC使いが危険なものを書く恐れはないのでしょうか。
 FORTRANの特徴的な文化として、暗黙の型宣言があります。現在ではあまり推奨されていないようですが、FORTRANでは宣言をせずに変数を使用できます。しかも、先頭の文字がI,J,K,L,M,Nから始まる変数はinteger、そうでないものはrealとみなされます。整数がI以降の6文字なのは、Integerから連想しやすいためとされています。
program blog
	i = 10
	j = 3
	a = (i + j) * 0.5
	print * , i , j , a
end program

! "!"の後ろの記述はコメントとして扱われる
! 結果 : 10 3 6.5
 ただし、変数名のスペルミスが深刻なバグを招きかねないため、この機能は基本的には推奨されていません。暗黙の型宣言を無効にする「implicit none」を記述することが推奨されています。
program blog
	implicit none
!	i = 10
!	暗黙の型宣言ができなくなる
end program
 暗黙の宣言を無効にしたところで、明示的な変数の宣言を行ってみましょう。とはいえ、ごく単純な宣言の場合であれば、方法はCなどと全く同じですので、迷う必要はありません。整数はinteger、実数はreal、文字はcharacter、論理(他の言語でいうboolean)はlogical、倍精度実数はdouble precisionとされています。また、complexで複素数も扱えるらしいのですが、複素数とやらの使い方が良く分かりません。気の利いたサンプルの1つでも作りたいのですが、Wikipediaで調べてもさっぱり理解できません。
 複素数はともかくとして、まずはintegerを宣言・表示してみます。
program blog
	implicit none
	integer i
	i = 10
	print * , i
end program
 基本的にCやJavaと似通っていますので、非常に簡単です。
 しかしながら、調子に乗って以下のように書いても上手くいきません。コンパイルエラーが発生してしまいます。
program blog
	implicit none
	integer i = 10
	print * , i
end program
 上記のような操作を実行したければ、このように書かなければなりません。それにしても、なぜ「::」なる記述は様々な言語で、しかも違う意味で使われているのでしょうか。
program blog
	implicit none
	integer :: i = 10
	print * , i
end program
 この「::」の前には様々な属性を記述できます。以下のコードでは、pi及びeなる定数を宣言しています。
program blog
	implicit none
	real , parameter :: pi = 3.14159
	real , parameter :: e = 2.71828

	print * , 45.0 * pi / 180.0
end program
 論理型はtrueまたはfalseを保持しますが、FORTRANの書き方は少々変わっています。「.true.」のようにドットではさまなければならないのです。
program blog
	implicit none
	logical :: l = .true.
end program
 この種の記述は今後もいくつか出てきます。FORTRANではtrueやfalseといった名前の変数をも作成できるため、衝突を回避しているのでしょう。
カテゴリ [開発魔法][社会問題][経済・知的財産] [トラックバック 0][コメント 0]

<-前のページ [1] [2] [3] [4] [5] [6] 次のページ->
- Blog by yamicha.com -