トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2006-02-26

_ #D

「on_scope_exit の代わりに (^_^) を使うとかかい?」 「それだwww」

(16:16)


2006-02-25

_ .machine pseudo-op

また今度見てみる。

これがないと GCC4 で GDC 作れない→ -framework は相変わらずできない、 となるようだ。

(16:13)


2006-02-24

_ こう使うべきだ

こう使うべきだ、っていうのはどうなんだろうな。 開発者は唯一それを希望できる人間である、 っていうのが僕の立場だと思うが、 いろんな正しい立場がありえそう。

(02:26)

_ 詭弁ガイドライン

http://www.hi-ho.ne.jp/inverse/kibennogaidorain.htm

(10:08)

_ lispに負けるなら本望

(14:16)

_ しーさー

(15:34)


2006-02-23

_ ニセ科学は

現象に対して、 「科学的」すぎる、わかりやすすぎる、はっきりしすぎる、 回答を与えることがあるという指摘は 非常に面白かったんだけど。

そう考えると社会科学とかが 陥りがちな誤りをいくつか説明できそうに思う。

(00:30)

_ sysprof

すげーすげー

(05:18)

_ core でバックトレースが出るということ

はなんかしら単なる mmap と loader のロードは違うことがある、と。

(13:58)

_ um の xorg.conf は変えちゃいけない。

なぜなら天才どろんじょ様が襲ってくるから。

(17:59)

_ どろんじょ様じゃないよバカ

それじゃメモにならないじゃないか。。。

um の X はモジュールのロードのミスると死ぬ。 /dev/input/mice, ModulePath あと画面サイズとか HSyncVSync。 Sync はモニタのボタンを押すと見れる。 そのへんでなおる。たぶん。

(21:13)

_ reddit

いつもはマイナーな関数野郎に圧迫されていますが。

ヘンなタイトルで投稿するとかどうだろう。 shinh.skr.jp:えろえろ とかで

(21:37)


2006-02-22

_ binhacks

ざっと思い起こすに、

  • まとめを書いてない
  • ロードしている共有ライブラリをチェックする は普通
  • C言語でリフレクション入門 は雑
  • libbfd でシンボルの一覧を取得する はなんか冗長
  • ffcall でシグネチャを動的に決めて関数を呼ぶ はそれなり
  • Portable Coroutine Library で軽量な並列処理を行う は普通
  • libdwarf でデバッグ情報を取得する はそれなり
  • dumper で構造体のデータを見やすくダンプする は雑
  • .o ファイルを自力でロードする は普通
  • GNU lightning でポータブルに実行時コード生成する は普通
  • libunwind でコールチェインを制御する はそれなり

普通>それなり>雑 という謎スケール。

(15:17)

_ 雑用

溜まりんぐ。

  • イタリア飛行機の領収書ゲット
  • 愛媛宿と飛行機振込
  • 愛媛領収書分離
  • 愛媛学会申し込み
  • 研究室メール
  • 実家メール

(18:37)

_ binhacks

  • gdb
  • gprof, gcov

あたりに手をつけてもいいかなぁ。あと LLVM とか。

それはそれとして、

  • C++ でポージング

をやってない。

(19:05)

_ ガルーダ2

2の部分がどうしようもなく情けない。

ラスボスに会えたわぁ。 1UP取り損なって、基本的にザコ戦調子悪くて ボス戦でバリア配分とか間違え気味って展開。 極めて限界が近い気もする。

(22:14)

_ estmaster@uk

は維持が無理なようだ。 んー estmaster どこで動かすかなぁ…

(22:24)

_ モンテカルロ囲碁

http://www32.ocn.ne.jp/~yss/monte.html

自由度高い場合はいい時もあるってことかなぁ…

(22:25)


2006-02-21

_

妙に現実に即してた。いくつか。

まずあの縦シューなんだ。 ボスラッシュが一瞬で倒せてるのは夢だから、 と認識してたにも関わらず起きてみると そもそもゲームの存在自体が不明。

1+x+2 はどうなるんだろうと夢見た。 http://d.hatena.ne.jp/w_o/20060220#p1

あと一点忘れた。 そこが一番現実ぽかったのに。

あとなんかはてなにものすごい量コメントがあったり。

(04:24)

_ 短命 addspace-region

神さまに聞いたら string-rectangle というのを 紹介していただいた。 C-x r t 。 [これはすごい]

(21:46)

本日のツッコミ(全2件) [ツッコミを入れる]

_ wo [夢の中の話ならいいんですが、それは、(0*0 + 1) + (x*1 + 0)が(x*1 + 1)になるので問題無い..]

_ shinh [あーはい、夢なのにそれなりに考えたっぽい内容だけどやはり全然どうでもいいというようなそんな記録でした。]


2006-02-20

_ addspace-region

車輪くさいけど作ってみた。

(defun addspace-region
  (beg end)
  (interactive "r")
  (save-excursion
    (goto-char end)
    (while (>= (point) beg)
      (beginning-of-line)
      (insert " ")
      (forward-line -1)
      )
    )
  )

(08:17)

_ 面白いパラドックス

http://d.hatena.ne.jp/Cryolite/20060220#p1

より

http://tinyurl.com/gnx9g

はまるなぁ。

とりあえず問題設定を、 他方は他方の二倍入っている、封筒を一つもらった。 中を見ると10000円であった、変更するか、しないか。 とする。

たぶんこれは数の密度の話と関係あるんじゃないかなぁ。 封筒を決める人は、まず一つの自然数 N を決定してから、 それを 2 倍する、というプロセスで N を決定したとする。 5000と20000が等確率であると考えているような問題設定から、 決定者は金に惜しみとかは無くて全ての自然数 N が 選ばれる確率が等確率、 つまり

各Nが選ばれる確率=1/自然数オーダの無限

は仮定して良さそう。 んで、 N として 5000 を選んだ確率と、 N として 10000 を選んだ確率を比較することになるけど、 うまく説明できないけど 5000 の方が二倍くらい密度が濃い。

んーと、 5000円の付近、5001と4999も似たようなもんだから 5000みたいなもんだと考える。 同じ比率で考えると、 10000円の付近、10001と10002と9999と9998は カスみたいな差だから10000みたいなもんだと考える。 で、4999とか5000とか5001とかからたまたま選ばれたのだから、 1/3みたいなファクターが選択される確率にかかり、 一方は1/5みたいなファクターがかかる。 というようなことを数学的に定式化すると うまく後者が1/2の確率になって、

5000*2/3+20000*1/3=10000

だから変えても変えなくても同じだべ、 となるんじゃない、かなぁ…

(20:40)

_ CDリッピング

http://slashdot.jp/comments.pl?sid=302929&cid=886936

これ面白いな。 クソエンコーダ作ってリッピングして配布はやっぱダメなんだろうけど。 しかしなんだろう。 鼻歌化するエンコーダとか作れば。

(22:10)


2006-02-19

_ ゲームメモ

カタン。 二人に独走されて結末どうなったか忘れるくらいサックリ負け。

ナイアガラ。 あんまいいとこ無いまま負け。 これも二人独走。 どんなゲームでも一人トップに比べて 二人トップはいかんともしにくい傾向が強い。

ラー。 競売ゲー。 なんかモニュメント集めて勝った。

陣取りゲー。 もうちょっとうまくやったら勝てたかなと思ったけどギリギリ負け。 見かけより案外早く決着がつく。 2戦目は瞬殺で勝利。

乗車券。 まぁ普通に割と理想的な感じで勝てた。 目的地追加はもうちょいした方が良いな。

アクワイヤ。 みんなやってるゲームだけにやれて良かった。 人のミス→最後の幸運、で勝てた。

まぁこの後は日和ったんだっけ。

メンバーズオンリーが無いとのこと。 賭けゲー。 これもなんか勝ったんだよな。

(19:59)


2006-02-16

_ 量子テレポーテーション

http://www.tees.ne.jp/~sin-x/200602b.html#1401b

とか見てて、(sin-xさんご自身はご存じだろうけど)量子テレポーテーションはネーミングの勝利なんだよなー、観測したらぶっ壊れるから簡単に移動できない、謎の状態の正体を正確に知ることはできない (aka no-cloning theorem)、とかいう厄介な特徴を克服するための移動手段にすぎないし、よくわからんものをよくわからんまま送ってるだけで、情報は光速だけでは伝わらんくて、実際量子テレポーテーションはスキームの最後で転送した側から転送された側に古典通信して送ったものを解読するヒントを送る必要があるのだから…とか思っててだいぶ前のスラドへの書き込みを思い出した。当時よりは少しは賢くなってる気はしないでもない。

http://slashdot.jp/~shinh/

(00:00)

_ 物体のテレポーテーション…

http://www.m-nomura.com/st/qteleport.html

(01:02)

_ "teleportation"

http://prola.aps.org/abstract/PRL/v70/i13/p1895_1

Bennet御大の命名かね…

(01:07)

_ WebDAV

PUTメソッド。成功時は 201 Created 。

COPY と MOVE メソッド。成功時は新規作成なら 201 。上書きなら 204 。

DELETE メソッド。成功時は 204 。

(03:52)

_ WebDAV

簡単ではない。

PUT は 201 Created で mod_estraier.c に来る。 ただし brigade に来てるレスポンスは Created の内容なので内容じゃない。 DELETE はそもそもフィルタに来ない。

→ 他のレイヤーでいじる。

(04:08)

_ binareal

なんだ画像に URL はってあるじゃん、と気付いて。

tree-widget をとってくる。

http://emhacks.sourceforge.net/

binareal のインストールはなんか失敗するので、templates/ 以下で

sudo make install pkgdatadir=/usr/local/share/binareal

んでなんか emacs の completing-read とフォーマットが違うぽいのでパッチ。

i@u src/binareal-20050311/binareal> diff -u path.scm- path.scm
--- path.scm-   2006-02-16 05:42:26.000000000 +0900
+++ path.scm    2006-02-16 05:45:37.000000000 +0900
@@ -35,7 +35,7 @@
 (define (binareal-template-list-templates)
   (map
    (lambda (f)
-     (substring f 0 (- (string-length f) 4)))
+     (list (substring f 0 (- (string-length f) 4))))
    (concatenate
     (map
      (lambda (path)

で、 (load "binareal") して hexl-mode 中で binareal-mode, binareal-decompose を実行。

(05:52)

_ 量子テレポ

すばらしきかなぐーぐる。

qubit A,B,C を用意して、 B,C はあらかじめからませておく。 Alice は A と B を持ち、 C を Bob が持つ。 A は unknown な state でこれを Bob に無傷で送りたい。 それには A と B に対して Bell 測定っていう 測定をすれば良く、その測定終了の時点で C は A に「近い」状態になる。 C を完全に A にするためには、 A と B を Bell 測定した結果を Alice は Bob に古典通信路で送る。 その情報を元に C をちょっと操作して、 Bob は A を得る。

一つ目。

http://www.m-nomura.com/st/qteleport.html

それだけ調べてなんで物体テレポができると考えたんでしょう。 量子テレポは最後に 1モルは10^23個くらいらしいんですが、 1モルの量子情報を送るには2*10^23 bit の古典通信が必要なのですが。 それができるんならスタートレックテレポーテーションができてる。

二つ目。

http://www5.ocn.ne.jp/~report/news/qteleportation.htm

物体をテレポートさせない、っていう記述はナイス。 そっから下のパズルがぐはあ。 とりあえず、なぜ、ハイゼンベルグの不確定性から 「無理に2つの粒子を量子的に絡み合わせると、 2つの粒子の持つ情報が失われてしまうはず」なんだろう。

最後の 「A、B、Cの粒子は物理的にどれだけ離れあっていても、 絡み合った瞬間に情報が送られるため、 見た目上は光速を超えていても、光速を超えれないという アインシュタインの法則にも反してはいないのです」 が謎。 「絡み合った瞬間に情報が送られる」んなら見事に光速越えてるじゃないか。

A と B をからめる、はいいんだけど、 それだけじゃ C に伝わらない。 A と B を測定して、その結果を古典経路で C に伝えて 始めて情報が伝わる。 古典経路は光速越えないのでよって情報は光速越えない、が正解。

てか暗号とテレポーテーションってそんな関係無いだろとか。 なんか弁証法がニセ科学と似てるんだよなぁ…

三つ目。

http://www.nanoelectronics.jp/kaitai/qteleportation/

双子のパラドックス=EPRパラドックスですか。

あとはだいたい良い感じ。

http://www.nanoelectronics.jp/kaitai/qteleportation/4.htm

の図がいい。

(18:03)

_ 分散バージョン管理を分散Wikiに使えないかな

http://www.jmuk.org/d/?path=2006/02/16#d16t01

を見てて思ったのでした。

(20:39)


2006-02-13

_ #D

D の irc に入ってみる。 なかなか率直な感じで良い気がする。 いきなり phobos hack guy かと聞かれて感謝されたのはビビったが。 ついでに throw のトレースが一行ずれる件について 調べ直して説明しておいた。 要するにデバッグ行情報が無い。

しばらく観察を続けようと思う。 とりあえず recls は快く思われてないようだ。ニヤニヤ。

(05:57)

_ しばらく見ない間に

D もなんかちょっと面白いことになってる気がするなぁ… 主に syntax sugar 。

(06:19)

_ すくいーずど

sq.jpg

びろん

(20:40)

_ ニセ科学

は案外めどい問題なんだな。

(20:40)


2024年
11月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
1.shinh(2006-02-23 00:52) 2.wo(2006-02-22 20:20) 3.shinh(2006-02-04 22:48)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h