ブログっ...!

自分についてのメモしかないので、見る価値がないよ。(人に説明する思いやりが皆無に近いよ。)

くずのつぶやき

すごく好きな作品の作者との会話を思い出した。

私「なんでこんなの作れたんですか?」
A「毎日朝から夜まで作業する。周囲の馬鹿にする声は気にせず、悩んだら寝て起きたらまた始める。」
私「なぜ自分はこんなことをしてるか意味は考えたりしない?」
A「考えないですね」

そういう人間になれたら人生様々な可能性がある、かっこいいし羨ましい。
人を感動させることもできる。
残念ながら自分とは無縁の能力だと思った。

私のように時間を無駄に使うこともない。
人生何もしないには長過ぎる。
精神の健康のためには(生きることの意味を自分の中に留めておくためには)、何かをすることが必要だ。 それができない。

「なぜしなくてはいけないの」
そういう下らない問にやる気をなくして、考えることさえ放棄する。
いつまでも自分の心動かすものを待っている。 いつか、自分の可能な限りの時間を全てつぎ込むほど夢中になれるような何かがくるのを待っている。

まあ、でも言ってしまえば、なんてダサい人間なのだ。 頭ではわかっているんだけど、ねえ。。

「なぜしなくてはいけないの」
という問に万人が納得できるような答えを与えられる人はまずいない。
まず、そういう解答は存在しない。
自分の思考世界で閉じるような(自己満足できるような)理由ならば存在するが、それは一歩その人の思考世界から離れてしまえば効力を失う。

だから理由がほしいのならば、自己完結するしかないのだ。
そして自己完結させるには何かしらの思い入れがないといけない。
例えば、「xxするのが好き。」「自分にはxxしかない。」とか。
思い入れが思い込みに発展し、理由となって、執着になる。
この思い入れを生成するには、まず「何かを始める」しかない。

なのに、始める前から「なぜやらないといけないの」と言って、理由がないからはねつける。

自己完結できる人は、「他人がなんと言おうと自分はこう思うのだ」と強い意志をもって日々の時間を積み上げ、そしていつか成し遂げて、その集中力や執着心や熱意の結晶とも言える完成品で人々に感動を与える。
その姿のなんとかっこいいこと、羨ましいことか!!

まあ、ようするに暇なんだな。
あるいは「本来なら忙しいはず」なのに、逃げていて、時間が無駄にあるんだな。
日々作業に終われ、忙しく走り回る生活ならば、理由が定かでなくても「やらなくては」となるのだ。

退屈は一番の病だと脳化学の先生が言っていた。

「ではやればいいんじゃん」と言われても、やろうという気分にならない。
それでも前にはいくつもの課題があって。
速く片付けなければいけないのに、やろうとするとすぐに集中力がきれ、別のことを始める。
一度好奇心がつくと、寝ないで作業することもあるが、ほんとにごくたまに。

人間やることがないと、意味を失うから死にたくなるのだ。
生きる意味を考えることをせっかく放置したのにこのざま。
あー、ださい。

楽して死ねるボタンがあるなら今すぐ押してしまいたい。
または、感情や意識を失くしたい。

ネズミを見に行った

すごかった。

イソターソ先の社員さんにこの大会の動画を見せてもらった8月。 当時は、その動画を見てゲラゲラ笑っていただけだった。 どう実装されているのか、とか仕組みを特に考えず、 ただ、いくつも並ぶ駐車場(トラップの行き止まり)に丁寧に一個ずつ入っていくネズミがアホらしくてひたすらに面白かった。 壁にがつがつ当たるネズミを見て、ランチ中に爆笑したのを覚えている。

全国大会が11月にあると聞いた。ので決勝だけ行ってみた。

これ、すごかったwww 思った以上に熱があがった。 会場一致で
「おおーー!!(歓喜)」
「ああーー!!(残念)」
「おおーー!!(感動)(拍手)」
と、選手とともに一喜一憂するのは、スポーツ観戦のようだった。

そして生で見ると、不思議に思うことがどんどん出てくる。

・ネズミと相性がよく、かつ最短路である経路を探す
・物理運動とソフトウェアの組み合わせ、誤差とか
(内がもつ情報と、外(物理上)の情報の差、大変そう。電気工作やったことない人間なので...)
・座標をどうとっているの
・まがり角を極力減速せずに曲がる人すごい
ジェネリックに迷路をどう認識しているのか
(迷路には多種のトラップがあり、しかしトラップに見せかけた正解路もある。 例えば駐車場トラップに特化したような対策をとってしまうと、偽トラップに柔軟に対応できなくなるんじゃ。)

聞くと、座標についてはタイヤの回転・角度で求めているらしいが、スリップすることがあると、座標を誤って保持してしまって誤動作しがちらしい。 座標が狂うと、内情報では壁がないはずなのに、壁にぶつかったりしてしまう。(そうするとだいたいリタイヤ)

しかし、上位のほうになっていくと、スリップも含めた補正を効かせているらしい。 この辺、意味わからないが... レベルの高い人はねずみの重さを思い切り削減するため、その誤差の補正もすると。

決勝は予選の順位の低い人順にだいたい出場してくるので、終盤に近づくにつれ、みんなヒートアップ。

こじネズミ (こジマさん)、ふぁんとむ (まツイさん)、が一番印象に残っている。 最も自分と相性の良い、最短経路を一、二度の探索で見つけてしまう。 この二体は、もはや背伸びをしなくては見えない(ほとんど壁で見えない)(特にこじネズミのほう)。 直線距離が一番得意なこの二体は、一見すると遠回りに見えてしまう経路をあえて選び、 最後の一直線でとんでもなく加速する。 凄まじかった。。

結局一位をとった人(前年の優勝者、予選の一位(つまり決勝のオオトリ))は速度パラメータを最大にする前に最高記録を出してしまった。 「一位になることが決まったら、使おうと思っていた最大パラメータがあります。」 とラスト走りで、披露。全速力なのに、どこにもぶつからず、完走。
これが再び決勝最高記録になった。
これが最高に盛り上がった。
パフォーマーとしても、すごかった...

結論。すげえ楽しかった。 スポーツ観戦みたいだった。 しかも、不思議&感心する部分が多いので、絶えず考えているため、見ていて飽きない。

社員さんが、大会後、PRに来ていた社会人の人を紹介してくれた。(ありがたい)
そこにハンダ付けから行うメカネズミキットがあった。 ちょうど初めて見たかったし、買うか!となるも、 げえええ!高え!46,000 wwwww

ちょっと衝動買いするには学生には辛い。

また次回にしよう。
(しかし、そうなると、数年のスパンでやらない可能性が出てくる。。なるたけ早めに。。)

すぐ近くに解説してくれる方がいてありがたかったし、
おかげでよりいっそう楽しめたと思う。
本当にありがたかった。
メカ可愛いと思った。ミニ四駆してえ。
ジャイアンに没収されそうだが。。

じゃ(^^)ノシ

私的なこと

最近、神宮で起きた某火災事故で非常にやるせない気持ちになった。
(相模原の夏の事件でも同じような気持ちになった。年に2、3度ある。)

父親の悲痛に助けを求める声や、困惑しながらもオブジェを懸命に動かそうとする背中や、 更には遺体まで写っているとかいうショッキングな動画がすぐそばにいた人間によって撮影され、ネットに公開されているらしいが、もちろん見たくないし見るつもりもない。 (遺体が写るところ以外はテレビのニュースで放送されているため、一部は見てしまっていることになるが。)

もちろん、怖いもの見たさの好奇心がないわけでもない。 それでも事件概要を知った後では、見る気にならなかった。

ツイッターではほぼリアルタイムに火災を至近距離から撮影した画像が拡散された。 消火活動をする人の後ろ姿が写っていたり、手前の方には少し離れたところに立つ野次馬の姿やら。 その中で一番衝撃的でやるせなくなったのは、その野次馬がみんなスマートフォンを掲げていたことだった。

もちろん、どうすればよいかわからなくって立ちすくむのは仕方ないことだと思う。 もし私がその場にいたら、高確率で救助や消火に積極的に加わらず、恐怖で棒になっている。 展覧会で火災が突然起きて、(火のまわりが相当速かったらしいので本当に一瞬で) 「中に子供が」と必死で泣き叫んでいる人がその近くにいたら、 なんとか助かるように祈ることさえもできずに、ひたすらに震えて突っ立ていると思う。 完全にその状況が異質だから、そうなってしまうのが情けないかもしれぬが仕方ないことだと感じている。

それでも、撮影する神経については全くわからない。 安いジャーナリズム精神だか、話題稼ぎだか知らんが、撮影したものを売り出して一体それは何のためになるんだろう。 糾弾されるべきだと思う。父親が助けの手を求めて後ろを振り向いた瞬間を想像すると吐き気がする。

まあ撮影者の神経が理解できないというのは確かなのだけど、どうしても自分の中で説明がつかないことがある。 というのも、以下二点の疑問点より。
・動画を撮影することによって社会にインパクトを与え、(特に今回のような過失による事件では)再犯防止効果があるのでは
・事件を撮影する行為を否定してしまっては、写真家はどうするのか

一つ目は、まあまんま。 この事件がここまでフューチャーされたのも、その火の強さを写す瞬間が、悲惨な父親の姿や声が視聴者の感情移入を誘ったからであるのは間違えないと思う。 白熱電球が火災を招きえて危険であること、決して火災を起こす上で危険なのは火それ自身だけではないこと。等...

実際に私も恥ずかしながら事件報道当初、白熱電球で着火するのか、と驚いた。 (まあ美術館の大きな照明具に近づくとすんげえ熱いことくらいは知っていたけど。 いや、しかし続報を受けて、「配線を木屑の中に置く」のはさすがにあり得ないと引いたが。) 一部の人が知らない情報を大きなインパクトと共に植え付けたと思う。 (防げなかったことと違って、未然に防げたことはニュースにならないが。) 撮影し公開することにより良い効果があるのは確かかと。まあでも積極的にほしい効果かは知らん。

二つ目について。 このニュースで見て、新宿西口バスの放火事件を思い出した。 新宿西口バス放火と言えば、バスが映画のように燃え盛っているシーンを撮影した写真が思い浮かぶが、 その撮影者の男性の妹がこの事件で重傷を負っていたというのも同じくらい有名だと思う。 偶然通りかかったこの男性はプロのカメラマンで、撮影することが職業なわけである。

この男性を非難する声もあったらしいが、なぜか先ほどの事故と違って私は「ひどい」と思えない。

同じような感じで、ベトナム戦争の象徴とも言える「安全への逃避」という写真があるけど、 この撮影者も「救助をなぜしないのだ」と非難されている。

これも同様に「ひどい」と思えないのだ。

プロか、素人かってだけで、やっていることは本質的には同じなように見えるんだけど。 そこに信念があるかどうか。 公開時に自身の名前も付け加えているかどうか。 とかいろいろこじつけを考えてみたが、あんましっくりこない。

まあ、私がそう感じないだけで、一般的には報道写真家って一般には非難されることが当たり前なのかもな。 「でもいなきゃ少なくとも困る存在なわけである。記憶から消さないためには。」が真とすれば、 プロがいつもそういう瞬間に偶然遭遇するとは限らないので、たとえ素人でも撮影する道具があれば撮影することは肯定される。

それでも、今回の神宮の事件はあまりにも悲しいと思ったんだよ。 このあたりの説明がうまくつくまでは堂々と否定できないけど。


話はちょっと変わる。 私が数年前から思っていたことを書く。

思わぬ事故に巻き込まれて亡くなったり、大切な人を失ったりする人々は毎日だいたい一定数いる。 そういう人々は事態の直前までは普通の平坦な生活を送る人間だったわけである。(だいたいな)
それが一瞬で崩落して、死ぬ人はなぜ自分が被害に遭わなければいけないのか、わけのわからぬまま死に、 生き残った周囲の人は大切な人を失った不幸を一生背負わなくてはいけなくなる。

本当に理不尽な世の中なんだけれど、まあだいたいいろんなことが理不尽である。 平和な生活をしているので、大口を叩けないが。

私は「そうであってほしいと望むのなら、そうでなくなることも同時に覚悟しなければいけない」という考えである。

明日は〜しよう、とか、いつか〜しよう、とかいう望みは、そのときに生きていることを前提にしているけど、 対になっているものは確率はどうであれ起こりうる。 生きることを望むなら、死ぬことも覚悟しなくてはいけない。 勝手に前提にしただけなので、直面すれば有無を言わず受け入れるしかないのだ。

この考えが正しいと身にしみるとき、本当にやるせない気分になる。

おととい帰路についたとき、母親のことを思った。 母親には出来る限り健康に生きていてほしいが、それは健康に生きれずに死んでしまう可能性も暗に意味している。 明日にでも、何でも、突然母親が亡くなることになっても、受け入れるしかない。 そう思うと、泣けた。(本当に歩きながら泣いたw)

理不尽さをいつも念頭に置いて幸せに生活することは絶対にできない。 わずかにでも忘れるか、霊的なものに頼るかしないと。

私も数日たったら「いつか被害に遭うかもと構えてもしかたない」と、忘れると思う。

でも、やるせない事故がある度に、それを垣間みて虚しくなる。 そういうものだ。。

ほげ

なんだかプログラム書く度思うことなんだけど、 自分がいわゆるシステムプログラミングに詳しくないせいで、順序に迷う。

たとえば、あるファイルを読み込んで、それの一部を細切れの配列に格納したいときに (細切れの配列の長さ自体はファイル内に記述があって長さがバラバラ、それを読み込む度に毎度mallocするとする)、 一旦適当な大きなバッファみたいなところに全てを詰めんこんで、ファイルストリームを閉じてから、細切れにすべきか。 それとも、そんなバッファは使わず、開いたまま、細切れにしていくか。

結局今回後者にしたけど、前者は途中でmallocとか大げさな処理を挟まなくてシンプルでよさそうだと思ったんだよ。。ファイルの大きさが小さいとわかっているときは前者でも良いのかな。 それぞれの長所と短所isなに。

あと、複数配列があって、そのひとつひとつ別々に何か処理をするんだけど、 その配列はそれ一つで閉じているので、一つの処理が終わり次第、対象の配列を解放して良いとするじゃない。 処理A -> 配列A解放 -> 処理B -> 配列B解放 -> ... -> 処理Z -> 配列Z解放 てやると、ループ一つで閉じれるけど、

それでも、 処理A -> 処理B -> ... -> 処理Z -> 配列A解放 -> 配列B解放 -> ... -> 配列Z解放 てな感じで全ての処理が終わってから、解放する方が良いと思うんだよな。。 もちろん、解放は最後にするのがお行儀が良いからっていうのもあるけど、 解放がひとまとめになっているほうが、最近の入れ知恵、空リスト氏のキャッシュヒット率が良いのではないかという素人ながらの考え。。

実質的には行うことが全く同じ処理Aと処理A'のどちらが「速い」かを示すときに、 (たとえば、大域変数にするか、引数にするか、とか) 天秤がキャッシュヒット率くらいしかない。

こういうことを考えしまうと、プログラム書くのも遅くなり、故、すぐに疲れてしまう。 こんなの気をつけても微々たるものなので、そもそもの処理A, B, ..., Zを高速化することを考えてほうがよいのでは?というのは御尤もなのだが、ええい、気にしちゃうんだよ、どうしてもな...!! 一度抱いた疑問はなるはやで解決しておいたほうが良いと思ったので、ここにメモしておくのみである。。

システムプログラミング。。である。。

もごもご

make について。

makeよくわからないまま使い続けていたら、ハマった。 (.cmaファイルが not found と言われる。) (もちろん本当にそのファイルが存在しないだけなんだけど、.cmo等との違いがわかっていない) そろそろその仕組み知るべき時期かもしれないな。。 まあほどほどに。。

OCamlMakefileしか使ったことないけど。

あと部分文字列の話も。。。


めもとしてgitの話。

今日gitをおさわりしていたのだけど、困ったことがあった。 ひとつの大きなコミットが完成した。 実際は5つだったのだけど、リモートにpushするためにrebase -iした。

git rebaseでsquashした場合とfixupした場合の違い - Qiita squash と fixup

(git rebase -i hoge はグラフで書くとどんな感じなんだろうと一瞬思ったけど、まあ普通にhoge以後の変更をまとめた、hogeを親とする新しいコミットを作成して、そこをheadとするだけかな。)

しかし、このコミットの中には、pushしてはいけない内容が入っている。

Unityってオブジェクトの参照関係等を.metaファイルで記述しているらしく、 ちょっと他のSceneとかをいじるだけで、そのSceneの.metaファイルが更新/作成されてしまう。 その失意に更新された.metaファイルの変更を気づかないうちにまとめてコミットしてしまっていた。 あとは間違えてしてしまった関係ないファイルの変更とかも入っていた。

$ git commit --amend
new file: edit.java
new file: hoge.meta
modified: hoge2.meta
modified: edit.class

このhoge.meta, hoge2.metaが要らない。

上の2, 3行目を削除しただけでその変更を引いたコミットができあがるといいんだけど。。... (A)

まあ、結局
$ git checkout HEAD^ hoge.meta hoge2.meta
$ git add -A
$ git commit -m "deleted irane- files."
$ git rebase -i HEAD~2
squash ... "deleted irane- files."

でやったけど、普通にもっといい方法ありそうだし、(A)の方法で変更できる実装するのもいいし。

まあ、痺れを切らしたときに。

じゃあ。。

同前々3

まろくって。。

文字列(というかchar*)は、'\0'を末尾につけることにより、値の終わりを示せるわけだが、 まろく(mmap/sbrk/brk)はそのへんどうなっているの。。 よくよく調べてみれば不思議なこと(現状理解していないところ)が多い。

mallocによる確保外の領域への参照 - C・C++ 解決済 | 教えて!goo

これ見てよくわからなくなった。 (セグメンテーションフォルトがどういうときに起きるのかをちゃんと分かっていない。 C言語のポインタは私の思っている以上の以上に緩いらしく、(キャスト至上主義だと最近知った) セグフォはもっと、頻繁に起きるものだと思っていた。)

以下のようなアクセスのしかたは「確保していない領域を使用している」ので、セグメンテーションフォルトが起きてしかるべきだと思っていた。

1) (pelem_point+100)->x

あと、

2) ( (point *)(pelem_point+100) )->x

で構造体としてアクセスできるのはまあいいけど、 1)でも可能なのがよくわからなくなった。 (Cのコソパヨヤーの仕組みがよくわかっていない。)

・x[y] は (x + y) の糖衣構文 ... (i) ・x->y は (x).y の糖衣構文 ... (ii) と知ったときにはいろいろ理解が進んだ気がした。まあそうなんだけど... あと、こんな年にもなってひどいんだけど、structの宣言をポインタ変数でしかしたことがなかったので、ドット演算子があることを知らなかった。(おかむるいえーい)

第十三回-03 ドット演算子とアロー演算子

この話をもってくると、 (pelem_point + 100)->x は (ii)より、(*(pelem_point + 100)).x (i)より、(pelem_point[100]).x

ここで漸く納得である。

しかし、なぜこれで違反にならないかはわからないままだ。:-D

static /

C言語システムコール-brk CapmNetwork

mmap/brk/sbrkのmanぺじ読んでいると、知らない単語が出てくるので、調べると、またそのぺじに知らない単語が出てきて... その繰り返しである。

リンカの話が出てきたときは闇だった。なんせ事前知識が皆無に近いので。(そういうdocumentを見る程、他のぺじに飛ばされる数が多くなる。)

同前2

1) ブルームフィルタのお話。

サーバsに問い合わせたいファイル名のリストxがある。
このリストxに含まれる任意のファイル名のファイルfが、サーバsに全てあるわけではないらしい。
全てのfを実際に一気にリクエストすると通信負荷が大きいので、
「実体がsにあるf」のみだけにしたいところ。
sの管理するファイル数がほどほどに小さいなら、その全ファイル名リストをとってきて、それにfが含まれるなら、実際にお問い合わせする
という手でもいいが、まあ、そんな手で回るような世の中ではない。。

そこで現れるブルームフィルタ。詳しくは以下。
 

ブルームフィルタ - Wikipedia
 

この技術により、「fの実体がsにあるか」が確認でき、実際に通信するものを篩にかけることができる。
篩に通ったら、通信する。。
しかし、この篩は100%正確なわけではなく、
fの実体がsにないにもかかわらず篩に通してしまうことがある。
(小麦粉のダマとか普通に通す荒い篩あるよね。。)

・フィルタが「ないよ」って言ったら、ないことは確実 (本当はありました〜ということは起き得ない)
・フィルタが「あるよ」って言ったら、たまにないことがあるが大体はある


第一種過誤と第二種過誤 - Wikipedia

これ数理統計学の授業でやっていたけど、形式的に問題を解くゲーにしてしまったため、ほとんど記憶に残っていなかった。
帰無仮説については、その単語を聞く度に頭の中に「氷室京介」という固有名詞が浮かび、(語感が似ているからか?)
ほとんど内容が入ってこなかったことが印象ぶかい。

統計学の文章は、今全く読む気分じゃないので、搔い摘んで読んだ。超適当に説明することにする。

偽陽性(False Positive)は帰無仮説が実際には真であるのに棄却してしまう過誤
偽陰性(False Negative)は対立仮説が実際には真であるのに帰無仮説を採用してしまう過誤


ここで、ブルームフィルタの話に戻ってみる。
対立仮説 = 「ファイルがある」
帰無仮説 = 「ファイルがない」


ファイルfについて、サーバsのフィルタに問い質してみる。

i) フィルタ「ねえです」
a) fの実体がsにある場合
起き得ない。
b) fの実体がsにない場合
10割

ii) フィルタ「あるよ」
a) fの実体がsにある場合
8割くらい(例えば)
b) fの実体がsにない場合
2割くらい

偽陽性(False Positive)は帰無仮説が実際には真であるのに棄却してしまう過誤
ii)b)のケースにあたる。
もっていないファイルに対して、「もっている」と判定してしまうケース
偽陰性(False Negative)は対立仮説が実際には真であるのに帰無仮説を採用してしまう過誤
i)a)のケースにあたるが、ブルームフィルタでは起きえない。

もっているファイルに対して、「ない」と判定してしまうケース
 

2) コルーチン in C言語
以下、そのメカニズムをわかりやすく記録するために自己満足スライドを作成。
(もちろん、自分のためのメモなので、リンク先は自分だけしか見れない設定になっているし、そのURLも載せるつもりはない。)

アセンブリを読みたい気分になった。
以下の記事を読んだり。

Super Technique 講座〜longjmpと例外

(あと上記の記事を読んでる最中、気になるリンクがあった
Deep Side of Java〜Java 言語再入門 第2回 〜 例外
Super Technique 講座〜シグナルとコールバック)