Hatena::Groupayucat

ayucatの日記 RSSフィード

2009-09-19

恋人関係が長く続く秘訣

|  恋人関係が長く続く秘訣 - ayucatの日記 を含むブックマーク はてなブックマーク -  恋人関係が長く続く秘訣 - ayucatの日記

ふと暗闇で出くわした旧友に伝授してもらうため、ふんわりまったり系のカフェでプレートライスよりシンプルな料理をいただく。

ちなみにお金は二人分払っておいた。

ハードな三週間であった・・・

| ハードな三週間であった・・・ - ayucatの日記 を含むブックマーク はてなブックマーク - ハードな三週間であった・・・ - ayucatの日記

実にハードであった。気づけば、シルバーウィーク突入でもうすぐ今月も終わり。

異常すぎる早さで時間が経っていく。

2008-08-25

coLinux 0.7.3に入れたUbuntu 7.10を8.04にアップグレードする part 1

|  coLinux 0.7.3に入れたUbuntu 7.10を8.04にアップグレードする part 1 - ayucatの日記 を含むブックマーク はてなブックマーク -  coLinux 0.7.3に入れたUbuntu 7.10を8.04にアップグレードする part 1 - ayucatの日記

私はcoLinuxが好きではないし、やや過去のモノだという気持ちも拭い切れないんですが、どういうワケだか実務レベルでの試用を行なっています。

教科書どおりの作法

$ sudoedit /etc/apt/sources.list

$ sudo aptitude clean

$ sudo aptitude update

$ sudo aptitude safe-upgrade

した。

たくさんのパッケージのためにlibdb4.6を入れる

上の結果を見て、

$ sudo aptitude install libdb4.6

をしないといかんな、と気づいて、

$ sudo aptitude install libdb4.6

$ sudo aptitude safe-upgrade

とする。

これでも

69 not upgraded

とか言ってるし。

aptitudeのためにlibcwidget3を入れる

aptitude(hardy)libcwidget(hardy)を欲するようになったとかあるので、

$ sudo aptitude install libcwidget3

$ sudo aptitude safe-upgrade

とする。

64 not upgraded

gccが4.1から4.2になった

gcc(gutsy)では

gcc-4.1(gutsy)だったのに、

gcc(hardy)から

gcc-4.2(hardy)となったので、

$ sudo aptitude install cpp-4.2 gcc-4.2

としたら、

GCC OpenMP (GOMP) support libraryもくっついてきたので、結局、

$ sudo aptitude install cpp-4.2 gcc-4.2 libgomp1

相当。

ここで、safe-upgradeすれば、

62 not upgraded

hal, hal-infoなどのために。。。

分からんので、保留。

ubuntu-standardの道連れでufw, bash-completion, friendly-recovery, mlocate, uuid-runtime

が必須で、

その他の

も推奨で勝手に入ってきたけど、そのまま入れちゃう。

61 not upgraded

このへんで休憩

時間切れ。

2008-08-24

百度が速いわけと人力はてなの回答のひどさと。

| 百度が速いわけと人力はてなの回答のひどさと。 - ayucatの日記 を含むブックマーク はてなブックマーク - 百度が速いわけと人力はてなの回答のひどさと。 - ayucatの日記

百度は、なんであんなに速いんでしょうか?

http://baidu.jp/

【予想】

・検索サーバが全部SSDだ。

DBが完全にメモリに乗っかっている。

インデックス数が少ない

・テラビットイーサネット

百度は、なんであんなに速いんでしょうか? http://baidu.jp/ 【予想】 ・検索サーバが全部SSDだ。 ・DBが完全にメモリに乗っかっている。 ・インデックス数が少ない ・テラビットイーサネットだ

いや、まー答えは何でもいいんだけど、さ。

id:verify

1 回答者:verify 2008-02-15 23:30:24 満足! 14ポイント

日本で誰も使ってないからでは。

やっぱこっちでしょ。↓

http://google.co.jp/

マジつまんなすぎ。質問者

はい、次の方どうぞ。

とかかわすしかない気分が分かる。のに、14ポイントって><

id:hagix

2 回答者:hagix 2008-02-16 03:56:49 満足! 14ポイント

http://fnconf.blog98.fc2.com/blog-entry-59.html

他の検索エンジンに比べて精度が低いから。。。。と、勝手に思っていました。

???

質問者のリアクションのように、

うーん、精度が低い = 速い というのが単純なイコールではないような。

である。正直言って論理的に飛躍しすぎ。

はい、次。

id:yo-net

3 回答者:yo-net 2008-02-16 13:14:35 満足! 14ポイント

回答とずれていたらごめんなさい。

多分ユーザ数が少ないからだと思います。

さらに、付け加えると、分散サーバで日本のサーバはjpアドレスからのアクセスに限定しているから、

ユーザ数が少ないのと合いマッチして早いのでは。

CEOが開発した検索アルゴリズムも関係しているかもしれませんが、良くわかりません。

[...]

これがもっとも近い気もするけど、それだけじゃ答えになってないだろうなぁ。

id:jagging

4 回答者:jagging 2008-02-16 14:29:52 満足! 14ポイント

早いんですか?

早い・・・確かに早いですね。

そんな回答中で聞き返しても><

...とかいう私も回答するを押してから調べることはあるけれども。

プログラマが優秀(または優秀な人が身軽に仕事が出来る)

サーバーを絞ってる(最適化されてる)

プログラマが優秀だとどうしてレスポンスが早くなるのかを聞いていると思われる。サーバを絞っている、最適化する、の意味が分からない。

個人的には、早いのは当たり前なので、

あなたのエンドユージングのことはおそらく質問者は聞いていないんだよ。

そういえば、

話、飛躍しすぎ。

ニコニコ動画とかは

一月で100倍増になったアクセス

サーバーを13台くらいで、チューニングのみで乗り切ったとかで、

技術凄いらしいです。

どうすごいのかよく分からないけど、一ヶ月で1アクセスが100アクセスになったのをサーバ13台もかけてチューニングもしなきゃいけないなんて全然技術力ないYo!!!

せめて、百度ニコニコ動画アクセス数の比較をしてくれ。説得力に欠くなぁー。

サイト運営では、

大手より、ベンチャーの方が、よっぽど効率の良いサイトが多いように思えます。

http://blog.nicovideo.jp/nicolumn/2008/01/000826.html

ん?どっちのことを大手と言って、どっちをベンチャーと言っているの?

百度公司ができたのは1999年*1で、ニコニコ動画の運営元の株式会社ニワンゴができたのが2005年*2だから、前者が大手で後者がベンチャーと言っている?

...そもそも論理的破綻だらけなので、そんな細かいとこいいや。

id:turkey_hate

5 回答者:turkey_hate 2008-02-16 18:11:24 満足! 14ポイント

・広告が無い

日本版の百度は広告に関する処理(ReadもWriteも)が無いからでは?

→本家の百度(http://www.baidu.com/)は広告が出るのだけど、やっぱりそんなには速く無いような気が。

インデックスが少ない

検索結果の件数もGoogleの方が一桁くらい多いですね。

あと、百度は国の政策で、内容によってインデックス化出来ない物が

あったりなかったり?

たとえば、天安も

・・・ん?

すいません、玄関に誰か来てるみたいなので、後で続きを書きmas

やっとまともな議論になった!

id:KUROX

6 回答者:KUROX 2008-02-16 19:03:58 満足! 14ポイント

(1)検索結果のキャッシュっぽいものをもって、ごまかしてそうな感じ

   同一キーワードで検索した場合に検索時間の差が激しすぎる

   Googleは毎回ほぼ同じなんですね。

(2)2バイトコード(漢字)を初めから想定した設計をおこなっていて

   その点で、有利な点がどこかにあるとか

1は分かる。2は不明。というのは質問者も述べている:

> 検索結果のキャッシュっぽいものをもって、ごまかしてそうな感じ

そう、画像検索で、個々の画像をぽろぽろ読み込むような感じが全くなく、一発ですぱっと全サムネイルが表示されるんですよね。(こちら側の回線が光の場合)これができるのは、あらかじめページがメモリ上にキャッシュされて、ディスクアクセスなしでレスポンス返せるからじゃないかな、と個人的には思っているのですが。

> 2バイトコード(漢字)を初めから想定した設計をおこなっていて

これがわからない。

baidu の外側の文字コードUTF-8で、文字コードの変換なしに入出力した方がサーバ側の効率はよいような気がするんですよね。とすれば、検索DBもUTF- 8でまるごと設計してしまった方が変換処理が入らない分速いような気が。ちがうかな。。。そもそもUTF-8のマルチバイトコードは3バイトじゃなかったでしたっけ。

id:myusky

7 回答者:myusky 2008-02-16 21:19:12 満足! 14ポイント

最初から中国語と限定してやってきたプログラムだから、

2バイトに強いという話がこちらに。

http://japan.cnet.com/interview/media/story/0,2000055959,2036716...

マルチバイトの強さと速度には関係なさそうな気もするし、リンク先は機能的な話で速度に関しては述べていないなぁ。

id:knaka20blue

8 回答者:knaka20blue 2008-02-17 00:18:15 満足! 14ポイント

(狭義な意味での検索エンジンとして)

GoogleYahoo!との比較で考えると

>・インデックス数が少ない

はとても大きいと思います。

クエリに対してヒットするドキュメント数が少なければ

ドキュメント毎にスコアをつけてスコアの大きい順にソートするという

処理の時間が短くてすみますから。

確かに。

(日本語のページに限れば1億ページもあれば99%以上のクエリ

100ページ以上を返すことは容易でしょう)

ん???

あとはヒットしたドキュメントに

スコアをつけるアルゴリズムが簡単というのがあると思います。

Googleスコアリングアルゴリズムの複雑さはよく語られていることで

この辺を端折っているとレスポンスはかなり良くなると思います。

baiduがgoogleのそれよりも複雑でない明らかな理由がないなぁ><

もちろん可能性としては有力だとは思うんだけど。

id:knaka20blue

9 回答者:knaka20blue 2008-02-17 16:56:17 満足! 13ポイント

>でも、キャッシング機能をもった検索サーバを日本においてよかったんでしたっけ?

この辺は近く法律改正されるみたいですね。

http://www.mext.go.jp/b_menu/shingi/bunka/gijiroku/013/07100407/...

現実はクロールしたキャッシュ

国内に置いているサービスなんて山ほどあるわけですし...。

なるほど、参考になります。

10 回答者:hirokiea 2008-02-17 18:22:39 満足! 13ポイント

結果ページのHTMLソースが軽いためじゃないですか。

DVDで検索してみたところ、baiduが20kb、googleが40kb、yahooが60kbでした。

ブラウザの表示って、回線やサーバーの性能が高くなった昨今だと、意外にボトルネックだったりしますよ。

唯一鋭い指摘。

客観的データを与えているのはこれだけですね。

もっとも内情を知れる人はここには書かないだろうけど。

id:quocard

11 回答者:quocard 2008-02-18 17:56:36 満足! 13ポイント

広告がないというのが大きいかもしれませんが

 ・利用者が少ない

 ・検索をするデータベースがそれほど大きくない

というのがあるのではないでしょうか。

始まったばかりというわけではないですが、クロールして集めているデータの

量がgoogleなどより少ないから早いという見方も出来るかもしれません。

上のほうの意見と同じ。

 またSSDやテラビットイーサを使用したとしても途中のネットワークボトルネックになって

それほどの効果を発揮できるかどうかは疑問が残ります。

そんなことはないけどなー。

id:KUROX

12 回答者:KUROX 2008-02-20 23:07:24 満足! 13ポイント

こんばんは

DBにシングルバイトのカラムとマルチバイトのカラムがあったとして、マルチバイト側の方が

速くなる設計ってどんなんなんでしょうね。不思議。

http://japan.cnet.com/blog/tamon/2006/09/15/googleoraclebig_6721...

データの持ち方とかそういう基本的なものではないでしょうか?

あと、表示はUTF-8だとしても、実際に持っているデータはどういうコードか不明です。

その不明なコードだとUTF-8よりもマルチバイトで速くなるの???

id:RIKKUN

13 回答者:RIKKUN 2008-02-21 10:28:02 満足! 13ポイント

http://www.nextglobaljungle.com/2008/01/fc2.html

アダルトフィルタデフォルトでOFFだから、不要なフィルタリングコストの分速いとか・・・。

質問者:biz_tanaka 2008-02-21 13:19:38

ああ、なるほど。

それもありますね。

しっかし、すんごい画像がヒットしますよね。なんだこりゃ。

id:yukimasa_2k

14 回答者:yukimasa_2k 2008-02-22 00:28:52 満足! 13ポイント

憶測&上の方々もおっしゃっていますが、アダルトフィルターの有無が一番大きいのではないでしょうか。

文字だけを見て除外するにしても、するとしないでは大違いですし…。

まぁ、そうかもしれないねぇ^^

総括

あまりこれと言った図星的回答も革新的なアイデアも得られず。

はてなクオリティですか?

2008-08-02

離散データの高階(高次)微分が分からない

| 離散データの高階(高次)微分が分からない - ayucatの日記 を含むブックマーク はてなブックマーク - 離散データの高階(高次)微分が分からない - ayucatの日記

みんな大好きXPathGraph最近のグラフを見てたら、

おそらく d:id:ka-nacht 氏 (また、そしておそらく、@kana) が

http://xpath.kayac.com/graph/HoUXrRhf3RGCvw

ってのを作ってて、私も最近、高階微分で悩んでいたので、勢いあまって

こんなにも無駄な有用なグラフを作ってしまった。

さて、d:id:ka-nacht 氏の no title は、おおもとの

の一階微分

をさらに微分したものである。

だから、おそらくd^2/dt^2のデータは二日分遅れているはず(離散データの微分はどこの微分かなのか、ってのが私は理解できていない><)。d/dtが一日遅れているとするならば。

二回、微分をすれば、二階微分であることくらいは高校生でも最近じゃ中学生でも、いや、小学生高学年くらいでも、知っているであろうが、時系列なんかの場合、

(X2-X1)-(X1-X0)=X2+X0-2*X1

であることを使って一発で二階微分が求まる、、、

んだけど、これで合っているのか悩んでる><

離散数学も解析もろくにやっていないから、分からんとです。誰か教えてえろいひと。

じゃあ三階微分

(X3+X1-2*X2)-(X2+X0-2*X1) = X3-X2+3*X1-X0

なの?みたいな。。。><

とか言ってみたものの、私の扱う世界では時系列の三階微分が必要な場面ってないけどさ。。。

二階微分も符号だけで十分みたいな><