Monday, October 26, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

Juha Nieminen <nospam@thanks.invalid>: Oct 26 07:28AM

> If you are a bit racist, sexist or homophobic then please watch https://vimeo.com/331247247 to re-baseline.
 
> /Flibble
 
Why don't you go somewhere else, spammer?
Stuart Redmann <DerTopper@web.de>: Oct 26 08:01PM +0100

>> https://vimeo.com/331247247 to re-baseline.
 
>> /Flibble
 
> Why don't you go somewhere else, spammer?
 
IDK, in contrast to „spam" from other frequent posters in this group, I
actually watched Flibble's link, and I have to say that I like it very
much. I would even go so far to say that it is a long overdue statement for
humanity (in all its facets), which contrasts some postings in this group.
I have little concern that Mr. Flibble will start to flood this newsgroup
with too many off-topic postings because I believe he knows when to stop.
 
Thx, Flibble, and keep up the good work.
 
Stuart
olcott <NoOne@NoWhere.com>: Oct 25 06:35PM -0500

On 10/25/2020 6:19 PM, Malcolm McLean wrote:
 
> Of course it's no longer the original problem. The question has changed and the
> requirement that H and H_Hat be Turing machines has been relaxed. I think
> I've been clear on that.
 
We have no need to drop the idea that this applies to Turing Machines
x86 language ≡ von Neumann architecture ≡ UTM
 
Does the UTM halt decider have to stop executing its subordinate UTM to
prevent its own infinite execution?
 
The UTM halt decider executes its subordinate UTM one state transition
at a time until it decides that it must stop the execution of its
subordinate UTM or its subordinate UTM has terminated normally.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 25 06:40PM -0500

On 10/25/2020 6:35 PM, olcott wrote:
 
> The UTM halt decider executes its subordinate UTM one state transition
> at a time until it decides that it must stop the execution of its
> subordinate UTM or its subordinate UTM has terminated normally.
 
In either case it transitions into one of two final states ((qn)) or
((qy)) indicating its decision.
 
 
--
Copyright 2020 Pete Olcott
"André G. Isaak" <agisaak@gm.invalid>: Oct 26 03:18AM -0600

On 2020-10-25 14:27, olcott wrote:
> UTM: https://en.wikipedia.org/wiki/Random-access_stored-program_machine
 
> So for all practical purposes the x86 language <is> a UTM description
> language, thus making x86utm a x86 based UTM operating system.
 
No, it isn't. Your constant repetition of this claim does not make it
true. To the extent that 'UTM description language' means anything, one
would assume it means a a language for specifying a particular TM (where
TM refers to a well-defined type of mathematical object) to be used as
the input for a UTM. x86 machine language doesn't do this.
 
 
> Yes for all we know the machine specified by Linz might not implement
> the simplest of all possible halt deciders instead it might always make
> a phone call to the psychic hotline.
 
First off, there is no possible way to construct a halt decider, as
demonstrated by Linz. This means there is also no such thing as the
'simplest of all possible halt deciders'. Your attempt to redefine the
question doesn't change this fact (and as far as I can tell, your
solution still suffers from the exact same contradiction that Linz draws
attention to anyways).
 
Second, if you want to talk about partial halt deciders, then your claim
that this is the simplest possible approach is simply something you are
pulling out of your ass. There is no actual argument which has been
offered by you to support this claim.
 
Third, your insistence on always choosing the most absurd interpretation
of people's comments you can think of rather than looking for a more
reasonable one is highly aggravating. Analyzing the state transitions of
the input without actually running the TM in some sort of emulation is a
reasonable interpretation. Calling a psychic hotline is not.
 
Since an approach which involves analyzing the state transitions without
actually running the TM in some sort of emulation involves no recursion
at all, you cannot claim that H(Ĥ-description, Ĥ-description) is
inherently recursive, let alone infinitely recursive.
 
André
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
"André G. Isaak" <agisaak@gm.invalid>: Oct 26 03:21AM -0600

On 2020-10-26 03:18, André G. Isaak wrote:
 
> actually running the TM in some sort of emulation involves no recursion
> at all, you cannot claim that H(Ĥ-description, Ĥ-description) is
> inherently recursive, let alone infinitely recursive.
 
Just to add something to this, the recursion you claim exists occurs
*inside* your DebugTrace. If it is possible for DebugTrace to get stuck
in infinite recursion, then your DebugTrace procedure fails to actually
do what it purports to do since that procedure is not itself guaranteed
to halt.
 
André
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 26 04:11PM

On 24/10/2020 23:01, olcott wrote:
> code. Although I don't have the halt decider code completed yet because
> the x86utm operating system is completed I can see exactly how the halt
> deciding code would work.
 
What are the false assumptions? It is not ok in a discussion to say
"you're wrong because you've made a false assumption, but I'm not going
to say what that is!".
 
My trace /is/ based on the assumption that Was_Its_Execution_Aborted()
detects non-halting behaviour and returns ABORTS to H() and H_Hat(). Is
that my false assumption?
 
Mike.
olcott <NoOne@NoWhere.com>: Oct 26 11:16AM -0500

On 10/26/2020 4:37 AM, Malcolm McLean wrote:
 
> But later on, that seems to have changed. I suspect because of confusion
> about whether you abort yourself or not.
 
> It's a root a very simple point. But it has generated a huge thread.
 
Here is how my code has been augmented based on feedback from
10/26/2020 9:44 AM, Melzzzzz:
 
 
void H_Hat(u32 M)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
Output("The function at this machine address has been aborted:", M);
else
{
Output("The function at this machine address has terminated:", M);
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
Output("The function at this machine address has been aborted:", M);
else
Output("The function at this machine address has terminated:", M);
HALT
}
 
 
int main()
{
u32 M = (u32)H_Hat;
H_Hat(M);
HALT
}
 
 
I recap everything here:
 
This thread starts with a simple overview of exactly how the redefined
the halt decider so that it cannot be fooled by the conventional halting
problem trick.
 
On 10/25/2020 8:33 PM, olcott wrote:
Making the Halting Problem Decidable
[ Includes deciding the Peter Linz proof counter-example ]
 
It goes on to explain all of the details of exactly how halting is
decided for the the Peter Linz H_Hat() counter example.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 11:30AM -0500

On 10/26/2020 8:37 AM, Alan Mackenzie wrote:
>>>> means that the input has infinite execution.
 
> It also means a fairy-tale halting decider would return "doesn't halt" in
> exactly the same circumstances.
 
No. Not at all. Not in the least little bit.
It is not a fairy-tale at all.
 
The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.
 
If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.
 
If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.
 
The redefined halt decider is not subject to the conventional halting
problem trick. Its input cannot possibly do the opposite of whatever it
decides because the input has already terminated before the halt decider
makes its decision.
 
 
--
Copyright 2020 Pete Olcott
"André G. Isaak" <agisaak@gm.invalid>: Oct 26 10:43AM -0600

On 2020-10-26 10:30, olcott wrote:
 
> If the halt decider UTM detects non-halting behavior of its subordinate
> UTM it simply stops executing the subordinate and transitions to its own
> final state of ABORTED_NON_TERMINATING_BEHAVIOR.
 
And the difference between 'non-terminating behaviour' and 'does not
halt' is...
 
> problem trick. Its input cannot possibly do the opposite of whatever it
> decides because the input has already terminated before the halt decider
> makes its decision.
 
I have no idea what difference this is supposed to make.
 
Linz's H (ex hypothesi) answers the question 'will my input Turing
Machine description halt with the specified input'. So whatever answer
it gives must conform to what happens when H_Hat(H_Hat-description) is
run as a Turing Machine. Whether it will be aborted prematurely or not
in your debug-mode isn't relevant to this question.
 
So what happens if you run your H_Hat with a description of H_Hat as
it's input? i.e. when you don't run it inside H()?
 
André
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
olcott <NoOne@NoWhere.com>: Oct 26 12:44PM -0500

On 10/26/2020 11:43 AM, André G. Isaak wrote:
>> it decides because the input has already terminated before the halt
>> decider makes its decision.
 
> I have no idea what difference this is supposed to make.
 
void H_Hat(u32 M)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
{
MOV_EAX_1 // Halts
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
MOV_EAX_1 // Halts
HALT
}
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT
}
 
To the question:
Does H_Hat halt on it input H_Hat?
Both Yes and No are the wrong final state to transition to.
 
 
void H_Hat(u32 M)
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(N) has been aborted
else
{
MOV_EAX_0 // M(N) has halted
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(N) has been aborted
else
MOV_EAX_0 // M(N) has halted
HALT
}
 
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT
}
 
The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.
 
If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.
 
If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.
 
The redefined halt decider is not subject to the conventional halting
problem trick. Its input cannot possibly do the opposite of whatever it
decides because the input has already terminated before the halt decider
makes its decision.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 01:03PM -0500

On 10/26/2020 11:29 AM, Mike Terry wrote:
 
> That's fine.
 
> If the outer invocation aborts the inner invocation, that implies that
> the H_Hat(H_Hat) calculation halts.
 
None of the invocations of H_Hat() would ever halt unless they are
aborted. That is why this is the correct halt decider question:
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
 
When the return value of true is provided for the (M, N) input this
return value is correct. Every other return value from
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
does not occur because every other
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
has had its execution terminated before it ever returns any value.
 
Therefore we can conclude that
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
Is a halt decider function that cannot be shown to be incorrect.
 
> or run on some physical computer.]
 
> Do you agree with this?
 
> Mike.
 
 
No. I pointed out the false assumptions.
The one time that
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
returns its decision value this decision value is correct.
There are no other times that it reteuns its decsion value.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 01:13PM -0500

On 10/26/2020 12:38 PM, Alan Mackenzie wrote:
 
> If your A_B_N_H_B_D's output doesn't correspond exactly with the
> fairy-tail halt detector's output, please identify an input program for
> which they would differ.
 
In both cases the input H_Hat would not halt unless it has been aborted:
H_Hat(H_Hat)
H(H_Hat, H_Hat)
 
That is why this is the correct halt decider function:
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
 
When the return value of true is provided for the (M, N) input this
return value is correct. Every other return value from
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
does not occur because every other
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
has had its execution terminated before it ever returns any value.
 
Therefore we can conclude that
bool Aborted_Because_Non_Halting_Behavior_Detected(M, N)
Is a halt decider function that cannot be shown to be incorrect.
 
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 01:14PM -0500

On 10/26/2020 1:03 PM, olcott wrote:
 
>> That's fine.
 
>> If the outer invocation aborts the inner invocation, that implies that
>> the H_Hat(H_Hat) calculation halts.
 
CORRECTION
> None of the invocations of H_Hat() would ever halt unless they are
> aborted.
 
In both cases the input H_Hat would not halt unless it has been aborted:
H_Hat(H_Hat)
H(H_Hat, H_Hat)
 
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 25 08:33PM -0500

Generic system to overcome the halting problem proofs
 
We can ask the halt deciding question in a way that allows the input
program to do the opposite of whatever the halt decider decides:
"Does this input program halt on its input (yes or no)?"
 
Or we can ask the halt deciding question in such a way where it is
impossible for the input program to do the opposite of what the halt
decider decides:
 
Did the UTM halt decider have to stop executing its subordinate UTM to
prevent its own infinite execution?
 
The UTM halt decider executes its subordinate UTM one state transition
at a time until it decides that it must stop the execution of its
subordinate UTM or its subordinate UTM has terminated normally.
 
The halt decider UTM transitions to one of two final states
((qn)) or ((qy)) indicating its decision.
 
Here is the same thing as a conventional software function:
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)
 
 
 
 
 
 
 
Specific details of overcoming the Peter Linz Halting problem proof
The following code is based on the Peter Linz H and Ĥ
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
I created the x86utm operating system on the basis of a very excellent
x86 emulator. The x86 emulator is written in "C" and has been adapted to
run on Linux and Windows.
 
x86 language ≡ von Neumann architecture ≡ UTM
 
x86utm operating system is written in C++ and provides a way to
functions written in "C" to be converted into virtual machines that are
executed in their own process context. The x86 machine language is the
the description language of these UTM equivalents and can be directly
executed in x86utm.
 
main() executes H() and
Aborted_Because_Non_Halting_Behavior_Detected(M, M)) in the process
context of x86utm. Aborted_Because_Non_Halting_Behavior_Detected(M, M))
creates a whole new process context to execute H_Hat() in a DebugTrace()
DebugStep() mode. All of this is fully operational.
 
 
// M has the machine address of H_Hat()
void H_Hat(u32 M)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_0 // Execution of M(N) has been aborted
else
{
MOV_EAX_1 // M(N) has halted
HERE: goto HERE;
}
HALT
}
 
// M and N have the machine address of H_Hat()
void H(u32 M, u32 N)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_0 // Execution of M(N) has been aborted
else
MOV_EAX_1 // M(N) has halted
HALT
}
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M); // MOV_EAX_0
HALT
}
 
Continuing from above: H_Hat() executes another instance of
Aborted_Because_Non_Halting_Behavior_Detected(M, M) in its own process
context which creates another process context to execute a second
instance of H_Hat().
 
As soon as the second H_Hat() would execute
Aborted_Because_Non_Halting_Behavior_Detected(M, M) a second time from
the same machine address the first instance of
Aborted_Because_Non_Halting_Behavior_Detected(M, M) recognizes that
H_Hat() is infinitely recursive. // 2018-12-13 @7:00 PM solution
 
This first instance stops executing H_Hat() which has invoked the second
instance of Aborted_Because_Non_Halting_Behavior_Detected(M, M) which is
executing the second instance of H_Hat().
 
The outer Aborted_Because_Non_Halting_Behavior_Detected(M, M) has
terminated the whole process tree (or hierarchy of UTMs executing other
UTMs) before the second instance has returned a value.
 
Although I have this complete detailed description of exactly how H()
correctly decides halting on H_Hat() the code for this has not been
written. It will be written shortly. Creating the x86utm operating
system took about a man-year working almost all the time. I am reducing
my coding time to less the 40 hours per week.
 
 
--
Copyright 2020 Pete Olcott
"André G. Isaak" <agisaak@gm.invalid>: Oct 26 08:18AM -0600

On 2020-10-25 19:33, olcott wrote:
 
> the same machine address the first instance of
> Aborted_Because_Non_Halting_Behavior_Detected(M, M) recognizes that
> H_Hat() is infinitely recursive. // 2018-12-13 @7:00 PM solution
 
Just to clarify, you are claiming that when the
Aborted_Because_Non_Halting_Behavior_Detected inside H decides it has to
abort H_Hat, the 'non-halting behaviour' it detects is occurring during
the execution of Aborted_Because_Non_Halting_Behavior_Detected inside
H_Hat, and not in the infinite loop present in H_Hat
 
{
if (ABNHBD(M, M)) // <-- the non-halting behaviour is HERE
MOV_EAX_0 // Execution of M(N) has been aborted
else
{
MOV_EAX_1 // M(N) has halted
HERE: goto HERE; // <-- the non-halting behaviour is NOT here.
}
HALT
}
 
Is that correct?
 
If so, you have just admitted that your
Aborted_Because_Non_Halting_Behavior_Detected) function is NOT
guaranteed to halt. If that is the case,
Aborted_Because_Non_Halting_Behavior_Detected() cannot possibly form the
basis of ANY decider. Certainly not of a halt (or forced-to-abort) decider.
 
André
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
olcott <NoOne@NoWhere.com>: Oct 26 12:52PM -0500

On 10/26/2020 9:18 AM, André G. Isaak wrote:
> abort H_Hat, the 'non-halting behaviour' it detects is occurring during
> the execution of Aborted_Because_Non_Halting_Behavior_Detected inside
> H_Hat, and not in the infinite loop present in H_Hat
 
Yes.
 
Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) detects that
H_Hat() specifies infinite recursion and must be terminated before any
H_Hat() ever reaches their undecidable state transitions.
 
>   HALT
> }
 
> Is that correct?
 
Yes.
 
> If so, you have just admitted that your
> Aborted_Because_Non_Halting_Behavior_Detected) function is NOT
> guaranteed to halt. If that is the case,
 
No, not at all. not in the least little bit.
bool Aborted_Because_Non_Halting_Behavior_Detected(M, M)
is what guarantees that the halt decider always halts.
 
 
--
Copyright 2020 Pete Olcott
"André G. Isaak" <agisaak@gm.invalid>: Oct 26 12:12PM -0600

On 2020-10-26 11:52, olcott wrote:
 
> Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) detects that
> H_Hat() specifies infinite recursion and must be terminated before any
> H_Hat() ever reaches their undecidable state transitions.
 
H_Hat doesn't specify any sort of recursion, so I don't know why you
keep claiming that. Even in an implementation where your H actually
'executes' H_Hat in some sort of modified environment, it is not recursive.
 
In Linz's proof, H_Hat is a modified version of H. It contains its own
*copy* of Aborted_Because_Non_Halting_Behavior_Detected, so the
Aborted_Because_Non_Halting_Behavior_Detected in H is not calling
itself, it is calling a separate function within H_Hat that just happens
to be identical to the one in H (similarly, the inner H_Hat has its own,
separate, copy of Aborted_Because_Non_Halting_Behavior_Detected)
 
And, as pointed out in an earlier post which you ignored, there is
nothing in Linz's definition which states that H must execute anything.
H is given an input consisting of the description of a TM and an initial
tape configuration about which it answers the question 'will this halt'?
There's nothing in that requiring that anything 'calls' anything,
recursively or otherwise.
 
 
> No, not at all. not in the least little bit.
> bool Aborted_Because_Non_Halting_Behavior_Detected(M, M)
 
> is what guarantees that the halt decider always halts.
 
But if the copy of Aborted_Because_Non_Halting_Behavior_Detected within
H_Hat doesn't always halt, then you cannot claim that this function is
guaranteed to halt in H either. If this function isn't guaranteed to
halt, then H isn't guaranteed to halt. If the the function within H_Hat
is not identical to the one in H, then you aren't constructing the
proper relation between H and H_Hat.
 
André
 
 
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 26 08:57AM +0200

25.10.2020 17:58 olcott kirjutas:
 
> 8 GB is 68,719,476,736 bits
> 2 Ghz is 2,147,483,648 operations per second
 
> 68,719,476,736 bits / 2,147,483,648 OPS = 32 seconds.
 
Just a small mistake: 68719476736 bits does not mean 68719476736 states,
it means 2^68719476736 states.
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 26 02:44PM


> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
 
> I explain exactly how the halt decider works so that H() correctly
> decides halting of H_Hat():
 
Problem is that program would not print output it will just abort...
You can do that simpply by running timer and if does not stops on
timeout it aborts. But you don't get result...
 
 
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
olcott <NoOne@NoWhere.com>: Oct 26 11:03AM -0500

On 10/26/2020 9:44 AM, Melzzzzz wrote:
 
> Problem is that program would not print output it will just abort...
> You can do that simply by running timer and if does not stops on
> timeout it aborts. But you don't get result...
 
This thread starts with a simple overview of exactly how the redefined
the halt decider so that it cannot be fooled by the conventional halting
problem trick.
 
On 10/25/2020 8:33 PM, olcott wrote:
Making the Halting Problem Decidable
[ Includes deciding the Peter Linz proof counter-example ]
 
It goes on to explain all of the details of exactly how halting is
decided for the the Peter Linz H_Hat() counter example.
 
I added I/O to my x86utem operating system a couple of days ago.
This seems to be what you are asking for:
 
Output("Infinite recursion detected at machine address", Address);
OutputString("H_Hat() has been aborted");
 
 
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 11:06AM -0500

On 10/26/2020 1:57 AM, Paavo Helde wrote:
 
>> 68,719,476,736 bits / 2,147,483,648 OPS = 32 seconds.
 
> Just a small mistake: 68719476736 bits does not mean 68719476736 states,
> it means 2^68719476736 states.
 
I knew that I must have screwed up somewhere.
Good job at correcting my mistake.
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 12:36PM -0500

On 10/25/2020 10:57 PM, Mike Terry wrote:
> refuting something), if the behaviour of this function is key to your
> argument, it's YOU who should be proving your case, rather than asking
> /us/ to respond to challenges?  That's typical Nam Ngyuyen tactics!
 
The would be exactly the same thing as rejecting the Church-Turing
thesis until after someone has proved it.
 
 
> 1)  The program spec for
> Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)
 
> 2)  Exactly what you mean by "impossible to decide correctly".
 
 
void H_Hat(u32 M)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
{
MOV_EAX_1 // Halts
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
MOV_EAX_1 // Halts
HALT
}
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT
}
 
To the question:
Does H_Hat halt on it input H_Hat?
Both Yes and No are the wrong final state to transition to.
 
 
> 3)  Is Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) a
> specific implementation (in C perhaps?) and do you actually have that
> souce code?
 
I will have it so that it correctly decides the Peter Linz H_Hat()
shortly. Since I have worked on this about 80 hours per weeks for six
months I have reduced my coding time to less than 40 hours per week for
this home stretch.
 
> 4)  Why not use a shorter name, because this is UseNet, and there are
> quite restrictive guidelines for line lengths.  I'm all for suggestive
> function names, but we need to be practical!  What about ABNHBD()?
 
No, Not all. Not in the least little bit.
The name must be utterly self-descriptive to eliminate any confusion
 
 
> "provide an input (P,I) for which
> Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) gives a
> response that doesn't meet it's spec."
 
Yes and I show an overview of the architecture of the halting algorithm
as it would be applied to a UTM halt decider deciding the halting of its
subordinate UTM below:
 
The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.
 
If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.
 
If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.
 
The redefined halt decider is not subject to the conventional halting
problem trick. Its input cannot possibly do the opposite of whatever it
decides because the input has already terminated before the halt decider
makes its decision.
 
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Oct 26 12:45PM -0500

On 10/24/2020 3:13 PM, olcott wrote:
 
> ALL INPUT IS DIVIDED INTO EXACTLY ONE OF THESE TWO SETS
> (a) The input Program/TM has infinite execution.
> (b) The input Program/TM DOES NOT HAVE infinite execution.
 
void H_Hat(u32 M)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
{
MOV_EAX_1 // Halts
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (!Halts(M, M))
MOV_EAX_0 // Does not Halt
else
MOV_EAX_1 // Halts
HALT
}
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT
}
 
To the question:
Does H_Hat halt on it input H_Hat?
Both Yes and No are the wrong final state to transition to.
 
 
void H_Hat(u32 M)
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(N) has been aborted
else
{
MOV_EAX_0 // M(N) has halted
HERE: goto HERE;
}
HALT
}
 
 
void H(u32 M, u32 N)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(N) has been aborted
else
MOV_EAX_0 // M(N) has halted
HALT
}
 
 
int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT
}
 
The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.
 
If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.
 
If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.
 
The redefined halt decider is not subject to the conventional halting
problem trick. Its input cannot possibly do the opposite of whatever it
decides because the input has already terminated before the halt decider
makes its decision.
 
 
--
Copyright 2020 Pete Olcott
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 25 11:08PM -0700

On 10/25/2020 9:11 AM, Rick C. Hodgin wrote:
>> Why not try to move the calculations to the GPU?
 
> Because I don't know how to do that. :-)  I've reported on things like
> OpenCL before, but I've never programmed with any of those GPU libraries.
 
At the least, think about:
 
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/
(read all)
 
The think of a MVP. Model, View, Projection.
 
 
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)