$tonePits

$tonePits

---

...is based on the hundreds of Manqala or Sowing games. There are always stones, pits, and rules. Well, I suppose maybe this can be used for computation, but it is unknown whether it is Turing complete.

Programming in "$tonePits" is like designing an own Sowing game and creating a start configuration. Maybe on the beach or a similar recreational area, there will be the possibility to present your $tonePits program, just with sand pits, pebbles, shells, or whatever is around. Maybe some kid will see it and become the next Euler, Newton or Perelman!

Syntax

Uh, maybe it's time for a sample to ease up the beginning:

(6) (71) (68) (75) (75) (78) (0)

Here, the parentheses represent a pit, and the number enclosed by them is the number of stones in the pit; we suppose sowing from the left to the right and then beginning from the left again;

Sowing is like in all common known sowing games - take all stones in your hands and then put them in one stone, then to the next pit and so on until you have no stones ... if the last stone falls in an empty pit the sowing process ends just in this sample (of course this is no essential rule of sowing games and could be changed), otherwise take out all other stones of the pit your last stone fell in and sow again ... in our sample we will start with the stones from the first pit, which contains (6) pebbles

No miracle, and hoping you did not fall asleep, it should result in

  (0) (72) (69) (76) (76) (79) (1) in decimal 
  (0) (48) (45) (4C) (4C) (4F) (1) in Hex  

Thus, maybe a $tonePits program would look like this. This program prints "Hello"

Usually a pit can not hold an infinite number of stones, so a limit has to be set. Lets set it to 255 and we could have the equivalent of a byte. Also sowing must not be always in the same directions, because we maybe want some kind of control structures in our $tonePits game/system/program. Maybe we want some additional pits created in the game (during program operation). Thus we define a rule like, well "after passing the last pit, create another one and then go back to the first pit". We could make the program multidimensional by defining sowing rules.

Multidimensional Sowing Rules

To have a simple sample, just an idea to make it 2d.

 (1) (2) (3) (4) 
 (5) (6) (7) (8) 
 (9) (A) (B) (C)
 (D) (E) (F) (0) 

If the last stone reaches a pit and its number gets 7 then sowing direction changes by 90 degrees. Thus for up and down in our sample the next forth or the last forth pit.

Parameters and Neighbours

Well, personally I got this idea from Argh!, but it is used in cellular automata. Let 7 be our control structure and sowing direction be decided by the neighbouring pit above. We can check for emptiness, parity, equality ... it's up to us. We can include the pit below, to the left right ... and so on. Just some idea to make the whole thing more like a language and less like what it's commonly used now.

Do you feel like a Paleolithic caveman programmer now?

Maybe you never will do .... however here are some kind of programs yet to be programmed.

Towards the Oscillator

Taken this "Oscillator" word from Game Of Life. By accident I found a small oscillator. Here's how I got to it.

  (1) (2) (3)

if you continue sowing starting from the second pit you get after some turns

  (2) (0) (4) 
  (0) (1) (5)  
  (2) (3) (1) 
  (3) (1) (2) which is a permutation of (1) (2) (3)  
              (the last stone fell in an empty pit which was defined as halt) 

Also, every state occurred only once.

I wanted to know if it is possible to make an Oscillator out of it and tried

 (1) (2) (4) and started sowing again from the second pit 
 (2) (0) (5)
 (0) (1) (6) 
 (2) (3) (2) 
 (3) (4) (0) 
 (4) (1) (2) 
 (5) (2) (0) 
 (6) (0) (1) 
 (2) (2) (3) 
 (0) (3) (4) 
 (2) (4) (1) 
 (0) (5) (2) 
 (1) (6) (0) 
 (3) (2) (2) 
 (4) (0) (3) 
 (1) (2) (4) ooh, again our starting position after so much .... 
             and again there's from the 2nd pit to be sowed , thus 
             exactly the same starting position, thus it will repeat ,
             thus we got an Oscillator 

Well, I count (maybe I did something wrong) 13 unique states and after that the initial state again, making 14. Maybe that could be used as a counter or incrementer.

To Be Programmed and Not Being Classical Quine, SelfInterpreter Esolang Stuff

Oscillator (reaching the starting position periodically)
Or better, a program who finds Oscillators with the desired period 
SpaceShip (Possible ?! What could it look like?) 
CheckingParity (Finds the answer if an even or odd number of stones are used in the game) 
Creatures (Expanding and changing it's rules to show more complex behaviour) 

Well, a quine and a self interpreter would be cool too ....