XML 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: IN739

this is a test question for CO631.

Answer 1:

and this is a test reply for CO631 (2006/2007).

Question 2:

Submission reference: IN743

I'm trying to write the "filter" process for exercise 1. This has to pass through only numbers not divisible by 5. Here is my test:

    IF
      (n \ 5) <> 0
	out ! n

where "n" is holding the latest number that's been input and "out" is the channel to which numbers are being passed. My process compiles but crashes when run? Why?!! Thanks.

Answer 2:

Please see slides 74-75 in "basics.ppt/pdf". If none of the IF conditions are TRUE, a run-time error is raised.

In the above, the first number arriving that *is* divisible by 5 means that the (single) IF condition above is FALSE. With no further conditions, the IF construct throws an error. You need another condition to catch the case when the first condition fails - in your example, it should be simply TRUE - e.g.

    IF
      (n \ 5) <> 0
        out ! n
      TRUE
        SKIP            -- do nothing

Keywords: if

Referrers: Question 6 (2011) , Question 11 (2009) , Question 59 (2008)

Question 3:

Submission reference: IN747

For the assessment, are you counting 0 as a multiple of 5 seen as 0 x 5 = 0?

Answer 3:

Yes, that's correct: 0 is a multiple of 5; also because (0 \ 5) = 0.

Keywords: q1

Question 4:

Submission reference: IN750

With IF statements, is it possible to have a number of statements executed in the body, for example:

    IF
      value <> 0
        out ! 42
        out ! -99
      TRUE
        SKIP

This however give a compile time error. Is there a way to allow multiple statements to be executed.

Answer 4:

The structure of an IF is:

    IF
      condition
        process
      ...
        ...

What you have in your code is two processes indented under the condition -- so you need to say how you want them executed. Sequentially would make sense here, e.g.:

    IF
      value <> 0
        SEQ
          out ! 42
          out ! -99
      TRUE
        SKIP

Missing SEQs are a common cause of the "incorrect indentation" error from the compiler.

Keywords: if , incorrect-indentation

Question 5:

Submission reference: IN751

when I run this code it just prints out 13 for some reason, and then says: Deadlock! Why is there a deadlock? and if i change the "INT eve:" declaration in:

    PROC S0 (CHAN INT out!)
      INT eve:
      SEQ
        eve := eve + 2
        out ! eve
    :

to:

    INT eve IS 0:

the compiler says:

  Error-occ21-q1.occ(6)- right hand side of abbreviation must be assignable

why doesnt it work? Im a bit behind so please help!

Answer 5:

These are relatively small errors; the Occam-Pi reference should help here. The first problem (that it outputs a 13) is the result of using an undefined variable (you added 2 to it). Declared variables do *not* get initialised to silly values (like zero). If you want your variable to hold a zero, assign it!

Your attempt at an initialising declaration is almost correct, but it should be this:

    INITIAL INT eve IS 0:

Alternatively, you could initialise the variable as the first thing in that PROC, e.g.:

    INT eve:
    SEQ
      eve := 0
      ...  other code

The deadlock arises from the fact that the "S0" process generates a single output then terminates -- it probably wants some kind of loop to keep it going.

Question 6:

Submission reference: IN753

I can't seem to find a copy of the exercise sheet on the module webpage (mines covered in spilt coffee). Would it be possible for them to be made avaliable along with the other class handouts?

Answer 6:

The exercise sheet "early-exercises.pdf" is in the "exercises" folder you copied to your file area. The original is on raptor at:

  \courses\co631\exercises\early-exercises.pdf

Hard copies were distributed in the first terminal class.

Question 7:

Submission reference: IN755

I know it's past the deadline, but it's driving me crazy ... why does this:

  PROC S0 (CHAN INT out!)
    INITIAL INT tot IS 0:
    INITIAL INT x IS 2:
    SEQ
      WHILE TRUE
        SEQ
	  tot := (x+tot)
	  out ! tot
  :

always output:

  2
  2
  2
  2
  2
  2

forever? And not:

  2
  4
  5
  6
  8
  10

It seems to be not saving tot, and sets it back to 0 after each run. why is this? It's pretty much exactly the same code as on the lecture slides, why does tot not accumulate? Thanks!

Answer 7:

It's *not* past the deadline! The deadline is tomorrow afternoon, whenever the CAS office closes for the day.

There's no logical error in your code for S0. It *does* produce the sequence of outputs: 2, 4, 6, 8, 10, ... (which is not what was specified... there should be an initial 0 sent).

How do you know it produces: 2, 2, 2, 2, 2, ... ? You have not included the rest of your program. The output from your S0 is supposed to be piped into the print.stream process, given in your q1.occ starter file, which then connects to the screen channel (which is a parameter of the given q1 PROC). The error lies in however you have used your S0.

Your S0 coding could be improved slightly: there is a redundant SEQ and your x should not be a variable initialised to 2 ... it should be a constant defined with a VAL declaration (not INITIAL). You also have redundant brackets in your assignment.

Question 8:

Submission reference: IN754

Hi, I'm just a bit confused about this:

  PROC filter(CHAN INT num?, CHAN BYTE screen!)
    INT z:
    WHILE TRUE
      SEQ
        num ? z
        IF
	  (z < 10)
	    print.stream(100000, num, screen)
	  TRUE
	    SKIP
  :

Just as a test I've set the condition in the IF to z < 10, however it continues to print all the numbers (except 0) out anyway. It also does so even if the while loop is taken out. I don't understand why the while loop apparently does nothing in this situation, or why the number zero is left out of the list.

My first thought is that z is not being set to the actual value of num, however I don't know how to debug the program to look at the value of z. Thanks.

Answer 8:

Look at the coding for print.stream. It sets up an infinite loop ("WHILE TRUE") and therefore never terminates. So, your filter process above inputs its first number and, if that is less than 10 (which it will be), invokes print.stream. Control never returns from this invocation ... so no more instructions from your filter code are ever executed! You have handed over filter's input channel to print.stream, which consumes all the remainder and outputs to filter's output channel ... which I presume is q1's screen output.

So, all your filter does is consume the first number received and then invoke print.stream to handle everything else. That is not right!

Look at the your network diagram ... which should be a minor modification to the final diagram given in Exercise 1 on the exercise sheet. The difference is there should now be five processes in the network: S0, S1, alternate, print.stream and (somewhere) your new filter. Coding this up, all five processes should be in the PAR construct in your modifed q1 process - what-you-see-is-what-you-get.

Summary: your filter should not invoke print.stream! It should be running in parallel with it and communicating to it.

[BTW: when passing channel-ends as arguments to processes, you should (must) indicate which end you are passing (with a "!" or "?"). In your above code, you did not do this when you invoked print.stream. The current occam-pi compiler allows you to get away with this ... but we will mark you down in assessments ...]

Question 9:

Submission reference: IN757

Just wondering for the bonus task, this is as far as I got, and nothing works, is there something I'm missing? just curious! I gave it a shot anyway...

  -- from demo.occ
  PROC print.streams (VAL INT delay, []CHAN INT in?, CHAN BYTE out!)
    INITIAL MOBILE []INT n IS MOBILE [SIZE in?]INT:
    -- Above is the rather complex way we have to declare an array whose size
    -- in not known until runtime.  This will be made simple in future versions
    -- of occam-pi.
    WHILE TRUE
      SEQ
        PAR i = 0 FOR SIZE n
          in[i] ? n[i]
        SEQ i = 0 FOR SIZE n
          out.int (n[i], 15, out!)	-- out.int is from "course.lib"
        out.string ("*c*n", 0, out!)	-- out.string is from "course.lib"
        pause (delay)
:

Mine:

  PROC cols (INT colNum, CHAN BYTE out!)
    VAL INT colNum1 IS 3:
    INITIAL INT in0 IS 66:
    [colNum1] CHAN INT c:
    
    INITIAL INT i IS 0:
    WHILE TRUE
      SEQ i = 0 FOR colNum1
        SEQ
          c[i] ? in0
          IF
            i = colNum1 
              print.streams (100000, c?, out!)
            TRUE
              SKIP
  :

Answer 9:

What you have there won't compile. The most obvious error is that your "cols" has no inputs -- so can't be connected up to the rest of the network. The spec talks about adding a "VAL INT" parameter, so I'd expect the rest of the PROC header to be intact, e.g.:

  PROC cols (VAL INT n.cols, delay, []CHAN INT in?, CHAN BYTE out!)

The order of parameters is, of course, unimportant. As long as it's wired up in a matching way.

Your code is attempting to declare a run-time sized array of channels, which we don't support (yet). You can do it, but it's a bit ugly:

  MOBILE []CHAN INT c:
  SEQ
    c := MOBILE [n.cols]CHAN INT

But you don't need to do this -- 'n.cols' channels should be passed as parameters (in the array of channels "in". The existing code uses the size of this ("SIZE in") to calculate the size of its data array. Your code also instances "print.streams"; as this contains a infinite loop ("WHILE TRUE"), that procedure call will be made, but won't ever return. Better would be to start with the existing definition of "print.streams" and modify that, rather than starting afresh.

The actual answer shouldn't be too much different from the original. As you learn more occam-pi this should become clearer. :-)

Keywords: channels

Question 10:

Submission reference: IN817

Hi, Why does this network result in deadlock?

PROC q4 (CHAN BYTE keyboard?, screen!, error!)
  ...
  CHAN INT a, b, c, d:
  SEQ
    numbers(a!)
    ...  other process instances
:

I am using SEQ as opposed to PAR for the second part of the assessment, where when I used PAR, integrate was re-set 2 numbers before numbers as input was already in the system. Thanks!

Answer 10:

Using a SEQ here is wrong -- that means do "numbers(a!)", and when that terminates, do the next thing. The "numbers" process contains a WHILE TRUE loop, so won't ever terminate — PAR is definitely the correct thing. See also anonymous questions relating to seq, q4 and parallelism.

If you're seeing behaviour where you hit reset, but the output takes a moment or two to reflect the change, that's fine (and expected). Once 'integrate' has been reset, the new value has to propagate through the rest of the process network (which will be "backed up" trying to feed data to the screen-output process).

Question 11:

Submission reference: IN825

I have to following for Q4:

  [snip code]

And i keep getting the errors:

Error-occ21-q4.occ(325)- incompatible channel direction specifier on `d'
Error-occ21-q4.occ(336)- incompatible channel direction specifier on `b'

I've tried changing around the channels and rewriting the PROC's but the same erros keep popping up. From what i can tell the channel directions are correct. For numbers replace outputs on d and delta takes an input on that channel.

Answer 11:

Double-check that you're wiring things up correctly. Because you don't specify which lines the errors are being reported for it's pretty hard to give any more advice! The compiler will generate this error when you try and specify an incompatible channel-direction. Your code had a mixture of some parameters with direction-specifiers and some without -- put them all in as you think they should be and try compiling again. If things still go wonky, email me your code (frmb@kent.ac.uk) and I'll see if there's something else going wrong (like a compiler bug!).

From phw@kent.ac.uk: yes, double-check! You have simply used the codes given in slides 46 and 49 (from choice.ppt), which are correct for the replace process defined on slide 34. Now, look at the replace process defined in your q4.occ starter file ... it's different! The difference is trivial - one parameter name and the order of its parameters. To fix things, either change the replace in your file *or* invoke it correctly.

Keywords: q4

Question 12:

Submission reference: IN826

With assessment 3, question 4 has this:

  's' ==> suspends output to the screen.  Output is resumed by the next
	     keypress (which is NOT processed according to the above rules
	     -- it is merely the signal to resume output).

How should it be processed differently? I assume that we press 's' once, and nothing is output but everything is still running. Then, I assume if 's' is pressed again then output it resumed, but at the state the machine reached even when it wasn't outputting. Am I wrong here though? Is there something special we need to do? Thanks.

Answer 12:

If you type an 's', the output must be frozen. The next key pressed (i.e. any key, not just an 's') lets output resume from the point at which it was frozen. That's still what must happen if, for example, that next character was an 'i' - i.e. that 'i' is not processed according to the rules (which would mean resetting the integrator).

Keywords: q4

Question 13:

Submission reference: IN827

In the current assessment, does pressing 'q' basically kill it? I.e. are we trying to make the whole thing crash and die? Thanks

Answer 13:

The question says: "Just cause the system to freeze (i.e. deadlock) in response to this 'q'". By this , we mean something stronger than the freeze in response to an 's', from which we could recover the system with a further keypress. By "freeze (i.e. deadlock)", we do mean force the system into deadlock - something we would not normally require! But this is trivial to do: terminate the keyboard monitoring process and one of the processes in the data stream(s) to the screen channel.

A (much) better solution would be to arrange for all processes to terminate "gracefully" - but that's a *lot* of work and definitely not required.

Keywords: q4

Question 14:

Submission reference: IN828

In reference to question 9, I am wondering about this bonus task? I am not aware of a bonus task. The q4.occ does not make any reference to such a bonus task? Is this information available somewhere? I would be interested in completing a bonus task. If you could inform me about where I could find this information, I would be greetful. Thanks.

Answer 14:

Sorry - there is no "bonus" task for this Assessment 3 (which is to complete q4.occ).

Question 15:

Submission reference: IN829

How do I bleep the screen?

Answer 15:

Send it the bleep character ... known as BELL in the course library:

  screen ! BELL

Actually, you should flush immediately afterwards - i.e.

  SEQ
    screen ! BELL
    screen ! FLUSH

Another way to do the latter is to use the library process:

  SEQ
    screen ! BELL
    flush (screen!)

The benefit of that being an explanation of 'flushing' in its documentation (see the course library documentation linked off the Co731 module page).

Question 16:

Submission reference: IN837

Hi, I totally get stuck on the fourth modification, how can I change the pairs process to undo the integration? Thanks

Answer 16:

I think you mean the third modification: dealing with a 'p' keystroke ... which has to change the behaviour of pairs. Read the specification of this change:

  'p' ==> 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.  In this
          state, the modified pairs becomes a `differentiator', undoing
          the `integration' effect of the process immediately upstream so
          that we see the natural numbers sequence.  A second 'p' toggles
          the process back to its original state.  Subsequent 'p's toggle
          between the two states.

This assumes you are modifying the pairs process whose implementation is given by the network shown in slide 98 of basics.ppt. Just do what it says in the first sentence! The second sentence will then just be true (as your experience in doing the second assessment exercise should inform you). Don't forget to deal with the third and fourth sentences in the specification above.

Keywords: q4

Question 17:

Submission reference: IN840

You said in the class that pressing 'p' should mean the third column is natural numbers, but when I do what you say I have delta - tail in pairs I get this but the numbers are decreasing. So which one is correct, delta - tail or tail - delta? Thanks.

Answer 17:

Sorry, I've no idea what you mean by: "delta - tail in pairs"? Same for "delta - tail or tail - delta"?

The pairs process, slide 98 of basics.ppt, has three sub-processes: delta, tail and plus, arranged in the network topology shown. Your task is to make that plus process behave like a minus when a 'p' keystroke is made (and vice-versa for the next 'p') ... etc.

Please see the answer to Q16 for further help.

Keywords: q4

Referrers: Question 19 (2006)

Question 18:

Submission reference: IN841

In question 17 I meant which number do I take off which? Its strikes me as important and I don't want to get it wrong :)

Answer 18:

Ah - I understand what you mean now! :)

The specification says it in words:

  'p' ==> ..............................................................
          .................... taking the numbers arriving from the tail
          process from those arriving directly from the delta.

Natural language, sadly, is a difficult medium with which to be precise - but we try. In your notation from question 17, this means:

  delta - tail

However, that looks wrong! And will lead to a decreasing sequence of negative numbers ... instead of an increasing sequence of positives!! Humm ... that specification has been running for many years and nobody spotted anything wrong. It should be:

  'p' ==> ..............................................................
          .................... taking the numbers arriving directly from
          the delta process from those arriving from the tail.

So, in your notation from question 17, this means:

  tail - delta

Even now, I find it hard to interpret that natural language correctly. Specifications should be written in mathematics - only then can we have precision. Meanwhile, we will accept as a correct solution to this part of the assignment one that does the subtraction either way around. Apologies.

Keywords: q4

Referrers: Question 5 (2010) , Question 19 (2006)

Question 19:

Submission reference: IN843

Do I get extra marks for spotting the specification problem in Question 17 (2006) and Question 18 (2006)? :)

Answer 19:

We don't know who you are ... these are anonymous questions! :)

Keywords: q4

Question 20:

Submission reference: IN833

Hi, I'm having some trouble with my zap adder control. I created a new PROC called operation that takes an additional parameter to decide what function is to be carried out. Does this seem like a sensible way to solve the problem?

  ...  code deleted

Also, to suspend output would a reasonable way be to simple halt numbers from outputting anything thus causing everything else to wait for input? Cheers.

Answer 20:

Sorry, we can't answer specific questions about a piece of code large enough to give too much of a solution away. A general guideline is given in the third paragraph of the general text at the top of this page.

Having said that, the deleted code does look sensible (albeit with some redundant SEQs). Your second question has "yes" as its answer, provided by "halt numbers" you really mean "suspend numbers".

Keywords: q4