https://community.wolfram.com RSS Feed for Wolfram Community showing questions tagged with Wolfram Science with no replies sorted by new. https://community.wolfram.com/groups/-/m/t/2380863 Are the four paradigms of science described in this Stephen Wolfram's writing (https://writings.stephenwolfram.com/2021/09/even-beyond-physics-introducing-multicomputation-as-a-fourth-general-paradigm-for-theoretical-science/) more general as we reach the 4th paradigm of the 2020's? In other words, does the 4th paradigm (the multi computational one) englobe or include the rest of them? Is it a "generalization" of all of them? (I mean, mathematical models are not included in the first "structural" paradigm, since they usually consider time, while in the structural paradigm time is not considered. But the mathematical paradigm includes all the models from the structural paradigm, since time is or is not considered in mathematical models. So, would this continue up until the last paradigm, which would include all the models from the rest)? If it is, then, according to the framework of the multicomputational paradigm, every possible model from the rest paradigms (all possible structural, mathematical and computational models) would be included in it. But if that is really the case, then, how could there be an incompatible model with Wolfram's framework (which is basically the multicomputational one) as he says here ( https://www.wolframphysics.org/questions/scientific-general-interest/ ): > Any particular rule could be proved wrong by disagreeing with > observations, for example predicting particles that do not exist. But > the overall framework of our models is something more general, and not > as directly amenable to experimental falsification. Asking how to > falsify our framework is similar to asking how one would prove that > calculus could not be a model for physics. An obvious answer would be > another model successfully providing a fundamental theory of physics, > and **being proved incompatible**. If his multicomputational framework englobes every possible conceivable model, how can there be any model incompatible with it? Nodu Agga 2021-10-06T23:21:02Z https://community.wolfram.com/groups/-/m/t/2124038 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/9ff169d0-d363-45ef-8c76-17ca6bc2b40f Eric Parfitt 2020-11-25T19:35:16Z https://community.wolfram.com/groups/-/m/t/1993079 I was doing some work and a notebook of mine got corrupted. When I restarted I used ResourceFunction instead of the pre-packed little functions, so I got a new version of the MultiwaySystem function downloaded. This code used to work: ResourceFunction["MultiwaySystem"][ ResourceFunction["WolframModel"][{{{0, 1}} -> {{0, 1}, {1, 2}}}], {0, 0}, 5, "StatesGraph"] However, now it does not. Looking at the examples again, I see the interface has changed slightly. So, if I change my example to: ResourceFunction["MultiwaySystem"][ "WolframModel" -> {{{0, 1}} -> {{0, 1}, {1, 2}}}, {{0, 0}}, 5, "StatesGraph"] The code executes (too rapidly to actually be doing a computation) and gives a blank output. If I change it to: ResourceFunction["MultiwaySystem"][ "WolframModel" -> {{{0, 1}} -> {{0, 1}, {1, 2}}}, {{0, 0}}, 5, "CausalGraph"] This now gives the correct output. If I use string substitution systems, it all works fine. Any clue what is going on? Brent Werness 2020-06-02T17:43:36Z https://community.wolfram.com/groups/-/m/t/1991416 I have a question regarding the possibility of utilising a matrix of actual living cells as "nodes" of a three dimensional biological cellular automata matrix where each cell acts like a state machine with multiple states, and the ability to broadcast their states to their neighbours, while also detecting the states of their neighbours and changing their internal states in response to changes in states of their neighbours. Brains accomplish this with actual physical connections and branching networks of axons and dendrites and can have tens of thousands of connections to other nodes that can be physically distant. Could it be done however without the physical "tendrils" that transmit and collect signals, and just use the waves of state changes propagating through a collection of "ordinary" cells? Could it be done while the cells are moving relative to one another within a solution, or would it only work in a solid matrix with stationary nodes? I thought this forum might be my best chance at finding some people who might have some answers. I have seen simple calculators built on Conway's Game of Life, and I think it has been shown that it is Turing complete. I was wondering if there are methods to figuring out what rule sets are Turing complete, and if they are, designing algorithms for computation to be run on them, and estimating the "efficiency" and "computing power" of such systems. Balazs Imri 2020-05-31T03:55:32Z https://community.wolfram.com/groups/-/m/t/1966961 Hi, I'm trying to understand how relativity follows from the fundamentals of the model. In the paper by Jonathan I read: > "One of the foundational features of conventional special relativity > is that two events are causally related if and only if they are > timelike-separated. From our definition of the discrete Minkowski norm > and the properties of layered graph embedding, we can see that a pair > of updating events are causally related (i.e.connected by a directed > edge in the causal graph) if and only if the corresponding vertices > are timelike separated in the embedding of the causal graph into the > discrete Minkowski lattice Z(1,n), as required." Would it be possible to elaborate a bit more on the "**if and only if** the corresponding vertices..." ? For me this is not clear. Thanks! Ygor Geurts 2020-05-07T09:59:05Z https://community.wolfram.com/groups/-/m/t/1964836 Given that Wolfram Physics Project is background independent I am curious how it interacts with formalism and predictions of "Shape Dynamics" - a theory of gravity locally similar to General Relativity but with different global implications. I will not go into all the detail what makes SD stand out from GR (https://arxiv.org/abs/1409.0105 has an SD tutorial which is a fascinating, but very technical in places, read). Similarities with the Wolfram Physics Project is that both are background independent and have an arrow of time. SD also has a relativity of size (implying that the length of an object is only measured locally by using other objects as a reference, objects far away from each other cannot be properly compared). Of course, in the Wolfram project, distance between elements is also somewhat arbitrary (if I understand it correctly). However, SD seems to really shine when it comes to solving for singularities (whether black holes or the big bang). My limited understanding of those solutions is that black holes can form pocket universes and that the big bang can be traced back to a big crunch of an earlier universe. My last paragraph is the most speculative, so please keep it in mind. If the universe is a branch tree of black holes within black holes with initial conditions being slightly different for each new daughter universe (as Lee Smolin proposed in his 1997 book "The Life of the Cosmos") then it has a direct bearing on this project. Another words, instead of randomly looking for a set of initial conditions plus a rule to start our computational universe, we can try to guess what the overall rule is. For example, Lee Smolin proposed that it could be some rule that maximizes the number of black holes in a universe. Anton Spektorov 2020-05-05T04:22:33Z https://community.wolfram.com/groups/-/m/t/1963134 I have been playing with some functions related to Wolfram Physics Project and most of the evaluated code, which should give some visual output (graphs etc.) ends up in producing mysterious gray rectangle. I have tested mostly codes from Technical Introduction and from Resources/Function repository, and some of them work, but mostly they don't. Also slight modifications of working line (such as changing number of iterations) usually gives such output. The problem appears to be not quite deterministic. I attach example of code taken from https://resources.wolframcloud.com/FunctionRepository/resources/MultiwaySystem?i=MultiwaySystem&searchapi=https%3A%2F%2Fresources.wolframcloud.com%2FFunctionRepository%2Fsearch ![Weird output][1] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=error.png&userId=1961061 Dominik Rzepka 2020-05-03T12:45:30Z https://community.wolfram.com/groups/-/m/t/1962565 I was wondering it you could use CA to investigate modal shapes of vibrating objects such as plates? Even starting with the frequency response of a simple cantilever. My problem is I have no idea where to start with this using NKS. I have limited knowledge of Mathematica or would you use Wolfram Alpha? Dave davematt 2020-05-03T01:46:55Z https://community.wolfram.com/groups/-/m/t/1945598 Has anyone thought of trying to find a relationship between the stochastic Hamiltonian equations we see with Schrodinger Equations and the Hypergraph model? It seems odd to me that we don't see this equation here. Granted, there's no notion of stochastic dynamics since he don't equip rule updating with probabilities (or amplitudes), but it seems to me like there is a type of Hamiltonian lurking in the model. For example, the Hamiltonians and Feynman Diagrams appear in the Hamiltonians for QM, and they're really obvious once you do the Taylor expansion that they represent specific state paths in a QM model. It feels to me like some form of Hamiltonian should exist for Hypergraph models, where the Feynman statepaths are the specific choices of updates to do on the graph. Is there any sort of analog to this at the moment in the Hypergraph models? Jalil F 2020-04-19T15:50:06Z https://community.wolfram.com/groups/-/m/t/1945647 From optics we know self-imaging or self-replicating effects like the Talbot effect or the Lau effect. I wonder what implications these mechanism of self-replication, or emergence of auto-propagating patterns, might have in the realms of hypergraphs. R K 2020-04-19T07:32:14Z https://community.wolfram.com/groups/-/m/t/1943636 Any consideration of the nodes as extremal black holes? Then you can consider their evolution in fractional dimensions. Arbitrary sets of nodes make up dimensional gradients when they are more dynamically evolving in a multi way graph that corresponds to a node being a greater contributor to a higher dimensional locality in the fractional scale. Using this harmonic oscillator behavior on whatever the topological correlate is of local sums of nodes in the multi way hyper graph local topological gradients(equivalent to particles), the local behavior would correspond to the causal flux(feynman diagrams). If your nodes are something like 10^-100 m or whatever, each. It could explain why the cosmological constant isn’t constant, but increasing locally for us, because these nodes are evaporating black holes in a VSL scale at some larger gradient at the scale of our universe. Where scale invariance is broken in quantum fractional dimensional steps and only applies to each conformal scale. Would explain why the quantization behavior at the Planck scale and then why it suddenly stops behaving quantum to the classical. Has to do with reduction of the multi wave graph, which has to do with these black holes evaporating from the casual graph ? It also allows you to have universes inside these nodes and thereby not having them be a weird abstract set of point constants of base reality. Where the extremal black hole nodes are entangled via Hawking radiation. And they’re each a Penrose Twistor Riemann Sphere. This then gives you a sphere packing description of the hypergraphs? I had intuited this two months ago and called them HawkingPenrose Networks. And the cohomological structure as Huerta Puzzles because fundamentally they are symmetry puzzles that are periodically solved across the VSL fractional dimensional continuum. Also, thought of black hole evaporation as preserving the change in entropy local gradients, which I can amend this to explain why mathematically later if desired. Among other ideas, thanks ! Salim Huerta 2020-04-18T04:12:38Z https://community.wolfram.com/groups/-/m/t/1942050 Hi all, I have recently been trying to model a CA for forest fires. I found some useful code on Rosetta code however it is applied to a 9-neighborhood totalistic model. I'm seeking to implement this, with a particular custom ruleset in place, for a 5-neighborhood totalistic method. How can I change this in the CA function? evolve[nbhd_List, k_] := 0 /; nbhd[[2, 2]] == 2 (*burning->empty*) evolve[nbhd_List, k_] := 2 /; nbhd[[2, 2]] == 1 && Max@nbhd == 2 (*near_burning&nonempty->burning*) evolve[nbhd_List, k_] := RandomChoice[{f, 1 - f} -> {2, nbhd[[2, 2]]}] /; nbhd[[2, 2]] == 1 && Max@nbhd < 2 (*spontaneously combusting tree*) evolve[nbhd_List, k_] := RandomChoice[{p, 1 - p} -> {1, nbhd[[2, 2]]}] /; nbhd[[2, 2]] == 0 (*random tree growth*) r = 100; c = 100; p = 10^-2; f = 10^-4; init = RandomInteger[BernoulliDistribution[0.05], {r, c}]; MatrixPlot[CellularAutomaton[{evolve, {}, {1, 1}}, {init, 0}, {{{300}}}], ColorRules -> {0 -> White, 1 -> Green, 2 -> Red}, Frame -> False] Jon Rickett 2020-04-17T07:03:31Z https://community.wolfram.com/groups/-/m/t/1842928 In [A Short Talk on AI Ethics](https://writings.stephenwolfram.com/2016/10/a-short-talk-on-ai-ethics/), Stephen Wolfram states > Well, if we can express laws in computable form maybe we can start telling AIs how we want them to act. Of course it might be better if we could boil everything down to simple principles, like Asimov’s Laws of Robotics, or utilitarianism or something. > But I don’t think anything like that is going to work. What we’re ultimately trying to do is to find perfect constraints on computation, but computation is something that’s in some sense infinitely wild. The issue already shows up in Gödel’s Theorem. Like let’s say we’re looking at integers and we’re trying to set up axioms to constrain them to just work the way we think they do. Well, what Gödel showed is that no finite set of axioms can ever achieve this. With any set of axioms you choose, there won’t just be the ordinary integers; there’ll also be other wild things. > And the phenomenon of computational irreducibility implies a much more general version of this. Basically, given any set of laws or constraints, there’ll always be “unintended consequences”. This isn’t particularly surprising if one looks at the evolution of human law. But the point is that there’s theoretically no way around it. It’s ubiquitous in the computational universe. **Question:** Can someone explain Wolfram's argument more formally? I've read NKS, as well as overviews on Godel's undecidability proofs. I don't see how this follows. To me he seems to be saying that our practical ethics are incredibly complicated, and so cannot be captured by simple ethical laws. But that violates one of the whole points of NKS, which is that **simple laws can generate incredible complexity.** So why couldn't simple laws (something resembling Asimov's Laws, etc) turn out to compute our entire ethical framework? George Singer 2019-12-17T21:10:59Z https://community.wolfram.com/groups/-/m/t/1294732 I want to simulate urban growth in the French Riviera with a cellular automaton. The following program works and analyzes the results. Rule 1000 seems appropriate. St. Wolfram has classified the behavior of cellular automata. But can we have a phenomenological classification ? What are the useful rules to simulate a simple diffusion or a diffusion equivalent to a flight Levy ? ClearAll["Global`*"] image={![enter image description here][1]} coteazur = ArrayPad[ImageData[Binarize[ColorNegate[image,30]; etats = Flatten[ CellularAutomaton[{1000, {2, 1}, {1, 1}}, coteazur, 20], {1}]; imd = Image[etats[[1]]]; imf = Image[etats[[20]]]; GraphicsRow[{ColorNegate[imd], ColorNegate[imf]}, ImageSize -> 300] ImageMeasurements[imd, {"Mean", "StandardDeviation", "IntensityCentroid", "Entropy"}, "Dataset"] ImageMeasurements[imf, {"Mean", "StandardDeviation", "IntensityCentroid", "Entropy"}, "Dataset"] ColorNegate[ImageDifference[imf, imd]] flist = {EuclideanDistance, ManhattanDistance, CorrelationDistance, "DifferenceNormalizedEntropy"}; Grid[Table[{f, ImageDistance[imd, imf, DistanceFunction -> f]}, {f, flist}], Alignment -> {{Right, Left}, Center}] croissance = Table[Count[Flatten[etats[[i]]], 1], {i, 1, 20, 1}]; ts = TimeSeries[croissance, {Range[1, 20]}]; ListLinePlot[ts] model = TimeSeriesModelFit[ts]; Normal[model] [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Captured%E2%80%99%C3%A9cran2018-03-02%C3%A011.42.35.png&userId=77503 André Dauphiné 2018-03-02T10:48:59Z https://community.wolfram.com/groups/-/m/t/1140115 #Introduction ----------- Hi, I'm Rishu Mohanka, and I developed a Cryptographic Hash Code Algorithm based off of Cellular Automata. I initially came up for the idea while thinking about the complexity of CAs (Cellular Automata) and their applications in the real world, and I came across a relatively old article regarding how researchers at Google were able to crack the SHA-1 Hash Code Algorithm; hash code algorithms are very important regarding the security of our personal and sensitive information, so I decided to try to make my own Hash Code Algorithm that generated hash codes for inputs/messages from complex and chaotic CA. I thought this project would be pretty easy to complete, but it was harder than I expected, and completing the project successfully required a lot of experimentation. In the end, I wasn't able to fully achieve my vision of the potential for my algorithm within the 2 weeks I had at Wolfram Summer Camp 2017, but I will continue to work hard at perfecting, refining, and improving my algorithm because I truly believe that chaotic CA are the best means to generate hash codes. --------- #What are Hash Code Algorithms? --------- First, let's go over what hash code algorithms *are* and *why* they are needed. Cryptographic hash functions are used to take in an arbitrarily long input/message, and it performs mathematical operations on the message to transform it into a hash code which is the output; the hash code must have a fixed length but it can be the same length or shorter than the input. These hash codes securely represents the input, and for good/valid hash code algorithms, it's easy to generate hash codes, but it's extremely hard to get the input from solely the hash code. Also, very good hash code algorithms must have extremely low probabilities of creating collisions meaning that if the hash code algorithm took in two distinct inputs, then if it generated the same hash code for the two distinct inputs, then that's a collision which creates the confusion and mix-up because you cannot have one hash code representing two distinct inputs. Also, a good/valid hash code algorithm must have the ability to generate the same hash code for the same input meaning that it is deterministic. Cryptographic Hash Code Algorithms are used for purposes like storing passwords securely, secure file/data transferring, etc. Good cryptographic hash code algorithms exhibit two main properties: Strong Collision Resistance and Weak Collision Resistance. Strong Collision Resistance means that it is computationally impractical for anyone to find any two distinct messages/inputs that when inputted into the cryptographic hash function, output the same hash code. Weak Collision Resistance means that for any large set of inputs, there exist no inputs in that set of inputs such that they will generate the same hash codes as another input in that set. If a hash code algorithm has the property of Strong Collision Resistance, then it also exhibits the property Weak Collision Resistance, but the converse is not true. ------- #Development -------- The CA used in this project have ranges of either 2 or 3, and they all have two states (black or white so k = 2), and the CA used are those that are very chaotic and complex with no pattern available within the CA's structure in order to prevent the hash code algorithm from generating collisions for distinct messages/inputs/passwords. To choose the CA from r = 2, r = 3, k = 2, I generated at hundreds of thousands of CA for each range. There are 2^2^5 (around 4.3 billion) number of possible CA for r = 2, k = 2 and around 2^2^7 number of possible CA for r = 3, k = 2, so it was computationally impossible for me to go through each and every one of those CA without crashing my kernel repeatedly, so I had to pick and choose (in the future, if I have access to powerful computers, I'd want to modify my algorithm and test every one of those CA). Example for r = 2: Select[Table[{n, Flatten@CellularAutomaton[{n, 2, 2}, RandomChoice[{1, 0}, 128], {{1000}}]}, {n, 1, 20000}], (60< Count[#[[2]], 0] < 75) &]; Example for r = 3: Select[Table[{n, Flatten@CellularAutomaton[{n, 2, 3}, RandomChoice[{1, 0}, 128], {{1000}}]}, {n, 123308249090345280300093458548552398347, 123308249090345280300093458548552438347}], (60 < Count[#[[2]], 0] < 70) &] I changed the parameters to go through more rules, so, in total for r = 2, k = 2, I went through the rules between 21000-65000, 65001 - 120000, 120001 - 200000, 200001 - 300001, 300002 - 600000, 600001 - 1000000, 1000001 - 1500000, 2000001 - 2500001, 90409230 - 90999240, 953402389 - 1094838934, 3008324031 - 3008563853, 2309409238 - 2309732198, 1094838929 - 1094939529. I only selected the rules that had between 55 and 75 0s (or between 60 and 70 0s for the larger rules) because I want approximately the same amount of 1s and 0s in the rules I use to make sure that I am using chaotic and random CA. For r = 3, k = 2, I looked at the rules from 90280300834552398346 - 90280300834552598349, 9090345280300834552398347 - 909034528030083454308552458347, 123909034528030083454308552398347 - 123909034528030083454308552410347, 12330824909034528030083454308552298347 - 12330824909034528030083454308552438347, 123308249090345280300093458548552398347 - 123308249090345280300093458548552438347, 58437598988924093823479989347 - 58437598988924093823479999347, 584378988924093823479989347 - 584378988924093823479999347, 9843095354984375023479989347 - 9843095354984375023479999999, 910843095354984375023479789347 - 910843095354984375023479989347. f = BooleanFunction[# /. {0 -> False, 1 -> True}, {a, b, c, p, q, t, u}] & I found the Boolean functions representing each rule for the CA in each range. Because I was going through so many rules, for many operations, I had to export the list of rules in text files that way I can just read those text files after my kernel crashes without having to evaluate the previous cells Then I ran Boolean Minimize on each Boolean Function for every rule. evenBetterRules = Table[{n[[1]], BooleanMinimize[n[[2]]]}, {n, ReadList["bestRules.txt"]}] I found the Leaf Counts for every Boolean Function after compressing each one. leafCountRules = Table[{n[[1]], LeafCount[n[[2]]]}, {n, ReadList["evenBetterRules.txt"]}]; I created a Distribution (Histogram) of the aforementioned leaf counts, then I took the rules at the 90th percentile graphOfDist = HistogramDistribution[ReadList["leafCountRules.txt"][[All, 2]]] This is what the histogram looks like for r = 3 ![enter image description here][1] It looks approximately normally distributed which is interesting. I took the rules at the 99.95 percentile for r = 2, listOfRules = Select[ReadList["leafCountRules.txt"], Last[#] > Floor[Quantile[graphOfDist, 0.9995]] &] and rules at the 95th percentile for r = 3. setOfRules = Select[leafCountRules, Last[#] > Quantile[w, 0.95] &] I then found the amount of information entropy in each CA (interestingly enough, I found that the max entropy of the rules for CA in r = 2, 3, k = 2 was 6.9085, no CA had more entropy than that) and found the rules whose information entropy exceeded 6.5. The following is the code for r = 3 theBestRules = Select[rules, N[Entropy[CellularAutomaton[{#, 2, 3}, RandomChoice[{1, 0}, 128], 1000]]] > 6.5 &] Then, I converted each CA in my new small set of rules into JPEG images and using file conversion compression algorithms; the following is the code for r = 3, just replicate the same process with r = 2. arrayPlotOfBestRulesr3k2 = Table[ArrayPlot[CellularAutomaton[{theBestRules[[n]], 2, 3}, RandomChoice[{1, 0}, 128], 1000]], {n, 1, Length[theBestRules]}]; picsOfBestRulesr3k2 = Table[Export[StringJoin[StringJoin["r3k2rule", ToString[n]], ".jpg"], arrayPlotOfBestRulesr3k2[[n]]], {n, 1, Length[theBestRules]}]; secondFinalSetOfRules = Table[{theBestRules[[n]], FileByteCount[picsOfBestRulesr3k2[[n]]]}, {n, 1, Length[theBestRules]}] I created a Distribution (Histogram) of file byte sizes for each CA then I took the CA at the 95th percentile and found that all of those CA at the 95th percentile were very complex, chaotic and had no pattern, and this distribution also looked approximately normally distributed (for r = 2, I took the CA at the 85th percentile, these were also very complex CA, but the distribution of file byte sizes for r = 2 was not normally distributed). ![enter image description here][2] Distribution = HistogramDistribution[FileByteCount /@ picsOfBestRulesr3k2] finalSetOfRulesr3k2 = Select[secondFinalSetOfRules, Last[#] > Quantile[Distribution, 0.95] &] An example of one of the CA at the 95th percentile in terms of file byte size for r = 3, this is rule 123308249090345280300093458548552398368 up to 1000 evolutionary steps: ArrayPlot[CellularAutomaton[{123308249090345280300093458548552398368, 2, 3}, RandomChoice[{1, 0}, 128], 1000]] ![enter image description here][3] To generate hash codes for inputs based off of my new set of CA, I converted the user's input into their binary representation, then I took the first n bits (length specified by the user, and if their input's binary representation was shorter than the user's specified length, then my algorithm pads their input's binary representation with 0s) and used that as the initial condition for a random CA rule (range specified by user) while the kth row is generated by taking the base-10 representation of the user's input, squaring it, and doing that number mod a random prime number between 2^10 and 2^15 (similar to Rabin cryptosystem processes), then the first n bits of that row are used as the hash code. I created a block system similar to Merkle Damgård Construction, so I partition the user's input into x amount of blocks where x is a multiple of the length of the hash code as specified by the user, then I use the hash code for the first block as an input as the initial conditions for the CA in the second block, then I take the hash code of the input in the second block and I perform the XOR operation on the hash codes from the first block and the second block and use that as the input for the third block,etc. The hash code from the final block is used as the final hash code of the user's message/input/password. In my algorithm, I got the number 57203 (from the process similar to Rabin's cryptosystem as described earlier) as the nth row to get the hash code for each block, and I decided to use the rule 2309726947 as the CA for r = 2, k = 2 and rule 123308249090345280300093458548552398368 for r = 3, k = 2. The user, through my microsite, can enter their message along with the length of the hash code and the range of the CA, so for example, if they enter in their message to get a hash code with length 128 using r = 2, my algorithm will generate the hash code for their message using rule 2309726947 at the 57203th evolutionary step. The predetermined nth evolutionary step helps ensure that the user will get the same hash code for the same input rather than fully implementing the random function in the algorithm which will produce a different nth row for every input meaning a different hash code for the same inputs which is NOT what we want. Here is my code for the described process: RoundFunctionr2k2[block_] := Flatten@CellularAutomaton[{2309726947, 2, 2}, block, {{PowerMod[FromDigits[block], 2, 57203]}}] RoundFunctionr3k2[block_] := Flatten@CellularAutomaton[{123308249090345280300093458548552398368, 2, 3}, block, {{PowerMod[FromDigits[block], 2, 57203]}}] CAHash[message_, len_, range_] := Block[{blocks = Partition[ImportString[ToString[message],"Bit"], len, len, 1, 0]}, If[range == 2, StringJoin[ToString/@Fold[RoundFunctionr2k2@BitXor[#1, #2] &,RoundFunctionr2k2[blocks[[1]]], blocks[[2;;]]]], If[range == 3, StringJoin[ToString/@Fold[RoundFunctionr3k2@BitXor[#1, #2] &,RoundFunctionr3k2[blocks[[1]]], blocks[[2;;]]]]]] ] After this, I wanted show that my hash code algorithm based off of cellular automata was really strong by showing that no two rows would be the same in two cases: by checking the CA if you had random initial conditions, but the same row, and by checking the CA if you had the same initial conditions(still random initial conditions) but different amount (random) of rows. You can use random initial conditions for the CA because it's supposed to represent the user's input and since there are so many possible inputs, it might as well just be random. For the first case, r = 2, my code is shown here: Block[{in = RandomChoice[{1, 0}, 128]}, Sort[Tally@(CellularAutomaton[{2309726947, 2, 2}, in, PowerMod[FromDigits[in], 2, 57203]]), #1[[2]] > #2[[2]] &]] and r = 3, Block[{in = RandomChoice[{1, 0}, 128]}, Sort[Tally@(CellularAutomaton[{\ 123308249090345280300093458548552398368, 2, 3}, in, PowerMod[FromDigits[in], 2, 57203]]), #1[[2]] > #2[[2]] &]] For the second case, r = 2, Block[{in = RandomChoice[{1, 0}, 128]}, Sort[Tally@(CellularAutomaton[{2309726947, 2, 2}, in, PowerMod[FromDigits[in], 2, RandomPrime[{2^10, 2^20}]]]), #1[[2]] > #2[[2]] &]] and r = 3, Block[{in = RandomChoice[{1, 0}, 128]}, Sort[Tally@(CellularAutomaton[{\ 123308249090345280300093458548552398368, 2, 3}, in, PowerMod[FromDigits[in], 2, RandomPrime[{2^10, 2^20}]]]), #1[[2]] > #2[[2]] &]] And for both cases, each row only occurs once! Here is the link to my microsite where you can test out my program: [https://www.wolframcloud.com/objects/ccc4a4f1-b362-431d-8f71-5688908ecfa7][4] -------- #Reflections and Extensions ----------- This project really gave me a taste of what software development was all about because almost everyday was full of intense work on my project including many rounds of just revisions and experimenting with Mathematica. My original vision for my project was not able to come into fruition because 2 weeks weren't enough to fully develop my project, but I will be hard at work refining and perfecting my novel algorithm. I personally think that my cryptographic hash code algorithm based off of Cellular Automata can be used to replace current cryptographic hash code algorithms implemented to secure passwords, securing file transfers, implemented in cryptocurrencies, etc., but I'm working hard to prove that it is better. In the future, I want to find complex CA and test each rule from r = 1 to r = 5 (or even r = 10) on more powerful computers to compile a list of CA fit to use for my cryptographic hash code algorithm. I also want to explore further methods of making my system more safe and secure than current cryptographic hash code algorithms (like SHA-256, SHA-512, etc.) because I believe that chaotic cellular automata can serve very useful purposes in cryptography, and chaotic/disordered CAs will allow for more secure cryptographic systems in the future. Also, I want to learn more about cryptanalysis and methods of cryptanalysis, so that I can try to break my own system, and if I can't (or if anyone else can't), then I'll try to prove that my cryptographic system is more secure than current cryptographic hash code algorithms (and if my system is "breakable", then I'll try my best to improve my system). I'm going to learn about more secure cryptosystems implemented in other hash functions to see if I can use those in junction with CA to create better cryptographic hash code algorithms based on CA that are harder to brute force than current hash functions like SHA-256 or SHA-512. [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=histogramr3k2leafcounts.png&userId=1138050 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=histogramr3k2filebytesize.png&userId=1138050 [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=rule123308249090345280300093458548552398368r3k2OneThousteps.png&userId=1138050 [4]: https://www.wolframcloud.com/objects/65d6c0a7-ce23-4f7e-8929-dd1e1df952d2 Rishu Mohanka 2017-07-07T01:24:13Z https://community.wolfram.com/groups/-/m/t/1139804 Description ----------- In this exploration, I explored the halting times of Turing machines. A Turing machine is essentially consists of a set of rules that can be applied to successive cells on a infinitely long tape of typically blank cells. Each step in a Turing machine is characterized by the state (color) of the current cell and the direction in which the head is turned. A set of rules for a Turing machine might resemble as follow: ![Rule 1507][1] This rule dictates, for example, that when the head is position 1 (up) and the cell it is on is likewise in position 1 (orange), the cell below it should become orange and the head, still facing up, should move a distance of -1 (one unit left). This can be notated as {1,1} -> {1,1,-1}. A common issue in the study of Turing machines is the halting problem, or whether and when a Turing machine will cease moving. Generally, this problem has been proved to be incomputable. However, it is possible to determine halting probabilities for more specific cases. I have investigated two definitions of halting in the following study. The first defines halting within the rules of a Turing machine; that is, when a Turing machine reaches a particular head-cell combination, it will halt. The second defines halting merely as a cessation of changing cell states. When a halting state is reached in this instance, the head may move as it pleases, but the resulting cell states will not differ from step to step. ---------- Basic Points ------------ Some basic principles to establish: - A Turing machine can do one of three things: halt relatively quickly, never halt, or continue on for an indefinite amount of time before reaching a halt state. - This third instance generally pertain to Turing machines where it is not obvious that the machine will never halt. After all, in some cases the repetition of steps in a machine leaves no room for halting motion. - For the sake of simplicity, these three kinds of machines will be referred to as halting, non-halting, and weird Turing machines. - A Turing machine will not halt unless some halt state is specified. - There will always be some rule dictating what the machine should do next that correspond to the current position of the head and cell. - Therefore, for a Turing machine to halt it needs some rule in some way, shape, or form that corresponds to a halt state. - A Turing machine does not necessarily halt even if a halt state is specified. - For example, a machine may enter a loop here it goes through the same few steps infinitely, never achieving a halt state. - On the other hand, some Turing machines halt immediately; the first step they take is halting. - Given a known maximum halting time for a specific kind of Turing machine, any machine that does not halt before the maximum time will not halt after. ---------- Halting as Defined by Rules --------------------------- As aforementioned, a Turing machine will not halt unless some halt state is specified. In this instance, the halt state for a given Turing machine was defined within the set of rules in a manner similar to busy beaver Turing machines. Busy beavers are machines with n head states and 2 cell states (denoted n, 2) which attempt to achieve the maximum amount of a given cell state before halting with known maximum halt values of 6, 24, and 107 step for 2, 3, and 4 head states, respectively. The rules can be defined by assigning every head state (s) on a cell of state (a) to a new head state (sp), cell state (ap), and head displacement (off), denoted {s, a} -> {sp, ap, off}. Here, the halt state was indicated by assigning a single {s, a} in any set of rules to {0, 3, 0}. In practice, this did not actually halt the Turing Machine, but it did provide a method to determine when a machine would have halted. As no other rule would result in a head state of zero or a cell state of three, it was easy to identify both visually and computationally which machines "halted". The below functions describe the process for finding the probability whether and when a 2, 2 Turing machine will halt. TM[n_, x_] := TuringMachine[n, {1, {{}, 0}}, x] (* A simpler, more convenient way to write the TuringMachine function. *) HEADS2 = Permutations[Flatten[Table[{i, j}, {i, 1, 2}, {j, 0, 1}], 1]]; (* Creates all possible head states *) pCELLS2 = Permutations[Flatten[Table[{i, j, k}, {i, 1, 2}, {j, 0, 1}, {k,{-1, 1}}],2],{3}]; (* Creates all possible cell states *) RuleMaker2[x_] := Table[Join[Thread[Rule[Rest[x], pCELLS2[[m]]]], {First[x] -> {0, 3, 0}}], {m,1, Length[pCELLS2]}] (*Creates machine rules*) Halting2 = Flatten[Table[ Select[RuleMaker2[n], ! FreeQ[TM[#, 8], {0, _, _}] &], {n, HEADS2}], 1]; (* Lists all sets of rules that eventually halt*) NonHalting = Flatten[Table[ Select[RuleMaker2[n], FreeQ[TM[#, 8], {0, _, _}] &], {n, HEADS2}], 1]; (* Lists all sets of rules that do not halt*) N[Length[Halting2]/(Plus[Length[Halting2], Length[NonHalting]])] (* Gives approximate halting probability*) The last functions returns that any given 2,2 Turing machine with a halting state defined in its rules has about a 43.3% chance of halting. The total amount of rules that halt at a certain step is given by the following function: HaltStep1 = KeySort[Counts[Table[First@Flatten[Position[First /@ TM[#, 8] &@n, {0, _, _}]] - 1, {n, Halting2}]]] Thread[Rule[Keys[HaltStep1], Table[N[x/100] "%", {x,HaltStep1}]]] (* The percentage of machines that halted at a certain step*) The -1 accounts for the initial step listed in the returned machine. The results of these functions are that: <|1 -> 2016, 2 -> 1008, 3 -> 288, 4 -> 108, 5 -> 12, 6 -> 60|> {1 -> 20.16 "%", 2 -> 10.08 "%", 3 -> 2.88 "%", 4 -> 1.08 "%", 5 -> 0.12 "%", 6 -> 0.6 "%"} Corresponding list plot that plots the step at which a function halts against how many functions halt at that step: ![enter image description here][2] For the most part, there is a great downward trend concerning at what step a 2,2 Turing machine halts. It is far more likely for a machine to halt at the first step than at the sixth. This makes a certain amount of sense. The Turing machines that halted at the first step would have to consist of all those whose rules dictated that when the head state is 1 and the cell state is 0, halt. Any rule with this as part of its rule set will definitely halt on step 1. However, those rules that halt on step 2 had to depend on two factors: the rule dictating what should happen after the initial state, and the rule dictating what should be done after that. It would follow that this compounding complexity results in less instances of halting. And of course, each step results in more complexities, leading to less instance of halting. However, it so happens a machine is five times more likely to halt at the sixth step than at the fifth. This may be a quirk of 2,2 Turin machines, I suppose, or it may be that at a certain point complexities begin to cancel out. If this is the case, then it would be something like mixing up a Rubik's cube. You can only mix up the pieces to a certain degree; after that, some moves begin to solve it, if even a little. It would seem that the increasing complexity is counteracted enough by this effect in order to produce more halting Turing machines than expected. Furthermore, although the curve is relatively smooth, no function approximates it quite that well. FindFormula[List @@ HaltStep1]; Plot[1128.` + 3291.8` #1 - 3435.5` #1^2.` + 1204.` #1^3.` -182.5` #1^4.` + 10.2` #1^5.` &@x, {x, 0, 7}] ![enter image description here][3] Theoretically, the above process could be performed for 2,3 and 2,4 Turing machines as well. However, the run time to Halting3 (the 2,3 machine counterpart to Halting2) was taking so long so as to be incompatible with my time constraints, and it could be imagined that functions dealing with 2,4 machines would take even longer. An example of functions that could potentially produce results if run: HEADS3 = Permutations[Flatten[Table[{i, j}, {i, 1, 3}, {j, 0, 1}], 1]]; pCELLS3 = Permutations[ Flatten[Table[{i, j, k}, {i, 1, 3}, {j, 0, 1}, {k, {-1, 1}}], 2], {5}]; RuleMaker3[x_] := Table[Join[ Thread[Rule[Rest[x], pCELLS3[[m]]]], {First[x] -> {0, 3, 0}}], {m, 1, Length[pCELLS3]}] Halting3 = Flatten[Table[ Select[RuleMaker3[ Part[HEADS3, RandomInteger[720]]], ! FreeQ[TM[#, 26], {0, _, _}] &], 10], 1]; Overall, the function `FreeQ[TM[n_List, x_],{0,_,_}]&]` can be used on a single Turing machine with a halting state defined in its rules in order to determine whether it will halt. ---------- Halting as Defined by Cell State -------------------------------- An alternative way to define a halting state could be to claim the machine halts when the cell state no longer changes from step to step. This, however, allows for the head to keep changing position. To check to see whether this happens in a Turing machine without a halt state explicitly defined in its rules, I created a function that looks for three repeats in a row at x-1, x, and x+1 steps, then checked to see whether this pattern held true at 2x. Originally, I had not thought to check the pattern at 2x, as it seemed natural to me that a Turing machine that produces the same result three times in a row would continue to do so for the fourth, fifth, sixth, etc. time. However, I had discounted the fact that the head moves and may be in different positions even when cell states are identical, leading to a mistake in computations that I caught when I plotted the halt times of various Turing machines and discovered surprising outliers that could only be accounted for by the fact that they don't actually halt. In the following incorrect Plot, older and incorrect versions of RepeatingBoolean and HaltWhen are being used. These will be defined correctly later. RepeatingBoolean returns True if a function repeats and therefore halts at a point, and HaltWhen checks at what point the repeating state first occurs, indicating the halt state. ListPlot[Counts[Table[Module[{x = RandomInteger[4095]}, If[RepeatingBoolean[x, 100], HaltWhen[x, 100]]], 1000]]] ![enter image description here][4] Note how most Turing machines had halted, as expected, between 0 and 5 steps. Some machines, however, appeared to halt close to the 100th step when in fact they merely had three identical cell states at that point. The proper way to follow through with this process goes as follow: RepeatingTM[rule_, n_] := If[Apply[SameQ, Last /@ Part[#, {n - 1, n, n + 1, 2 n}] &@TM[#, 2 n] &@ rule], {rule, "Halts"}, {rule, "Doesn't Halt"}] (*Takes a rule and the number of steps the rule should run and returns whether a given rule halts or not*) HaltWhen[rule_, n_] := First@First@Position[TM[rule, 2 n], Last@Part[TM[rule, 2 n], 2 n]] - 1 (* Shows at what step a function halts.*) The -1 in the above function accounts for the fact that some Turing machines may "halt" from their initial position: they never changed from their initial state, and halt at step 0. Here n should represent the same n used in RepeatingTM, as it might not necessarily work if a smaller value is chosen. Although this function will produce a result for a non-halting function, it shouldn't be used for that purpose. ProbabilityTM[h_, k_] := N[Mean[#]/1000] &@ Table[Length[ Select[Table[ RepeatingTM[{RandomInteger[(2 h k)^(h k) - 1], h, k}, 100], 1000], ! FreeQ[#, {_, "Halts"}] &]], 20] This function takes h to be amount of head states of a machine and k to be the amount of cell states in a Turing machine. It then generates 1000 random Turing machines (where the rule is represented as a number between 0 to ((2 h k)^(h k)-1), the total amount of possible h,k Turing machines) and checks after 100 steps whether it halts or not. This should be sufficient for most machines. Using the above function, one can generate a table of probabilities for Turing machines ranging from having 2 head and 2 cell states to those having 6 head and 6 cell states. ProbabilityTable = Table[ProbabilityTM[i, j], {i, 2, 6}, {j, 2, 6}]; Grid[Join[{{"h\c", 2, 3, 4, 5, 6}}, Table[Prepend[Part[ProbabilityTable, k - 1], k], {k, 2, 6}]], Frame -> All] ![enter image description here][5] In the above grid, the "h" column represents the amount of head states of a Turing machine while the "c" row represents the cell states. (The error indicated on the right side of the cell only occurs because \c is "an unknown string escape". As I am using the notation h\c only to more clearly label the grid, this error is inconsequential.) This data can be used to observe trends both when the cell states keep constant while the head states change and when the head states are constant and the cell state changes. (* Cell states constant, head states change*) ListLinePlot[ Table[{i + 1, Part[#, j] &@Part[ProbabilityTable, i]}, {j, 1, 5}, {i, 1, 5}], PlotLegends -> {"h, 2", "h, 3", "h, 4", "h, 5", "h, 6"}, AxesLabel -> { "Head State", "Probability of Halting"}] ![enter image description here][6] (* Head states constant, cell states change*) ListLinePlot[ Table[{i + 1, Part[#, i] &@Part[ProbabilityTable, j]}, {j, 1, 5}, {i, 1, 5}], PlotLegends -> {"2, c", "3, c", "4, c", "5, c", "6, c"}, AxesLabel -> { "Cell State", "Probability of Halting"}] ![enter image description here][7] The cell state appears to determine halting probabilities to a greater degree than cell state. This makes sense, as per this definition of halting it was cell state, not head state, that determined when a machine should stop. In that respect it must be that head state alters halting probability only by increasing the complexity of the machine. As described in context with Halting1, an increase in complexity gives more possible states for a machine to be in, though the amount of those states that result in halting may not increase. Although it is possible to find functions that somewhat resemble the above plots, for the most part approximations are still inaccurate. Constant Cell States: FindFormula /@ Table[{i + 1, Part[#, j] &@Part[ProbabilityTable, i]}, {j, 1, 5}, {i, 1, 5}]; Table[Plot[Part[%24, k]@x, {x, 0, 7}], {k, 1, 5}] ![enter image description here][8] Constant Head States: FindFormula /@ Table[{i + 1, Part[#, i] &@Part[ProbabilityTable, j]}, {j, 1, 5}, {i, 1, 5}]; Table[Plot[Part[%26, k]@x, {x, 0, 7}], {k, 1, 5}] ![enter image description here][9] The below function randomly selects 2,2 Turing machines and detects when those that halt do so. RepeatingBoolean[rule_, n_] := Apply[SameQ, Last /@ Part[#, {n - 1, n, n + 1, 2 n}] &@TM[#, 2 n] &@rule] (* Returns TRUE when a machine halts and FALSE when it doesn't *) HaltStep22 = KeySort[Merge[{Counts[ Table[If[RepeatingBoolean[x, 100], HaltWhen[x, 100]], {x, 0, 4095}]], <|3 -> 0|>}, Total]] Thread[Rule[Keys[Drop[HaltStep22, -1]], Table[N[100 x/Plus @@ Values[Drop[HaltStep22, -1]]] "%", {x, Values[Drop[HaltStep22, -1]]}]]] This returns: <|0 -> 1568, 1 -> 178, 2 -> 20, 3 -> 0, 4 -> 6, 5 -> 2, Null -> 2322|> {0 -> 88.3878 "%", 1 -> 10.0338 "%", 2 -> 1.1274 "%", 3 -> 0., 4 -> 0.338219 "%", 5 -> 0.11274 "%"} Corresponding list plot: ![enter image description here][10] Although the halt times for HaltStep1 ranged from 1 to 6, the halt times for HaltStep22 ranged from 0 to 5. This arises mainly through the different definitions of "halting" in each case. For example, it would clearly be impossible for a machine to halt after 0 steps using the first definition; that would mean that it halted before it even started. This, however, is acceptable per the second definition, as this definition describes a change in state rather than a state in itself. That is, when there is no change in state, the machine is said to halt, as opposed to reaching a single "halt state". Furthermore, it appears that HaltStep22 never halts at 6 or 3 steps. This may be a random consequence; the low amount of machines that halt at 4 and 5 steps would certainly allow it. However, it is interesting how both in HaltStep1 and HaltStep22 briefly increase after a stretch of decreasing values. Perhaps this corresponds with the aforementioned "canceling out", but more data is needed for a complete conclusion. As with HaltStep1, no function quite approximates this trend. FindFormula[List @@ HaltStep22] Plot[8659.05 - 12756.8 #1 + 7595.42 #1^2 - 2199.33 #1^3 + 265.796 #1^4 + 8.55533 #1^5 - 5.07196 #1^6 + 0.339872 #1^7 &@x, {x, 0, 7}] ![enter image description here][11] Comparing the results of the first definition of halting with the second, it can be noticed that although neither exceed six steps to halt, with HaltStep22 it is generally more likely that the machine will halt at or before the first step. {PieChart[Values[HaltStep1], ChartLabels -> Keys[HaltStep1]], PieChart[ Drop[Values[HaltStep22], -1], ChartLabels -> Placed[Keys[HaltStep22], "RadialOuter"]]} (* Left pie chart represents HaltStep1, right HaltStep2 without the Null values*) ![enter image description here][12] The following chart further emphasizes how much more likely it is for a function to halt at 1, compared to other values, in Halting22. PieChart[ Take[Values[HaltStep22], 2 ;; 6], ChartLabels -> Placed[{1, 2, 3, 4, 5}, "RadialOuter"]] ![enter image description here][13] Much like with the computing issue of Halting1, it is difficult to garner complete information about the halting patterns of higher order Turing machines with this method. Although it is easier to select Turing machines at random, there are substantially more Turing machines to choose from, which requires a larger sample size to accurately depict probabilities. In fact, as there are 2985983 machines of the 2,3 degree, (compared to the 4095 of the 2,2 degree), even 100,000 randomly selected machines may not produce a significant percentage of halting machines. Halt23 = KeySort[Counts[ Module[{x = RandomInteger[2985983]}, Table[If[RepeatingBoolean[{x, 2, 3}, 100], HaltWhen[{x, 2, 3}, 100], "NONHALTING"], 100000]]]] This usually returns `<|"NONHALTING" -> 100000|>`. ---------- Weird Turing Machines --------------------- For most Turing machines, it is simple to determine after a relatively small number of steps whether it will halt or not. However, there exist some Turing machines that will appear to never halt but will actually reach a halt state (per the second definition) after a tremendous amount of steps. The following functions work much like RepeatingBoolean, only they have the option to check a greater number of steps per a given input. WeirdTM[weird_, n_, max_] := NestWhileList[ Plus[#, 1000] &, n, ! RepeatingBoolean[weird, #] &, 1,max] WeirdHalt[weird_, n_, max_] := If[Length[WeirdTM[weird, n, max]] == max + 1, "NEVER HALTS", StringJoin["HALTS AT ", ToString[HaltWhen[weird, n]]]] Here WeirdTM takes a single Turing machine running for n steps at a time, adding 1000 to n every cycle. This cycle will occur a specified max number of times. WeirdTM then returns a list of all values of n used to achieve it goal (either by halting, making !RepeatingBoolean false, or by reaching the max value). WeirdHalt then checks the length of this list; if its length is equivalent to the length the list would have had if n cycled through the max number times, the function returns that it never halts, but if the length of the list is shorter that, apparently the machine halted at some point, prompted the function to return when the machine halted. These "weird" machines are relatively rare, and are tricky to detect through their resemblance to Turing machines that never halt. The above functions are best for Turing machines know to be complex and suspected of eventually halting. Most machines, however, clearly either halt or don't, leaving little confusion. Furthermore, weird Turing machines can be compressed in order to reach farther steps (or to check out interesting though not necessarily halting patterns). Left-compression only returns the steps when the head is farther left than it ever was before, and right-compression only returns the steps when the head is farther right than it ever was before. CompressedRepeatingBoolean works much the same way as RepeatingBoolean, only that it first decides whether left-compression is applicable in the given situation. If, for example, the machine never moves left at all, right-compression will be used instead. Admittedly, though, there may exist machines that may move left for long enough that SameQ[LeftCompression[rule, 20 n],{}] returns false, prompting it to use left-compression, even though it may eventually continue only on the right side. Still, if this is the case, then CompressedWeirdTM would still detect a string of unchanging, blank values after a certain point, indicating a "halt". Furthermore, due to a lack of data concerning "weird" Turing machines, it is not certain that this situation can arise at all. LeftCompression[rule_, n_] := Module[{s = {1}, ls = {}}, Table[If[Last@First@Part[TM[rule, n], i] < Min[s], {AppendTo[s, Last@First@Part[TM[rule, n], i]], AppendTo[ls, Last@Part[TM[rule, n], i]]}, Nothing], {i, 2, n}]; ls] RightCompression[rule_, n_] := Module[{s = {-1}, ls = {}}, Table[If[Last@First@Part[TM[rule, n], i] > Max[s], {AppendTo[s, Last@First@Part[TM[rule, n], i]], AppendTo[ls, Last@Part[TM[rule, n], i]]}, Nothing], {i, 2, n}]; ls] CompressedRepeatingBoolean[rule_, n_] := Module[ {x}, x = If[SameQ[LeftCompression[rule, 20 n], {}], RightCompression[rule, 20 n], LeftCompression[rule, 20 n]]; Apply[SameQ, Part[#, {n - 1, n, n + 1, 2 n}] &@x]] CompressedWeirdTM[weird_, n_, max_] := NestWhileList[ Plus[#, 1000] &, n, ! CompressedRepeatingBoolean[weird, #] &, 1, max] CompressedWeirdHalt[weird_, n_, max_] := If[Length[CompressedWeirdTM[weird, n, max]] == max + 1, "NEVER HALTS", StringJoin["HALTS AT ", ToString[HaltWhen[weird, n]]]] As a side note, here is a cool application of using compression on more complex Turing machines: {ArrayPlot[Last /@ TM[{596440, 2, 3}, 100]], ArrayPlot[RightCompression[{596440, 2, 3}, 1000]], ArrayPlot[LeftCompression[{596440, 2, 3}, 1000]]} ![enter image description here][14] This is not particularly related to the above study, but it demonstrates compression well. ---------- Conclusion ---------- When halting is defined within the rules of a 2,2 Turing machine, there is an overall 43.3% chance that any given machine will halt. Of those that halt, the chances of a machine halting at a given step goes as follows: 1-> 20.16 % 2-> 10.08 % 3-> 2.88 % 4-> 1.08 % 5-> 0.12 % 6-> 0.6 % For the most part the probability of halting at a given step decreases as the amount of steps increase, presumably because of issues with complexity. The fact that a machine is more likely to halt at step 6 than at step 5 is possible either a random incongruity or a result of cancelling complexities. When halting is defined as a lack of change in cell state, overall probabilities for 2,2 machines up to 6,6 machines are given by this chart: ![enter image description here][15] For 2,2 Turing machines, the likelihoods of a machine halting at given steps are as follows: 0-> 88.3878 % 1-> 10.0338 % 2-> 1.1274 % 3-> 0. 4 ->0.338219 % 5-> 0.11274 % Weird, eventually halting Turing machines can theoretically be detected by using methods similar to the second process of determining halting times. However, due to their scarcity and my own computing limitations I lack enough examples to come to an acceptable conclusion concerning them. In either case of halting, it would be nice to have more data concerning higher order Turing machines so that more accurate conclusions may be reached about the probability trends. In this study, computing time (and possibly memory storage) was mainly the issue. To fix this I could find more concise functions to achieve my purposes, or I suppose that the functions could be run as they are when I can spare my laptop for a few days. For now, though, these results should suffice. [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Final_Project.png&userId=1138184 [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=HaltStep1Plot.png&userId=1138184 [3]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ApproxHalt1.png&userId=1138184 [4]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Wring.png&userId=1138184 [5]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-44-22.png&userId=1138184 [6]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-46-12.png&userId=1138184 [7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-47-26.png&userId=1138184 [8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-55-36.png&userId=1138184 [9]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-57-01.png&userId=1138184 [10]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Halt22.png&userId=1138184 [11]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Approx22.png&userId=1138184 [12]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0615-06-09.png&userId=1138184 [13]: http://community.wolfram.com//c/portal/getImageAttachment?filename=PieChart.png&userId=1138184 [14]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0615-17-29.png&userId=1138184 [15]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Screenshotfrom2017-07-0614-44-22.png&userId=1138184 Katarzyna Krzyzanska 2017-07-06T22:40:45Z https://community.wolfram.com/groups/-/m/t/1017048 ![Variant of Rule 90 in which black squares are generated 99% instead of 100% of the time][1] ## Introduction ## During the summer of my junior year, I participated in the Wolfram Summer Camp, a program which gave me the unique opportunity to learn and explore the Wolfram Language. After completing a project on predicting the trends of the Housing Price Index, I was so fascinated by the unimaginably powerful capabilities of the Wolfram Language that I began looking for other opportunities to further explore in this amazing language. Through the Wolfram Mentorship program, I have been able to continue doing so. Interested in computational mathematics, I began working on the "Probabilistic Cellular Automata" project with the objective of creating the most efficient Mathematica program that can output cellular automaton based on eight predetermined probabilities. ## Cellular Automaton ## A traditional cellular automaton function has three basic components: the initial list, the rule, and the number of iterations. For those who are unfair with this concept, the initial list is simply a list of 0's and 1's which correspond to white and black, respectively. The rule is essentially a function that takes a sequence of three digits and outputs a 0 or 1. For example, for rule 30, the list {0,0,0} gives 0, {0,0,1} gives 1, {0,1,0} give 1, etc. Since there are eight possible three digit sequences of zeros and ones, there are 2^8 = 256 rules. The number of iterations is just the number of times we apply the same rule to the new list. One can see that the traditional cellular automaton function is limited to only 256 possibilities and that the sequences or images are predetermined. To address these shortcomings, I have created a Probabilistic Cellular Automaton function in which the output of a given list of three digits will be based on a probability. For example, the sequence {1,0,1} will output 1 80% of the time and 0 the other 20% of the time. ## Initial Coding ## Creating a function that performs accurate iterations is not a difficult task. One only needs to consider the probabilities for each of the eight possible three-term sequences. Such code is shown below: PCA[{p7_, p6_, p5_, p4_, p3_, p2_, p1_, p0_}, init_, t_] := NestList[ Replace[Partition[#, 3, 1, 2], {{1, 1, 1} :> RandomChoice[{p7, 1 - p7} -> {1, 0}], {1, 1, 0} :> RandomChoice[{p6, 1 - p6} -> {1, 0}], {1, 0, 1} :> RandomChoice[{p5, 1 - p5} -> {1, 0}], {1, 0, 0} :> RandomChoice[{p4, 1 - p4} -> {1, 0}], {0, 1, 1} :> RandomChoice[{p3, 1 - p3} -> {1, 0}], {0, 1, 0} :> RandomChoice[{p2, 1 - p2} -> {1, 0}], {0, 0, 1} :> RandomChoice[{p1, 1 - p1} -> {1, 0}], {0, 0, 0} :> RandomChoice[{p0, 1 - p0} -> {1, 0}]}, {1}] &, init, t] While this code will compute the result, it is inefficient for large iterations.After creating my first working function, I experimented with several other functions and compared their efficiency through the Repeated Timing function. Some of the other codes I created are listed below: PCAUnitStep[{p7_, p6_, p5_, p4_, p3_, p2_, p1_, p0_}, init_, t_] := NestList[ Replace[ Partition[#, 3, 1, 2], {{1, 1, 1} :> UnitStep[RandomReal[1] - (1 - p7)] , {1, 1, 0} :> UnitStep[RandomReal[1] - (1 - p6)], {1, 0, 1} :> UnitStep[RandomReal[1] - (1 - p5)], {1, 0, 0} :> UnitStep[RandomReal[1] - (1 - p4)], {0, 1, 1} :> UnitStep[RandomReal[1] - (1 - p3)], {0, 1, 0} :> UnitStep[RandomReal[1] - (1 - p2)], {0, 0, 1} :> UnitStep[RandomReal[1] - (1 - p1)], {0, 0, 0} :> UnitStep[RandomReal[1] - (1 - p0)]}, {1}] &, init, t] Using FoldList and another function: f[probabilities_, list_] := probabilities[[FromDigits[#, 2] + 1]] & /@ Partition[list, 3, 1, 2] PCAUnitStep2[{p7_, p6_, p5_, p4_, p3_, p2_, p1_, p0_}, init_, t_] := FoldList[f[#2, #1] &, init, Table[{UnitStep[-RandomReal[1] + (p7)], UnitStep[-RandomReal[1] + p6], UnitStep[-RandomReal[1] + p5], UnitStep[-RandomReal[1] + (p4)], UnitStep[-RandomReal[1] + (p3)], UnitStep[-RandomReal[1] + (p2)], UnitStep[-RandomReal[1] + (p1)], UnitStep[-RandomReal[1] + (p0)]}, t]] Using NestList and Partition: PCA3[prob_, init_, t_] := NestList[UnitStep[-RandomReal[1, Length[init]] + (prob[[ FromDigits[#, 2] + 1 & /@ Partition[#, 3, 1, 2]]])] &, init, t] And using FoldList and Partition: PCA4[prob_, init_, t_] := FoldList[ UnitStep[-#2 + (prob[[ FromDigits[#, 2] + 1 & /@ Partition[#1, 3, 1, 2]]])] &, init, RandomReal[1, {t, Length[init]}]] Through trial and error, I eventually arrived at the most efficient code (of the ones I've tried). The code is shown below: PCA5[prob_, init_, t_] := FoldList[ UnitStep[-#2 + (prob[[ListConvolve[{1, 2, 4}, #1, 2] + 1]])] &, init, RandomReal[1, {t, Length[init]}]] ## Probabilistic Cellular Automaton versus Traditional Cellular Automaton ## Below are the arrays plots of two cellular automaton. The first one is generated using rule 126 while the second one uses probabilities that are really close to rule 126 but differs by 1% when generating black squares. ![Traditional Cellular Automaton (using probability list {0, 1, 1, 1, 1, 1, 1, 0})][7]![Probabilistic Cellular Automaton (Using probability list {0, 0.99, 0.99, 0.99, 0.99, 0.99, 0.99, 0.99 ,0})][8] It is interesting to see how even though the codes are more than 99% alike, the images can differ so drastically. ## Challenges Faced ## This project was more difficult in the beginning since I was still inexperienced with many of Mathematica's functions. It took me a long time to figure out how to properly use each one and also my knowledge was limited to only what I had learned through the Wolfram Summer Camp. Overall, the most difficult aspect of the project was finding functions that could make my code more efficient. ## Conclusion ## From this project, I have learned how to use several functions in Mathematica and have gleaned valuable insights into programming. This experience helped me understand the seemingly easy yet actually complex process behind creating an efficient function and showed me that simple changes could lead to widely varied results. Links: [Wolfram Summer Camp][4] [Wolfram Mentorship Program][5] [Cellular Automaton][6] [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=pcapic3.png&userId=993979 [4]: http://education.wolfram.com/summer/camp/ "Wolfram Summer Camp" [5]: http://education.wolfram.com/mentorships/ "Wolfram Mentorship Program" [6]: http://mathworld.wolfram.com/CellularAutomaton.html "Cellular Automaton" [7]: http://community.wolfram.com//c/portal/getImageAttachment?filename=3676pcapic4.png&userId=993979 [8]: http://community.wolfram.com//c/portal/getImageAttachment?filename=1468pcapic5.png&userId=993979 Arthur Tseng 2017-02-19T05:23:27Z https://community.wolfram.com/groups/-/m/t/981112 Dear Wolfram friends, Stephen Wolfram's blog ["What Is Spacetime, Really?"][1] refers to what seems to me like a paper . I am really dying to read it. Can someone please point me to the journal in which it was published? Thank you so much! ![enter image description here][2] [1]: http://blog.stephenwolfram.com/2015/12/what-is-spacetime-really/ [2]: http://community.wolfram.com//c/portal/getImageAttachment?filename=6471SW.png&userId=956938 Amin C 2016-12-14T18:31:48Z https://community.wolfram.com/groups/-/m/t/245858 has anyone done a speed comparion of Gosper's Golly program/app (http://golly.sourceforge.net) and the CellularAutomaton function? it would be interesting because e.g. the Game of Life program implemented in CellularAutomaton function (http://www.wolfram.com/language/gallery/implement-conways-game-of-life/) is very fast - much faster than the 3 versions i wrote in the final section of my turorial notes set (http://library.wolfram.com/infocenter/MathSource/5216)/) which surprised me becuase in one of those programs i made direct use of all of the 512 update rules which i expectedd to be quite fast since it directly uses the rule-based, pattern-matching nature of WL). if anyone knows of, or can do, a speed omparision, i'd like to know the results (you'll need to look at the effect of both the grid size and  the number of time steps  - and possibly the initial number of empty (i.e. dead) sites as well - because the relative speed of execution of the various programs can change as a function of these parameter values..  Richard Gaylord 2014-05-01T15:25:59Z