tags:

views:

201

answers:

5

is this proofed:

every algorithm A designed using go to or something like, is equivalence to another algorithm B that does not use go to.

in other words:

every algorithm designed using go to, can be designed without using go to.

how to proof?

+2  A: 

The proof is in all the languages that do not have a goto feature.

Coronatus
And maybe there is something that they cannot implement. Not necessarily something useful.
Thilo
As long as they are Turing complete, they can implement anything that another Turing complete language can.
jleedev
Dear Coronatus,forgot languages! I'm speaking about a an algorithm theory problem. not about programming languages and their features. they do not provide 90% of the algorithm theory concepts at all.
Sorush Rabiee
@Sorush That’s a tough distinction, since every description of an algorithm uses a language to do so.
jleedev
@jleedev:yes, they do, but not a programming language. you pointed at digital world and its limitations by referring to programming languages. they do not implement a Turing language
Sorush Rabiee
@Sorush: the only obstacle to implementing a Turing machine in Python is resource limits (you don't have an infinite tape). This can easily be seen by doing it. That obstacle has nothing to do with the lack of `goto`, so Coronatus' result follows. The Böhm-Jacopini result is more sophisticated, though, it doesn't just prove the obvious fact that you can do without goto by emulating the whole machine, it provides a set of transformations to replace goto with structured control flow.
Steve Jessop
+11  A: 

C. Böhm, G. Jacopini, "Flow diagrams, Turing Machines and Languages with only Two Formation Rules", Comm. of the ACM, 9(5): 366-371,1966.

http://en.wikipedia.org/wiki/Structured_program_theorem

http://en.wikipedia.org/wiki/P"

The Böhm-Jacopini proof describes how to construct a structured flow chart from an arbitrary chart, using the bits in an extra integer variable to keep track of information that the original program represents by the program location. This construction was based on Böhm's programming language P′′. The Böhm-Jacopini proof did not settle the question of whether to adopt structured programming for software development, partly because the construction was more likely to obscure a program than to improve it. On the contrary, it signalled the beginning of the debate. Edsger Dijkstra's famous letter, "Go To Statement Considered Harmful," followed in 1968. Subsequent proofs of the theorem addressed practical shortcomings of the Böhm-Jacopini proof with constructions that maintained or improved the clarity of the original program.1

ja
http://en.wikipedia.org/wiki/Structured_programming is also a good article.
Ben Challenor
The ironic part is: the moment you compile it, it get's transformed into loads of gotos (or jmp statements as it is called in Assembly)
Toad
@reinier: ironic in the sense that it occasionally leads to nonsense like "function calls are just goto, so it's fine if I use unrestrained goto in my code", or "feature X is just goto, don't use it". The difficulties of goto have nothing to do with machine code, structured programming is there to make code easier for humans. A `jmp` is *not* the equivalent of goto in most compiled languages, because a goto isn't just a jmp, it also usually requires some kind of sync to get the stack into the correct state for the destination. `goto` in C is a pretty high-level programming construct ;-)
Steve Jessop
+1  A: 

The goto feature can introduce "multiple entry loops", also known as "irreducible" loops. Elimination of irreducible loops is essentially achieved by duplicating code.

See Handling Irreducible Loops: Optimized Node Splitting vs. DJ-Graphs for a discussion of the ways in which this can be done.

Ben Challenor
A: 

Every computer program could be expressed without branching. You would need an infinitely long program, but it could be done. (You'd still need an if statement) I guess that's where you would get your formal proof. http://www.jucs.org/jucs_2_11/conditional_branching_is_not/Rojas_R.html

Also, any block of code you could GoTo, can be separated out and placed either in a state machine, or a Repeat Loop. If you take a block of code filled with random (and overlapping goto statements), then each goto point could be assigned to a specific function, and each Goto could be replaced with a function_exit and an assignation of the next state.

So

Point1: 
    do something 
Point2: 
    do something 
    if blah goto point3
    goto point4
point3: 
    something
point4: 
    goto point2: 
end

can be replaced by 

function point1
    do something 
    return = point2
end_function

function point2
    do something 
    if blah return = point3
    return = point4
end_function

function point3 
    something
    return = point4
end_function

function point4
    return = point2
end_function

state = point1
repeat 
    state = call_function (state)
until (state=end)

This completely emulates goto without using goto, and because of this, I'd answer - yes.

I'm not sure about goto where the goto-point can be a variable.

seanyboy
Even tough I think this is right. I'm not sure that this is a state machine, so you may need to correct my language. Self taught - so, you know... :-)
seanyboy
"You would need an infinitely long program, but it could be done". That's another way of saying "it can't be done". All the computation models that we actually use define programs to be finite, including the Turing machine.
Steve Jessop
+1  A: 

The proof is: you can implement a universal Turing machine without goto's and you can implement any algorithm with a universal Turing machine and a character string representing its input.

jkff