quentron.com

[sarkeizen]

Your statement was that it is impossible to write a program to determine whether another, abitrary program, will end or not.   Considering that we are starting with a single set of values and no chance of anything changing, this would be an achievable, but time consuming project.

What does a single set of values mean? What does "no chance of changing" mean? I may not have stated it clearly but this is for all programs and all possible input streams. 

What was your plan of attack?  I mean you're wrong but call me curious.

I noticed that you guys were speaking freely in Javascriptesque whilst coveting C, that's all.  Are you a web developer?

No I'm not a web developer.  Good point! I just used "function" to designate a function for clarity I suppose and of course I wasn't typing anything or using address operators. So I can see how this looks like (or is) Javascript.  I don't really do much JS but about two years ago I started writing a CS textbook based around Javascript as a teaching tool.  I thought it was novel and useful by virtue of JS having some more obscure features like closures (which PHP only got recently) as well as a loose object model and that it's available just about everywhere.

Haven't really touched it since perhaps one or two Dojo applications that are around the office. Goes to show how pervasive C-Style syntax. 

[Regster]

Well, my code would decompile the program first and trace the variables used for the exit point(s) logic before running the same number of instances as there are input conditions (yes -> (possibly) trillions), resulting in an enormously juicy pot of data if there are no exits within a predetermined time frame.  The data would show whether there is a trend towards exit conditions or not in any of the instances or whether limits or repetition will preclude an exit from occuring.

Of course if you want to be constrained by limits of the hypothetical problem you are referring to and are not allowed to look at the code of the program then of course the problem stands as unsolvable.  But nobody mentioned that to lil' ol' me. 

So, back to hot tail electrons and strong tailed salmon.  Neither need any sort of demon.

[sarkeizen]

Well, my code would decompile the program first and trace the variables used for the exit point(s) logic before running the same number of instances as there are input conditions (yes -> (possibly) trillions), resulting in an enormously juicy pot of data if there are no exits within a predetermined time frame.  The data would show whether there is a trend towards exit conditions or not in any of the instances or whether limits or repetition will preclude an exit from occuring.

IMHO you could probably do as good a job simulating as decompiling and tracing.  However if you're going to cut your code analysis off at a predetermined time then the only thing you can state ended deterministically would be code that ended in that time  Everything beyond that would be probabilistic.   The "trending" sounds a little like you've simply embedded the same halting problem inside your code.

If you looked at the example I gave it was code that passed a pointer to itself to your code midway through executing itself.  Then your code returns with an answer, my code sees it and does the opposite.  If you say we exit, then we loop forever.  If you say we loop forever we exit.   

[Regster]

IMHO you could probably do as good a job simulating as decompiling and tracing.  However if you're going to cut your code analysis off at a predetermined time then the only thing you can state ended deterministically would be code that ended in that time  Everything beyond that would be probabilistic.   The "trending" sounds a little like you've simply embedded the same halting problem inside your code.

I disagree.  Being able to trace and (rev 0.1 here) add debugging to the program gives far more scope for determining the outcome than a single boolean value. 

If you looked at the example I gave it was code that passed a pointer to itself to your code midway through executing itself.  Then your code returns with an answer, my code sees it and does the opposite.  If you say we exit, then we loop forever.  If you say we loop forever we exit.

I haven't seen your code (link?), but suffice to say my code wouldn't accept your pointer.

Anyway, are there infomation theory bears required to sort out salmon in salmon leaps?

[sarkeizen]

I haven't seen your code (link?), but suffice to say my code wouldn't accept your pointer.

How does it accept my program it's supposed to analyse then?  It doesn't really matter.  If your program is callable and takes my program as a parameter and always returns a result  I can always change behavior by looking at this result.

The whole point of this discussion was that Lumen said if I don't know the mechanism I can't tell that something doesn't work.

I don't know what salmon jumping is in terms of a formalism but if you can produce a formal proof that it is NOT a MD machine be my guest.