問題タブ [bottom-up]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
parsing - 解析テーブルのサイズ (ボトムアップ)
(同じ言語の) あいまいな文法と明確な文法のために構築された解析テーブルのサイズの比較を見てきました。ambiguous 用に作成されたものは、大幅に小さくなっています。使用したパーサーは SLR(1) でした。
あいまいな文法を表す (ボトムアップ パーサーの) 解析テーブルのサイズは、対応する明確な文法の解析テーブルよりも常に小さいというのは常に本当ですか? 明らかに、競合が正しく解決されていると仮定します。
私はいくつかの調査を行いましたが、この質問に対する証拠や答えを見つけることができません。
parsing - ボトムアップ解析を使用して、指定された入力に対して生成された出力
この質問を解いてみましたが、答えはオプション c でした。しかし、与えられた答えがオプション b である教科書はほとんどありません。私は混乱していますが、正しい答えは何ですか？助けてください
！
parsing - LR-Parsing-Table: 削減アクションの次の状態を決定するものは?
LR-Parsing テーブルの生成について私が知っている (読む) 限りでは、reduce アクションが特定の状態のセルに書き込まれる列 (= トークン)は、FOLLOW セットにあるターミナルに依存するということです。縮小シンボルの。
あれは正しいですか？*
もしそうなら、私の頭に浮かぶ次の質問は、次の状態を決定するのは何かということです.還元後に遷移を起こすのは何ですか.
たとえば、状態 5 では、r6 はシンボルを削減してから状態 6 に遷移することを意味します (さらに遷移する状態への goto-table を考慮する場合があります)。
解析テーブルまたは DFA (LR-Parser である) の状態は、グラフ表現のパスです。ボトムアップ パーサーとして、LR パーサーは、開始シンボル/受け入れ状態に戻るパスを見つけることによって機能します。解析テーブルは、そのようなすべてのパスを見つけようとします。
そして、結果として正しい還元状態を選択することは、私には複雑に思えます。
それは、現在の状態に先行する状態/アイテムセットと、まだ読み取られていない入力トークンに応じて現在の状態に完全に続く状態に密接に依存するためです。
reduce アクションに比べれば、shift アクションや goto アクションは、ドット位置を移動するときに現れる遷移にすぎないため、簡単に見えます。
ありがとう
PS: *それが正しければ、追加機能として FOLLOW-Set を使用して LR1Items を生成するのは「二重のトラブル」ではありませんか?
swift - Swift でフィボナッチ関数を実装するためにボトムアップ アプローチを試行するとランタイム エラーが発生しますか?
Swift 5 でフィボナッチ関数を実装しようとしています。Xcode Playground で関数を実装しているときに ( CSDojo の YouTube ビデオから関数のコードを取得しました)、このエラー メッセージが表示されました。
エラー: 実行が中断されました。理由: EXC_BAD_INSTRUCTION (コード=EXC_I386_INVOP、サブコード=0x0)
最初は、エラーは添え字のインデックスが範囲外であるに違いないと思っていました。そのため、コードを再度確認しましたが、問題はないようです。Xcode Playground を実行しようとすると、なぜこのエラー メッセージが表示されるのでしょうcomputeFiboBottomUp(n: 100)か。まで正常に動作しますcomputeFiboBottomUp(n:35)。
コンパイラが処理するには、スタックに再帰呼び出しが多すぎるためですか? または、コードにエラーが含まれている可能性がありますか?