On 8/3/2022 6:46 AM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>
>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>
>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>
>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>
>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>
>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>
>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>
>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>> running.
>>>>>>>>>
>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>
>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>
>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>
>>>>>>> You don't get to change the question.
>>>>>> When the question is WRONG, I do get to change the question.
>>>>>
>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>
>>>> main()
>>>> {
>>>> H(P,P);
>>>> P(P);
>>>> }
>>>>
>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>> has been executed first and H has not yet been executed then H is
>>>> reporting incorrectly, directly against the verified facts.
>>>
>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>> *The above specification is incoherent
>
> So you're saying that it's impossible to create an H that meets this specification?

In the same way that it is impossible to correctly answer this question:
What time is it (yes or no)?

*The above spec is flat out wrong in some cases*
No one ever noticed this before because they never examined simulating
halt decider thoroughly enough to see that the behavior of the correctly
simulated input by H diverges from the directly executed P(P).

The ultimate measure of the behavior of the input is the correct
simulation of this input by H.

A halt decider must compute the mapping from its inputs to an accept
or reject state on the basis of the actual behavior that is actually
specified by these inputs.

int sum(int x, int y) { return x + y; }
Otherwise you have something like sum(3,4) returning the sum of 4+5.

--
Copyright 2022 Pete Olcott

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