Here are some preliminary thoughts about the organisation of the SciFest 2016 activities.

Arduinolas: The archetype for an Arduinola that Tapani, Janne and I discussed at C15 takes the following form:

• it has a set on 'input' observables that get their values from Arduino sensors
• it has a set of 'output' observables that are used to determine the Arduinola's responses
• it has an internal state that is expressed via a definitive script that establishes a set of dependencies to couple ouput observables to the input observables.

I'm assuming that there can be a direct connection (via the JS-Eden-Arduino connection mechanisms that have been developed) between input and output observables in the script and physical observables in the external world. (Tapani has prepared this brief manual to document the JS-Eden-Arduino connection.)

I'd been playing with simple mathematical examples that could be used to supply the 'are you happy?' functionality that must link the state of the output observables to that of the input observables. These most natiurally take the form of mathematical puzzles in configuraton. The example we discussed briefly at C15 was that of placing 10 red and 10 blue tokens on a 3 by 3 grid in such a way that each cell has tokens of the same colour and there are exactly the same number of red and blue tokens on each row, column and diagonal line of 3 cells. A prototype script that realises this kind of link between state and 'happiness' (which can be made a little more subtle by having a notion of happiness relative to each of the eight possible lines) can be found in wmb/seesaw15puzzle. As we concluded in discussion with Tapani and Janne at C15, it is unlikely that such a puzzle can be converted into an input output mapping that directly interfaces with Arduino. It would probably be too expensive to create a bank of sensors that could determine the colour and number of tokens on each cell.

At C15, we decided that a more appropriate approach would be to create a world in which the Arduinolas could be placed (e.g. a rectangular area equivalent to two or three tables) within which we could create artificial contexts where different levels of light, noise and heat could be registered by an Arduinola. There appear to be some technical challenges in ensuring that such regions are clearly demarcated (how to muffle sound / compensate for background noise? prevent heat from travelling from one region to another? etc). It would also not be very interesting if each Arduinola liked just one location, as that would lead to a rather boring trial and error exercise. A further point to be clarified is whether it would be an easy matter to establish the correspondence between Arduinolas placed in the world and their virtual counterparts in the JS-Eden construal of the situation.

If it is possible to engineer an environment and some Arduinolas in such a way that a script of observables associated with the Arduinolas can be maintained as a faithful representation however the Arduniolas are positioned in the world, then perhaps it would be natural to blend the physical positioning of Arduinolas with the satisfaction of constraints imposed by a definitive script of the kind associated with a mathematical puzzle. If (for example) we have a set of N Arduinolas and N locations where they may in principle be placed, each of which may or may not suit a particular Arduinola, the task of placing the Arduinolas on the locatiions in such a way that each is happy is a well-known mathematical problem known informally as the Marriage Problem. Searching for a solution to the marriage problem doubtless has some kind of algorithmic interest, and there would be a lot of value in having a virtual representaton to complement the physical environment in which it might make sense to adopt an empirical approach.

A prototype consrual for the Marriage Problem can be found in the two scripts:

scifest2016/matching4/mark2 and scifest2016/matching4/candomatch

This is set up for 4 Arduinolas (numItem is the number of Arduinolas) and 7 locations (regions where and Arduinola may or may not be happy). When you load the first script, you get a visualisation with a bipartite graph in which the points in the left represent Arduinolas and the points on the right are locations. Green edges connect Arduinolas to locations where they are happy. The significant observables for the purposes of the Arduinola interface are possmatch - which specifies where the four Arduinolas are happy, and matchposs which tells you whether a match can be found so that all the Arduinolas are happy. You can change the value of possmatch and see how this affects matchposs. If there is no match, the observable OKix01ls (!) enables you to identify which subsets of Arduinolas cannot all be happy at the same time. This could be another source for audio output. The kernel of an algorithm for finding a matching when one exists is outlined in the script scifest2016/matching4/expt. This can be transformed into an algorithm for making all the Arduinolas happy when the conditions for this are met.

There are other criteria for satisfaction that could be applied through transformation from a configuration of Arduinolas to a virtual configuration - this might for instance make the illustrative example involving 20 tokens mentioned above useful for instance. The mechanism behind a winning strategy for Nim may also be useful here. Hamish's suggestion that Arduinolas might have different modes (such as being asleep, awake, hungry etc) potentially adds additional interest - and complication! - but with a good physical-virtual correspondence between states we would surely be well-placed to handle this.

Publicity materials for SciFest: The flyer originally devised by Edumotiva for distribution at the Athens Science Festival earlier in April has been translated into Finnish and English. There is a poster for CONSTRUIT! developed by Rene and Steve that we used to advertise SciFest last year. A poster tangentially related to our life on Mars workshop is the following (supplied by Hamish at Edinburgh). More to be added!

At our Interim Review meeting in March, following a suggestion made by Ilkka after Scifest 2015 at Joensuu, the possibility of creating a live construal in the web-browser that could be used to publicise CONSTRUIT! was discussed. The technical work needed to embed a JS-EDEN construal in a standard webpage was done at that time. One idea I had was that it might be interesting to create a blend that draws upon three construals: the construal of the game of Nim developed for SciFest last year (see scifest2015/nimcoins/stones in the MCE), the binary number representation construal (see wmb/numberreps and import just the two scripts wmb/hailstormgame/binary and wmb/hailstormgame/binarynumber) and a musical construal such as Jonny Foss's Theremin (see jf/musictheramin - which is not actually the correct spelling of the instrument name!) or Elizabeth Hudnott's musical instrument (see Elizabeth/demos/midi/playNotesJSPE). In principle, elements from these three construals can be readily combined to make a basic 'game' that is a sort of musical version of Nim for which there is a simple interface that could readily be embedded in the browser. To envisage this game, which might aptly be called 'Therenim', imagine that:

• as the sole interface, you have a visualisation of the numbers 0 to 15 in their binary encodings, as extracted from the binary number representation construal, together with three vertical lines to represent the contents of the three piles in a game of Nim. In your turn, you would simply select one of the vertical lines and move it to the left ("subtracting stones from the chosen pile").
• there is an audio output based on the MIDI dependency features introduced by Jonny and Elizabeth that is linked to the NimSum (which of course you set to zero on your turn when you are following the winning strategy). The idea is that each bit of the NimSum that is set to 1 activates a MIDI instrument.

With this construal in place, the chances are high that, in the initial configuration for a game of Therenim (based on the random allocation of up to 15 stones to three piles), there will be an initial noise (a noise is an indication that the player with the move can win with best play). Winning the game involves selecting the appropriate move to make the current position silent. You can find a basic prototype for Nim with this audio extension constructed by Elizabeth at wmb/therenim/audio. Before you venture to try it out, you are recommended to master the winning strategy for Nim (or check the location of your mute control) since you will otherwise be subjected to irritating repeated notes.

In principle, it's quite easy to complete the construction of Therenim from here - and to embed it in the browser. The problem at present is that no single up-to-date version of JS-Eden is suitable for all the consitutuent construals. (The number representations only seem to work properly in construit-v1.2, Jonny's Ther[a]min only works in construit-v1.2.0, and the prototype mentioned above only works in construit.c15). It is also unclear whether having such a construal embedded in the browser would be a good advertisement for CONSTRUIT!!

Note that the Therenim mechanism (though probably not the number rep interface) is quite a good prototype for a baby Arduinola, since it responds to three inputs in the range 0-15, and wil be happy provided that you set these inputs so that they have NimSum zero (which is always possible if you choose to diminish the setting on one of the three sensor inputs in the appropriate way - this may be more appropriately something you do to the Arduinola rather than the environment). If you perturb any one of the sensor inputs, the Arduinola will start to cry, but with skill you can get it into the state where it is truly sleeping, and is not responding to any sensory input. Starting a new Therenim game may be good analogy for waking the baby - we could have some randomness in the environment to simulate events that might be suitably disturbing. Another idea (not yet implemented in Elizabeth's prototype) is that the overall volume of crying could depend on the total sum of the three sensory inputs, which will diminish as the baby 'falls into deeper sleep'.

Tapani, Janne and I discussed the 'Therenim in the browser' idea last week, and were not convinced it was a good idea. Alternative suggestions are welcome. It would be good to make the game within a browser (if only as proof-of-concept) nonetheless provided that a suitable variant of JS-Eden can be developed to run it.

The latest prototype for this 'construal in a browser' can be found at:

http://www.dcs.warwick.ac.uk/~jonny/construit/therenim.html

Logistics for SciFest: At C15, we discussed the possibiilty of having two locations in the SciFest Areena devoted to CONSTRUIT! activities - one for the Arduinolas, the other for the Mars workshops and the non-stop workshop activities. We thought that we would ideally need five or so laptops at each of these locations (I'm no longer entirely clear about the reasoning where the Arduinolas are concerned). We would also appreciate having a projector such as we used last year to support the non-stop workshop.