This was given to me by one of my HL students. It’s a set of condensed notes on Java. You might find it useful.
In a recent discussion with the IBO about mastery factors I was told that students should show at least TWO examples of each master factor in order to claim. This is not documented anywhere, and is probably not official, but please bear it in mind and update your mastery index accordingly.
One of the past paper questions in the File Organization presentation asks what you would do if you had 10,000 large data objects that you wanted to sort, but you couldn’t read them all into RAM at the same time because they are too big.
The answer to this is to read small batches of data into RAM, sort them there using some sorting algorithm like quicksort, and then write them back to the disk in order. Do this repeatedly and you will have, say, 100 batches of 100 sorted objects. Then you can take pairs of 100 objects and merge them into 200 sorted objects, then take pairs of 200 objects and merge them into 400 objects, 800, 1600, and so on until the whole data set is merged.
The point is that you can merge two sorted lists without reading the lists into RAM first. This is a useful technique.
See below for a detailed response. My advice would be to reference your Java textbook both in the bibliography, the mastery index and the source code where you label the code for which you are claiming the ADT mastery factor.
My post to the IBO Computer Science forum:
From the 2006 Subject Report:
Candidates must reference any code that is taken directly or indirectly from another source – this will be the usual case for an ADT as it is extremely unlikely that a candidate will write an ADT from scratch.
Extremely unlikely? Is it? Surely any reasonable HL student is expected to be able to write the code for a Linked List or Binary Tree from scratch. Are students really expected to reference where they got that information from?
I’d interpret this as meaning that a high school student is not likely to “invent” the concept of a Linked-List. They will certainly have seen examples in class or in a text-book. I think the normal situation is that HL students have lectures where the teacher explains how a Linked-List (or other ADT) works and shows some sample code. Then the students are going to write their own code, part of which will be similar but not identical to the code they saw. I normally show my students how to create the list, how to code the NODE class and how to add nodes at the beginning and how to traverse the list. They do the rest themselves, and they don’t code the simple stuff exactly like I showed them. I can’t see any reason that they need to reference this, unless they copy a lot of code exactly, letter-for-letter. I suppose they could write something like “The linked-list is based on the discussions we had in class, but I wrote the code myself.”< /p>
I’ve marked a lot of dossiers and I have never seen an HL student acknowledge the source of a Linked-List or other ADT. I do occasionally see dossiers where they have downloaded some other library code, like something to do web communication, and then ackowledged the source.
The real offense would be a copy-and-paste from a web-site – or even worse from another student. I have seen that before. Then they need to acknowledge the source, and they won’t be awarded mastery factors because they did not write the code themself.
The short answer? Yes, they are allowed to read books. “Writing from scratch” presumably means typing code on a blank screen or in an exam without notes. I agree with you, any capable HL students should be able to do this. And I hope they are not going to credit their teacher when writing exams.
These contain a huge amount of information that is not available in the guide or anywhere else, particularly on the subject of the Program Dossier, and what each section should contain, and what counts for each mastery factor.
They are essential reading.
I read something that Dave Mulkey wrote in this forum in 2009 on the subject of ADTs as a mastery factor:
As I said above, my students never try to get 4 marks, and usually not 3. They just implement the most normal features with normal error checking and that’s sufficient for 2 marks. If they really need 4 marks (say there are no files in the application), it’s easier to implement 2 different ADTs and get 2 marks for each.
Huh?! Can you do that?! It would be great news if so, but I think it needs to be made much clearer in the guide.
That is certainly a good question. I’d agree this is not thoroughly explained in the Guide.
The May 2006 Subect Report says:
“Candidates may gain some credit for all ADTs which have been properly documented, implemented and demonstrated to work via hard copy. Four such ADTs which all work only partially may gain the full 4 marks (although it does seem a hard way to go about it).”
I recommend reading the Subject Reports – they contain lots of clarifications. In case you have a real life and don’t want to read all of them, I recommend May 2006 and May 2009 as being particularly helpful. May 2009 has a nice chart about Mastery Factors, which is short, clear and useful.
My students don’t create 2 ADT’s very often, but I have given “partial marks” to some of my students for multiple ADT’s, as well as giving them as a moderator. I’ve never heard any complaints about this. Still, what I’m saying is not “official”. If you want an official answer, you can have your IB Coordinator send an official query to the IBO and you will receive an official and binding answer from the office.
Awarding Mastery marks is a subjective issue, with only broad guidelines to help standardize things. The best thing you can do for your students is to clearly explain your thinking, on paper, and include this with the samples that go to the moderator. It’s a lot easier for a moderator to support your marks if they understand why they were awarded, rather than trying to guess what the teacher was thinking. It’s not necessary to explain ALL the marks – e.g at SL if there are numerous IF..ELSE.. constructs throughout the program, a simple list of page numbers/line numbers of a few of them is sufficient. But the ADT marks are quite variable across schools, so a brief explanation from the teacher is very helpful. Also, the students are expected to “document” (explain or discuss or justify) their Mastery aspects. In my experience, the students don’t tend to write very clear (or even correct) explanations, so the teacher’s comments are a big help. If you read those Subject Reports, you’ll see the word “justify” used repeatedly. I think that sounds a bit like arguing a case in a court of law. I prefer the word “explain”. But the Subject Reports are written by the Senior Moderator and/or Chief Examiner (as far as I know), so I would take those suggestions seriously.
From the May 2006 Subject Report:
“Perhaps the biggest issue with mastery aspects is the frequent lack of documentation or inaccuracies in documentation. These cover several aspects such as administrative errors, lack of hard copy output and lack of discussion of the need of the solution for certain mastery aspects.”
The key point there is “the need of the solution for certain mastery aspects”. In this case, I think the statement in the 2010 Guide (p 65) is actually clearer:
” “Non-trivial” means that the programmer must demonstrate that the program benefits from the use of the [mastery] aspect.
Where one aspect includes others, all are credited (always provided that the use is non-trivial, well documented and appropriate).”
I like the idea “benefits from”. Most importantly, the program must actually USE (execute) the code that was written. I’ve seen a number of dossiers where a perfectly functionaly Linked-List has been coded, but is never actually executed. Even more commonly, methods or ADT’s are coded and then executed once, but for no particular reason. Hence the application did not actually “benefit” from using that code.
The worst error (sorry, I’m getting carried away but I must say this) that I’ve seen repeatedly is incorrect use of recursion. Students know they can get a mastery mark for using recursion, so they code a “recursive” method by having it call itself instead of using a loop. Unfortunately, in several cases the recursion was coded incorrectly and never terminated, and the students turned in dossiers with no sample output because the program locked up in an infinite loop. Clearly, those programs did not “benefit” from the use of recursion.
Perhaps that was “too much information”. Hope it helps anyway.
Parsing a text file or other data stream
Using the built-in wrapper classes such as Integer and Double with their methods parseInt(String) and parseDouble(String) is considered a trivial use. An input data stream, such as from a file, the keyboard or a network, which consists of character bytes representing text, should be split into separate components in some way. The use of String.split() or java.util.StringTokenizer is acceptable. The components must then be recognised as belonging to a particular set, each with a particular processing requirement. Taking lines from a text file in csv or similar formats and creating record-style object instances is an acceptable use. In this type conversion using Integer.parseInt() etc is fine. The formats and the process of interpretation must be discussed in the data structures and algorithms of stage B.
The question of the recursion mastery factor has cropped up a few times on the IBO computer science forum and if you are considering incorporating it into your dossier you need to bear these points in mind:
- Don’t include recursion unless it is appropriate. It should be used for quicksort, or for binary tree traversal, and that is about it. If you have any other use in mind, please ask me first.
- Don’t use recursion to implement a while loop, eg to keep asking the user for input until they type ‘x’. This is inappropriate and can actually cause a stack overflow.
- Don’t use recursion where an iterative method would be easier. The whole point of recursion is that it can provide very elegant solutions to what would otherwise be quite complicated procedures. If you don’t believe me, try traversing a binary tree iteratively.
- Even if you do use it for sorting, make sure that ‘sortability’ is a success criterion. Otherwise it can look like you’ve only included a sort to gain the mastery factor, and that is not really the point.