約 1,716 件
https://w.atwiki.jp/akios/pages/34.html
3. 字句構造 3.1. Unicode 3.2. 字句変換 Unicode文字の未加工ストリームは以下の3ステップで行われる字句変換(lexical translations)によってトークンと呼ばれるものの列に変換されます。順に説明すると Unicode文字の未加工ストリーム内のUnicodeエスケープを対応するUnicode文字へ変換します。Unicodeエスケープは\uxxxxで記述され、ここでxxxxは16進数、符号化された値がxxxxであるUTF-16コード単位を表します。この変換ステップがあることによってあらゆるプログラムをASCII文字のみによって記述することが可能です。 ステップ1の結果を、入力文字と行終端子の列に変換します。 ステップ2の結果から、空白とコメントを取り除き、構文文法で使用する終端記号であるトークンで構成される入力要素の列へと変換します。 個々のステップは最長一致によって変換が行われます。最長一致変換では最終的に正しいプログラムにならない場合でも、ステップの順序を途中で変えて行うことはありません。 このように、入力文字a--bはa、--、bとトークン化されます。これは文法的に正しいプログラムではりません。a、-、-、bとトークン化されれば文法的に正しいプログラムですがこうはトークン化されません。 3.3. Unicodeエスケープ 3.4. 行終端子 3.5. 入力要素とトークン 3.6. 空白 3.7. コメント 3.8. 識別子 3.9. キーワード 3.10. リテラル 3.11. 分離子 3.12. 演算子
https://w.atwiki.jp/nofx/pages/22.html
α : 記号列(空列εを含む) α∈(N∪Σ)* First(α) : αの始動記号の集合 First(α) = { a | a∈N, α⇒a…} A : 非終端記号 Follow(A) : Aの追随記号の集合 Follow(A) = { a | a∈N, S⊥⇒…Aa…} (開始記号S、Follow(S)は文末記号⊥を含む) 生成規則 A→α (A:非終端記号、 α:記号列) に対して、 Director(A,α) : 生成規則 A→α の引率記号の集合h Director(A,α) = First(α) (α⇒εでないとき) First(α) ∪ Follow(A) (α⇒εのとき) 文法G=(N,Σ,P,S)において、右辺だけ異なる任意の生成規則A→αとA→βに対してDirector(A,α)∩Director(A,β)=Φが成り立つとき、GはLL(1)文法であるという。 与えられた文法がLL(1)文法であれば、入力トークン列の先頭の終端記号を見れば、次にAのどの生成規則を使用すべきかが決定できる。 ■非終端記号Xに対してXが空列を生成しうるか否かを判定するアルゴリズム (X⇒εか否か?) 配列ary[]を用意し、Xに対応するary[X]は次のような値を持つものとする。 yes (Xが空列を生成すると決定したとき) ary[X] = no (Xが空列を生成しないと決定したとき) u (未定) まず、全ての非終端記号Xに対してary[X]= uとする 右辺に終端記号を含む全ての生成規則をチェックする。この結果、ある終端記号Xに対して全ての生成規則がチェックされたらary[X]= noとする 右辺に ε を持つ生成規則であれば、チェックし、その生成規則の左辺の非終端記号Xに対してary[X]= yesとする この時点で ary[X]= u であるXが残っているならば、次を ary[X]= u が無くなるまで以下を繰り返す。① 右辺に ary[X]= no を満たす非終端記号を持つ全ての生成規則をチェックする。この結果、ある非終端記号Yに関して全ての生成規則がチェックされたならary[X]= noとする② 右辺に ary[X]= yes を満たす非終端記号を持つ全ての生成規則からXを削除する。この結果、生成規則の右辺が空になったら、この生成規則をチェックしその左辺の非終端記号Yに関してary[X]= yesとする ■非終端記号Xに対して、始動記号の集合S(X)を求める手順 S(X)=φで初期化 S(X)が変化しなくなるまで以下を繰り返す。 X→aαなる生成規則があればS(X)=S(X) ∪ { a } X→Yαなる生成規則があれば① Y⇒ε ならS(X)=S(X) ∪ S(Y) ∪ S(α)S(α)の求め方は下に示す。② そうでないならS(X)=S(X) ∪ S(Y) ■記号列αに対して、始動記号の集合S(α)を求める手順 α=εのときS(α)=φ αの先頭が終端記号aのときS(α)={ a } α=Yβのとき① Y⇒ε ならS(α)=S(Y) ∪ S(β)② そうでないならS(α)=S(Y) ■非終端記号Bに対して追随記号の集合F(B)を求める手順 B:開始記号なら F(B)={⊥} (⊥:文末記号) B:開始記号以外なら F(B)=φ で初期化 F(B)が変化しなくなるまで以下を繰り返す。 右辺にBを含む生成規則を A→αBβで表す β=ε (Bが最後の記号)のときB≠Aなら F(B)=F(B)∪F(A)B=Aなら 何もしない βの先頭が終端記号aのときF(B)=F(B)∪{ a } 1.、2.以外の場合① β⇒εのときF(B)=F(B)∪S(β)∪F(A)② それ以外のときF(B)=F(B)∪S(β)
https://w.atwiki.jp/gear-jpn/pages/18.html
GEAR - How to create a biped rig VimeoのGear解説ムービー 0 00 イントロダクション メインメニューバーの[Gear]- [Character]- [Guide Tools]でガイドツールウィンドウの起動。 テンプレートタブから、汎用人型ガイドの紹介など。 ここから Guide Tools を使用して、スパイン、脚、足、腕、手、など一つ一つのリグガイドを作成し、それを元にリグを生成します。 ガイドツールによって作成されたヌルやコントロールアイコンは、描画のあと、いつでも適切な場所へ移動できます。 1 00 キャラクタ全体の基点とそのコントローラの設定 ガイドツールウィンドウから(メインメニューバーの[Gear]- [Character]- [Guide Tools]) コンポーネントタブで、メニューから[control_01]を選択、[描画]を押下し、ビューポート上をクリック。 シーン上に「Guide」という名のモデルが作成され、その下にリグ作成の基点となるNullと、表示用アイコンとなるオブジェクトが作成される。 セッティングウィンドウからは、名前、アイコンの形状などを指定できる(解説動画では名前を「Local」、形状は円形に設定) 3 35 胴体部の基点となる腰のコントローラの設定 前段階で作成したルートアイコンを選択した状態で、ガイドツールから[control_01]を選択、[描画]、ビューポート上をクリック。 ルートアイコンの子としてNullと表示用アイコンが作成される(解説動画では名前を「Body」、形状は四角に設定) 4 05 胴体スパインの設定 前段階で作成したBodyアイコンを選択した状態で、ガイドツールから[Spine_ik_01]を選択、[描画]、ビューポート上でスパインの起点と終点をクリック。 7 20 脚部の設定 前段階で作成したスパインのルートアイコンを選択した状態で、ガイドツールから[leg_int_01]を選択、[描画]、腿の付け根、膝、足首、足の方向を示すエフェクタの4箇所をクリックして指定。 9 30 脚部IKの設定 guide_leg設定ウィンドウから、RIGで生成されるIKコントローラとアップベクタコントローラの親となるオブジェクトを指定する。ムービーでは最初に作成した円形のLocalアイコンを指定。 10 05 足の設定 脚部で作成した leg_C0_ankle ヌルを選択し、ガイドツールから[foot_bk_01]を選択、[描画]。つま先へ向けて分割したいだけヌルを置く。右クリックで終了。 終了すると、足の裏の接地基点を指定するための3つのヌルが生成される。それぞれを踵の先、足の内外、に移動させる。 つま先のヌルも、つま先の接地する位置へ移動させておく。 12 30 脚から先のガイドをを左から右へ鏡面コピー leg_C0_rootヌルを選択しsettingのプロパティを開く(F3でアタッチメントを開きsettingをダブルクリック)。 メインタブ>Naming で「センター」をプルダウンして「レフト」に変更。(これで脚のガイド用ヌル一式の名前が leg_C0_** から leg_L0_** に変更されます) 同じくfoot_C0_root も設定ウィンドウからメインタブ>Naming で「センター」をプルダウンして「レフト」に変更。 (leg_L0_root を適切な位置に移動) leg_L0_root を選択して、ガイドツールウィンドウで、[Dupl.Symmetry]を押下。(これでX軸の反対側に、R0という名前の入ったガイド一式がコピーされます。) 14 20 肩の設定 胴体スパインガイドの終端エフェクタを選択した状態で、ガイドツールから[chain_01]を選択、[描画]。鎖骨の付け根から肩にあたる部分へヌルを置く。右クリックで終了。 セッティングのプロパティで名前をchain_01からshoulder_01に、センターをレフトに変更。 作成されたshoulder_L0_bladeアイコンを選択、加算モードで回転させて正面に向ける。 15 15 ガイドツールにテンプレートで用意されている[arm_guide]の紹介 15 55 腕の設定 肩のルートヌルを選択、settingプロパティ(F3でアタッチメントを開きsettingをダブルクリック)のオプションタブから、[Kinematic]-「タイプ」で「fk only」を選択。 肩のルートヌルを選択した状態で、ガイドツールから[arm_2int_01]を選択、[描画]。上腕の付け根(肩)、肘、手首、終端エフェクタ、を描く。 作成されたarm_L0_rootヌルのsettingプロパティで、オプションタブ、IK Reference、新規にピックを押し、IKの参照、及び肘のアップベクターの参照オブジェクトとして、local_C0_rootと肩のルート、終端、3つのヌルを指定。右クリックで指定終了。IK Referenceのプルダウンメニューに選んだ3つが候補として出るので、ここではlocal_C0_rootを選択。 17 40手と指の設定 腕の終端エフェクタを選択した状態で、ガイドツールから[meta_01]を選択、[描画]。手のひらの骨、中手骨の根元になる部分を指定。ここでは4箇所。metacarpalとは中手骨の意。 描いたmetaのヌルのうち、人差し指にあたるものを選択し、ガイドツールから[cain_01]を選択、フロントビューから指の関節と終端エフェクタを描く。右クリックで終了。settingプロパティで名前を「Finger」に変更。チェインを描く際に左右の指定されたオブジェクトを選択していれば、自動的にNamingの左右も同じものが選択される。 トップビューにうつり指のチェインを複製してゆく。指のルートヌルを選択して、ガイドツールで[複製]を押す。複製したチェインはNamingに自動的に0~3と連番が入るようになっている。 複製した指チェインをそれぞれmetaヌルの子にする。 腕の終端エフェクタを選択して、ガイドツールから[cain_01]を選択、[描画]。親指の間接と終端エフェクタを描く。右クリックで終了。 metaと各指のルートヌルの表示を小さく。プロパティのサイズを調整。 腕のルートヌルを肩へ移動させて、親子関係を肩のルートの子から終端の子へ変更。 21 25 コンストレインメニューで「子変換コンペイセイション(ChldCom)」をONにしておけば、各ヌルの位置調整が簡単だよというデモンストレーション。
https://w.atwiki.jp/3594chugen/pages/36.html
都市隣接チェック 1BE39h~ 現在選択している都市と隣接しているかのチェックを行う 準備:M$0617に隣接元の都市ID、M$0642に隣接対象の都市ID 結果:キャリーフラグ=0(隣接あり)、1(隣接なし) BE29 AD 17 06lda$0617;都市ID取得 BE2C 0Aasla;都市ID左シフト(2倍) BE2D A8tay;レジスタyに格納(オフセットとして利用) BE2E A9 3Clda#$3C;隣接都市IDデータアドレス読み込みのためバンク切り替え準備 BE30 20 13 E6jsr$E613;バンク切り替えルーチンへジャンプ BE33 B9 40 9Alda$9A40,y;隣接対象の BE36 85 00sta$00;隣接都市IDデータアドレスを BE38 B9 41 9Alda$9A41,y;M$00とM$01に格納する BE3B 85 01sta$01; BE3D A0 00ldy#$00;レジスタyに00を格納(インデックスとして利用) BE3F B1 00lda($00),y;隣接都市IDデータから隣接都市IDを取得 BE41 C9 FFcmp#$FF;データの終端かチェック BE43 F0 09beq$BE4E;データの終端なら$BE4Eへブランチ BE45 C8iny;インデックスを BE46 C8iny;インクリメントする(yを+2) BE47 CD 42 06cmp$0642;隣接対象の都市IDと一致するかチェック BE4A D0 F3bne$BE3F;一致しなかったら$BE3Fへブランチ BE4C 18clc;一致したらキャリーフラグクリア(0)※隣接あり BE4D 60rts;ルーチン終了 --------------------------------------------------------------------------------------------------- BE4E 38sec;一致しなかったらキャリーフラグセット(1)※隣接なし BE4F 60rts;ルーチン終了 隣接都市IDデータアドレス 19A50h~ 2バイト×30都市 ・00:リョウトウ~1D:エイショウの順 ・各都市の隣接都市IDデータのアドレスが格納されている 隣接都市IDデータ 19A8C~ 可変長データ×30都市 ・00:リョウトウ~1D:エイショウの順 ・隣接する都市数が異なるため可変長データとなる 隣接都市IDデータ形式 XX・・・都市ID YY・・・未解析データ FF・・・終端データ XX YYを一組にして隣接している都市数分繰り返し最後にFF XX1 YY1 XX2 YY2 XX3 YY3 ・・・ XXn YYn FF 例) リョウトウの隣接都市IDデータ 01 01 03 00 FF 01 ユウシュウと隣接 01 未解析データ 03 セイシュウと隣接 00 未解析データ FF 終端データ
https://w.atwiki.jp/akios/pages/27.html
2. 文法 2.1. 文脈自由文法 2.2. 字句文法 Javaプログラミング言語の字句文法(lexical grammer)は3.で記述します。この文法の終端記号はUnicode文字セットの文字です。そこではUnicode文字の列を入力要素の列に変換するめの、目標記号Input(3.5.)から始まる生成規則の集合を定義しています。 この入力要素では空白とコメントは削られており、Javaプログラミング言語用の構文文法で使える終端記号の形になっています。これをトークンと呼びます。このトークンはJavaプログラミング言語の識別子やキーワード、リテラル、分離子、演算子です。 2.3. 構文文法 2.4. 文法記法
https://w.atwiki.jp/0x0b/pages/72.html
概要 このセクションは、 ECMAScript 言語の非公式な概要で構成する。 ECMAScript は、ホスト環境下での演算実行および演算的オブジェクト操作のための、オブジェクト指向プログラミング言語である。ここで述べる ECMAScript は演算的にそれ自身で十分なものを意図したものではない; 実に、外部データの入力及び演算結果の出力のためには、本仕様は何も提供しない。代わりに、 ECMAScript プログラムの演算環境は、本仕様内に述べられるオブジェクトとその他の設備の提供だけでなく、 ECMAScript プログラムからアクセス可能な個々のプロパティと呼び出し可能な個々の関数の提供してよいと示すことを除いて本仕様のスコープ上に説明と振る舞いを持つ、個々の環境指定のホストオブジェクトの提供が期待される。 スクリプティング言語は、既存のシステムの設備を操作、カスタマイズ、自動化に用いられるプログラミング言語である。そのようなシステムでは、ユーザーインターフェイスを通して既に有用な機能性が利用可能で、スクリプティング言語はプログラム制御への機能性の露出のためのメカニズムである。この方法で、既存のシステムは、スクリプティング言語の許容性を満たすオブジェクトと設備のホスト環境の提供に話す。スクリプティング言語は専門的また非専門的プログラマの両方による利用を意図している。非専門的プログラマに順応するために、言語の指針はあまり厳格ではなくてもよい。 ECMAScript は本来、ブラウザ内において Web ページを活気付け、そして Web ベースのクライアント-サーバアーキテクチャの一部としてサーバー演算を実行するメカニズムを提供する、 Web スクリプティング言語として設計された。 ECMAScript は様々なホスト環境にコアなスクリプティング機能を提供可能であり、それゆえ本仕様では、個々のホスト環境から切り離したコアなスクリプティング言語が規定される。 ECMAScript の機能には、他のプログラミング言語で使われるものに類似した部分もある; とりわけ、次に述べる JavaTM と Self である Gosling, James, Bill Joy and Guy Steele. The JavaTM Language Specification. Addison Wesley Publishing Co., 1996. Ungar, David, and Smith, Randall B. Self The Power of Simplicity. OOPSLA 87 Conference Proceedings, pp. 227-241, Orlando, FL, October 1987. Web スクリプティング (Web Scripting) ウェブブラウザは、例えばウィンドウ、メニュー、ポップアップ、ダイアログボックス、テキストエリア、アンカー、フレーム、履歴、クッキー、入出力を表すオブジェクトを含む、クライアントサイド演算のためのホスト環境を提供する。さらにホスト環境は、フォーカス、ページと画像の読み込み、遷移、エラー及び中止、選択、フォーム送信、マウス行動の変更のようなイベントにスクリプティングコードを取り付ける手段を提供する。スクリプティングコードは HTML 内に出現し、そして表示されたページは、ユーザーインターフェイス要素と固定され演算されたテキストと画像の結合体になる。スクリプティングコードはユーザの相互作用にすぐ反応し、メインプログラムには必要ない。 ウェブサーバはサーバサイド演算のための異なるホスト環境を提供し、リクエスト、クライアント、ファイルを表すオブジェクトと、ロックとデータ共有のメカニズムを含む。ブラウザサイド、サーバサイドのスクリプティングを共に使用することで、Web ベースアプリケーションにカスタマイズされたユーザーインターフェイスを提供すると同時に、クライアントとサーバ間の演算の分配を可能にする。 ECMAScript をサポートする Web ブラウザ及びサーバはそれぞれ、 ECMAScript 実行環境を完成する自分自身のホスト環境を提供する。 言語の概要 (Language Overview) 下記は ECMAScript の非公式な概要である -- 言語のすべての部分が記述されるわけではない。この概要は厳密には標準の一部ではない。 ECMAScript はオブジェクトベースである 基礎的な言語およびホスト設備はオブジェクトによって提供される。また、 ECMAScript プログラムは、通信するオブジェクトの群である。 ECMAScript オブジェクト は、序列のない プロパティ の集合体で、それぞれのプロパティが、その利用されうる方法を決定する 0 個以上の 属性 を持つ -- 例えば、プロパティの ReadOnly 属性が true にセットされるときは、そのプロパティの値を変更しようとする、実行される ECMAScript コードによるどんな試行も効果を持たない。プロパティは、他のオブジェクトや プリミティブ値 、メソッド を保持するコンテナである。プリミティブな値は、次の組み込み 型 Undefined, Null, Boolean, Number, String の内のひとつの仲間である; オブジェクトは残りの組み込み 型 Object の仲間である; メソッドはプロパティ経由でオブジェクトに関連づけられた関数\である。 ECMAScript は 組み込みオブジェクト (built-in object) の集合を定義し、これは ECMAScript 実体の定義を完成する。これらの組み込みオブジェクトは、Global オブジェクト、 Object オブジェクト、 Function オブジェクト、 Array オブジェクト、 String オブジェクト Boolean オブジェクト、 Number オブジェクト、 Math オブジェクト、 Date オブジェクト、 RegExp オブジェクト、そして Error オブジェクト、Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError を含む。 ECMAScript は組み込みの演算子のセットも定義し、厳密には、それらは関数やメソッドではないかもしれない。ECMAScript 演算子は、さまざまな単項演算(unary operations), 乗除演算子(multiplicative operators), 加減演算子(additive operators), ビットシフト演算子(bitwise shift operators), 関係演算子(relational operators), 等価演算子(equality operators), ビット演算子(binary bitwise operators), 論理演算子(binary logical operators), 代入演算子(assignment operators), カンマ演算子(comma operator) を含む。 ECMAScript 構文は、意図的に Java 構文と似ている。 ECMAScript 構文は緩やかで、容易に利用できるスクリプティング言語としての提供を可能にしている。例えば、変数に型宣言は要求されず、プロパティに関連する型も要求されず、定義される関数は、テキスト的にそれが呼び出される前に宣言を出現させることを要求されない。 オブジェクト (Objects) ECMAScript は、C++、Smalltalk あるいは Java のような厳密なクラスを持たない。だが、コードの実行によりオブジェクトを生成するコンストラクタをサポートし、このコードはオブジェクトに記憶領域を確保し、オブジェクトの全て又は一部をプロパティへの初期値代入によって初期化する。コンストラクタは全てオブジェクトであるが、しかし、すべてのオブジェクトがコンストラクタということではない。コンストラクタはそれぞれ prototype プロパティを持ち、プロトタイプベースの継承および共有プロパティの実装に使用される。オブジェクトは new 式中でのコンストラクタ使用により生成される; 例えば、new String("A String") は新しい String オブジェクトを生成する。 new を使用しないコンストラクタの呼出しの結果は、コンストラクタに依存する。例えば、 String("A String") は、オブジェクトではなくプリミティブな文字列を生成する。 ECMAScript はプロトタイプベースの継承をサポートする。コンストラクタは皆関連づけられたプロトタイプを持ち、また、そのコンストラクタに作成されたオブジェクトは皆、そのコンストラクタに関連づけられたプロトタイプ (オブジェクトのプロトタイプと呼ばれる) に暗黙の参照がある。プロトタイプは、更にそのプロトタイプに null 以外の暗黙の参照があるかもしれない(以下同様である); これはプロトタイプチェーン (prototype chain) と呼ばれる。オブジェクトのプロパティへが参照される場合、その参照は、プロトタイプチェーン中でその名前のプロパティを持つ最初のオブジェクトのプロパティへの参照である。言いかえれば、まず直接指定されたオブジェクトが、そのプロパティの有無を検査される; そのオブジェクトが指定されたプロパティを持つ場合、それが参照するプロパティである; そのオブジェクトが指定のプロパティを持たない場合、そのオブジェクトのプロトタイプが次に検査される; 以下同様に続く。 クラスベースのオブジェクト指向の言語では、一般に、状態(state) がインスタンスによって運ばれ、メソッドはクラスによって運ばれ、継承は構造(strucutuer) と振る舞い(behaviour) にのみ存在する。ECMAScriptでは、状態およびメソッドがオブジェクトによって運ばれ、構造、振る舞い、状態がすべて継承される。 プロトタイプが持つプロパティを直に持たないオブジェクトはすべて、プロパティとその値を共有する。次の図がこれを例示する CF はコンストラクタである(オブジェクトでもある)。5 つのオブジェクト cf1, cf2, cf3, cf4, cf5 が new 式の使用により作成されている。これらのオブジェクトの各々は、q1 と q2 というプロパティを持つ。破線は暗黙のプロトタイプ関係を表わす; したがって、例えば、cf3 のプロトタイプは CFp である。コンストラクタ(CF) は、それ自身で P1 および P2 と名づけられた 2 つのプロパティを持つ(それは、CFp, cf1, cf2, cf3, cf4, cf5 からは見えない)。CFp の CFP1 というプロパティは、 CFp の暗黙のプロトタイプチェーン上で見つかる q1, q2, CFP1 という名でない任意のプロパティであり、cf1, cf2, cf3, cf4, cf5 に共有される( CF に共有されるのではない)。暗黙のプロトタイプ・リンクが CF と CFp の間にないことに注目しなさい。 クラスベースのオブジェクト言語と異なり、プロパティは値の代入によって、オブジェクトに動的に追加できる。すなわち、コンストラクタは、構築されるオブジェクトの全てまたは任意のプロパティの命名や値の代入を要求されない。上図では、CFp 内でプロパティに新たな値を代入することで、cf1, cf2, cf3, cf4, cf5 に新しい共有プロパティを追加できる。 定義 (Definitions) 次は ECMAScript に関連する鍵となる術語の非公式な定義である。 [訳注 この仕様では "instance" という語が散見するが、 ECMAScript はプロトタイプベース言語であり、この語はクラスベース言語における "instance" のような技術的意味を持たない。現に仕様内にこの語に関する定義は公式非公式含めて見つからず、日常語としての「実例、実体、具体的なもの」としての意味合いで用いられているとも考えられる。] 型 型 (type) とはデータ値の集合である。 プリミティブ値 プリミティブ値 (primitive value) は Undefined, Null, Boolean, Number, String 型のうちの一つの構成要素である。プリミティブ値は言語実装の最低レベルにおいて直接表されるデータである。 オブジェクト オブジェクトは Object 型の構成要素である。序列のないプロパティの集合体で、それぞれのプロパティがプリミティブ値やオブジェクト、関数を含む。オブジェクトのプロパティに格納された関数はメソッドと呼ばれる。 コンストラクタ コンストラクタとは、オブジェクトを生成し初期化する Function オブジェクトのことである。各コンストラクタは関連する prototype オブジェクトを持ち、継承と共有プロパティの実装に用いられる。 プロトタイプ プロトタイプはオブジェクトであり、ECMAScript 中では、構造(structure), 状態(state), 振る舞い(behaviour) の継承に用いられる。コンストラクタがオブジェクトを生成するとき、プロパティの参照を解決する目的で、そのオブジェクトは暗黙にコンストラクタに関連するプロトタイプを参照する。コンストラクタに関連するプロトタイプはプログラム式 constructor.prototype で参照され、オブジェクトのプロトタイプに追加されたプロパティは、継承を通して、そのプロトタイプを共有する全オブジェクトによって共有される。 ネイティブオブジェクト Native オブジェクトは、 ECMAScript 実装によって提供される任意のオブジェクトで、ホスト環境に依存しない。標準 Native オブジェクトは本仕様中で定義される。Native オブジェクトの一部は Built-in(組み込み) である。他のものは ECMAScript プログラムの実行行程の間に構築されるだろう。 組み込みオブジェクト Built-in オブジェクトは ECMAScript 実装によって提供される任意のオブジェクトであり、ECMAScript プログラムの実行の開始時に存在するホスト環境に依存しない。標準 Built-in オブジェクトは本仕様中に定義され、ECMAScript 実装は他を定義してもよい。全 Built-in オブジェクトは Native オブジェクトである。 ホストオブジェクト Host オブジェクトは ECMAScript の実行環境を満たすためにホスト環境によって提供される任意のオブジェクトである。Native でない任意のオブジェクトは Host オブジェクトである。 undefined 値 undefined 値は、プリミティブ値であり、変数に値が代入されていないときに用いられる。 Undefined 型 Undefined 型は、厳密には undefined と呼ばれるひとつの値を取る。 null 値 null 値は、プリミティブな値であり、ヌル、空(empty)、存在しない参照を表す。 Null 型 Null 型は、厳密には null と呼ばれるひとつの値を取る。 真偽値 真偽値は Boolean 型の元 (member 集合を構成するもの) で、一意的な二つの値、 true と false の一方である。 Boolean 型 Boolean 型は論理的実体を表し、厳密には二つの一意的な値で構成される。一方は true と呼ばれ、他方は false と呼ばれる。 Boolean オブジェクト Boolean オブジェクトは Object 型の元で、組込み Boolean オブジェクトのインスタンスである。つまり、 Boolean オブジェクトは、 new 式内で引数にブーリアンを渡した Boolean コンストラクタを用いて作成される。結果のオブジェクトはブーリアンである暗黙の(無名の)プロパティを持つ。 Boolean オブジェクトはブーリアン値に強制される。 文字列値 文字列値は String 型の元で、0 以上の 16 ビット符号なし整数値による有限の順序あるシーケンスである。 NOTE 各値は通常単一の UTF-16 テキストの 16 ビット単位をあらわすが、言語はそれらが 16 ビット符号なし整数であること以外の制限また要求を値上に設置しない。 String 型 String 型はすべての文字列値の集合である。 String オブジェクト String オブジェクトは Object 型の元で、組込み String オブジェクトのインスタンスである。つまり、String オブジェクトは new 式内で引数として文字列を供給する String コンストラクタを用いて生成される。結果のオブジェクトは文字列である暗黙の(無名の)プロパティを持つ。 String コンストラクタの関数としての呼び出しにより、 String オブジェクトは文字列値に強制される。 数値 数値は Number 型の元で、数を直接表現する。 Number 型 Number 型は数を表す値の集合である。 ECMAScript において、値の集合は、特殊な "Not-a-Number" (NaN) 値、正の無限大、負の無限大を含めた倍精度64ビット形式 IEEE 754 値である。 Number オブジェクト Number オブジェクトは Object 型の元で、組込み Number オブジェクトのインスタンスである。つまり、 Number オブジェクトは new 式において Number コンストラクタに引数として数を渡して生成される。結果のオブジェクトは数字である暗黙の (無名の) プロパティを持つ。 Number オブジェクトは関数としての Number コンストラクタ呼び出し (関数として呼ばれる Number コンストラクタ) によって数値に矯正できる。 Infinity プリミティブ値 Infinity は正の無限大をあらわす。この値は Number 型の元である。 NaN プリミティブ値 NaN は、 IEEE 標準 "Not-a-Number" 値のセットあらわす。この値は Number 型の元である。 表記法について 構文と字句の文法 このセクションでは、この仕様で ECMAScript プログラムの字句構文構造の定義に用いられる文脈自由文法 (context-free grammers) について述べる。 文脈自由文法 (Context-Free Grammars) 文脈自由文法はたくさんの生成規則 (production) によって構成される。各生成規則はその左辺に非終端記号 (nonterminal symbol) と呼ばれる抽象的記号を持ち、右辺に 0 個以上の非終端記号と終端記号 (terminal symbol) の並びを持つ。各文法のために、終端記号は特定のアルファベットか引き出される。 目標記号 (goal symbol) と呼ばれる、単一の識別される非終端記号で構成される文から始まり、与えられる文脈自由文法は言語を規定する。すなわち、終端記号の可能なシーケンスの (おそらく無限の) 集合で、それはシーケンス内で非終端記号を、非終端記号が左辺である生成規則の右辺で繰り返し置換することから生じる。 字句と正規表現の文法 ECMAScript の字句文法は(字句について)に与えられる。この文法は終端記号として Unicode 文字セットの文字をもつ。目標記号 InputElementDiv や InputElementRegExp から始まる生成規則のセットを定義し、これは Unicode 文字のシーケンスが入力要素のシーケンス内にどのように翻訳されるかを説明する。 空白類及びコメント以外の入力要素は、 ECMAScript トークン (ECMAScript tokens) と呼ばれ、 ECMAScript の構文的文法に終端記号を形成する。これらのトークンは ECMAScript 言語の予約語、識別子、リテラルおよび接続子である。さらに、行終端子 (line terminator) はトークンだと考えられてはいないが、入力要素のストリームの一部になり、自動セミコロン挿入 (字句について 自動セミコロン挿入) のプロセスをガイドする。 単純な空白類および一行のコメントは、廃棄されて構文的な文法用の入力要素のストリームに出現しない。MultiLineComment (1 行を超えるか範囲かどうか関係ない "/*…*/" 形式のコメント) が行終端子を含まない場合、同様に単に廃棄される; しかし、MultiLineComment が 1 つ以上の行終端子を含んでいる場合、それは 1 つの行終端子と置換され、それは構文的な文法用の入力要素のストリームの一部になる。 ECMAScript のための RegExp 文法は(RegExp (正規表現) オブジェクト)に与えられる。この文法は、さらにその終端記号として Unicode 文字セットの文字を持つ。それは 1 セットの生成規則を定義し、目標記号パターンから開始して、 Unicode 文字のシーケンスが正規表現パターンにどのように翻訳されるか説明する。 字句と RegExp 文法の生成規則は、区切り分離として 2 つのコロン " " を持つことで識別される。字句と RegExp 文法はいくつかの生成規則を共有する。 数値文字の文法 第二の文法は文字列をを数値の値に変換するのに使用される。この文法は、数値リテラルと関係する字句の文法の一部に似ていて、その終端記号として Unicode 文字集合の文字を持つ。この文法は(型変換 String 型に適用される ToNumber )に出現する。 数値的文字文法の生成規則は、接続子として 3 つのコロン " " を用いて区別される。 構文的文法 ECMAScript のための構文的文法は、(式), (文), (関数定義), (プログラム) の中で与えられる。この文法は ECMAScript トークンを持ち、字句文法によってその終端記号 (記述法について 字句と正規表現の文法) として定義される。それは生成規則の一集合を定義し、目標記号 Program から開始し、トークンのシーケンスがどのように構文上正しい ECMAScript プログラムを形成できるか説明する。 Unicode 文字のストリームが ECMAScript プログラムとして解析されることになっている場合、それは字句文法の繰り返された適用によって、最初に入力要素のストリームに変換される; この入力要素のストリームはその後、構文文法の単一のアプリケーションによって解析される。残ったトークンのない、ゴール非終端記号Program の単一の実例として入力要素のストリームのトークンを解析できない場合、プログラムは構文上誤っている。 構文的文法の生成規則は、接続子として 1 つのコロン " " を用いて区別される。 (式), (文), (関数定義), (プログラム)の中で示される構文的文法は、トークンシーケンスが正しい ECMAScript プログラムとして認められる、現実に完全な説明ではない。疑う余地のない追加トークンシーケンス、すなわち、文法によって記述され、セミコロンだけが (行終端子文字の前のような) 確実な場所内のシーケンスに加えられた場合も受理される。更に、終端子文字が確実に "不適当な" 場所に現われる場合、文法によって記述されるあるトークンシーケンスは、受理可能であるとは考えられない。 文法記法 (Grammar Notation) 字句と文字列の文法の終端記号といくつかの構文文法の終端記号は、文法の生成規則内及びこの仕様を通して、テキストがそのような終端記号を直接参照するときは 等幅フォントであらわされる。これらはプログラム中に書かれるものとして出現する。この方法で指定される非終端記号の文字は全て、 ASCII の範囲から 適当な Unicode 文字として理解されるものであり、他の Unicode 範囲の類似した文字ではない。 非終端記号は イタリック体 であらわされる。非終端記号の定義は、一つ以上のコロンの続く定義されている非終端記号の名前によって案内される。(コロンの数は生成規則がどの文法に属するかを示す。) 非終端記号の一つ以上の代替の右辺は後続行に続く。 [訳注 この HTML 版邦訳でのフォントはこの限りではないかもしれない。] 例えば、次の構文定義 WithStatement with ( Expression ) Statement は、非終端記号 WithStatement がトークン with 、左括弧トークン、 Expression 、右括弧トークン、 Statement の続きをあらわすことを明言する。 Expression 及び Statement の出現はそれ自身非終端である。別な例として、次の構文定義 ArgumentList AssignmentExpression ArgumentList , AssignmentExpression は、 ArgumentList が単一の AssignmentExpression 、または ArgumentList 、カンマ、 AssignmentExpression の続きのどちらかをあらわすかもしれないことを明言する。この ArgumentList の定義は再帰的で、つまり、自分自身の表現の中で定義される。結果として、 ArgumentList はカンマで区切られた任意の正数の引数で構成されうる。その各引数式のところは AssignmentExpression である。非終端記号のそのような再帰的定義が一般的である。 下付き文字による後置句 "opt" は、終端記号または非終端記号の後に出現でき、選択的記号を示す。代替構成の選択的記号は実際は 2 つの右辺を規定する。1 つは選択的要素を省いたもの、1 つは含めたものである。これはつまり VariableDeclaration Identifier Initialiseropt は次の略記であるということだ VariableDeclaration Identifier Identifier Initialiser そして IterationStatement for ( ExpressionNoInopt ; Expressionopt ; Expressionopt ) Statement は次の略記であり IterationStatement for ( ; Expressionopt ; Expressionopt ) Statement for ( ExpressionNoIn ; Expressionopt ; Expressionopt ) Statement 順に次の略記ということになり IterationStatement for ( ; ; Expressionopt ) Statement for ( ; Expression ; Expressionopt ) Statement for ( ExpressionNoIn ; ; Expressionopt ) Statement for ( ExpressionNoIn ; Expression ; Expressionopt ) Statement 順に次の略記ということになる IterationStatement for ( ; ; ) Statement for ( ; ; Expression ) Statement for ( ; Expression ; ) Statement for ( ; Expression ; Expression ) Statement for ( ExpressionNoIn ; ; ) Statement for ( ExpressionNoIn ; ; Expression ) Statement for ( ExpressionNoIn ; Expression ; ) Statement for ( ExpressionNoIn ; Expression ; Expression ) Statement 従って非終端記号 IterationStatement は、実際には 8 個の代替右辺を持つ。 フレーズ "[empty]" が生成規則の右辺に出現するならば、それは生成規則の右辺が終端記号も非終端記号も含まないことを示す。 フレーズ "[lookahead ∉ set]" が生成規則の右辺に出現する場合は、直後の入力終端記号が与えられた set の元ならば、生成規則が使われないことを示す。 set は { } 内に囲まれた終端記号のリストとして書くことが出来る。簡潔に言えば、 set は非終端記号として書くことも出来る。その場合、非終端記号から展開可能な終端記号の全てをあらわす。例えば、定義 DecimalDigit one of 0 1 2 3 4 5 6 7 8 9 DecimalDigits DecimalDigit DecimalDigits DecimalDigit を与えられて、定義 LookaheadExample n [lookahead ∉ {1, 3, 5, 7, 9} ] DecimalDigits DecimalDigit [lookahead ∉ DecimalDigit ] は、偶数で始まる一つ以上の数字が続く文字 n 、あるいは他の数字が続かない数字にマッチする。 フレーズ "[no LineTerminator here]" 構文的文法の生成規則の右辺に出現する場合、生成規則が 制限生成規則 (restricted production) であることを示す 入力ストリームの示された位置に LineTerminator が出現しなければ使用できない。例えば、次の生成規則 ReturnStatement return [LineTerminator 無し] Expressionopt ; プログラム内の return トークンと Expression の間に LineTerminator が出現する場合はこの生成規則は使用できない。 LineTerminator の存在が制限生成規則に隠されなければ、入力要素のストリーム内の 2 つの連続するトークン間に LineTerminator はいくつでも出現でき、プログラムの構文的受容性に影響を与えない。 文法定義内のコロンに語句 "one of" が続く場合、後続行の終端記号のそれぞれが代替定義であることを意味する。例えば、ECMAScript の字句文法は次の生成規則を含む NonZeroDigit one of 1 2 3 4 5 6 7 8 9 これは単に次の略記である NonZeroDigit one of 1 2 3 4 5 6 7 8 9 字句文法また数値文字文法の生成規則内の代替が複数文字トークンである場合、そのトークンを作る文字シーケンスをあらわす。 生成規則の右辺は、フレーズ "but not" を用いてある展開が許可されないことを規定してよく、その展開は除外される。例えば、次の生成規則 Identifier IdentifierName but not ReservedWord は、非終端記号 Identifier が IdentifierName に置換可能だが ReservedWord で置換不可能な文字シーケンスであることを意味する。 最後に、全ての代替をすべてあげるのが現実的でないいくつかの非終端記号が、ローマン体の説明的フレーズで記述される SourceCharacter any Unicode character アルゴリズム記述について 仕様はしばしば番号を振ったリストを用いて、アルゴリズム内のステップを規定する。これらのアルゴリズムは意味論を明確にするために用いられる。実際には、与えられる機能の実装に有効な、より能率的なアルゴリズムであってよい。 アルゴリズムが結果として値を生成するとき "x を返す" が用いられ、アルゴリズムの結果が x の値であり、アルゴリズムが終了すべきであることを示す。表記 Result(n) は "ステップ n の結果" の略記である。Type(x) は "x の型" の略記である。 本セクションで後に述べる加法、減法、否定、乗法、除法、数学的関数のような数学的操作は、常に、無限及び正の 0 から区別される負の 0 を含まない数学的な実数上の厳密な数学的結果を演算するものとして理解されるべきである。浮動小数点数計算を作るこの標準のアルゴリズムは、必要に応じて、無限と符号付きの 0 を操作し丸めの実行する、明示的なステップを含む。数学的操作または関数が浮動小数点数に適用される場合、その浮動小数点数\であらわされる厳密な数学的値に適用されるものとして理解されるべきである; そのような浮動小数点数は有限であるべきで、そして +0 または -0 ならば該当する数学的値は単に 0 である。 数学関数 abs(x) は x の絶対値をもたらし、 x が負(0 未満) なら -x 、そうでなければ x 自身である。 数学関数 sign(x) は、 x が正ならば 1、 x が負ならば -1 をもたらす。 x が 0 のときのための sign 関数はこの標準では用いられない。 記法 "x modulo y" (y は 0 以外の有限数) は、ある整数 q について abs(k) abs(y) かつ x - k = q * y であるような、 y (又は 0) と同じ符号の値 k を算出する。 数学関数 floor(x) は x より大きくない最大の整数 (正の無限に接近する) をもたらす。 NOTE floor(x) = x - (x modulo 1). アルゴリズムが "例外を投げる" と定義されていれば、アルゴリズムの実行は終了し、結果を何も返さない。アルゴリズム呼出しも終了し、 "例外が投げられたら…" のような用語を用いて、アルゴリズムのステップが明示的に例外を扱うに至る。一度そのようなアルゴリズムのステップに遭遇したらそれ以上例外の発生は考慮されない。
https://w.atwiki.jp/yokkun/pages/133.html
4.空気抵抗 Phun空間には規定値で空気が存在する。Options-Simulation-Air friction strength[オプション-シミュレーション-空気とのまさつ]から抵抗の大きさを設定することができる。また,空気の密度は0.010kg/であり,重力下で物体の密度をこれより小さくすると浮かび上がっていく。 規定値(Air friction strength[空気とのまさつ]=1.00)での空気抵抗の影響を見てみよう。 大きさや質量の異なる円で空気中の落下をシミュレートして,終端速度を調べてみたところ,われわれの3次元空間と異なりPhun空間では空気抵抗はもっぱら速さに比例しているように見える。 推定される落下の運動方程式は, となった。は円の質量,は重力加速度,は空気の密度,は円の面積,は落下の速さである。すなわち右辺第2項は浮力である。また,抵抗係数は 前後になっているようである。ただし,条件によって多少の幅が生じるのは積分による誤差の蓄積によるものであると思われる。なお,この値はAir friction strength[空気とのまさつ] の値に比例して増減設定が可能になっている。 として終端速度の理論値はm/s。画面はそれに一致する終端速度を表示している。なお,このシミュレーションをするためには,設計画面で既設されているはるか下方のKiller[キラー]設定(接触した物体を消去する)された黒い水平面を消しておく必要がある。 空気がある場合とない場合の投射体の軌跡。
https://w.atwiki.jp/tanosiiorika/pages/3267.html
究極終了証明―コード・F(フェルマー)― 水 コスト8 呪文 ■自分のデッキを見る。その後好きな順番でカードを置く。 ■カードを10枚まで引いても良い。 ■終端(自分はこのゲーム中、もう呪文を唱えることができない。) (F)証明の先に何があるか私は到達することができた。しかしそれをここに記すには余白が足りない。――サファイア・ウィズダムによる伝記、最終ページの走り書き 作者:あるふぁ 終端のテスト。強いのかどうなのか・・・ 名前 コメント -
https://w.atwiki.jp/nofx/pages/19.html
有限オートマトン 1.有限個の状態の集合 K2.有限個の入力アルファベット Σ3.遷移の集合δ+開始記号 S(S∈K)4.最終状態の集合 F(F⊆K)有限オートマトン M=(K,Σ,δ,S,F) 形式文法 1.非終端記号の集合 N2.終端記号の集合 Σ3.生成規則(書き換え規則) P4.開始記号 S形式文法 G=(N,Σ,P,S) 正則文法(正規文法)(regular grammer RG) 形式文法 G=(N,Σ,P,S)のうち生成規則Pが次の形になっているもの。●A→aB もしくは●A→a開始記号Sについては●S→εただし、 A,B∈N, a∈Σ正則文法は3型文法とも呼ばれる。 文脈自由文法(context-free grammer CFG) 形式文法 G=(N,Σ,P,S)のうち生成規則Pが次の形になっているもの。●A→α ( A∈N, α∈(Σ∪N)* )文脈自由文法は2型文法とも呼ばれる。プログラミング言語は文脈自由文法で生成できる。→ ある条件を満たす文脈自由文法 : LL(1)文法 チョムスキー標準形(Chomsky normal form CNF) 形式文法 G=(N,Σ,P,S)のうち生成規則Pが次の形になっているもの。1.A→BC ( A,B,C ∈ N )2.A→a ( a∈Σ )3.S→ε グライバッハ標準形(Greibach normal form GNF) 形式文法 G=(N,Σ,P,S)のうち生成規則Pが次の形になっているもの。1.A→aB1B2…Bm ( a∈Σ、 B1,B2,…,Bm ∈ N )2.A→a ( a∈Σ )3.S→ε s文法 1.生成規則の右辺は終端記号で始まる2.生成規則の左辺が同じなら右辺は異なる終端記号で始まる LL(1)文法
https://w.atwiki.jp/swfspec/pages/18.html
文字列の値 文字列の値は、終端 null の文字の連なりで表現されます。 STRING 型 フィールド 型 コメント String UI8[0 以上] null でない文字データ StringEnd UI8 文字列の終端記号。常にゼロ SWF 5 以前のものでは、 STRING の値は ANSI (ASCII のスーパーセット) か shift-JIS (日本語のエンコーディング方式) のうちいずれかでエンコードされていて、エンコーディング方式がどちらになっているか指し示すことができないため、Flash Player の実行環境のロケールにより決定されていました。 これは、 SWF 5 以前のコンテンツが ANSI か shift-JIS のどちらかでしかテキストのエンコードができないことを意味し、ターゲットとなるユーザ層をオーサリング環境と合わせる必要がありました。 SWF 6 以降では、常に Unicode の UTF-8 標準に合わせて STRING の値がエンコードされるようになりました。 これはマルチバイトのエンコーディング方式で、1 文字が 1 ~ 4 バイトの間に収まります。 UTF-8 は ASCII のスーパーセットで、 UTF-8 の 0 ~ 127 の値の範囲は、 ASCII のマッピングと同一の内容になります。 UTF-8 では 1 文字が複数バイトで構成される場合でも、中に 0 (null キャラクタ) が含まれないことを保障します。 これは、文字列中に null が出現することを避け、 ASCII 文字列のように null が正しく文字列の終端を指すことを意味します。 移動 前のページ ビット値 次のページ 言語コード