体系的なプログラミング入門 – 第 3 週

Introduction to Systematic Program Designの3週目は、以前よりも間違いなくビデオコンテンツが多かったのですが、すでに4週目からビデオを見始めているので、これからはさらにクレイジーになると言っても過言ではありません。

そこで、クラスの第3週は主にデータの設計方法の学習に焦点を当て、学んだ各レッスンをできる限り段階的に説明します。興味深いことに、これらの要約を書くことは私自身の学習にも役立つことに気付いたので、それらを読むことで、私のクラスメートである皆さんにも同様の効果が得られることを願っています。

レッスン 1: cond 式

このレッスンでは、データの設計がプログラムの設計におけるレバレッジのポイントであることをクラスに明らかにしました。これは、私たちがそれぞれデータを設計するとき、後でそのデータに対して動作するすべての関数がどのように動作するかについて、意識的または無意識的に決定を下しているからです。

条件式、またはcond式を使用すると、2つ以上のケースがある場合に条件付き動作をプログラムできます。これにより、cond 式を「マルチアーム条件」と見なすことができます。

標準の cond 式テンプレート:

cond QA 式を作成するには、次のようにします。

ここで、式 1 は質問で、式 2 は回答です。

cond 式テンプレートを使用して cond の例を作成する:

コンドを評価するためのルールは次のとおりです。

1. No Question/Answer pair? Signal an error.
2. 最初の質問が値でない場合は、それを評価し、その値に置き換えます。cond 全体を新しい cond に置き換え、最初の質問をその値に置き換えます。
3. 最初の質問が true と評価されるブール値であるか、else と評価されるステートメントである場合は、cond 全体を最初の回答に置き換えます。
4. 最初の質問が false の場合は、最初の質問/回答のペアを削除し、最初の質問/回答のペアを持たない新しい条件に置き換えます。
5. 1^番目の質問は真か偽かではないので、エラーを知らせます。

このレッスンの追加メモ:

[]は視覚的な規則です – Dr. Racket は () と [] を同じ方法で処理しますが、[]を使用すると圧倒されることはありません。

レッスン 2: データ定義

このレッスンではまず、データ定義が設計要素であることを説明します。どのプログラムにも、データだけでなく問題のあるドメインも存在します。問題ドメイン内に格納されている情報を取得し、それをデータで表現するのはデータの領域です。基本的に、データ定義は、プログラム内で情報をデータとして表現する方法を記述します。このレッスンのビデオを見ていたとき、Excel で作成するカラー キー、つまり記号または色を取得し、それがユーザー (この場合はコンピューター) にとって何を意味するかを定義して、デザイナー (私) が何を意味するかを解釈できるようにすることを思い出しました。

Dr. Racket データ定義の例を次に示します。

Lesson 3: Atomic Non-Distinct Data Definitions

このレッスンでは、都市の名前を表すデータ定義を設計することを前提として、データ定義が実際にどのように機能するかの直接的な例を提供しました。

覚えておくべきポイント:

1. データ定義の部分は、レシピ・リストにあります
2. データ定義にはさまざまな種類があります
3. アトミックとは、分解して問題情報の範囲内で意味を保持できないことを意味します。

アトミック非個別のデータ定義の例:

;; CityName is String
;; interp the name of a city
(define CN1 “Boston”)
(define CN2 “Vancouver”)

データ ドリブン テンプレートについては、次のレッスンで説明しましたが、この同じ例で、次のように続けます。

レッスン 4: データ定義を使用した HtDF

このレッスンの目的は、非プリミティブ データを使用する関数を設計する方法を教えることでした。

このレッスンから、私が集めた簡単なヒントがいくつかあったので、皆さんと共有したいと思います。

1. ブール式の場合、述語は ?
2. データ定義を使用して設計する場合は、例をガイドラインとして使用します。
3. 関数に 2 つのケースがある場合は、テンプレートの周囲に if ステートメントをラップしてテンプレートを具体化します
4. (最も重要なことは!!)コードを開始するときは、スタブをコメントアウトすることを忘れないでください。

レッスン 5: HtDF X データ直交性の構造

まず第一に、このレッスンのタイトルを見たとき、それが何について書かれているのか全くわかりませんでした - 私はかなりまともな英語の語彙を誇りに思っていますが、直交性は私にとってまったく新しい用語でした。同じ船に乗っている人のために説明させてください:直交は単に「ほとんど独立している」という意味です。この場合、HtDFメソッドは、処理しているデータ型が直交しているという前提で構成されているため、より多くの種類のデータを学習するにつれて、以前に記述した関数にエラーなしで実装できるため、重要です。私はこの理論をテストしていませんが、ここで提供された教訓に基づいて理解しているのはそれです。

このレッスンの残りの部分は、このデータ型チャートの説明に基づいていましたが、これは実際にはかなりきちんとしていると思います。

このグラフは基本的に、さまざまなデータ型をすべて説明し、間隔、列挙、および項目化について説明する今後のレッスンに備えます。

レッスン 6: 間隔データの定義

間隔データ定義は、表す数値が一定の範囲内にある場合に使用されます。これを適切に表現するための鍵は、包括性と排他性のニュアンスです。例えば：

[1, 7] は包括的であり、区間に含まれる数字は 1、2、3、4、5、6、7 であることを意味します。

[1, 7)は排他的であり、この間隔に含まれる数値は1、2、3、4、5、6であることを意味します。

cond 式とは対照的に、間隔データ定義の場合、[] と () は異なる結果を生成します。

さらに、間隔データ定義を使用する場合は、次の 2 つのルールを利用することが重要です。

1. データ チャートを使用して、最適なレシピを見つけてください。最も具体的なものを選びましょう。
2. [データ定義テンプレート] ページを使用してテンプレートを検索します。

レッスン 7: 列挙データの定義

列挙は、2 つ以上の異なる値の固定数のドメイン情報を持つ関数/プログラムを作成するときに使用されます。より現実的な例では、私はそれらを好むので、成績の追跡の違いを文字値またはパーセンテージとして考えてください。文字値は、文字値が少なく、正確に定義されているという点で、表現がはるかに簡単です。ただし、パーセンテージは不正確であるため、列挙で定義することはできません。

列挙型を操作する際に留意すべき主な点は、列挙型ではデータ定義で "one of" 語句が使用され、"one of" セクション内にインデントされたこれらの項目はサブクラスと呼ばれることです。さらに、例は文字通り定義自体を繰り返すため、列挙では例が完全に冗長になります。

Lesson 8: Itemization Data Definitions

明細化データ定義は、機能/プログラムにさまざまな状態、さまざまな値、およびタイプのカテゴリが必要な場合に使用されます。2つ以上のサブクラスが必要であり、そのうちの少なくとも1つは単一の個別の値ではありません。

混合データの項目化を操作している場合は、関数を実行できるようにサブクラスを適切に保護することに注意することが非常に重要です。これは、ブール値であるサブクラスはナチュラルと同じように評価できないため、プログラムが見ているデータの種類を確認するようにプログラムに指示しないと、混乱してプログラムが故障する可能性があるためです。これを行うには、「ガード」を設定します。たとえば、数値を保護している場合は、実際の評価式の前に次のように配置します: (数値? c)。

これは、より高度な言語のコンパイラが自然にデータ型をチェックするのと同じ方法で、Dr. Racket で使用されます。しかし、Dr. Racketではこれを手動で行う必要があります。

レッスン 9: 間隔を使用した HtDF

間隔データ定義を使用する場合のテストは、これまでのコースでチェック期待値を書くように教えられてきた方法よりも少し複雑です。インターバルの場合、インターバルの境界と中間点の両方を必ずテストすることが、このセクションで配布される最も重要な教訓です。

レッスン 10: 列挙による HtDF

列挙型を使用したテストに関しては、ここで重要なのは、少なくともサブクラスと同じ数のチェック期待値をテストすることです。そうしないと、すべての可能性をカバーすることはできません。

また、このレッスンでは、同じプログラム内に存在する場合、別々の関数に対して個別のデータ定義は必要ないことにも注意してください。データ定義を再利用できます。

レッスン 11: 項目化による HtDF

アイテム化テストの場合、残念ながら、ベースをカバーするにはもう少し考える必要があります。項目化のすべての分散点をテストし、隣接する定義の境界をチェックして、それらの動作が期待どおりであることを確認することが不可欠です。プログラムを完成させてユーザーに送信し、テストが「忙しすぎて」テストできないと判明したものを遡及的に修正するのではなく、徹底的にテストし、思いつく限りのコーナーケースを含める方がはるかに良いです。

第12課 情報フローの構造

今週のノートの冒頭で述べたように、データの作成方法の選択は、最終的に関数/プログラム全体のコードを作成する際のオプションに影響を与えるため、情報の構造を特定することはプログラム設計の重要なステップです。

第3週のまとめ

そのため、クラスフォーラムでは、今週は授業が「現実になった」時期だと多くの人が言いました。率直に言って、私は同意しません。多くのMOOCの第3週は、提示される内容がジェネラリストの知識から得られ、少し深くなってしまうため、かなり急激な落ち込みがあると思います。しかし、繰り返しになりますが、私は第 4 週からビデオを見始めましたが、第 4 週が「現実になる」場所であると自信を持って言えます。インタラクティブなプログラム?それは私が興奮できることです。

来週もご期待ください、そして私がまだ授業にぶら下がっているかどうかがわかります。ビデオコンテンツが2倍になり、宿題が激しいものになると確信しています。