comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the
Halting Problem when I first discovered (see above) that a simulating
halt decider could correctly determine the halt status of the
"impossible" input:
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete
simulation of its input would never reach the final state of this
input that all [these] inputs (including pathological inputs) are
decided correctly.
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input that all
[these] inputs (including pathological inputs) are decided correctly.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:admiration of half a dozen people, one calling himself "Mr Flibble", as a worthwhile reward for five years of full-time work? Or do you intend going further, eg getting the results published elsewhere?
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting
Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
Stepping back a bit from the detail of this, may I ask where you intend going with this? Suppose for example that you posted something that did make Flibble, Richard and the others realise that they were mistaken and admit it. Would you regard the
Paul N <gw7rib@aol.com> writes:
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting
Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted something
that did make Flibble, Richard and the others realise that they were
mistaken and admit it. Would you regard the admiration of half a dozen
people, one calling himself "Mr Flibble", as a worthwhile reward for
five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull. There's nothing "in P" that can stop the apparent infinite recursion, but that's
just sophistry. H is as much part of the computation as any other and H should, stop the recursion when it returns 0 to P. But he gets around
that by "aborting" (by which I think he means a non-local transfer of control) so execution never reaches P's ret instruction. His claim that
H is a pure function is just bogus.
Or do you intend going further, eg
getting the results published elsewhere?
If he ever does publish, it will be in one of those predatory journals
that change fees.
On 6/20/2022 1:38 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the
Halting Problem when I first discovered (see above) that a
simulating halt decider could correctly determine the halt status
of the "impossible" input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted
something that did make Flibble, Richard and the others realise
that they were mistaken and admit it. Would you regard the
admiration of half a dozen people, one calling himself "Mr
Flibble", as a worthwhile reward for five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull.
There's nothing "in P" that can stop the apparent infinite
recursion, but that's just sophistry. H is as much part of the
computation as any other and H should, stop the recursion when it
returns 0 to P. But he gets around that by "aborting" (by which I
think he means a non-local transfer of control) so execution never
reaches P's ret instruction. His claim that H is a pure function
is just bogus.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would never reach the "ret" instruction of P.
Or do you intend going further, eg
getting the results published elsewhere?
If he ever does publish, it will be in one of those predatory journals
that change fees.
Paul N <gw7rib@aol.com> writes:
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting
Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted something
that did make Flibble, Richard and the others realise that they were
mistaken and admit it. Would you regard the admiration of half a dozen
people, one calling himself "Mr Flibble", as a worthwhile reward for
five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull. There's nothing "in P" that can stop the apparent infinite recursion, but that's
just sophistry. H is as much part of the computation as any other and H should, stop the recursion when it returns 0 to P. But he gets around
that by "aborting" (by which I think he means a non-local transfer of control) so execution never reaches P's ret instruction. His claim that
H is a pure function is just bogus.
Or do you intend going further, eg
getting the results published elsewhere?
If he ever does publish, it will be in one of those predatory journals
that change fees.
On 6/20/2022 1:38 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:Every sufficiently competent software engineer can easily verify that
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting >>>> Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted something
that did make Flibble, Richard and the others realise that they were
mistaken and admit it. Would you regard the admiration of half a dozen
people, one calling himself "Mr Flibble", as a worthwhile reward for
five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull. There's
nothing "in P" that can stop the apparent infinite recursion, but that's
just sophistry. H is as much part of the computation as any other and H
should, stop the recursion when it returns 0 to P. But he gets around
that by "aborting" (by which I think he means a non-local transfer of
control) so execution never reaches P's ret instruction. His claim that
H is a pure function is just bogus.
the complete and correct x86 emulation of the input to H(P,P) by H would never reach the "ret" instruction of P because both H and P would remain stuck in infinitely recursive emulation.
If H can determine that this is the case in a finite number of steps
then H could reject its input on this basis.
If you can't form a correct rebuttal in terms of the actual software engineering of the *exact words specified above* then that would prove
that you are insufficiently technically competent on this point.
If you incorrectly paraphrase what I said and form a rebuttal to this incorrect paraphrase then sufficiently technically competent software engineers would know that you are trying to get away with the strawman deception.
straw man
An intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument. https://www.lexico.com/en/definition/straw_man
Or do you intend going further, eg
getting the results published elsewhere?
If he ever does publish, it will be in one of those predatory journals
that change fees.
On 6/21/22 9:54 PM, olcott wrote:
On 6/20/2022 1:38 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:Every sufficiently competent software engineer can easily verify that
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the Halting >>>>> Problem when I first discovered (see above) that a simulating halt
decider could correctly determine the halt status of the "impossible" >>>>> input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted something
that did make Flibble, Richard and the others realise that they were
mistaken and admit it. Would you regard the admiration of half a dozen >>>> people, one calling himself "Mr Flibble", as a worthwhile reward for
five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull. There's >>> nothing "in P" that can stop the apparent infinite recursion, but that's >>> just sophistry. H is as much part of the computation as any other and H >>> should, stop the recursion when it returns 0 to P. But he gets around
that by "aborting" (by which I think he means a non-local transfer of
control) so execution never reaches P's ret instruction. His claim that >>> H is a pure function is just bogus.
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
An even somewhat competent software engineer would understand that if H actually DOES a complete and correct emulation of its input, it can't
stop that emulation to answer 0, now can it?
If H can determine that this is the case in a finite number of steps
then H could reject its input on this basis.
Thats your claim, but not proven. In fact, it has been proven to be
impossibe for H in emulating the input to H(P,P) for the P built on that H.
You CLAIM a lot, but seem to be weak on proof.
On 6/21/2022 9:35 PM, Richard Damon wrote:
On 6/21/22 9:54 PM, olcott wrote:
On 6/20/2022 1:38 PM, Ben Bacarisse wrote:
Paul N <gw7rib@aol.com> writes:Every sufficiently competent software engineer can easily verify that
On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
Essence of the culmination five years of full time work on the
Halting
Problem when I first discovered (see above) that a simulating halt >>>>>> decider could correctly determine the halt status of the "impossible" >>>>>> input:
Stepping back a bit from the detail of this, may I ask where you
intend going with this? Suppose for example that you posted something >>>>> that did make Flibble, Richard and the others realise that they were >>>>> mistaken and admit it. Would you regard the admiration of half a dozen >>>>> people, one calling himself "Mr Flibble", as a worthwhile reward for >>>>> five years of full-time work?
Five? He first "solved" the halting problem 18 years ago!
BTW, if it was you that gave him the "review" he wanted in
comp.lang.c++, you were lead stray by his trace. It does not show
what he claims it shows.
He's now being very clear about the trick he's trying to pull. There's >>>> nothing "in P" that can stop the apparent infinite recursion, but
that's
just sophistry. H is as much part of the computation as any other
and H
should, stop the recursion when it returns 0 to P. But he gets around >>>> that by "aborting" (by which I think he means a non-local transfer of
control) so execution never reaches P's ret instruction. His claim
that
H is a pure function is just bogus.
the complete and correct x86 emulation of the input to H(P,P) by H
would never reach the "ret" instruction of P because both H and P
would remain stuck in infinitely recursive emulation.
An even somewhat competent software engineer would understand that if
H actually DOES a complete and correct emulation of its input, it
can't stop that emulation to answer 0, now can it?
Of course.
If H can determine that this is the case in a finite number of steps
then H could reject its input on this basis.
Thats your claim, but not proven. In fact, it has been proven to be
impossibe for H in emulating the input to H(P,P) for the P built on
that H.
You CLAIM a lot, but seem to be weak on proof.
I just posted all of the details that sufficiently prove this point to sufficiently competent software engineers.
A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.
All of the recent rebuttals try to bluff their way past this requirement
to hide the fact that they lack this sufficient technical competence. Sufficiently competent software engineers will agree.
On 6/21/2022 9:38 PM, olcott wrote: [Technically competent Software
engineers can verify this halting problem proof refutation]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 128:31:49 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,335,196 |