on 08-Sep-2018 (Sat)

For your assignments, use the coding style in this guide, not the style from the HtDP textbook, or the condensed style from the presentation slides

In 2006, when I switched from being a human to being a chess player, I worked through 26 chess books from cover to cover. But somehow I arrived at the conclusion that improving at chess requires more active learning than what is possible by simply reading.

The first question is whether rules of thumb and thinking techniques are useful at all. I found an extensive debate about this while I was finishing this book and got myself up to date on the latest chess literature of the last few years.

Willy Hendriks takes the most extreme position in Move First, Think Later (2012). He argues that there's nothing but concrete moves; Alexander Kotov's mechanical variation trees, from Think Like a Grandmaster (1971), and other thinking techniques are oversimplifying and of no use at the board.

I completely agree with Jonathan Rowson in Chess for Zebras (2005) that the main problem for many ambitious players is that they focus on knowledge.

A good chess player is not someone with well-defined knowledge, but rather one with great skills.

DrRacket(.rkt) files can store rich content that can include images, extended formatting, comment boxes, and special symbols.

some of the content in the In- teractions window may be “rich” (e.g., rational numbers), and so you should avoid copy-and-pasting from your interactions window into your definitions window.

code that appears in a .pdf document (e.g., presentation slides and as- signments) may contain hidden or unusual symbols

For your assignments, save in plain text format. In DrRacket you can ensure your .rkt file is saved using plain text format by using the menu items: File > Save Other > Save Definitions as Text.

During a game, it's too time-consuming to always look for candidate moves and make blunder checks. Instead, I think those techniques should be used extensively in training during a limited period. I will explain what I mean with a short theoretical discussion.

There are also things we know that we can't do - inabilities. I guess one example is winning with two knights against a pawn. Other things we don't even know that we can't do - it's completely beyond our horizon. For understandable reasons, giving an example is impossible.

Making a blunder check is such a skill for some players. They do it, but not deliberately. Looking for pawn levers may be a less known example

It may not give the best short-term results to make a blunder check before every move; it takes time and disturbs the normal thought process. However, hopefully the blunder check will gradually be internalized. After some time, the subconscious intuition automatically makes a blunder check when needed, without a big effort.

The first chapter is about pawn levers, with the thesis that they are the essential part of planning. The next chapter moves on to the pieces, mainly discussing exchanges but also positions with material imbalances. I think they are a good foundation for understanding which factors make a piece good or bad. In the third chapter, the pawn levers and piece exchanges are linked together to form a list of auxiliary questions, where critical positions and general game theory are two of the added topics.

Calculation is the subject of the fourth chapter.

The four pillars of chess training described in this book, in decreasing order ofimportance, are: J.. The List of Mistakes -analysing your games and categorizing the mistakes J.. The Woodpecker Method - learning the tactical motifs and solving simple exercises to internalize them into your intuition J.. Openings -studying them in such a way that you also learn middlegame positions and standard moves J.. Theoretical Endgames - studying them only once

Learning from our mistakes One important characteristic for a chess player is self-knowledge; to understand that you don't lose by chance but because you still have things to learn. To show what I mean, I dive directly into action -a game.

Never include Comment Boxes or images in your submissions. Do not copy-and-paste from the Interactions window or from .pdf documents into the Definitions window, or your assignment may become unmarkable.

Always follow a semicolon by a space to improve readability.

Additional comments should begin with capitals but do not need to end with periods.

Use in-line comments sparingly.

file should start with a header to identify yourself, the term, the assignment and the problem.

Insert two consecutive blank lines between functions or “function blocks”, which include the documentation (e.g., design recipe) for the function.

Insert one blank line before and after the function definition: do not use more than one consecu- tive blank line within a function block.

If you have many functions and/or large function blocks, you may want to insert a row of symbols (such as the * ’s used in the file header above) to separate your functions.

If the question asks you to write more than one function, the file should contain them in the order specified by the assignment.

Helper functions are placed above the assignment function they are helping.

Indentation plays a big part in readability. It is used to indicate level of nest- ing, to align related subexpressions (e.g., arguments of a function), and to make keywords more visible. DrRacket’s built-in editor will help with these.

If you start an expression (my-fn and then hit enter or return, the next line will automat- ically be indented a few spaces.

However, DrRacket will never break up a line for you, and you can override its indentation simply by putting in more spaces or erasing them.

DrRacket also provides a menu item for reindenting a selected block of code (Racket > Reindent) and even a keyboard shortcut reindenting an entire file (Ctrl+I in Windows).

When to start a new line (hit enter or return) is a matter of judgment. Try not to let your lines get longer than about 70 characters, and definitely no longer than 80 characters.

Style marks may be deducted if you exceed 80 characters on any line of your assignment.

In DrRacket there is a setting you can change to show you when you’ve exceeded the line length: Edit -> Preferences -> Editing tab -> General Editing sub-tab -> Maximum character width guide.

your examples and tests may exceed the line length guidelines when there is no obvious place to break the line.

If indentation is used properly to indicate level of nesting, then closing parentheses can just be added on the same line as appropriate.

Some styles for other programming languages expect that you place closing brackets on sep- arate lines that are vertically lined up with the opening brackets. However, in Racket this tends to negatively effect the readability of the code and is considered “poor style”.

For conditional expressions, placing the keyword cond on a line by itself, and aligning not only the questions but the answers as well can improve readability (provided that they are short). However, this recommendation is not strictly re- quired. Each question must appear on a separate line, and long questions/answers should be placed on separate lines.

choose names for functions and parameters that are descriptive, not so short as to be cryptic, but not so long as to be awkward. The detail required in a name will depend on context: if a function consumes a single number, call- ing that number n is probably fine.

It is a Racket convention to use lower-case letters and hyphens, as in the identifier top-bracket-amount. The rare exception is when proper names are used such as Newton. In other languages, instead of top-bracket-amount one might write this as TopBracketAmount or top _ bracket _ amount, but avoid these styles when writing Racket code.

predicates that re- turn a Boolean value usually end in a question mark (e.g. zero?)

functions that do conversion use a hyphen and greater-than sign to make a right arrow (e.g. string->number). This convention is also used in contracts. In some course materials you may see an actual arrow produced (e.g. string→number), but you should always type them as two characters (->).

If the value of cost-per-minute changes, it is much easier to make one change to the definition of the constant than to search through an entire program for the value 0.75. When this value is found, it is not obvious if it refers to the cost per minute, or whether it serves a different purpose and should not be changed.

As values used in testing and ex- amples become more complicated (e.g., lists, structures, lists of structures), it can be very helpful to define named constants to be used in multiple tests and examples.

• Use one blank line before and after your function definition.

Make it clear where function blocks begin and end (i.e., two blank lines between function blocks).

Style marks may be deducted if you have poor headers, identifier names, whitespace, indentation or layout.

If you hand in only code, even if it works perfectly, you will earn only a fraction of the marks available.

The purpose statement has two parts: an illustration of how the function is applied, and a brief description of what the function does. The description does not have to explain how the computation is done; the code itself addresses that question.

The purpose starts with an example of how the function is applied, which uses the same parameter names used in the function header.

Do not write the word “purpose”.

The description must include the names of the parameters in the purpose to make it clear what they mean and how they relate to what the function does (choosing meaningful parameter names helps also). Do not include parameter types and requirements in your purpose statement — the contract already contains that information.

If the description requires more than one line, “indent” the next line of the purpose 2 or 3 spaces.

If your purpose requires more than two or three lines, you should probably consider re-writing it to make it more condensed. It could also be that you are describing how your function works, not what it does.

If you find the purpose of one of your helper functions is too long or too complicated, you might want to reconsider your approach by using a differ- ent helper function or perhaps using more than one helper function.

The contract contains the name of the function, the types of the arguments it con- sumes, and the type of the value it produces.

If there are important constraints on the parameters that are not fully described in the contract, add an additional requires section after the contract. For example, this can be used to indicate a Num must be in a specific range, a Str must be of a specific length, or that a (listof ...) cannot be empty. Indent multiple requirements.

The examples should be chosen to illustrate ‘typical’ uses of the function and to illuminate some of the difficulties to be faced in writing it.

Examples should cover each case described in the data definition for the type consumed by the function.

The examples do not have to cover all the cases that the code addresses; that is the job of the tests, which are designed after the code is written.

It is very useful to write your examples before you start writing your code. These examples will help you to organize your thoughts about what exactly you expect your function to do. You might be surprised by how much of a difference this makes.

Typically, for recursive data, your examples should include each base case and at least one recursive case.

Develop your purpose, contract and examples before you write the code for the function.

use the provided basic tests when you submit your assignments. If your code does not pass these tests, then you should carefully check your submission for spelling errors and the like.

You do not have to repeat your examples in your tests section. Your examples also count as tests.

Make sure that your tests are actually testing every part of the code. For example, if a conditional expression has three possible outcomes, you have tests that check each of the possible outcomes.

your tests should be directed: each one should aim at a particular case, or section of code.

Some people write tests that use a large amount of data; this is not necessarily the best idea, because if they fail, it is difficult to figure out why.

Others write lots of tests, but have several tests in a row that do essentially the same thing. It’s not a question of quantity, but of quality.

design a small, comprehensive test suite.

Never figure out the answers to your tests by running your own code. Work out the correct answers independently (e.g., by hand).

Do not use the word “helper” in your function name: use a descriptive function name.

Helper functions only require a purpose, a contract and at least one illus- trative example. You are not required to provide tests for your helper functions (but often it is a very good idea).

we have seen students avoid writ- ing helper functions because they did not want to provide documention for them. This is a bad habit that we strongly discourage.

Writing good helper functions is an essential skill in software development and simply writing a purpose and contract should not discourage you from writing a helper function.

Marks may be deducted if you are not using helper functions when appropriate. Helper functions should be placed before the required function in your submission

Functions we ask you to write require a full design recipe. Helper functions only require a purpose, a contract and an example.

If we ask you to write two mutually recursive functions, only one of the functions requires tests.

When using wrapper (primary) functions, only one of the functions requires tests. If the required function is the wrapper function, then include the examples and tests with it. Otherwise, use your judgement to choose the function where ex- amples and tests seem most appropriate.

For functions defined with a local block, no tests or examples are necessary

Add a blank line after each local function definition.