私はTwitterが怖い。これだけ人気があるサービスだけれど、私は少なくとも三つの問題点を見て取れる： 1)Twitterは心理学にいう「間欠的不規則報酬」のほとんど完璧な実例である。これはスロットマシンが人を惹きつける仕組みと同じ。 2)Twitterを使うことで得られる強力な「人とつながっている感覚」は、脳を騙して「何か有意義な社会的交流を行っている」と思わせてしまいうる。その一方で、脳の別の(古い)部分では、そこに人間の生存にとって重大な何かが欠けていると「分かっている」 3)Twitterは「常時マルチタスク状態」の問題を悪化させる要因の一つであるーーもしかしたら他のものよりもっと強力かもしれない。Twitterをしながら(もちろん、emailでもチャットでも同じ)、深く考え込んだり、フローの状態に入ったりすることはできない。

[注意: 私はこの問題について本当に少数派みたいで...ほとんど100人中99人がTwitterを支持している状態だから、たぶん私が間違っているのでしょうね(でもとりあえず書いてみるけど)。それと、この記事の大部分は、関係するテーマについて私が書いた様々な記事を混ぜ合わせて作ったものです]

この三点についてもっと詳しく見てみましょう：

1) Twitter スロット マシン

スキナーの発見の中でも最も重要なものの一つは、間欠的に強化された行動は(継続的に強化されたものとの対比において)、最も消えにくいということだ。言い換えると、間欠的な報酬は予測可能な報酬より優れているのだ。これは大抵の動物トレーニングの基礎となっていて……人間にも応用が効く。スロットマシンがあんなに人の心に訴えるのはそのためで、別に中毒にならずともこのことに気がつくことはできる。

Time誌のマルチタスクに関する記事より:

テクノ心理学者のパトリシア・ウォレスは〔中略〕Emailがーー十代の子供のみならず成人に対してもーー持つ魅力の一部はスロットマシンの持つ魅力に似たものだと主張している。「間欠的変動強化を受けているのです」とウォレスは説明する。「毎回報酬をもらえるのか、またどれくらい頻繁にもらえるのかがはっきりと分からないがゆえに、ハンドルを引き続けるのです」

2) 人とつながっているという感覚

多くの人にとってTwitterの最大のメリットは、他の人とよりつながっていると感じられることにあるようだ。カーソン・システムズのリサは、Twitterを擁護するテラ・ハントの記事へのコメントの中で、これを次のように表現している。

「Twitterは友達の感情や地理的な場所、動作を記録することによって〔中略〕このギャップを生めてくれる。まるで私たちが本当にそこにいるみたいにね。このおかげで『本当に』つながっているって感じになるの」

これは本当に良いことなのだろうか？

おそらく、答えはイエスなのでしょう。たぶん、ほとんどの人にとっては。けれど、「人とつながっているということは常に良いことだ」という反射的な回答は批判的に検討してみる価値はあると思う。UCSFの神経生物学者であるThomas Lewisさんは、「注意しないと、たとえ実際はそうでない場合であっても、人は脳の一部を騙してーーはるか昔より人の生存にとって不可欠なものであるーー本当の社会的交流を行っていると思わせてしまう」と主張している。これは不快な(しかし無意識の)認知的不合致、つまり脳が必要だと思っているものを取っているのだけど、「科学的に完全に分かっているわけではないけど、おそらく嗅いで感じられる何か」を満たすには足りないという状態につながる。彼はこれをTwitterについて言ったわけじゃないけど……Conference on World Affairsで彼の講演を聞いた時には、emailやチャット、さらにはテレビにまで言及していた(脳は「人々」を見ていると認識して、社会的関係を持っているに違いないと考える(GOOD)、けどそこには何かが欠けているとも気がついている(BAD))

Lewis先生はとても多くの研究を引いていたけど、私はそれを書きとめなかったので、このことは割引いて聞いてもらってもいい。加えて、私は彼がemailやチャットについて述べたことをTwitterに拡張していることにも注意。けれど、Lewis先生が言うことには、私たちがこのようになる理由の一部は、私達の脳が体の身振りや顔の表情や声の調子などを解釈する先天的な能力を発達させていて、こういう情報のチャンネルを予期していることにあるのだという。だから、社会的交流があるように見えているけれども、この先天的な、昔ながらの脳の機能の一部が働いていない状態になると、ストレスを感じるのだ。

繰り返すけれど、だからといってそれに見合う価値がないというわけじゃない。これは遠くに離れた家族や友達とつながっているには非常に有益なものだ。私が言いたいのは単に、これが一部の人々に「私はつながっている」という誤った感覚を与えていて、現実のつながりを犠牲にさせているかもしれないと問うてみる価値があるということだけ。

隣の人とコーヒーを飲むのは、千のTwitterの投稿より脳に多くを与えてくれるかもしれない。

これと同じような議論はずっとなされてきたし、テレビにだって同じことはいわれているけど、それだからこの話が間違っているということにはならない(孤立したカナダ人の村にケーブルがようやく開通すると、集団のIQが下がってしまったという研究がある...とルイス先生は講演のなかで述べていた。私はこの研究への引用をウェブで見つけることができなかったけど)

皮肉なことに、Twitterのようなサービスは同時に、仲間の輪の中に入っていないのではないかという心配を一部の人たちに植え付けて、「つながっていない」という感覚を起こさせる。「常に更新している」ことの重要性を高めることで、十分頻繁にtwitterをチェックしたり投稿したりしていない人たちの「何かが欠けている」という感覚を増幅させてしまうのだ。

3) Twitterは最も(厄介に)継続的な注意散漫状態を作り出すものである

前の私の記事より:

最悪なことに、この押し寄せる投稿は、私たちのほとんどを最も幸せにしてくれる「あること」から引き離してしまうということだ...つまり、フローの状態にいることから。フローの状態に入るには深く考え込み、意識を集中させる必要があるけど、この種のコンテキストを切り替えるものはそのどちらも妨げてしまう。フローの状態では知識やスキルを意欲的に使う必要がある。これはマルチタスクで(食べながらや、テレビを見ながらなど)できるような頭を使わない仕事とは全然違う。フローでいるには、ある程度の時間を使って知識とスキルを脳のRAMにロードする必要がある。そして、それが大きいものであれ小さいものであれ、より多くの邪魔が入るにつれて、ますますフローの状態にはたどり着き難くなる。

しかも、フローの状態に入れなくなるというだけではない。およそ何かについて熟達するということもなくなってしまい、エキスパートにもなれなくなってしまうのだ。脳科学者に尋ねてみれば、エキスパートとなるのに重要なのは天才かどうかではなく、物事に集中できるか否かなのだと教えてくれるだろう。

情報過多という現象に対する反動はもう見えている。Web2.0 VC はかなりの額を、情報を整理(されたままに)するサービスを約束する会社に注いでいるみたい。43 Foldersがトップ100のブログに入っているのにはそれ相応の理由があって、それは単にMerlin Mannがカッコいいというだけではないの ; )

たくさんの人がこのことについて語っている。でも、たぶんLinda Stone以上に雄弁な人はいないと思うけど:

継続的な注意散漫状態とは、半端な注意を払うということーーそれも絶え間なくね。これはネットワークのライブノードでいたいという欲求に基づく行動だ。別の言葉で言えば、私たちは人とつながりたいし、つながれた状態でいたいの。どんな時でも、チャンスを見逃さないように効率的に目を見張らせようとし、最も良いチャンスや行動や関係のために最適化しようとしている。忙しくすること、つながっているということは、すなわち生きているということ、他者から認識されること、そしてなにがしかの存在となるということなの。

絶え間なく部分的な注意を払うのは、何一つとして見落とさないため。常時つきっぱなしで、どこへでも、いつでも、どんな場所でも働くもので、人為的に作出された慢性的な危機感もこれに含まれる。この人為的で慢性的な危機感というのは、マルチタスクというより、継続的な注意散漫状態に典型的に見られるものよ。

要点:

Twitterを使うことにメリットがあると思う？　もちろん。Teraはこのメリットを本当によくまとめている(その全てがメリットであるとは考えない人もいるけれど、その人たちもテラの主張には賛成の立場に立っているのであって、大事なのはその部分)

人々がTwitterを責任を持って使えると考えているの？しっかりコントロールしつつ、twitterを使うことで注意散漫になりすぎたり、(タブロイドニュースやTVがアメリカでこれほどまでに広まった原因たる)覗き見のたぐいを避けて？

当然、そう思っている。

私が言いたいのは、ごまかしを避けて、「常に注意をそそぎつづける」というウサギ穴にどれだけ深く入り込みたいと思っているのかを判断してみるべきだというだけ。

私はTwitterのターゲットではなかったーー生まれながらの独り者なのよ。私はそこまでつながりあっていたいとは思わない。そして、ミステリーを残しておくという美学が大好きなの。それだけ多くの人たちについて、そんなにも多くを知りたいとは思わないし、人々にそんなに私のことを知ってもらいたいとも思わないの..それが日常のことであれその他のことであれね。だから、これは私がマイノリティたるゆえんで、私のTwitterに対する恐怖は、私独自のーーねじくれてあまり一般的でないーー個人的な性格に由来するものなの。

本文書は原文の著作権表示にしたがい、Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Licenseのもとで利用できる。なお、訳者の著作権は全て放棄する。

Permalink | トラックバック(6) | 20:26

2010-01-13

■http://okajima.air-nifty.com/b/2010/01/post-abc6.html

少し遅れた感があるけど、解いてみた。

出力がテキストでないけど・・・。

仕事の合間を使ってやったものの、昼前に始めたのが5時頃にようやくできる程度。

これを25分とは尋常じゃないな、大口叩くだけあってよっぽど優秀なんだろう。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;

<html&gt;

<head&gt;
<meta http-equiv="Content-Type" content="text/html; charset=shift_jis"&gt;
<meta http-equiv="Content-Language" content="ja"&gt;
<meta http-equiv="Content-Script-Type" content="text/javascript"&gt;
<meta http-equiv="Content-Style-Type" content="text/css"&gt;
<style type="text/css"&gt;
<!--

pre {
  font-family: monospace;
}

--&gt;
</style&gt;
<script type="text/javascript"&gt;
<!--

window.onload = function() {

  var q = new Map();
  q.load("maptest.txt");
  q.search();

  var answer = document.getElementsByTagName("pre").item(0);
  var answerText = "\r\n";
  for(var ix = 0; ix < q.route.length; ix++) {
    answerText += q.route[ix].join("") + "\r\n";
  }
  answer.firstChild.data = answerText;

  alert("終了しました。");
};

/** マップオブジェクト
 */
function Map() {
  this.ymap = [];
  this.route = [];
}

//マップの読み込み
Map.prototype.load = function(filePath) {
 //ファイルシステム
  var fileSystem = new ActiveXObject("Scripting.FileSystemObject");

 //ファイル読み込み
  var file = fileSystem.OpenTextFile(filePath);
  while(!file.AtEndOfLine) {
    var fileBuffer = file.ReadLine();
    this.ymap.push(fileBuffer.split(""));
  }
  file.Close();

  fileSystem = null;
};

//マップの探索
Map.prototype.search = function() {

  var that = this;

 //マップコピー
  var ymap = this.ymap.concat();
  for(var y = 0; y < ymap.length; y++) {
    ymap[y] = ymap[y].concat();
    for(var x = 0; x < ymap[y].length; x++) {
      if(ymap[y][x] == "S")
        var start = new MapNode(y, x);
      if(ymap[y][x] == "G")
        var goal = new MapNode(y, x);
    }
  }

  var openList = [];
  var closeList = [];

  start.costf = start.distance(goal);
  openList.push(start);

 //経路探索
  while(openList.length &gt; 0) {
    var node = openList.shift();
   //探索終了
    if(goal.equal(node)) {
      createRoute(node);
      break;
    }
    closeList.push(node);

   //隣接ノードの作成
    var tonari = [];
    if( ymap[node.positionY][node.positionX - 1] == " "
     || ymap[node.positionY][node.positionX - 1] == "G" )
      tonari.push(new MapNode(node.positionY, node.positionX - 1, node));
    if( ymap[node.positionY - 1][node.positionX] == " "
     || ymap[node.positionY - 1][node.positionX] == "G" )
      tonari.push(new MapNode(node.positionY - 1, node.positionX, node));
    if( ymap[node.positionY][node.positionX + 1] == " "
     || ymap[node.positionY][node.positionX + 1] == "G" )
      tonari.push(new MapNode(node.positionY, node.positionX + 1, node));
    if( ymap[node.positionY + 1][node.positionX] == " "
     || ymap[node.positionY + 1][node.positionX] == "G" )
      tonari.push(new MapNode(node.positionY + 1, node.positionX, node));

   //隣接ノードの検索
    for(var tx = 0; tx < tonari.length; tx++) {
      var openIn = false;
      var closeIn = false;
      tonari[tx].cost = node.cost + 1;
      var costf = tonari[tx].cost + tonari[tx].distance(goal);
      tonari[tx].costf = costf;

     //オープンリストから検索し入れ替える。
      for(var ox = 0; ox < openList.length; ox++) {
        if(tonari[tx].equal(openList[ox])) {
          openIn = true;
          if(costf < openList[ox].costf) {
            openList.splice(ox, 1);
            push(openList, tonari[tx]);
          }
          break;
        }
      }
     //クローズリストから検索し、オープンリストへ移す。
      for(var cx = 0; cx < closeList.length; cx++) {
        if(tonari[tx].equal(closeList[cx])) {
          closeIn = true;
          if(costf < closeList[cx].costf) {
            closeList.splice(cx, 1);
            push(openList, tonari[tx]);
          }
          break;
        }
      }
     //どちらにもない場合、オープンリストへ追加する。
      if(!openIn &amp;amp;&amp;amp; !closeIn)
        push(openList, tonari[tx]);
    }
  }

 //適切な位置に追加する。
  function push(array, item) {
    for(var ix = 0; ix < array.length; ix++) {
      if(item.costf < array[ix].costf) {
        array.splice(ix, 0, item);
        return;
      }
    }
    array.push(item);
  }

 //ルートマップの作成
  function createRoute(lastNode) {
    var node = lastNode.parent;
    while(node.parent) {
      ymap[node.positionY][node.positionX] = "$";
      node = node.parent;
    }
    that.route = ymap;
  }
};

/** マップノード
 */
function MapNode(y, x, parentNode) {
  this.positionY = y;
  this.positionX = x;
  this.parent = parentNode;
  this.cost = 0;
  this.costf = 0;
}

//同一ノードかチェックする。
MapNode.prototype.equal = function(targetNode) {
  if( this.positionY == targetNode.positionY
   &amp;amp;&amp;amp; this.positionX == targetNode.positionX )
    return true;
  return false;
};

//直線距離を求める。
MapNode.prototype.distance = function(targetNode) {
  sabunY = this.positionY - targetNode.positionY;
  sabunX = this.positionX - targetNode.positionX;
  return sabunY ^ 2 + sabunX ^ 2;
};

// --&gt;
</script&gt;
<title&gt;経路探索：A*</title&gt;
</head&gt;
<body&gt;

<pre&gt;&amp;nbsp;</pre&gt;

</body&gt;
</html&gt;

Permalink | トラックバック(3) | 19:23

2009-12-22

■魔女狩りの聖夜に

id:HiromitsuTakagiが遂にWinny ネットワーク観測・閲覧ツールNyzillaをリリースする。

Nyzillaの特徴

いわゆる「クローラ」ではなく、アドレスバーの「接続先」に入力されたホストにしか接続しない（接続先の指定はIPアドレスやドメイン名で行う）
接続先のWinny ノードから受信した情報だけをもとに表示する
「ファイル保持（Cache フォルダないしアップロード用フォルダに入っている）」を推定できる
表示されるのは、ノードでやり取りされているファイル名や保持の推定結果、参照数など
実際にファイルのダウンロードが可能か確認できる（ファイルの先頭数KBのみ実際にダウンロードする）

Winny 開発者である金子勇の著書では以下の様に書かれている（この文章はHiromitsuTakagiも引用している）。

しかしWinnyの場合、通信相手は不特定であり、Winny プロトコルを使う誰もが通信相手になれます。たとえば、Winny プロトコルを真似てWinny ノードに接続するようなプログラムの作成ができれば、接続相手のキャッシュファイルを観察することも可能です。このため、たとえどんなに強い暗号方式で通信内容を暗号化したとしても、通信相手は解読可能であり、通信内容は隠しようがありません。

また、Winnyのキャッシュファイルは、そもそも公開されているデータと考えるべきです。

金子勇著「Winnyの技術」p.151より

要するに、Winny ネットワークに入れるソフトウェアさえ持ってれば、そこでやり取りされてる情報は筒抜けだよ、と言うことだ。

Winny自体にはない機能だが、特定のIPアドレスでどんな情報をやり取りしてるかと言う事も、全部駄々漏れなのだ。

元々駄々漏れしている情報を見える化するだけなのだから、何の問題もなかろう。

そもそも、見られて困る様な事をしている方が悪いのだ。

本当にそうか？

駄々漏れている情報なら晒して良いと言うスタンスであるならば、RFIDタグやBluetoothによる追跡のプライバシー問題を取り上げていたのは何だったのか。

単に駄々漏れている「仕様」が問題だ、と言うだけなのか。

だとしても、Winnyの仕様を叩けば良いのであって、特定のIPアドレスで何をやり取りしているかを晒すツールを公開する理由にはならない。

RFIDタグやBluetoothの問題を語る時に、追跡ツールを公開していないのと同じだ。

システムの問題を語る為に、個人を攻撃する凶器を放流する必要は無い。

HiromitsuTakagiの意図がどうであれ、Nyzillaが公開されれば、個人を攻撃する為に利用する輩が出てくるだろう。

必ず、出るだろう。

IPアドレスさえ判れば良いのだから簡単だ。

mixiアプリが始まって、今やmixiのアクセスだって足跡と組み合わせてIPアドレスが取得できる。

気に入らないコメントをつけた奴とか、ID知られちゃって仕方なくマイミクにした上司とか。

偉そうな事言ってるけど、Winnyでこんなファイル流してるじゃねーか、と。

攻撃の為に使う人間にとってはIPアドレスが可変だとか、IPアドレス＝ユーザじゃないとか、そんな事はどうでも良い。

むしろ、全く無関係のWinny ユーザとIPアドレスがバッティングしてくれた方が都合が良い位だ。

架空請求詐欺にも利用出来るかも知れない。

未だに1クリック詐欺に引っかかる人が居る位だ。

「貴方の家の息子さんが著作権侵害を行っている証拠です」とか言われて往生する人も出て来るだろう。

或いは、悪意を持った攻撃者でなくても、単純な好奇心で知人のIPアドレスの利用状況を見てみる人だって居るだろう。

そこで運悪くIPアドレスのバッティングが起きたらどうするのか。

知識のある専門家がその技術を使うのと、知識のない素人が技術だけ使えてしまうのとでは、引き起こされる結果は全く違うものになるだろう。

ソフトウェアは一度公開されてしまえば、もう止められない。

Winny ネットワークが止まらないのと同じだ。

HiromitsuTakagiの意図がどうかなど知らない。

だが、Nyzillaの公開は今までのセキュリティ・プライバシー問題に対する言動とは明らかに次元が異なる。

その行動は「Winnyで違法行為やってる様な奴は叩いて良い」と言う倫理観に基づいている様に見える。

倫理観と言えば聞こえが良いが、要は私刑だ。

個人的には「Winnyで違法行為やってる様な奴なんかどうなろうが知らん」が、そんな攻撃に巻き込まれるのはお断りだ。

真っ平ごめんだ。

Nyzillaの公開は12/23だと言う。

クリスマスを前に魔女狩りが始まる訳だ。

これだけは言っておく。

最初に「魔女が居るぞ」と叫んで火を放ったのは id:HiromitsuTakagi、君だ。

今後何が起ころうと、Nyzilla公開によって起きる全ての責任は id:HiromitsuTakagi、君にある。

さて、増田諸氏よ。貴方達はどうする？

火を手に掲げて、魔女を探しに行くのか

降りかかる火の粉を恐れ、謂れのない糾弾に慄くのか

どちらでも好きにすれば良い。

Permalink | トラックバック(2) | 00:31

2009-12-01

■http://anond.hatelabo.jp/20091129223310

計算する問題が分割されたままで良い、という領域においては当然そうなる。分割したもの同士が相互作用しないのなら。

残念ながらシミュレーション系においてはそらGRAPEが扱うなかでもごくごく一部ぐらいだけがそうで（普通は共有メモリ内で参照できるからそんな高いコストを払わなくて良い）、それ以外はメッシュだろうが格子だろうがIBだろうが最低でも隣接する領域との相互作用計算のための共有メモリ外との通信が発生する。

スケールアウトできないのはものすごく雑に言うと、

・扱う問題が原理的に向いてない

・計算機同士のインターコネクトが今でも遅すぎるのにこれ以上遅くしたらまさに演算系の無駄

ってとこがものすごく大きい。

評価・統合などなどまあ使う方式で言い方も使い方もいろいろあるけど、分割しただけで統合したりする処理が要らないんだったら、まさにRoadrunnerのOpteronブレード部分は無用だよ。計算するだけならCellブレードとインターコネクトボードがあればいい。だがOpteronを使わなきゃいけない（というわけでも無いんだけどあれぐらいの処理能力とメモリバンドとローカルメモリはバランス的に欲しい）というところに何かがあると感じてくれ。これをかいてる自分増田は定量的に～とか言われると式をグダグダ書き連ねないと説明できない低脳なので。

長大ジョブを投入して計算中でも、計算を止めないままノードごと別のノードに引き継がせて、そのノードを捨てたり点検したり、ってのは超大規模クラスタではもちろんある。

（脱線するが、x86は縮退させにくいとか、信頼性が足りないとかいうのも最近みかけるけどそんなことはない。x86だからということはないし、ノードの設計とジョブの入れ方できまるようなもの。あとすべてのノードをVMにのせてジョブを続けながらLive Migrationした実証実験なんてのもある。x86系コア・メモリのRAS機能は充実してきてるとはいえまだ足りないが、RAS機能がホントに重要ならPOWER ベースにすれば実績と性能の点で申し分ない。x86の出自云々をいうならsparcだって出自がアレだしね。zシリーズにまで同一コアが使われるPOWERとは違う。脱線終わり）

それにスケールアップといったときに地球シミュレータの例はあまり適切ではないとおもう。アレは元々いろいろとアップグレードしにくいシステムだったし。

どうせならアップグレードしやすいCray XT5や、今度のXT6あたりで比較しよう。ちょうどJaguarのコアアップグレードは4Phaseにわけて実行された。

http://www.nccs.gov/computing-resources/jaguar/road-map/

コアの入れ替えだけなんでかかった費用は支援費の二千万ドル含んで数千万ドル（ちょっと語弊があるけど）。

あとJaguarはNCCSの配下にあるというのは一つの特徴だろう。利用時のスケジュールポリシーなんかもほぼ全部載ってるので、読んでみるといいよ。ちなみにNCCSのトップページにはいつも今配下のクラスタに投入されてるジョブがでてる。

ついでにGoogleのシステムはパソコンがベースって言って良いのかわからないぐらい特化してるよ。だから省電力でもある。それを安く調達するのはまさに規模の経済。

ToR スイッチを完成品じゃなくてBroadcomからチップ買って自前で専用のスイッチつくっちゃうのも規模の力。

最近いろんなところで引き合いに出されるNACCのGPU クラスタはコスト面とアルゴリズムで比較対象にもいい。簡単にいうと「苦手」なものを対象としないことで他の問題に最適化したのが濱田先生のところのチームがつくったクラスタ。特性を把握して性能を引き出して、実際に運用したという意味でとても良い研究なんだけど、故に超大規模クラスタとかで走らせることになる巨大CFD モデルなんかは対象外のシステムだ。

だから最近のスパコンうんたらかんたらとやらでNACCの話を持ち出してる記事やらエントリやらを見かけたら、そこに書かれてることは無視するといい。持ち出してくる奴は、基本からして間違ってるか何でも繋げればスケールアウトすると勘違いさせたがってるだろうから。

Permalink | トラックバック(0) | 03:57

■http://anond.hatelabo.jp/20091130233803

それも検討したけどさ、WinnyとかShareとかを相手に使わせたくないんだよね。配布する主要な相手がP2Pとか無縁な人達なので、既に公式に公開が停止されてるソフトの入手と設定(初期ノードやらルータの設定やら)を強いるのは避けたいんだわ。

ベストなのは、「関連キーワードをググればすぐに上位にヒットして、いくつかのリンクを辿るだけでダウンロード出来る、みたいな提供方式なんだけどね。

ちなみに公開対象はテキスト形式のログファイル群約100個合計約5.3GBを分割圧縮したやつ。

Permalink | トラックバック(1) | 01:22

2009-11-19

■http://anond.hatelabo.jp/20091119085753

まあLinpack走らせれば比べられるといえばいえるんだけどねえ。

なんかあのニュースに対する反応をいろいろなところで見て地球シミュレーターの凄さと京速計算機のしょぼさをわかってない人が結構いるなあと。

ESの凄いところは、NECにほぼ製品に近いものをつくってもらって買ってきて、気象予測に必要なだけ建物を埋め尽くして、気象予測のために改良がんばったら「原理的に不得意なはずの」ベンチマークソフトを走らせたときの性能ですらトップクラスに長いことい続けたということ。

製品に近いものを使ってるから、後継機が出てきて置き換えて電気代削減なんてできた。

京速はすごい一発狙いで「ぼくたちのかんがえるさいきょうこんぴゅーたをつくりたい」が先にたっちゃってる。すくなくとも今までのプレゼンはそうなってる。そういう場合、作るほうは何を基準に改良してよいかわからない。ベクトルとスカラー混在がだめになった時点ですでに死んでいるものを延命してどうする。

とりのこされた富士通が、開発費ジャブジャブ入れられて作ったとしてその個々の「何にも特化していない」ノードは外販できるのかよっていうね。

目的があっての演算能力と、そうでない演算能力はぜんぜん違うよね。前者が本来の目的のために出せる力と後者が想定していなかった特定の目的に使われたときの力では、ベンチマークソフトとはまったく異なる結果が出るものだよね。

Permalink | トラックバック(1) | 10:11

2009-09-16

■http://anond.hatelabo.jp/20090916142456

セクショニング・コンテンツ要素やセクショニング・ルート要素のアウトラインは、一つ以上の潜在的にネストしたセクションから構成されます。セクションとは、本来の DOM ツリーのいくつかのノードに相当するコンテナのことです。略（アウトラインの中のセクションとは、section 要素に相当するものもあるかもしれませんが、section 要素のことではありません。これらは、ただ単に概念上のセクションでしかありません。）

http://www.html5.jp/tag/elements/headings-and-sections.html#outline

セクショニング・コンテンツ

ヘッディング・コンテンツ（このセクショニング・コンテンツの見出しとなる）

アウトライン - 一つ以上のセクションから構成される

セクション - セクショニング・コンテンツでもよい

セクショニング・コンテンツならヘッディング・コンテンツ~~があることが期待される~~をおくことが出来る(なくても良い)？

アウトライン - 一つの段落のみのセクションかも知れない

セクション - セクショニング・コンテンツでなくてもよい

Permalink | トラックバック(0) | 16:31

2009-09-08

■http://anond.hatelabo.jp/20090908192852

用語並べるのはいいけど、勉強したことあるの？

ニューラルネットだろうがSVMだろうがなんだろうが（ていうかそこに並列にボルツマンマシンとかどう考えても枯れてる話を持ってくるセンスがよくわからん）、ノード数増やしたところで人間の思考に近いものすら作れないのはほとんど自明だろ。

人間の仕事を肩代わりできるだけの複雑さを持っていればいいんだ。あとはどうやって学習させるかの問題。

その「どうやって学習させるか」が大問題なんだっての。

無論ネットワークを構築するだけでは学習できないので外界を知覚するセンサーを与えたりしなければならない。人間と同じようなセンサーを与え、人間と同じような環境で学習させなければ人間と同じような知能にはならない。

簡単に言ってくれちゃってるけど、そのセンサーとやらはどうやって実現するわけ？

でその学習した記憶はどうやって人間並みの効率性でストックするつもりなの？

Permalink | トラックバック(0) | 19:56

2009-08-04

■雲をつかむような話

今朝の日経1面に日立とか富士通がクラウドに100億づつ投資、みたいな煽り記事が出ていて気持ちが暗くなる。VM の個別のインスタンス毎に(OS、アプリレベルの)設定は違うし、RDBMS を明日捨てるわけにもいかないだろうから、物理的なサーバやスイッチの構成が多少均一化されたところで自分の知識が1年後には全く無用になっている筈もないのだが。とりあえず VM ハイパーバイザと hadoop 等の練習はしといたほうがいいかも、ただ未経験なら採ってはもらえないらしいからやっぱりジョブリレバンスは疑問。

クラウドというのは廃熱は減らしても物理的ノード数を減らす方向には行かない(Core 7i をやめて Atom を複数並べる方向ということ)から、大手系列のチェンジニアにとってはむしろ朗報なのだと思う。DC電源化もなんともいえない。やっぱり AC で行くような気がする。iSCSI もイーサネット給電も(IP電話端末を除けば)普及していないし。

Permalink | トラックバック(0) | 11:29

2009-07-18

■ネット上で実際に流通している「児童ポルノ」の今後

児童ポルノ禁止法が改正されそうになっていた件で、個人的には単純所持禁止や二次元の規制には反対したいものの、未だにネット上で児童ポルノが流通しているのは確か。その辺をどうするんだ放置したままでいいのかという規制賛成派の指摘はもっともだと思う。

しかし、今時ウェブサイトに画像やら動画やらをアップロードする馬鹿は希少だろう。それを放置するウェブサイトの管理者も多いとは思えない。画像投稿掲示板の管理者が逮捕された例もあるわけで、国内外問わず、いやむしろ海外の方がよほどリスクが高い。

というわけで、専らその手のファイルってのはP2Pで流通していると思われる。国内だとWinny、Share、Perfect Darkといった所か？

だからこれらをピンポイントで潰すだけでかなりの効果が出るような気がするんだが、どうだろうか？

元々この手のツールなんてのは著作権的「クロに限りなく近いグレーゾーン」な存在なわけで、長い時間かけて消滅する方向に持って行ってもいいんじゃないかと思う。

大ざっぱに必要な作業としてはこんな感じか？

初期ノードサイトを潰す
- Winny、Share、Perfect DarkといったP2Pツールは、最初に起動する際に初期ノードを登録しなければそれぞれのP2P ネットワークに繋がらない(ファイルがダウンロード出来ない)。でもって有効な初期ノードを掲載しているサイトはちょいと検索すれば少ないながらも簡単に見つけることができる。まずはこれを何とか廃止に追い込んで、これ以上のユーザの増加を止める。ついでに、ファイル名とハッシュ値の組み合わせを蓄積しているデータベースサイトも潰す。
- とはいえ、わいせつ物でも何でもないただの文字列を延々と表示し続けるだけのサイトを潰すために、どんな理屈をこねるのかが問題だよなあ。仮に成功したら、その手のツールの使い方を解説している書籍類もついでにまとめて駆逐出来そうだな。
児童ポルノファイル共有者への警告
- どこまで本当だか知らないが、WinnyやShareの場合、任意のファイルを共有している者はそれなりに特定が可能らしい。まあ、どちらもバージョンアップが止まってから何年と経っているので、その間にいろいろと解析技術が確立されたんだろうな。なので警察だかプロバイダーだかがガンガン警告を送りまくる。削除しないと回線切るぞ、と。
- そもそもファイル共有者の特定が技術的にどこまで可能なのかがよく分からんし、特定する作業はどこが請け負って、コストは誰が払うのか、という所を解決しないといけないだろうな。Seti@homeみたいに、延々とP2Pに繋いでる端末のIPを取得し続けてしかるべき機関に報告するスクリーンセーバーなんてのを配布する、みたいな方法でいけるかな。それと、今のところIPアドレスからの個人情報照会は警察じゃないと出来ないんだっけ。