●紀PM
未踏とはなにか。経産省、5年間の計画。今年が3年度目。
最初は天才プログラマー、今はスーパークリエイター。
11人のPM。個人をえらんで採択する。
7月からはじまった。8月上旬に京都でkick offセミナー。
今は仕上げ段階。一般の人に知ってもらう。
→2ch、未踏ソフトのスレができた。
●近山PM
ソフトウェアは予定よりも早く進んでいるという例はあまりない。
やや遅れています。そのややがどのくらいか。
目的は個人の発掘であり、出来上がったものの評価ではないが、
どうしても出来上がったものを評価することになる。
●萩谷PM
月一回くらい顔をあわせてきた。
目標: ソフトウェアを通して有名になってほしい。
■岡田、自動作曲。
→目標の引き直し: 様々なアプリに摘要可能な、自動作曲のフレームワークを作る。
→背景、ネットワークゲームなど、やっぱり自動作曲は必要。
ピンチ、一発逆転、勝利とかをBGMでも表現する。
→新コンセプトのゲーム作品。1、2年前のRezという音楽ゲームがでた。
ネットワークゲームの演出。
→ホームビデオBGMの自動作曲。音楽初心者でも作曲。
→スタジオ・ミュージシャン・モデル
Composer→Lead Sheet→Performaer群
→メロディ譜、コード進行、編曲上の注意(フィル・イン、ブレイクなど)
●これまでの成果
→既存楽曲 (MIDIファイル)
→Composer
→メロディの学習、コード進行の学習。
コード進行とメロディの関係とか。
→それを元にメロディの生成、コード進行の生成
→LeadSheetの作成
→Performer、メロディの演奏、コードに従った伴奏
●基本構造
→既存局MIDIファイル
→学習ロジック、C#
→知識ファイル、XML
→作曲ロジック、C#
→Wrapper, Managed C++
Sound出力はDirectSound。Wrapperをかませている。
→演奏エンジン、DirectX8.1、演奏情報 STY, 音色情報 DLS
●デモ用プログラム
→Pops曲みたいのを自分で作る。
複数のPerformerをえらぶ。クラブっぽい、カントリー調など選べる。
●デモ
LEARNIGNボタンを押してMIDIファイルをドラッグ。
抽象化してXMLで保存。.knowledgeファイル。
→HAMASAKI. play
去年人気だったMONGOL800とか、単純な構造を持つ
●苦労した点
→C#からDirectXを使うのが難しかった
MIDIをソフトシンセでならすとチープになる。CDクオリティーにしたかった。
→DirectMusicが使いづらかった。トーダ・フェイさんがつくった。
7、8年前にMicrosoftに売った。フェイさんはMicrosoftはやめてしまった。
DirectX9がでたが、DirectMusicは変化無し。
→メロディの生成で、影響を与える要素が多いため調整に苦労した
→学習内容をどれだけ忠実に再現するのがいいか。
●自己評価
→人間による作曲を分解し、オブジェクトに機能を配置したのは効果的だった。
→コードやメロディの学習に、コードやメロディを組成する要素の抽象化を行う独自の方法を用い、
高い効果をあげることができた。
→既存技術であるDirectMusicを効果的に使えた。
●今後の課題
→ピックアップ小節からはじまるメロディの学習と生成
きりがいいところからはじまるメロディー、
まえだおしではじまるメロディーはどこに属するんだ、どうやって学習するのかとか。
→メロディのリフレインの実現。
メロディは、同じモチーフが繰り返される。それが重要。
→シンコペーションなど、複雑なリズムのメロディの学習と生成。
プロの歌手、ちょっと遅らせたり早めたり。それがフェイク。
→よりインテリジェントなPerformer
今はおれはカントリーのperformerだ、とかシンプルにやってる。
自分なりにbass lineをくみたてられるように。
→よりインテリジェントなオーサリングツール。
コード進行の自動解析、Performerの自走作成など。
→リアルタイム処理
●プロフィール
→岡田
→2002、Improvista Interactive Music, Inc. Co-founder & CTO
●質問
→サビとか。
もりあがる場所、静かな場所。
オーサリングでカバーしたい。
一般的な作曲技法をしっておく。
こっから曲がおわらないといけない。
こっから三秒以内に終らないといけないとか。
→著作権の問題は? 使用条件でクリア。
★楽曲の学習で一番難しいのは、ブレイクのような繰り返さないパターンだが、
どのようにやっているのか?
→オーサリングでカバーする。
サビの直前とか、音符の密度とかで、ブレイクがどこに入るのかのルールは作れそう。
■新井さん、歌唱練習ソフトウェア「うたうたう」
有限会社メロートーン、新井
→音痴のなおるソフト。
→練習すると苦手意識がなくなる。
歌を練習すると楽器の音にあわせてうたう。
ピアノにあわせてうたうほうがかんたん。
先生がはずれていたら教えてくれる。
→歌の練習用ソフトとしての市場開拓を目指している。
オンライン販売。
●「うたうたう」の仕組み
マイクにむかってうたうと、音程が表示される
→教師データと重ね合わせた視覚的な練習。ヴィヴラートや音の強弱など
●コアとなる技術
音高推定の技術、1998年から断続的に行い、高度な技術。
他の類似にくらべて高機能。
●ソフトウェアのニーズ
→学校や声学化の音楽教育
→声学の表現、ビブラートなども見ることができる
→音痴の治療
→ゲーム的に歌を楽しむ機能を提供する。楽しめる製品。
●仕様
→Windows、低スペックへ対応。
→インターフェイスに工夫
●アドバンテージ(比較)
→他に競合がいない。
→ソング頼太は作曲支援である。
→歌唱練習を主軸とするとのは研究者がつくったものだけ。
→ピアノ練習用ソフトはあるが。
●高い技術力
→3オクターブの範囲を実現
→10cent単位での認識
→誤認識を少なく
●応用の可能性
→語学学習、中国語、ベトナム語など
箸と橋は音は同じだがイントネーションが違う。
★方言を直すソフトとか?
→楽器練習、ピアノ、ギター、
→聴覚障碍者の練習
→自動伴奏
→音楽の採譜、MIDI化の支援
→新楽器の開発
●語学学習
→声調(音程)、NHKの声調弐号があった。
●成果
→つかいやすく、ウィザード、レッスン、曲の表示、判定機能
→性能、MMXへの対応
→公開可能な品質
→完成度98%! これからは普及と中国語!
●レッスン機能
→ドレミが表示される
→あってるところはOKと表示される
●目標
→音痴をなくす、歌嫌いを直す
→PCを使って音楽をたのしむ
→新しいソフトウェア市場を作りだせるようにしよう
●謝辞
萩谷先生、Borland C++ Builder、デニーズ成城店
●デモ
Sing-a-Tune
★イイ!!
●会社概要
→メロートーン、2002年11月設立
→いままでにないソフトウェアの開発
→技術支援とシステム開発請負
●新井
1978年うまれ
中学校卒業後、学校にはいっさいかずに、独学で学ぶ。
みなさん、未踏はすばらしいです。
未踏は一人で全てやっていかないといけない。
そのためのモチベーションをいかに維持するかが大変。
こんなのを作ってもだれも見てくれないよとか。
心の悪魔に負けないようにするべし。
●質問
→歌というのがどういうものか、まったくわからないという人もいる。
→ヴィブラートは見た目では見える。検出は?
→MMXをどう勉強したか。
Intelのhome pageにアセンブラを最適化というPDFの資料。日本語もある。
本は一冊もかってない。
→音痴を直すのにもモチベーションが欲しい。スコアがでるとか。
GoodとかExcelentとか。
●3オクターブになった、1/10centになったとかは?
素早く計算させるための最適化の手法を開発した。
→いままでの研究でも、パラメータ調整が必要だった。
そのパラメータをちゃんと調整した。
→オクターブ間違いをどう抑制したか。
アドホックな方法もいろいろ試している。
いままではFFTをつかった手法が多かった。
今の手法で、低音でも高い周波数分解能をあげることができた。
→音高推定の技術は?
bit別冊、「コンピュータと音楽世界」
参考文献。論文をかりてきて読んだ。
国会図書館。一つの論文で、一、二時間。
→MIDIには歌詞をいれる機能があるはずなのだが、いいEditorがないので探している。
■光成さん、有料配信における海賊版受信機・パスワード漏洩防止スキーム
●背景
有料コンテンツ(Sky perfecTVとか)をどうやってパソコンで受ければいいのか?
こうげいせんい大学のかさはらまさお先生のところにいってたときに、
ある暗号を考案し、アルゴリズムの特許をとった。
●不特定多数向けコンテンツ配信において、
不正受信の防止
●暗号の性質
→一対他の暗号系、錠一つにたいして個人鍵が複数
→デコーダに個人鍵をもたせない
→不正な個人鍵の生成が不可能
→不正な個人鍵の流出が検出可能
●従来1
一対一対応、
各自が同じ鍵をもたないといけない。
鍵の流出者を特定できない
●従来2
個人認証とセッション鍵デコーダーは別
個人鍵、個人確認、鍵デコーダ、セッション鍵、暗号化されたコンテンツ、コンテンツデコーダ
人数分だけ鍵が必要。アルゴリズムが別々。
●提案方式
認証とセッション鍵デコーダを統合
暗号化されたセッション鍵、(同じものを配付)
別々の個人鍵、
同一のセッション鍵
セッション鍵は10分ごとにかえることができる。
何万人の鍵をあつめてきても、
セッション鍵を作るルールは解析できない。
●特徴
個人鍵は、320bit. うち160bitに個人情報をうめこむことが可能。
RSAとかは、1024bit。比較的短い。
個人鍵をあつめても、不正な個人鍵を作ることはできない。
個人鍵から個人を特定可能
●特徴2
暗号化されたセッション鍵、320bit
ユーザ数によらず一定
デコーダ。。。
●特許
→核となるアルゴリズムは取得すみ
→実装に欠陥がみつかる。
→デコーダをなんとかして工夫した。
解析対策にパラメータをみえにくくすのはよいかも。
エンジン部分。C++とアセンブリ。
i86系、Windows、Linuxnなど。
RSAとかにくらべ、はるかに処理が重い。
Penrium4向け最適化。
Solaris for SPARC、PowerPC, ARMへも対応
簡単なGUI。
●苦労した点
→数字ばかりでデバッグが単調。動作テストをやりにくい
→イメージがわきにくい。メーリングリストのみでのやりとり。
5人でML。5人の中の二人は一度もあったことがない。
→コンパイラのバグによくであう。
●課題
エンジン部分の完成
アプリケーション、一対他という性質をどう使うか
●質問
→個人鍵を盗まれたらどうする?
クレジットカードの番号を盗まれたらどうする? というのと同じ問題。
→衛星放送をPCでdecodeするとして、横からとられるのでは?
デコーダー側にすかし情報をうめておくとか。
リアルタイム性の高い情報を高くするとか。
Windows自体をemulateすることもできるので、どうしようもない。
decodeしたデータは大きくなるので、そういうった対処とか。
鍵の計算に時間がかかるが、10分に一回負荷がたかまるだけだから大丈夫。
コンテンツのデコードは通常の暗号でするので。
極端な話、10分かけて展開してもいい。
→二つ鍵があるのか?
個人鍵がある。暗号化されたセッション鍵を10分ごとに配付して、それを解除すると、
暗号化が解除されたセッション鍵がてにはいる。
→BS、CSとかは、バンド幅がたかいので、人数分の鍵を全部おくっている。
これはブルートフォースな解決方法である。
●広島大の吉田先生、第一原理に基づいた分子構造による生命プログラミング
杉野桂司
●20世紀、もっとも大きな発見は、プランク定数の発見。
物質を理論的に理解。社会に役立つ物質ができるようになった。
●21世紀は? 分子言語により記述される生命。
ヒトゲノムの解析。ダンプリストの意味を理解するべし。
●ポストゲノム研究の流れ
→タンパク質の集合の反応の総体
→タンパク質の三次元構造。
アミノ酸の配列の一次元の情報しかわからない。タンパク質の三次元情報を扱えるように。
●システムの概念
→計算化学、1980年代からフリーである
→バイオインフォマティクス、これもある
→それをつなげる分子モデリング、これは未踏。
ビューワーも必要
●MOLDA
→Googleの、Molecular Modeling Viewerカレゴリーで、top10くらい。
→一位は、VMD、MOLMOL、タンパク質を表示する著名なソフト。
→スイスのソフト。WebLab viewer、これらの機能をとりこもう。
→MOLDAは有機化合物だけだった。
●ダウンロード数
１ヶ月で1000本くらいダウンロード。
→MOLDA for Protein Modeling、MOLDA for Javaにタンパク質のモデリング機能を追加
→MOLDA Qulis (Quantum Life Science)、OpenInventorを用いて3Dグラフィックス
→iMolda jMolda
●分子化学計算プログラムとの連携
AMBER, MOPAC Gaussianと連携
ISISDraw→MOLDA、化学構造式から3次元化可能。
MOLDEN, SPDBViewer, RadMol
VRMLをはきだす
Protein Bank形式もexport可能。
●画面
ISISDraw→MOLDA→Tinker→PDB file→RadMol
ISISDraw→Mol file→ MOLDA→ MOPAC→ MOPAC file→ MOLDEN(電子密度表示)
MOLDAは標準では、import, exportの機能しかない。他と連携で、ほとんどの操作が可能。
VRMLによる分子グラフィックス。
●MOLDA for protein Modeling
→ヒストン、生体分子の一種
→蛋白のまわりをDNAがとりまいた構造。
→原子数一万個以上。2万個まで可能。
→XML形式の読み込み
Chemical Markup Langauageの対応を、
ピーターブレーラッドと共同でつくっていた。
ポリペプチドの作成、
ポイントミューテーション。
●タンパク質のモデリング
ポリペプチドの作成。A→アラニン
Aが9つならんんで、ポリアラニン、アルファヘリックス構造が自動的にできる。
PDB読み込みを強化した。
●ポイントミューテーション
6盤面のロイシンをアルギニンに変える。
●タンパク質の参事構造の構築
ペプチド結合の回転角を指定することで構造がきまる。
任意の回転角が指定可能。
●DB化
PostgreSQLでDB化
Point mutations...
●MOLDA Quilis、3D viewr、マックスネットの協力。
ヘムをリボンで表示。
1,VRML viewer、2,MOLDAの表示、この二つが一画面におさまっている。
●球棒模型図による表示
VRMLは通常モデリングができないと思われているが、これはモデリングできる。
原子オブジェクトの変形、結合値をかえたり、回転させたりが可能。
原子団のオブジェクト操作。
フェニル、ベンゼン環。代表的な置換基は用意してある。
●分子ドッキング
●iMOLDA
CGIで、3D structural DB、
化合物名を送信、分子の座標値を送信
●コミュニティ
www.molda.net
www.biwa.ne.jp/~k-sugino/
3016.net
molda-ml@mlc.nifty.com
●開発計画
→分子ドッキングにおける分子間衝突検知機能
医薬品開発にものすごく役立つのでは。
→3Dディスプレイによる立体視。
●デモ
CO結合
エーテル化合物ができる。
●タンパクのmolecular docking
原子数、8000くらい。
→分子結合の結合かえたりするインターフェイスが使いにくいのではないか?
化学屋については一番やりやすいと思う。専門は構造化学。
→VRML表示にどれだけデータが入っているのか?
球棒模型図。
リボン表示にも、データははいっていてもよいのでは。
★生命プログラミングというタイトルに釣られて見にきてみたら、
単なる分子モデリングだった。俺はもーれつにがっかりしたね。
CGでリボン状に表示することにそれなりの意味があるとの話だが、
これから先、衝突判定などで物理シミュレーションをしようとするところに
もっとも難しいところがある。
1万個の分子の相互衝突判定は、リアルタイムにやるのはそうとうにきつそう。
■川合さん、
Banyan - 3D CGコンテンツのコラボレーティブオーサリングフレームワーク
●目標
3D CGコンテンツを
複数のスタッフが「寄ってたかって」
製作できるようにするフレームワーク
"WikiWikiWeb for 3D"
●従来
個人で完結する作業を前提
ファイルベースのモノリシックなデータ管理
製作と納品のステージが分離
●Banyan
データは全て共有を前提
ネットワーク上での協同、並行作業
製作と発表のステージを統一する
●対象
プロダクション内での協同、並行製作
独立アーティストのネット上での協調作業
一般ユーザの製作への参加(バザールモデル)
●概念
●Scene
3Dの空間としてレンダリングされるひとかたまりのデータ
Nodeのネットワーク(Scene graph)として表現
camera, light, instance
→データをクライアントがロードしてきて、集合された結果できたもの。
つまりクライアントの中にしか存在しない。
「lightだけ作りました」「机だけ作りました」というのもあり。
●Part
Scene graphのサブグラフ
http://www.schemearts.com/banyan/repository/shiro/scene1
●Repository
→履歴管理はCVS
→依存関係 (相互参照は一repository内)
http://www.schemearts.com/banyan/repository/
file://home/shiro/...
●デモ
ABCさん
A レイアウト
B 建物
C 見てる
まずBさんがビルをつくって、物だけcomit
Aさんがよびだして、配置する
Cさんは見てるだけだとつまらないけど、
本気で参加するのもつらいので、別のBranchを作って木を配置する
●実装
Scheme+C
ベースライブラリ
クライアント
プロトコル
サーバ
Gauche+gtk
Gauche+gtkgl
Gauche+gl
glmath3d →4X1のカラムベクターとか
GtkGLExt
libbanyan extension
(頂点normalの計算などだけCでかいている。)
GLIM →CLIMを参考にしたHighレベルなUIツールキット
banyanは入出力など
banyan.gui
banyan.client
●クライアント
Schemeプラグイン L-system
うめこみScheme, sandbox evaluator
●プロトコル
S式 over HTTP
→Header
Content-type: application/x-banyan
X-Banyan-Auth:
X-Banyan-Status:
→Header
Metadata
Node graphのdump
●サーバー
CGIスクリプト
ブラウザから、metadata
Banyan client
バックエンドでCVS
●これから展開
アニメーション機能
レンダリング、multipass shader, shadow
複数revisionのcheck out
ちょっとrevision戻ったものとか
→サーバー機能拡張
更新衝突時の管理、あんまり問題にならない。
表示して、手でmergeしてくださいとか。
自動mergeを考える、lockをかけるかも。
グラフの差分検出とか
グラフ変換
→ソフトはオープンソース、BSDライセンス
デフォルトサーバを運用
ユーザーベースの確保
コンテンツの配信へ
Banyan
Gauche-0.6.7
Gauche-gl-0.2.2
Gauche-gtk-0.3
www.shiro.dreamhost.com/scheme/gauche
GtkGLExt-0.6.1
●プロフィール
川合
2002 Scheme Arts.
Dynamic Languageをつかった、協調製作支援環境
創作活動の支援
●質問
→Schemeの利点は?
CGソフトは元々一般的にLispでかかれていた
ネットワーク型のデータを扱うのが簡単だった。
外部表現がはっきりしていた。S式をそのままdumpすればよかった。
interpreterだった。
■奥地さん、GRUB拡張
●概要
GRUBを拡張、移植など。
PUPAというコードネーム
●BugCommunicator
Rubyのバグ追跡システム。BTS
Savannnaをつかっている。
CodeXが腐っているので開発。
Debian BTSに近いが拡張性にとむ。
0.3。CVSが最新。
メールでフォローアップができる。
検索ができる。
www.nongnu.org/pupa/bugcomm.html
bugcomm.enbug.org
すでに運用中。
●Ruby/Cache
LRUアルゴリズムによるオブジェクトをキャッシュ。
レスポンスを高速化のために。
0.3
www.nongnu.org/....
FileCacheをサンプルとして添付。
まつもと氏の反応がいまいち。
★まつもとさんの反応が無いのはいつものことで、
MLでアナウンスしてむりやりCVSにつっこめば、標準になったりするらしいです。
●GRUBとは
PC用高機能ブートローダー (ブートモニターに近い)
Multiboot Specification
LILOとの違い、shellをもっている
ファイルシステムに対応
serial、hercules対応
ネットワーク対応、OSをもってくるとか
GRUB自体もネットワークからとってくるとか
●GRUBの不運
元々そんなに機能はなかった
要望が続出
場当たり的な対応
→→→始めたころのGRUBはちっぽけ。
ファイル名補完なし
ネットワークなし
シリアルなし
(シリアルはescシーケンスとかきりがない。dumb端末もどうすれば…。)
などなどのある程度機能が拡張されてから普及したのでした。
そうした想定されていなかった機能追加の結果
→→→スパゲッティーの完成
元々モジュール化が低い。
大域変数で支配されている。
●GRUBによせられる無茶な願望
設定ファイルを分割したい。 むりです。
変数やif文がつかいたい。メモリ管理が原始的です。
Powerでうごかないの? i386べったりです。
(little endian, word size 32bit, bootする枠組の仮定とか)
パーティションを消したら動かなくなった。 Stage2はファイルシステム内にあります。
RedHatとか使ってるとこうなる。
(安全性が低い。stage2、つまりmainがなくなったらなにも動かない。)
機能を追加し難い。 構造化されてないから…。
(開発のプラットフォームにつかいたい。)
●目的
救援モードによる安全確保
動的リンクによる拡張機能
真のメモリ管理機能 (今は静的メモリ確保。コンパイル時に決定。)
構造化されたフレームワーク
CPUやマシンに依存したコードの明確な切り分け
異なるアーキテクチャ上でのinstall機能
(Sparcで、シリアルの先にi86系組み込み機器がつながっている。それすらも今は対応できない。)
過去の汚物はばっさり
●従来のGRUBの配置
MBR Stage1
空き領域 Stage1.5
(通常シリンダ境界にあわせないといけないので)
ファイルシステム Stage2
●PUPA
空き領域(通常62セクタ)を有効利用する
MBR boot (512byte)
空き領域 kernel (62セクタ弱、31Kbytes弱)
→救援モードが動くくらいはここにつめこむべし
マシンの救済ぐらいはできるように。
最近はフロッピーがついてないのがめずらしくない。
ファイルシステム normal
→モジュール
●構成
→boot, diskboot, kernelの3イメージとモジュール群
diskbootは中間的存在、bootから直接kernelをよぶのがむずかしい。
→モジュールはELF relocatable object
→kernleは実行時にモジュールをロード
→モジュールのロードに必要なのは、
前もってkernelにロード(preload)
ファイルシステム理解のモジュールは、preloadにする。
●利点
再コンパイルの必要がない、異なる構成のkernelを容易に利用可能
(バイナリーは一個だけというのがいい。)
コード管理が簡単
独立性を高めることができる
●フレームワーク
→メニュー、シェル
→コマンド
→OSローダ、
→ファイル、
→ファイルシステム、
→デバイス、
→ディスク,ネットワーク
→メモリ
階層間をスキップしないようにしている。
●コードの浄化
Automakeを強引に使ってる。 (Automakeは拡張性を考えてない)
PUPAではRubyで記述の独自のMakefileジェネレータを作成
汚いコードはi386の依存の排除もふくめて徹底的に書き直し。
●よもやま話
GRUB、元々Ericさんが作った。すごくレベルの高い人。
すさまじいコード。アセンブラに洗脳された頭脳をもっている。
変数を再利用する。変数名をきにしていない。
swich文の中で、breakをいれないでfall throughするとか。
とにかく普通の人が読みとれるコードじゃない。
→これ以上知りたい人は、コードをみるべし。
●状況1
→ブートストラップ、サイズの問題
31Kbytes以内にしないといけない。
dynamic loadingとかつめこむとどんどん減ってきている。
→メモリ管理
→動的リンク
→フレームワーク
→救援モード
→通常モード
●状況2
ファイルシステム
ディスク
ネットワーク
端末
OSローダ
インストーラ
PowerPC(iBook)からでもインストール可能なことは検証済み
国際化
●デモ
Bochs IA-32 emulatorを使用
1. 通常モードが動いてるところ
救援モードにはいったり、通常モードに戻れる
2. 通常モードがロードできない場合に
救援モー0ドに突入できお
3. 救援モードからLinuxがboot可能。
完全にブートは
cをおすと、shellっぽいCUI
history, 補完はまだ。
rescueとうつと、rescue mode
helpとうつと、コマンドの説明
boot
cat
rescue modeはkernelだけでうごく。
normalとうつともどる。
ls
ls (fs0)
fatだよ
ls /
boot vmlinuz
ls /boot/pupa/
normal.mod.bak
.bakがついているからだめ。
insmod /boot/pupa/normal.mod.bak
これでhelpをみるとnormalがつかえるようになっている。
normalといれる。
ls /
GRUBはkernelというコマンドで自動判別する。
しかしnetBSD OpenBSDは区別つかない。
Linuxだったらiinuxとうてと。そういうことにした。
linux /vmlinuz root=d/dev/hda1
boot
●さらなる情報
www.nongnu.org/pupa/
●予定
→圧縮、自己解凍をつかってイメージ縮小する道を探る。
10Kbytesくらいは空くのでは?
→通常モードを使えるレベルにする。
→国際化関連をなんとかする。
●終った後
PUPAという名称は捨て、GRUB 2として開発を続行する。
現行のGRUBを駆逐するには後一年はかかるかな?
本当に移植できるのか、試したい。
●質問
→PUPAの意味は?
preliminary universal programming architecture for GRUB
PUPAはさなぎ、GRUBはうじむし。かぶとむしの幼虫。
★BeetleじゃなくBootleという名前とか。
■松井さん、Cプリプロセッサ
診断メッセージなどが充実。
ドキュメント化、
最近のCのスタンダードにあわせる
GCC3との比較、
●MCPP(Matsui CPP)の概要
きわめて正確。
検証セットによって、詳細なテストをしている。
規格の全てを検証する。規格外の品質も検証。
診断メッセージが豊富。あやしいコードを指摘とか。
マクロ展開をtraceするとか
●検証セット、262項目
項目数 最低点 最高点
C90規格合致度 178 -162 448
C99規格合致度 20 0 98
c++98 8 0 24
診断メッセージ 45 0 67
その他 16 -40 111
計 262 722
●各種PPの検証
GCC 3.2の結果
CPPがまったくいれかわった。
●なぜ必要か
FreeBSD 2.2.2のkernelソース、libcソース
glicのソースを例に
●glibのソース
行をまたぐ文字列リテラル
●MCPPの実装
トークンベースの原則
文字ベースの処理をまぎれこませない。
関数型マクロの関数的展開
引数付きマクロの混乱の歴史
function-like原則の徹底
●実現できたこと
GCC 2.95.3対応
GCC 3.2R対応
include directryが複雑化している問題
3.2自体のCPPを置き換えられるように。
検証セットをGCC 3.2/testsuiteに対応
英語版ドキュメントの作成、翻訳会社に依頼している。400数十ページ。
GCC2 cpp2 cc1
GCC3 cc1
●GCC/testsuite
mkae -k check: runtestをよびたして、testcaseを検証
runtest: DejaGnuのツール群をよびだすshell-script
DejaGnu 汎用のテストツール (expect (Tcl/Tk))
/* { dg-do run } */
/* { dg-do preprocess } */
●やりのこしたこと
処理系をふやす。VCへの対応
●CVSレポジトリ
matsui-cpp
■手書きパターンの収集
PDAで手書き入力。
フリーな手書き入力パターン。
www.shikigami.com/~fukui/nnmnd/
64x64のデータフォーマット。
■異種協調
Prolog CafeとJavaの協調でJobShop問題の解消。
難しすぎてよくわからんかった。
■大場さん、連綿文字。
→たしかにかなりきれい。
■小松さん、予測入力の拡張
●プロフィール
小松
●予測入力方式
POBox ['96 増井]
SONYの携帯電話
あり →ありがとう →ございました
●Japanist、富士通、二文字いれるとOK。
●Wnn7, ATOKなど。
●SKK、単語の展開はある、
●POBox for Emacs
taiyaki.org/pobox/
サーバ
増井、C言語
岡田、C++
高林、RUby
●ここから未踏の成果
PRIME(Predictive Input Method Editor)
→サーバの作成
→入力クアイアント
→予測方式の改善 (文脈、新語・固有名詞)
●特徴
●単文節変換の実現
単文節変換が実現できるようになった。
その結果、文節を考慮した学習ができるようになった。
●複数変換エンジンのサポート
従来はクライアント側にもっていたが、サーバ側にエンジンをもつようにした。
●単語情報の抜本的変更
いままでは、記号がでてしまったり、字面の順にでた。
→従来
yosoko 予測
shin'ai 親愛
→今、頻度順にだせる
よそく 予測 サ行・名詞 15007
しんあい 新案 名詞 10002
●水鏡(Suikyo)
従来: suiky→すいky →予測失敗
今: suiky の段階で、展開してくれる。
●同音語辞書の作成
始めてと初めての違いとか。
MSIMEなどには標準で塔載している。
フリーなライセンスで近日公開
●接続方法
PRIMEサーバ
Rubyクラス →XIMクライアント
標準入出力 →Emacsクライアント
TCP/IP
Unixソケット
(セキュリティの確保が難しい)
●クライアントx漢字
→Emacs clietn
→XIM client
taiyaki.org/pobox/
●候補のしぼりこみ
複数の読みをいれることによって字をさがす。
か×ひ
かんじ×もじ
ひろゆき×しあわせ
●XIMクライアント
→Kinput2にRubyをうめこみ。
Kinput2コア→WNn, Cannnaと並列にRubyモジュール。
その上にPRIMEモジュール。PRIMEサーバと通信。
●Nanashiki(七式)
編集中の文章からえられた単語を予測候補に加える
gで祇園がでる
●デモ
メールの返信とか。
ウェブの内容をメールする
●新語・固有名詞の予測ができるように
一度見た単語は覚えてほしい。
Webページから情報収集
●デモ
→Webページをひらきながら見ていると予測してくれる。
(delegateによるproxyをかませて実現)
●Kukura「句倉」
→いまみているページの内容を予測。
制限時間をこえたものは見ていない。
●展望
公開するべし
単語辞書
●長期
Windows版の作成
PDA版の作成
他言語へのバインディング
もっと予測を!
●質問
→学習辞書
15000＋頻度
→Kukura
9600＋(500x頻度(1〜10程度))
→一般辞書
要するに、Kukura語はしばらく時間がたつと後のほうにもっていく。
★サーバ側の辞書データベース管理
→Sary
テキストのデータベース
インデックスを見ている。
共起的関係、原宿と表参道
排他関係、インターフェイスとインタフェイス
共起関係より、PPMのほうが予測精度がたかいらしい。
実装の問題でまだとりくんでいない。
→同じ言葉は省略して表示してほしい。
■閉会式
●新部
中国、韓国でオープンソースやろうぜという話をしにいった。
未踏には、ソフトウェアで面白いことやろうぜという気持が残っている。
Happy Hacking.
●近山
学会と違うのは、自分でやりたいことをやっている。
学会でもそうは言わないけど、すけてみえる。
みんな大変と言うが、すこし大変じゃないと楽しくないよね。
●紀
Kick offセミナーから半年。
たった半年とはいえ、内容が充実している。
PMは調査報告書を短期間でかかないといけない。