!kiyoka.blog RSSPLAIN

Related pages: !kiyoka.blog.2005_04 !kiyoka.blog.2005_03 !kiyoka.blog.2005_02 !kiyoka.blog.2005_01 !kiyoka.blog.2004_12 !kiyoka.blog.2004_11 !kiyoka.blog.2004_10 !kiyoka.blog.2004_09 !kiyoka.blog.2004_08 !kiyoka.blog.2004_07
5555555000000000000000000000000000000000000000000221222222222222222222244444444443444444444444333444444444444555555555555555555554455555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
5

kiyoka日記。NendoSekkaの開発や、最近思うことなど

5

最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list

5

kiyoka.blog_header 

5

このブログを書いている人: 西山 清香(kiyoka) - twitter: @kiyokaEXT

5

5

 

5

 

0

kiyoka.2015_02_23[Sekka] SKKユーザーを満足させるのは難しい

0

 

0

前回の記事で、Sekkaをレベルアップできないかという話題を書いた。

0

SKKライクなIMEの特徴である、シフトキーを頻繁に押さないといけないという問題をなんとか改善できないか…

0

ローマ字先頭の大文字を指定しなくても快適に使えるようにならないかということを軽々しく書いた。

0

 

0

SKKユーザーを満足させるのは難しい

0

いろいろ試してみて、漢字とひらがなは「現段階では」人間が細かく指定したほうがよいという結論になった。「現段階では」という括弧書きだが。

0

いくらIMEが賢くなってもどこかでユーザーの考えていることとくい違ってしまう。つまりそれは誤変換だ。

0

本当のことをいうと、ユーザーが考えていることと完全に一致した結果を返せれば、それは誤変換は無いということになるので、完全に満足できる「賢さ」というポイントは必ずあるはずだ。

0

しかし、コンピューターの能力は有限なのでどこかでその壁が来る。

0

 

0

試しに、共起頻度の辞書100MByte分を追加して実験してみたが、変換中の単語の直前2語が辞書にヒットするとは限らず、どの単語が確からしいかは推定できない。(bigramとskip-bigram)

0

辞書には "日本語" と "変換" は共起するという情報があるので "日本語"の直後の"henkan" は漢字の"変換"と推定できるが、いつもこのようにうまくいくとは限らない。

0

自分の文章が必ずセオリーどおりのパターンで構成されているわけではない。辞書に無ければそれでアウトだ。

0

SKKユーザーはこの「漢字」と「ひらがな」と「カタカナ」間の誤変換というのを普通の人以上に嫌うので、なかなか難しい問題だ。

0

 

0

パーソナライズというもうひとつの問題

0

Webコーパスなどから集計した共起頻度の辞書を使うと、例えば句読点として「、。」を使うのか「,.」を使うのかという個人設定を維持することを困難にする。

0

コーパスとその人の趣向が一致しない場合、期待しない候補が選択されてしまう。(まあ、狭い範囲での解決策はいろいろあるが)

0

この点、SKKは最後の選択肢が愚直に第一候補になるので、文脈によって変換候補の順位が影響を受けない。

0

 

0

結論

0

SKKユーザーのように少しの誤変換も許しがたいユーザーにとって、IMEの挙動に推測はなるべく入れないほうが良い。

0

恐らく、SKKユーザーを納得させることができるのは人間の知性を上まわる「強いAI」が完成した時しかありえないだろう。

0

 

0

使ったデータ

0

辞書は以下の2gmと3gmを使った。

0
 N-gram コーパス - 日本語ウェブコーパス 2010EXT
0
 形態素 N-gram 頻度 10 以上のファイルリスト    圧縮時 12.1GB,展開時 75.2GB 
0

 

0

GitHubの作業branch

0

多分リリース予定なし。将来の約に立つかも。

0
 https://github.com/kiyoka/sekka/tree/ngram_dict
0

 

0

感想

0

自分でいうのもなんだが、SKKユーザーはなかなか頑固ものである…

0

 

0

comment please => kiyoka.2015_02_23

0

0

 

0

 

2

kiyoka.2015_02_12[Sekka] SKKライクな日本語入力システムでシフトキーを押す回数を減らしたい

2

 

1

Sekkaを話題にするのがあまりに久しぶりなのだが、思い立ってSekkaをさらに改善できないか検討している。

2

今度は、大文字始まりのローマ字を入力しなくても単語が漢字かひらがなかカタカナかを勝手に推測してくれるというもの。

2

本来、SKKライクなIMEを使っている人は、ひと手間掛けてもよいから思考を乱されるような誤変換を減らしたいという心理で使っている。

2

なので、わざとひらがなで「ひらがな」と入力したいところを第一候補に「平仮名」という漢字が出てくるといやがられる。

2

 

2

ただ、使い易さというのはバランスなので、あまりにもシフトキーを押す回数が多い場合はそれも思考のさまたげになる。(小指が痛いというのも思考の妨げになる)

2

毎回先頭大文字のローマ字を入力しなくてもよいならそれに越したことはない。

2

 

2

回避策は二つあって、一つは形態素bi-gramの辞書を導入するもの。

2

隣りあう形態素同士の共起頻度を使って、文脈から明らかに漢字を優先すべきローマ字は漢字候補を優先する。

2

例えば、「漢字」で確定された次の単語で henkan と入力された場合でも Henkan  と入力したかった可能性も考慮し 「変換」 と 「へんかん」を共起頻度の得点を積んだ上で変換候補に入れる。

2

 

2

もう一つは、Ctrl-Jでの変換確定時にマウスのダブルクリックのように素早くCtrl-jを2回押すと先頭を大文字にしたとみなす。 (henkan Ctrl-j Ctrl-j」というキーストローク)

2

この案は安易すぎるかもしれないけど、意外とこういう姑息な方法でも効果があったりするのでやってみるのもよいかな。

2

 

2

comment please => kiyoka.2015_02_12

2

 

2

2

 

2

 

4

kiyoka.2015_01_19[Xwindow][RDP] rdesktop経由でリモート接続したWindows日本語IMEを有効・無効制御したい

4

 

4

自分用メモ。

4

環境

4

ハードウェア: PowerBook G4 (日本語キーボードモデル)

4

OS: MacOS X 10.5.8

4

RDPクライアント: rdesktop (MacPortsに入っているもの)

4

接続先Windows: Windows Server 2012 R2 on Amazon EC2

4

 

4

やりたいこと

3

MacOSと同様に、Windowsでも「英数」キーでIMEをOFF / 「かな」キーでIMEをONしたい。

4

 

4

MacOS X上のX windowの設定

4
rdesktopが認識できるキーシンボルを定義する
4
$ vi ~/.Xmodmap
4

 

4
以下の内容にする
4
 keycode 110 = Muhenkan
4
 keycode 112 = Henkan
4

 

4
xmodmapを適用する
4
$ xmodmap ~/.Xmodmap
4

 

3

WindowsのIMEの設定

3

MS-IMEのキーバインドの設定で、「英数」をIME-OFF / 「かな」キーをIME-ONに割り当てる。

3

 

4

参考リンク

4
 OSXのX11で英数キー、かなキーの設定を変更する - HongoWikiEXT
4

 

4

comment please => kiyoka.2015_01_19

4

 

4

 

4

 

4

 

4

 

4

4

 

4

 

5

kiyoka.2015_01_15[Xwindow][RDP] rdesktop経由でリモート接続したWindowsの中でバックスラッシュが打てない

5

 

5

自分用メモ。

5

環境

5

ハードウェア: PowerBook G4 (日本語キーボードモデル)

5

OS: MacOS X 10.5.8

5

RDPクライアント: rdesktop (MacPortsに入っているもの)

5

接続先Windows: Windows Server 2012 R2 on Amazon EC2

5

 

5

現象

5

リモート接続して ¥キーを押しても、Windowsでバックスラッシュが入力できない。バー'|'は入力できる。

5

¥キーを押す度に、rdesktopがワーニングメッセージを出す。

5
$ rdesktop -f xxx.xxx.xxx.xxx
5
Autoselected keyboard map ja
5
WARNING: No translation for (keysym 0xa5, yen)
5
WARNING: No translation for (keysym 0xa5, yen)
5
WARNING: No translation for (keysym 0xa5, yen)
5

 

5

対処方法

5

rdesktopのkeymapsファイルを編集する。

4
$ cd /opt/local/share/rdesktop/keymaps
4
$ sudo vi ja
5

 

5

編集内容

5

以下を削除

5
backslash 0x73
5

以下を追加

5
backslash 0x7d
5
yen 0x7d
5

 

5

参考リンク

5
 UbuntuPC/rdesktop(RDP)のかな入力が不正 - PelicanWikiEXT
5

 

5

comment please => kiyoka.2015_01_15

5

 

5

5

 

5

 

5

kiyoka.2014_10_08[ssh][X] XQuartzが固まるのはX11Forwardingのタイムアウト設定のせいだった

5

 

5

MacOS XのXQuartzEXTのX11プロトコル転送を使っていたら、とちゅうでよくsshが切れていた。

5

ずっと原因がわからなかったが、どうやらこれが原因だった。

5

 

5

X11 Display Forwarding Fails After Some TimeRandomnessEXT

5

 

5

MacOS X側(XQuartz側)の /etc/ssh_config にこれを定義して ssh -X [ホスト] で繋げばOK。

5
ForwardX11Timeout 596h
5

 

5

最近のopensshだと、デフォルトは20分くらいになっているそうだ。

5

なんとも単純だけど、今季最大の収穫だなのでメモ。

5

 

5

comment please => kiyoka.2014_10_08

5

5

 

5

 

5

kiyoka.2014_09_03[LLVM][実験] LLVMが楽しい

5
 LLVM-Logo-Derivative-2
5

 

5

LLVMが普及しつつあるけど実際どうなのか

5

ふと思いついてLLVMについて調べ始めた。

5

世間ではGoogle ChromeのPNaCLとかemscriptenやasm.jsが実用的に使われる気配が見えてきた。

5

AppleのMacOS XやFreeBSDのLLVMへの傾倒を見ると、そろそろどんなものか知りたくなってきた。

5

なぜか昔から自分はCross Platformの話題が好きなようで、i386で動くLinuxのエミュレーターをJavaで書いたこともある。(完全に黒歴史…)

5

 

5

LLVM-IR

5

Cross Platformerとしての興味の対象はLLVM-IREXTなので、まずはここから。

5

LLVM-IRの言語仕様を調べたりclangの出力するLLVM-IRのコードを眺めてみたりした。

5

clangの最適化オプションを -O0 から -O3 にしてどれくらい最適化されるのかを眺めたり。

5

LLVM-IRの抽象度は非常に高く読みやすく(読むものでは無いだろが)Cross Platformな話題が好きな自分にはかなり楽しそう。

5

挙句の果てには、LLVM-IRのコードをEmacsLispで動かせないかと実験をしてみたりした。

5

 

5

LLVM-IRをEmacsLispに翻訳

5

可能性を探るためにちょっとやってみたのだが、LLVM-IRのインタプリタlliコマンド の 約1000倍の実行時間がかかることがわかった。

5

ということでこれで思考実験は終わり。

5

 

5

このようなCプログラムをclangでコンパイルし、LLVM-IRを翻訳したEmacsLispで動かしてみた。

5
#include <stdio.h>
5
5
int main(void)
5
{
5
  int total = 0;
5
  volatile int i;
5
  for( i = 0 ; i < (1000000 * 1000) ; i++ ) {
5
    total += i+1;
5
  }
5
  printf( "total = %d\n", total );
5
  return 0;
5
}
5

 

5

"clang -O0 -S -emit-llvm loop.c" で出力したLLVM-IRコードもあわせて見るにはこちら。

5
 simple loop program.EXT
5

 

5

つぎに愚直にEmacsLispに翻訳してみたのが loop1.el 

5

手でちょっとだけ最適化してみたのが loop2.el 

5
 Translate to Elisp from LLVM-IR codeEXT
5

 

5

LLVM-IRをSchemeに翻訳

5

愚直にSchemeに翻訳してGaucheで動かしてみたのがこちら。

5

lliの100倍の時間がかかる。しかしGaucheは速い。

5
 Translate to Scheme from LLVM-IR codeEXT
5

 

5

cmigemoをEmacsLispで走らせられないか(妄想)

5

cmigemoを1000倍非力なCPUで動かすとどれくらい使えないかを測ってみた。

5

cmigemoの検索クエリから正規表現への展開は1000回実行しても100ms程度で、実用的な範囲。

5

しかし、mcigemoが辞書をロードする時間は1000回実行すると3分もかかる。これは実用にならない。

5

 

5

っと、ここで夢から覚めて我に返った(←イマココ)

5

いやー妄想って楽しいもんです。

5

 

5

comment please => kiyoka.2014_09_03

5

5

 

5

 

5

kiyoka.2014_07_16[Sekka] sekka.elからpure emacsでhttp通信しようするも断念

5
 iStock_000016378483XSmall
5

Emacsも年々進化していることだし、もうそろそろcurlコマンドを使わなくてもEmacsだけでHTTP通信できるのでは?と思ってチャレンジしてみた。

5

今回はあきらめたのだが、理由を忘れそうなのでここにメモしておく。

5

gibthubのSekka作業ブランチは "http_pure_elisp" 。

5
  https://github.com/kiyoka/sekka/tree/http_pure_elisp
5

 

5

url.elのリクエストが不正?な問題

5

Emacs-24に入っている url.elを使ってsekka-serverにアクセスするも、webrickが400 Bad Requestを返す。

5

url-retrieve-synchronously関数の返却バッファには、200 OKのレスポンスの後ろに、400 Bad Requestのレスポンスがくっついてくるので原因がよくわからない。

5

curlコマンドからWebrickにリクエストした時は発生しないので、url.elのリクエストがRFCに準拠していないのか、Webrickの潜在バグを突いているのか…

5

 

5

url.elからのリクエスト中にEmacsのキーイベントが消費される問題

5

url-retrieve-synchronously関数を実行している間にCtrl-jを押しても効かない。

5

キーイベントがどこかで消費されているのかもしれない。

5

curlコマンドをプロセス起動した場合にはそのような現象は発生しないので、url.elの作りの問題なのかもしれない。

5

url*.elで "discard" や "event"  などで検索したがあやしい処理は見つからず…

5

 

5

Webrickの代替が見つからない問題

5

Webrickの代わりに別のRackドライバを探したが、thinくらいしか見つからなかった。

5

thinを使ってみるも、Segmentation Faultで動かず断念。

5

 

5

こんな感じで、あまり時間をかけていないが、一旦断念。

5

また一年後くらいに再チャレンジするかも。

5

ただ、curlが非常に安定していることもあって、EmacsからHTTPリクエストする場合はcurlがデファクトスタンダードになっているようだ。

5

いっそEmacs本家にcurlをリンクしてくれたりいいのにと思うんだけどなぁ。

5

 

5

comment please => kiyoka.2014_07_16

5

5

 

5

 

5

kiyoka.2014_03_15[PasteHub] PasteHub.netは「コピペをいろんなWebサービスのハブにする」

5
 iStock_000019296334XSmall
5

PasteHub.netの大改造中。

5

 

5

コンセプト

5

コンセプトは「コピペをいろんなWebサービスのハブにする」にしようかと考えている。

5

もう、サーバーサイドのコードはgitのmasterからきれいに削除し、Dropbox必須とした。

5

おかげでクライアント側のコードも半分以上は不要となった。

5

それでも「コピペを同期する」という本来の機能の利便性と安定性が上がった。

5

 

5

大改造のきっかけ

5

きっかけは自分がスマートフォン(iPod touchなんだけど)を買っていろんなアプリが動くようになったことだろう。

5

 

5

今迄使っていたiPod touchはとても古く、iOS 4.2までしかインストールできなかった。なにせ2014年におけるiOS 4.2というのは、とんでもない時代遅れのシロモノなのだ。

5

どんなアプリ作者もiOS 6.0以上で動くアプリしか作らない(当然か…)。iOS 4.2ではTwitterクライアントはなぜか起動せず、Feedly、Safari to go 、Kindle、Evernoteは非対応だ。

5

 

5

それが一変した。

5

最新のiPod touchを買ってiOS 7.xが使えるようになり、EvernoteやTwitterクライアント、Feedly、Safari to go、Kindleが動くようになった。

5

今までスマートフォンのサービスがここまで便利になっているとは知らずに来たもんだから、その進化には正直たまげた。

5

EvernoteもブラウザベースのWebサービスとして使っていると、それほど便利さは実感できない、なので使う意味はほとんど無い。おまけに古いiPod touchにはカメラさえ付いていないので、写真でメモを取るということもできなかった。それはEvernoteと言えるのか?…

5

 

5

時代の流れとDropboxの普及

5

2012年に作り始めたPasteHubというプログラムは、当初、コピペ情報を仲介するためのサーバーサイドを時前で持っていた。

5

2014年の今ではDropboxが事実上の標準となり、使っていない人はいないというところまで来た。(Google DriveとかOneDriveも含めたクラウドストレージというくくりで見ると、ほぼ100%だろう)

5

そんな背景もあり、Dropboxに完全依存することに決めた。

5

 

5

というわけで、ぼちぼち使えるプログラムとして生まれ変わる最中です。応援よろしく。

5
 kiyoka/pastehub · GitHubEXT
5

 

5

comment please => kiyoka.2014_03_15

5

5

 

5

 

5

kiyoka.2014_02_25[PasteHub] 新PasteHub.netは何を優先するか

5
 iStock_000019296334XSmall
5

自分用メモ。

5
インストールが簡単(設定なし)
5
Mac/Windowsはインストーラーにてインストールするだけ。
5
Linuxはrpm/debをインストールするだけ。
5
Emacsはmelpaからelispをインストールするだけ。
5

※ 但し、Dropbox以外のストレージサービスを使っている場合は、設定値変更が必要。

5

 

5

最後のEmacsクライアントは実装がけっこう大変そうな気がするが、やってやれないことは無い。

5

使うのが簡単なものほど作るのは大変というのはよくある話。

5

実装が多くなるという意味で当然といえば当然なのだが…

5

 

5

comment please => kiyoka.2014_02_25

5

5

 

5

 

5

kiyoka.2014_02_22[PasteHub] 大きなピボット

5
 iStock_000019296334XSmall
5

PasteHub.netというコピーペーストを複数のマシンで共有するサービスを作った。

5

しかし、ここへきてPasteHub.netの「コレジャナイ感」が大きくなってきた。

5

自分が欲しいのは、複数のOS、複数のマシンでコピーペーストが同期されるシステムだ。

5

PasteHub.netではそれだけのために、次のような手順を踏む必要があった。

5
サイトを用意
5
ユーザーアカウントを登録
5
アプリケーションをインストール
5

 

5

これはなかなか敷居が高い。

5

サービスを提供する側にとっても、ユーザーにとっても。

5

実際にこの敷居の高さのせいか、ツールを使う人は皆無に近かった。

5

 

5

そんなわけで、しきり直しをします。

5

 

5

PasteHub.netを使うには、

5
アプリケーションをインストール
5

だけでいけるようにしたい。

5

 

5

自分でサイトを構築・維持するのではなく、Dropboxのような共有ストレージサービスを利用しようと考えている。

5

Dropboxのような共有ストレージは既に誰もが使っているだろう。

5

有名なドリルの喩えでいうと、「ドリルを買う理由は"穴"が必要だからである。ドリルが無くても、穴が得られれば良いのである。」ということだ。

5

自分も"穴"だけが欲しいので、ここいらでピボット(方針変更)しよう思う。

5

 

5

共有ストレージも、同期のタイムラグの問題などいろいろ課題は出るだろうが、それを解決できれば簡単に使えるものになるだろう。

5

仕組みが単純になる分、Dropboxと連携するIFTTTなどのサービスとも連携できるなど、価値も増える。

5

というわけで、いろいろ実験しながら可能性を探っていきます。

5

 

5

comment please => kiyoka.2014_02_22

5