ブログっ...!

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

ほげ

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

たとえば、あるファイルを読み込んで、それの一部を細切れの配列に格納したいときに (細切れの配列の長さ自体はファイル内に記述があって長さがバラバラ、それを読み込む度に毎度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 講座〜シグナルとコールバック)
 

読んだめも1

よんだはしかたないやつだ!(それは「やんだ」である。。)(よつばとネタ)


callccによる排中律の証明 - sumiiの日記

これ面白かったw
寸劇の話はcallccというワードがヒントになって、わかったw おもしろい。

callccがカリーハワード同型で二重否定に当たる、という話は小耳に挟んだことはあるが、
あんまりよく知らなかった(調べることを忘れていた)ので、調べた。
下のリンクの「call/ccの型」

call/ccと古典論理のカリー・ハワード対応 - 再帰の反復

途中の
λx.(Left x) : A→A∨¬A
のとこで、なんでこうなんだ?と思っていたが、そうだった。
記憶が薄れてて困る。
(下、AgdaのData.Sumリンク。
http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Sum.agda)
(ので、ひとつめのリンク先のInRight(λx:T. k(InLeft x)))は、
InLeft x : T v not T
k(InLeft x) : not
λx:T. k(InLeft x)) : T -> not
となって、InRight(λx:T. k(InLeft x))) : T v not T となるのが解釈。(%s/not/¬/g))
(いっこっつ型を確認する主義)

すごくわかりやすい記事だった...
しっかり理解している方の説明はしゅごいありがたい。

更にこれを読んで、納得してシメ。

http://www.kmonos.net/wlog/61.html#_0538060508

はわわ。。

あと次いでに、voidの話もよんだ。

void - sumiiの日記

Void (コンピュータ) - Wikipedia

あと、前回の記事書いた続きとして、
直観主義論理の話のリンクを超かみつまんで読んだ。

http://www.kurims.kyoto-u.ac.jp/~terui/summer2013.pdf


はっっ、こんなことをしていたらゆうがたに。。じゃあ。。

「構成的」ってなんだ

構成的という言葉の意味がわからなくなって調べてた。
調べたら、「数学的構成主義」「構成的数学」という言葉がちらちら出現。
それも追っかけてたら「数学的直観主義」などなども出現。

直感主義論理は授業でやったので覚えていた。

他もろもろ。

 

数学的直観主義 - Wikipedia

構成的数学とその周辺

数学的直観主義 数学的構成主義 形式主義

 

1) 直感主義論理

授業で先生が以下のようなことを言っていた。

------

A「私のこと本当に好きなの?」

B「好きじゃないわけじゃないよ」

古典主義なA「嬉しい♡ありがとう♡♡」

直感主義なA「ひどい!どういうことっっ」

------

 

2) 構成的論理

(二つ目のリンクがとてもよい。適当に主要だけまとめると)

  • 「現代では直観主義論理は、数学の証明は全て構成的に為されなければならないという主張(数学的構成主義)と関連が深い」(Wikipedia より)
  • あるものの存在dを示すには、dそれ自体を明示する。
  • 「非存在を仮定 => 矛盾 => 存在(背理法)」の流れでは示すことができない。
  • 「AまたはB」の成立を示すには、Aが成り立つことを示すか、Bが成り立つことを示すかどちらか。
  • 「not A かつ not Bを仮定 => 矛盾 => AまたはB」の流れでは示すことができない。
  • 「自分でそれ自体を確認するまでは何も言えない」考え
  • 古典論理に(強い)縛りをかけたものが構成的論理である。

肝心の「構成的」の意味は、「本質的」と言ったほうがしっくりくるような印象をもったんだが、どうだろうか。

 

※二つ目のリンクの冒頭で述べられていた通り、「構成的」という形容詞の解釈がゆらいでいた感じがあった。ちなみに、('constructive' の)英訳を読んでみると、日本語でのイメージとは結構違った。

Constitutively - definition of constitutively by The Free Dictionary

このページもおもしろかった。

アニヲタWiki(仮) - 数学的構成主義

 

3) 形式主義

このページ。

形式主義 ( 哲学 ) - honky tonk manの黙示録 - Yahoo!ブログ

 

でしたー。

二ヶ月のフルタイムイソターソシップを終えて

おっす、オラharukam

二ヶ月間のインターンシップが終わった。
たくさん学ぶこともあったし、辛いことも嬉しいことも起きた。
その過程で自分の悪いとこ良いところがよく見えた二ヶ月間だった気がする。
忘れないうちにそれをメモしておこうかと思った。

まずインターン先について説明。

 

インターン
あらゆる意味で"つよい" "最強"の会社である。
会社についての説明はこれで事足りる。(面倒なだけ)

インターンの評価が良いと、翌年もインターンできるシステム。
私は運が良かった。
昨年の夏、初めてそこでインターンをして、今年の夏も再びお世話になった。

昨年の夏は小さなチームでinternalなお仕事をしていたのに対し、
今年は世界中にたくさん使い手がいるproductをいじるお仕事でした。(ちなオープンソース)
使い手に近い部分なので、より一層"お仕事"っぽい経験ができたと思う。

強い方々に囲まれ、教育される毎日は本当に素晴らしかった。
全てが刺激的だった。楽しかった。
そして、社食は美味しすぎた。全環境が天国だった。お菓子うまい。

 

 

・長所

次に、この仕事を通じてわかった自分の長所。

 

1) 地道

以上。

はい、終了なんでしゅが。

 

 

・改善点

続いては、この仕事を通じて思った自分の改善点を。
以下、「この会社の方々」を「私の周囲で仕事をしていた方々」と置換して頂きたい。


1) 向上心

この会社の方々はとにかく、向上心が強いと思った。
いろんなことに対して好奇心があって、知らないことならすぐに取り込もうとする。
集中力もすごい。
仕事が速い。
マウスを触らない。
キーボード打つのメッチャ速い。
基本、会話が好きで、会話力も素晴らしい。説明がとても上手。

「つよい」
この一言に限る。

元々の実力もさることながら、
これまでプログラミング等々にかけてきた時間の多さも感じさせる、熟練した人たちばかりだった。

しかし、とあるものの素晴らしさを完全に知るには、それなりの力や経験が必要なわけで...
私はおそらく、この会社の方々のすごさの氷山の一角しかわかっていない。
(それでも、去年よりは人々の会話している内容が理解できることがちらほらあったので、嬉しかった。)

もっともっと、物事を知ろうと思った。
その過程で自分にとって面白いものを見つけうるかもしれないし。
(三十歳で「プログラミング楽しい」と思えた方もいらっしゃったので、
まあ物事は決めつけないでとりあえずやってみるものだ、と思った:D)

勉強会によく行って、consistantに刺激を受けるのも良いかな :)
週末になると行く気失せるけど。

 

2) 英語

英語です。英語!
これから、あらゆる場面で言語が英語になる。
英語が出来るほうが得られる情報が破壊的に多いので、consistantに英語を続けようと思った。

speakingも、listeningも。
consistantにやらないと言語は結果がでないものだ。。

 

3) 思い詰めすぎ、悪い意味で自意識が強い、失敗なんてどうでもよい

この仕事を絶対に今日までに終わらせる、という無理な計画を立て、
精神をボロボロにした挙げ句、観念して帰宅するということがあった。
「よくない」ことだと注意を受けた。
「テストをつくれ」
「どこまでうまくいっているのかを確かめて、問題を探索する部分を減らせ」

総計数日くらいは帰り道に
「こんなのができないなんて、もう私というゴミクズは死んでしかるべきだ」とよく思ったものだ。
基本的に自虐癖が強い。
目標ラインがしっかりしてない上に、目標ラインを自分の実力を凌駕するはるか遠くにうようよさせているため、
自虐癖との相性は最悪である。気分は落ちに落ち込む。

実際、こういう自分の無理な計画のせいで、やるべきことがないがしろにされてギリギリになってしまったりした。

「物事に近づきすぎているときは大事なことが見えなくなる」まさにこれだと思った。
そして去年社員さんに言われた
「仕事に自分のプライベートな感情を消費する価値はない。その境目はいつでも明確に定めておかないといけない。」
もよく思い出した。あんまり改善されていないな。

こういうところは自分の悪いところの一つ。
結構厄介な欠点なので、まあゆっくり改善していけたらと思うのです。

あとこれに関連したエピソードがもうひとつ。
最終日に英語でインターン仕事をプレゼンをする機会があった。
数日前に突然決まり、私は緊張に震えていた。
「死ぬ未来しかない」「隕石よ、落ちてくれ」と本気で思ったり。
ありえないと思った、自分が人の前で発表なんぞしているのが。

本当にひどく緊張していた。

ここで、とある辛口な社員さんから二言三言。

「一体、何をそんな緊張しているの。harukamさんがプレゼンで失敗するのなんて、
harukamさんが思っている以上の以上にどーーーーーでもいいことですよ。
誰も覚えずにすぐ忘れるよ。
harukamさんだから、ではなく、どのプレゼンもそんな感じ。
どーーーーーでもいいんですよ。」

的なことを言われた。
た、確かに。どうでもいいことだな。
と、とても腑に落ちた。

どうでもいいと思ったので、当日になるまであまり準備をしなかった。
なるようになれ。満身創痍で終えるのが一番自分らしいと思った。
(直前2時間は必死になって準備したけど、どうなっても良いという余裕があった。)
結果、英語力は社員さんに助けて頂いたものの、私自身がとても楽しめたプレゼンになった。
観衆がとにかく優しかった。反応が多くて、楽しかった。

どうでも良いことかもしれないが、きっと悪い結果になってもきっと学ぶことは多かった。
悪い方向にいっても良い方向にいっても、どちらにせよ収穫はあるので。。
まあ、あらゆる人にとってどうでもいい機会を積み重ねて(いろんな場所での発表とか)
その場にいる人たちには私が成長するための糧の犠牲になっていけばよい。

それくらいの気持ちで人生経験を積んでいけたら良いのでは、と初めて思った。

 

4) その場で即時に理解すること、会話をしながら考えること

ひどい。
見知らぬ人との会話が破滅的に苦手なことがわかった。
会話をしながら咀嚼することが本当に苦手なようだ。
自然言語をリスニングしながら、何かを考えることが。。

今までなんで気づかなかったのかわからないけど...

始めは英語だからだと思っていたが、日本語でも全く同じ現象が起きた。
足も手も痺れるような震えがおきたりした。

これはひどい
私は落ち込んでいた。

人々は「場数」だという。
ならば、場数をふむしかないな... あとは知識も。。

 

5) 人とのつながり

この会社の人々は結構フレンドリーで、いろんな人と話せたりして楽しかった。
「このまま仲良くして、わからないことあったら聞くといいよ。インターンの収穫の一つ。」
優しい社員さんがくださったアドバイスだが、私はとんでもない・恐れ多いと感じた。

しかし、いざ終わってみると、
そういえばあの人とは交流があったけど、つながりがなくなってしまった・・・
ということもチラチラ後悔。

人とのつながりを大事にしようと思った。
まあそれでも、そう後悔するくらいがちょうどいいと思ってしまうのだ(悲)

 

・まとめ

良い会社だった。

より一層、全てはソースコードitselfが語る、ていう気持ちが強くなた。

写真とかほとんど撮っていないし残っていないが、私はおそらく一生忘れないと思う。
たくさん学んできた。

時間がなくて、感謝の言葉をしっかり述べられなかったが、本当にありがとうございました、と何度でも言いたい。

 

ゆっくり、前進するのみである。
たまに後退するのもよしだ。

人生はフォーカスをずらすと解決することが多い。
「なぜ自分はこんなことをしなくてはいけないのか」それは実行もしていないのに考えるに値する問題ではなく、
実際にやってみてこそわかるものだ。ゲーテ的。