yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2017/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
新型インフルエンザの恐怖
2009/11/01(Sun)21:19:49
 このところ、新型インフルエンザの被害拡大がよりいっそう社会問題化しているようです。マスコミも連日のようにこれを報じ、新聞では社説のテーマに取り上げなかった社の方が珍しいほどです。もともとインフルエンザは冬に流行する傾向があるため、本格的な冬にかけてさらに大流行を起こす懸念は否定できず、医療体制の問題が問われている他、ワクチンをどう配分するかも問題となっています。
 何事も「備えあれば憂いなし」ですので、新型インフルエンザに対する正しい知識を身につけ、備えを怠らないのは良いことです。マスコミも、新型インフルエンザに関する正確な情報を提供して国民の知識を充実させ、啓蒙活動を行うのであれば、その報道には価値があるといえます。多くの国民が正しい知識を習得し、いたずらにあわてずに対策をすることができれば、被害を最小限に抑えられるに違いありません。
 しかしながら、果たして国民の多くはそれを実行できているでしょうか。マスコミはそのような報道を行っているでしょうか。おそらくそれを行っている人も少なくないはずですが、残念ながら虚像を作り上げるような報道と、虚像に踊らされる人間が非常に多いように見受けられます。もともと西洋文化であるクリスマスやハロウィーンまでお祭りにしてしまうなど、日本人はとかくお祭りが好きな民族のようですが、新型インフルエンザさえもそのレベルで扱われているような気がしてなりません。
 無論、正しい知識を身につけ、正確な備えを行うのであれば、何の問題もありません。しかし、あまりにも派手に騒ぎすぎたり、時には不確かなデマまで飛び交う状況となれば、それは百害あって一利なしと言わざるを得ません。かつて関東大震災が発生した際、地震とそれに付随する火災によって多くの悲劇が生じましたが、さらに「朝鮮人が井戸に毒を入れている」というデマまでもが飛び交い、朝鮮人やそう誤認された日本人に死傷者が出るなど、さらなる悲劇を生み出しました。最近のインフルエンザ騒ぎに感じるのは、まさにこのような印象です。
 当然のことながら、余程の無政府状態にもならない限り、現代日本でここまでの騒乱は発生し得ないでしょう。ところが、さすがに殺傷事件までには達しないにしても、その土壌は確かに存在しています。日本で新型インフルエンザが確認された際、修学旅行でインフルエンザを持ち込んだとされる生徒が所属していた学校に対して電話で文句をつけ、謝罪を要求した者がいたというのです。また、インターネット上などで感染生徒に対する不当な誹謗中傷が行われたことも問題となっています。ちなみに、新型インフルエンザ自体はその前からすでに一部で流行しており、ここで初めて正式に新型インフルエンザであることがが確認されただけという説もあるようです。
 このような状況に際し、マスコミには正しい情報と冷静な対応を呼びかける責務があるはずです。ところが、そのマスコミもまた火に油を注いでいるばかりか、自ら火種を作っている有様です。関東大震災の際、ただのデマ程度の噂が暴動や殺傷にまで発展した原因は、おそらく疑心暗鬼にあるはずですが、新型インフルエンザ問題でのマスコミの対応は、まさにそれをあおっているようにしか見えません。
 マスコミの影響力の大きさは、今さら言うまでもありません。健康番組が「納豆を食べるとダイエットができる」と称すれば、納豆があっという間に売り切れてしまい、逆に捏造が発覚した後はさっぱり売れなくなってしまい、本当に良いものを作ろうとしている納豆業者が最大の被害者となりました。鳥インフルエンザが報道された際には鳥がさっぱり売れなくなる風評被害を生じ、それ以外にも実に様々な被害をもたらしています。あるいは、健康や病気にかかわらない分野であっても、昨今は昔に比べて殺人が増えている、少年犯罪が増えているなどという、統計資料を見れば一目で分かるデマを流布し、無用な不安をあおっています。国民がそのようなものを信用しないのであれば何の問題もありませんが、実際には納豆が店頭から消えてしまいました。
 どういうわけか、新型インフルエンザでは死者が発生するたびに報道がなされていると言っても過言ではなく、これによって「致死性」の印象から恐怖を抱く人も少なくないはずですが、実際には既存のインフルエンザでも毎年多数の人が亡くなっています。致死率は0.5%程度で季節性より高いともされますが、医者にかからぬまま、あるいは不健在感染や風邪と思い込むなどして自分でも気づかぬまま治癒してしまう人も非常に多いと考えられ、それを合計すると0.05%程度ではないかとする意見もあります。少なくとも、既存のインフルエンザを大きく上回るものではないと考えるのが妥当でしょう。むしろ、もし本ウイルスが感染性・致死性ともに極めて高く、毎日数百数千の人が犠牲になるような悪魔のウイルスであるのなら、犠牲者が出るたびにいちいち報道することはできないわけですから、個々の犠牲者に対する大きな報道は致死性の低さの証左と捉えるべきでしょう。
 無論、今は弱毒性のインフルエンザであっても、後に強力な毒性を持ってしまう可能性はありますし、いくら弱毒性でも感染拡大に対する警戒を怠ってはいけませんが、注意を促す報道と疑心暗鬼を誘う報道は全くの別物です。それどころか、あまりに新型インフルエンザの危機が誇張されて報道されるせいで、やはり強力な感染力と致死率を持つ季節性インフルエンザや、警戒を怠ってはならない鳥インフルエンザへの注意がお留守になっています。
 また、過剰反応から病院に人が殺到する現象は現時点でも発生しており、それによって医療機関がパンクして必要な治療が行えなくなったり、二次感染が発生してしまう懸念が生じています。それ以外にも過剰反応は様々な余波をもたらしており、実害が生じています。納豆騒動は納豆が正しく理解されている、あるいは納豆を食べてダイエットなる簡単な話はあり得ないと理解されていれば、最初から発生しなかったはずですし、鳥インフルエンザ問題にしても、食用肉からの感染の可能性がないことが理解されていれば、鶏肉が売れなくなることはなかったはずです。これらと同様に、新型インフルエンザについて本当に正しい理解がなされていれば、無用な過剰反応は抑制できるはずなのです。
 ワクチン配備と投与も結構ですが、ワクチンが万能でない点には留意しなくてはなりません。国民は案外冷静なのか、「ワクチン接種を受けたくない」と考える人は少なからず存在するようですが、事実としてワクチンは絶対的なものではありません。既存のワクチンも様々な副作用が報告されており、あまり効果を発揮しない場合もあることから、老人などの高リスク者は接種を推奨されてはいるものの、あまり接種を行うべきでないとの意見もあります。ましてや、新型に対するワクチンは突貫製造の上に十分な知見が得られていません。一応のテストは行われているにしても、テストを行った末に認可されたはずの薬に大問題が生じる場合があるのを見るまでもなく、実際の効用や副作用は使ってみなくては分かりません。このワクチンが有意に感染率を低下させるのが確かであれば、高リスク者への接種を行うのは妥当な策ではありますが、少なくとも万能であると考えてはいけません。
 今回の新型インフルエンザは、せいぜい季節性に匹敵する程度の致死性しかない軽微なものでしたので、マスコミの過剰報道にせよ、国民の過剰反応にせよ、害悪ではあっても致命的なほどの混乱は生じていませんが、私が危惧するのはその先です。もし免疫が暴発する強毒性鳥インフルエンザが大発生したり、エボラ出血熱や天然痘のような極めて感染力と致死率の高い(致死率は前者で5〜9割、後者で3〜5割程度とされる。「天然痘」そのものは世界から根絶されたが、類似ウイルスが人間への感染性を獲得する可能性を指摘する声もある)病気が流行した場合、マスコミはどのようにこれを報道し、国民はいかなる反応を示すのでしょうか。たかだか今回の新型インフルエンザでさえ、学校に中傷の電話をかける連中がいたり、これだけパニックを起こしたりする有様なのです。それこそ、医療機関の麻痺や関東大震災の再来、その他様々な大問題が現実のものとなる可能性が否定できません。

 まずは以前のおさらいより。OCamlなどの諸言語が丸カッコ(...)を使ってタプルを作成するのと異なり、Erlangのタプル型は{...}を使って作成することになっています。少々紛らわしいですが、おそらく慣れの問題でしょう。そのような人がどれほど存在するのかは不明ですが、Erlangを最初に習得した人であれば、丸カッコを使用する方が紛らわしく見えるかもしれません。
 余談ながら、OCamlでは「()」(空のタプル)がunitなる特殊なもの(主にvoidとしての役割)を表していますし、F#ではタプルがCなどの関数呼び出しのように見えるのを利用してか、「Console.WriteLine()」のように表記すると引数なしのメソッドが呼ばれ、「Some(a , b)」ならaとbを引数とするメソッドが呼ばれる仕組みとなっています。すなわち、C#などの「int Some(int , int)」は、F#では「int * int -> int」に当たります(*1)。これらのような分かりづらい性質を考えると、タプルを丸カッコで扱わないErlangの方が合理的な気がしなくもありません。

(*1)09/11/04 「(int * int) -> int」と書いていたところを、いげ太さんよりご指摘をいただき、修正しました。本来カッコなど全く必要ないところを、タプル作成の表記に気を取られて誤っていました(F#でもOCamlでもカッコなど全く必要ない場面であるはずなのに、この何の脈略もないミスは自分でも不思議です)。ご指導ありがとうございます。

 それでは、タプルから値を取り出す場合はどうするのでしょうか。そこは関数型言語ですから、パターンマッチに限ります。
-module(blog).
-export([calc/2]).

calc(V , {add , D}) -> V + D;
calc(V , {subtract , D}) -> V - D.
 タプルの1つ目のアトムがaddであれば足し算、subtractであれば引き算を行う簡単なサンプルです。
1> blog:calc(100 , {add , 10}).
110

2> blog:calc(100 , {subtract , 64}).
36
 これを使ってバリアントの真似事でも行ってみます。さすがにPrologを基にしているだけはあって、とにかく条件にマッチさえすれば何の問題もなく動作します。
-module(blog).
-export([value/1]).

value({real , V}) -> io:fwrite("Real: ~f~n" , [V]);
value({complex , V1 , V2}) -> io:fwrite("Complex: ~f , ~f~n" , [V1 , V2]);
value({nan}) -> io:fwrite("Not A Number~n").
% Erlang では何型であってもとにかくマッチさえすれば動作するので
% nan は別にタプルにしなくても(直接アトムを使っても)構わない
 実数、複素数、NaNのいずれかを取る関数(という設定)です。サンプルであるため、ここでは単に中身を表示するだけですが、実際に計算を行わせても面白いでしょう。OCamlで言うところの以下のようなバリアントを仮想しています。
type num = Real of float | Complex of (float * float) | NaN;;
 後は単に適当なタプルを渡すだけです。
1> blog:value({real , 2.71828}).
Real: 2.718280
ok

2> blog:value({complex , 10.0 , 5.0}).
Complex: 10.000000 , 5.000000
ok

3> blog:value({nan}).                 
Not A Number
ok
 これを踏まえて、レコードについて。
 他の多くの言語と同様、Erlangもレコードをサポートしています。独立した機能というよりは、ほとんど「名前付きタプル」です。
 まず以下のような記述を行い、レコードを宣言するようです。
% 単純な書き方
-record(book , {title , author}).

% デフォルト値も設定できる
-record(book , {title = "" , author}).
 デフォルト値を明示的に指定しなかった場合、デフォルト値は「undefined」(アトム)とみなされます。ブール値といい、Erlangのアトムはなかなか巧妙に使われています。
 レコードの「オブジェクト」(なる言葉をErlangで使うのが適切かは不明ですが)を作成する際には、シャープ記号に続いてレコード名を書き、その後ろに値を並べます。
% ごく普通の作り方
create_book(Title , Author) -> #book{title = Title , author = Author}.

% 通常のタプルと違い、値は任意の順番で書ける
create_book(Title , Author) -> #book{author = Author , title = Title}.

% 値指定の一部または全部を省略してもよい
% 省略した場合、デフォルト値があるならその値、ないなら undefined が格納される
create_book(Title , Author) -> #book{title = Title}.

% このような書き方はできない模様
% create_book(Title , Author) -> #book{Title , Author}.
 レコードの中身を取得する際には、「object#recordname.varname」の形式を取ります。
get_title(Book) -> Book#book.title.
% 末尾のピリオドは取得の構文の一部ではありません。念のため
 これが型のはっきりした言語であれば、例えばCなら
struct Book book;
...
book.title;
 これで(book変数はBook型であると分かっているため)書名を取得できますし、OCamlなどの関数型言語でも同様です。しかしながら、Erlangでは型の自由度が高く、いかなる型が渡されるか分からないため、このような記法となっているのでしょう。
 さらに言えば、実はそもそもレコード自体が「特定の手順に従ってタプルを取り扱う」一種のマクロか糖衣構文に近い扱いのようで、レコードのオブジェクトの実態はレコード名をアトムとして含むタプルです。
 ここに以下のようなプログラムがあるとして、
-module(blog).
-export([create_book/2 , get_title/1]).
-record(book , {title , author}).

create_book(Title , Author) -> #book{title = Title , author = Author}.
get_title(Book) -> Book#book.title.
 このcreate_bookを呼び出して、bookレコードのデータを作成してみると、
1> blog:create_book("Design Pattern" , "four gangs").
{book,"Design Pattern","four gangs"}
 {レコード名 , 値...}のタプルが返ってきました。それなら、最初からこの形式でタプルを作り、当該レコードを引数に取る関数に渡した場合、一体どうなるのでしょうか。
1> blog:get_title({book , "Introduction Erlang" , "Ericsson"}).
"Introduction Erlang"
 この通り、何事もなく動作してしまいます。すなわち、レコードの正体は以上のようなものであると分かります。
 また、レコードを使用すれば値の修正も容易にできそうです。以下の例であれば、set_title関数は「書名を変更するものである」ことが一目瞭然です。
-module(blog).
-export([create_book/2 , get_title/1 , set_title/2]).
-record(book , {title , author}).

create_book(Title , Author) -> #book{title = Title , author = Author}.
get_title(Book) -> Book#book.title.

% 既存のデータのタイトルのみを変更する関数
% 無論、元の値を変更(参照透過性を破壊)するのではなく、
% 新しい値を格納した新しいオブジェクトを生成して返す
set_title(Book , Title) -> Book#book{title = Title}.
 これは以下のように使用できます。
1> B = blog:create_book("(TBD)" , "Jane Doe").                   
{book,"(TBD)","Jane Doe"}

2> blog:set_title(B , "Erlang Process Trainer").
{book,"Erlang Process Trainer","Jane Doe"}
 つくづく奇妙ながらも面白い言語です。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 1]
<- 前の記事を参照 次の記事を参照 ->

Comments(1)
いげ太 - 2009/11/03(Tue)21:16:02
> C#などの「int Some(int , int)」は、F#では「(int * int) -> int」に当たります
int Some(int, int) なるメソッドの F# における型表現は int * int -> int です。(int * int) -> int だと、int Some(Tuple<int, int>) なメソッドの型になります。ややこしいですが。

- Blog by yamicha.com -