▲ 101 points
back
37 comments
SVG doesn't contain looping constructs AFAIK and is thus not Turing complete. Copy pasting lines that simulate one step of a TM is not the same.
You might have been the first who actually checkd the source
<!-- 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)"/>
This is also the issue with the CSS "proof" of turing completeness. It does not actually work for the same reason.
Perhaps the title here on HN should be changed to reflect the truth, as "SVG Is Turing Complete" is clearly false. (I wish there were a way to suggest/do that other than via commenting.)
The simplest definition of a Turing Machine is a tuple:
-a set of states
-symbol set
-initial state
-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.
>I think copying and pasting could be justified as "evaluating".
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." https://github.com/tom-p-reichel/svg-is-turing-complete/issu...
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)"/>
Linear progression from one state to another without conditionals is not even DFA.
You could sort of get a loop with a circular reference, but you would have no control over iteration count...the UA is supposed to stop them.
An element can reference itself and perform calculations which would be a looping construct though? That `url` reference includes itself.
How about using automatic page reload? Can that be used or is there no way to pass all the state?
You don't need a "looping construct" to be able to perform looping. GOTO is not a looping construct, but with it you can perform looping.
For the purposes of this discussion, GOTO is a looping construct, because it does allow looping (that is, potentially running forever). As I understand it, the SVG sample does not demonstrate looping, and the parent is saying that SVG does not allow it as far as they know.
To be fair, for Turing completeness, "looping constructs" are not actually necessary. None of the "foundational" computational models (Turing machines, lambda calculus, Post tag systems, Magic the Gathering, ...) has any kind of "looping construct".
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.
Lambda calculate has a looping construct, recursion. You can make any loop with recursion, just like you can make any loop with goto. SVG appears to have neither of these things.
What is the difference? The point is to be able to take a transition back to an earlier state.
It's just a jump that can be used as a loop.
I wouldn't say this proves that SVG is turing complete.
I don't see why a perfect (i.e. correct and complete) SVG interpreter could solve the halting problem using this idea.
Computationally speaking, specifying each iteration manually is equivalent to directly drawing the final image - the difference is just the representation.
However, it's nice to see how expressive SVG is.
Halting problem is fundamental and applies to Turing complete languages as well. You cannot solve halting problem in, say, Python, but nobody would argue that as a language ideal (disregarding physical limitations of the machine that it is being interpreted on) it is not Turing complete.
EDIT: grammar.
The parent should have said "couldn't"; the halting problem isn't an issue for most non-turing complete languages.
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.
I meant to say "could", but referred to the halting problem of turing machines.
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.
At this point we're agreeing about everything except "could" vs "couldn't"
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.
I share this view. Of course, adding a line
<use href="#line[N+1]" y="30" id="lineN" filter="url(#rule110)" />
result[N+1] = rule110(result[N])
If SVG were actually Turing complete, that would be a serious bug in the SVG spec, since it would be possible for the SVG layout algorithm to never terminate.
Unfortunate about the performance. A side question I have is whether or not this is Turing complete given the lack of looping and recursion possible (at least in this example). The author defines each iteration 'manually.'
I say no, by far. The ability to add and multiply is "Turing complete" if you add external looping. Or in this case, the ability to XOR and NOT.
But nobody is going to click on "SVG/CSS/HTML is arithmetic-complete". Or "ring-complete".
I hope the author made a mistake and didn't make a false claim for clicks.
I won't accuse them of doing it on purpose when many other people have made essentially the same claim. "Turing complete" is a somewhat vague term that is tricky to evaluate in certain contexts.
> Runs in Chromium 73.0.3683.103 after several seconds, seriously, this thing is slow!
Interestingly, this renders on my iPad almost instantly.
Also, fun fact: you can embed JavaScript in an SVG. Just add a script tag: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/scr...
> you can embed JavaScript in an SVG
I guess that settles the Turing complete issue then!
Javascript should have never been added to SVG. IMHO Javascript should always be outside the SVG.
Javascript in SVGs only gets executed when the top-level document is an SVG, never when the SVG is used as an img.
In Chromium 76.0.3809.132 it renders instantly for me as well. I wonder what changed.
It doesn't render correctly in Firefox, though that finishes instantly as well.
It seems trivial as a naive guess that SVG is TC if it can contain JavaScript, which is TC.
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.
SVG can contain javascript, so yeah.
E.g. http://srufaculty.sru.edu/david.dailey/svg/clipdrag12.svg
On Chrome android I get a SIGSEGV in the GpuWatchdog process of Chrome. No stack gets decoded.
Interestingly, it only happens if I plug in or remove the power cable while the page is loading. It happens reliably.
Switching between GPU is taking place when you do that.
Not on Android as far as I'm aware?