XML

kent logo

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.


Question 1:

Submission reference: IN1477

How many swallows does it take to change a parallel process?

Answer 1:

Twelfty.


Question 2:

Submission reference: IN1489

Hi Peter/Fred, For the first assessment, when we're altering the print.stream proc, do you want us to sensibly deduce the colwidth based on the size of the numbers? Or are you happy with it staying as 10?

Answer 2:

The largest/smallest 32-bit integers are 2,147,483,647 and -2,147,483,648 respectively. Without the commas, therefore, the longest number of characters needed for such an integer is 11. So, keeping a fieldwidth of 10 will mis-align large negative numbers and cause large poisitve ones to run into each other if they happen to occur in adjacent columns of the same row. Play safe: use a fieldwidth of, say, 15 (which will let you have up to 5 columns in an 80 character wide terminal window).

Keywords: q1


Question 3:

Submission reference: IN1501

Hi, I am currently doing the first exercise on assessment 1, the part which requires us to alter the print.stream process to allow multiple columns. I was wondering, are you expecting us to define a new process for dealing with this, that we then use in print.stream process?

Thanks.

Answer 3:

No. The question says: "modify print.stream so that it takes an extra (VAL INT) parameter that specifies the number of columns of output produced". So, for this part we do want you to change the process code (header and body) of print.stream. It would not be easy modifying the stream of characters (BYTEs) coming out from print.stream in another process downstream from it.

Keywords: q1


Question 4:

Submission reference: IN1502

Hi, I am having trouble outputting the initial zero, in exercise 2 of the first assessment. I currently have the following for the body of my differentiate process:

  ...  omitted
At present, this is just outputting zeros every time. When I remove the <deleted> line however, it outputs correctly just without that initial zero. I'd be grateful if you could point me in the right direction as to where I may be going wrong. Many Thanks.

Answer 4:

Sorry – there was too much detail in the code in your question to pass on. See the note at the top of each Q&A page: "please do not simply paste in your code and ask what is wrong with it ...".

The only feedback I can give is that the code you sent does indeed produce nothing but zeroes. That is reasonably clear from looking at (and not running) the code ... I'm afraid it's just wrong. It can, however, be quickly corrected ... the basic approach is sound ... you just have the wrong circuit.

Keywords: q2


Question 5:

Submission reference: IN1504

For the filter in Assignment 1, does 0 count as a multiple of 5? ie; should we have the program produce 0, 1, 2, 3, 4, 6... or 1, 2, 3, 4, 6... when the filter is implemented?

Answer 5:

Yes, 0 is a multiple of 5 ... (5 x 0 = 0), :).

Keywords: q1


Question 6:

Submission reference: IN1505

Assignment 2 (q2) says not to re-type existing procs: "(e.g. the `Legoland' components 'numbers', 'integrate' ...)".

But I get "Error-occ21-q2.occ(144)- integrate is not a procedure" when I try to use integrate.

However, numbers works fine though, having printed its output to be sure.

Do we actually have to define a new PROC, in contradiction of our instructions, or am I really not getting something?

Thanks.

Answer 6:

Like numbers, integrate is in the course library (imported by the "#INCLUDE "course.module" line at the start of your q2.occ starter file). You must invoke it correctly, of course, with the correct number and type of arguments. Documentation for the libraries packaged with the standard occam-pi release are linked from the Co631 web page. The relevant library here is the one on demonstration networks. Others are demonstration cycles and a whole bunch of stuff for terminal i/o.

Keywords: q2


Question 7:

Submission reference: IN1511

Question 2 of the first assignment states that we will need a minus process and 2 others, but lists 3 (delta, tail and another I forget the name of). Should we use 3?

If so, should we choose from the list of 3 (since we already have minus)?

Or have I got it totally wrong? If I have got it totally wrong, could you please clarify? Thanks.

Answer 7:

You are asking about Exercise 2, which is the second assignment (not the first).

The question says you need two others from a set of three (delta, tail and prefix). So, don't choose three! Choose two ... you have to work out the right two, of course, and design the circuit that uses them (with the minus process that you still have to write).

You did have things wrong! Are you OK now?

Keywords: q2


Question 8:

Submission reference: IN1513

If there are several processes and they are all waiting for input from another in a parallel set of processes, such as:

  PAR
    procA (a?, b!)
    procB (b?, c!)
    procC (c?, a!)

Is there a way of instantiating c, for example, for the first run to kick it all off because I think that's what's causing deadlocks.

This question relates to a problem I am facing in Q2. Thank you.

Answer 8:

First: you are right in that if you connect n processes in a ring network and each process then waits for input from the one upstream, the result is deadlock. Everyone is waiting for someone to do something!

We could eliminate that immediate deadlock by injecting something into the ring (e.g. with a prefix process). With your example, the same thing can be done directly by doing that prefix explicitly - e.g. kicking something off on the 'c' channel:

  PAR
    procA (a?, b!)         -- one process
    SEQ                    -- second process
      c ! something        -- still second process
      procB (b?, c!)       -- still second process
    procC (c?, a!)         -- third process

However, Q2 is best answered without tricks like this!

Keywords: q2

Referrers: Question 10 (2008)


Question 9:

Submission reference: IN1518

Could someone post this week's class exercises? Thanks!

Answer 9:

You were being helped through the second Assessment (Exercise 2). Details are given in the "What's Happening ..." section of the module web page.


Question 10:

Submission reference: IN1512

For Q2, is there a way I can identify the cause of deadlocks in windows?

I've swapped out a component (to test that most of the proc works), got parameters right and everything for what I swapped out, and yet I keep getting a deadlock.

Answer 10:

I'm afraid there is currently no debugging support for deadlocks in occam-pi (under either the Transterpreter or the kroc compiler).

Your system should be designed free from deadlocks, so that you don't have to debug for it! However, encountering deadlock at this early stage will be a very good learning experience. Deadlock happens in occam-pi for two reasons only:

Keywords: q2


Question 11:

Submission reference: IN1526

Is the differentiate process the only part of Assignment 2? It just seems too easy.

Answer 11:

Yes!

It's not meant to be hard. Working out a correct circuit means you understand how to design and reason about concurrent process networks. You have achieved one of the primary learning goals of this module, :).

Keywords: q2


Question 12:

Submission reference: IN1535

In q4, with pairs set to differentiate, if integrate is reset then pairs will give a negative number.

This is of course accurate, however the question states: the modified pairs becomes a `differentiator', undoing the `integration' effect of the process immediately upstream so that we see the natural numbers sequence. Should we employ some method to enable this to return the natural numbers sequence immediately, or is the negative number acceptable?

Answer 12:

Regarding the pairs process, Exercise 4 says: "Note: 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." So yes, the odd negative number just after the reset you describe is acceptable, :).

Keywords: q4


Question 13:

Submission reference: IN1536

It was mentioned in a seminar that there is a quick solution for doing basic print to screen, for basic debugging in occam, akin to System.out.println() in Java.

I appreciate that test-rigs are the proper way to go, but they are a bit overkill when all one would like to do is inspect a variables contents e.g. corner-cases testing etc. I am using Kroc.

Answer 13:

The code below will work in KRoC, as you are using, but will not work in the Transterpreter (yet!). At the start of your program, somewhere near the #INCLUDE directives:

  #PRAGMA EXTERNAL "PROC C.out.stderr (VAL []BYTE str) = 0"
  #PRAGMA EXTERNAL "PROC C.out.stderr.int (VAL INT n) = 0"

These make available two routines defined in the run-time system for outputting simple strings and integers. To use, e.g.:

  PROC debug (CHAN BYTE kyb?, scr!)
    INT x:
    SEQ
      x := 42
  
      C.out.stderr ("Hello world! x happened to be ")
      C.out.stderr.int (x)
      C.out.stderr ("*n")
  :

As you point out, test rigs (or other screen-connection mechanisms to get program output) are the better way, but can be awkward sometimes. Something that hasn't been covered in the course yet (see slides 2..26 of the shared-etc) is the ability to have a shared screen channel, e.g.:

  #INCLUDE "course.module"
  
  PROC do.stuff (VAL INT x, y, SHARED CHAN BYTE scr!)
    SEQ
      -- maybe do something useful with 'x' and 'y' :)
  
      -- debugging
      CLAIM scr!
        SEQ
          out.string ("Hello world! x happened to be ", 0, scr!)
          out.int (x, 0, scr!)
          out.string ("*n", 0, scr!)
  
      -- maybe do something else
  :
  
  PROC my.program (CHAN BYTE kyb?, SHARED CHAN BYTE scr!, CHAN BYTE err!)
    SEQ
      CLAIM scr!
        out.string ("Hello, shared-screen world!*n", 0, scr!)
      -- now run 3 processes, all writing to the SHARED screen channel
      PAR i = 0 FOR 3
        do.stuff (i, 42, scr!)
      -- without the SHARED attribute, the above would be illegal
  :

This is [amongst many other things!] a handy way to share the screen (or error) channel for debugging purposes. Note the use of CLAIM blocks around outputs to the channel. Some other examples of shared-channels can be found via the shared-channel keyword. This is standard occam-pi and will work in the Transterpreter.

Keywords: debugging


Question 14:

Submission reference: IN1539

Is there an abs() function/process in occam, as for the life of me I can't find it in the library documentation :).

Answer 14:

Oddly enough, no, there is not! Perhaps we should add one just for the sake of completeness? But you can write your own quite easily:

  INT FUNCTION abs (VAL INT v)
    INT r:
    VALOF
      IF
        v < 0
          r := -v
        TRUE
          r := v
      RESULT r
  :

This is an example of an occam-pi function declaration (slides 88..93 of shared-etc). It can be used in the expected way – e.g. "x := abs (i)". Bear in mind that this will cause a run-time error if you were to ask for "abs (MOSTNEG INT)".

Keywords: abs


Question 15:

Submission reference: IN1545

Duplicate of my question originally posed on the forum (I later realised that the forum was not being used).

In assessment 3, the last task:

‘+’ : double the rate of output of lines of text (up to a maximum of 1024 lines/second)

‘-’ : halve the rate of output of lines of text (down to a minimum of 1 line/second)

Do we determine max and min speed just by observation, or do we have to actually count the number of lines per second?

Answer 15:

Ah!! I see your problem now – sorry, an earlier answer did not.

To double or halve the speed, we need to know the current speed! The question does not say what initial speed to use – this is about to be fixed, :). Please set the initial speed to some value of your choice, within the min and max ranges given in the question (e.g. 32).

Your process should compute the delays necessary to control the speed. You may assume that the system can produce lines faster than the maximum (1024 per second) specified and your task is to constrain it. Actually, the transterpreter will have difficulty delivering more than 256 lines per second ... no matter. Your delays should still be computed so that, if you run your program on a faster platform, the controlled speed will increase to either 1024 lines per second or whatever the maximum happens to be.

Note: with the transterpreter, a delay of 0 microseconds will actually give a delay averaging 5 milliseconds. With the kroc compiled native code, the delay will average 0.5 microseconds. For both, a delay set to -1 yields no delay at all. Sorry, this is a subtlety of the runtime support. So, when the question says: "instance it with a delay of zero", change that to: "instance it with a delay of -1". I'll fix that as well.

By the way, if you wind the speed right down to one line per second, when you reset the numbers generator (or the integrator or pairs), the system outputs around 3 or 4 more lines (i.e. takes 3 or 4 seconds) before the changes resulting from the reset happens. This effect is less marked for the integrator and pairs resets. This is not an error on your part, nor is it due to an inefficiency in the occam platform – it is a property of the (exercise 4) system itself. Can you see why?

Keywords: q4


Question 16:

Submission reference: IN1546

Hi, I'm struggling to avoid deadlock in Q4, specifically the "freeze control" bit.

I understand the problem I'm seeing (I think): if you hook up "print.streams" to feed data into monitor, then it creates a "circle of wires" and it is feasible that monitor could be trying to send a reset signal to numbers, but numbers would be trying to send to print.streams which is trying to send to monitor.

The problem is to think of a way around this. Is it acceptable to simply modify print.streams to accept a "freeze" signal the same way numbers2 and its friends do? That seems the most logical and consistent thing to do, but it also seems bad to fiddle with existing processes.

If that idea is "bad", can you offer any sort of hint as to the "proper" answer? Thanks. :)

Answer 16:

Your analysis of the deadlock sounds quite plausible, but keeping the existing "print.streams" process as it is would be sensible, unless there is no other sensible solution. If the deadlock is in that loop of processes, then all you need to do is (somehow) break that cycle. It sounds like you have your "print.streams" feeding data back into the "monitor", which is then doing two jobs: handling keyboard input, and handling output from the program. Which is where things start to get a bit complicated.

So ... don't do that! Just keep the "monitor" process handling keyboard input (and sending other signals appropriately). Separately, add some sort of "freeze.control" process, similar to the one in Exercise 3, whose single job it is to freeze the output of "print.streams" going to the screen. That way, you add one extra process to the top-level network, which doesn't increase the complexity of any individual component :-).

There may still be opportunities for deadlock (e.g. if trying to reset numbers (and others) when the output is frozen), about which there is a note about in the q4.occ file. However, that will be impossible if your follow the specification (of the required reaction to an 'f') in the question (bottom of page 5 in more-exercises).

Keywords: q4


Question 17:

Submission reference: IN1549

I've moved onto Q4 finally, but I am completely confused by this:

  -- The squares pipeline from the `legoland demonstration' (see "demo_nets.occ"
  -- in the "libsrc" directory, which contains the "course.module" sources) is:
  -- ...
  -- Unpack and rebuild this squares pipeline and pipeline it into print.stream
  -- to make a system that outputs perfect squares - one per line:
  -- ...

It sounds like we have to change squares in the course files, which I can't even find. Surely I'm misreading this.

Answer 17:

The last portion of text in the comment you quote (and also the first line of Exercise 4) gives the answer – the key word is "rebuild":

  -- Note: we don't need to redefine any of the processes defined in these files.
  -- They have already been defined and pre-compiled.  The #INCLUDE directive,
  -- at the start of this file, gives access to them.

So, no, you are not expected to change these. However, you will need to write new versions of some of these (simple) processes to incorporate the reset channels as required.

But you are not expected to modify the course files to do that :-). The simplest way is to re-type the code from the Legoland catalog (slides 88 and 95 from the basics slides) and rename appropriately (e.g. "numbers.reset" for your modified "numbers") when you add in and deal with the reset channels.

For the first part of Exercise 4, the text explicitly points you to that slide 95 as a model for the required code – you just have to add one more process to the pipeline.

Alternatively (and only if you are a very slow typer!), you could copy the relevant sources from the "course.module" library. For those working with the kroc system, these sources are in your downloaded release: modules/course/libsrc/demo_nets.occ. Otherwise, they are on raptor: /courses/co631/libsrc/demo_nets.occ (from Windows, this looks like: S:\courses\co631\libsrc\demo_nets.occ, assuming your S: drive is mapped to '\\raptor\files').

Keywords: q4


Question 18:

Submission reference: IN1551

Hi there, I am having difficulty in implementing the toggle functionality for the pairs process. Am I right in thinking that the way to go about this to create a new proc and add that as a subcomponent to the pairs process? So, in effect not altering any of the other components such as the plus process? So, then the new component would switch between passing data to the existing plus proceess and a newly created minus one, depending on whether there has been an interrupt?

Also, does our program need to allow for capital letters being inputted? For example should entering 'I' having the same effect as entering 'i' ? Or should capital letters simply be ignored? Thanks,

Answer 18:

Yes to your first and second questions: the best way is to introduce another that enables the additional functionality and to leave the existing processes untouched. No to your third question: adding a switch process and a minus means at least two extra processes ... and it's tricky ... two streams of data flow would have to be switched. It can be done directly with one extra process ... and, once you see it, it's very easy, :). But you can, instead, just bring the reset line into a modifed plus and which flips its behaviour when triggered (which is the first suggestion given in the question).

If you like, you may treat upper and lower case characters the same. No extra marks though!


Question 19:

Submission reference: IN1552

Hi, I was wondering if you could tell me whether for modifying the pairs process in q4, do you expect us to being using one of either the substitute or the greater processes from the Legoland catalogue? Cheers.

Answer 19:

Sorry – that's for you to work out! Using one (not necessarilly either of the ones you mention) of the processes already given in the slides is only one (possibly the best) approach. The question suggests another: plug the reset line into a modified plus process (that would then be better called something like plus.minus).

Keywords: q4


Question 20:

Submission reference: IN1554

Could you clarify which upper boundary I should be using for the number of lines per second? In Question 15 (2008), you specify a maximum of 1024 lines, in the assessment PDF file it is 256 lines, and in the comments at the top of q4.occ it is given as 128 lines per second. I understand that the Transterpreter will have difficulty delivering more than 256 lines per second anyway, but I wouldn't want to lose marks for not correctly implementing the specification.

Answer 20:

Sorry – our inconsistency! Any of the upper bounds mentioned is OK. We will edit all the files to bring the limit to the same number (probably 256).

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:22 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.