<!-- by repeatedly using the line above and applying one more iteration of our filter, we do rule 110 -->
<use href="#data" y="30" id="line2" filter="url(#rule110)" />
<use href="#line2" y="30" id="line3" filter="url(#rule110)" />
<use href="#line3" y="30" id="line4" filter="url(#rule110)"/>
<use href="#line4" y="30" id="line5" filter="url(#rule110)" />
<use href="#line5" y="30" id="line6" filter="url(#rule110)"/>
<use href="#line6" y="30" id="line7" filter="url(#rule110)" />
<use href="#line7" y="30" id="line8" filter="url(#rule110)"/>
<use href="#line8" y="30" id="line9" filter="url(#rule110)" />
<use href="#line9" y="30" id="line10" filter="url(#rule110)"/>
-a set of states
-set of accepting states
-a transition function
(plus blank symbol, and an alphabet, but not so important here)
Evaluation (computation) is faithfully applying the transition function on the states. Effectively just a set of rules you need to follow. This definition doesn't include a "crank" that you have to turn to make it run. I think copying and pasting could be justified as "evaluating".
\mu-Recursive functions (so allowing primitive recursion) are the types of functions Turing machines can compute, but that is not the definition of a Turing machine.
Infinitely copying and pasting is justified to encode the state, but not to encode the transition function, as is the case here to emulate loops. To encode an infinite loop would require an infinitely long SVG, but a Turing machine requires that the transition function be finitely encoded.
As someone on the GitHub commented, "If you can not construct an SVG that never halts (finishes drawing) SVG can not be turing complete."
Edit: more explicitly, for each state, the user has to manually add the line
<use href="#line[n - 1]" y="30" id="line[n]" filter="url(#rule110)"/>
It may not even be enough: the most basic looping construct (i.e. a bounded for-loop) is primitive recursive, but not Turing complete. You couldn't implement the Ackermann function without more sophisticated tools.
However, it's nice to see how expressive SVG is.
With svg, I think it's fair to say that the halting problem is solvable trivially: every svg program halts. Any language which has a trivial solution to the halting problem is not turing complete. That's the point the parent comment is trying to make I believe.
The browser can clearly decide whether an arbitrary SVG program halts (the answer is always "yes"). If you can reduce every turing machine M to an SVG image so that they are semantically equivalent, but can decide for every SVG program whether it halts, your reduction must be uncomputable as your SVG interpretation could otherwise solve the halting problem.
However, the authors reduction is clearly computable for a given TM/CA rule, so something is wrong here.
You wrote "I don't see why a ... SVG interpreter could solve the halting problem using this..."
The "don't" and "could" imply that given this, an svg interpreter could not solve the halting problem, and thus can't give an answer of "yes".
I was saying you want either "I don't see why it couldn't" (a double negative to say that it could), or "I think an svg program could (removing the "don't").
I'm being incredibly pedantic here, yes. I think we're both on the same page, and you just flipped your thoughts from a double negative sentence to a single positive thought, but didn't fixup the part you had already written.
<use href="#line[N+1]" y="30" id="lineN" filter="url(#rule110)" />
result[N+1] = rule110(result[N])
But nobody is going to click on "SVG/CSS/HTML is arithmetic-complete". Or "ring-complete".
Interestingly, this renders on my iPad almost instantly.
I guess that settles the Turing complete issue then!
It doesn't render correctly in Firefox, though that finishes instantly as well.
However, the posted solution seems inelegant and uncompelling. Simply iterating in SVG, which can infinitely scalable.
The author expresses apprehension in this closed issue: https://github.com/tom-p-reichel/svg-is-turing-complete/issu...
It is mentioned that they intend to demonstrate this using feComposite in the source code.
There are bits and pieces of how one would prove TC for SVG.
A first step, would be identifying basic operations, as they have done. The next step would be compiling to a tag system, and simulate cyclic tag behavior.
It is expressed elsewhere that the lack of loops would exempt TC. Perhaps it can still be argued through DOM manipulation.
Interestingly, it only happens if I plug in or remove the power cable while the page is loading. It happens reliably.