HW 1 is made a range of Bit problems. HW1 is due Tue Jan 14th at 11:55pm.
CS106A section leaders will be available Sun, Mon, Tue, Wed, Thu eve to provide help in the Tresidder Lair. Definitely swing by there if you get stuck or need more explanations, that what they're there for. The "Lair" is downstairs in the Tresidder dining area, midway between the Starbucks and the Ice cream shop.
Solve these problems using loops and logic like the lecture examples (not using Python features like for, range, int counting, break .. which have not covered yet.)
Work on your code using one case at a time. As a last step, select the "Run All" option in the menu and Run to check your code against all the cases. If successful, the output is "All Correct" at the top with the big checkmark, which means your code produces the correct output. You should also check your code over for clean style. The link to submit your code is at the bottom of tihs page.
These first 5 problems are 1 function each - no extra decomposition.
Now for some bigger problems made of several functions. For the Crazy Stanford problem, the function decomposition is provided. Use the radio buttons at the top of the page to build and test the functions one at a time to build the whole thing.
6. Crazy Stanford
Suggestion (added): consider the point where your code has drawn the first S. Now you need to find the next green square for the next S. You do not need a new while-loop to find the next green square.
For this problem, bit starts facing west next to a "rectangle" made of 1 or more blocks. First bit does one "side" move, moving forward while there are blocks to the left, painting squares red. There's a boundary detail here: paint the squares next to a block red, but not the last square.
Before side move:
After side move:
To complete the rectangle, turn left, move, and do another side move, but with the color green.
Then do the last side with blue. That completes one rectangle, which looks like this:
The overall "triple" problem is just 3 rectangles put together, with a right turn making the transition to the 2nd and 3rd rectangles, like this:
After the whole triple:
The main function for this problem is called do_triple() and it solves the whole problem. You should decompose out 2 or more helper functions to help solve the problem. (Nick's solution uses 2 helper functions.) Typically, helper functions are above the main function in the text, but it's not a requirement. For each decomposed helper function write a 1 or 2 sentence description within the """triple quotes""" at the top of the function summarizing what the function does. For the wording of your description, you may assume the reader is familiar with the definitions and terminology of the problem itself. Your description should address the pre and post conditions of the function (and of course you need to have those ideas clear in your head in order to mesh the functions together).
For this problem, bit starts in the upper left corner, facing down. Move bit to the lower left corner, filling in all the rows with a checkerboard pattern, like this:
It's handy to have terms for the two row types — we'll say the topmost row is "type 0", since the blue squares begin right away, and the second row is "type 1". This is a classic, algorithmic CS106A problem. Make a little diagram to think through each function.
Your code should be able to solve any size world that is 2x2 or larger, and the world may not be square.
The main function for this project is called do_checkerboard() and it solves the whole problem. As with the Triple problem, decompose out 2 or more helper functions to help solve the problem. (Nick's solution uses 2 helper functions.) For each decomposed helper function write a 1 or 2 sentence description within the """triple quotes""" at the top of the function describing what it does as above. For this problem, a clear definition of bit's position and facing in the pre/post conditions is important to mesh the functions together.
Here are some friendly suggestions to keep from getting too stuck:
Suggestion 1: there's a non-obvious but extremely cute coding trick that works here: the code that solves the type-1 row can call the code that solves the type-0 row.
Suggestion 2: It's tempting to do a zig-zag pattern, one row going left-to-right, and the next row going right-to-left — that's how you would do it as a person walking around. Unfortunately, that zig-zag scheme works poorly as an algorithm because of the pre/post conditions. With the zig-zag scheme, various rows have different pre/post conditions, so it's very hard to mesh them together. It works more cleanly to do all the rows in the same direction, so their pre/post conditions are uniform.
Turn In HW1