# Alternative representations of P systems solutions to the graph colouring problem

- 75 Downloads

## Abstract

This paper first presents a simulation of the simple kernel P systems solution to the graph 3-colouring problem presented in a previous paper by Gheorghe et al., implemented in a programming style named Concurrent ML, which is based on the concept of synchronous communication between logical processing elements. This paper then presents and informally analyses an alternative compact single-cell solution to the same problem using P systems with compound objects (cP systems), which has the benefit of naturally adapting to the use of any number of colours greater than zero—only the specified colour symbols need to be changed. Successful and failing examples of the latter solution are also presented.

## Keywords

cP systems Simple kernel P systems Graph colouring problem Concurrent ML## 1 Introduction

The graph colouring problem is a deceptively simple problem in graph theory. In its most basic form, it is the problem of assigning labels such as colours to the nodes in a graph, such that no two nodes connected by an edge share a colour, usually with the addition of the extra requirement either of finding the minimum number of colours required or only using a number of colours up to some upper bound—clearly, for any graph with \(N\) nodes, it is trivial to colour it using \(N\) colours. The problem finds applications in many areas, including timetabling, register allocation for compilers, as well as solving Sudoku puzzles (which are in turn a special case of Latin Squares) [10]. The general case is NP-Complete, and thus no polynomial time solution has been found so far (finding one would prove that P = NP), though they have been found for specific forms of graph or particular numbers of colours. For example, in the case of 3-colouring, the current best known solution takes \({\mathcal {O}}(1.3289^n)\) time [1].

Gheorghe et al. [6] presented a P systems solution to the 3-colouring problem, using communicating simple kernel P systems (SKP). Based on this work, we first discuss in Sect. 2 a Concurrent ML implementation of the SKP solution in [6], briefly compare the two approaches and indicate some other P systems variants we think Concurrent ML might be a good fit with. We then present in Sect. 3 a fairly concise single-cell solution to the problem using P systems with compound terms (cP systems for short—see [11] for a detailed background on cP systems), and provide an informal analysis of it. Lastly, in Sect. 4, we provide examples of the operation of our cP system on the 3-colour problem, both for a graph that is colourable and one that is not, before concluding in Sect. 5.

To the best of our knowledge, this is the first time cP systems have been applied to Graph Colouring, and the first time that a Concurrent ML implementation has been used to simulate the operation of any P system.

We wish to emphasise that we do not consider our simulation or cP systems solution to be ‘superior’ to that of Gheorghe et al. (though we do think it demonstrates the utility of cP systems), but instead wish to complement theirs and others’ work with another alternative.

## 2 Simple kernel P systems solution to the graph colouring problem in Concurrent ML

We were interested in exploring Concurrent ML as another methodology to use for simulating P systems where communication is involved. For a first experiment, we chose to implement Gheorghe et al.’s [6] 3-colouring problem solution from, as it involves communication between compartments but is relatively low-complex and thus appears to be suitable for a first attempt.

We chose to use the programming language F# with the library Hopac,^{1} which is modelled on Concurrent ML and follows it closely.^{2} ‘Record’ types are used to represent the individual compartments described in [6]. The program then advances through multiple steps, applying the rules (encoded as functions that operate on the record types) in accordance with [6]. Finally, once a solution is found, or found not, to be possible, it is communicated to the environment.

Insofar as possible, our implementation has been created to follow the algorithm described in [6] faithfully, and thus perhaps is not optimal in its efficiency, as an idiomatic specification of a simple kernel P system does not necessarily match to the idiomatic or efficient form of an F# program. That is, we have written the program to prioritise staying as close to the original SKP model as possible, rather than writing the program to suit the strengths and typical style of the host language. Consequently, the efficiency of the program may be worse than it could be otherwise.

Ultimately, however, this example is relatively straightforward and involves little communication, and therefore does not test the use of Concurrent ML significantly. Much of the operation of the algorithm in fact does not involve communication between different compartments/processing elements at all. Instead, it is primarily based in the evolution of objects contained within the compartments, with minimal communication between compartments at the end. While that is highly effective in P systems [15], it would be interesting to see the results of using Concurrent ML for other problems where synchronous communication^{3} is a much bigger part of the evolution of the system.

We do note here that, in common with most ad hoc simulations, while our implementation is reasonably successful, it is the case that it is not particularly customisable, and the code as written does not comport as precisely to the appearance of the theoretical rules of the SKP system as the P-Lingua version created for [6] does. Neither does our Concurrent ML-based simulation have any form of verification or invariant detection, as provided by MeCoSim [14] and Spin [2, 9]. We suggest that it would be worthwhile to pursue future work that seeks to improve one implementation/simulation by incorporating relevant parts of the other.

Concurrent ML seems to match to SKP well, but also looks like it might fit well with tissue P systems with symport/antiport [19] as well perhaps as tissue P systems with channel states [18], and generalised communicating P systems with minimal interaction rules [4]. It would also appear to be a good fit for spiking neural P systems [8], though Concurrent ML would probably be ‘overkill’ for those systems when running on a shared-memory system. In general, any variant of P systems which heavily uses synchronous communication between different cells/neurons/non-nested membranes/etc. over well-defined channels may be amenable to a Concurrent ML implementation.

Technically, the base form of Concurrent ML would only support antiport (i.e. one-way synchronous communication), but it is fairly simple to build two-way communication on top of it [17, ch. 6]. We have not attempted to model other systems yet, however.

### 2.1 Simulation results

We recorded our program’s running time on a number of differing graphs, with red, green and blue as our set of colours with which to colour the graphs. The desktop computer used for these simulations has a four-core 3.6 GHz Intel Core i7-7700 CPU, with 16 GB of RAM, running Windows 10, build number 10.0.17134.228. Our F# programs were run on .NET Core 2.1.4, while MeCoSim was run on Java version 8, build 1.8.0_201-b09.

^{4}we also tested the graphs \(G(10,1)\) and \(G(10,10)\) (see Fig. 3), finding that it requires 0.3 s for each. We also decided to test our simulation using the classic Petersen graph, shown in Fig. 4, and found that it too required approximately 0.3 s.

We further ran our simulation on some complete graphs. For a complete graph of \(N = 10\), the algorithm again requires 0.3 s. We then tried it on a complete graph of \(N = 20\), but the test had to be aborted after a matter of minutes due to the computer running out of memory. We then recorded running times of 0.83 s, 2.6 s, 8.88 s, 26.6 s and 84 s for \(N = 11, 12, 13, 14\) and \(15\), respectively. Given that we observed significant jumps in memory use in the course of running the larger graphs, it appears that the major cause of the rapid slowdown is likely to do with frequent ad hoc memory allocations and de-allocations, though we have not profiled this fully.

Gheorghe et al. state [6, p. 828] that in the latest version of P-Lingua at the time of writing, a strategy of eliminating compartments for which there can be no further rule applications is mentioned. Using said strategy, results are typically achieved quite quickly. It has the effect of pruning the search space, and reduces the total running time in some instances to just one-fifth of the running time of the simulation without such dead-compartment elimination.

Our program does not choose which compartments to operate upon in the same fashion, but we note that applying the colour guard on rule \(r_{2,2n+1}\) of the SKP system throughout the process results in the pruning of compartments which already contain invalid results and thus can be eliminated safely; so, to achieve the same effect as with P-Lingua’s strategy, we apply this guard in the course of applying rule \(r_{2,2n+1}\) and use the result to filter out all invalid compartments. Doing this reduces the evaluation of complete graphs to around 60 ms or slightly more, since every compartment in them can always be entirely eliminated once colours have been assigned to four nodes. It also reduces the running time of Fig. 2 to around 0.25 s, and the Petersen graph, \(G(10,1)\) and \(G(10,10)\) to 0.1 s.

#### 2.1.1 Comparison with original results

^{5}[14] to re-run the same simulations locally on the same computer used to time our solution, along with the timing results mentioned above.

Comparison of recorded timings between [6] and this work

Graph | P-Lingua (original) | P-Lingua (local) | CML | CML with pruning |
---|---|---|---|---|

Figure 2 | N/A | 17.0 | 2.6 | 0.25 |

Petersen | N/A | 1.5 | 0.3 | 0.1 |

G(10, 1) | 7 | 2.6 | 0.3 | 0.1 |

G(10, 10) | > 4 min | N/A | 0.3 | 0.1 |

Complete 11 | 5 | 0.15 | 0.83 | 0.06 |

Complete 12 | 5 | 0.15 | 2.6 | 0.06 |

Complete 13 | 5 | 0.15 | 8.88 | 0.06 |

Complete 14 | 5 | 0.15 | 26.6 | 0.06 |

Complete 15 | 5 | 0.15 | 84 | 0.06 |

Our attempts to run the simulation of \(G(10,10)\) repeatedly failed with an out-of-memory error. We are unsure as to why this should be the case, given that in the other instances, our executions of the MeCoSim SKP simulations achieved lower runtimes than those of the original paper. We believe that execution of \(G(10,10)\) notwithstanding the overall improvements in runtime of the SKP systems is likely due to a combination of the computer used locally being more recent and thus likely more powerful, and improvements in the underlying MeCoSim and P-Lingua software.

Further, we find it odd that two functionally identical graphs, \(G(10,1)\) and \(G(10,10)\), would have such dramatically different run time behaviours when running in MeCoSim—seen in both the original and our local results. We speculate this might be due to an unusual performance bug hidden deep within MeCoSim, though we have not investigated this further.

These results appear to suggest that our final implementation generally provides superior results with regards to running time, though it must be emphasised that we have not tested a particularly wide variety of scenarios. We speculate that the scenarios which would provide the ‘worst’ running time will likely be those that have a moderate level of connectedness in the graph. Highly connected graphs will likely see many potential paths eliminated early due to frequent occurrences of colour conflicts, while graphs with few connections will not have many potential paths to explore.

Our results and those of the MeCoSim simulations are not *completely* comparable, however. Our solution was programmed directly to follow the SKP system’s rules, whereas the MeCoSim solution was specified as the SKP system rules in P-Lingua, with the operation of the computer simulation carried out by MeCoSim. This difference between ‘ad hoc’ and ‘general’ simulation means that one would expect to see our simulation achieve better results from the outset, as overheads that accompany a general simulation implementation can be avoided.^{6} MeCoSim is an excellent tool and, combined with P-Lingua, it provides a valuable service to the Membrane Computing community, in that it allows researchers to validate their systems and rulesets while staying close to their mathematical descriptions, and without having to delve into the details of implementing a given algorithm in code. See further [13] for more of a discussion on ad hoc versus general simulations, and the beginnings of a substantial narrowing of the differences between the two.

## 3 cP systems solution to the graph colouring problem

In working to create the Concurrent ML simulation of the problem, we noticed that in fact most of the work is performed by the instantiation of new objects, rather than communication. Thus, the problem appears to be an excellent fit to the pre-existing formulation of cP systems [11].

This problem, rather unsurprisingly, has a lot in common with the Hamiltonian Path Problem, and in fact our cP systems solution for the graph colouring problem is similar in some regards to our previous Hamiltonian Cycle Problem solution, as presented in [3]. General simulation of cP systems remains an open problem at present, and so while we have verified this system programmatically, we have not as of yet created a general-purpose simulation.

We assume a graph with at most one edge between nodes (i.e. there are not two or more edges between the same two nodes), and that there are no edges leading from a node back to itself.

We take as given inputs to the process conceptual finite sets \(V \subset {\mathbb {N}}\) representing the nodes of the graph^{7}; \(E \subseteq \{(i,j)\,|\,i, j \in V, i \ne j \}\) representing the edges of the graph; and \(K\) representing the chosen colours, where \(K\) contains whatever representation of the desired colours is considered appropriate.

Based on these definitions, for the purposes of the remainder of this paper, \(|K|\) is defined to be the number of colours used in the current problem, \(|V|\) the number of nodes in the graph under consideration for the current problem and \(|E|\) the number of edges in the graph.

### 3.1 Pseudocode for our parallel algorithm

In our notation, \(m\) is a partial functional relation in Dom(m) \(\times\) K; Dom(m) is a partial spanning tree over the graph; \((x, c) \in m\) iff \(c\) is the colour of node \(x\); \(B\) is the set of all such partial functional relations built up so far; and \(l \in {\mathbb {N}}\).

In brief, our system works by starting with the colours and graph under consideration, then building up in a maximally parallel fashion a collection of objects which represent all validly coloured partial spanning trees of the graph. Eventually, once full spanning trees have been constructed, one is chosen at random and its colouring output to the environment. Or, if no valid colouring is possible, the system will detect it by the complete absence of any partial spanning tree, and signal to the environment that no appropriate colouring is possible. The conceptual spanning trees are built following all possible tree edges, but checking those all new frond edges do not invalidate the colouring.

Note that while this algorithm is guaranteed to return a valid colouring if one is possible, there is *no* guarantee as to precisely which valid colouring will be selected. We assume here that all potential colourings are equally desirable, and make no provision for specifying that certain nodes must be coloured from a subset of the available colours.

### 3.2 cP system initialisation

We start construction of the system with a top-level cell containing functor \(V' = v(n(i)\,|\,i \in V)\) which contains the labels of the nodes in \(V\); a set \(E' \subseteq \{e(n(i)\,n(j))\,|\,(i,j) \in E\}\) representing the edges of the graph; a starting node \(s(h)\) where \(h \in V\) is an arbitrary node label; and a set \(K' = \{k(\kappa )\,|\,\kappa \in K\}\) of the potential colours—in the case of the three-colour problem, it might look like \(K' = \{k(r), k(g), k(b)\}\). Using separate colour symbols in this fashion means that the algorithm can operate as a \(|K|\)-colour problem, without any other modification.

While we represent the colours here as separate symbols for legibility, they can in fact be represented equivalently by natural numbers, because each colour symbol is contained within a \(k\) functor—one simply need fill each functor with the appropriate number of the counting symbol to represent the desired different colours; e.g. \(r\) might be represented by one symbol, \(\alpha\), \(g\) by two and \(b\) by three, i.e. \(r = k(\alpha )\), \(g = k(\alpha ^2)\) and \(b = k(\alpha ^3)\). Exactly, the same is true of the edges. This means that in fact we do not require any extra symbols in our alphabet to represent the colours and edges of a given problem—we merely re-use atoms (see further in Sect. 3.3).

### 3.3 cP system notation

### 3.4 Rules

*weak priority order*. They are explained below:

- 1.
This rule begins the evolution of the system. It converts the functor \(v\) into a functor \(b\), which is used further to instantiate new objects with the possible colourings of the system. It merely selects the node described by \(s(h)\), and assigns it a colour at random.

The \(b\) object holds an \(l\) functor which keeps track of which iteration a given \(b\) belongs to; a multiset of \(m\) functors which track nodes and their assigned colours in a potential solution; and a \(v\) functor which continues to track the reducing unexplored nodes of the graph.

A separate global \(l\) functor is also instantiated at this point, which tracks the current iteration number of the system and which is used in later rules. This rule begins in state \(s_0\) and ends in state \(s_1\). This rule corresponds to the upper Graph Colouring function in Fig. 5.

- 2.
This rule is one of the potential end points of the evolution of the system. If there are no further remaining nodes to explore, i.e. the \(b\) objects have empty \(v\) functors, then one of the \(b\)s is selected at random and the set \(M\) of \(m\) functors within said \(b\) which represent a complete solution to the graph colouring problem is output to the environment. This rule begins in state \(s_1\) and ends in state \(s_2\). State \(s_2\) is used to indicate to the environment that a solution has been found and the evolution of the system has terminated. The change in state means that no other rule can be applied if this rule is applied. This rule corresponds to lines 1–3 of the lower Graph Colouring function in Fig. 5.

- 3.
This rule is arguably the heart of the process and runs in a maximally parallel fashion (as indicated by \(\rightarrow _+\))—meaning that every possible exploration from the currently extant \(b\) objects is performed simultaneously. In each application, for every pre-existing \(b\) object, new ones are generated with a random colouration assigned to an unexplored node, as long as there exists an edge between those nodes in the graph and the selected colours are not the same and there does not already exist another \(m\) object within the current \(b\) object that represents another node connected to the newly chosen node with the same colour. It also increments the iteration counter within the \(b\) object. This rule begins in state \(s_1\) and ends in state \(s_1\). This rule corresponds to lines 5–7 of the lower Graph Colouring function in Fig. 5.

The interaction of the \(v\) objects in the output and the first promoter works in the same fashion as \(y \in V {\setminus} {\textsc{Dom}}(M)\) in the pseudocode of Fig. 5. That is, this rule selects an \(n\) inside the given \(b\)’s \(v\), but naturally avoids selecting an \(n\) that is already used in one of the \(b\)’s \(m\)s because they have already been removed from \(v\).

- 4.
This rule is a ‘cleaning’ rule, which removes all extant \(b\) objects with the current iteration count, thus keeping the working space relatively clean. Recall that in P systems, rules are applied top-to-bottom in a weak priority order. This means that, while this rule will eliminate the \(b\) objects used by rule 3 to instantiate the next generation, said objects will not be eliminated until immediately after the application of rule 3 and thus, the two rules do not cause conflicts. This rule begins in state \(s_1\) and ends in state \(s_1\).

The operation of this rule occurs implicitly in the pseudocode, and does not have corresponding lines. There is no reference to the current set of \(b\)s, \(B\), carried forward into the next call of the pseudocode function. Instead, \(B\) is replaced with \(B'\) for the next execution of the function, and \(B\) will be cleaned up by the system in whichever way it clears away objects after all references to them have been dropped.

- 5.
This rule is the other possible termination rule. It merely transits to state \(s_3\), which is used to signal to the environment that no solution is possible. The key to this rule is that, because it transits to state \(s_3\), it is only applicable if none of the prior rules are. This effectively means that it can only apply if all \(b\) objects have been removed from the system (because the presence of at least one \(b\) would mean that one of the prior rules will apply), indicating that every possible combination explored so far has already found a colouring conflict and thus there is no possible valid solution. This rule begins in state \(s_1\) and ends in state \(s_3\). This rule corresponds to lines 8–9 of the lower Graph Colouring function in Fig. 5.

- 6.
This rule merely increments the global iteration counter. It is placed last so that the termination rules can trigger before it, as otherwise it will always be applicable while the system is in state \(s_1\). This rule begins in state \(s_1\) and ends in state \(s_1\), and thus is applied simultaneously with rules 3 and 4. This rule is implemented in the successive recursive calls of the lower Graph Colouring function in Fig. 5 at line 10. As part of the recursive call, the value for \(l\) in the next call is given as the current value of \(l\) plus one, i.e. \(l\) is incremented as part of the function call.

### 3.5 Termination and correctness

The behaviour of the system with regards to termination and correctness is stated and explained below. This informal discussion explains the reasoning used to justify the assertion that the system always terminates with a correct answer.

### Proposition 1

*All*\(b\)*objects present in the top-level cell hold a monotonically growing set*\(M\)*of*\(m\)*functors*, *which represent validly coloured partial spanning trees of the whole graph*, *and at step*\(l \le |V|\)*in the evolution of the system*, *each partial spanning tree will have a length equal to*\(l\).

At step one, a single \(b\) object will have been created by operation of rule 1. Contained within this \(b\) object is a single \(m\) functor, which pairs a node label with a colour label. Thus, the size of \(M\), \(|M|=1\), \(m \in M\).

At step \(l > 1\), any pre-existing \(b\) objects are removed, but are replaced with new \(b\) objects which between them cover all possible valid-coloured partial spanning trees rooted at the initial node so far, after adding one further \(m\) object to \(M\), so \(|M|=2\). Thus, at step two, the extant \(b\) objects will each contain two \(m\) functors, one describing the initial node, and the other describing another node of the graph that has been chosen at random from amongst those that have an edge in the graph connecting said node to the first node. By operation of the same rule, the number of node labels contained inside the \(v\) functor, itself inside each \(b\) object, will decrease by one, and thus the number of remaining unexplored nodes inside it will be equal to \(|V| - l\).

At step 3, there will be three \(m\) objects inside each \(b\) object, where there are edges in the graph connecting the represented nodes. Due to the maximally parallel nature of rule 3, every possible partial spanning tree of size \(l\) rooted at the initial node will be represented in a \(b\) object at step \(l\). Assuming that a colouring is possible, the system proceeds in the same fashion for each following step, up until step \(l = |V| + 1\) when the \(M\) sets inside the \(b\) objects contain full spanning trees, and the \(v\) functors will be empty.

At that point, rule 3 can no longer be applied (because there will no longer be any \(n\) functors inside the \(v\) functors). More importantly, rule 2, which enjoys priority under the weak priority ordering, becomes applicable and is, thus, selected as the rule to apply, ending evolution of the system with one of the \(M\) colouring sets output to the environment.

If a colouring is not possible, then eventually every possible application of rule 3 will be confounded by the inhibitor, leading to rule 4 removing all \(b\) objects without any more replacing them. At this point (which can itself potentially occur at step \(l = |V| + 1\), such as in the case of a 4-node complete graph with 3 colours), rule 5 will terminate evolution of the system.

### Proposition 2

*In all cases*, *evolution of the system proceeds wholly deterministically between the first and final steps*, *exclusively.*

Due to the nature of rules 3, 4 and 6, which are the only ones applied during the middle steps of the system’s evolution, there is essentially no choice made at any point. Rules 3 and 4 make a non-deterministic choice in an individual application of them, but the rules are applied in a maximally parallel fashion, meaning that all possible choices are selected simultaneously. Thus, all valid choices are explored, while the inhibitor ensures that no invalid choices are possible.

Rule 5 is also deterministic. It can only be applied when there are no \(b\) objects inside the top-level cell, and thus the decision of whether it is applied or not simply requires checking the truth or otherwise of a simple proposition. Further, there is only one possible result from applying rule 5—transitioning the system to state \(s_3\)—so, there is no choice involved in its application. This means that, in all cases where there is no valid colouring possible (and thus the system will end up in a state with no \(b\) objects), the final step of the system is also deterministic.

Likewise, rule 6 is deterministic, because there will only be one \(l\) functor contained within the top-level cell.

### Proposition 3

*The system is only non-deterministic with regards to the choice of the colour of the starting node*, *and the final selection of which valid colouring to send out to the environment*, *assuming that the evolution of the system finishes with an application of rule* 2.

The system is deterministic for all rule applications except the first, and potentially the last, by Proposition 2. Application of rule 1 to start the system is partially non-deterministic, with regards to the choice of the initial colour only. Application of rule 2 to end the evolution of the system is likewise non-deterministic only in the choice of the set of colourings to send out.

Rule 1 uses the pre-selected starting node, encoded in the \(s\) functor, to create the first \(b\) object with which to evolve the system. While that functor will be unique by the creation conditions described above,^{8} it has a free choice between the available colours. As the rule is applied exactly once due to its application mode, only one colour is selected, but the specification of the colour promoter for rule 1 simply states that one of the supplied \(k\) colour objects is used.

While this selection is non-deterministic, it has no impact upon the termination of the evolution of the system, because for the standard graph colouring problem, there is no functional difference between colours. That is, they do not imbue special properties or behaviours to their marked nodes, they merely label them. Thus, the colour selected does limit the potential colouring sets that are available at the end by fixing the colour of the starting node, but has no impact upon the which rule is applied next.

Finally, as with the selection of a colour in rule 1, the selection of which extant \(b\) object to take the colouring set \(M\) out of and send out to the environment by rule 2 is non-deterministic, as rule 2 has a free choice in which one it selects. From its perspective, any \(b\) object with an empty \(v\) functor is acceptable.

### Proposition 4

*The termination of the evolution of the system by application of rule* 2 *or rule* 5 *is also deterministic.*

Both rule 2 and rule 5 can only be applied in specific, mutually exclusive circumstances. In particular, it is only possible to apply rule 2 when there is at least one \(b\) object, which additionally must have an empty \(v\) functor. Conversely, rule 5 may only be applied where there are absolutely no extant \(b\) objects in the system. The only way \(b\) objects can be removed is by operation of rule 4, which cannot be applied in conjunction with either rule 2 or rule 5, as they have differing final states. This means that *only* one of rule 2 or rule 5 may be applied during a step when either of them is applied, and both are considered to terminate the evolution of the system. If there are any \(b\)s with an empty \(v\), then rule 2 is applied. If there are no \(b\)s whatsoever, then rule 5 is applied. In all other cases after the first step, rules 3, 4, and 6 are applied.

### Theorem 1

*The evolution of every valid instance of this system* (*where the system is created in accordance with Sect.* 3.3, *and*\(|V|, |E|, |K| > 0\)) *will terminate*, *either sending a valid colouring out to the environment where a valid colouring is possible*, *or signalling to the environment that no valid colouring is possible*.

By Propositions 2 and 3, the applications of the rules are deterministic in all ways, except the choice of the colour of the starting node, and the choice of the final selected colouring. Thus, the progression of the system is always deterministic. By Proposition 4, the evolution of the system is *always* terminated by rule 2 when there exist any \(b\) objects with a full set of colourings, or by rule 5 *only* when no colouring is possible. A full set of colourings inside a \(b\) is ensured under Proposition 1.

### 3.6 Complexity

As with the discussion on correctness and termination, we informally discuss the time and space complexity of the system, with an emphasis on the maximum for each because the minimum is highly graph dependent.

#### 3.6.1 Time complexity

Our system requires at most \(|V| + 1\) steps, where \(|V|\) is the total number of nodes in the graph. In the case that a valid colouring is possible, the system will require that many steps to find a complete colouring, but for graphs where there is no possible \(|K|\)-colouring it may terminate early.

Rule 1 requires one application. Rules 2 and 5 between them require one application. Rules 3, 4 and 6 all require at most \(|V|-1\) applications, but the applications occur concurrently in all cases because there is no chance for a conflict of states. In total, it simplifies to at most \(|V| + 1\) steps, giving a time complexity of \({\mathcal {O}}(|V|)\). This holds regardless of the relative sizes of \(K\) and \(V\), as all possible valid colourings are simultaneously explored for a given node. It is trivial to create a valid colouring when \(|V| \le |K|\). When \(|V| > |K|\), i.e. the number of nodes in the graph is at least one greater than the number of colours available, the maximally parallel nature of rule 3 ensures that the running time does not depend on \(|K|\).

Furthermore, in cases where \(|V| > |K|\), the system requires *a minimum* of \(|K| + 2\) steps before terminating. At each step up to step \(l = |K|\), it will always be possible to choose a colour that does not conflict with any chosen so far, simply by selecting a colour that has not been used yet.

At step \(l = |K| + 1\), however, in the case of a complete graph, no further \(b\) objects can be created, because whatever colour would be selected for the next node, it is guaranteed to conflict with one of the colours selected previously. This means that rule 4 will remove all current \(b\) objects, but rule 3 does not replace them with new ones. Thus, at the next step, rule 5 will transit the system to state \(s_3\), signalling to the environment that no colouring is possible, and the evolution of the system will terminate. As such, a lower bound on the number of steps can be determined as \(|K| + 2\). Other graphs potentially will require a greater number of steps to reach an answer, but as described above never more than \(|V| + 1\).

#### 3.6.2 Space complexity

*theoretical*maximum number of objects that can be present in the system at the end of each step from step 1 onwards is given by (1) below and provides an upper bound.

*never*contain this many objects at once, due to the restriction on creating new \(b\)s where there would be conflicting colours. Instead this is a theoretical upper bound. For the purposes of the above, \(0!\) (which will occur when \(l = |V|\)) is defined to be equal to 1, in accordance with standard mathematical conventions.

After the first step, there will always be precisely one \(b\) object in the top-level cell, simply by the operation of rule 1, but in each proceeding step the count will depend on the exact nature of the graph and colour set under consideration. At the point that \(l = |V| - 1\) (i.e. at the \(|V|\)th step), for each \(b\), there will be only one possible choice for the next node to explore (as there will only be one \(n\) remaining in each \(b\)’s \(v\)), but each one of those choices can potentially be made with each one of the system’s colours, and thus while the “base” number of \(b\)s will remain the same between those two steps, the total maximum possible number of \(b\)s will increase by a factor of \(|K|\).

A complete graph gives the upper limit to the number of objects that can exist, because (ignoring the operation of the inhibitor in rule 3) every node can be reached from any other given node, and thus it provides the widest possible search—any non-complete graph will contain an incomplete set of edges between nodes, disallowing some potential explorations from taking place. This gives an upper bound on space complexity proportional to the number of nodes and colours in the system under consideration, i.e. \({\mathcal {O}}(|K|^{|V|})\), while \(\mathcal {O}(|K|)\) is an upper bound for* distinct* objects. Of course, due to the operation of the inhibitor in rule 3, no more \(b\) objects will be created for a complete graph once \(l > |K|\).

Equations (2) and (3) provide formulae to calculate the total space requirements of an individual \(b\) and the overall system. These equations assume that the size of a functor that contains only atoms, such as the colour functors \(k\) which contain only a given number of the counting atom, is constant regardless of how many atoms it contains. This is perhaps unrealistic in a real biological system, but is appropriate for computer simulations, where fixed-bit-length representations are likely used to represent the various elements of the system.

### 3.7 Comparison with the simple kernel P systems solution

*invariant*to the problem graph under study, as opposed to defining a family of rules that are customised to the graph at hand. The same is true for our alphabet. Our

*fixed*alphabet consists of only 9 atoms and functors plus the unique counting symbol, but with the nesting of atoms and functors, these combine into further forms. As the semantic meaning of each never changes, we do not consider this to add a great deal of complexity. We require roughly equivalent starting objects to the SKP solution.

SKP systems vs cP systems

Type/specification | SKP systems | cP systems |
---|---|---|

Alphabet | \(|V|(|V|-1)/2 + 7|V| + 10\) | \(10\) |

Rules | \(2|V|\ \text{and}\ 2|V| + 7\) | 6 |

Maximum number of subcompartments | \(3|V| + 1\) | N/A\(^{\mathrm{a}}\) |

Number of steps | \(2|V| + 3\) | \(\le |V| + 1\) |

Table 2 provides a comparison of the simple kernel P systems solution presented in [6] compared with our solution presented above, and is based upon Table 1 in [6].

#### 3.7.1 Differing concepts of subcompartments

Atoms are simple objects, but one could perhaps argue that functors should be regarded as somewhere between full subcompartments and simple objects, because they are non-atomic and can potentially hold objects (including other functors) within themselves. The key difference between subcompartments and functors is that the former have rules of their own and typically evolve separately to their containing compartment, whereas the latter have *no* computing/evolutionary power of their own, and are simply more complex objects operated upon by their top-level cell’s rules. A subcompartment could potentially have all its parent compartments removed and still function as though it now has the skin membrane, but not so functors. This means that cP systems do not have a concept of subcompartments completely comparable to SKP systems, with instead the functors in use being closer to normal inanimate objects.

#### 3.7.2 Rules length

The ‘price’ for reducing the number of rules and symbols involved in the system is arguably making the rules themselves more complex.^{9} Much the same as the SKP system in [6] allows for a “more succinct (in terms of number of rules, objects, number of cells and execution steps)” specification than an earlier Tissue P system from [5] “at the expense of a greater length of the rules,” so too does our cP system again allow for a more compact solution to the problem in exchange for longer rules.

If one chooses to exclude the guards specified, then the longest rule in [6] has a length of \(5\). If you include the guards, however (which we feel is more realistic), then the longest SKP rule has length of \(3 + 3|V|(|V| - 1)/2\) while our longest rule, rule 3, has a *fixed* length of 14, determined by counting the number of distinct atoms, functors and variables that appear in it. We consider this to be an entirely acceptable price to pay considering what this permits us to achieve otherwise. Which style is most appropriate fundamentally depends on the specifics of a given situation, and the relative costs of the alphabet size, rule length, etc. in implementing a system in a chosen form.

## 4 Examples

### 4.1 Successful example

From this starting state, rule 1 is applied, choosing node 1 to start the process with, and selecting red as its colouring. This creates the standard \(b\) and \(l\) objects. No other rules are applicable at this point, as the top-level cell started in state \(s_0\). The application of this rule leaves the top-level cell in state \(s_1\). Rule 1 will henceforth be inapplicable, as the rules provide no way to revert to state \(s_0\).

At the next step, rule 2 is checked but found inapplicable, as at this point the \(v\) object inside the only \(b\) object will not be empty, instead containing \(v(n(2)\, n(3)\, n(4)\, n(5))\). Rule 3, conversely, is applicable and thus can generate further new \(b\) objects. In this instance, two edges exist from node 1 to other nodes (2 and 5 specifically), meaning that both choices can apply, generating new \(b\) objects containing all legal colourings. Both nodes are chosen to connect to, but there are only two other possible colourings to choose here, as red is currently blocked due to it being selected for the first \(b\) object. This leads to the creation of four new \(b\) objects \(b\big (l(2)\,m(n(1)\,c(r))\,m(n(2)\,c(g))\,v(n(3)\, n(4)\, n(5))\big )\), \(b\big (l(2)\,m(n(1)\,c(r))\,m(n(5)\,c(b))\,v(n(2)\, n(3)\, n(4))\big )\), etc.

### 4.2 Failure example

With no \(b\) objects available in the system, at the next step none of rules 1–4 will be applicable. Thus, the first rule selected is rule 5, which merely transits the top-level cell to state \(s_3\), signalling to the environment that the evolution of the system has ceased after determining that there was no possible valid colouring for the graph using the colours provided.

## 5 Conclusions

Firstly, we implemented a version of Gheorghe et al.’s SKP solution to the 3-colouring problem using F# and a Concurrent ML-derived library, Hopac. On the small sample of graphs tested, this produces reasonable results for smaller graphs, at least as good as those achieved by the P-Lingua/MeCoSim simulation. In both systems, the inclusion of a test for already-invalid compartments has the potential to improve the runtimes significantly, as it prunes the search space, sometimes quite dramatically.

Concurrent ML appears to be a good fit in principle to P systems variants that use communication between cells/membranes, but this particular problem had fairly minimal communication and instead relied heavily upon cell division. Further testing with other problems is required to determine the efficacy of Concurrent ML for sure.

We secondly provided a single-top-level-cell cP systems solution to the graph colouring problem, which is capable of solving the problem for arbitrary graphs with an arbitrary number of potential colours in at most \(|V| + 1\) steps. Its operation was demonstrated with two 3-colouring examples based on two different graphs, for which it was and was not possible, respectively, to find a valid 3-colouring.

## Footnotes

- 1.
- 2.
The final program can be found at https://github.com/jcoo092/acmc2018.

- 3.
Note that, while Concurrent ML uses synchronous communication by default, it is relatively simple to implement asynchronous communication also using it [17].

- 4.
Note that this is different to the random graphs that are also commonly denoted by this notation.

- 5.
The latest version of MeCoSim available from http://www.p-lingua.org/mecosim/ as at 10 January 2019 was used.

- 6.
One could see ad hoc as being akin to running a program compiled to native instructions, while using a general simulation is similar in principle to running a program in an interpreter. The latter is typically simpler to work with and more portable, but comes with overheads that slow down execution.

- 7.
In fact, any finite set of arbitrary symbols could be used, but we use the natural numbers here for ease of reading.

- 8.
We note that, should it be desired, it would be possible to have the system make a random selection between possible starting nodes, simply by starting the system with more than one \(s\) functor. The correctness and termination of the system will be unaffected, however.

- 9.
We consider these rules to be fairly easy to understand nevertheless —they are simply longer and involve a greater number of symbols than those of other systems.

## Notes

### Acknowledgements

We would like to thank Luis Valencia-Cabrera of Universidad de Sevilla (the University of Seville), Spain, for providing valuable assistance with regards to the use of MeCoSim. We also would like to thank the anonymous reviewers for their detailed and considered reviews, which proved very helpful to us in improving the paper.

## References

- 1.Beigel, R., & Eppstein, D. (2005). 3-Coloring in \(O(1.3289^n)\) time.
*Journal of Algorithms*,*54*(2), 168–204. https://doi.org/10.1016/j.jalgor.2004.06.008.MathSciNetCrossRefzbMATHGoogle Scholar - 2.Ben-Ari, M. (2008).
*Principles of the spin model checker*. London: Springer. https://doi.org/10.1007/978-1-84628-770-1.zbMATHGoogle Scholar - 3.Cooper, J., & Nicolescu, R. (2019). The Hamiltonian cycle and travelling salesman problems in cP systems.
*Fundamenta Informaticae*,*164*(2–3), 157–180. https://doi.org/10.3233/FI-2019-1760.MathSciNetCrossRefGoogle Scholar - 4.Csuhaj-Varjú, E., & Verlan, S. (2011). On generalized communicating P systems with minimal interaction rules.
*Theoretical Computer Science*,*412*(1–2), 124–135. https://doi.org/10.1016/j.tcs.2010.08.020.MathSciNetCrossRefzbMATHGoogle Scholar - 5.Díaz-Pernil, D., Gutiérrez-Naranjo, M. A., Pérez-Jiménez, M. J., & Riscos-Núñez, A. (2008). A uniform family of tissue P systems with cell division solving 3-COL in a linear time.
*Theoretical Computer Science*,*404*(1–2), 76–87. https://doi.org/10.1016/j.tcs.2008.04.005.MathSciNetCrossRefzbMATHGoogle Scholar - 6.Gheorghe, M., Ipate, F., Lefticaru, R., Pérez-Jiménez, M. J., urcanu, A., Valencia Cabrera, L., et al. (2013). 3-Col problem modelling using simple kernel P systems.
*International Journal of Computer Mathematics*,*90*(4), 816–830. https://doi.org/10.1080/00207160.2012.743712.MathSciNetCrossRefzbMATHGoogle Scholar - 7.Hoare, C. A. R. (1985).
*Communicating sequential processes. Prentice-Hall international series in computer science*. Englewood Cliffs: Prentice/Hall International.Google Scholar - 8.Ionescu, M., Păun, G., & Yokomori, T. (2006). Spiking neural P systems.
*Fundamenta Informaticae*,*71*(2/3), 279–308.MathSciNetzbMATHGoogle Scholar - 9.Lefticaru, R., Tudose, C., & Ipate, F. (2011). Towards automated verification of P systems using spin.
*International Journal of Natural Computing Research*,*2*(3), 1–12. https://doi.org/10.4018/jncr.2011070101.CrossRefzbMATHGoogle Scholar - 10.Lewis, R. (2016).
*A guide to graph colouring*. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-25730-3.CrossRefzbMATHGoogle Scholar - 11.Nicolescu, R., & Henderson, A. (2018). An Introduction to cP systems. In C. Graciani, A. Riscos-Núñez, G. Păun, G. Rozenberg, & A. Salomaa (Eds.),
*Enjoying natural computing: Essays dedicated to Mario de Jesús Pérez-Jiménez on the occasion of his 70th birthday. Lecture notes in computer science*(Vol. 11270, pp. 204–227). Cham: Springer International Publishing. https://doi.org/10.1007/978-3-030-00265-7_17.CrossRefGoogle Scholar - 12.Panangaden, P., & Reppy, J. (1997).
*The essence of concurrent ML*(pp. 5–29). New York: Springer. https://doi.org/10.1007/978-1-4612-2274-3_2.CrossRefGoogle Scholar - 13.Pérez-Hurtado, I., Orellana-Martín, D., Zhang, G., & Pérez-Jiménez, M. J. (2018). P-lingua compiler: A tool for generating ad-hoc simulators in membrane computing. In M. J. Dinneen, & R. Nicolescu (Eds.),
*Pre-proceedings of Asian branch of international conference on membrane computing*(pp. 149–163). Auckland: Centre for Discrete Mathematics and Theoretical Computer Science. https://www.cs.auckland.ac.nz/research/groups/CDMTCS/researchreports/publication-list-bydate.php?selected-date=2018. Accessed 10 Jan 2019. - 14.Pérez-Hurtado, I., Valencia-Cabrera, L., Pérez-Jiménez, M. J., Colomer, M. A., & Riscos-Núñez, A. (2010). MeCoSim: A general purpose software tool for simulating biological phenomena by means of P systems. In K. Li, Z. Tang, R. Li, A. K. Nagar, & R. Thamburaj (Eds.),
*2010 IEEE fifth international conference on bio-inspired computing: Theories and applications (BIC-TA)*(pp. 637–643). Changsha: IEEE. https://doi.org/10.1109/BICTA.2010.5645199.CrossRefGoogle Scholar - 15.Păun, G., Pérez-Jiménez, M. J., & Riscos-Núñez, A. (2008). Tissue P systems with cell division.
*International Journal of Computers Communications & Control*,*3*(3), 295. https://doi.org/10.15837/ijccc.2008.3.2397.CrossRefGoogle Scholar - 16.Reppy, J. H. (1991). CML.
*ACM SIGPLAN Notices*,*26*(6), 293–305. https://doi.org/10.1145/113446.113470.CrossRefGoogle Scholar - 17.Reppy, J. H. (2007).
*Concurrent programming in ML*. New York: Cambridge University Press.zbMATHGoogle Scholar - 18.Song, B., Pérez-Jiménez, M. J., Păun, G., & Pan, L. (2016). Tissue P systems with channel states working in the flat maximally parallel way.
*IEEE Transactions on NanoBioscience*,*15*(7), 645–656. https://doi.org/10.1109/TNB.2016.2594380.CrossRefGoogle Scholar - 19.Verlan, S. (2005). Tissue P systems with minimal symport/antiport. In C. S. Calude, E. Calude, & M. J. Dinneen (Eds.),
*Lecture Notes in Computer Science (Developments in language theory)*(Vol. 3340, pp. 418–429). Berlin: Springer. https://doi.org/10.1007/978-3-540-30550-7_35.Google Scholar