~matubara/ChangeLog / 2007-05 →移動しました

■ Solving large scale traveling salesman problems by chaotic neurodynamics [opt][net]

<http://dx.doi.org/10.1016/S0893-6080(02)00017-5>
完全結合（自己結合）型（ホップフィールド型）ニューラルネットワークには、
結合荷重に対応した安定不動点が存在することが知られている。

安定不動点への収束は、最適化の観点からは、局所最適値への収束に相当する。
この性質を利用して、NNでTSPを解いた研究が過去にある。

この論文は、結合荷重を一定比率で減衰する負の値にすることにより、
ノード集合の変化にカオス性を持たせ、
安定不動点をアトラクタに変えて、
大規模なTSPでも、悪い局所最適に陥りにくくなることを実験的に示した。

■ IPA の項目がすばらしく充実している件 [sr][audio][net]

<http://en.wikipedia.org/wiki/International_Phonetic_Alphabet>
これだけで、音声学のよい復習になります。

情報処理推進機構ではないのに注意。

追記
音声学を勉強したような顔をしてますが、本を読んだだけです。
言語学の中で音声学だけはトレーニングを受けないとどうしようもないと思います。

■ Specmurt Anasylis -- A Piano-Roll-Visualization of Polyphonic Music Signals by Deconvolution of Log-Frequency Spectrum [sr][net]

<http://hil.t.u-tokyo.ac.jp/~lab/topics/Sagayama04SAPA10/index.html>

■ 「虜みたい」と「取り込みたい」 [lx]

あるいは「可みたい」と「噛みたい」
この種類の対立は、トピックモデルで解消すべきことのような気がする。

この種の同音異義表現は、仮名漢字変換において盲点になっているのでは、と思った。

人間にとって同音異義語であることが意識されやすい同音異義語の多くは、品詞が一致している。
たとえば「気候」と「機構」。
仮名漢字変換は、品詞連接頻度を有力な手がかりとする場合が多いので、
品詞が一致する同音異義語を間違えやすい。
たとえば「ここのきこうはよくない」を正しく変換することができない。
それは人間でも同じで、単独の文ではどちらか分からない。
人間の場合は、前の文（発話）を参照することで、だいたい解決できているのだと思う。
そこで本当は仮名漢字変換でもトピックモデルが必要なのだと思うけれど、
実はそうとも限らない。
品詞が一致しているので、間違う箇所が狭く限定されていて、
間違いをあとから訂正するのが簡単だから。
どれが好まれる文字列かを、学習させるのも簡単。
間違う箇所が狭いからユーザが気づきにくいともいえるけど。

品詞が一致しない同音異義語は、まさに品詞連接頻度で解決できる。
「うみたがらない」を「海他画羅内」にしないということ。
未知語が絡むときくらいしか間違えないと思う。
間違える場合は、単語のレベルを越えて間違うので、ユーザは気づきやすい。
でも直すのに手間がかかる。

表題の同音異義語は、品詞が一致しない方に含まれるわけだけれども、
品詞が一致する方にかなり近いと思う。
これ全体が「用言」のような大雑把な品詞に分類されていて、
だからユーザは気づきにくい。
けれど単語レベルではないので、直すのに手間がかかる。

今回のリニューアルで初心者ユーザーを一気に虜みたい考えだ。

http://www.itmedia.co.jp/news/articles/0608/09/news083.html

■ マイク入力からの録音、Windows vs Linux + ALSA [linux][win][howto]

Windows:
1分以内なら、「サウンドレコーダー」で。ただし録音内容をオンラインで聞くことができない。
1分より長いなら、フリーソフト等を使う。
タイムシフトレコーダ は、ほぼオンラインで内容を聞けるので便利でした。

Linux + ALSA:

arecord > output.wav

で再生と録音。これだと 8 bit, 8kHz で音質が低いので、

arecord -f cd > output.wav

■ Perl Critic [perl][net]

<http://perlcritic.com/>

Some Ways Are Better Than Others

Perl のスタイルチェッカー

■ MUST1 -- 日本語複合辞用例データベース v1.0 [nlp][lx][net]

<http://nlp.iit.tsukuba.ac.jp/must/>
Matsuyoshi-Utsuro-Satoh-TsuchiyaでMUST

複合辞の表層表現のリストと、
その正例・負例へのポインタ（毎日新聞記事）リストとして提供されている。

<subentry id="A01-1000" name="といって[といって],と言って[といって]" freq="2828" total="28
60">
<example id="A01-1000-001" source="MNP-950101008-17" target="28-32" label="C"/>
<example id="A01-1000-002" source="MNP-950108168-36" target="34-38" label="C"/>
<example id="A01-1000-003" source="MNP-950116142-11" target="50-54" label="C"/>
<example id="A01-1000-004" source="MNP-950125251-25" target="32-36" label="C"/>
<example id="A01-1000-005" source="MNP-950201313-2" target="33-37" label="C"/>
<example id="A01-1000-006" source="MNP-950209310-3" target="2-6" label="B" note="と いっ ていい(B30-2000)"/>
...

■ CRF tutorial [learning][net]

<http://164.67.141.39:8080/ramgen/ipam/smil/7-28-05-pm-2.smil>
Lafferty先生によるCRFチュートリアルのビデオ

■ Reference is not alias [cxx]

#include <iostream>

class cmplx {
public:
  double x;
  double y;
  double& real;
  double& imaginary;

public:
  cmplx(double _x, double _y) : x(_x), y(_y), real(_x), imaginary(_y) {}
};

int main(int argc, char** argv) {
  cmplx c(0.1, 0.1);
  std::cout << c.real << "+i" << c.imaginary << std::endl;
}

Following the discussion in http://www.thescripts.com/forum/thread640395.html,
I can say that making aliases for a member variable using reference is not a good idea.
Since, in run time, those aliases *may or may not* be deleted.

In the above example, the type cmplx may consume sizeof(double)*2 + sizeof(double*),
or sizeof(double)*2.

#include <iostream>

class cmplx_simple {
public:
  long double x;
  long double y;

public:
  cmplx_simple(long double _x, long double _y) : x(_x), y(_y) {}
};

class cmplx {
public:
  long double x;
  long double y;
  mutable long double& real;
  mutable long double& imaginary;

public:
  cmplx(long double _x, long double _y) : x(_x), y(_y), real(x), imaginary(y) {}
};

int main(int argc, char** argv) {

  cmplx_simple x(10.0, 10.0);
  cmplx c(0.1, 0.1);

  std::cout << sizeof(x) << std::endl;
  std::cout << sizeof(c) << std::endl;
  std::cout << c.real << "+i" << c.imaginary << std::endl;
  c.x = 0.2;
  c.y = 0.3;
  std::cout << c.real << "+i" << c.imaginary << std::endl;
  std::cout << &c.real << " " << &c.x << std::endl;
}

■ Graphical Models - Elsevier [vis][net]

<http://www.elsevier.com/wps/find/journaldescription.cws_home/622839/description>

論文誌graphical modelsは、bayesianの言うgraphical modelsではなく
 3d reconstructionの文脈でのそれ。

■ コンストラクタのインターフェイスを増やす [cxx]

Javaでいうところの

public class Foo {
  public Foo(String s) {
  ...
  }
  public Foo(SomeClass x) {
    this(x.toString());
  }

がやりたいのですが、

class Foo {
  Foo(string s) {
  ...
  }
  Foo(int x) {
    Foo(x + "");
  }
}

だと

→ 共通部分を関数にしてください。
[10.3] How can I make a constructor call another constructor as a primitive? -- No way.

■ もっとも近い点を探す [algorithm][ir]

離散値（あるいは有限精度の実数値）の高次元空間を考える。
サイト集合と問い合わせ点が与えられたとき、
問い合わせ点にもっともちかく、サイトのひとつである点を出力せよ。

近さはユークリッド距離で定義する。
ただし、他の距離で高速な手法があればその定義をつかってもいい。

サイト数をN個、次元数をDとすると、
素朴な方法では O(ND) 時間になる。

次元数は1万程度、サイト数は千程度を想定している。
サイト数に関してオーダーNより小さい計算時間が望ましい。

1. 二分探索的な手法
2. 計算幾何で有名な方法があった気がする
3. Z-ordering
4. approximate near neighbor search -- nearest neighbor search を誤差つきにして、誤差内にあるかどうかの決定問題

■ 言語モデルの評価について [lm]

パープレキシティは簡単な比較をするためには便利だけれど、
特徴を分析して改良のヒントを探すためには粗すぎる。

というわけでもっと細かい評価の方法：

1. テストコーパスを文程度のレベルで区切って、
長さ正規化された確率降順でセグメントをランキング

2. 正解単語と予測単語の確率順リストを照らし合わせたときの、
reciprocal rank の分布とか推移

大規模コーパスを使ってテストする場合には、
細かすぎるかもしれない。
その場合は、適当な長さ・個数の区間をサンプリングしてやる。

どの評価指標を使うかは、目的や応用による。
確率スコアそのものは使わなくて、順位付けだけを使う場合には、
平均順位が有効だろうし、
スコアを使って足したり引いたりする場合には、
スコアそのものを使うパープレキシティが有効だろう。

順位を使うものとパープレキシティ以外には、
負例を入れた識別性能でみる discriminative language model with negative examples が有効。