On 5/3/2024 4:43 AM, Mikko wrote:
On 2024-05-02 14:43:45 +0000, olcott said:
On 5/2/2024 4:00 AM, Mikko wrote:
On 2024-05-01 16:00:57 +0000, olcott said:
>
On 5/1/2024 5:03 AM, Mikko wrote:
On 2024-04-30 15:45:59 +0000, olcott said:
>
On 4/30/2024 5:22 AM, Mikko wrote:
On 2024-04-30 05:54:51 +0000, olcott said:
>
On 4/29/2024 6:19 PM, Richard Damon wrote:
On 4/29/24 10:43 AM, olcott wrote:
On 4/29/2024 6:24 AM, Richard Damon wrote:
On 4/28/24 11:58 PM, olcott wrote:
On 4/28/2024 6:07 PM, Richard Damon wrote:
On 4/28/24 3:51 PM, olcott wrote:
On 4/28/2024 2:45 PM, Richard Damon wrote:
On 4/28/24 3:35 PM, olcott wrote:
On 4/28/2024 2:25 PM, Richard Damon wrote:
On 4/28/24 2:58 PM, olcott wrote:
On 4/28/2024 1:39 PM, Richard Damon wrote:
On 4/28/24 2:19 PM, olcott wrote:
On 4/28/2024 1:06 PM, Richard Damon wrote:
On 4/28/24 1:50 PM, olcott wrote:
On 4/28/2024 11:08 AM, Richard Damon wrote:
On 4/28/24 11:33 AM, olcott wrote:
On 4/28/2024 10:08 AM, Richard Damon wrote:
On 4/28/24 9:52 AM, olcott wrote:
On 4/28/2024 8:19 AM, Richard Damon wrote:
On 4/28/24 8:56 AM, olcott wrote:
On 4/28/2024 3:23 AM, Mikko wrote:
On 2024-04-28 00:17:48 +0000, olcott said:
>
Can D simulated by H terminate normally?
>
One should not that "D simulated by H" is not the same as
"simulation of D by H". The message below seems to be more
about the latter than the former. In any case, it is more
about the properties of H than about the properties of D.
>
>
D specifies what is essentially infinite recursion to H.
Several people agreed that D simulated by H cannot possibly
reach past its own line 03 no matter what H does.
>
Nope, it is only that if H fails to be a decider.
>
>
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*
*We don't make this leap of logic. I never used the term decider*
>
>
You admit that people see that as being a claim about the Halting Problem, and thus the implied definitons of the terms apply.
>
>
The only way to get people to understand that I am correct
and thus not always ignore my words and leap to the conclusion
that I must be wrong is to insist that they review every single
detail of all of my reasoning one tiny step at a time.
>
>
>
No, the way to get people to understand what you are saying is to use the standard terminology, and start with what people will accept and move to what is harder to understand.
>
People have no obligation to work in the direction you want them to.
>
Yes, when you speak non-sense, people will ignore you, because what you speak is non-sense.
>
You are just proving that you don't understand how to perform logic, or frame a persuasive arguement.
>
That fact that as far as we can tell, your "logic" is based on you making up things and trying to form justifications for them, just makes people unwilling to attempt to "accept" your wild ideas to see what might make sense.
>
>
Linguistic determinism is the concept that language and its structures
limit and determine human knowledge or thought, as well as thought
processes such as categorization, memory, and perception.
https://en.wikipedia.org/wiki/Linguistic_determinism
>
So? Since formal logic isn't based on Linguistics, it doesn't directly impact it. IT might limit the forms we
>
>
Some of the technical "terms of the art" box people into misconceptions
for which there is no escape. Some of the technical "terms of the art"
I perfectly agree with.
>
*Important technical "term of the art" that I totally agree with*
Computable functions are the formalized analogue of the intuitive notion
of algorithms, in the sense that a function is computable if there
exists an algorithm that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
>
But you seem to miss that Halting isn't a "Computable Function", as Turing Proved.
>
>
Even the term "halting" is problematic.
For 15 years I thought it means stops running for any reason.
>
And that shows your STUPIDITY, not an error in the Theory.
>
Now I know that it means reaches the final state. Half the
people here may not know that.
>
No, I suspect most of the people here are smarter than that.
>
>
What Turing proved or did not prove requires carefully
examining every tiny step and not simply leaping to the
conclusion that Turing was right therefore I am wrong.
>
Turing PROVED he was right with a rigorous proof that has been examined by many people and no errors found.
>
You just admitted that you have been working under wrong definitions, and have no grounds to claim you understand all (or any) of what you talk about.
>
Yet, you have the gaul to claim that you must be right and everyone else is wrong, just after admitting that you have been wrong for most of the time.
>
>
>
You claim you want to work in a manner to save time, but then seem to explicitly go on a tack that will force you to waste time by needing to return to your prior points when you change the definition and prove them again.
>
>
I am only interested in an actual honest dialogue. Because of this I
must insist that any dialogue must go through every single detail of
my reasoning one tiny nuance of a point at time.
>
So, why do you insist that people must do it YOUR way.
>
>
I insist that people go over every single detail of my reasoning
instead of saying "no matter what you say Turing was right therefore
you are wrong".
>
But since your "reasoning" begins by making dodgy assumptions, people are going to reject that from the start. And then you insist that people start by accepting your dodgy assumptions, with a promise to prove them later. START by proving them, and maybe people will look at your work.
>
So far, everything that I have seen you present has been based on the idea that "Turing is wrong and I am right, and I ask you to trust me on by dodgy assumptions".
>
Since previously you point blanks said that H, as a Halt Decider was "Correct" as a Halt Decider to return non-halting for H(D,D) even though D(D) halted, and the DEFINITION of H(D,D) was to ask about the behavior of D(D), but "for reasons" the wrong answer was correct because D(D) doesn't always behave the same way when that is counter to the fundamental definitions of Computation Theory.
>
It then came out that the reason was that H never was the required computation (since it depended on a hidden input) so you whole proposal was just a lie.
>
>
That is the OPPOSITE of "Honest Dialog"
>
>
I have spent 20 years doing this and found that this is the only
possible way to get people to actually validate my actual reasoning
and not simply ignore my words and leap to the conclusion that I
must be wrong.
>
>
Nope, perhaps you learned that you can get sidetracked, but it is not the only way.
>
I think your biggest problem that keeps you from getting to where you want to get to is not knowing anything about the fields you try to talk about.
>
We can go around and around about this until one of us gets
bored, yet I absolutely will not progress to any other points
until we have mutual agreement on the current point:
>
01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
>
Simulating termination analyzer H determines whether or not
D(D) simulated by H can possibly reach its final state at its
own line 06 and halt whether or not H aborts its simulation.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
>
>
And, until you actually DEFINE the terms I have asked about, we can go no farther. I can not "agree" to something that has poorly defined words in it.
>
The above is 100% complete with no other terminology needed.
>
Nope.
>
Unless you accept that it is true because it is trivially true, that H is "correct" to say its simulation of the input didn't finish because H aborted it simulation, and an aborted simulation of course never reaches the end.
>
And thus, ANY such Simulation Termination analyzer would be correct to decide that ALL inputs were needing to be terminated because that is what it did.
>
>
>
For instance, how can "whether or not H aborts its simulation" have any meaning for what you have defined H to be, since H is a single program, and that will always do what it is programmed to do.
>
>
The above is clearly not any single program.
The above is a C version of the Linz template.
>
Nope.
>
Linz template has D using a COPY of H,
>
I say that X is like Y in one exact way and you say no X
is not like Y in every possible way.
>
My H/D <is> a program template in that it simultaneously refers to
an infinite set of every possible H that simulates D.
>
>
So, you admit that D is NOT a C version of the Linz input, as Linz's H^ was an actual Program based on the decider H.
>
>
My H (above) is exactly the same as the Linz H in that it specifies
an infinite set of implementations of H.
>
Nope, Linz's H is a SINGLE machine, chosen out of that infinite set.
I say that MY H is just like the Linz H in that they both
have Y you say no you are wrong they do not both have X.
>
>
No, you say your H has property Y that Linz's H does not Have.
>
>
My H has many properties the Linz H has many properties.
One of them that they share in common is that:
*they are templates specifying an infinite set of implementations*
*they are templates specifying an infinite set of implementations*
*they are templates specifying an infinite set of implementations*
>
Nope. You just don't understand the proof then.
>
H does NOT specify a templates of an infinite set of posibilities, but a specific machine out of that infinite set.
>
We know this because H is DEFINED to be a TURING MACHINE, and an actual TURING MACHINE can not be a TEMPLATE.
>
>
Also an actual Turing machine must specify all of it steps
one cannot correctly say and the magic occurs here: ⊢*
and have an actual Turing Machine.
>
>
Right, the ACTUAL Turing Machine will have a specific path. The specification that limits what machines could meet the requirements to be this H allow it to use any combination of states that get there.
>
Remember, Linz isn't fully specifing exactly how H will get to its answer, but is providing a structure that defines the set of machines that we can choose a particular machine from.
>
The SPECIFIACTION defines an infinte set of machines.
>
>
OK so we are perfect agreement on this.
Thus Linz H/Ĥ is isomorphic to My H/D in that they
both specify an infinite set of implementations.
>
The specification of H specifies a set of implementations. Whether the
set is infinite is not specified but be worked out separately. Turns out
that the set is not infinite but empty.
>
00 int H(ptr x, ptr x) // ptr is pointer to int function
01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
>
That is the specification of the relationship between H and D.
At this point in the my proof all that we know about H is that
D is simulated by H(D,D). Since there is fully operational code
that does this your point that such an H does not exist is fully
refuted.
>
From this specification follows that there is a D for each H
>
Not when looking at the from software engineering. D is a finite
string always having the exact same bytes. It always calls whatever
H at the exact same machine address.
>
Looking at it this way disconnects it from any discussion of halting
tehorem and related topics.
>
We can also look at this as a class of H/D pairs such that above D
is the template for every D and even though every D has the exact
same bytes and always behave the exact same way we can construe them
as different D instances.
>
Therefore this is the way to look at it.
>
It is ordinary software engineering that conclusively proves that
no D of any H/D pair where D is simulated by H ever reaches past
its own line 3.
>
This was the first person to agree with that:
On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching it that the
> program is repeating itself. Thus we can appreciate
> that it will never reach the final "ret" - indeed,
> it won't even get to the infinite loop identified above.
This quote does not prove anything as it contains pronouns that
refer to something not quoted.
It was enough for Richard to agree
Message-ID: <
1a63f362-31ad-4d75-b339-f91b2d95ea00n@googlegroups.com>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3C1a63f362-31ad-4d75-b339-f91b2d95ea00n%40googlegroups.com%3E Ordinary understanding of the C code already proves my point.
I can't imagine people that are care about computer science
that can't understand a simple C function.
That seems to me like going to an auto mechanic and asking to
have the spark plugs changed and the mechanic is confused because
they never heard of "spark plugs".
Since then I had three experts on C agree with that and two of
them have masters degrees in computer science. Last night Richard
agreed with Paul that too.
>
No, it proves that the simulation of H is never continued past
the line 3. D itselfs continues further if the H it was made of
is a decider.
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
A that contais the ambigous term "D(D) simulated by H" an agreement
does not mean anything.
The following is 100% of the actual D. The only way that
this could be ambiguous is if you don't kn ow the first
that about C.
Can D correctly simulated by H terminate normally?
00 int H(ptr x, ptr x) // ptr is pointer to int function
01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
You don't seem to understand that once the directly executed
H(D,D) stops simulating its input that every aspect of the
simulated D immediately stops.
That depends on the interpretation of the ambiguous term "simulated D".
I think that you are playing head games. I use an x86 emulator to correctly emulate the x86 instructions of D in the order that they
are specified. A C interpreter would work as well.
_D()
[00001d72] 55 push ebp
[00001d73] 8bec mov ebp,esp
[00001d75] 51 push ecx
[00001d76] 8b4508 mov eax,[ebp+08]
[00001d79] 50 push eax ; push D
[00001d7a] 8b4d08 mov ecx,[ebp+08]
[00001d7d] 51 push ecx ; push D
[00001d7e] e8cff7ffff call 00001552 ; call H
[00001d83] 83c408 add esp,+08
[00001d86] 8945fc mov [ebp-04],eax
[00001d89] 837dfc00 cmp dword [ebp-04],+00
[00001d8d] 7402 jz 00001d91
[00001d8f] ebfe jmp 00001d8f
[00001d91] 8b45fc mov eax,[ebp-04]
[00001d94] 8be5 mov esp,ebp
[00001d96] 5d pop ebp
[00001d97] c3 ret
Size in bytes:(0038) [00001d97]
This is not computer science it is only software engineering.
Therefore not convincing.
We must have agreement on verified facts before proceeding
otherwise people leap to the conclusion that I must be wrong
on the basis of not paying attention to what I am saying.
There is no judgment call here it is all empirical fact.
Empirical facts are not proofs. That someting sometimes happened
some way does not generalize to other more or less similar things
at other times.
If you are telling the truth that D(D) simulated by H
is ambiguous to you then you have insufficient skill at C.
Can D correctly simulated by H terminate normally?
00 int H(ptr x, ptr x) // ptr is pointer to int function
01 int D(ptr x)
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
Line 11 H(D,D) is executed.
Line 01 H begins to simulate D(D)
Line 02 H simulates D(D)
Line 03 Simulated D calls simulated (H,D)
Line 01 H begins to simulate D(D)
Line 02 H simulates D(D)
Line 03 Simulated D calls simulated (H,D)
Line 01 H begins to simulate D(D)
Line 02 H simulates D(D)
Line 03 Simulated D calls simulated (H,D) ...
-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
…