RFC1019 日本語訳

1019 Report of the Workshop on Environments for ComputationalMathematics. D. Arnon. September 1987. (Format: TXT=21151 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                           D. Arnon
Request for Comments: 1019                                    Xerox PARC
                                                          September 1987

コメントを求めるワーキンググループD.アルノンの要求をネットワークでつないでください: 1019 ゼロックスPARC1987年9月

  Report of the Workshop on Environments for Computational Mathematics
                                July 30, 1987
                          ACM SIGGRAPH Conference
              Anaheim Convention Center, Anaheim, California

コンピュータの数学の1987年7月30日ACM SIGGRAPHコンファレンスアナハイムコンベンションセンター、アナハイム、カリフォルニアへの環境に関するワークショップのレポート

Status of This Memo

このメモの状態

   This memo is a report on the discussion of the representation of
   equations in a workshop at the ACM SIGGRAPH Conference held in
   Anaheim, California on 30 July 1987.  Distribution of this memo is
   unlimited.

このメモは1987年7月30日にアナハイム(カリフォルニア)で開催されたACM SIGGRAPHコンファレンスにおけるワークショップにおける、方程式の表現の議論に関するレポートです。 このメモの分配は無制限です。

Introduction

序論

   Since the 1950's, many researchers have worked to realize the vision
   of natural and powerful computer systems for interactive mathematical
   work.  Nowadays this vision can be expressed as the goal of an
   integrated system for symbolic, numerical, graphical, and
   documentational mathematical work.  Recently the development of
   personal computers (with high resolution screens, window systems, and
   mice), high-speed networks, electronic mail, and electronic
   publishing, have created a technological base that is more than
   adequate for the realization of such systems.  However, the growth of
   separate Mathematical Typesetting, Multimedia Electronic Mail,
   Numerical Computation, and Computer Algebra communities, each with
   its own conventions, threatens to prevent these systems from being
   built.

1950年代以来、多くの研究者が、対話的な数学の仕事の自然で強力なコンピュータ・システムのビジョンがわかるために働いています。 この頃は、シンボリックで、数字の、そして、グラフィカルで、documentational数学の仕事のための融合システムの目標としてこのビジョンを言い表すことができます。 最近の、パーソナルコンピュータ(高画質スクリーン、ウィンドウシステム、およびネズミがいる)の開発、高速ネットワーク(電子メール、および電子出版)はそのようなシステムの実現に、十二分に適切な技術的なベースを作成しました。しかしながら、別々のMathematical Typesetting、Multimedia Electronicメール、Numerical Computation、およびコンピュータAlgebra共同体の成長(それ自身のコンベンションがあるそれぞれ)は、これらのシステムが構築されるのを防ぐと脅かします。

   To be specific, little thought has been given to unifying the
   different expression representations currently used in the different
   communities.  This must take place if there is to be interchange of
   mathematical expressions among Document, Display, and Computation
   systems. Also, tools that are wanted in several communities (e.g.,
   WYSIWYG mathematical expression editors), are being built
   independently by each, with little awareness of the duplication of
   effort that thereby occurs.  Worst of all, the ample opportunities
   for cross-fertilization among the different communities are not being
   exploited.  For example, some Computer Algebra systems explicitly
   associate a type with a mathematical expression (e.g.,   3 x 3 matrix
   of polynomials with complex number coefficients), which could enable
   automated math proofreaders, analogous to spelling checkers.

具体的に言うと、考えはほとんど現在異なった共同体で使用されている異なった表現表現を統一するのに与えられていません。 Document、Display、およびComputationシステムの中に数式の置き換えがあれば、これは行われなければなりません。いくつかの共同体(例えば、WYSIWYG数式エディタ)で欲しいツールもそれぞれによって独自に組立てられています、その結果起こる努力の複製の少ない認識で。 すべての最悪、異なった共同体での他家受精の十分な機会は利用されていません。 例えば、いくつかのコンピュータAlgebraシステムが明らかに数式(例えば、複素数係数がある多項式の3x3マトリクス)にタイプを関連づけます、スペル市松模様に類似しています。(数式は自動化された数学校正者を可能にすることができました)。

   The goal of the Workshop on Environments for Computational
   Mathematics was to open a dialogue among representatives of the

Computational MathematicsのためのEnvironmentsの上のWorkshopの目標は代表の中で対話を開くことになっていました。

Arnon                                                           [Page 1]

RFC 1019                                                  September 1987

アルノン[1ページ]RFC1019 1987年9月

   Computer Algebra, Numerical Computation, Multimedia Electronic Mail,
   and Mathematical Typesetting communities.  In July 1986, during the
   Computers and Mathematics Conference at Stanford University, a subset
   of this year's participants met at Xerox PARC to discuss User
   Interfaces for Computer Algebra Systems.  This group agreed to hold
   future meetings, of which the present Workshop is the first.  Alan
   Katz's recent essay, "Issues in Defining an Equations Representation
   Standard", RFC-1003, DDN Network Information Center, March 1987
   (reprinted in the ACM SIGSAM Bulletin May 1987, pp. 19-24),
   influenced the discussion at the Workshop, especially since it
   discusses the interchange of mathematical expressions.

コンピュータAlgebra、Numerical Computation、Multimedia Electronicメール、およびMathematical Typesetting共同体。 1986年7月に、スタンフォード大学のコンピュータとMathematicsコンファレンスの間、今年の関係者の部分集合は、コンピュータAlgebra SystemsのためにUser Interfacesについて議論するためにゼロックスPARCで満たされました。このグループは、今後の会合を開くのに同意しました。(そこでは、現在のWorkshopが1番目です)。 アラン・キャッツの最近の随筆、「方程式表現規格を定義することにおける問題」、RFC-1003、DDN Networkインフォメーション・センター、1987年3月(ACM SIGSAM Bulletin1987年5月、ページでは、翻刻します。 19-24), 特に数式の置き換えについて議論するので、Workshopで議論に影響を及ぼしました。

   This report does not aim to be a transcript of the Workshop, but
   rather tries to extract the major points upon which (in the Editor's
   view) rough consensus was reached.  It is the Editor's view that the
   Workshop discussion can be summarized in the form of a basic
   architecture for "Standard Mathematical Systems", presented in
   Section II below.  Meeting participants seemed to agree that: (1)
   existing mathematical systems should be augmented or modified to
   conform to this architecture, and (2) future systems should be built
   in accordance with it.

このレポートは、Workshopの転写であることを目指しませんが、むしろ、(Editorの意見における)荒いコンセンサスに達した主旨を抜粋しようとします。 以下のセクションIIに提示された「標準の数学のシステム」のために基本的な構造の形にWorkshop議論をまとめることができるのは、Editorの視点です。 ミーティング関係者は、以下のことに同意するように思えました。 (1) 既存の数学のシステムは、この構造に従うように増大するべきであるか、または変更されるべきです、そして、それに従って、(2)未来のシステムは構築されるべきです。

   The Talks and Panel-Audience discussions at the Workshop were
   videotaped.  Currently, these tapes are being edited for submission
   to the SIGGRAPH Video Review, to form a "Video Proceedings".  If
   accepted by SIGGRAPH, the Video Proceedings will be publicly
   available for a nominal distribution charge.

WorkshopでのTalksとPanel-聴衆議論は録画されました。 現在、これらのテープはSIGGRAPH Video Reviewへの服従のためにフォームa「ビデオ議事」に編集されています。 SIGGRAPHによって受け入れられると、Video Proceedingsは公的にわずかな分配料金に利用可能になるでしょう。

   One aspect of the mathematical systems vision that we explicitly left
   out of this Workshop is the question of "intelligence" in
   mathematical systems.  This has been a powerful motivation to systems
   builders since the early days.  Despite its importance, we do not
   expect intelligent behavior in mathematical systems to be realized in
   the short term, and so we leave it aside.  Computer Assisted
   Instruction for mathematics also lies beyond the scope of the
   Workshop.  And although it might have been appropriate to invite
   representatives of the Spreadsheets and Graphics communities, we did
   not.  Many of those who were at the Workshop have given considerable
   thought to Spreadsheets and Graphics in mathematical systems.

私たちがこのWorkshopから明らかに外した数学のシステムビジョンの1つの局面が数学のシステムの「知性」の問題です。初期からのシステム建築業者にとってこれは強力な動機です。 重要性にもかかわらず、私たちが、数学のシステムにおける知的な振舞いが短期で実現されると予想しないので、私たちは傍らにそれを残します。 また、数学のためのコンピュータ利用のInstructionがWorkshopの範囲を超えています。 そして、SpreadsheetsとGraphics共同体の代表を招待するのが適切であったかもしれませんが、私たちは適切であったというわけではありません。 Workshopにいた人の多くが数学のシステムのSpreadsheetsとGraphicsにかなりの考えを与えました。

   Financial support from the Xerox Corporation for AudioVisual
   equipment rental at SIGGRAPH is gratefully acknowledged.  Thanks are
   due to Kevin McIsaac for serving as chief cameraman, providing
   critical comments on this report, and contributing in diverse other
   ways to the Workshop.  Thanks also to Richard Fateman, Michael
   Spivak, and Neil Soiffer for critical comments on this report.
   Subhana Menis and Erin Foley have helped with logistics and
   documentation at several points along the way.

SIGGRAPHのAudioVisual設備レンタルのためのゼロックス社からの資金援助は感謝して承諾されます。 感謝は主要なカメラマンとして勤めるためのケビンMcIsaacのためです、このレポートで批判的なコメントを提供して、Workshopへの他のさまざまの方法で貢献して。 また、このレポートの批判的なコメントをリチャードFateman、マイケル・スピバク、およびニールSoifferをありがとうございます。 道に沿ったロジスティクスとドキュメンテーションが数ポイントにある状態で、Subhana Menisとアイルランドフォーリーは助けました。

   Information on the Video Proceedings, and any other aspect of the
   Workshop can be obtained from the author of this report.

Video Proceedingsに関する情報、およびWorkshopのいかなる他の局面もそうであることができます。このレポートの作者から、得ます。

Arnon                                                           [Page 2]

RFC 1019                                                  September 1987

アルノン[2ページ]RFC1019 1987年9月

I. Particulars of the meeting

I. ミーティングの子細

   The Workshop had four parts: (1) Talks, (2) Panel Discussion, (3)
   Panel and Audience discussion, (4) and Live demos.  Only a few of the
   systems presented in the talks were demonstrated live. However, many
   of the talks contained videotapes of the systems being discussed.

Workshopには、4つの部品がありました: (1) 会談、(2)パネルDiscussion、(3)パネル、Audience議論、(4)、およびLiveデモ。 ほんの会談で提示されたシステムのいくつかはライブな状態で示されました。 しかしながら、会談の多くが議論するシステムのビデオテープを含みました。

   The talks, each 15 minutes in length, were:

会談(長さ各15分)は以下の通りでした。

   1. "The MathCad System: a Graphical Interface for Computer
      Mathematics", Richard Smaby, MathSOFT Inc.

1. 「MathCadシステム:」 「コンピュータ数学のためのグラフィカルインタフェース」、リチャードSmaby、MathSOFT Inc.

   2. "MATLAB - an Interactive Matrix Laboratory", Cleve Moler,
      MathWorks Inc.

2. 「MATLAB--、対話的なマトリクス研究所、」、クリーブ・モウラー、MathWorks Inc.

   3. "Milo: A Macintosh System for Students", Ron Avitzur, Free Lance
      Developer, Palo Alto, CA.

3. 「ミロ:」 「学生のマッキントッシュシステム」、ロンAvitzur、Free Lanceの開発者、パロアルト、カリフォルニア。

   4. "MathScribe: A User Interface for Computer Algebra systems", Neil
      Soiffer, Tektronix Labs.

4. 「MathScribe:」 「コンピュータAlgebraシステムのためのUser Interface」、ニールSoiffer、テクトロニクスLabs。

   5. "INFOR: an Interactive WYSIWYG System for Technical Text",
      William Schelter, University of Texas.

5. 「INFOR:」 「技術的なテキストの対話的なWYSIWYGシステム」、ウィリアムSchelter、テキサス大。

   6. "Iris User Interface for Computer Algebra Systems", Benton Leong,
      University of Waterloo.

6. 「コンピュータ代数システムのための虹彩ユーザーインタフェース」、ベントンLeong、ウォータールー大学。

   7. "CaminoReal: A Direct Manipulation Style User Interface for
      Mathematical Software", Dennis Arnon, Xerox PARC.

7. 「CaminoReal:」 「数学ソフトウェアのための直接操作様式ユーザーインタフェース」、デニス・アルノン、ゼロックスPARC。

   8. "Domain-Driven Expression Display in Scratchpad II", Stephen
      Watt, IBM Yorktown Heights.

8. 「スクラッチパッドIIでのドメイン駆動の表現表示」、スティーブンWatt、IBMヨークタウンの高さ。

   9. "Internal and External Representations of Valid Mathematical
      Reasoning", Tryg Ager, Stanford University.

9. 「有効な数学の推理の内部の、そして、外部の表現」、Trygエージャ、スタンフォード大学。

   10. "Presentation and Interchange of Mathematical Expressions in the
       Andrew System", Maria Wadlow, Carnegie-Mellon University.

10. 「アンドリューシステムにおける、数式のプレゼンテーションと置き換え」、マリアWadlow、カーネギメロン大学。

   The Panel discussion lasted 45 minutes.  The panelists were:

Panel議論は45分続きました。 パネリストは以下の通りでした。

      Richard Fateman, University of California at Berkeley
      Richard Jenks, IBM Yorktown Heights
      Michael Spivak, Personal TeX
      Ronald Whitney, American Mathematical Society

リチャードFateman、カリフォルニア大学バークレイ校のリチャード・ジェンクス、マイケル・スピバク、個人的なテックスロナルド・ホイットニー、IBMヨークタウンの高さの数学会

Arnon                                                           [Page 3]

RFC 1019                                                  September 1987

アルノン[3ページ]RFC1019 1987年9月

   The panelists were asked to consider the following issues in planning
   their presentations:

パネリストが、計画における以下の問題が彼らのプレゼンテーションであると考えるように頼まれました:

   1. Should we try to build integrated documentation/computation
      systems?

1. 私たちは統合ドキュメンテーション/計算システムを構築しようとするべきですか?

   2. WYSIWYG editing of mathematical expressions.

2. 数式のWYSIWYG編集。

   3. Interchange representation of mathematics.

3. 数学の表現を交換してください。

   4. User interface design for integrated documentation/computation
      systems.

4. 統合ドキュメンテーション/計算システムのためのユーザーインターフェース設計。

   5. Coping with large mathematical expressions.

5. 大きい数式に対処します。

   A Panel-Audience discussion lasted another 45 minutes, and the Demos
   lasted about one hour.

Panel-聴衆議論はもう45分続きました、そして、Demosはおよそ1時間続きました。

   Other Workshop participants, besides those named above, included:

上で指定されたもの以外に他のWorkshop関係者は:だった

      S. Kamal Abdali, Tektronix Labs
      George Allen, Design Science
      Alan Katz, Information Sciences Institute
      J. Robert Cooke, Cornell University and Cooke Publications
      Larry Lesser, Inference Corporation
      Tom Libert, University of Michigan
      Kevin McIsaac, Xerox PARC and University of Western Australia
      Elizabeth Ralston, Inference Corporation

S.カマルAbdali、テクトロニクス研究室のジョージ・アレン、デザイン科学のアラン・キャッツ、情報科学が、より少ない状態でJ.ロバート・クック、コーネル大学、およびクックPublicationsラリーを任命して、推論は、西洋のオーストラリアのエリザベス・ラルストンの社のトム・リベールと、ミシガン大学ケビンMcIsaacと、ゼロックスPARCと大学です、推論社

II. Standard Mathematical Systems - a Proposed Architecture

II。 標準の数学のシステム--提案された構造

   We postulate that there is an "Abstract Syntax" for any mathematical
   expression.  A piece of Abstract Syntax consists of an Operator and
   an (ordered) list of Arguments, where each Argument is (recursively)
   a piece of Abstract Syntax.  Functional Notation, Lisp SExpressions,
   Directed Acyclic Graphs, and N-ary Trees are equivalent
   representations of Abstract Syntax, in the sense of being equally
   expressive, although one or another might be considered preferable
   from the standpoint of computation and algorithms.  For example, the
   functional expression "Plus[Times[a,b],c]" represents the Abstract
   Syntax of an expression that would commonly be written "a*b+c".

私たちは、どんな数式のための「抽象構文」もあるのを仮定します。 抽象的なSyntaxの1つの断片がOperatorとArgumentsの(命令される)のリストから成ります。(そこでは、各Argumentが抽象的なSyntaxの1つの(再帰的に)断片です)。 機能的なNotation、Lisp SExpressions、Directed Acyclic Graphs、およびN-ary Treesは抽象的なSyntaxの同等な表現です、等しく表現しているという意味で、1か別のものが計算とアルゴリズムの見地から望ましいと考えられるかもしれませんが。例えば、機能表現「プラス[回[a、b]、c]」は一般的に「*b+c」に書かれている表現の抽象的なSyntaxを表します。

   A "Standard Mathematical Component" (abbreviated SMC) is a collection
   of software and hardware modules, with a single function, which if it
   reads mathematical expressions, reads them as Abstract Syntax, and if
   it writes mathematical expressions, writes them as Abstract Syntax.
   A "Standard Mathematical System" (abbreviated SMS) is a collection of
   SMC's which are used together, and which communicate with each other
   in Abstract Syntax.

「標準の数学のコンポーネント」(SMCを簡略化する)がソフトウェアとハードウェアモジュールの収集である、ただ一つの機能で、抽象的なSyntaxとそれが数式を書くかどうかとしてのそれらは抽象的なSyntaxとしてそれらを書きます。(それであるなら、それは、数式、読書を読みます)。 「標準の数学のシステム」(SMSを簡略化する)はSMCの収集です(一緒に使用されて、抽象的なSyntaxで互いにコミュニケートします)。

   We identify at least four possible types of components in an SMS.

私たちはSMSで少なくとも4つの可能なタイプの成分を特定します。

Arnon                                                           [Page 4]

RFC 1019                                                  September 1987

アルノン[4ページ]RFC1019 1987年9月

   Any particular SMS may have zero, one, or several instances of each
   component type.  The connection between two particular components of
   an SMS, of whatever type, is via Abstract Syntax passed over a "wire"
   joining them.

どんな特定のSMSにも、それぞれのコンポーネント型のゼロ、1、またはいくつかの例があるかもしれません。 彼らを接合しながら「ワイヤ」の上に渡された抽象的なSyntaxを通していかなるタイプのSMSの2つの特定の部品の間の接続があります。

   1) EDs - Math Editors

1) EDs--数学エディターズ

   These edit Abstract Syntax to Abstract Syntax.  A particular system
   may have editors that work on some other representations of
   mathematics (e.g., bitmaps, or particular formatting languages),
   however they do not qualify as an ED components of a SMS.  An ED may
   be WYSIWYG or language-oriented.

これらは抽象的なSyntaxに抽象的なSyntaxを編集します。 特定のシステムには、数学(例えば、ビットマップ、または特定の形式言語)のある他の表現に取り組むエディタがいるかもしれなくて、しかしながら、それらはSMSのEDの部品の資格を得ません。EDはWYSIWYGか言語指向であるかもしれません。

   2) DISPs - Math Displayers

2) DISPs--数学Displayers

   These are suites of software packages, device drivers, and hardware
   devices that take in an expr in Abstract Syntax and render it. For
   example, (1) the combination of an Abstract Syntax->TeX translator,
   TeX itself, and a printer, or (2) a plotting package plus a plotting
   device.  A DISP component may or may not support "pointing" (i.e.,
   selection), within an expression it has displayed, fix a printer
   probably doesn't, but terminal screen may. If pointing is supported,
   then a DISP component must be able to pass back the selected
   subexpression(s) in Abstract Syntax. We are not attempting here to
   foresee, or limit, the selection mechanisms that different DISPs may
   offer, but only to require that a DISP be able to communicate its
   selections in Abstract Syntax.

これらは抽象的なSyntaxでexprを中に入れて、それをレンダリングするソフトウェアパッケージ、デバイスドライバ、およびハードウェアデバイスの一組です。 Syntax->を抜き取ってください。(1) 例えば、組み合わせ、TeX翻訳者(TeX自身)とプリンタか、(2) 企みパッケージと企み装置。 DISPの部品は、(すなわち、選択)を「指すこと」を支持するかもしれません、それが表示した表現の中で、プリンタがたぶんフィックスでないフィックスにもかかわらず、端末のスクリーンはフィックスであるかもしれません。 指すことが支持されるなら、DISPの部品は抽象的なSyntaxで選択されたsubexpression(s)を戻すことができなければなりません。 異なったDISPsが提供するかもしれない選択メカニズムを見通すか、または制限するためにここで試みるのではなく、私たちは試みていますが、DISPが抽象的なSyntaxで選択を伝えることができるのが必要です。

   3) COMPs - Computation systems

3) COMPs--計算システム

   Examples are Numerical Libraries and Computer Algebra systems. There
   are questions as to the state of a COMP component at the time it
   receives an expression. For example, what global flags are set, or
   what previous expressions have been computed that the current
   expression may refer to.  However, we don't delve into these hard
   issues at this time.

例は、Numerical図書館とコンピュータAlgebraシステムです。表現を受けるとき、COMPの部品の状態に関して質問があります。 例えば、現在の表現が示すかもしれないどんなグローバルな旗が設定されるか、そして、すべての前の表現を計算してあります。 しかしながら、私たちはこのとき、これらの困難な問題を調べません。

   4) DOCs - Document systems

4) DOCs--ドキュメント・システム

   These are what would typically called "text editors", "document
   editors", or "electronic mail systems".  We are interested in their
   handling of math expressions.  In reality, they manage other document
   constituents as well (e.g., text and graphics).  The design of the
   user interface for the interaction of math, text, and graphics is a
   nontrivial problem, and will doubtless be the subject of further
   research.

これらは、「テキストエディタ」と呼ばれて、何が通常そうするだろうか、そして、「ドキュメントエディタ」、または「電子メール・システム」です。 私たちは彼らの数学表現の取り扱いに興味を持っています。 ほんとうは、彼らはまた、他のドキュメント成分(例えば、テキストとグラフィックス)を管理します。 数学、テキスト、およびグラフィックスの相互作用のためのユーザーインタフェースのデザインは、重要な問題であり、さらなる研究の確かに対象になるでしょう。

   A typical SMS will have an ED and a DISP that are much more closely
   coupled than is suggested here.  For example, the ED's internal
   representation of Abstract Syntax, and the DISP's internal
   representation (e.g., a tree of boxes), may have pointers back and

典型的なSMSには、ここに示されるより非常に密接に結合したEDとDISPがあるでしょう。 そして例えば、EDの抽象的なSyntaxの内部の表現、およびDISPの内部の表現(例えば、箱の木)がポインタを返してもらうかもしれない。

Arnon                                                           [Page 5]

RFC 1019                                                  September 1987

アルノン[5ページ]RFC1019 1987年9月

   forth, or perhaps may even share a common data structure.  This is
   acceptable, but it should always be possible to access the two
   components in the canonical, decoupled way.  For example, the ED
   should be able to receive a standard Abstract Syntax representation
   for an expression, plus an editing command in Abstract Syntax (e.g.,
   Edit[expr, cmd]), and return an Abstract Syntax representation for
   the result.  Similarly, the DISP should be able to receive Abstract
   Syntax over the wire and display it, and if it supports pointing, be
   able to return selected subexpressions in Abstract Syntax.

先へ、または恐らく、一般的なデータ構造を共有さえするかもしれません。 これは許容できますが、正準で、衝撃を吸収された方法で2つのコンポーネントにアクセスするのはいつも可能であるべきです。 例えば、EDは表現の標準の抽象的なSyntax表現、および抽象的なSyntax(例えば、Edit[expr、cmd])での編集命令を受け取って、結果の抽象的なSyntax表現を返すことができるはずです。 同様に、DISPは抽象的なSyntaxをワイヤの上に受けて、それを表示できるはずです、そして、指すのを支持するなら、抽象的なSyntaxで選択された「副-表現」を返すことができてください。

   The boundaries between the component types are not hard and fast. For
   example, an ED might support simple computations (e.g.,
   simplification, rearrangement of subexpressions, arithmetic), or a
   DOC might contain a facility for displaying mathematical expressions.
   The key thing for a given module to qualify as an SMC is its ability
   to read and write Abstract Syntax.

コンポーネント型の間の境界は、困難であって、速くはありません。 例えば、EDが簡単な計算(例えば、簡素化、「副-表現」の配列換え、演算)を支持するかもしれませんか、またはDOCは数式を表示するための施設を含むかもしれません。 与えられたモジュールがSMCの資格を得る主要なものは抽象的なSyntaxを読み書きするその性能です。

III. Recommendations and Qualifications

III。 推薦と資格

    1. It is our hypothesis that it will be feasible to encode a rich
       variety of other languages in Abstract Syntax, for example,
       programming constructs.  Thus we intend it to be possible to
       pass such things as Lisp formatting programs, plot programs,
       TeX macros, etc. over the wire in Abstract Syntax.  We also
       hypothesize that it will be possible to encode all present and
       future mathematical notations in Abstract Syntax (e.g.,
       commutative diagrams in two or three dimensions).  For
       example, the 3 x 3 identify matrix might be encoded as:

1. それは抽象的なSyntaxの豊かなバラエティーの他の言語をコード化するのが例えば可能であるという私たちの仮説です、構造物をプログラムして。 したがって、私たちは、それがLispフォーマット・プログラム、陰謀プログラム、TeXマクロなどのようなものを抽象的なSyntaxのワイヤの上に渡すのにおいて可能であることを意図します。 また、私たちは、抽象的なSyntax(例えば、2における可換図式か三次元)のすべての現在の、そして、将来の数学的表記をコード化するのが可能であることを仮定します。 例えば、3x3がマトリクス力を特定する、以下としてコード化されてください。

       Matrix[ [1,0,0], [0,1,0], [0,0,1] ]

マトリクス[ [1,0,0], [0,1,0], [0,0,1] ]

       while the Abstract Syntax expression:

抽象的なSyntax表現である間:

       Matrix[5, 5, DiagonalRow[1, ThreeDots[], 1],
       BelowDiagonalTriangle[FlexZero[]],
       AboveDiagonalTriangle[FlexZero[]]]

マトリクス[5、5、DiagonalRow、[1、ThreeDots[]、1、]BelowDiagonalTriangle、[FlexZero[]]、AboveDiagonalTriangle、[FlexZero[]]]

       might encode a 5 x 5 matrix which is to be displayed with a
       "1" in the (1,1) position, a "1" in the (5,5) position, three
       dots between them on the diagonal, a big fat zero in the lower
       triangle indicating the presence of zeros there, and a big fat
       zero in the upper triangle indicating zeros.

aと共に表示されることである5x5マトリクスをコード化するかもしれない、「(1、1)位置の1インチ、「(5、5)位置、それらの間の対角線に関する3つのドット、下側の三角形のそこでゼロの存在を示す大きい太っているゼロ、および上側の三角形のゼロを示す大きい太っているゼロにおける1インチ。」

    2. We assume the use of the ASCII character set for Abstract Syntax
       expressions.  Greek letters, for example, would need to be
       encoded with expressions like Greek[alpha], or Alpha[].
       Similarly, font encoding is achieved by the use of Abstract
       Syntax such as the following for 12pt bold Times Roman:
       Font[timesRoman, 12, bold, <expression>] Two SMCs are free to
       communicate in a larger character set, or pass font
       specifications in other ways, but they should always be able to

2. 私たちはASCII文字の組の抽象的なSyntax表現の使用を仮定します。 例えば、ギリシアの手紙は、ギリシア語[アルファ]、またはアルファー[]のような表現でコード化される必要があるでしょう。 同様に、字体コード化は以下などの抽象的なSyntaxの12ptの大胆なタイムズの使用でローマで達成されます: 2SMCsが、より大きい文字の組で自由に伝えることができる[timesRoman、12、大胆な<表現>]、またはしかし、他の方法によるパス字体仕様、それらがいつもできるべきである字体

Arnon                                                           [Page 6]

RFC 1019                                                  September 1987

アルノン[6ページ]RFC1019 1987年9月

       express themselves in standard Abstract Syntax.

標準の抽象的なSyntaxに言い表してください。

    3. COMPs (e.g., Computer Algebra systems), should be able to
       communicate in Abstract Syntax.  Existing systems should
       have translators to/from Abstract Syntax added to them.  In
       addition, if we can establish a collection of standard names and
       argument lists for common functions, and get all COMP's to read
       and write them, then any Computer Algebra system will be able to
       talk to any other.  Some examples of possible standard names and
       argument lists for common functions:

3. COMPs(例えば、コンピュータAlgebraシステム)は抽象的なSyntaxで交信するはずであることができます。 既存のシステムには、彼らに加えられた抽象的なSyntaxからの/には翻訳者がいるはずです。 さらに、私たちがCOMPのすべてのものに一般的な機能のために標準の名前とアーギュメントの並びの収集を確立して、それらを読み書きさせることができると、どんなコンピュータAlgebraシステムもいかなる他のも話すことができるでしょう。 一般的な機能のための可能な標準の名前とアーギュメントの並びに関するいくつかの例:

   Plus[a,b,...]
   Minus[a]
   Minus[a,b]
   Times[a,b,...]
   Divide[<numerator>, <denominator>]
   Power[<base>, <exponent>]
   PartialDerivative[<expr>, <var>]
   Integral[<expr>, <var>, <lowerLimit>,<upperLimit>] (limits optional)
   Summation[<<summand>, <lowerLimit>, <upperLimit>] (limits optional)

プラス[a、b] [a]マイナス[a、b]時間[a、b]を引いて 不可欠の状態で[<expr>、<var>、<lowerLimit>、<upperLimit>][<分子>、<分母>]パワー[<ベース>、<解説者>]PartialDerivative[<expr>、<var>]を分割してください、(限界、任意である、)、足し算[<<被加数>、<lowerLimit>、<upperLimit>](限界、任意である、)

      A particular algebra system may read and write nonstandard
      Abstract Syntax.  For example:

特定の代数システムは標準的でない抽象的なSyntaxを読み書きするかもしれません。 例えば:

   Polynomial[Variables[x, y, z], List[Term[coeff, xExp, yExp, zExp],
   ...

多項式、[変数[x、y、z]、List、[用語[coeff、xExp、yExp、zExp]…

      but, it should be able to translate this to an equivalent standard
      representation. For example:

しかし、それは同等な標準の表現にこれを翻訳できるべきです。 例えば:

   Plus[Times[coeff, Power[x, xExp], ...

そのうえ、[回、[coeff、[x、xExp]を動かしてください…

    4. A DOC must store the Abstract Syntax representations of the
       expressions it contains.  Thus it's easy for it to pass its
       expressions to EDs, COMPs, or DISPs.  A DOC is free to store
       additional expression representations. For example, a tree of
       Boxes, a bitmap, or a TeX description.

4. DOCはそれが含む表現の抽象的なSyntax表現を格納しなければなりません。 したがって、EDs、COMPs、またはDISPsに表現を述べるのは、簡単です。 DOCは自由に追加表現表現を格納できます。 例えば、Boxesの木、ビットマップ、またはTeX記述。

    5. DISPs will typically have local databases of formatting
       information.  To actually render the Abstract Syntax, the DISP
       checks for display rules in its database.  If none are found,
       it paints the Abstract Syntax in some standard way.  Local
       formatting databases can be overridden by formatting rules passed
       over the wire, expressed in Abstract Syntax.  It is formatting
       databases that store knowledge of particular display
       environments (for e.g., "typesetting for Journal X").

5. DISPsには、形式情報のローカルのデータベースが通常あるでしょう。 実際に抽象的なSyntaxをレンダリングするために、DISPはデータベースの表示規則がないかどうかチェックします。 なにも見つけられないなら、それは何らかの標準の方法で抽象的なSyntaxを塗装します。 抽象的なSyntaxで急送されたワイヤの上に通過された形式規則でローカルの形式データベースに優越できます。 それは特定の表示環境(例えば、「Journal Xのための植字」のための)に関する知識を格納する形式データベースです。

       The paradigm we wish to follow is that of the genetic code: A
       mathematical expression is like a particular instance of DNA, and
       upon receiving it a DISP consults the appropriate formatting
       database to see if it understands it.  If not, the DISP just

従いたいと思うパラダイムは遺伝情報のものです: 数式はDNAの特定の例に似ています、そして、それを受けるとき、DISPはそれがそれを理解しているかどうか確認するために適切な形式データベースに相談します。 そうでなければ、DISP、まさしく。

Arnon                                                           [Page 7]

RFC 1019                                                  September 1987

アルノン[7ページ]RFC1019 1987年9月

       "passed it through unchanged".  The expression sent over the wire
       may be accompanied by directives or explanatory information,
       which again may or may not be meaningful to a particular DISP.  In
       reality, formatting databases may need to contain Expert
       System-level sophistication to be able to produce professional
       quality typesetting results, but we believe that useful results
       can be achieved even without such sophistication.

「変わりのないことでそれを通過します。」だった ワイヤの上に送られた表現は指示か説明している情報によって伴われるかもしれません。(それは、再び特定のDISPに重要であるかもしれません)。 ほんとうは、形式データベースは、結果を植字するプロの品質を作り出すことができるようにExpert System-レベル洗練を含む必要があるかもしれませんが、私たちは、そのような洗練がなくても役に立つ結果を獲得できると信じています。

    6. With the use of the SMC's specified above, it becomes easy to use
       any DOC as a logging facility for a session with a COMP.  Therefore,
       improvements in DOCs (e.g., browsers, level structuring, active
       documents, audit trails), will automatically give us better
       logging mechanisms for sessions with algebra systems.

6. SMCのものの使用が上で指定されている状態で、COMPとのセッションに伐採施設としてどんなDOCも使用するのは簡単になります。 したがって、DOCs(例えば、ブラウザ(平らな構造の、そして、アクティブなドキュメント)は道を監査する)での改良、自動的に、代数システムとのセッションのために、より良い伐採メカニズムを私たちに与えるでしょう。

    7. Note that Abstract Syntax is human-readable.  Thus any text
       editor can be used as an ED.  Of course, in a typical SMS, users
       should have no need to look at the Abstract Syntax flowing
       through the internal "wires" if they don't care to.  Many will
       want to interact only with mathematics that has a textbook-like
       appearance, and they should be able to do so.

7. 抽象的なSyntaxが人間読み込み可能であることに注意してください。 したがって、EDとしてどんなテキストエディタも使用できます。 もちろん、典型的なSMSでは、ユーザは気にかけないなら抽象的なSyntaxが内部の「ワイヤ」を通して流れるのを見る必要性を全く持つべきではありません。 多くが教科書のような外観を持っている数学だけと対話したくなるでしょう、そして、彼らはそうすることができるべきです。

    8. Alan Katz's RFC (cited above) distinguishes the form (i.e.,
       appearance) of a mathematical expression from its content (i.e.,
       meaning, value).  We do not agree that such a distinction can be
       made.  We claim that Abstract Syntax can convey form, meaning,
       or both, and that its interpretation is strictly in the eye
       of the beholder(s).  Meaning is just a handshake between sender
       and recipient.

8. アラン・キャッツのRFC(上では、引用される)が内容(すなわち、意味、値)と数式のフォーム(すなわち、外観)を区別します。 私たちは、そのような区別をすることができるのに同意しません。 私たちは抽象的なSyntaxがフォーム、意味、または両方を伝えることができて、解釈が厳密に見物人の目にあると主張します。 意味はただ送付者と受取人の間の握手です。

    9. Help and status queries, the replies to help and status queries,
       and error messages should be read and written by SMC's in
       Abstract Syntax.

9. 助けてください。そうすれば、状態質問、助ける回答、状態質問、およびエラーメッセージは抽象的なSyntaxでSMCのものによって読み書きされるはずです。

   10. In general, it is permissible for two SMC's to use private
       protocols for communication.  Our example of a tightly coupled ED
       and DISP above is one example.  Two instances of a Macsyma COMP
       would be another; they might agree to pass Macsyma internal
       representations back and forth.  To qualify as SMC's, however,
       they should be able to translate all such exchanges into
       equivalent exchanges in Abstract Syntax.

10. 一般に、2SMCがコミュニケーションに個人的なプロトコルを使用するのは、許されています。 私たちの上のしっかり結合したEDとDISPに関する例は1つの例です。 Macsyma COMPの2つの例が別のものでしょう。 彼らは、前後に内部の表現にMacsymaに合格するのに同意するかもしれません。 しかしながら、SMCのものの資格を得るために、彼らはそのようなすべての交換を抽象的なSyntaxの等価交換に翻訳できるべきです。

Arnon                                                           [Page 8]

アルノン[8ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Apacheから2GB以上のファイルをダウンロードしようとすると403エラーが出ます

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る