|
CO538 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.
Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.
Submission reference: IN1477
How many swallows does it take to change a parallel process?
Twelfty.
Submission reference: IN1895
Error-occ21-q2.occ(70)- cannot open file "course.module" WHY?! I've re-run the batch file, tried opening a fresh q1 file, and still the same problem occurs.
This suggests that the version of the Transterpreter IDE you are running does not have module support. This usually means the software is out of date. There are two common explanations for this:
Submission reference: IN1894
Will you be putting up a lecture outline showing which slides were covered in which lectures? Just so we can read up more after the lecture if we fall asleep during?
Sorry, we were a bit slow in doing this. It's happening now. Thanks for the nudge!
Keywords: website
Submission reference: IN1899
I'm currently working on Q3 and have managed to get the output to the screen to freeze when 'f' is received. When the next key is pressed, numbers are again put to the screen but the process has kept on running and therefore some numbers are not printed. Is this correct or do I have to stop the numbers from incrementing (any pointers on how to do this would be appreciated)?
It's not correct!
The question (Exercise 4) in the "more-exercises" sheet does say: "from wherever it left off". Keying 'f' should freeze screen output, which should resume from where it froze when the next character is entered.
It's actually simpler to program the above behaviour than to leave the demo process running without printing its output. Remember that a channel cannot lose any messages: if the receiver does not input, the sender just blocks (until such time as the receiver does input from the channel ... at which time, the message comes across). So to lose message from demo, we would need to program control explicitly to continue to take in messages but not forward them! To block messages from demo, just don't listen to it – simple!!
Submission reference: IN1898
When it comes to flipping the adder within the pairs process to a subtractor, it states in the q4.occ starter file that after we do this: "...we see the natural numbers sequence".
In Exercise 4 in the "more-exercises" sheet, it states: "in its flipped mode, the modified pairs2 process becomes a differentiator so that the stream of numbers produced are the same (bar a bit of slosh) as those coming from numbers2".
This means positive numbers must be produced. However, back in the q4.occ file it also states: "The first 'p' zaps the adder process within pairs so that it becomes a subtractor, taking the numbers arriving from the tail process from those arriving directly from the delta".
This means that negative numbers are produced.
Unless I am doing something wrong, which is entirely likely, do these two statements not mean different numbers will be produced? Which is the right one if this is so? Does the aforementioned "slosh" mean the minus sign?
You are not doing anything wrong!
This is our mistake, for which we apologise. The quote you gave from the q4.occ starter file tells you to do the subtraction the wrong way around. Stupidly, this was a known error – see Question 18 (2006). It was corrected in the starter file but, sadly, an old version has crept back in!
The q4.occ starter file has been corrected again – hopefully, we have better version control in place now! The corrected file can be found on raptor at:
\courses\co538\exercises\q4.occ
Note: when marking this assessment, no marks will be lost for programming these subtractions the wrong way round (i.e. for doing what the q4.occ starter file specified) – even though that leads to (a decreasing sequence of) negative numbers. Apologies.
Keywords: q4
Submission reference: IN1900
Would you mind putting up the model answers q1 and q2 now the deadlines have passed? Thanks.
These are available on raptor at:
\courses\co538\answers\a1.occ \courses\co538\answers\a2.occ
See also:
\courses\co538\answers\e1-ans.occ \courses\co538\answers\no-bugs.occ
Keywords: model-answers
Submission reference: IN1901
For Q4, the pairs2 process is it okay to write a new toggle process that upon a 0, say, being put down its reset channel, it outputs the opposite of values that arrive (instead of the same). For example, if 2 was input, the opposite (i.e. -2) would be output?
Also is there somewhere we can find an example of the output we should get upon the flip being activated?
That toggle process sounds a really good idea!
Here's output from the model answer:
77 3003 6084
78 3081 6241
79 3160 6400
80 3240 6561
81 3321 6724 <-- 'p' keyed in round about here
82 3403 6889
83 3486 84
84 3570 85
85 3655 86
86 3741 87
87 3828 88
Keywords: q4
Referrers: Question 8 (2010) , Question 14 (2010)
Submission reference: IN1902
For Q4, why does flipping to minus within pairs2 result in a number being generated that is 1-bit from the correct answer? Now that I've implemented speed.control the number being generated by pairs2 is 1 from the correct answer if it's doing addition and 2 from the correct answer if it's doing minus. I've tried putting speed.control in different places but either delay() functions strangely or I deadlock (trying not to give too much away). I'd like to learn more about this strange behaviour so I can fix it with my current set-up. Any hints? :)
Check the model solution output given in the answer to Question 7 (2010).
It sounds like you are doing something wrong. Does the above allow the "1 from the correct answer" you mention? Which bit in the number is "1-bit from the correct answer"? "2 from the correct answer" sounds definitely wrong.
But it also looks like you are doing something right! Try mailing your code to one of us. We won't correct it but will give you a pointer if we can.
Keywords: q4
Referrers: Question 9 (2010)
Submission reference: IN1903
In relation to Question 8 (2010): I get that output if I remove speed.control. The only other instance I've got it to work correctly is putting speed.control before/after my freeze process. The problem is that delay() acts strangely (very slow compared to invoking it from print.streams).
I'll have another good crack at it tonight and if I fail I'll email you :)
If you put the speed.control process after the output from print.streams, it'll be controlling the delay between each character sent to the terminal. As terminals are line-buffered (unless you explicitly FLUSH each character), you will have to wait some time before each line appears (the delay per character multiplied by the number of characters in the line).
If the delay is called from within print.streams, then you'll be getting the delay for each line of output, rather than each individual character, so it will generate screen output faster.
Rather than clutter up print.streams with additional speed control logic to adjust delay times, keep that logic separate in your new speed.control process but get it to control the speed of (any) one of the channels going into print.streams.
Note: using the delay process to force delays in the speed control logic has the following problem. Whilst the delay is on-going, the logic cannot respond to further instructions – such as to speed up. For instance, if the speed has been wound down to one line per second and we key in a '+' to make it go faster, the keystroke cannot be responded to until the end of the current delay period and – with one second intervals – that will feel very unresponsive. Consider how to solve this!
[Hint: your speed,control must already be ALTing between the input channel (whose speed it is controlling) and a control line (for adjusting speed). Rather than use a delay somewhere, get it to ALT between the input channel, control channel and a timeout guard. With suitable logic, it can now be programmed to respond immediately to any control signal, regardless of how long it is till the next timeout.]
Keywords: q4
Submission reference: IN1904
Will the model answer for Q3 be available to look at before the Q4 submission deadline?
Sorry, no! Q3 is a warm up exercise for Q4. The freeze control it asks for can be reused intact in Q4.
Submission reference: IN1905
Using the Transterpreter, if you send a BELL down the error channel, is it meant to actually do something, because for me it does nothing or is that just the Transterpreter?
The BELL character is ASCII code 7 (known as "bell"). On old teletypes, when this was received it actually rang a real bell. On later video terminals, it caused a beep sound. In terminal windows (on modern desktop screens), what happens depends on how your terminal emulator is programmed (sometimes this is user configurable). Many effects are possible:
The terminal window in the Transterpreter JEdit occPlug does the third action above (screen flash) – at least, that's what it does on my Macbook.
Here's a short program (test-bell.occ) that you can cut-and-paste and compile-and-run:
--------------------------------------------------------------------------------
--** Test BELL on screen and error channels.
#INCLUDE "course.module"
--* the main process
--
-- @param keyboard The standard input channel (stdin, in Unix-speak)
-- @param screen The standard output channel (stdout, in Unix-speak)
-- @param error The standard error channel (stderr, in Unix-speak)
--
PROC test.bell (CHAN BYTE keyboard?, screen!, error!)
BYTE ch:
SEQ
-- test BELL on screen channel ...
out.string ("screen: this line will end with a BELL (press a key) ...", 0, screen!)
screen ! FLUSH
keyboard ? ch
screen ! BELL
screen ! FLUSH -- the effect of the BELL, if any, happens now!
out.string ("*c*n", 0, screen!)
keyboard ? ch -- wait for keypress. This is to let the terminal
-- emulator complete its reaction to the BELL on
-- the screen channel. Otherwise the terminal
-- emulator mixes that up with the following text
-- sent to the error channel. By default, screen
-- and error channels are crudely multiplexed to
-- the same output device. From Unix, they can
-- be separated.
-- test BELL on error channel ...
out.string ("error: this line will end with a BELL (press a key) ...", 0, error!)
keyboard ? ch
error ! BELL -- the effect of the BELL, if any, happens now!
out.string ("*c*n", 0, error!)
:
--------------------------------------------------------------------------------
Note: the screen channel needs a FLUSH in order to force out text that doesn't form a completer line (no line-feed character). The error channel, however, flushes every character sent automatically.
Referrers: Question 15 (2010)
Submission reference: IN1906
To implement the freeze control, are we allowed to add a new process in Q4? This process would communicate with the monitor process.
Yes. In general, it's a good idea to implement new functionality with a new process!
The new process for freeze control can be identical to the control process from Q3 (just implementing the freeze part – not the other stuff provoking deadlock etc.).
Keywords: q4
Submission reference: IN1907
Hi, For the freeze control in Q4, can I change the whole network diagram from the previous modification or should I stick to the old diagram, but with new processes included??
Well, you may design a different network diagram if you have a better way of arranging things. However, the question asks for features to be added incrementally – e.g. when adding freeze control, the previous reset controls must be retained.
Process orientation enables safe incremental design and implementation. Because the internal logic and data structure of each process is isolated (strictly private to the process), processes only impact on each other when they communicate (or, we will see later, barrier synchronise) and that can only happen with the explicit agreement of the processes involved. So, nothing can happen to a process behind its back! This means that as we add processes to a network, only those parts of the network to which they are explicitly connected (by channels or, later, barriers) are affected – the rest of the network behaves as before.
There is one caveat to the above. Whilst plugging in new processes cannot alter the behaviour of existing ones (and the sub-networks they form), we do have to ensure that the network overall remains alive. Any modification to a network may introduce a possibility for deadlock and we must take care not to do this! We will be teaching design rules that guarantee freedom from deadlock ... but these are not complete (i.e. they don't cover all the designs we need to make). For the others (e.g. the dining philosophers' college), we need to make individual analyses to remain safe. It is a challenge to make such formal analysis routine ... and, if time, we shall have a go in this course! :)
So in answer to your question here, we recommend incrementally modifying the old diagram (as has been done in the exercise sheet in the four developments of the q4 process network) by connecting in new processes with the necessary behaviour. It's the simplest way to go – for both the freeze and the speed controls.
Keywords: q4
Submission reference: IN1908
In Q4, while testing I noticed that when pressing 'n' there is a delay between my reset in the increment:
0 0 1 1 1 4 <-- 'n' key pressed 2 3 9 3 6 16 4 10 20 0 10 21 <-- finally! 1 11 24
This isn't allowed, is it?
Yes, it is! See Question 7 (2010).
How quick the reaction to your reset is depends on how much is already
in the pipeline to the screen ahead of where the reset is processed.
The 'n' keypress is processed inside inside numbers2,
whose numbers generated in future start again from 0.
Ahead of that are numbers already generated in a delta,
integrate2, another delta, pairs2 and
print.streams.
Your reset clearly can have no effect on those numbers and you have to watch
them come out of the system before you see the reset
If your screen output is set very slow (e.g. one line per second), there will be numbers backed up in all stages of the pipeline and the response from the system to the reset will be delayed (as you observed). If your screen output is very fast (and it would need to take around a million lines per second - unfortunately, your terminal window cannot manage that), the pipeline will be empty and the response from the system to the reset will be immediate. occam-pi is good for real-time control.
Keywords: q4
Referrers: Question 22 (2012)
Submission reference: IN1910
In the speed.control process when it comes to outputting BELL nothing seems to happen. I have also changed my code so that whenever I press the '-' key it outputs BELL without doing anything else but this still has no effect (no inverting of colours/screen flash etc). I'm using a Windows machine so in reference to the Question 11 answer this may be different to a Macbook.
Sorry – this seems to be a bug in the Windows version of the Transterpreter. I finally found a Windows machine and tried the model answer. As you and others have observed, no reaction to BELL, :(. The problem is that characters sent to the error channel are not automatically flushed as per spec (and as we have told you, for example at the end of our answer to Question 11 (2010))!
This is only a problem with the Transterpreter on Windows. On the Mac – and, probably, Linux (I've not tried that yet) – the error channel correctly flushes every character. The kroc run-time also manages the error channel correctly.
We will get this fixed. Meanwhile, wherever you send BELL to the error channel in your solution to q4, follow this with a FLUSH – e.g.
error ! FLUSH
Apologies.
Referrers: Question 16 (2010)
Submission reference: IN1912
Hello, my bell isn't working ...
If ALL my code does is output a BELL on the error channel, it works fine! But when I add my processes in, to run AFTER outputting the BELL (SEQ), nothing happens :/
I don't understand! :((
Sorry – see the answer to Question 15 (2010). You probably have the same trouble and the same fix should work.
Submission reference: IN1911
Hi, I'm currently working on step 3 of Assignment 4 – changing pairs to subtract rather than add. Without wanting to go into too much detail I've got both a modified pairs process and another new process which uses a boolean flag to toggle. The last time I used a flag in such a way it was pointed out to me that it was unnecessary and I'd missed an alternate way of doing things.
Am I going down the wrong road again with regards to this? Thanks.
Your solution sounds good.
For many cases, remembering state in global variables leads to more complex code than just letting process logic flow through the states (where the state of the process is represented by where the logic has reached, rather than data in a variable).
However, for the toggle process you describe, using a boolean flag (declared global to the loop) is probably simplest.
There are no complete rules for things like this that cover all circumstances we encounter – only guidelines. The guideline two paragraphs above often works simply and elegantly (and is often missed by too much thinking along OO lines) – just not here. Always look for the simplest solution.
Keywords: q4
Submission reference: IN1913
Hey, When I add my speed.control before the print.streams method, all of the lines get outputted at once for some reason.
Say I am at 2 lines per second, rather than 1 line being outputted at 0.5 seconds and then the next being outputted 0.5 seconds later, 2 lines are outputted each second.. :( Is this what's supposed to happen? :<
Also, not sure if outputted is a word, but if it isn't it should be >.> Thnx!
Sorry – that's not supposed to happen! I'm afraid there's something wrong in your speed.control logic (probably).
Sorry – outputted is not a word. The word you are looking for is: output!
Keywords: q4
Submission reference: IN1914
I am wanting to use the various raster graphics libraries to do my dining philosophers with, but the problem I am having is that the SDL raster interface (http://occam-pi.org/occamdoc/sdlraster.html) uses channels of type "RASTER" to output the graphics on the screen but all the other raster libraries use channels of "INT[][]".
I have looked through the documentation and cannot find a way to convert the INT[][] to RASTER, unless I first output it as an image file (which is hardly efficient when doing animations).
Is there a process that will convert the INT[][] to RASTER or some other way of displaying the images that uses INT[][]?
Have you tried compiling code that uses both of these? The RASTER type is defined to be a "MOBILE [][]INT". Although we haven't taught you about MOBILE types yet (which use a movement semantics rather than copying semantics), you should be able to pass RASTERs to procedures that expect [][]INT parameters (although not vice-versa). Within your own code, it'd be more efficient to use things like "CHAN RASTER" rather than "CHAN [][]INT", as the latter will take an appreciable amount of time to copy large graphics windows. We'd recommend just trying to compile your code as-is, and if you run into any specific type errors, ask here again :-).
Submission reference: IN1915
I have a couple of questions regarding the speed.control modification in Assessment 3.
If you halve the initial speed of the system right down to 1 line/second, the system won't let you go any slower than 1 line/second, as specified. But if the speed is doubled at any point by pressing '+' before slowing it right down like this, the slowest the system can output becomes 1 line every 2 seconds. Could you possibly give me any indication why this might be?
Early on in the assessment pdf, when it talks about generalising input to the reset processes, it mentions that monitor should only output zeros. But I use different integer values on a single channel to discriminate between plus and minus signals in my speed.control implementation. Is this acceptable or should I use a plus channel and separate minus channel?
Thanks! :)
This is not entirely unexpected behaviour in some cases. Not having seen your code, I'm guessing that at some point you cap the integer at the top/bottom to impose the limit. However, the maximum value is probably not a power-of-2 multiple of the initial value, which is why you get this slightly odd behaviour — one sequence of integers as you speed up, which is capped when it reaches the maximum speed, and a different sequence of integers as you slow down (and vice-versa). Hence you get this behaviour. It would be better if you could fix it though — the fact you get the behaviour you describe suggests something is slightly wrong somewhere. Try building a test-rig for your speed.control process to see what it's doing.
What you have is fine — the zeros are only for resetting the number-processing components. The point is that you should be able to reset numbers or integrate to any value, i.e. the reset component used in them is general.
Keywords: q4
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
