モード切り換えせずにソフトキーボードと文字認識を 共存させることができる点と、 ストロークを書きはじめた瞬間に漢字単語候補が出る点は 画期的だと思うのだが、製品採用例や文献引用例が 全然無いのは残念なことである。 (2003/8/25 増井)

というか、何度か拝見しているのですが、 あまりにも画期的すぎて理解に頭がついていかない感じ。 「入」以外の例を見たいのですが。あと、配っているのですか？ (2003/8/25 美崎)

• BITPICT, VisuLan, KidSimなどと似ており、何が新しいのかよくわからない。
• セルオートマトンが面白いのと同じように、色々面白いのは確かかもしれない。
• しかしセルオートマトンと何が本質的に違うのかわからない。 Walfrumの本などは参照していない。
• セルオートマトンはあらゆるピクセルで同時に反応が起こるが、 Furnasのシステムではどのピクセルで書き換えが起こるかは非決定的である。
• セルオートマトンとは本質的に計算能力が異なると言っているのだが本当だろうか。
• そもそもインタフェースに使えるような代物ではなかろう。 なんでこういうのがCHIに採録されるのか。

(2003/8/1 増井)

ピクセルの組を書き換えることによって様々な画像処理や インタラクションが可能になるシステムの提案。 細線化、塗りつぶし、GUIのボタンなどの例を出している。 GUIのボタンというのは、あるピクセルをクリックすると そこをもとに連鎖的に反応が起こって画面が塗り潰されたりするという動作。

Macintosh上のユーザ操作を記録してニューラルネットで推論する ことにより、ユーザ操作を予測して提示するシステム。

宣伝のとおりならば素晴らしいが、 いらないことをうるさく言ってくるのでうっとうしいと 感じた人もいるようである。 私は使ったことがないのでよくわからない。(増井)

KidSimの商品版。ATGもついに商売の役にたったか？？

HyperCard上における繰り返し操作を自動的に検出して ユーザに指示する。システムの予測が正しいとユーザが 認めた後はシステムが自動的に繰り返し操作を実行して しまう。

Tcl/Tkを使って、操作履歴から機械学習的にXfを学習させようとしている。 問題が生じた場合はユーザに確認を求める。

進化的にきれいな絵を作る Sbartという プログラムの紹介。

PBEの先駆的システム。それにしても大昔である。 KidSIMのDave Smithは20年も似たことをやっているのか?? この論文で「Icon」という言葉が発明されたろいうのは 本当か?? Smithはその後Starのデザイナになったらしい。 (1997/6/10 増井)

PBEの歴史、機械学習の歴史、その融合、今後などについての Invited Talk

エディタ上でのユーザの操作履歴からプログラムを生成する。 エディタ操作は簡略化したもの(insert,delete,select,locate) をつかい、何文字/何語移動したか、語の先頭か最後か、操 作の周辺のコンテキストは、などの情報から汎化を行ないプ ログラムを生成して次の操作に適用する。 同じ操作が続くときは「エントロピー」の小さなプログラム を生成するためループを生成する。同じ操作は必ずマージす る/オペランドは正規表現に汎化する(例:「電話番号 222-8899の選択」と「234-2277の選択」を汎化すると 「2..-....の選択」というような正規表現になる)など、プ ログラムの生成方法はヒューリスティクスに頼っている。汎 化のしすぎを防ぐにはコンテキスト情報を使用する。 適用は1ステップずつ行ない、間違っていた場合はユーザが 訂正することによりインクリメンタルに目的のプログラムが できあがる。(Nixの例の場合などはユーザはほとんど訂正が 必要ない)訂正するとそれが失敗例として記憶され、次から はそれが考慮される。

dmacroと同じくユーザは普通のエディット操作をした後で その再実行を指定できるので便利と思われる。汎化がうまく いく(ように見える)のはエディット操作が限られており ヒューリスティクスがいろいろ使われているからである。 訂正が簡単ならばよいが、そのインタラクション手法については 書いていない。 訂正しない場合はdmacroと同じようなものである。 簡単に訂正できてかつ役にたつものはできるのだろうか？ 例がひとつしかない場合汎化は行なえないから最初から 設定されているヒューリスティクス(周囲のコンテキスト からの判断とか)に従うことになるだろう。これがうまく いく例も多いだろうがsearch-replaceと全然違う操作には 役にたたないのではないか。コピー/ペースト機能も無いし 実際の使用実験もされていない。(無理と思われる) 頑張ったらプログラムも作れないことはない、ということを 示したことに意義があるのだろうか。 Eagerにタイプは似ている。複雑なことが出来るが、その割に 操作が面倒で推論が当たらないように思われる

アプリケーションのGUI操作から自動的に再利用可能な部分を抽出し、 マクロとして登録するシステムである。 メールボッスのようなデータ集合の要素(ひとつのメール)に対して GUI操作が行なわれた場合、システムは他の要素に対しても同様の操作が 行なわれる可能性があると判断し、自動的にマクロ生成を開始する。 また、データの依存関係を解析することにより、操作された要素に 関連した操作のみを履歴から抽出/汎化してマクロを生成する。 異なる操作が行なわれたときにはまた別のマクロを自動生成する。 実際に他の要素に対して同じ操作が必要になった場合は、 用意されたマクロに対して新しい要素を適用可能かどうか、 実行前に試してみることができるようになっている。 (1997/2/8 増井)

複数ルールからの推論をDemoに加えたものらしい。 Stimulus(ユーザのアクション)とResponse(それに対する システムのアクション)の組を例示によって推論する。 お絵書きシステムと制約解決システムの外にエキスパート システムがいて、これが推論を行なう。 エキスパートシステムにstimulus,responceに関する factの集合を送りこむとその間の制約を70の規則から 推論する。

factsはどうやって選ばれるのかよくわからないが、これに よって推論結果も全然違ってくるはずである。Xeyeの例が 示してあるが、こんなに前堤条件をたくさん用意しかつ 苦労してやっとXeyeでは馬鹿馬鹿しいと思うが... (Xeyeとちょっと異なる仕様だったらすぐに使えなく なってしまうはず)

ユーザーの動作とそれに対するシステムの反応をデモすると, stimulus-response の関係がルールとして登録される. 例として XEyes を作っている. なかなか優れものかも知れない.

Director的時間制御とPBE的プログラミングを組み合わせた アニメーション(シミュレーション?)作成ことが目標 ユーザ操作や時間(刺激)に対する動き(反応)を定義することにより システムの動きを定義する。オブジェクトの生成/変型/削除/前進/などの 反応を使用できる。 描画モード/刺激定義モード/反応定義モード/テストモードを使う。 例示は一度だけで、「説明にもとづく学習」の手法を使う。 (システムの推論が違っていれば自分でテキスト編集して直す) Object.Responce(Param1,Param2...) when Condition という形の反応を作る。満たされる条件が複数あるときはリストの中から選ぶ。 e.g. 「車1と車2が重なっていないとき(condition)ハンドルが切られ たら車を回転させる」 リアルタイム反応モードでは操作のタイムスタンプを記録して アニメーションを作れる。直進/回転動作を設定できる。 * アプリケーションプログラムとリンクできないのが問題。

まさに車のレースのアニメーションを作るために考えられたように 見えるが.... とても汎用には見えない。

グラフィックエディタの操作ヒストリを、 操作前と操作後の状態を示すアイコンの組の列で 表現する。アイコンは重要なところだけ表示するように し、細かい一連の操作はまとめてアイコン組となる ように工夫されている。

Chimeraは以下の5個のテクニックを組みあわせたものだそうである。

• Graphical Search and Replace
• Constraint-based Search and Replace 離れた点でもひとつにする、etc.
• Constraints from Multiple Snapshots 複数の例から制約を推論
• Editable Graphical Histories 編集ヒストリをうまく紙芝居に
• Graphical Macros by Example そこからマクロを生成

のOverviewだと思う。

Chimeraは以下の5個のテクニックを組みあわせたものだそうである。

• Graphical Search and Replace
• Constraint-based Search and Replace 離れた点でもひとつにする、etc.
• Constraints from Multiple Snapshots 複数の例から制約を推論
• Editable Graphical Histories 編集ヒストリをうまく紙芝居に
• Graphical Macros by Example そこからマクロを生成

エンドユーザプログラミングをどうするべきかについての本。 PBEについても述べており、以下の点において問題があると 言っている。(p78) (他のところは読んでない)

1. 終了条件を示すことができない
2. 条件分岐を示すことができない
3. 操作が間違いを多く含んでいるとき困る
4. エラーを修正できない
5. 推論に高いコストがかる

だから、ユーザが簡単にプログラムを書けるようにした方が 有効だろうと言っている。

Dynamic Macroの場合はどうか？

1. 終了条件を示す必要はない
2. 確かに条件は示せない (Triggers式なら大丈夫か？)
3. 確かに困る (簡単な場合しか使わないから関係ないけど)
4. 確かに修正できない (同上)
5. 推論コストは低い

Dynamic Makeの場合はどうか？

1. 終了条件を示す必要はない
2. 条件はMakefileに書ける
3. 最終的に正しい操作をしていれば大丈夫
4. 修正は可能
5. 推論コストは低い

GP Layoutの場合はどうか？

1. 終了条件を示す必要はない
2. 条件は書けないが
3. 多少間違えてても大丈夫
4. 修正はむずかしい
5. 推論コストは低い(時間はかかるが)

GUIの初期デザインを高速に行なうために、 スライダなどを手書きしたら即使ったり試したり できるようにしたシステム

MondrianはChimeraと同じように、 図形の編集操作履歴をマクロとして登録することのできる システムである。 登録される各編集操作は 編集前の状態と編集後の状態を組にした ドミノ状のアイコンで表現され、 ビジュアルプログラミングの要素として再利用することができる。 Chimeraの場合と同様に、マクロ化にあたって システムは各種の推論や汎化を行なう必要があるが、 推論の様子を音声や自然言語テキストでユーザに知らせる 工夫がされているため、 間違った推論が行なわれた場合はユーザはすぐにそれに 気付いて修正を行なうことができる。

Quickenは米国でよく売れている金銭管理ソフトで あるが、簡単な予測機構によりかなり使い勝手が よくなっているらしい。たとえば

• 昔のチェックと同じようなエントリを入力 し始めると、前のエントリをそっくりコピーされる
• 日付のところに'15'と入力すると'15 May, 1997' などと拡張される

会計ソフト「大番頭」とか給料計算ソフト「大入袋」とかを 作っているミルキーウェイという会社と一緒になって 「インテュイット株式会社」 というものが97/2に出来たらしい。 個人向けソフト(日本版Quicken??)はまだ出ていない模様。 (1997/6/2 増井)

PBDと機械学習は似ているようで大きな違いがあり、 PBDではインタラクションが非常に重要な役割を持っていると いうことを述べている。
機械学習には以下のような特徴がある。

• 問題が定式化/抽象化されている
• 学習フェーズ/適用フェーズが明確に分離されている
• 学習のためのデータが豊富なことが多い
• どういう推論アルゴリズムを使うかが重要
• アプリケーションにあまり依存しない

一方、PBDの特徴は以下のようなものである。

• 推論途中にユーザが割り込んでよい
• 推論のためのヒントを与えたり、何を推論するかを制御したりしてできる
• システムに対するユーザのかかわりが推論アルゴリズムより重要 (良い推論アルゴリズムが必ずしもPBDでもうまく働くとはかぎらない)
• システムにものを教え込む姿勢が大事 (データだけ与えてつきはなすのと異なる)
• システムを教育する間にユーザの状況も変化する
• システムの反応によって、与える例データを変えられる
• 説明重視 (説明にもとづく学習)
• 常にSupervised Learning

このため、最もすぐれた機械学習アルゴリズムが インタフェースにおいても最適であるとは限らない。

確かに純粋な学習アルゴリズムをそのままPBDに適用することは できない。いわゆるAI的学習アルゴリズムがインタフェースに 役にたったことは全く無いような気もする。(1997/1/28 増井)

Active Web pageを例示で作れるシステム。 人のWebページ内の欲しい部分を切り出すフィルタとか CGIのフォームとかを例示で作ることができる。 「こういうパタンのこういう部分をこのように切り貼り」 といったことを指定できるパタン言語を持っており、 そのプログラムを例示から推論する。 推論はヒューリスティクスに頼っているが、ユーザが ヒューリスティクスを追加することができる。

杉浦氏のInternetScrapbookシステムに類似している。 パタンをユーザが指定できる点が違う。 パタン言語は結構強力。

IBM PC上で同じ操作を2度繰返すと音が鳴り、別のキーで そのパタンを繰返すことができるソフトウェア。 完全に2度(以上)同じ操作を繰り返す必要がある。 (ababと打っただけで音が出たらうっとおしいだろうから)

Cyphterの本で紹介されていたものだと思う。
1997年1月現在Web上でこの製品は宣伝されていない。(1997/1/30 増井)

GUIのなんでもかんでも例示でプログラムしてしまおうという 若干無謀な試みである。 「図形エディタでラバーバンドをどのように描くか」といった ことまで例示で指定する。 描画モードのようなものまで例示でプログラムできる。 Interface Builderでは設計モードと デモモードのふたつのモードをいったりきたりして静的な画面を 作っていくが、これに「Train」「Show」のふたつのモードを 追加する。Trainモードではユーザは実際のアプリ操作と全く 同じマウス/キー操作を行ない、その途中でShowモードにして 操作に対応するアプリのアクションを指定することができる。 システムは例示されたアクションから本当のアクションを 推定する。例えばTrainモードにおいてマウス押下とマウス 移動を指定し、Showモードでその間に点線を引くと、 システムは「マウスドラッギングにより点線が移動する」 ことを推論する。推論の間違いを訂正するため(プレファレンス) パネルを使用する。 描画エディタにおいてオブジェクトの生成や属性変更によく使用される パレットも簡単な操作で作ることができる。

マウスを押し下げたままでShowモードに移動するには特殊キーを 使用する。ではその特殊キーを含むインタフェースはどうやって 作るのだろうか?? 結局インタフェースを類型化してユーザが 選択できるオプションを増やしただけということのような 気がするが...

どのような例を与えるか/いくつ与えるか/によって この図のように PBEシステムを分類している。

B. A. Myersは，グラフィックスそれ自体が プログラムであるものをビジュアルプログラミング， プログラムは従来のテキストで記述され， プログラムのある側面や実行状態を表示するために グラフィックスを利用するものをプログラムビジュアライゼーションと 定義した ． さらに，描画が静的なものか動的か，視覚化するものが コードかデータかの2つの軸によって以下の4種類に分類した．

• 静的コード視覚化システム 古典的なのは，プログラムを読み込みプログラムの制御構造を 自動的にフローチャートとして出力するものである． また，コードを整形出力するシステムもこの範疇に入る．
• 静的データ視覚化システム 例えば，MyersのIncenseはポインタ接続された構造体のような データ構造を自動的に図形出力した．
• 動的コード視覚化システム 例えば，一部デバッガのように， コードの実行されている部分を動的にハイライトする システム等が含まれる．
• 動的データ視覚化システム データの変化等を動的に表示するシステムで アルゴリズムアニメーションシステムが有名である．

(小池氏の bit別冊記事)

ゲームを簡単にPBEで作れるようにするためのGamutというツールの枠組。 システムと操作者の間のコミュニケーションを密にするための各種の工夫が 組み込まれている。

• ユーザは、システムが推論を行ないやすいように、 オブジェクトをつついて積極的に意味的なヒントを与える。 (e.g. 何か推論しろ、何を手がかりにしろ、そういう動作をするな、etc.)
• 「積み上げたカード」(ランダムにシャフルされる)を使って 動作を指示できる
• 実行時には見えなくなるガイド線/枠を使って動作を指示できる
• オブジェクトの動作パタンをアイコン化して切り貼りできる
• オブジェクトの以前の状態も影のように見えており、 以前の状態も次の行動の決定に使用できる (e.g. Marquise)

Emacsの補完(completion)機能の歴史。 70年代初頭のOS(XDS940, Tenex)などでコマンド行補完が 存在したらしいが、本当の起源は不明。

グラフィカルなルールの記述による ビジュアルプログラミング言語

ユーザと対話しながら学習していくシステムをDBLシステムという。 この方式により、メールで会議の時間を調整するシステムと グラフィックエディタを作ってみたというもの

「利己的な遺伝子」のDawkinsの進化に関する本。 人工的に「虫」を進化させて好みの虫を作るシステム 「BioMorph」の説明がある。 畝見のシステムに近い。

ペンによる文字入力時に、既に書いた文字からその次の 文字列を予測して表示し、その上をなぞるかなぞらないか により確定するかどうかを決めるというもの。 入力点の前の文字列から次の文字列を予測したりすることにより 手書き操作を10%〜44%削減することができるらしい。 実際のシステムを使った時間の測定については書いていない。

ソフトキーを使う 増井のシステムとの違いが非常に小さい。 「福島方式をソフトキーにしただけ」に見える。
何故手書き認識にこだわっているのかわからない。 増井方式の利点をあげるとすれば、

• プルダウンメニューで簡単に選択できる
• 曖昧検索を用いている
• 英語でも大丈夫(?) ピテカン方式となるか？
• 処理が軽い
• 入力が速い
• 場所を喰わない
• ストロークは少ない → 疲れない
  • 福島式: 「トーナメントに」が「ト」「ナ」「に」の3文字入力 (7ストローク) 漢字だったらもっと顕著に違うはず。
  • 増井式: 2〜3ストローク
• 文字種にこだわらず予測する
• 普通のソフトキーと同様にも使える
• 論文もペンで書ける(?)
• コンテクストを使用できる(?)

工作をしているときは最近使った工具を近くにちょっと 置いておくのが便利であるのと同様に、 ちょっと前に使ったコマンドを再利用できるようにするため ヒストリ情報を使う工夫について。 沢山の統計をとって解析している。 ``WORKBENCH''というシステムをSunViewで試作している。

結局「役にたつのかもしれないが、役に立ちかたが少ないんじゃないの？」という 卒直な意見である。 確かに、苦労して指定しなければならない割に見返りが少ない ようなPBDシステムが多いのが困りものである。 Dynamic Macroはそれを解決するものだと思う。

Stimulus(ユーザのアクション)とResponse(それに対する システムのアクション)の組を例示によって推論する。 お絵書きシステムと制約解決システムの外にエキスパート システムがいて、これが推論を行なう。 エキスパートシステムにstimulus,responceに関する factの集合を送りこむとその間の制約を70の規則から 推論する。

factsはどうやって選ばれるのかよくわからないが、これに よって推論結果も全然違ってくるはずである。Xeyeの例が 示してあるが、こんなに前堤条件をたくさん用意しかつ 苦労してやっとXeyeでは馬鹿馬鹿しいと思うが... (Xeyeとちょっと異なる仕様だったらすぐに使えなく なってしまうはず)

ユーザーの動作とそれに対するシステムの反応をデモすると, stimulus-response の関係がルールとして登録される. 例として XEyes を作っている. なかなか優れものかも知れない.

"お絵かきツールのユーザが操作の例を与えると システムがその例を汎化して操作手続を自動生成してくれる"

フォーマッティングの例を示すことにより システムがそれを汎化してマクロを作る。 例えばセクションタイトルのフォームを 例として与えるとシステムはそれを生成するような スタイルをヒューリスティクスで作成する。 (位置、フォント、番号付けなど)

バラエティがかなり限られているようである。 結局カスタマイズしているだけのようである。 何故制約お

PBE(Programming by example)関係のサーベイ。 Demonstrational Interfaceをプログラマブルなものと そうでないもの、Intelligentなものとそうでないものに 分類している。プログラマブルでインテリジェントでない ものとしてEmacsのマクロ機能などをあげており、 ノンプログラマブルでインテリジェントなものとして MacDrawのコピー機能(コピーして移動させると、次に 複写を指示したとき前と同じスペーシングで表示される。) プログラマブルでインテリジェントなものとして Eager, Peridot, Metamouse, Thesysをあげている。 結局PBEでたいしたことはできないが応用はあるんじゃない？ という感じである。(1992 10/19)

エディタ上でのユーザの操作からプログラムを生成する。 エディタ操作は簡略化したもの(insert,delete,select,locate)を つかい、何文字/何語移動したか、語の先頭か最後か、 操作の周辺のコンテキストは、などの情報から汎化を行ない プログラムを生成して次の操作に適用する。適用は1ステップ ずつ行ない、間違っていた場合はユーザが訂正することにより インクリメンタルに目的のプログラムができあがる。 (Nixの例の場合などはユーザはほとんど訂正が必要ない) 訂正するとそれが失敗例として記憶され、次からはそれが 考慮される。このあたりについてはくわしく書かれていない。

dmacroと同じくユーザは普通がエディット操作をした後で その再実行を指定できるので便利と思われる。汎化がうまく いく(ように見える)のはエディット操作が限られており ヒューリスティクスがいろいろ使われているからである。 訂正が簡単ならばよいが、その手法がよくわからない。 訂正しない場合はdmacroと同じようなものである。 簡単に訂正できてかつ役にたつものはできるのだろうか？ 例がひとつしかない場合汎化は行なえないから最初から 設定されているヒューリスティクス(周囲のコンテキスト からの判断とか)に従うことになるだろう。これがうまく いく例も多いだろうがsearch-replaceと全然違う操作には 役にたたないのではないか。

PBDは``Just-in-time Programming''のための技法と考えられる。 これは「必要になったとき即時にプログラムを作る」という ものである。プログラムを普通のプログラム言語で書いたり キーボードマクロとして定義したりすることもできるのだが、 PBDにした方が楽なことも多いと考えられる。 Just-in-time Programmingには5つの障害が考えられる。 ・必要なデータや演算子にアクセスできない 既存のアプリの場合など ・アルゴリズムの入力に精神的/物理的手間がかかる ・本格的プログラムには汎用計算能力が必要だが、 マクロ定義はTuring機械になってないことが多い ・折角定義したプログラムを起動するのが面倒なことが多い ・かえって時間がかかるというリスクや、プログラムが うまく動かないかもしれないといったリスクが大きい。 PBDシステムはこれらの難点をクリヤしなければならない。

以前にタイプした文字から次の文字列を予測するシステムを Macintosh上に実装した。トライを使って頻度を覚えておく。 以前の文字列のうちいちばん長くマッチしたものから予測 する。予測結果はリストにして別ウィンドウに表示し、 マウスで選択できるようにしている。

以前にタイプした文字から次の文字列を予測するシステムを Macintosh上に実装した。トライを使って頻度を覚えておく。 以前の文字列のうちいちばん長くマッチしたものから予測 する。予測結果はリストにして別ウィンドウに表示し、 マウスで選択できるようにしている。 タイピングの速い人には役にたたないが障害者には役に たつのだそうである。 従来のシステムより良い点は以下のとおり:

• 適応型予測をしている
• どんどん次の文字を予測して文字列を表にして提示している
• 長くマッチしたものから使用しており正解率が高い

確かにプロにはあんまり便利そうでない。「障害者には便利」 というのはあまり面白いテーマとは思えない。 予測の方法(従来より良いと主張している点)も特にすごいとは 思えないが... RK-ButtonというUNIXのコマンドライン予測システムが ある。これはヒストリ機能の拡張のようなもので、これは 少しは役にたつかもしれない。(増井)

「繰返しコマンド列」(ヒストリ中に同じコマンドが 繰り返されるもの)を使って次のコマンド予測を行なった ときの手間を計算している。

繰返しコマンド列の定義と予測方法がよくわからないし 計算が意味があるとも思えない。

お絵かきツールのマクロを例示でプログラミングする。 学習した手順をグラフィカルに(絵の並びとして)エディット できる。

お絵書きソフトのトレースからマクロを作る. 全ての動 作のトレースが undo/redo のためにもともととられてい るので, ユーザーはマクロの開始と終了を意識する必要が ない. また出来上がったマクロは, パラメータも含めて全 て元のgraphical な表示で表されているので, ユーザーに とって分りやすい."

Starを模擬するSmallStarという例示プログラミングシステム。 マクロとしたい操作の最初に「start recording」 を指示して操作列を記録する。自動的にやらなかった理由は 操作列が長くなるのと、操作列をテキストにしてあとで 調べるのは大変だからだそうである。(この点は KurlanderのMacro By Exampleの方が優れていると思う) マクロとして定義した操作列はテキストとしてユーザが 編集することができる。

PBEを使ったプログラミング環境「Tinker」の紹介。 子供などのノンプログラマにプログラミングを教えるのには 抽象的な概念よりも具体的な操作でやる方が有効であると いうことがLogoにおけるInstant Turtuleシステムで 示されている。Instant Turtleでは実際の操作をマクロ化 することができる。(操作のあとで「さっきのをマクロ化して」 と言うことができる)
Instant Turtleは単なるマクロ化しかできなかったが、 Tinkerではこれを拡張して引数の変数を指定したり条件分岐を 示したり再帰呼び出しを定義したりできるようになっている。

制御を指定できるようにするのはやっぱり苦しいと思う。 (増井)

例示により配置やダイアログを指定するUIMS。Motifを使用 している。

A kind of filter, that converts a pattern to another pattern. The conversion can be taught with examples.

筆者の開発したエディタ「Ｕ」上で、テキストの変換前と 変換後の例を与えることによりそれらの間の変換を推論して 残りのテキストにそれを適用する。 変換はregexpのsearch&replaceのサブセット(繰り返しの 指定などができない。単なる変数置換だけ)のようなもので 「gap programming」と呼ばれるプログラムを使う。 使うときは、まず変換前のテキストを例として示し、 その後変換後のテキストを示すことによって推論が行なわれて プログラムが生成される。一つの例だけでは正しく推論され ないことがあるので、そういう場合は複数の例を示すことにより 正しいプログラムを得る。(これはかなり面倒であろう) このように明示的にいろいろ示さなければならないので 使いやすいとは思えないが、gap programminの使用、その推論、 証明に力をいれている。 推論されたgap progrmは後で修正することも可能である。 ちなみに、この論文で示されている例はすべてdmacroで簡単に 実現できるので使い勝手は明らかにdmacroの方が優れている。 変換の入力と出力の関係だけからその変換プログラムを推論する という点は面白いかもしれないが、これはいわゆる自動プログラ ミングの範疇かもしれない。(93/3/1 増井)

商品版はCOCOACypher_Cocoa

図形の編集操作列において、点や線同志の接触関係を頼り にして操作列からプログラムを抽出する。接触している複 数のポイントのうちどれが重要かはユーザが教えてやる。 システムが何を推論しているかは「亀のBasil」がいつも 指示しているので、間違えたりしかけたらなるべく早目に ユーザがシステムに知らせることにより無駄な推論を避け させている。 プログラムはproductio ruleのように表現される。単一の 例からでも変数や制約を抽出したプログラムを生成する。 似たようだがちょっと違う例があるときは、より詳細な条 件をもつruleが生成され、条件分岐のように働く。ruleが ループを構成するとき繰り返し操作が実現できる。 以前の操作と完全に同じ操作を始めたときは、システムが すぐに次の行動を予測して提示する。(同じ操作を2度以上 含む大きな繰り返しは検出できないことになる?)

Robert Nix describes a radical approach to inductive inference in a system which provides what he calls editing by example. The system generates programs to do text transformations. The use gives the system one or more examples of some text before and after some editing operations. Based on these examples, the system construts a generalized proram to do the transformation. Note that the system does not look at the editing operations themselves, only at the example input and output. Input and output examples are given separetely and do not always need to ocur in pairs. By using various heuristic, the system can synthesize some desired programs using just a few input examples for each program. Synthesized progrms are presented to the user so that he can verify their correctness.
This approach is very different from the algorithmic methods of programming by example used in systems such as Pygmalion, since it pays no attention to the user's actions. Nevertheless, Nix finds it is a feasible way of creating text-editing programs, and believes further work should be done on similar practical applications of inducive inference. (SmallStarの論文からの引用)

Edwardはグラフィックインタフェースにおけるユーザの手順 から次の操作を推論するシステムである。(e.g. Eager, Metamouse) 手順の推論方式自体はEagerと似たようなもののようで あるが、自然言語でユーザが操作を指示することができるし システムも自然言語で説明したり聞いてきたりする。 推論された手順はマクロとして名前をつけてセーブして おくことができるし、これを編集することもできる。 サーベイ的にいろいろな意見が書いてある。

• PBEとかDemonstrational Interfaceとかいうよりも Action Inferring Interfacesという名前が適当。
• 手順指示型システムは、ワープロ打ちのようなプロ には便利なはずである。特に繰り返しが多いアプリ ケーションではそうである。
• また決まった手順(ルーチンワーク?)が多いときも 有用である。インテリジェントヘルプにも使える。
• このようなインタフェースではUNDOできることが 重要である。
• 推論は正しいことを証明することはできないし ノイズにより誤った推論をすることも多い。 (例)場所をあけるためにアイコンを右に移動する - 「場所をあけるため」などという意図はわからない。
• そもそも正しく推論が絶対不可能なこともある。 (例)昨日のパーティーに来てた人達のアイコンだけ 移動する

システム自体はそう面白くないが、PBE全般に関し 意見がいろいろ書いてあって面白い。 やっぱり、苦労して推論するよりも何も推論しない アプローチが正しく思えるが。 (増井)

グリッド上でのレイアウト操作例をシステムが汎化するが、 ユーザに汎化プロセスを提示してユーザに選択させるという 「共同作業」により汎化を助ける。 たくさんの例を与えればより正確な汎化が可能であるが、 少ない例から各種の配置アルゴリズムを計算してそれを 別の例に適用した結果をユーザに提示してその中から選択 させることにより正しいものを選ぶ方が楽との考えである。 制約の手法はオブジェクトの数が変わると困るが、配置 アルゴリズムを使うときはオブジェクトの数が増えても 大丈夫である。 人と共同してアルゴリズムを決めるという意味では Kochhar_CCADのフロアプラン配置手法と似ている。 アルゴリズムは「内挿」及び「繰返し」により推論する。

(1)
(2) (3)

という操作から

(1)
(2)
(3) (4) (5)

というのを推論するのが内挿で、

(1)
(2) (3)
(4) (5)

と推論するのが繰返しである。 これらをいろいろ組み合わせてアルゴリズムを作り、 適用結果をユーザに提示する。

アイデアには面白いところも多いが、実際にはあまり有用では なさそうである。 Dawkinsのように人為的に虫を作るのに似ているか？ (1993/12/16 増井)

トロント大学のMENULAYというUIMS。表示したい出力をエディットすると、 そのUIを示すプログラムが出力される。設計者はそれと実際の動作を行う関数を リンクすることによって目的のシステムを得る。例示によるプログラミングの考えに つながる。

Mac上(?)のユーザの操作がプログラムとして「操作前」「操作後」 のポンチ絵(Kurlanderのもののように)表示されるらしい。 フォルダから新しいTeXファイルを選んで別のフォルダにコピー すると、「6/23以降」とかラベルのついたアイコンがあらわれ、 コピー前と後の状態を示すフォルダが絵で示されるというような 例が書いてあるが、どうしてそんなことができるのか不明である。 PURSUITというのはビジュアルシェルの名称らしい。