On 5/21/2024 10:09 PM, Richard Damon wrote:
On 5/21/24 10:05 PM, olcott wrote: >> On 5/21/2024 8:46 PM, Richard Damon wrote:
>
You persistently did refuse to provide the message_ID
this did make you look like a liar.
Because why do I need to provide a pointer to a message you read and ignored.
YOU CONTINUE TO USE THE CHANGE-THE-SUBJECT FAKE REBUTTAL
AS SOON AS YOU DO THIS I IGNORED EVERYTHING ELSE THAT YOU SAID.
Note, I kept on saying I would give it under a condition, one that I am going to hold you to, that you admit that you have been wrong about your claims that others haven't refuted you.
You used a loophole that was not really there yet I can
call this an honest mistake and not a lie.
ANYTIME form now one that you make that claim, I can point out that you have been wrong about this in the past.
Message-ID with every claim that I have been wrong
on any point going forward.
>
>
>
>
I made sure to not call you a liar on this. I said that until
proved otherwise I will assume that you are a liar and then
you proved otherwise.
>
But you continued to assert a statement that was untrue, even though it was proved incorrect, you LATER changed your definition to try to get around my answer,
>
>
You persistently did refuse to provide the message_ID
this did make you look like a liar.
Because you refued to make the pledge not to use the false arguement that you have not be refuted.
You used a loophole that was not really there yet I can
call this an honest mistake and not a lie.
>
You still haven't refuted the first method.
>
>
Sure I have this H is ONLY simulator thus the first method
loses its basis.
Why is that? Isn't a valid simulation (one that your own H uses) is to replace the call to H with an "equivalent" response. WHy else do you list the simulation of the call H as the results of the simulation that H does.
THAT FAILS TO MEET THIS SPEC THAT I WOULD NOT HAVE WRITTEN
EXCEPT FOR YOU CRITIQUE, THANKS
In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation.
So, by your claim above, your H isn't allowed to presume by its logic that a call to H will not return, as that isn't a "simulation" of the input.
Only by moving the goal posts, do you try to argue.
Note, this is why I am asking for you to come up with a PRECISE specification of what you are claiming to do.
*SURE AND THAT IS A GREAT IDEA THAT IS PROVING VERY HELPFUL THANKS*
>
>
Thus, it is proven that you whole concept is just built on inconsistant lies.
>
>
>
This is the only post about this subject that I will respond
to from you. I have to paint half of my house and empty my
garage within about a week.
>
If you can find some source that conclusively proves that
not all pure functions are computable functions I would like
to see it. All of the experts that I could find seem to agree
that all pure functions in C would be computable functions
by a Turing machine.
>
So, you just don't understand that "Computable Function" is a Term-of-the-art to talk about the mathematical mapping, an NOT the algorithm that shows the mapping is computable.
>
>
Pure functions <are> Turing computable functions until you
conclusively prove otherwise.
>
So, you still don't understand the meaning of the words.
>
>
>
Try and point out the specific error and I will correct any
mistake that you find. Until you provide a basis I will assume
that your claim is baseless.
>
"Correct Simulation" to show something about non-termination, must be per the methods of Computation Theory, which means like a UTM, which means it does not stop.
>
>
It is essentially trivial to see that D correctly simulated by H
cannot possibly reach its own final state at line 06 because
D correctly simulated by H remains stuck in recursive simulation.
Which, due to your now clarified definition of what you mean by "correctly simulated" means absolutly NOTHING in regards to the behavior of the input.
In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation.
It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that
D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.
>
A "Computable Function" isn't a program, but a mathematical concept of a mapping from the input set to the output set for which there exists an finite algoritm that computes it. (The program is that algorithm, not the Function).
>
>
How do we tell if a C function is Turing Computable?
That Term doesn't apply to C funcitons at all, but to mathematical mappings.
Do you mean the computational equivalent of a Turing Machine?
Not quite, almost. The computational equivalent of a Turing computable function. TM's can get stuck in loops.
>
Note also, a "Pure Function" and this algorithm are NOT exactly equivalent. Pure Function might take a hidden input that makes copies of the function not equivalent, breaking them form being the requirements of an algorithm, which is a bit stricter, as it requires that ALL COPIES return the same answer for the same inputs.
>
>
These H/D pairs only simulate.
And thus your logic has divorsed itself from behavior of the machine described by the input, since your simulation is not "Correct" by the correct meaning.
In the above case a simulator is an x86 emulator that correctly emulates at least one of the x86 instructions of D in the order specified by the x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the order specified by the x86 instructions of H thus calling H(D,D) in recursive simulation.
Alternatives would be incorrectly emulating the x86 instructions
of D or emulating them in the wrong order, or both. Likewise for H.
>
Also, it is possible for an algorithm to violate the definiton of a "Pure Function" in certain limited manners, and still be a proper algorithm, the key is that the definition of an algorithm is a strictly Input to Output relationship, and doesn't talk about how the answer is given.
>
>
I am saying that it must be a pure function.
And you would be wrong. I can show functions the Computational Equivalent of a Turing Machine that violate the requirement of not using static memory.
Then my measure is more restrictive than necessary yet still
sufficiently restrictive.
>
>
Your claim is like saying that cats are 10 story office building.
>
>
One key point that make "Pure Functions" not necessarily equivalent to a Turing Machine is the ability to get "hidden inputs" from things like their own program address, something a Turing Machine doesn't have.
>
>
*That is irrelevant to the current post*
*You can always look at the title and see if you went off topic*
>
No, you keep making the error, and thus destroy your arguement.
>
>
Since I am only responding to you via this single thread I
don't have to cut off the first divergence from the title.
>
>
>
*This boiler plate will be the only reply*
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.
>
Enlarge the category a tiny little bit and then the time
becomes infeasible.
>
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
>
>
>
And if you can't actually define your category or the thing to be analyzied you are just wasting your time, as if you don't know where you are going, it is hard to find the path.
>
>
The way I see it I defined it correctly and completely and you
are simply pretending otherwise. Until you prove otherwise I
will continue to assume this.
>
But since you can't clearly state it, it means we can't help you.
>
>
I stated it perfectly and the proof of this is that
you did not point to any gaps in my spec.
Nope.
Failing to point to gaps right now is evidence that you
are not telling the truth. Just like the election deniers.
There is evidence somewhere, OK then give me a link or I will
assume that you must be lying about election fraud evidence.
>
>
You seem to favor baseless rhetoric because you know that baseless
rhetoric with ad hominem mixed in is very convincing for gullible fools.
Gullible fools are outside of my target audience.
>
>
Nope, your deception seems to be an attempt to go after gullible fools.
>
>
THE ONLY REASON THAT I WORK ON THIS IS TO MATHEMATICALLY
FORMALIZE THE NOTION OF TRUTH ITSELF SO THAT THE NAZI
LIARS CANNOT GET AWAY WITH THEIR LIES.
But since your logic is based on LIES, like that H(D,D) is allowed to say its input is non-halting when D(D) Halts, that seems unlikely.
That you fail to comprehend what I say is not even slight
evidence that I am incorrect. The one "mistake" that you
pointed out used a loophole that didn't really exist.
>
If you where honest, you could post you whole arguement and let it be worked on.
>
>
WE ARE ONLY TALKING ABOUT THE SUBJECT LINE OF THIS THREAD.
You said otherwise.
>
From your past, the reason you need to break the arguement into pieces is you need to seperate to logic to allow a change of definition between the sections.
>
>
IT IS BECAUSE I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE
ENDLESS DEFECTION
So, why do you waste so much digging your heals on triva.
Just answer the questions and we can move on.
*IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA*
>
For instance, you definition here of correct simulation means your results can not be used to show non-halting.
>
>
WE CAN GET TO THIS POINT AFTER WE FINISH THE SUBJECT OF THE THREAD
I DON'T HAVE ENOUGH TIME LEFT TO TOLERATE ENDLESS DEFECTION
Then you don't have time to just repeat the same request over and over.
*IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA*
*IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA*
*IT IS THE KEY BASIS OF MY WHOLE PROOF THUS NOT TRIVIA*
>
My guess is in a later section, you will pull out the rule that if a correct simulation doesn't reach a final state, the input is non-halting, which is just a LIE because you have changed definition mid proof.
>
This has been your history.
>
It is trivial to see that D correctly simulated by H cannot
possibly reach its own final state at line 06 and halt because
D correctly simulated by H remains stuck in recursive simulation.
>
Unless H aborts its simulation, which it must do to answer. And, since it does, that means the partial simulation it does, doesn't show that the machine in non-halting.
IT IS TRIVIAL TO SEE THAT WHEN 1 TO 2^64 STEPS OF D ARE CORRECTLY SIMULATED BY H THAT BECAUSE D REMAINS STUCK IN RECURSIVE SIMULATION
THE REST IS OUTSIDE OF THE SCOPE OF THE TITLE OF THIS THREAD
WE CAN GET TO OTHER POINTS AS SOON AS THIS POINT IS FINISHED
This is one reason you need to clarify you exact meaning. Since you have implied that your goal is about halting, you are stuck with the definitions from that, and to allow deviations, we need EXPLICIT agreement that these results can not be then just used to show non-halting, as that would be a lie.
Of course, if you admit that you aren't working on deciding halting, then you have just wasted you 20 years, so showing that you can POOP decider this one machine doesn't mean anything. The non-computability of Halting still can be used for all of the proofs it is part of.
And, if you want to revamp the logic system with new definitions, you are working at the wrong end, you need to go to the foundations, and start there, and fully define the axioms you are going to be using.
-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
Can D simulated by H terminate normally?
Re: Can D simulated by H terminate normally? POE