This file contains questions asked by students along with the answers provided. (The identity of the students will not be included) New Q&A will be added at the top of this file as they arrive -- it's a stack. ----------------------------------------------------- Question 14 Jan 20 In Task 4 the Show command always outputs something. If tester.dem tests the Show command then the specification for only printing "Test Succeeds" is violated. What should I do? Answer One interpretation is Show cannot be called in the minimal output driver. Another interpretation is to have debug statements not only for entering the prucedure but also to guard against executing the put statement. Thus with debugging turned on output displays stack contents as well as "Entered Show". With debugging turned off show does not display anything. The second approach would seem to be more in spirit with minimal output and the use of debug statements. ----------------------------------------------------- Question 13 Jan 20 Finalize for stack1 does not work correctly. If I test in Task 4 with asserts then the final message "Test succeeded" will not execute, contradicting the specification. What should I do? Should I correct the error? Answer Do not correct errors, you are only testing the program. You can do one of the following either (1) Put the Finalize as the last thing to do in tester.dem and document that fact, or (2) put debug statements around Finalize, show a test run with Finalize not being called (satisfying the specification of printing "Test succeeded") and documenting the use of debug to bypass the execution of Finalize. ----------------------------------------------------- Answer 12 Jan 20 It does not seem to me to be Finalize's job to make IsEmpty true. Its job is to deallocate memory. I have been telling people that the purpose of Task 1 is to design tests to test the interactive driver. These are likely different then the tests to test the stack. Jeff ----------------------------------------------------- Question 11 Jan 17 > In task III, if the user enters a element which is greater then > maxint we get an invalid integer error. We try > checking for this in the following way in our code: > > put "please eneter element: ".. > get element %execution stops after this line of code.. > if element > minint and element < maxint then > Stack.Push(element) > else > put "invalid input...." > endif > > The problem is it doesn't check the line after "get element" so we > always get the invalid integer error. This level of checking is not required for the assignment. The only solution is to read the string of digits in as an asci string and then to write routines to process it. ----------------------------------------------------- Question 10 Jan 15 - I am not sure but I think we have a problem with Assignment1 - specification for task2 and task3. Here is the problem : - In the part 2 we are told that operation p (pop) is supposed - to pop the first elemnent and print its value. That is exactly - what I stated in the list of commands in my driver.dem file. - But it is obvious that stack1.tu file from task 3 is written just - to pop the value but not to print it too. There is no problem here. You are confusing the two levels of implemenation. The driver.dem program when given the 'p' command by the user calls pop and prints out the popped value. This printing is not done by the Stack implemenation. - P.S. If we(students) have any questions about assignments who are we - supposed to ask for a help. Going to one of the office hours is the best bet. There are many of them. ----------------------------------------------------- Question 9 Jan 15 Since the capacity of the Stack in stack2.tu depends on the virtual memory we have. It seems the Stack will never be full because once it is full, the program will crash. As a result, we may never reach a condition that the stack is full and we may never be able to test whether the IsFull function is working properly, i.e. detecting a full Stack as full. So in task 4, how can I test the IsFull function of stack2.tu ? Answer Dynamically allocated collections can never be full. Running out of memory space is not the same as being full. Consider having two dynamically allocated stacks that together fill up memory -- it is impossible to obtain space for a new element to add to either stack. Suppose space is freed up from stack1, then stack2 does not suddenly become not full. We did nothing to the stack2 so how can it have changed state. When memory is full it is impossible to allocate space for a new object, the dynamically sized objects do not all suddenly become full. The solution, IsFull is always false for a dynamically allocated object. It is the new operation which fails not the add to stack operation. Be a good citizen, do not allocate more than a few dozen elements to stack2. If enough people use millions of stack elements Ariel can crash. The Unix version of Turing does not have sufficent memory protection. ----------------------------------------------------- Question 8 Jan 13 In task 3, if we run the program, enter 'P' and enter a non-integar, the program stops. Is it considered a bug of the program "stack1.tu" or a bug of the test driver? Answer It is a "bug" of the user. Please see Question 7. ----------------------------------------------------- Question 7 Jan 13 In the task 3, we are asked to test stack1.tu. What if the program stops because of the failure of the pre and post conditions in the stack1.tu? Do we have to check whether or not the input is valid in "driver.dem"? (eg. Pop when the stack is not empty) Answer Please note the following line in the specification for task 2. The driver you write for Task 2 should work with no change (other than which stack to import). "The user must know which calls are supported and what functions each call should perform. It is up to the user to ensure that proper action is taken." ----------------------------------------------------- Question 6 Jan 13 In task 2, it said that the test driver "should read input from the keyboard and excute commands accordings to the input specified". Is it mean that if I run the program and enter "e", the program will output the message from the stub along with the message that indicates whether or not the stack is empty? Answer A stub cannot print the message that indicates the stack is empty. As the stub, according to Task 1, does not computation but only prints which procedure/function was called and with what parameters (See Question 3). In general, output from the test driver is whatever output is displayed by the driver and by the routines being tested. In Task 2 the driver would display the output from procedures and functions. ----------------------------------------------------- Question 5 Jan 13 Is the format of the assignment the same as we did in CS1020? That is, do we have to follow the format of the file " report.template"? Answer The general ideas would be followed but the emphasis changes. Reports need to be structured to suit the task. In assignment 1 you have 5 tasks, so the report should be structured with 5 major subparts. Each subpart would have substructure according to the task. Those that are programming in nature would be close to the style of 1020, those that emphasize testing would have subsections describing testing in great detail -- such as test plans, conclusions reached, additional tests arising from the test plan. ----------------------------------------------------- Question 4 Added Jan 13 - When I started working at home on the assign#1 ( 1030), some problems get - into my way. - My Driver.dem ( used to test the stack) worked very well with my stubs( - please excuse me if I used this word incorrectly) (procedures and - functions in my stubs do not have error checking ) But In TASK 3, where - we replace the stub with the real STACK (in which I can see there are - error checking), my testing program crashed ( pre condition not satisfied) This means that your test program has not been implemented correctly. - I am getting confused whether or not I should put some error checking in - the stubs. If I do this, then my stubs will eventually turn out to be the - real stack ( it is not supposed to do anything except printing messages ?) The stubs should have no error checking. However, you should read the specification provided in the text book and write your test programs in such a way that the pre and post conditions specified for the Stack ADT are satisfied. - Also for the testing using INPUT file . My Driver.dem crashed when - reached EOF. If I insert a EOF checking statement in Driver.dem then I - will have the problem to use the program in normal way ( without - redirection). So what should I do? Should I just ignore it? It's fine just to put a 'q' at the end of your file (since that is the command for quit). - Thank you for your time. I really enjoy this class ( seems like the - assignments are more challenging than in 1020 :) That's the hope :-) ----------------------------------------------------- Question 3 - I would like to know in TASK 2, since we use the stub implementation of - the stack, all functions seem to work since they don't have any error - checking. Should I add these checking statements in the TEST PROGRAM NOW - or LATER (in TASK 3)? The stubs don't do anything useful. They do no checking and they also don't do any computation. ----------------------------------------------------- Question 2 > In the Web page and in class you told us that we are able to work in > pairs for the assignment 1. Can we work with someone from another > section though? It is the same class just taught by different > professors. Yes you can work with someone from another section. You write the name of the section that you are ENROLLED in. There is also a line on the cover sheet that asks which section the assignment should be returned to (the assignment will be handed back in that section). ----------------------------------------------------- Question 1 >1) Is the format of the assignment the same as we did in CS1020? That >is, do we have to follow the format of the file " report.template"? The general ideas would be followed but the emphasis changes. Reports need to be structured to suit the task. In assignment 1 you have 5 tasks, so the report should be structured with 5 major subparts. Each subpart would then have substructure according to the task. Those that are programming in nature would be close to the style of 1020, those that emphasize testing would have subsections descrbing testing in great deal -- such as test plans, conclusions reached, additional tests arising from the test plan. >2) In task 2, it said that the test driver "should read input from the >keyboard and excute commands accordings to the input specified". Is it >mean that if I run the program and enter "e", the program will output >the message from the stub along with the message that indicates whether >or not the stack is empty? A stub cannot print the message that indicates the stack is empty. As the stub, according to Task 1, does not computation but only prints which procedure/function was called and with what parameters. In general, output from the test driver is whatever output is displayed by the driver and by the routines being tested. In Task 2 the driver itself does not output anything. >3) In the task 3, we are asked to test stack1.tu. What if the program >stops because of the failure of the pre and post conditions in the >stack1.tu? Do we have to check whether or not the input is valid in >"driver.dem"? (eg. Pop when the stack is not empty) Please note the following line in the specifications: "The user must know which calls are supported and what functions each call should perform. It is up to the user to ensure that proper action is taken." >4) In task 3, if we run the program, enter 'P' and enter a non-integar, >the program stops. Is it considered a bug of the program "stack1.tu" or >a bug of the test driver? It is a "bug" of the user. Please see the previous comment.