Pictures.パントマイムが終わったら、シアターの中が明るくなるまでなにも見逃してはいけない。Thorの続編、キャプテン・アメリカの続編、アヴェンジャーの続編が本編前にある。本編エンディングだったか、終了後のエンドオールに入ってからだったかもしれないが、おそらく見逃してはいけない行動をトニー・スタークはする。IIIから、色々と集めた絵が表示される。これだけでも、脳内で内容が高速&並行で早送りされ、いろいろ思い出されて面白い。エンディングの後も見逃してはいけない。Thorの続編がもう少しだけ観ることができる。先のアヴェンジャーズでは別世界からいろいろ送り込まれて来て、トニーも張り切っていたと思う。PTSDを残していった。操る軍隊があること、標準兵装で対応できないことなど。3での敵は、コレまでと異なり、亜流アイアンマンではない。トニーは科学者であるから、合理的に考えるが、科学的にありえない存在が敵となる。幸いにも相手の数がさほど多くなかったことが幸いしたのだろう。叩きのせせたのにはもう一つ理由があって、各アイアンマンが、ジャーヴィスの制御下で各々の行動が可能だったのだ。各モデルを、もっとよく見えるようにして欲しかった。タフ・ガイみたいなのもいるし。マーク42は今回開発している、パーツごとに飛行と姿勢制御が可能で、スタークが走りまわていても自動的に装着できるようなものだ。おまけに、中身なしで合体して、ある程度動くこともできる。トラックに跳ねられてばらばらになるのはどうかとも思うが。MARVELとParamountがどう考えていたとしても、MARVELという面で似ている映画の公開は来年見たい。一度上映がはじまったら絶対に席をたってはいけない。それだけ面白いし、エンディング、エンドロールの前半、エンドロール後の予告も、本当に面白い。Tweet2013年04月26日00:49カテゴリギリシア語だとギリシア語だと制約に相当する語頭文字πなのか。音からのκ使えないし。Tweet2013年04月23日22:22カテゴリ研究関連Computerデータ形式まぁ、データ活用の基本企画は決まった。どのプログラミング言語でどういうデータ構造にするかは悩んでる。うーむ、空とかnullはφという記号を使うとして。不定ってのはなにかよく使われる記号ってあったっけ?普通に単一化みたいに考えてただの変数みたいに書いとけばいいのかな...。ギリシア文字とか使った方がかっこいい、じゃなくて目立つから、見た目で分かり易いのだが。空にεを使うのもふつうだな。∃と∀はこの記号でいいや。分野によっては不定なんとかをχを使うのもあるのか。直接は使わないけど、記号論理と述語論理を軽く読み直した方がいいかも。どっかに詰め込まれた本を探さないと。記号論理はどこにあるか分かっているけど。Tweet2013年04月21日13:25カテゴリ微分方程式まぁ、常微分方程式も偏微分方程式も忘れたけど。伯父が書いたものに偏微分の式があって、「なんでだろうなぁ?」と思ってたのだが、そういうことか。ミトコンドリアがどうのこうのということをやってたらしいけど。以前、伯父の手書きのもののほんの何枚かを挟んだ本ももらってた。これが面白いことに、数字も記号も文字も、私の字とそっくり。早い話が汚い字なんだけど。うちの母も不思議がってた。他にも、クセみたいなもので似てるというかそっくりなところがあるし。字がそっくりってのは、それでは説明できないような気がする。高校の時は、伯父に勉強も見てもらってたな。伯父としては、私を同じ分野に進ませたかったらしい。思ってたのかは知らないけど。computers)みたいなのとか、ナノマシン(人工細胞?)みたいなのとかやりたかった。大学受験時にどっちに進むか決められず、運に任せたらこっちになった感じ。両方受かってたら、そうとう悩んだだろうな。Tweet2013年04月19日20:42カテゴリComputeramazon.co.jpamazon.co.jpでkindleを出したころから、amazon.co.jpのマイストアの感じが変わった。amazon.comのと同じようになってる。amazon.comと同じようにするのは構わないけど、現状、amazon.co.jpのマイストアもamazon.comのもちょっと問題がある。マイストアで、本でもkindle本でもいいけど、">"を1回でもクリックしてみる。その上で、表示されてる本をクリックする。すると、その本のページにジャンプする。そこから、「マイストア」のリンクをクリックしても、ブラウザのバックボタンをクリックしても、キーボードのバックスペースボタンを押しても、マイストアでの表示が最初のものに戻ってしまう。(何回か">"をクリックしたときの)本をクリックした状態に戻って欲しいのだが。">"を何回かクリックした後で、元に戻ると面倒で...。クッキーあたりを使えばどうにかなると思うのだが。Tweet2013年04月19日18:33カテゴリComputer研究関連データ構造と使うプログラミング言語で悩んでるちょっと仕事で、扱うデータ構造と、それを処理するために使う言語で悩んでます。いうデータ構造にするのが楽かを決めかねてる。record)単位で済ましてしまうのは、記述能力が低い。できないことはないけど、「参照、参照」の嵐で、面倒になりそう。単純に考えると、多重の入れ子構造にするのが素直なんだけど。いわゆるリスト(あるいはS式)みたいなもの。プログラミング言語で処理をする時に、ぱっと見で、各々の処理で必要なところをデータから直に引っ張り出せない。引っ張り出す関数やメソッドを書けばいいだけだけど、言語によって書きやすさが違う。関数やメソッドを書いて独立させるにせよ、書かないでべた書きするにせよ、計算機にやらせるのだから、時間がかかるとかそういうことはとりあえず気にしなくていい。データ構造の基礎は単純であっても、実際に作るデータは結構面倒になるので、使う言語によっては、プログラムを後で自分が見たときに、「何をやってたんだっけ?」ということになりかねない。深い入れ子構造ではなく、比較的単純な入れ子構造にしといて、適宜マーカーを埋め込んでおくという方法もある。ある理由から、適宜マーカーを埋め込んでおく方法が実はいろいろと楽かもしれないとは思っている。データ構造の方は、そういうわけで、詳細はともかく、基本的にはリストにしとくのが楽かなぁとは思っている。事情があって、データの前処理にはRubyを使う。外部ライブラリの関係なので、Rubyでなくてもかまわない。以前Rubyで作った、そこのところのプログラムを使えるはずなので、前処理はRubyでやろうと思っている。言語について悩んでいるのは、前処理の結果を読み込んで、リストにして、いろいろ処理をするのにはどの言語を使うと楽かなぁと。前処理で、出力を微妙にリストにすることはできるから、その可能性も込みで。あ、前提として、正規表現を使えるととっても便利という条件はある。使えないなら使えないでやりようはいくらでもあるけど。Rubyも、リストの入れ子というか配列の入れ子はできる。Pythonも同じく。やり方しだいというところはあるけど、リスト操作や、リストでの入出力がちょっとやりにくいかなぁとも思う。LISP的なリストが頭にあって、その考え方をしているので、RubyやPythonではやりにくいと思うのかもしれない。データ構造もリストを基礎にしたものとは別のものもありうるかと思ってみたり。配列の入れ子の方が、ぱっと見では楽に扱えるようにも思えるかもしれない。それは配列の何番目にはどういうデータが入っているかが分かっていることが前提。表計算の列には、同じ種類のデータしか入ってない(なんでもいいけど、たとえば単価とか)。列の中で、このセルは単価、あっちのセルは製品番号というようになってたら、データとして扱えない。扱おうと思っているデータが、困ったことに、それと似たようなものになる。その程度の問題なら、適宜可能な範囲で整列させ直せばいい。ところが、扱おうと思っているデータだと、配列的にうまく扱おうと思っても、難しい場合があることがはっきりしている。配列的に扱う方法もないわけではないけど、例外処理になっちゃうので、ちょっと避けたいかなぁと。リストを基礎にしたデータ構造を想定しているので、LISP系統の言語を使うのが素直かもしれない。GaucheとかClojureとか、いろいろある。任意のデータを引っ張り出すのがなぁ。関数やメソッドの定義で済んでしまうことだから、そうするのが良いのだと思う。「REBOLは?」と聞かれるかも。日本語訳ドキュメント(一部)。)は日本語文字コードに対応していない。UTF-8(だったと思う)を使うが、処理系そのものがαテスト段階。αテスト段階でも、だいたいまともに動くみたいなんだけど、ちょっと不安もある。現状、データ構造を先に決めるか、使う言語を先に決めるか、なんだか卵が先か鶏が先かみたいな状況になってる。同じことが出来るなら、どうせなら楽に出来るほうが嬉しいし。目的とする処理にあまり向いていないデータ構造でも、力技でどうにでもできる。面倒だからそれは避けたい。力技でやると、バグの発見・修正が面倒だったり、後でソースを読み直したときに、「なにやってんだっけ?」(上にも書いたけど)となる。そこをうまい事やるのも技術なんだとは思う。私は別の方向での対応の方が好き。BEGINえーと、プログラミング言語によっては、それぞれに扱い易いデータ構造があるってことです。配列が扱い易い言語もあれば、連想配列が扱い易い言語もあれば、リストを扱い易い言語もある。使うデータ構造と、使う言語の相性がいいと、プログラミングがとてもやり易くなる。それから、仕事とかやる事によるところもあるという前提で。私の場合、あまり大きなプログラムは作らないようにしている。全体としてはある程度大きなプログラムになる場合ももちろんあるけど。基本的にある程度の機能ごとに独立したプログラムを書くようにしている。それぞれの機能のプログラムごとに、異なるプログラミング言語を使う場合がままある。それぞれの処理や、データの扱いを、それをやり易いプログラミング言語で書く。それが可能な仕事とできない仕事もあるけど、私の場合、それをやっても構わないので。プログラム間のデータの受け渡しは、ファイルにするのがたぶん一番簡単。その場合はファイルの書き出し・読み込みに少し時間が取られる(OSが提供するキャッシュとかRAMディスクはあるけど)。場合によってはパイプとかプロセス間通信とか。それでも、モノリシックなプログラムより、実行の効率は下がるだろうけど。個々のプログラムの開発や修正は、その中でとりあえずまとまっているので、作るのも理解するのも覚えるのも修正するのも楽。必要なときに、「あぁ、あのプログラムか」と思うと、ソースコードが頭の中に全部展開されるくらいの感じ。必要があればモノリシックで大きなプログラムも書くけど、できるだけそういうのは避けるようにしている。モノリシックで大きなプログラムを書かないといけないときでも、効率は落ちても、それなりに分割して考えられる単位に分けるようにしている。あとは、処理によってはmakeを使って処理手順を書いたりする。makeを使うと、たとえば拡張子(.exeとか.docとかいろいろ)などによって、これこれの処理をする際には前もってあっちをやっとかないといけないなどなどを自動化できるので楽だ。いう機能があるのと、プログラムを処理ごとに分割してあるので、途中結果をファイルに書き出しておけば、その続きの処理を先と異なるパラメータで計算することもできるし。パラメータと言えば、プログラムの動作に関するパラメータも、プログラムの起動時に渡すものとして何種類もそれぞれの処理として記述しておけるので、ソースコードを見ながら、「さっきうまく動いた時のパラメータはどうだったっけ?」とか「直し終えてない場所はないよな?」とか、頭を抱えなくてすむ。だいたいソースコードにいくつもの値がコメントとして並んでいると、それぞれについての説明も書いておいたとしても結構混乱するんだ。