[Year 12 SofDev] MC - plus a correction
Adrian Janson
janson.adrian.a at edumail.vic.gov.au
Wed Nov 23 11:38:14 EST 2011
Hi Kevork and others,
I think that this is a good *extension discussion for a class - and I did
read the bottom bit - great stuff!! We have to be mindful of what the
examiners will (or can) ask - and so from that perspective we need to be
aware of what a simple 1D array implementation looks like (I think - as this
is the intention of the SD). But I for one will definitely include this
deeper discussion in 2012!
Cheers,
Adrian
Adrian Janson B.Sc, Dip.Ed, M.Ed
Director of ICT
Melbourne High School, Forrest Hill, South Yarra, Victoria 3141 Australia.
Phone: 03 9826 0711 International: +61 3 9826 0711
Fax: 03 9826 8767 International: +61 3 9826 8767
E-mail: janson.adrian.a at edumail.vic.gov.au
Website: http://www.mhs.vic.edu.au
Blog: http://jansona.edublogs.org
-----Original Message-----
From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au]
On Behalf Of Kevork Krozian
Sent: Wednesday, 23 November 2011 11:28 AM
To: Year 12 Software Development Teachers' Mailing List
Subject: Re: [Year 12 SofDev] MC - plus a correction
Hi Folks,
Adrian, I do take your point of specific implementations differing from
others. I just wonder if retaining the popped element is helping the
understanding. That is really the one and only issue.
I guess we are talking stacks here and we need to see the structure
reflect what is in the stack rather than the imperfections of the
implementation.
For what it is worth one of our programmers and I did some testing on
inbuilt stack structures on 3 languages yesterday and the results were
below. I have also added a correction to a statement I made yesterday.
You won't be any worse off if you don't read it :)
Kind Regards
Kevork
-------------------------------------------------------------------------
We have been doing some testing with Stack implementations today and the
results seem far from consistent.
C# seems to keep the absolute physical memory address for "Top" the same
no matter how much data is popped or pushed - suggesting the memory is
being managed by either compressing up when popped ( move the stack
structure up one memory location) or down when pushed ( move the stack
structure down one memory location ). In built garbage collection ?
C++ seems to be more "interesting". When a pop occurs, it is possible to
access the
previous memory item via a pointer to the absolute address of the
previous top element. Yes, the popped item is still there ! No inbuilt
garbage collection ?
PHP uses an array implementation for a stack with its own array_push and
array_pop methods ( for a queue the array_push and array_shift are used).
If an attempt is made to access a popped element by the use of the index
of the popped item the data is nowhere to be found - an error occurs. That
is because an
array element outside the range is not defined.
A stack is defined by the top variable to show the last item added or the
current top. What benefit is it to see what was previously popped ?
I do need to correct one earlier statement:
Elements are not stored contiguously in memory ( I meant to say
Elements are not necessarily stored contiguously in memory )
with
Elements appear to be always stored contiguously in memory. It makes
sense to make access to the stack as easy as possible.
In other words more often than not a stack implementation will try to use
contiguous memory. We struggled but could not find an example of a stack
structure being broken up in memory.
Kind Regards
Kevork
> I used the 1D array to teach the concept, and got my kids to implement it
> in code, which they did surprisingly easily, even adding PEEK & SWAP
> commands.
>
> Actually implementing it made it far clearer to them how the stack pointer
> worked to prevent having to constantly shift data in memory.
>
> On 22 November 2011 09:32, Adrian Janson
> <janson.adrian.a at edumail.vic.gov.au
>> wrote:
>
>> Hi everyone,****
>>
>> ** **
>>
>> My 2c now!****
>>
>> ** **
>>
>> I disagree with this view - we are discussing a stack implementation in
>> a
>> 1-D array and in such a case, a stack will work in exactly this way.
>> Isn't
>> this the way that we all taught it? VB.Net has an inbuilt stack data
>> structure and I certainly made use of it - but only after I taught my
>> class
>> how to implement a stack in a 1-D array. I am interested to hear how
>> others taught it - I just felt that if I used the 'stack' data structure
>> that the understanding of my class would have been minimal. I first
>> taught
>> them how a stack worked, then asked them to write a push and pop
>> algorithm
>> using a 1-D array, which we then coded - and after we had completed all
>> of
>> these - I showed them the 'stack' data structure in VB.Net.****
>>
>> ** **
>>
>> Is this what others are doing or am I way off base?****
>>
>> ** **
>>
>> Cheers,****
>>
>> Adrian****
>>
>> ** **
>>
>> *Adrian Janson **B.Sc, Dip.Ed, M.Ed
>> **Director of ICT
>> *Melbourne High School, Forrest Hill, South Yarra, Victoria 3141
>> Australia.
>> Phone: 03 9826 0711 International: +61 3 9826 0711
>> Fax: 03 9826 8767 International: +61 3 9826 8767
>> E-mail: janson.adrian.a at edumail.vic.gov.au****
>>
>> Website: http://www.mhs.vic.edu.au****
>>
>> Blog: http://jansona.edublogs.org****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* sofdev-bounces at edulists.com.au [mailto:
>> sofdev-bounces at edulists.com.au] *On Behalf Of *Andrew Shortell
>> *Sent:* Tuesday, 22 November 2011 8:49 AM
>> *To:* Year 12 Software Development Teachers' Mailing List
>> *Subject:* Re: [Year 12 SofDev] MC****
>>
>> ** **
>>
>> Hi all (you too K)
>>
>> Older members of the list might remember back a long time ago when we
>> were
>> taught programming.
>>
>> This way of doing is how it was taught way back then. It made perfect
>> sense to me. (yes I am 53+ !! ;-)
>>
>> Modern programming languages do not have to be so parsimonious with RAM
>> and processor speed thus the implementation nowadays is not so old
>> fashioned.
>>
>> Perhaps this is one of those times when making the effort to understand
>> the exam setting panel makes sense (many of you know my preaching about
>> that so no more on it now and NO I am not on the panel). Clearly the
>> hard
>> core programmer on the panel learnt theory back then... (or was taught
>> by
>> someone who learnt the theory back then.....! )
>>
>> Off my soapbox and back to work
>> I need to start packing my gear soon as I am off to a new school in 2012
>> Very exciting
>>
>> Andrew
>>
>> --
>> Andrew Shortell
>>
>> mailto:shortell at get2me.net <shortell at get2me.net>
>> Leaving the
>> Heidelberg Teaching Unit at the end of 2011
>> Ph 9470 3403
>> Fax 9470 3215
>>
>>
>>
>> On 22/11/11 7:27 AM, "Kevork Krozian" <kevork at edulists.com.au>
>> wrote:****
>>
>> Hi Gordon,
>>
>> I am with you on this question.
>> This very point about the state of the stack is what gets me and every
>> one of my programmer and lecturer friends scratching our heads.
>>
>> Once a stack is popped ( this can be demonstrated with a few short
>> segments of code in PHP, C#, C++ ) any attempt to access the popped
>> location leads to either garbage or undefined or no value being returned
>> from the element.
>>
>> This clearly demonstrates that for stack data structures that are built
>> in
>> to a programming language
>> 1. Elements are not stored contiguously in memory
>>
>> 2. Elements are not retained once popped
>>
>> 3. There is no overwriting of a popped element by a new Push
>>
>>
>> It seems a manual deliberate implementation with a quirky Pop method is
>> the only way to duplicate the scenarios presented in both the practice
>> and
>> final exams. Whilst possible to do, it does not reflect what happens
>> when
>> programming.
>>
>> Kindest Regards
>>
>>
>> Kevork Krozian
>> Edulists Creator Administrator
>> www.edulists.com.au
>> tel: 0419 356 034
>>
>>
>> *From:* sofdev-bounces at edulists.com.au [
>> mailto:sofdev-bounces at edulists.com.au <sofdev-bounces at edulists.com.au>]
>> *On
>> Behalf Of *Poultney, Gordon A
>> *Sent:* Friday, 18 November 2011 8:41 AM
>> *To:* Year 12 Software Development Teachers' Mailing List
>> *Subject:* Re: [Year 12 SofDev] MC
>>
>>
>> Heath,
>>
>> I saw your comment and realised I must not have replied to the list
>> yesterday?
>>
>> I was nitpicking about A-18
>>
>> "re: Q 18, D is clearly the best answer.
>>
>> But I would have thought that the 'pop' removes reference to that
>> location, while leaving '10' in memory, but not in the stack as such. 10
>> is
>> no longer 'there' in stack. Maybe just nitpicking on my part Damien!
>> At least there were 3 clearly incorrect answers.
>>
>> Pretty good exam for Part A and B.
>>
>> I still haven't read the case study through, but C-3 is a little
>> awkward.
>> I wouldn't link functional reqs. with a context diagram that only shows
>> data flows - perhaps a DFD was intended here?"
>>
>> cheers
>> gordon
>>
>>
>>
>> *-----------
>> Gordon Poultney
>> Horsham College*****
>> ------------------------------
>>
>> *From:* sofdev-bounces at edulists.com.au [sofdev-bounces at edulists.com.au]
>> on behalf of Matheson, Heath A [Matheson.Heath.A at edumail.vic.gov.au]
>> *Sent:* Thursday, 17 November 2011 11:39 PM
>> *To:* Year 12 Software Development Teachers' Mailing List
>> *Subject:* Re: [Year 12 SofDev] MC
>>
>> Hi guys,
>>
>> I agree with Juliana's solutions, except I think in your description of
>> Q12 that B and D are non-functional requirements since they don't affect
>> the data inputs and outputs of the program. I don't think we're told any
>> of
>> the functional requirements for this scenario. I think Michelle needs
>> to
>> interview the bank manager for them.
>>
>> For question 13, I'm 90% confident you always complete internal
>> documentation while you are coding and this would be before testing
>> which
>> only leaves option B. A is incorrect as the only time you interview is
>> in
>> the analysis and evaluation phases and the question states analysis is
>> complete.
>>
>> I had to think about Question 20. I think is a bit of a "horses for
>> courses" question between A and B. Some people like scrolling while some
>> people are really good at zooming in on images with index finger and
>> thumb
>> and could click a map. This would be particularly useful if you were
>> looking different countries in a region, but a problem if you don't know
>> where the country is located. So I think the scrollable list, still
>> works
>> well on the iPod. Matching characters would be difficult if there was a
>> spelling error or you enter a city instead of a country (Someone asked
>> me
>> today if Dubai was a county).
>>
>> I'm interested to see what error Gordon has spotted.
>>
>> Heath Matheson
>> Mount Beauty Secondary College.
>> PS - I have more in my IT class next year than my biology class. First
>> time for everything.
>>
>>
>>
>> *From:* sofdev-bounces at edulists.com.au [
>> mailto:sofdev-bounces at edulists.com.au <sofdev-bounces at edulists.com.au>]
>> *On
>> Behalf Of *Pang, Juliana C
>> *Sent:* Thursday, 17 November 2011 6:06 PM
>> *To:* Year 12 Software Development Teachers' Mailing List
>> *Subject:* Re: [Year 12 SofDev] MC
>>
>> This is just my opinion for question 12.
>>
>> A. The bank does not want her to add extra functions (so this
>> defines the boundary of the solution)
>>
>> B. The program will be made available via the bank's website
>> (functional requirement)
>>
>> C. The bank is only small and does not require a complex program
>> (silly response)
>>
>> D. The program must cater for visually impaired people and people
>> with normal vision (functional requirement)
>>
>>
>> So I think A.
>>
>>
>> *From:* sofdev-bounces at edulists.com.au [
>> mailto:sofdev-bounces at edulists.com.au <sofdev-bounces at edulists.com.au>]
>> *On
>> Behalf Of *El Tabbal, Riad R
>> *Sent:* Thursday, 17 November 2011 5:57 PM
>> *To:* sofdev at edulists.com.au
>> *Subject:* [Year 12 SofDev] MC
>>
>> For Q12, the manager specified that the program must cater for visually
>> impaired people as well as people with normal vision. What do you think?
>>
>> *Kind regards,
>> Riad El Tabbal
>> Math/IT Teacher
>> Copperfield College
>> Delahey Campus
>> 03 9307 5555
>> *
>>
>>
>> *Important - *This email and any attachments may be confidential. If
>> received in error, please contact us and delete all copies. Before
>> opening
>> or using attachments check them for viruses and defects. Regardless of
>> any
>> loss, damage or consequence, whether caused by the negligence of the
>> sender
>> or not, resulting directly or indirectly from the use of any attached
>> files
>> our liability is limited to resupplying any affected attachments. Any
>> representations or opinions expressed are those of the individual
>> sender,
>> and not necessarily those of the Department of Education and Early
>> Childhood Development.
>>
>> *Important - *This email and any attachments may be confidential. If
>> received in error, please contact us and delete all copies. Before
>> opening
>> or using attachments check them for viruses and defects. Regardless of
>> any
>> loss, damage or consequence, whether caused by the negligence of the
>> sender
>> or not, resulting directly or indirectly from the use of any attached
>> files
>> our liability is limited to resupplying any affected attachments. Any
>> representations or opinions expressed are those of the individual
>> sender,
>> and not necessarily those of the Department of Education and Early
>> Childhood Development.
>>
>> *Important - *This email and any attachments may be confidential. If
>> received in error, please contact us and delete all copies. Before
>> opening
>> or using attachments check them for viruses and defects. Regardless of
>> any
>> loss, damage or consequence, whether caused by the negligence of the
>> sender
>> or not, resulting directly or indirectly from the use of any attached
>> files
>> our liability is limited to resupplying any affected attachments. Any
>> representations or opinions expressed are those of the individual
>> sender,
>> and not necessarily those of the Department of Education and Early
>> Childhood Development.
>>
>> *Important - *This email and any attachments may be confidential. If
>> received in error, please contact us and delete all copies. Before
>> opening
>> or using attachments check them for viruses and defects. Regardless of
>> any
>> loss, damage or consequence, whether caused by the negligence of the
>> sender
>> or not, resulting directly or indirectly from the use of any attached
>> files
>> our liability is limited to resupplying any affected attachments. Any
>> representations or opinions expressed are those of the individual
>> sender,
>> and not necessarily those of the Department of Education and Early
>> Childhood Development.****
>> ------------------------------
>>
>> _______________________________________________
>> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
>> IT Software Development Mailing List kindly supported by
>> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment
>> Authority and
>> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
>> http://www.vitta.org.au - VITTA Victorian Information Technology
>> Teachers Association Inc
>> http://www.swinburne.edu.au/ict/schools - Swinburne University****
>>
>>
>> -- ****
>>
>> *Important - *This email and any attachments may be confidential. If
>> received in error, please contact us and delete all copies. Before
>> opening
>> or using attachments check them for viruses and defects. Regardless of
>> any
>> loss, damage or consequence, whether caused by the negligence of the
>> sender
>> or not, resulting directly or indirectly from the use of any attached
>> files
>> our liability is limited to resupplying any affected attachments. Any
>> representations or opinions expressed are those of the individual
>> sender,
>> and not necessarily those of the Department of Education and Early
>> Childhood Development.
>>
>> _______________________________________________
>> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
>> IT Software Development Mailing List kindly supported by
>> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment
>> Authority and
>> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
>> http://www.vitta.org.au - VITTA Victorian Information Technology
>> Teachers Association Inc
>> http://www.swinburne.edu.au/ict/schools - Swinburne University
>>
>
>
>
> --
> Mark Kelly
> Manager of ICT, Reporting, IT Learning Area
> McKinnon Secondary College
> McKinnon Rd McKinnon 3204, Victoria, Australia
> Direct line / Voicemail: +613 8520 9085, Fax +613 9578 9253
> kel at mckinnonsc.vic.edu.au
> VCE IT Lecture Notes: http://vceit.com
> Moderator: IT Applications Edulist <http://www.edulists.com.au/>
>
> Want a good time? Call 0112358. Ask for Mr Fibonacci.
> _______________________________________________
> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
> IT Software Development Mailing List kindly supported by
> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment Authority
> and
> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
> http://www.vitta.org.au - VITTA Victorian Information Technology Teachers
> Association Inc
> http://www.swinburne.edu.au/ict/schools - Swinburne University
_______________________________________________
http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
IT Software Development Mailing List kindly supported by
http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment Authority
and
http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
http://www.vitta.org.au - VITTA Victorian Information Technology Teachers
Association Inc
http://www.swinburne.edu.au/ict/schools - Swinburne University
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
More information about the sofdev
mailing list