|
Robert den Hartog wrote: It's because your instructions are to literal
Well no, that was part of my point. They use the descriptions that are typical for that abstraction level. You do divide that array into groups of 4 bytes, but only mentally. That is what they have to get used to, because descriptions of algorithms and data structures are always going to work that way.
But these examples are just examples. You're taking them too literally too.
|
|
|
|
|
harold aptroot wrote: But these examples are just examples. You're taking them too literally too.
Agree, it's taken literally because that is what your instructions specify: 'take this, do this then do this then do this,' not 'take this and give me that.'
Yes you do need to give examples, but make the examples more abstract, instead of:
'take this array,
divide the array of bytes into groups of 4 bytes,
then xor those blocks like this'
instead (i.e. shown on blackboard / projector):
'using this data // show a string of data bytes
xor these 4 bytes, xor with this next 4 bytes, now draw some arrows 1 -> 5, 2 -> 6, 3 -> 7, 4 -> 8
then xor that with the next 4 bytes, (draw new dotted line arrows, 5 -> 9, 6 -> 10 ...)
repeat to the end'
It's your instructions that are are too explicit.
It's your instructions that are explicitly stifling creativity.
(And hold back a bit to see if any of the students have enough thought to ask about the length of data not being evenly divisible by 4 - and if so let them propose solutions before giving them an answer.)
Sin tack ear lol
Pressing the "Any" key may be continuate
modified 16-Oct-16 0:32am.
|
|
|
|
|
But my entire point is that this not too explicit. This is precisely the level of "it looks like it's telling you to implement it a certain way, but you still shouldn't" that they should get used to. How are they going to get used to it if I go out of my way avoid the normal way of specifying these things?
Edit: to put it an other way, the problem is not that they're writing those solutions. The problem is that maybe half of them are not learning to see past the literal wording of an assignment, which is a skill they will need daily. So removing that aspect is the opposite of a solution.
modified 16-Oct-16 7:35am.
|
|
|
|
|
While they may need to "learn to see past the literal wording", THIS is not a scenario in which such behavior is generally rewarded. When you are taking a programming class, and your instructor gives instructions that have a clear literal solution, providing anything else is usually a good way to get a bad grade. (Take my word for this as someone who had to challenge any number of professors on this point because of my "creative" solutions to their "literal" assignments. It usually boiled down to - Prof: "This doesn't do what I said!" Me: "Did you actually run my code?")
In other words, the instructions are "translate the for loop into assembly" NOT "provide the most efficient assembly that accomplishes the task represented by this for loop". Depending on the for loop provided, transliteration may indeed be the most efficient implementation. On the other hand, if the provided start, end, and increment values are constants, it might be most efficient to just repeat the code. You didn't provide enough information (to us) to determine which might be the case.
Or "break down this array into 4-byte blocks and XOR them" - starting with the fact that I have no idea WHY you want to do this. What are you actually testing with that particular assignment? Their ability to subdivide an array? Their understanding of XOR? Both? Neither and you just want them to give you a specific 4-byte result?
|
|
|
|
|
Perhaps I may still be missing something but if you are asking how to get people to see the "big picture" and look past the initial, literal assignment then good luck 
I guess this comes with experience and I have come to the conclusion that quite a bit of this "programming" of ours falls into the category of tacit knowledge. I guess since it is more of a creative synthesis of sorts. Also falls in quite nicely with the "Dreyfus model of skill acquisition" at the "Novice" level.
Anyhow, I think you basically have to wait for the penny to drop.
|
|
|
|
|
Put it in the syllabus! 
All jokes aside, I saw it mentioned in another response that explicitly following the instructions is something that is baked into the education system nowadays with standardizations. An explanation that is missing from your original post is that the explicit specifications and the need to determine what is fluff and what is specification is an industry standard. There is a lot of rewiring of brains needed here. You'll need to experiment to get the results you want, but this is what I would try
1) Talk about it leading up to the first assignment.
Make sure they know what you are looking for, dissect the first example in class. Let them try it out then critique them gently. Make sure they know that they will be penalized in the following assignments. Also give them the explanation before hand. Maybe dig up some real world examples and tell them their job is to find the most efficient approach for the correct answer, not follow along line by line.
2) Hammer them on the second assignment.
Make them shocked when they see their results. Don't just blow them off though (it would suck to make that much animosity right off the bat). But, now that their eyes are open, give them a chance to redeem for partial credit. Maybe go over it as a thing that is commonly happening and this is how to fix it. Drive the point home that this is a skill they will need to perfect to work with the specifications which can be seen in the industry.
3) Keep a tough but fair approach going forward.
Keep an ear to the ground when other abnormally large assignments are going around and cut some slack in those weeks for the students who could use it. Otherwise, offer office hours for those few who just "don't get it"
That's my 3 cents, good luck 
|
|
|
|
|
Those are the days of dirt-cheap memory... People born with that never think about O(1) in memory algorithms 
Banking establishments are more dangerous than standing armies. T.Jefferson
|
|
|
|
|
They've been taught all through their schooling that if they are given instructions, they must follow the instructions. They would be downgraded if they ever got the right answer but not in the way specified. This is a hard habit to break.
One way is, like another reply said, to not give any 'how-to', but only specify inputs and outputs.
Another way is to give a bad and buggy implementation and tell them to both fix and optimize it.
Both are useful skills for them to learn.
|
|
|
|
|
Start by Googling "requirements specification." The phrase "For example" can do wonders. Define both input and output data structures. When some students use different strategies to get from I to O, you have an opportunity for discussion.
In the case of the for-loop, did you specify coding for maximum efficiency in that specific case of 8 loops, or did you leave their minds open to the possibility that they were expected to create a general solution and would be down-graded for giving you a trivial specific solution?
Writing good exam questions takes time and experience. If you rush the process the students will find valid possible answers you never anticipated, but are correct for the specified question. I have written exam questions in the biological sciences for decades and still get "caught" writing an ambiguous test question from time to time. Few people achieve perfection without recycling their "good" questions and refining the "bad" ones. That's how professional testing services work: they continually evaluate and refine their pool of exam questions.
|
|
|
|
|
In order to prevent students from taking the assignment too literally, give them examples.
I mean, give them an example of an assignment, then give them a solution for this assignment that corresponds to taking the assignment too literally, and after that give them a solution that you think is way more appropriate.
Then do this with another example assignment, and its own solutions that are "too literal" and that are "appropriate".
Then do this with yet another example assignment, and its own solutions that are "too literal" and that are "appropriate".
If you do this a few times, the students will eventually understand.
|
|
|
|
|
In the "old days", we (noobs) had to submit a "flow chart" for review / approval before starting to code.
But I guess that now flies in the face of being "agile". Or that's not how "functional programming" works.
Anybody know what a "flow chart" is? How about an ERD?
|
|
|
|
|
Yea the new style is "throw code at the test cases and see what sticks"..
|
|
|
|
|
Add to that that some people are better with pictures versus others that prefer text versus the spoken word ...
Different levels of comprehension right from the outset.
|
|
|
|
|
I take it you are teaching then?
In my university days I had an eye opening experience across two courses. The first course we had an prof who would give us an assignment and award a C to work that did the strictest literal thing asked for, this prof asked us to always think about over delivering, optimizing, adding useful features, etc.
The second course we had a different prof. On the first assignment I actually forgot about it until the day it was due, so I rush coded the bare strict literal requirements given to us. I got 98/100 A. I was confused, adding to the situation most of my classmates (who had also been in the previous course with me) were receiving D's and F's... and they were pissed.
Turned out different profs wanted different things, the second prof was a true believer that we code to the requirements literally, period. The first not so much, he liked seeing extra effort.
I am just sharing this in reply to your post, as it may be that your students already had a prof like my second one?
|
|
|
|
|
Yours is an excellent description of college: close to 80% of a student's effort is determining exactly what a professor wants. The other 20% is simply providing that.
In of itself, that is not a bad thing; it is quite relevant to the remainder of life. In a job, you have to determine what the boss wants and adapt. At home, you have to determine a significant other's expectations. In each case, you get to decide whether to modify your behavior to remain in the situation or cut your losses and move on.
School is a little rougher. It is possible to drop a course if you cannot alter yourself to match the instructor's expectations, but sometimes, no other routes exist and you find you must change to meet your goal.
To the overall question, very few companies truly want "creativity". A unique solution is difficult for others to interpret and modify in the future. Ironically, creativity is also not a spontaneous, natural choice for most: indeed, as many have indicated, our elementary and secondary schools truly drown it out in most students well before college. The more a student remains in the sciences - computer, math, physics - the less creative he is. This tends to be the selling point of liberal arts: an exposure to more options that may not pertain to a future career, but will open the individual to different perspectives, and by association, be more "creative".
In short, don't expect a student to easily "think outside the box"; all have been taught from preschool to "color within the lines", "line up alphabetically", "be quiet and courteous". As members of society, we all follow a LOT of rules. Creativity can be curated, but it doesn't come easily.
|
|
|
|
|
Harold,
We are creatures of pattern recognition. For most of our lives, in school, and in math, we are asked to do X. If we do anything other than X, we get in trouble. It creates this literal interpretation trap, IMO.
My recommendation is to simply retrain them. Come up with 10 assignments with 3-4 answers that could be considered acceptable. And grade them out. The goal being to teach them how to think through what the problem is asking.
Again, IMO, students should be reading 10 times more code, and analyzing it, than writing it. But alas, they would barely do the reading they were supposed to do anyways. LOL.
I remember getting in trouble for the opposite. We were asked to write a C Program that would prompt for INPUT format (binary, hex, octal, decimal), and an OUTPUT format (same set). Then the user would type in a number in the input format, and our job was to output it properly in their output format. My implementation effectively did (scanf(inputFormat,value); printf(outputFormt,value);) and the teacher went all crazy on me, that I failed to write the code that converted the values, and that I did not show I understood... Blah Blah Blah. I told her it demonstrated that I understand that they are just integers, and the format is really a display/input issue.
So, the point is that the students should be learning by example. The example problems should actually have multiple answers. What you feel are good and bad answers, and why. Get the students thinking about things that cannot fit into memory. Our teachers would give us small test files, and then the TA would use these HUGE files that would never fit into memory. The program would fail, and we would have to go back and rewrite it. All Valuable stuff, IMO.
But I don't think it is fair to ask a NEW programmer to be a good programmer, without teaching the difference between the good and the bad. Without giving them the requisite examples.
Finally, it is fair to HINT the problems:
- You should not try to load everything into an array at once
- You could write this without using a BRANCH statement
- Extra Credit for making the loop count a variable
And the only other comment. Utilize the TA to solve the problems first. Most of them are
closer to the students. And if they need a hint, then the students will certainly need a hint.
Allow the TA to suggest rewording.
Finally. This might be crazy. But spend 10 minutes after class answering questions about the
homework assignment. I usually had 3-4 kids who just wanted to confirm I was okay with the simplest
answer. A bunch stayed after, confused and listening. And a few had those questions that made you think they were late for Basket Weaving ))) (or just confused)
It is IMPOSSIBLE to make a question Fool Proof.
I never said write it like that! (This sentence has 7 meanings, depending on what word you emphasize. And that is part of the problem).
|
|
|
|
|
I would say you're not writing the assignments correctly if you're not getting the results you anticipate.
Keep the assignment goals (requirements) clear and separate from tutor 'hints' at the anticipated solution. Better yet just point the students in the direction of the relevant topics that will help resolve the assignment.
If you want to emulate the real world, then they won't get hints at the solution. They will get vague requirements or specifications. Probably with contradictions. In this scenario the students that ask questions to clarify the gaps ought to find a path to a better grade. Unless they get lucky and guess right. That happens a lot too.
|
|
|
|
|
just curious. recently I start to use extension methods in my projects.
diligent hands rule....
|
|
|
|
|
I use them.
I dunno about "extensively". Let's say they are pretty common.
|
|
|
|
|
For common tasks, and when it makes sense. Absolutely!
|
|
|
|
|
Very much so! Done properly, they make the code so much more compact and readable.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Not only does proper use of extension methods do this it also "cleans" up the API. For instance, Visual Basic has a StrReverse(string) method, but the underlying dotNet framework's Reverse() extension method for System.String doesn't return a string. It returns an array of characters. I'll add extension methods for this type of situation.
|
|
|
|
|
As per Super Lloyd - I use them, I don't know about 'extensively', but, 'when it seems to make sense'
|
|
|
|
|
|
I have an assembly full of them.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
