2008-03-19
2008-03-18
■Photoshopの災厄 ありえない修正がされた画像たち
そんな画像や、何かの間違いが混じり込んだ画像を見つけて紹介しているblog。
分かりにくいものは英語を読まないといけないんですが、写真だけで分かるものもあるので、フィードリーダに入れておくと時々吹き出してしまったり。
http://photoshopdisasters.blogspot.com/2008/03/victorias-secret-classic-severed-hand.html
心霊写真か? みたいなのとか。
http://photoshopdisasters.blogspot.com/2008/03/bebe-eva-longoria-is-made-of-rubber.html
あなたの体はゴムで出きてるんですか? みたいな無茶な修正とか。
http://photoshopdisasters.blogspot.com/2008/03/imagine-babyz-whats-watermark.html
素材無料使用した時に入り込む透かしマークが、なぜかゲームのパッケージに……、とか。
http://photoshopdisasters.blogspot.com/2008/03/diario-sportivo-as-i-wasnt-expecting.html
スペインにはソックリさんがたくさんいるようで……。
■日本の伝統的な強みって を受けて
「技術が形式知化されずに*1人から人へ伝承できること」だったのかなぁ、と私は思いました。
人材だよね。技術じゃないよね。とかふと思った。
日本の伝統的な強みって - lethevert is a programmer
今は何でも"形式知化"で(ISO9000シリーズとか)、"人から人へ伝承できなく"なっているんじゃなかろうか、と。
あぁ、そのことを指して漠然と"人材"という言葉で言い表しているんだろうなぁ、と想像してはいますが。そこをあえてくどい表現にしてみました、ということです。
*1 されないままでも、の方が良かったか。
2008-03-17
■「牛の首」 ネタバレ注意!!
聞いたらあまりの怖さで死ぬとかおかしくなるとかいう「牛の首」と言う話が知りたいのですが
http://q.hatena.ne.jp/1069654969
小松左京の短編小説に同名のものがある。
の巻頭に収録されている。
他には、
にも収録されているようだ。
では、ネタバレをこれから書きます。
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
一人称小説。
「こわい話もずいぶんきいたけど……」とS氏は、急にあらたまった口調で言った。「やっぱり一番すごいのは……」
という書き出しで始まる。
そして「私」は"牛の首"という"本当にこわい話"の存在を聞きつける。
が、誰もその中身については口をつぐんで話そうとしない。
「もう、あの話だけはよそう」
「それがなかなか――」(略)「いえないし――、実をいうと、思い出す*1のもいやなんで……」
という感じ。
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
最後に「私」は気付く。
それは題名と、非常に恐ろしい話だということだけわかっていて、その内容は誰も知らないのだということに。
あんなものすごい話は
誰もどんな話か知らないのに、その恐怖だけが
そして結末。
「私」がある人に、"牛の首"という怪談があるそうですね、と尋ねられ、そして応える。
「ああ……」私は顔が青ざめるのを意識しながら、低くつぶやいた。「知っているとも――あんな、恐ろしい話は、きいたことがない……」
と幕引き。
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
という内容のショートショートなのである。
このショートショートの何が「怖い」かというと。
物語世界の「私」と同じ情況に、読者も陥るからなのだ。
聞いたらあまりの怖さで死ぬとかおかしくなるとかいう「牛の首」と言う話が知りたいのですが
というはてなの質問に、なんと回答すればいいのだろう?
小松左京に「牛の首」というショートショートがある。
それは実は、題名だけが伝えられていて、その中身については誰も知らない、という物語なのです。
と答えたとしよう。
……そう。答えになっていない。
これが答えだと認識する人はいないだろう。
物語の中の「私」の状況が、物語を超えて現実の自分にも降りかかる。
「小松左京の"牛の首"という題名のショートショート」であるはずの作品が、その内容を説明しようとしたとたん、物語の中に自分が組み込まれてしまったことに気がつくという恐怖なのである。
以下余談。というか完全に蛇足だな。
それとは別に都市伝説として語られている"牛の首"という話もあるようなのだけど――。
それが小松左京の"牛の首"が発端であって、つまり、題名だけで中身の無い話に誰かが中身を与えようとした
出てくるのだけどそれを確認できないあたりもまた、この話の怖いところ。
*1 引用者註:本文では傍点での強調。
2008-03-16
■Set が Ruby にはないという話
に参加してでてきた話。
Ruby使いの人
「Java の Set って何?」
「Java の Set にあたるものって Ruby では何? と聞かれて分からなかった*1」
Java使いの人
「あぁ、Set って確かにあまり使わないなぁ」
「っていうか Map つまり連想配列のキーの部分と変わらないし」
私
「Set には実装として HashSet と TreeSet があるから、Set は抽象レベルの話で、Java では実装が選べるから……」
Java使いの人
「やっぱり結局ハッシュのキーの部分ってことでいいんじゃ?」
私
「いや、連想配列のことを俗にハッシュって言っているけど、それはイコールじゃないし。あぁ、説明できない〜。っていうか忘れてる〜」
となったのでその話。
import java.util.*;
public class Test {
public static void main(String[] args) {
Set s = new HashSet();
s.add("a");
s.add("b");
s.add("c");
s.add("b");
s.add("c");
s.add("d");
System.out.println(s.size());
Iterator iter = s.iterator();
while (iter.hasNext()) {
System.out.println(iter.next());
}
}
}
実行すると、
4 d b c a
こんな感じ。
s の中身は4つ。"b"を2回、"c"を2回 add しているけど、Set の性質である"重複を許さない"ためにそうなる。
重複要素のないコレクションです。すなわち、セットは、e1.equals(e2) である e1 と e2 の要素ペアは持たず、null 要素を最大 1 つしか持ちません。その名前が示すように、このインタフェースは、数学で言う集合の抽象化をモデル化します。
Java 2 Platform SE 1.3: インタフェース Set
ということ。
さて、上のソースでは interface Set の具象クラスとして HashSet を利用したのだけど、これを TreeSet にしてみる。
Set s = new TreeSet();
に変更するだけ。
実行結果はこう。
4 a b c d
つまりソートされた状態を保持するわけだ。
iterator で中身を全部吐き出す時や、first, last メソッドがその様に振る舞う。
Set を実装するにあたって"重複を許さない"という性質をどのようにするか? 逆に言うと"重複があるかどうかを調べる"にはどうするか? ということ。
単純に頭から重複があるか探していったら O(n) のオーダになってしまいます*2。
で、Java で最初から用意されている方法がハッシュを使う方法と、ツリーを使う方法。ってそのままカタカナに直しただけに見えますな。
後者は、赤黒木を使って、ソートされた状態を保った平衡二分木でデータを保持します。
前者は……全くややこしいことですが、ハッシュ=連想配列と考えている人が多いので困ります。
初期のJavaの実装では、まず11個の配列を用意しています。
add するオブジェクトの hashCode() メソッドを呼び、その11の剰余でそれぞれの配列に分配していきます。
なぜ11かというと、
- あまり配列が小さくて大きくても効率が悪い
- Object#hashCode はメモリアドレスを返す仕様になっているので、4や8の倍数になると予想される。その倍数や約数の配列を用意すると、全部の配列にうまくまんべんなく入ってくれない*3ので都合が悪い。
という感じで、適当に小さくも大きくもない素数として選ばれたんではなかろうか、と私は思う(きっと情報工学の初期にこういうことを研究した人がいて、ちゃんと論文もあるんだろうなぁ、とは思う。いや数論の分野かな?)
Javaでもあとのバージョンになると単純な剰余ではなくなり(計算時間を気にした? とも思えないけど、効率がよくなかったんだろうなぁ)、上の様な簡単な話にはならない。
でも、ある数の配列を用意して、それにうまく分散して格納していくことで、重複のチェックにかかる時間を 1/(配列の数) あたりまで減らすことができる、という考えは一緒。
本題はここから。 < おい
Ruby になんで Set にあたるものが無いかというと、連想配列(Ruby でいうと Hash クラス)のキーの部分だけ見ると同じ機構を持っているからなんだろう。
s = {}
s['a']=nil
s['b']=nil
s['c']=nil
s['b']=nil
s['c']=nil
s['d']=nil
p s.size #=>4
p s.has_key?('a') #=>true
s.each_key {|key|
p key
}
でいいわけで。
で、オチなんだけど、実はJavaも、古いバージョンの TreeSet の実装って中に TreeMap を持っているだけだったと記憶しているんだよね(今確かめる気はないけど)。
なんだよ、じゃ Set なんて要らないじゃん? とか思わなくもない。
けど、きっと Collection という一連のユーティリティとして、あった方が"完璧"つまり"キズが無い"ってことを重視したのではないかと。
そしてもちろん、抽象概念としての Set とその実装を分離することで、アルゴリズムやデータ構造に対して意識を向けさせられる。
私としてはそっちの方に大きな意味を感じるのだけど、開発の現場では結局あまり意識されない、というのもきっと事実。
(で、連想配列=ハッシュ という勘違いが広がるんだよ)
(最近でこそハッシュに、"大きなデータストリームの同一性のチェック"という利用価値が出て来たけどな。それを除けば、ハッシュといえば連想配列に使われる、ってことでいいんじゃね?)
関連
2008-03-15
■帰ってきた
楽しかったし、勉強にもなった。
昨日上手く寝つけなくてもう眠いのでもう寝ようっと。





