2017-04-03
積極的な記憶定着の方法と消極的な記憶定着の方法
例えば外国語を学習するにあたり、文法事項にしろ単語にしろ、覚えることが推奨されることが多くあります。文法書や単語帳を眺めているだけで記憶できてしまう人もいるかもしれませんが、多くの人は記憶を定着させるためには積極的に暗記するなどの努力をしなければならないでしょう。
外国語学習法としては、暗記を避けようとする方法論もあり、丸暗記は真の実力がつかないから止めるべきだという主張もあります。これはこれで一理あります。外国語の文章を読んだり、耳にしていれば自然に覚えるから、そうあるべきだというのです。それで外国語が身につくのであればありがたい話ですが、なかなか思うようにはいきません。
ところが分野によっては、積極的に記憶を定着させようとはしていないのに、自然と記憶できてしまうような事柄もあったりするのです。確かにその分野の情報には常に接するようにはしていますが、それだけで覚えてしまうこともあります。「好きこそものの上手なれ」というところかもしれませんが、諺には「下手の横好き」というものもあるので、好きだから覚えるわけでもないでしょう。
趣味的事項であれば、記憶の定着のために、積極的手段を用いても、消極的手段でも、どちらでも構いません。しかし外国語学習のようなものは、むしろ積極的に記憶定着に努めているにもかかわらず、なかなか頭に残りません。なんとかならないものだろうかと、いつも思っています。
外国語学習法としては、暗記を避けようとする方法論もあり、丸暗記は真の実力がつかないから止めるべきだという主張もあります。これはこれで一理あります。外国語の文章を読んだり、耳にしていれば自然に覚えるから、そうあるべきだというのです。それで外国語が身につくのであればありがたい話ですが、なかなか思うようにはいきません。
ところが分野によっては、積極的に記憶を定着させようとはしていないのに、自然と記憶できてしまうような事柄もあったりするのです。確かにその分野の情報には常に接するようにはしていますが、それだけで覚えてしまうこともあります。「好きこそものの上手なれ」というところかもしれませんが、諺には「下手の横好き」というものもあるので、好きだから覚えるわけでもないでしょう。
趣味的事項であれば、記憶の定着のために、積極的手段を用いても、消極的手段でも、どちらでも構いません。しかし外国語学習のようなものは、むしろ積極的に記憶定着に努めているにもかかわらず、なかなか頭に残りません。なんとかならないものだろうかと、いつも思っています。
旅行の記念としての「証明写真」
証明写真というと普通は履歴書に添付する写真や、運転免許証とか学生証・社員証などにある写真のことを想像すると思います。街角の写真屋さんなどで「証明写真」と言ったら、そういうものです。
これに対して、旅行をすると有名な旅先などを背景にして（たいていは無表情の）写真を撮ることが多く見られます。これは旅行の記念写真を意図していると思いますが、まるで「証明写真」です。自分は間違いなく「その有名な某に行ってきた」ということを「証明」するための写真のようです。
自分の旅の記録をどのようにして写真として残すのかということは難しい問題なので、どうしたら良いのか僕自身としても試行錯誤しているところです。
昔は日本人の旅行者を指して揶揄的に「カメラを持っている」と言われたりもしました。しかし日本人じゃなくても、どこの国の人でも、多くの旅行者はカメラを持っているし、写真を撮っているのではないかと思います。
これに対して、旅行をすると有名な旅先などを背景にして（たいていは無表情の）写真を撮ることが多く見られます。これは旅行の記念写真を意図していると思いますが、まるで「証明写真」です。自分は間違いなく「その有名な某に行ってきた」ということを「証明」するための写真のようです。
自分の旅の記録をどのようにして写真として残すのかということは難しい問題なので、どうしたら良いのか僕自身としても試行錯誤しているところです。
昔は日本人の旅行者を指して揶揄的に「カメラを持っている」と言われたりもしました。しかし日本人じゃなくても、どこの国の人でも、多くの旅行者はカメラを持っているし、写真を撮っているのではないかと思います。
2017-03-31
FreeBSDで複数のLLVM/clangがインストールされてしまった
FreeBSDではgccを止めてLLVM/clangが使われています。昔は他のBSDやLinuxと同様にgccでしたが、今は完全にLLVMに置き換えられています。
ところが気がついて見ると、標準のLLVMの他に、portsから異なるバージョンのLLVMがインストールされてしまっていることに気がつきました。
このような状況はLLVMに限らず、gccであるとか、perlなどでも起きることがあります。特定のバージョンを使わなければならない必然性があるのなら仕方ないと納得できますが、たいていの場合はデフォルトのバージョンでも問題にならないことが多いのです。
FreeBSDに標準でLLVMが入っているのに、さらにバージョン3.7や3.9のLLVMが入るのはリソースの無駄としか思えません。
ところが気がついて見ると、標準のLLVMの他に、portsから異なるバージョンのLLVMがインストールされてしまっていることに気がつきました。
% cc --versionどうしてこうなってしまったのか今後調べてみようと思いますが、おそらくportsから入れた何かのパッケージが特定のバージョンのLLVMに依存する設定になっていたのでしょう。
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.3
Thread model: posix
% pkg version -vIL=
*snip*
llvm37-3.7.1_4 < needs updating (index has 3.7.1_5)
llvm39-3.9.1_2 < needs updating (index has 3.9.1_3)
*snip*
このような状況はLLVMに限らず、gccであるとか、perlなどでも起きることがあります。特定のバージョンを使わなければならない必然性があるのなら仕方ないと納得できますが、たいていの場合はデフォルトのバージョンでも問題にならないことが多いのです。
FreeBSDに標準でLLVMが入っているのに、さらにバージョン3.7や3.9のLLVMが入るのはリソースの無駄としか思えません。
2017-03-30
undocumented feature
昔々のことになりますがNECのTK-85を持っていました。CPUはインテルの8085で、RAMは何と僅か512バイトです。
8085というCPUは、有名な8080を改良したもので、命令が2つ追加されています。当時のインテル製CPUのアーキテクチャはCISCです。命令長は可変長ですが、命令の1バイト目だけみれば後続する命令長が分かるようになっています。要するに1バイトで命令をデコードするわけですから256個定義できるのですが、実際には数箇所の未定義部分があります。
当時のCPUは現在とは違い原始的ですので、未定義となっている命令を実行させようとしても「例外処理」が起きるような機能を持っていません。未定義命令を使ったバイナリを実行させてみると、思いもがけないような結果が得られることがあります。アセンブラでプログラムを書く身であれば在れば有り難いと思うような機能が実装されているのが分かったりします。しかしそれはマニュアルに記載されていませんから必ず利用できるとは保証されません。このような機能は「undocumented feature」と呼ばれます。
ここまで書いた話はハードウェアに関することですが、ソフトウェアであっても同じことです。ハードであれソフトであれ、仕様に関する文書に記載されていない場合でも、操作してみれば何らかの「一見すると有用そうな」挙動を示すことがあります。しかしそれは（厳格に捉えるなら）undocumented featureです。つまりその「機能」は永続的に利用できる保証がありません。
このようにundocumented featureを使うのは慎重となるのですが、問題は特にOSSでは仕様を明示的に示す文書が欠けていることが多いことです。あろうことか「ソースコードが公開されているんだから、文書は要らない」とか言い出す人が出てくる始末です。仕様書とソースコードが同一だとする立場であれば、そこには「バグ」という問題は原理的に発生しません。バグというのは、仕様としてあるべき状態と、プログラムとしての実際の挙動の違いから判断されるべき事柄なのです。
商用製品では、OSSに比べれば 、文書がある程度用意されていますが、些細な点まで全て網羅されているような詳細な文書が用意されているとも限りません。使おうとした機能や、行おうとした操作が、undocumented featureなのか否かを判断するのは、思うほど簡単ではありません。
このようにundocumented featureは恐いので、使わないで済むものなら使いたくないところです。問題は、文書が充実しているとは言い難いことが多い現状においては、確実に「仕様に基づいた機能を使っている」と言い切れる事態は決して多くはないという事実です。否応なしに、undocumented featureを利用しているのか違うのかも不明なままに、目の前で動いているものが「永続的」であるように祈りながら、日々を過ごしていくことになります。
8085というCPUは、有名な8080を改良したもので、命令が2つ追加されています。当時のインテル製CPUのアーキテクチャはCISCです。命令長は可変長ですが、命令の1バイト目だけみれば後続する命令長が分かるようになっています。要するに1バイトで命令をデコードするわけですから256個定義できるのですが、実際には数箇所の未定義部分があります。
当時のCPUは現在とは違い原始的ですので、未定義となっている命令を実行させようとしても「例外処理」が起きるような機能を持っていません。未定義命令を使ったバイナリを実行させてみると、思いもがけないような結果が得られることがあります。アセンブラでプログラムを書く身であれば在れば有り難いと思うような機能が実装されているのが分かったりします。しかしそれはマニュアルに記載されていませんから必ず利用できるとは保証されません。このような機能は「undocumented feature」と呼ばれます。
ここまで書いた話はハードウェアに関することですが、ソフトウェアであっても同じことです。ハードであれソフトであれ、仕様に関する文書に記載されていない場合でも、操作してみれば何らかの「一見すると有用そうな」挙動を示すことがあります。しかしそれは（厳格に捉えるなら）undocumented featureです。つまりその「機能」は永続的に利用できる保証がありません。
このようにundocumented featureを使うのは慎重となるのですが、問題は特にOSSでは仕様を明示的に示す文書が欠けていることが多いことです。あろうことか「ソースコードが公開されているんだから、文書は要らない」とか言い出す人が出てくる始末です。仕様書とソースコードが同一だとする立場であれば、そこには「バグ」という問題は原理的に発生しません。バグというのは、仕様としてあるべき状態と、プログラムとしての実際の挙動の違いから判断されるべき事柄なのです。
商用製品では、OSSに比べれば 、文書がある程度用意されていますが、些細な点まで全て網羅されているような詳細な文書が用意されているとも限りません。使おうとした機能や、行おうとした操作が、undocumented featureなのか否かを判断するのは、思うほど簡単ではありません。
このようにundocumented featureは恐いので、使わないで済むものなら使いたくないところです。問題は、文書が充実しているとは言い難いことが多い現状においては、確実に「仕様に基づいた機能を使っている」と言い切れる事態は決して多くはないという事実です。否応なしに、undocumented featureを利用しているのか違うのかも不明なままに、目の前で動いているものが「永続的」であるように祈りながら、日々を過ごしていくことになります。
登録:
投稿 (Atom)