XPost: comp.theory
From: chris.m.thomasson.1@gmail.com
On 10/28/2025 5:33 PM, olcott wrote:
> On 10/28/2025 7:25 PM, Kaz Kylheku wrote:
>> On 2025-10-29, olcott wrote:
>>> On 10/28/2025 6:52 PM, Kaz Kylheku wrote:
>>>> On 2025-10-28, olcott wrote:
>>>>> On 10/28/2025 5:14 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-28, dbush wrote:
>>>>>>> On 10/28/2025 4:57 PM, olcott wrote:
>>>>>>>> On 10/28/2025 2:37 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-10-28, olcott wrote:
>>>>>>>>>> On 10/28/2025 11:35 AM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-10-28, olcott wrote:
>>>>>>>>>>>> Deciders only compute a mapping from their actual
>>>>>>>>>>>> inputs. Computing the mapping from non-inputs is
>>>>>>>>>>>> outside of the scope of Turing machines.
>>>>>>>>>>>
>>>>>>>>>>> Calculating the halting of certain inputs is indeed impossible
>>>>>>>>>>> for some halting algorithms.
>>>>>>>>>>
>>>>>>>>>> Not just impossible outside of the scope of every Turing machine.
>>>>>>>>>> Its the same kind of thing as requiring the purely mental object
>>>>>>>>>> of a Turing machine to bake a birthday cake.
>>>>>>>>>
>>>>>>>>> It simply isn't. Inputs that are not correctly solvable by some
>>>>>>>>> deciders are decided by some others.
>>>>>>>>>
>>>>>>>>
>>>>>>>> THIS INPUT IS SOLVABLE
>>>>>>>> THE NON-INPUT IS OUT-OF-SCOPE
>>>>>>>
>>>>>>> Then why do you claim that H(D) must decide on this non input?
>>>>>>
>>>>>> Because he claims that D is two things; it has two properties:
>>>>>> D.input and D.noninput.
>>>>>>
>>>>>> H(D) is solving D.input (as machines are required) and (believe
>>>>>> him when he says) that D.input is nonterminating.
>>>>>>
>>>>>> What is terminating is D.noninput (he acknowledges).
>>>>>>
>>>>>
>>>>> Good job.
>>>>> Your naming conventions make things very clear.
>>>>>
>>>>>> If some H_other decider is tested on H_other(D), then the "Olcott
>>>>>> reality distortion wave function" (ORDF) collapses, and D.input
>>>>>> becomes the same as D.noninput.
>>>>>>
>>>>>
>>>>> *So we need to clarify*
>>>>> D.input_to_H versus
>>>>> D.non_input_to_H which can be:
>>>>> D.input_to_H1
>>>>> D.executed_from_main
>>>>>
>>>>> I take Rice's semantic properties of programs and
>>>>> clarify that this has always meant the semantic
>>>>> properties of finite string machine descriptions.
>>>>>
>>>>> Then I further divide this into
>>>>> (a) semantic properties of INPUT finite strings
>>>>> (b) semantic properties of NON_INPUT finite strings
>>>>
>>>> The problem is that "input" is just a role of some datum in a context,
>>>> like a function
>>>>
>>>> The input versus non-input distinction cannot be found in any
>>>> binary digit of the bit string comprising the datum itself.
>>>>
>>>
>>> Unless you bother to pay attention to the fact that
>>> the sequence of steps of D simulated by H is a different
>>> sequence of steps than D simulated by H1.
>>
>> How do we know what is correct?
>>
>
> Because all deciders only report on what their
> input specifies H(D)==0 and H1(D)==1 are both correct.
>
>> Suppose I'm given an input D, and two deciders X and Y.
>> I know nothing about these. (But they are simulating deciders,
>> producing different executions.)
>>
>> X accepts, Y rejects.
>>
>> Do I regard both of them as right? Or one of them wrong?
>> If so, which one? Or both wrong?
>>
>> Suppose I happen to be sure that D halts. So I know X is correct.
>>
>
> As far as a DOS (denial of service) attack
> goes H(D)==0 correctly rejects its input.
Imvvho, I don't think you know what to do with a proper DOS, or a DDOS.
Think if a bunch of connections some in, they send some commands to the
server, communicate a little, then stop for say a random amount of time,
then continue, then stop. Then a flood of connections come in that
execute commands that upload/download big random files, over and over
again. Some of them say done!, Some of them hang around for say 20
minutes holding your socket open. I don't think you know what a DOS even
is? Humm... lol.
[...]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
