Programming with Numipulator: Issues and Support

It is worth highlighting some of the issues that the programmer will come across when working with Numipulator, and also some of the support.

Most difficulties arise when programming complex apps, such as Triple Jewels (you can see and play the game by tapping here) - a version of a well-known game, Bejeweled, in which the player selects two adjacent jewels to be swapped with an aim of forming lines of 3 or more jewels of the same type, which then disappear to be replaced by ones falling from above. For this, 9 different phases were identified, including filling, checking adjacency, swapping, checking for clusters of 3 or more, and removing jewels. Although the programming is declarative, the procedural aspects of the overall game are crucial and must be considered carefully. Some phases require multiple repetitions, others only one; some require the display to be updated after a cycle and a delay for the user to see this, while others don't. The program must therefore include functions that produce different control values (repetition termination, display and delay) for the different phases.

The main difficulty, however, is that each phase may require its own set of functions to generate outputs for the display and also the state (Memory numipulation boxes). The functions required to generate a table with jewels added are quite different from those to generate a table showing jewels being removed or swapped. The program must include them all, and all sets of functions will be evaluated at each cycle, regardless of the phase; this is because the program consists of a set of numipulation boxes, and this set will not change from one cycle to the next, even though the input specifications for Memory boxes may change. If-Then-Else boxes, or others, are used to select which outputs to use for each phase. This is clearly inefficient, but is a feature of evaluating the same complete set of functions at each cycle, rather than processing different procedures at each phase, as would be the case with standard procedural programming. To explain further and to demonstrate the inefficiency, consider the Tricolor app (you can see and play the game by tapping here). The initial board is determined by a numipulation box that produces 100 random integers between 3 and 5 (red, green and blue colour codes). This is specified as the initial value (init) of a memory box, which as used as the initial (first cycle) board layout, with other values (showing collapsed blocks modified through user actions) specified subsequently. Nevertheless, at each later cycle the numipulation box will produce 100 random numbers that are not used.

Another issue found with Numipulator, as with spreadsheets and most other programming languages, is the complexity of linkages: the data flows between the numipulation boxes can be hard to understand and remember, which consequently makes it harder to identify errors. The information (i) button on a numipulation box makes clear which boxes it depends on, and also which numipulation boxes are directly dependent on it, but tracing through these can be tedious and error-prone. Greater transparency is required. Transparency for users is provided through two features, each triggered by a button: Flow and Values.

Flow provides top-down tree-like graphical structures that show how a formatter or numipulation box is dependent on other numipulation boxes. No values are shown in this, nor are the functions selected. Importantly, however, the notes for the manipulation boxes are shown, as these can help explain what is going on. The Flow for the Small red ball game is shown below. More on this, including a link to the game and an analysis of the Flow diagram, can be in found in Programming in Numipulator.

The Values button provides a value-based view of the numipulation boxes and formatter inputs, together with the functions being applied, based on the last evaluation cycle. They are listed in a bottom-up manner (so, starting with all numipulation boxes that are not dependent on others). The Values output for a program to generate the first 20 numbers of a Fibonacci sequence, stopped before completion, is as follows:

----------------------
Z1: (Fibonacci sequence)
Has a memory input which evaluates to: 0,1,1,2,3,5,8,13
----------------------
C1: (Length of sequence)
la=Z1
which evaluates to: 0,1,1,2,3,5,8,13
Function of la: Length of list
Value=8
----------------------
H1: (Reverse of sequence)
la=Z1
which evaluates to: 0,1,1,2,3,5,8,13
Function of list: Reverse
Value=13,8,5,3,2,1,1,0
----------------------
J1: (Sum of first two numbers)
la=H1
which evaluates to: 13,8,5,3,2,1,1,0
p1,p2... p1,p2... ...=1,2
Operations on la (for each set of parameters): Sum: items p1->p2
Value=21
----------------------
Next value of Z1: (Fibonacci sequence)
Defined as: Z1,J1
which evaluates to: 0,1,1,2,3,5,8,13,21
----------------------
Repeat until: first=C1
which evaluates to: 8
second=20
=
Value=0

There is also a Notes button, which displays all the notes of the numipulation boxes, and so provides a quick overview of the boxes and what they're about.