CSC 148H: INTRODUCTION TO COMPUTER SCIENCE

Old Announcements -- Week 3

Friday 27 September: Assignment 1 -- about the sample output

If you saved or printed a copy of the sample output from the web page before the starter code was available, please discard that sample output and make a new copy. That early version of the sample output doesn't match the starter code that I posted; the current version does.
Note that the sample output was produced by a complete program. The starter code is not capable of producing such output because it lacks the procedure Simulate.run.

---

Friday 27 September: Assignment 1 -- Small typos

There are two small typos in the printed handout. The titls says "Assignment 2", when it should say "Assignment 1". And on page 4 it says that "we are also proving the main program", when it should say that "we are also providing the main program". These typos are marked and corrected on the version of the assignment available through this web page.

---

Friday 27 September: Forwarding mail from the CDF PCs

Question: Can our PC facility's mail system can forward a student's e-mail messages (if any) to another address?
Answer: This is not currently possible; however, they system administrators are looking into it. Watch the newsgroups ut.cdf.pc.gripes and ut.cdf.pc.announce for updates.

---

Thursday 26 September: Office hour cancellation

Diane Horton's office hour Tuesday, October 1st, 3-4 pm is cancelled due to a scheduling conflict.

---

Thursday 26 September: Assnt 1 is ready

The handout for assignment 1 is now available on this web page (see "Assignments" below, or click here). It will be handed out in Borodin's and Horton's lectures on Friday.
There are sample runs and starter code associated with this assignment. They are available here also.

---

Tuesday 24 September: Assnt 0 -- handing it in

Question: Is there any way to check that my assignment was handed in properly?
Answer: You should have received feedback from the dialog box at the time you handed the assignment in. If you're worried about it, you can hand it in again.
Question: Is filename that is required is case-sensitive? In DOS, it is A0.T and not a0.t as in the handout.
Answer: Either A0.T or a0.t will be fine.

---

Tuesday 24 September: Assnt 0 -- IntLength in SubtractLastDigit

Question: In StripLeadingZero, IntLength is a var parameter, so we can change the length when we remove the zero. But in SubtractLastDigit IntLength in not a var parameter, so when we do the subtraction, how can we set the IntLength lower?
Answer: You can set it lower, but just not within SubtractLastDigit. Instead, the code that calls SubtractLastDigit must do it.
Whether or not the length reduction should be done by SubtractLastDigit was a decision that was made when we designed the starter code. Another possibility would have been to use another parameter for the single-digit number to be subtracted from BigInt[1..(IntLength-1)]. You can debate the relative merits of the various possibilities, but you must not change our code.

---

Monday 23 September: Latest batch of accounts

To see the accounts that were created today (for students who enrolled last week), click here.

---

Monday 23 September: What is a "token"?

The kind of get statement that you use determines how big a chunk of the input OOT will read in for you. If you use a plain get such as "get name" (vs a get with formatting indicated, such as "get name:5" or "get line:*"), then you have asked for "token-oriented" input. OOT will go and read a single token for you - a sequence of characters surrounded by white space (blanks, tabs, or carriage returns). If that token doesn't turn out to be of the right type, you will get an error message and your program will be terminated.
The other kinds of get statement are "character-oriented" and "line-oriented".
Reference: BHH page 40.

---

Monday 23 September: Assnt 0 -- You must use our algorithm

As the handout says, "only the correctness of your code will be evaluated". To be correct, your program must produce correct results as specified in the handout, and it must use the algorithm specified in the handout.

---

Monday 23 September: Assnt 0 -- Non variable passed to "var" formal

The error message Non variable passed to "var" formal indicates that you have called a subprogram and passed a non-variable actual parameter into a formal parameter that was declared to be "var", ie changeable. (See BHH page 46 if you are unclear about formal vs actual parameters.) It doesn't make sense to do this, because the subprogram is permitted to change the value of the formal parameter, and any such change needs to be reflected in the actual parameter.
There is a simple solution to this problem: copy the value into a temporary variable and pass that variable into the formal parameter.

---

Monday 23 September: Assnt 0 -- False advertising

Some students are writing solutions that do produce correct results and use our algorithm, but that contain "false advertising". That is, their subprograms do not behave as advertised in the comments. Make sure that your subprograms do what the comments say they will - no more, no less.
Don't think of a subprogram being used only in the context of the present program. A subprogram should be a small modular piece of code that can be easily plugged into another program and will behave as the comments lead one to expect.

---

Monday 23 September: Indent your code

Many students are showing me printouts of code that is not consistently indented. You should never try to read such code, much less ask anyone else to. It's much easier to read code that has been indented, and OOT will even indent it for you if you type control-I.

---

Monday 23 September: Trace your code

If you aren't already, you should get into the habit of tracing your code. By this I mean sitting down with a piece of paper and mimicking the steps of your program by hand, exactly as OOT will perform them, keeping careful track of the values of each variable as you go. This may seem like a waste of time; after all, the whole point is to get the computer to do the steps for you. But tracing your code gives you a feel for what's happening that is difficult to get any other way. In fact, you should trace small pieces of your code as you write them. This will help you to get the code right in the first place, and save much debugging time.
You will find that hand tracing is particularly important when you write code involving pointers - as you will be doing in assignment 1.