[過去ログ] (強いAI)技術的特異点/シンギュラリティ156 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
71: yamaguti 2019/04/04(木) 20:13:45.36 ID:oZpuEpFw(4/22)調 AAS
2chスレ:future SaitouSenseiMesoddo NanoKeizai
72: yamaguti 2019/04/04(木) 20:14:28.43 ID:oZpuEpFw(5/22)調 AAS
>28 名前:yamaguti E-mail:sageYdzZn_giE4w 投稿日:2019/03/27(水) 08:44:21.46 ID:qWdbt0oO?2BP(0) \>112 yamaguti 190316 1859 oq9O0c4s?
>> Google 翻訳 外部リンク[html]:www.cs.virginia.edu
>>
>>
>> バージニア大学コンピュータサイエンス学科
>> CS655:プログラミング言語
>> 2001年春
>>
>>
>> Smalltalkの背後にある設計原則
>>
>>
>> ダニエルHHインガルス
>>
>> 学習研究グループ
>> ゼロックスパロアルトリサーチセンター
>>
>> BYTE Magazine、1981年8月。(c)ニューヨークのThe McGraw-Hill Companies、Inc.。
>>コピー元 外部リンク[html]:users.ipa.net
>>Dwight Hughesによってスキャン 、(再作成されたグラフィックを含む)HTMLに変換
>
>
> 2chスレ:future DensiZunou SekkeiGaiyou
> 2chスレ:future KanseiZumi HannyouAI/AL
> 前回 2chスレ:future
前回 2chスレ:future
訂正
>? 良いデザイン: ry 一般的なもの ry は統一された枠組みの中に保持 ry 。
>? メッセージ:ry オブジェクト固有 ry
>メッセージ送信メタファは、メッセージの意図 (その名前で具現化されている)を、その意図の実行の為に受信者によって使用されるそのメソッドから、切離すことによってモジュール性を提供する。
ハイデルベルクニューロモルフィックコンピューティングプラットフォームへのHTMモデルの移植 2chスレ:future 2chスレ:future
73: yamaguti 2019/04/04(木) 20:15:07.76 ID:oZpuEpFw(6/22)調 AAS
外部リンク:google.jp
2chスレ:future 45,35 : HPKY # 40 : MetaAL , DSL Suityoku
2chスレ:future KenRon # DSL Suityoku
外部リンク:google.jp
外部リンク:google.jp
外部リンク:google.jp
2chスレ:future YuukiKa # TRONCHIP 68 32bitARM ## E2EDGE
2chスレ:future BurokkuDaiaguramu : SW26010 Cell
リンク先
>145 yamaguti~貸 171005 1350 Mw10xW3l? >176 yamaguti 180528 1221 x4HB0Rxw?
:
> >483 481 161004 1236 AszDQOBN
>>動的レンダリング自己イメージ意識人格基盤 内部外部幻影実在分身 縁リンク
>>TRONCHIP 根源要素透過可視大深度再帰自律実身仮身浸透細粒度動的鏡像 JIT/DSL
> :
>>拡張自律スプライト 細粒度リンク 思考文法関節
74(1): yamaguti 2019/04/04(木) 20:15:56.16 ID:oZpuEpFw(7/22)調 AAS
? ry 、クラスが拡張の主なメカニズムです。
Smalltalkでは、クラスは拡張の重要なメカニズム
? ry 、 ノート 、 メロディ 、 スコア 、 ティンバー 、 プレーヤーなどの表現とインタラ レを ry 。
例えば、音楽システムは、 Note 、 Melody 、 Score 、Timbre 、 Player 等の、表現とインタラクションプロトコルとを記述する新しいクラスを追加 によって作成されるでしょう。
? ry 「等脚」節は重要です。
それが設計されたようにシステムが使用されることを保証するので、上記の原則の「同等」節は重要
? ry 、メロディはピッチ、 ry 表す整数の ry 、言語が整数と同じくらい簡単にメモを処理できる場合、ユーザはメロディをメモの ry します。 。
言い換えると、メロディは、ピッチ、長さ、その他のパラメータを表す Integers のアドホックコレクションとして表すことができますが、 Notes を Integers と同じくらい簡単に言語が扱える場合、ユーザはメロディを音符のコレクションとして自然に記述します。
? ry がそれを提供する場合、人間は当然最も効果的な表現を選択します。
設計の各段階で、システムが提供する場合、最も効果的な表現を人間は当然選択します
? ry ます。
モジュール性の原則は、システム内の手続き型コンポーネントにとって興味深い意味合いがあります :
多態性: プログラムはオブジェクトの動作だけを指定し、それらの表現は指定しないでくださ
? ry 、与えられたオブジェクト ry が決して宣言するべきではなく、整数プロトコルに応答するということだけであるということです。
この原則の従来の言い方は、所与オブジェクトがSmallIntegerまたはLargeIntegerであることをプログラムは、決して宣言すべきでなくそして整数プロトコルに応答するだけにすべき、です。
? ry 一般的な説明は、 ry 。
そのような汎用的な記述は、現実世界のモデルにとって非常に重要
75: yamaguti 2019/04/04(木) 20:18:15.23 ID:oZpuEpFw(8/22)調 AAS
自動車交通シミュレーションを考え 。
そのようなシステムにおける多くの手順は、関係する様々な車両を参照す
? ry 、道路掃除人を ry 。
たとえば、道路清掃車を追加したいとします。
? コードが操作するオブジェクトに依存している場合、 ry 。
操作するオブジェクトにコードが依存している場合、この単純な拡張を行うには、かなりの量の計算(再コンパイルの形で)と起こり得るエラーが関係します。
メッセージインタフェースはそのような拡張のための理想的なフレームワークを確立
? ry です。
道路清掃車が他のすべての車両と同じプロトコルをサポートしていれば、シミュ にそれらを含めるための変更は不要です :
? ファクタリング: ry 各独立したコ ry トは1箇所にしか表示されません。
因数分解 ( 因枢分解 韻枢分解 ) : システム内の各独立コンポーネントは 1 箇所にしか現出しません
この原則には多くの理由があります。
まず第一に、システムへの追加が一箇所でのみ行われる必要がある場合、それは時間、労力、およびスペースを節約
? ry 簡単に見つけること ry 。
第2に、ユーザーは特定のニーズを満たすコンポーネントをより簡単に配置 できます
? ry 同期化し、相互 ry 。
第3に、適切な因数分解がないと、変更を同期化しそして相互に依存するすべてのコンポーネントが一貫 を保証する際に問題が発生
? 因数分解の失敗は ry 違反になることがわかります。
因枢分解での失敗がモジュール性の違反に達する様をあなたは目にします
76: yamaguti 2019/04/04(木) 20:22:20.02 ID:oZpuEpFw(9/22)調 AAS
? Smalltalkは継承を通じて、よく練られたデザインを奨励します。
継承を通じたよく因枢分解された設計をSmalltalk は奨励
すべてのクラスはそのスーパークラスから動作を継承
? この継承はますます一般的なクラスにまで拡張され、 ry デフォルトの動作 ry 。
より一層一般的なクラス達を通じてこの継承は拡張し、最終的には すべてのオブジェクトのデフォルト動作を記述するクラスObjectで終わ
? ry デフォルトの動作が継承され、さまざまな場所で同じ概念が繰り返されません。
上記の交通シミュ では、 StreetSweeper (および他のすべての車両クラス)は一般的なVehicleクラスのサブクラスとして記述されているため、適切なデフォルト動作を継承し、様々な場所での同概念の繰返しを避けます。
? ry ます。
継承は、ファクタリングのさらに実用的な利点を示しています :
? ry よく調整されていれば、 ry 。
レバレッジ: システムがよく因枢分解されていれば、ユーザーと実装者の両方にとって大きなレバレッ
順序付けられたオブジェクトのコレクションをソートする場合を考え 。
Smalltalkでは、ユーザーはOrderedCollectionクラスでsortというメッセージを定義します。
これが完了すると、システム内のすべての形式の順序付きコレクションが、継承を通じてこの新しい機能を即座に取得
? 余談ですが、比較プロトコルはテキストと数字の両方をサポートするクラスで認識されるため、同じメソッドでテキストとソート番号をアルファベット順に並べ替 できます
余談ですが注目すべきは、テキストと数字との両方をサポートするクラスで比較プロトコルは認識されるため、テキストアルファベット順化をだけでなく数値ソートをもがその同一メソッドは可能です。
77: yamaguti 2019/04/04(木) 20:24:05.95 ID:oZpuEpFw(10/22)調 AAS
実装者にとって構造の利点は明らか
まず、実装するプリミティブが少なくなります。
たとえば、Smalltalkのすべてのグラフィックは単一のプリミティブ操作で実行
? 1つの作業だけで、実装者はすべての命令に愛情のこもった注意を捧げることができ、効率のわずかな ry ことを知っています。
1 つの作業をするだけで、全ての命令に愛情篭った注意を実装者は捧げる事ができ、効率の其々僅かな改善がシステム全体で増幅される事を知ります。
? ry 、どの一連の基本操作で十分であるかを尋ねるのは自然です。
コンピューティングシステム全体をサポートするには、どんなプリミティブ操作セットならば足るかを尋ねる事は自然
? ry は仮想マシン仕様と呼ばれます。
この質問に対する答えはバーチャルマシン仕様と呼ばれます :
仮想マシン: 仮想マシン仕様は、テクノロジを適用するためのフレームワークを確立
? Smalltalk仮想マシンは、保存用のオブジェクト指向モデル、処理用の ry 。
Smalltalk バーチャルマシンは、ストーリッジ用のオブジェクト指向モデル、プロセッシング用のメッセージ指向モデル、および情報の視覚的表示用のビットマップモデルを確立
? ry コード、そして ry 使用することで、システムの他の利点を損なうことなくシステムのパフォーマンスを劇的に向上 できます。
マイクロコードを、そして最終的にはハードウェアを使用する事を介し、システムの他の美点に如何なる妥協も伴わずのシステムパフォーマンス劇的向上が可能です。
79: yamaguti 2019/04/04(木) 20:26:26.10 ID:oZpuEpFw(12/22)調 AAS
ユーザーインターフェース
? ユーザーインターフェイスは、 ry 。
ーザインタフェースは単純に、コミュニケーションの大部分が視覚的な言語です
? ry は確立された人間の文化と非常に重なるので、 ry 。
視覚的表現は確立済人間文化と著しくオーバラップするので、審美性はこの分野で非常に重要な役割 。
ータシステムのすべての機能は、最終的にはユーザーインターフェイスを通じて提供されるため、ここでも柔軟性が不可欠
? ry 指向の原則と言えます。
ーザーインターフェイスの十分な柔軟性を実現するための有効条件は、オブジェクト指向な原則と言えます :
? ry コンポーネントは、観察と操作のために意味のある方法でそれ自体 ry 。
反応原理: ユーザーがアクセス可能なすべてのコンポーネントはそれ自身を観察と操作との為の有意義な方法で提示できるべき
この基準は、通信オブジェクトのモデルによって十分にサポートされています。
定義上、各オブジェクトは対話のための適切なメッセージプロトコルを提供します。
このプロトコルは本質的にまさにその種のオブジェクトに特有のマイクロ言語です。
? ry キーボード操作 ry 使用を通して ry 。
ーザインタフェースのレベルでは、スクリーン上の各オブジェクトに適した言語が視覚的に(テキスト、メニュー、写真として)提示され、キーボード活動とポインティングデバイスの使用とを介して感知されます。
80: yamaguti 2019/04/04(木) 20:29:11.05 ID:oZpuEpFw(13/22)調 AAS
オペレーティングシステムはこの原則に違反しているように思われることに注意
? ry プログラマーは、他の点では一貫性のある記述の枠組みから離れ、どんな文脈が構築されていようとも、まったく異なる、通常は非常に原始的な環境を扱わなければなりません。
ここでプログラマは、一貫性ある記述フレームワークから逆に立去り、構築済な如何なる文脈も置去りにして、全く異なったそして通常とても原始的な環境を取回します。
これはそうである必要はありません:
? ry 集まりです。 ないはずです。
ィングシステム: オペレーティングシステムは、言語に収まらないものの集まりです。 それらを一つにすべきでない。
?
これらは、Smalltalk言語内に自然に組み込まれてきた従来のオペレーティングシステムコンポーネントの例です。
* ストレージ管理 -
全自動
? ry され、それ以上の参照が存在しなくなったとき ry 。
オブジェクトは、そのクラスへのメッセージによって作成され、 それらへの参照がもはやなくなった時に回収されます。
仮想メモリを介したアドレス空間の拡張も同様に透過的
* ファイルシステム -
? ry 持つファイルやディレクトリなど ry 。
ァイルアクセスをサポートするメッセージプロトコルを持つ Files や Directories などのオブジェクトを通じて、通常のフレームワークに含まれます
* ディスプレイの取り扱い -
? ディスプレイは単に継続的に見えるFormクラス ry 。
ィスプレイは継続的可視な単なる Form クラスのインスタンスであり、そのクラスで定義されているグラフィカル操作メッセージは可視画像を変更するために使用さ
* キーボード入力 -
? ry に、状態を判断したり、一連のイベントとして履歴 ry 。
ーボード入力 - ユーザー入力デバイスも同様に、それら状態を判断したり、イベントのシーケンスとして履歴を読み取ったりするための適切なメッセージを持つオブジェクトとしてモデル化されています。
81: 2019/04/04(木) 20:31:02.50 ID:UJwAImLJ(1)調 AAS
どうなってんだ?
迷惑なやまぐちとあぼーんしかない
82: yamaguti 2019/04/04(木) 20:36:01.97 ID:oZpuEpFw(14/22)調 AAS
* サブシステムへのアクセス -
? ry 大規模な記述領域を利用でき、ユーザーとの対話を伴うサブシステムはユーザーインターフェイスのコンポーネントとして参加できます。
サブシステムは、Smalltalk内に独立したオブジェクトとして自然に組み込まれています。そこでは、既存の大規模な記述の宇宙をキャンバスにでき、それらは、ユーザインタフェース内のコンポーネントとして参画できるユーザとの、インタラクションを取込んでいます。
? ry は、一連のスタックフレームを所有 ry 。
Smalltalkプロセッサの状態は、スタックフレームのチェーンを所有するProcessクラスのインスタンスとしてアクセスできます。
* デバッガ -
? デバッガは、中断された ry 。
デバッガは、サスペンドされたプロセスの状態を操作するためのアクセス権を持つ、単なるSmalltalkサブシステムです。
? ry 唯一の実行時エラーは、 ry 。
Smalltalkで発生する可能性があるほぼ唯一のランタイムエラーは、メッセージが受信者によって認識されないこと
? Smalltalkにはそれ自体「操作システム」はありません。
Smalltalk はそれ自体では「オペレーションシステム」を持ちません
? ry 必要な基本操作は、その他の点では通常のSmalltalkメッセージに応答して基本メソッド ry 。
ディスクからページを読み取るなどの必要なプリミティブオペレーションは話が別であり通常の Smalltalk メッセージに応答するプリミティブメソッドとして組み込まれています。
83: yamaguti 2019/04/04(木) 20:38:42.00 ID:oZpuEpFw(15/22)調 AAS
今後の取り組み
予想されるように、Smalltalkでの作業はまだ残っています。
説明が最も簡単な部分は、このホワイトペーパーの原則の継続的な適用です。
たとえば、Smalltalk-80システムは階層継承のみをサポートしているため、ファクタリングが不十分です。
将来のSmalltalkシステムはこのモデルを任意の(複数の)継承に一般化するでしょう。
また、メッセージプロトコルは形式化されていません。
? 組織はプロトコルを ry 。
オーガナイぜーションはプロトコルを規定していますが、プロトコルがクラス間で一貫していることは現在のところスタイルの問題です。
これは、一貫して共有できる適切なプロトコルオブジェクトを提供することで簡単に解決できます。
これにより、多態性の利点を失うことなく、プロトコルによる変数の正式な型指定が可能
? ry ことがより容易ではありません。
他の残りの仕事は明瞭にする事が容易と言うに足りません。
この論文では扱われていない、人間の考えには明らかに他の側面があります。
? ry できる比喩として識別 ry 。
これらは既存の言語モデルを補完することができるメタファとして識別されなければならない。
84: yamaguti 2019/04/04(木) 20:40:26.07 ID:oZpuEpFw(16/22)調 AAS
時には、コンピュータシステムの進歩は憂鬱なほど遅いように思われます。
? 蒸気機関車が ry を忘れています。
蒸気機関が私たちの祖父母にとってハイテクであったことを我々は忘れています。
私は状況について楽観的
? 実際、コンピュータシステムはより ry 。
コンピュータシステムは、実際、よりシンプルになり、その結果、より使いやすくなっています
? ry を閉じたいと思います。
私はこのプロセスを支配する一般原則を纏めたいと思います :
? ry き換えられるべきです。
自然な選択: 健全なデザインの言語とシステムは存続するでしょう、より良いものだけによって置換えられて。
時計が刻々と動いている間でさえ、創造的な精神のためのますます優れたコンピュータサポートは進化しています
? すぐ助けに行くからね。
救援は途中まで来ています
バージニア大学
CS 655:プログラミング言語
evansATcs.virginia.e
? ry 22秒
最終更新日:月曜日3月19日17時13分22秒 2001 年
上下前次1-新書関写板覧索設栞歴
あと 917 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ アボンOFF
ぬこの手 ぬこTOP 0.246s*