[Year 12 SofDev] Sample Exam Questions
Mike Brookes
mikebr at tpg.com.au
Wed Apr 27 15:45:05 EST 2011
G'Day Mark
In pre-hysterical times I was a member of the first exam setting panel
for IS. At that stage there were a few teachers who had no formal IT
training so we would occasionally drop in a more interesting question to
encourage teachers to look more closely at particular topics that were
poorly answered. This question may well have been designed to get
classes to look more closely at different ways of handling stacks.
Conventionally the top of stack pointer does not actually point to the
top of the stack but to where the next item should be added, however
this may confuse newbies more than having a TOS pointer which points to
the actual top of stack. Also if the question used a conventional TOS
pointer the stack would not get full with the given steps.
Often element zero in the stack array would contain the TOS pointer so
in a new stack element 0 would contain the value 1. Doing this avoids
the need for a separate TOS variable.
I think the question has certainly provoked discussion - maybe its a
hint that there will be a question on stacks on the EOY exam :-)
Might be a good idea to look at various stack algorithms. ;-)
Mike
On 27/04/2011 2:35 PM, Mark KELLY wrote:
> Thanks for the bone, Mike. Woof! It finally let me work out the many
> assumptions underlying the question: and after all that, I'm not
> wagging my tail.
>
> I think the question is far from clear, and I doubt students would
> make much of it in a real exam.
>
> - It does not, for example, say that the stack is zero-based. If one
> assumes (as I did) that the stack indexing starts at 1, the whole
> thing changes and nothing makes sense.
> - It does not indicate what the mysterious bolding of the bottom 2
> items is meant to represent. If the examiners invent their own
> conventions, they should explain them to us.
> - It does not tell us that the stack pointer in updated *before* a
> push/pop instead of being changed afterwards, as often happens.
> Again, this changes everything.
> - One has to realise that the stack is expanding from the bottom and
> not from the top. Stacks are often represented growing in either
> direction.
>
> When it comes to real-world stack implementation, there are so many
> different options such as these that I found the question
> mind-boggling while I went through the permutations of possible readings.
>
> Grrr.
>
> On 21 April 2011 14:45, Mike Brookes <mikebr at tpg.com.au
> <mailto:mikebr at tpg.com.au>> wrote:
>
> Hi Mark et Al
>
> For the question to make sense one has to make the assumption that
> the stack positions start at the bottom with position zero and go
> up to position 4 which is the top of the stack. At the start the
> bottom two (in bold on the PDF) are valid, hence the top of stack
> pointer showing 1.
>
> Below is the completed table and the stack at the start and after
> each step:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stack at start and after each step
> Step Function Top Output
>
>
> Start Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
> 1 Push (23) 2 Item added (23)
> Stack position 4 92 92 92 92 92 92 92
> 2 Push (18) Item added (18)
> 3 75 75 18 18 75 75 75
> 3 Pop 2 Item removed (18)
> 2 23 23 23 23 23 23 23
> 4 Push (75) Item added (75)
> 1 83 83 83 83 83 83 83
> 5 Push (92) 4 Item added (92)
> 0 52 52 52 52 52 52 52
> 6 Push (47) Stack full
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Top 1 2 3 2 3 4 4
>
>
> Mike Brookes
> Semi retired gentleman from Copperfield College
>
>
> On 21/04/2011 1:35 PM, Mark KELLY wrote:
>>
>> Would someone be kind enough to throw me a bone about the stack
>> question - Q3?
>>
>> I thought I knew stack implementation from my assembly language
>> days with Z80... this question feels like walking into someone's
>> half-finished thought process. I'm really confused about
>> this.After half an hour of conjecture, I’ve tried four times to
>> ask a series of sensible questions to make sense of it, and have
>> failed every time.
>>
>>
>> The only apparent answer involves time travel, reversed arrays,
>> irrelevant stack pointers and bogus bolding of stack items. The
>> relationship between the stack and the table is only the
>> beginning of the problem...
>>
>>
>> I’d be delighted if anyone could walk me through this...
>>
>>
>> Regards
>>
>> Mark
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20110427/f372e188/attachment.html
More information about the sofdev
mailing list