Does the call from P() to H() specify infinite recursion?

[olcott]

#define ptr uintptr_t

void P(ptr x)
{
H(x, x);
}

int H(ptr x, ptr y)
{
((void(*)(ptr))x)(y);
return 1;
}

int main()
{
H((ptr)P, (ptr)P);
return 0;
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[Richard Damon]

On 11/11/21 11:00 AM, olcott wrote:
> #define ptr uintptr_t
>
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int H(ptr x, ptr y)
> {
>   ((void(*)(ptr))x)(y);
>   return 1;
> }
>
> int main()
> {
>   H((ptr)P, (ptr)P);
>   return 0;
> }
>

Yes.

So all you have proven is that if H unconditionally executes its input
you get infinite recursion.

And, H will never return.

If H isn't that function, then the computation of P changes so you have
no proof for what the behavior of that machine is.

This is just more of your POOP talk.

[olcott]

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]


If H simulates the x86 machine language of its input and sees that its
simulated P is calling H with the same parameters that H was called with
H can abort its simulation of P and correctly report that P would never
reach its final state at 1a72.

[olcott]

On 11/11/2021 10:14 AM, Richard Damon wrote:

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]


If H simulates the x86 machine language of its input and sees that its
simulated P is calling H with the same parameters that H was called with
H can abort its simulation of P and correctly report that P would never
reach its final state at 1a72.

[Richard Damon]

No it can't.

If H can abort its simulation, then it needs to take into account that H
can abort its simulation. PERIOD.

H, in making that conclusion, is PRESUMING that the called H will not
abort its simulation, which it is wrong about.

Youy are basing your argument on LIES, thus you are a LIAR.

You need to decide which behavior H has.

1) Does it abort its simulation and return 0 in this case, in which case
when H sees the call to H here it needs to assume that H will return the
value 0. Of course then when it continues to follow the path after the
call, it sees that H stops, but it has already committed itsself to
returning 0, so it can figure out that it will be wrong.

2) Does in NEVER abort its simulation, in which case it isn't allowed to
abort its simulation, and thus even though it can see that Pn(Pn) will
be non-halting, it has no way to return that result without breaking its
assumptions.

3) A path you aren't following is it could presume that H(P,P) returns
1, and then continue the trace following that premise, and see that
P1(P1) goes into an infinite loop, so it knows that when it gives the
Halting answer it will be wrong.


Thus H might be able to correctly determine the right answer to the
problem, but only by commiting itself to returning the wrong answer and
thus knowing it has failed.

In all cases, the outside observer, looking at the answer the H
provides, which is the only answer that really matters, and comparing it
to the acutal behavior of the machine provided in the input, will see
that H is always wrong.

FAIL

[Richard Damon]

FALSE.

See other response.

You are just talking about POOP here.

[olcott]

Because I keep repeating these same words dozens of times and you never
acknowledge that you have ever seen them I really believe that you
actually have attention deficit disorder (ADD):

(a) P only halts if it reaches its final state at 1a72.

(b) If H does not abort its simulation of P then P never reaches its
final state at 1a72.

(c) If H aborts its simulation of P then P never reaches its final state
as 1a72.

Because P never halts in all possible cases H(P,P)==0 is always correct.

[Richard Damon]

So, which H is H?

For B, yes Pb(Pb) doesn't halt, but Hb(Pb,Pb) doesn't answer, so it
wasn't right.

For C, We do have the Hc(Pc,Pc) return 0, but we also have that if we
actually run Pc(Pc) then the actual execution trace of Pc when run as an
independent machine, or simulated by a REAL pure simulator will call H
at 1A69, and then that H WILL return 0, and Pc will reach the final
return at 1a72 and halt.

You make the mistake that in assuming that the aborted simulation that H
did means anything,

Read the ACTUAL definition of the problem, does the machine represented
by the input halt, not does the simulation done by H reach the final
state of the machine it is simulating. All you have shown is that H
can't prove that its input is halting, so it makes the WRONG choice in
assuming it is not.


AGAIN, you make the error of not definie which H you are talking about
so not only are you WRONG, but you are DOUBLELY WRONG.

Maybe even Triple wrong as you not only haven't proven what you claim,
you show that you don't understand what Halting really is or even how to
make a proof.

FAIL.

[Marcel Mueller]

Am 11.11.21 um 17:00 schrieb olcott:

> #define ptr uintptr_t
>
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int H(ptr x, ptr y)
> {
>   ((void(*)(ptr))x)(y);
>   return 1;
> }
>
> int main()
> {
>   H((ptr)P, (ptr)P);
>   return 0;
> }

Besides the fact that there is no good reason to write that type unsafe
code in C++ did you test it? The code will never compile because of the
forward reference to H.

And well, H calls P and P calls H. What do you expect?


Marcel

[olcott]

Yes the code does compile and I did test it.
This is the pure C part of my halting theorem refutation. I wanted to
get some C experts to weigh in on the the analysis of the C code.

I won't be discussing anything besides the pure C aspects here because
people here get upset.

[Jeff Barnett]

I expect that PO (the OP) is nuts and lonesome. This crap is just
another bid for attention and companionship, no matter the quality of
the interaction.

However many programing languages allow 'mutual recursion" and it's very
useful. Common LISP, for example, has two different forms for lexically
binding functions. One makes the bound functions only visible within the
body of the binding form; the other makes these functions visible in the
bodies of the bound functions themselves as well as the body of the
binding form. Further, the batch compilers do not output "missing
function definition" warnings or errors until the entire batch has been
compiled. Together these features allow incremental development and
debugging as well as mutual recursion.

And as an aside, I think that Common LISP has at least as flexible and
powerful an object system as does any of the C variants.
--
Jeff Barnett

[Richard Damon]

On 11/11/21 1:52 PM, olcott wrote:
> On 11/11/2021 12:01 PM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
>>
>>
>> Marcel
>
> Yes the code does compile and I did test it.
> This is the pure C part of my halting theorem refutation. I wanted to
> get some C experts to weigh in on the the analysis of the C code.
>
> I won't be discussing anything besides the pure C aspects here because
> people here get upset.
>

First, this CAN'T be the complete definition of the source file, as at
minimum it needs a #include <stdint.h> to get the definition of uintptr_t

Second, if you are using a version of C that has uintptr_t defined, (C99
or later) then the lack of a declaration for H in P is an error

Only C90 and before allowed the calling of a function with no
declaration before it.

It might 'compile', but if it does, it will include a manditory
diagnostic, and that means that if the compiler still produced an output
file, if you run that program, the behavior of that program is BY
DEFINITON of the Standard, Undefined.

Thus, there ARE NO 'C aspects' of this 'program' as the C standard has
declared that it suppies NO definition of what it does.

FAIL.

[olcott]

On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> On 11/11/2021 11:01 AM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
> I expect that PO (the OP) is nuts and lonesome. This crap is just
> another bid for attention and companionship, no matter the quality of
> the interaction.
>

(Attacking the person): This fallacy occurs when, instead of addressing
someone's argument or position, you irrelevantly attack the person or
some aspect of the person who is making the argument.

https://www.txstate.edu/philosophy/resources/fallacy-definitions/Ad-Hominem.html

> However many programing languages allow 'mutual recursion" and it's very
> useful. Common LISP, for example, has two different forms for lexically
> binding functions. One makes the bound functions only visible within the
> body of the binding form; the other makes these functions visible in the
> bodies of the bound functions themselves as well as the body of the
> binding form. Further, the batch compilers do not output "missing
> function definition" warnings or errors until the entire batch has been
> compiled. Together these features allow incremental development and
> debugging as well as mutual recursion.
>
> And as an aside, I think that Common LISP has at least as flexible and
> powerful an object system as does any of the C variants.

That is the strawman error. I am only referring to the x86 machine code
specified by this Microsoft C source-code.

#define ptr uintptr_t

void P(ptr x)
{
H(x, x);
}

int H(ptr x, ptr y)
{
((void(*)(ptr))x)(y);
return 1;
}

int main()
{
H((ptr)P, (ptr)P);
return 0;
}

[olcott]

I added this: #include <stdint.h>

[Richard Damon]

But it still fails and will get a mandatory diagnostic, and the
execution is undefined. P can not use the symbol H without it being
prior declaired in any version of C that defines uintptr_t.

You either need the definition of H before the definition of P or you
need a forward decleration for the function H before the call.

C90 allowed this, which is why you may be just getting a warning, but
the actual meaning is that the C Standard has disavowed any definition
to the program.

And, all this shows is that for a H that just calls its input, you do
get an infinite recursion, but such an H never gives the answer about it.

Since the behavior of P depends on the behavior of H, if you change H to
be able to give an answer, you have changed the behavior of P so you
'proof' doesn't apply any more.

Show your level of skill as a junior programmer.

[olcott]

#include <stdint.h>
#define ptr uintptr_t

int H(ptr x, ptr y)
{
((void(*)(ptr))x)(y);
return 1;
}

void P(ptr x)
{
H(x, x);
}

int main()
{
H((ptr)P, (ptr)P);
return 0;
}

I embedded the above in a whole other program so these "errors"
were corrected in code that I did not know about.

> C90 allowed this, which is why you may be just getting a warning, but
> the actual meaning is that the C Standard has disavowed any definition
> to the program.
>
> And, all this shows is that for a H that just calls its input, you do
> get an infinite recursion, but such an H never gives the answer about it.
>
> Since the behavior of P depends on the behavior of H, if you change H to
> be able to give an answer, you have changed the behavior of P so you
> 'proof' doesn't apply any more.
>
> Show your level of skill as a junior programmer.

[Richard Damon]

On 11/11/21 2:59 PM, olcott wrote:
>
>
> I embedded the above in a whole other program so these "errors"
> were corrected in code that I did not know about.

In other words, you don't know how to do a controlled experiment so we
really need to deman FULL disclosure of exactly what you are doing
before we can accept any 'experimental' evidence.

You are writing your obituary here.

[olcott]

Don't say that. I have terminal cancer in its advanced stages.

[Richard Damon]

On 11/11/21 3:16 PM, olcott wrote:
> On 11/11/2021 2:11 PM, Richard Damon wrote:
>>
>> On 11/11/21 2:59 PM, olcott wrote:
>>>
>>>
>>> I embedded the above in a whole other program so these "errors"
>>> were corrected in code that I did not know about.
>>
>> In other words, you don't know how to do a controlled experiment so we
>> really need to deman FULL disclosure of exactly what you are doing
>> before we can accept any 'experimental' evidence.
>>
>> You are writing your obituary here.
>
> Don't say that. I have terminal cancer in its advanced stages.
>

Right, so you should be trying to do something meaningfull.

If the last decades of your life we just filled with non-sense, that is
what you will be remembered for.

You actions ARE LITERALLY writing your real obituary. Maybe not the one
that is publisned in the paper, as that tends to get whitewashed as not
talk about the foibles of the individual, but the obituary in the minds
of those that know you will be filled with what you actually did.

You don't seem to be able to see who you really are. You seem to have
lost you sense of what is really true, and what is important.

Face it, you don't have the background to even attempt the proof you are
trying to do, as I have mentioned before, if you real basis is that you
disagree with the fundamental logic uses in mathematics, then you can't
start at late stage proofs that prove things you find inconvenient,
because to talk about those you actually DO need to accept the logic
system they were built on. You can't say that it was ok to use the
standard logics to get you to that point, but not any farther.

You seem to not understand that there HAVE been a number of great minds
working on Maths with different base logics to try and avoid some of the
results that you don't like (things like there being unprovable truths).
All that has been found is that none of these can express the fullness
that the mathematics you want to change can express.

If you really think you can do better than those people, go ahead, but
that means starting at the bottom and working up. And, those people
spent a life time working on these things, and it sounds like you don't
have much time.

Take you last days and do something PRODUCTIVE, something that you can
actually DO (something that others say you can do) and end on a positive
note, not as the crazy man who doesn't understand what he has been
talking about.

[olcott]

On 11/11/2021 2:31 PM, Ben Bacarisse wrote:

> olcott <No...@NoWhere.com> writes:
>
>> #include <stdint.h>
>> #define ptr uintptr_t
>>
>> int H(ptr x, ptr y)
>> {
>> ((void(*)(ptr))x)(y);
>> return 1;
>> }
>>
>> void P(ptr x)
>> {
>> H(x, x);
>> }
>>
>> int main()
>> {
>> H((ptr)P, (ptr)P);
>> return 0;
>> }
>

> It's clearer without all the casts:
>
> #include <stdint.h>
>
> typedef void (*ptr)();

>
> int H(ptr x, ptr y)
> {

> x(y);

> return 1;
> }
>
> void P(ptr x)
> {
> H(x, x);
> }
>

> int main(void)
> {
> H(P, P);
> }
>

Brilliant !!!

[Jeff Barnett]

On 11/11/2021 12:26 PM, olcott wrote:
> On 11/11/2021 1:06 PM, Jeff Barnett wrote:

<SNIP>

>> I expect that PO (the OP) is nuts and lonesome. This crap is just
>> another bid for attention and companionship, no matter the quality of
>> the interaction.
>>
>
> (Attacking the person): This fallacy occurs when, instead of addressing
> someone's argument or position, you irrelevantly attack the person or
> some aspect of the person who is making the argument.

I was not attacking your argument; I was attacking you as a demonstrable
idiot. Therefore this was/is not an example of Ad Hominem argument. You
are nuts, you are lonesome, you are making a bid for attention, and the
quality of the interaction, no matter how negative, is what you grave.
All facts. Find a qualified mental health professional, show them your
posts - any half dozen or so will do - and ask for an evaluation. I bet
they wont let you leave the office without a lifetime prescription for
"happy" pills.

Most of my message was to Mueller about relative approaches to mutual
recursion in different languages. In fact what I said, technically,
might have been a slight defense of your abysmal code. There is no straw
man here unless it was you with straw in your head for brains. You
really should read and understand before criticizing.

I haven't ask you this for a long time but I think it is appropriate
now: Are you typing with one hand in your pants, playing with yourself?
Your not very good at multitasking; so one thing at a time. Go slow,
very slow else you will out run your brain.
--
Jeff Barnett

[olcott]

On 11/11/2021 1:06 PM, Jeff Barnett wrote:

> On 11/11/2021 11:01 AM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
> I expect that PO (the OP) is nuts and lonesome.

> This crap is just

A conclusion was formed about the quality of my work and the only basis
provided for this conclusion was the personal attack that preceded it.

> another bid for attention and companionship, no matter the quality of
> the interaction.
>
> However many programing languages allow 'mutual recursion" and it's very
> useful. Common LISP, for example, has two different forms for lexically
> binding functions. One makes the bound functions only visible within the
> body of the binding form; the other makes these functions visible in the
> bodies of the bound functions themselves as well as the body of the
> binding form. Further, the batch compilers do not output "missing
> function definition" warnings or errors until the entire batch has been
> compiled. Together these features allow incremental development and
> debugging as well as mutual recursion.
>
> And as an aside, I think that Common LISP has at least as flexible and
> powerful an object system as does any of the C variants.

This is an example of the strawman error in that the concrete code that
I precisely specified never halts because of infinite recursion.

[DV]

> Don't say that. I have terminal cancer in its advanced stages.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

I am sorry to learn about this. I am assuming that what you are saying is true. I hope you will find it encouraging to hear: the theory of everything I've been working will be very likely, assuming it is one day published or used in the right ways, to facilitate the technology to bring all people who have ever died back to life.

Best wishes,
Philip White

[olcott]

On 11/11/2021 3:55 PM, Jeff Barnett wrote:
> On 11/11/2021 12:26 PM, olcott wrote:
>> On 11/11/2021 1:06 PM, Jeff Barnett wrote:
>
> <SNIP>
>
>>> I expect that PO (the OP) is nuts and lonesome. This crap is just
>>> another bid for attention and companionship, no matter the quality of
>>> the interaction.
>>>
>>
>> (Attacking the person): This fallacy occurs when, instead of
>> addressing someone's argument or position, you irrelevantly attack the
>> person or some aspect of the person who is making the argument.
>
> I was not attacking your argument; I was attacking you as a demonstrable
> idiot. Therefore this was/is not an example of Ad Hominem argument. You


On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> I expect that PO (the OP) is nuts and lonesome.

> This crap is just

a conclusion about the quality of my work that only has the personal
attack that precedes it as its basis.

> another bid for attention and companionship, no matter the quality of
> the interaction.

> are nuts, you are lonesome, you are making a bid for attention, and the
> quality of the interaction, no matter how negative, is what you grave.
> All facts. Find a qualified mental health professional, show them your
> posts - any half dozen or so will do - and ask for an evaluation. I bet
> they wont let you leave the office without a lifetime prescription for
> "happy" pills.
>
> Most of my message was to Mueller about relative approaches to mutual
> recursion in different languages. In fact what I said, technically,
> might have been a slight defense of your abysmal code. There is no straw
> man here unless it was you with straw in your head for brains. You
> really should read and understand before criticizing.
>
> I haven't ask you this for a long time but I think it is appropriate
> now: Are you typing with one hand in your pants, playing with yourself?
> Your not very good at multitasking; so one thing at a time. Go slow,
> very slow else you will out run your brain.


--

[dklei...@gmail.com]

On Thursday, November 11, 2021 at 12:16:42 PM UTC-8, olcott wrote:

> ... I have terminal cancer in its advanced stages.

I hope that doesn't mean exactly what it says. If it does I am sorry
to hear it. Have as decent health as possible for as long as possible.

[olcott]

Follicular lymphoma throughout my body.
A Flippi index of 3 beginning two years ago.

https://www.mdcalc.com/follicular-lymphoma-international-prognostic-index-flipi


It would be really great if my reviewers would break out of rebuttal
mode and truly try to earnestly understand what I am saying.

[Richard Damon]

On 11/11/21 6:20 PM, olcott wrote:
> On 11/11/2021 5:04 PM, dklei...@gmail.com wrote:
>> On Thursday, November 11, 2021 at 12:16:42 PM UTC-8, olcott wrote:
>>
>>> ... I have terminal cancer in its advanced stages.
>>
>> I hope that doesn't mean exactly what it says. If it does I am sorry
>> to hear it. Have as decent health as possible for as long as possible.
>>
>
> Follicular lymphoma throughout my body.
> A Flippi index of 3 beginning two years ago.
>
> https://www.mdcalc.com/follicular-lymphoma-international-prognostic-index-flipi
>
>
> It would be really great if my reviewers would break out of rebuttal
> mode and truly try to earnestly understand what I am saying.
>

The problem is what you say is actually incorrect when examined within
the framework of the system you claim to be working in.

As I have said several times, if your disagreement is with the logical
framework that mathematics works with, this proof is not the place to
try to tackle that issue. You have no 'authority' (and neither do we) to
change that logical framework inside this proof.

You DON'T get to change the definitions or the rules.

By those rules, the proof that you are trying to discredit is very
solid, so you really have no hope of disproving it.

If you want to try to show that you can build an equivalent math system
on a different logical base, you need to start with that base and start
at the BOTTOM. Basic number theory and work up there and show that you
can derive a system sufficiently similar to mathematics to be useful,
but without the 'problems' you don't like.

Greater minds they yours have spent lifetimes working on it, and there
are some parts of math that can be done, but no where near the full theory.

Good luck in trying to do better with your background.

[Joe Pfeiffer]

Marcel Mueller <news.5...@spamgourmet.org> writes:
>
> Besides the fact that there is no good reason to write that type
> unsafe code in C++ did you test it? The code will never compile
> because of the forward reference to H.
>
> And well, H calls P and P calls H. What do you expect?

He's imagining he can solve the Halting Problem if he uses the x86
instruction set instead of a Turing Machine. Many people have tried to
explain the flaws in his argument; he doesn't listen. There is nothing
to do but killfile him.

[olcott]

Talent hits a target no one else can hit; Genius hits a target no one
else can see.

Arthur Schopenhauer

People that cannot see the target are unqualified to judge hits from
misses.

[olcott]

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
> [..wanting to solve the halting problem..]
>
>> You do understand that if the halting problem were solvable, and
>> someone solved it, it would be the Holy Grail of mathematics?
>> Pretty much every single unsolved mathematical hypothesis that can
>> be expressed as a computer program could be solved just like that.

I do understand that is simply not the way it works.
If you want to continue discussing this reply to the follow-up group.

Flibble agrees that I am correct:
[Why has the argument with Olcott gone on for so long?]
On 11/13/2021 10:57 AM, Mr Flibble wrote:
> Because the halting problem as defined is a category error: only
> Olcott sees this and the rest of you are blind to it. Classic outcome
> of failing to recognize a category error is an argument that goes
> nowhere and never ends.
>
> /Flibble
>



>> [...] The Collatz conjecture? Solved. [...]
>
> Can you explain what program would serve to provide a solution to
> the Collatz conjecture?

>


--
Copyright 2021 Pete Olcott

[Richard Damon]

On 11/13/21 1:34 PM, olcott wrote:
> On 11/13/2021 12:24 PM, Tim Rentsch wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>> [..wanting to solve the halting problem..]
>>
>>> You do understand that if the halting problem were solvable, and
>>> someone solved it, it would be the Holy Grail of mathematics?
>>> Pretty much every single unsolved mathematical hypothesis that can
>>> be expressed as a computer program could be solved just like that.
>
> I do understand that is simply not the way it works.
> If you want to continue discussing this reply to the follow-up group.

No, it is a true statement. A vast majority, if not all, of the unsolved
problems in mathematics can be converted into a Turing Machine working
on the answer, and the mere knowledge that the Computation it is working
on is non-halting proves one side of the problem, and knowing that it is
halting, proves the other side (getting the final state would be a
bonus, but knowing it is there is a big step).

I think you just don't understand the nature of Mathematics to
understand what having an actual Halting Decider would do.

Now, if it takes a 1000 years to run, it may not change things right
away, but it says they all ARE solvable.

[olcott]

On 11/13/2021 1:28 PM, Richard Damon wrote:
> On 11/13/21 1:34 PM, olcott wrote:
>> On 11/13/2021 12:24 PM, Tim Rentsch wrote:
>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>
>>> [..wanting to solve the halting problem..]
>>>
>>>> You do understand that if the halting problem were solvable, and
>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>> be expressed as a computer program could be solved just like that.
>>
>> I do understand that is simply not the way it works.
>> If you want to continue discussing this reply to the follow-up group.
>
> No, it is a true statement.

If H(P,P) correctly decides the halt status of its input suddenly H
becomes all knowing by pure magic.

> A vast majority, if not all, of the unsolved
> problems in mathematics can be converted into a Turing Machine working
> on the answer, and the mere knowledge that the Computation it is working
> on is non-halting proves one side of the problem, and knowing that it is
> halting, proves the other side (getting the final state would be a
> bonus, but knowing it is there is a big step).
>
> I think you just don't understand the nature of Mathematics to
> understand what having an actual Halting Decider would do.
>
> Now, if it takes a 1000 years to run, it may not change things right
> away, but it says they all ARE solvable.
>
>
>>
>> Flibble agrees that I am correct:
>> [Why has the argument with Olcott gone on for so long?]
>> On 11/13/2021 10:57 AM, Mr Flibble wrote:
>>  > Because the halting problem as defined is a category error: only
>>  > Olcott sees this and the rest of you are blind to it. Classic outcome
>>  > of failing to recognize a category error is an argument that goes
>>  > nowhere and never ends.
>>  >
>>  > /Flibble
>>  >
>>
>>
>>
>>>> [...]  The Collatz conjecture?  Solved.  [...]
>>>
>>> Can you explain what program would serve to provide a solution to
>>> the Collatz conjecture?
>>>
>>
>>
>

[Richard Damon]

On 11/13/21 2:43 PM, olcott wrote:
> On 11/13/2021 1:28 PM, Richard Damon wrote:
>> On 11/13/21 1:34 PM, olcott wrote:
>>> On 11/13/2021 12:24 PM, Tim Rentsch wrote:
>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>
>>>> [..wanting to solve the halting problem..]
>>>>
>>>>> You do understand that if the halting problem were solvable, and
>>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>>> be expressed as a computer program could be solved just like that.
>>>
>>> I do understand that is simply not the way it works.
>>> If you want to continue discussing this reply to the follow-up group.
>>
>> No, it is a true statement.
>
>
> If H(P,P) correctly decides the halt status of its input suddenly H
> becomes all knowing by pure magic.

No, that isn't what he said, he said if the Halting Problem is SOLVED,
ie we have an H such that H(P,I) for ALL machines P and inputs I gave
the right answer in finite time, then THAT H would solve all sorts of
problems.

Yes, your worthless H that claim to handle the one trivial case (which
is still doesn't) wouldn't do that, and in fact, it wouldn't dicredit
the other proofs of the halting theorem so you still would have that
thorn in the side of you precious idea of Truth.

In fact, all that showing a proof that you can come up with an H that
correctly gets the answer right does is prove that somewhere in getting
to that proof the logic system has gone inconsistent, as you have done
nothing to actually show an error in the original proof that it is
impossible to have such an H. The addition is almost certainly going to
be found in your own logic, as otherwise we need to find another great
reset in mathematical logic after someone can figure out what definition
was added that broke mathematics (like was found in Niave Set Theory).

[olcott]

On 11/13/2021 2:05 PM, Richard Damon wrote:
> On 11/13/21 2:43 PM, olcott wrote:
>> On 11/13/2021 1:28 PM, Richard Damon wrote:
>>> On 11/13/21 1:34 PM, olcott wrote:
>>>> On 11/13/2021 12:24 PM, Tim Rentsch wrote:
>>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>>
>>>>> [..wanting to solve the halting problem..]
>>>>>
>>>>>> You do understand that if the halting problem were solvable, and
>>>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>>>> be expressed as a computer program could be solved just like that.
>>>>
>>>> I do understand that is simply not the way it works.
>>>> If you want to continue discussing this reply to the follow-up group.
>>>
>>> No, it is a true statement.
>>
>>
>> If H(P,P) correctly decides the halt status of its input suddenly H
>> becomes all knowing by pure magic.
>
> No, that isn't what he said, he said if the Halting Problem is SOLVED,

Ah you caught an actual mistake of mine.

[olcott]

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
> [..wanting to solve the halting problem..]
>
>> You do understand that if the halting problem were solvable, and
>> someone solved it,

Because I didn't see these last three words my reply was incorrect.

I am not trying to solve the halting problem merely show how this
simplest possible equivalent to the halting theorem counter-examples can
have its halt status correctly decided by H.

int H(ptr x, ptr y)
{

x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P

void P(ptr x)
{
H(x, x);
}

int main(void)
{
H(P, P);
}

H simulates its input and as soon as its input calls H with the same
parameters that H was called with H aborts this simulation and returns 0
for not halting, infinite recursion detected. It took me 16,000 hours
since 2004 to get it this simple.

> it would be the Holy Grail of mathematics?
>> Pretty much every single unsolved mathematical hypothesis that can
>> be expressed as a computer program could be solved just like that.

>> [...] The Collatz conjecture? Solved. [...]
>
> Can you explain what program would serve to provide a solution to
> the Collatz conjecture?
>

--
Copyright 2021 Pete Olcott

[Mikko Levanto]

On 2021-11-13 20:05:19 +0000, Richard Damon said:

> On 11/13/21 2:43 PM, olcott wrote:
>>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>>
>>>>> [..wanting to solve the halting problem..]
>>>>>
>>>>>> You do understand that if the halting problem were solvable, and
>>>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>>>> be expressed as a computer program could be solved just like that.
>>

>> If H(P,P) correctly decides the halt status of its input suddenly H
>> becomes all knowing by pure magic.
>
> No, that isn't what he said, he said if the Halting Problem is SOLVED,
> ie we have an H such that H(P,I) for ALL machines P and inputs I gave
> the right answer in finite time, then THAT H would solve all sorts of
> problems.

In order to solve those problem it would be sufficient to have some method
to solve the Halting Problem of Turing Machines, not necessarily a Turing
computable one. Even a method involving magic would do as long as its result
can be trusted.

Mikko

[olcott]

On 11/14/2021 5:36 AM, Mikko Levanto wrote:
> On 2021-11-13 20:05:19 +0000, Richard Damon said:
>
>> On 11/13/21 2:43 PM, olcott wrote:
>>>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>>>
>>>>>> [..wanting to solve the halting problem..]
>>>>>>
>>>>>>> You do understand that if the halting problem were solvable, and
>>>>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>>>>> be expressed as a computer program could be solved just like that.
>>>
>>> If H(P,P) correctly decides the halt status of its input suddenly H
>>> becomes all knowing by pure magic.
>>
>> No, that isn't what he said, he said if the Halting Problem is SOLVED,
>> ie we have an H such that H(P,I) for ALL machines P and inputs I gave
>> the right answer in finite time, then THAT H would solve all sorts of
>> problems.
>

If the halting problem is solved then you could make a program that
doesn't halt until it figures out a physical cure for old age thus
providng physical immortality.

> In order to solve those problem it would be sufficient to have some method
> to solve the Halting Problem of Turing Machines, not necessarily a Turing
> computable one. Even a method involving magic would do as long as its
> result
> can be trusted.
>
> Mikko
>

[Richard Damon]

On 11/14/21 9:07 AM, olcott wrote:
> On 11/14/2021 5:36 AM, Mikko Levanto wrote:
>> On 2021-11-13 20:05:19 +0000, Richard Damon said:
>>
>>> On 11/13/21 2:43 PM, olcott wrote:
>>>>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>>>>
>>>>>>> [..wanting to solve the halting problem..]
>>>>>>>
>>>>>>>> You do understand that if the halting problem were solvable, and
>>>>>>>> someone solved it, it would be the Holy Grail of mathematics?
>>>>>>>> Pretty much every single unsolved mathematical hypothesis that can
>>>>>>>> be expressed as a computer program could be solved just like that.
>>>>
>>>> If H(P,P) correctly decides the halt status of its input suddenly H
>>>> becomes all knowing by pure magic.
>>>
>>> No, that isn't what he said, he said if the Halting Problem is
>>> SOLVED, ie we have an H such that H(P,I) for ALL machines P and
>>> inputs I gave the right answer in finite time, then THAT H would
>>> solve all sorts of problems.
>>
>
> If the halting problem is solved then you could make a program that
> doesn't halt until it figures out a physical cure for old age thus
> providng physical immortality.

No, the Halting Problem doesn't tell you the ANSWER the other machine
would give, just if it will give one, so a Halting Decider could just
tell you IF a physical cure for old age exists.

And that, only if you can write a finite algorithm of enumerated steps
to find that physical cure. Not every problem in the world can be
solved with a computation.

The key is that most MATHEMATICAL propositions can be,