In order to make my halt decider a pure function it had to have a way to
look at the inputs to function calls. In order to look at the inputs to
function calls it had to know how many inputs that a function has.

This is DFA analyzes C source code to provide the number of parameters
of each function in the file. The number of parameters per function is
the number of {vt} matches per {fn} match.

The only thing that will change with this file is that the halt decider
will use different halt deciding criteria so that the halt decider
becomes a pure function.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

In computer programming, a pure function is a function that has the
following properties:[1][2]

(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).

(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).

https://en.wikipedia.org/wiki/Pure_function

//
// Deterministic Finite Automaton (DFA) recognizer
// of C function headers.

// Character Classes
//
EMPTY [0]
ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
NUMERIC [0123456789]
WS [0x09,0x0A,0x0D,0x20]
LPAREN [(]
RPAREN [)]
ASTERISK [*]
COMMA [,]
COMMENT [0x2f]
NEWLINE [0x0A]
ASCII [0x20-0x7e]
CONTROL [0x00-0x09,0x0b-0x1f,0x7f]

// Recognized Patterns
//
{et} Empty
{ft} Function_Type
{fn} Function_Name
{vt} Variable_Type
{vn} Variable_Name
{fh} Function_Header

// DFA Definition to recognize C function headers

// begin of function type
<00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
<01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
<02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)

// begin of function name
<03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
<04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
<05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)

// begin of variable type
<06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
<07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
<08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)

// begin of variable name
<09> WS (09) ALPHA(10) NUMERIC(00) [*] (00)
<10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
<11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)

// ignores all "//" comments
<12> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](13)
<13> CONTROL(13) ASCII(13) [0x0A] (00)

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/23/21 9:27 PM, olcott wrote:
> In order to make my halt decider a pure function it had to have a way to
> look at the inputs to function calls. In order to look at the inputs to
> function calls it had to know how many inputs that a function has.
>
> This is DFA analyzes C source code to provide the number of parameters
> of each function in the file. The number of parameters per function is
> the number of {vt} matches per {fn} match.
>
> The only thing that will change with this file is that the halt decider
> will use different halt deciding criteria so that the halt decider
> becomes a pure function.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> In computer programming, a pure function is a function that has the
> following properties:[1][2]
>
> (1) The function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams).
>
> (2) The function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> https://en.wikipedia.org/wiki/Pure_function
>
>
>
> //
> //  Deterministic Finite Automaton (DFA) recognizer
> //  of C function headers.
>
> // Character Classes
> //
>     EMPTY [0]
>     ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>   NUMERIC [0123456789]
>        WS [0x09,0x0A,0x0D,0x20]
>    LPAREN [(]
>    RPAREN [)]
>  ASTERISK [*]
>     COMMA [,]
>   COMMENT [0x2f]
>   NEWLINE [0x0A]
>     ASCII [0x20-0x7e]
>   CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>
>
> // Recognized Patterns
> //
> {et} Empty
> {ft} Function_Type
> {fn} Function_Name
> {vt} Variable_Type
> {vn} Variable_Name
> {fh} Function_Header
>
> // DFA Definition to recognize C function headers
>
> // begin of function type
> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>
> // begin of function name
> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>
> // begin of variable type
> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>
> // begin of variable name
> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>
> // ignores all "//" comments
> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>

Ok,

Just remember that being a 'Pure Funciton' isn't the actual requirement,
the decider needs to be a Mathematical Computation, which means that all
copies of it, when given the same inputs, generates the same outputs.

You STILL have the error that you treat H as a 'pure simulator' when it
is not, it is only a 'pure simulatior until' and as such, the behavior
of the copy of H in H^ DOES have an affect on the behavior of that H^.
Remember, a 'Pure Simulator' (aka a UTM) NEVER stops simulating until
the machine it is simulating ends, even if that takes forever.

Do you think you are immortal as you will be living until you die?

This effect is easy to actually prove by looking at the trace of the run
of H^/P when run as a top level mchine, and seeing that the call to H
inside it does abort its simulation, returns non-halting, and thus H^/P
does Halt.

If H is actually a Computation, as requried, then ALL copies of it must
do exactly that same thing.

On 10/23/2021 8:49 PM, Richard Damon wrote:
>
> On 10/23/21 9:27 PM, olcott wrote:
>> In order to make my halt decider a pure function it had to have a way
>> to look at the inputs to function calls. In order to look at the
>> inputs to function calls it had to know how many inputs that a
>> function has.
>>
>> This is DFA analyzes C source code to provide the number of parameters
>> of each function in the file. The number of parameters per function is
>> the number of {vt} matches per {fn} match.
>>
>> The only thing that will change with this file is that the halt
>> decider will use different halt deciding criteria so that the halt
>> decider becomes a pure function.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> In computer programming, a pure function is a function that has the
>> following properties:[1][2]
>>
>> (1) The function return values are identical for identical arguments
>> (no variation with local static variables, non-local variables,
>> mutable reference arguments or input streams).
>>
>> (2) The function application has no side effects (no mutation of local
>> static variables, non-local variables, mutable reference arguments or
>> input/output streams).
>>
>> https://en.wikipedia.org/wiki/Pure_function
>>
>>
>>
>> //
>> //  Deterministic Finite Automaton (DFA) recognizer
>> //  of C function headers.
>>
>> // Character Classes
>> //
>>      EMPTY [0]
>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>    NUMERIC [0123456789]
>>         WS [0x09,0x0A,0x0D,0x20]
>>     LPAREN [(]
>>     RPAREN [)]
>>   ASTERISK [*]
>>      COMMA [,]
>>    COMMENT [0x2f]
>>    NEWLINE [0x0A]
>>      ASCII [0x20-0x7e]
>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>
>>
>> // Recognized Patterns
>> //
>> {et} Empty
>> {ft} Function_Type
>> {fn} Function_Name
>> {vt} Variable_Type
>> {vn} Variable_Name
>> {fh} Function_Header
>>
>> // DFA Definition to recognize C function headers
>>
>> // begin of function type
>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>
>> // begin of function name
>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>
>> // begin of variable type
>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>
>> // begin of variable name
>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>
>> // ignores all "//" comments
>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>
>
> Ok,
>
> Just remember that being a 'Pure Funciton' isn't the actual requirement,
> the decider needs to be a Mathematical Computation, which means that all
> copies of it, when given the same inputs, generates the same outputs.
>
> You STILL have the error that you treat H as a 'pure simulator' when it
> is not, it is only a 'pure simulatior until' and as such, the behavior
> of the copy of H in H^ DOES have an affect on the behavior of that H^.
> Remember, a 'Pure Simulator' (aka a UTM) NEVER stops simulating until
> the machine it is simulating ends, even if that takes forever.
>

void Infinite_Loop()
{ HERE: goto HERE;
}

_Infinite_Loop()
[00000ab0](01) 55 push ebp
[00000ab1](02) 8bec mov ebp,esp
[00000ab3](02) ebfe jmp 00000ab3
[00000ab5](01) 5d pop ebp
[00000ab6](01) c3 ret
Size in bytes:(0007) [00000ab6]

Are you saying that the only way that a simulating halt decider can
correctly decide that the above code will never stop running is to wait
until the end of time?

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/23/21 10:16 PM, olcott wrote:
> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>
>> On 10/23/21 9:27 PM, olcott wrote:
>>> In order to make my halt decider a pure function it had to have a way
>>> to look at the inputs to function calls. In order to look at the
>>> inputs to function calls it had to know how many inputs that a
>>> function has.
>>>
>>> This is DFA analyzes C source code to provide the number of
>>> parameters of each function in the file. The number of parameters per
>>> function is the number of {vt} matches per {fn} match.
>>>
>>> The only thing that will change with this file is that the halt
>>> decider will use different halt deciding criteria so that the halt
>>> decider becomes a pure function.
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>> In computer programming, a pure function is a function that has the
>>> following properties:[1][2]
>>>
>>> (1) The function return values are identical for identical arguments
>>> (no variation with local static variables, non-local variables,
>>> mutable reference arguments or input streams).
>>>
>>> (2) The function application has no side effects (no mutation of
>>> local static variables, non-local variables, mutable reference
>>> arguments or input/output streams).
>>>
>>> https://en.wikipedia.org/wiki/Pure_function
>>>
>>>
>>>
>>> //
>>> //  Deterministic Finite Automaton (DFA) recognizer
>>> //  of C function headers.
>>>
>>> // Character Classes
>>> //
>>>      EMPTY [0]
>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>    NUMERIC [0123456789]
>>>         WS [0x09,0x0A,0x0D,0x20]
>>>     LPAREN [(]
>>>     RPAREN [)]
>>>   ASTERISK [*]
>>>      COMMA [,]
>>>    COMMENT [0x2f]
>>>    NEWLINE [0x0A]
>>>      ASCII [0x20-0x7e]
>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>
>>>
>>> // Recognized Patterns
>>> //
>>> {et} Empty
>>> {ft} Function_Type
>>> {fn} Function_Name
>>> {vt} Variable_Type
>>> {vn} Variable_Name
>>> {fh} Function_Header
>>>
>>> // DFA Definition to recognize C function headers
>>>
>>> // begin of function type
>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>
>>> // begin of function name
>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>
>>> // begin of variable type
>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>
>>> // begin of variable name
>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>
>>> // ignores all "//" comments
>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>
>>
>> Ok,
>>
>> Just remember that being a 'Pure Funciton' isn't the actual
>> requirement, the decider needs to be a Mathematical Computation, which
>> means that all copies of it, when given the same inputs, generates the
>> same outputs.
>>
>> You STILL have the error that you treat H as a 'pure simulator' when
>> it is not, it is only a 'pure simulatior until' and as such, the
>> behavior of the copy of H in H^ DOES have an affect on the behavior of
>> that H^. Remember, a 'Pure Simulator' (aka a UTM) NEVER stops
>> simulating until the machine it is simulating ends, even if that takes
>> forever.
>>
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> _Infinite_Loop()
> [00000ab0](01)  55              push ebp
> [00000ab1](02)  8bec            mov ebp,esp
> [00000ab3](02)  ebfe            jmp 00000ab3
> [00000ab5](01)  5d              pop ebp
> [00000ab6](01)  c3              ret
> Size in bytes:(0007) [00000ab6]
>
> Are you saying that the only way that a simulating halt decider can
> correctly decide that the above code will never stop running is to wait
> until the end of time?
>

No. You seem to have a reading comprension problem.

The Simulating Halt Decider is fully allowed to abort the simulation of
the machine it is simulationg.

The only issue is that IF it does so, it can't treat itself as if it was
a UTM/Pure SImulator, and thus the fact that it never saw the comptation
reach a halting state isn't proof of anything.

For the above program, that isn't an issue, it can easily see the loop
without a conditional in it and thus detect that the loop is forever.

The same thing for a 'normal' infinite recursion that doesn't go though
H, that also is easily detected and aborted.

The problem is the recursion through H, which is NOT an 'infinite'
recursion for an H that is able to abort its simulation in this case. If
H can abort, it is NOT a UTM/Pure SImulator, so you can't use the
transform of converting the simulation of the simulator to the trace of
the simulated machine. It just doesn't Hold. You also can't 'ignore' the
presence of the copy of the simulator in the machine it is simulating,
as that copy DOES affect the behavior of the machine (dispite your false
rheteric claiming otherwise).

Your H uses UNSOUND logic to decide that H^ is non-halting, which is why
you come up with a Halting Computation appearing to be non-halting.

You logic conflates the version of your decider that does abort the
simulation with the totally different version that does not, and the
totally different version of H^ that uses that other version.

THAT IS JUST WROHG.

On 10/23/2021 10:19 PM, Richard Damon wrote:
> On 10/23/21 10:16 PM, olcott wrote:
>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>
>>> On 10/23/21 9:27 PM, olcott wrote:
>>>> In order to make my halt decider a pure function it had to have a
>>>> way to look at the inputs to function calls. In order to look at the
>>>> inputs to function calls it had to know how many inputs that a
>>>> function has.
>>>>
>>>> This is DFA analyzes C source code to provide the number of
>>>> parameters of each function in the file. The number of parameters
>>>> per function is the number of {vt} matches per {fn} match.
>>>>
>>>> The only thing that will change with this file is that the halt
>>>> decider will use different halt deciding criteria so that the halt
>>>> decider becomes a pure function.
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>> In computer programming, a pure function is a function that has the
>>>> following properties:[1][2]
>>>>
>>>> (1) The function return values are identical for identical arguments
>>>> (no variation with local static variables, non-local variables,
>>>> mutable reference arguments or input streams).
>>>>
>>>> (2) The function application has no side effects (no mutation of
>>>> local static variables, non-local variables, mutable reference
>>>> arguments or input/output streams).
>>>>
>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>
>>>>
>>>>
>>>> //
>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>> //  of C function headers.
>>>>
>>>> // Character Classes
>>>> //
>>>>      EMPTY [0]
>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>    NUMERIC [0123456789]
>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>     LPAREN [(]
>>>>     RPAREN [)]
>>>>   ASTERISK [*]
>>>>      COMMA [,]
>>>>    COMMENT [0x2f]
>>>>    NEWLINE [0x0A]
>>>>      ASCII [0x20-0x7e]
>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>
>>>>
>>>> // Recognized Patterns
>>>> //
>>>> {et} Empty
>>>> {ft} Function_Type
>>>> {fn} Function_Name
>>>> {vt} Variable_Type
>>>> {vn} Variable_Name
>>>> {fh} Function_Header
>>>>
>>>> // DFA Definition to recognize C function headers
>>>>
>>>> // begin of function type
>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>
>>>> // begin of function name
>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>
>>>> // begin of variable type
>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>
>>>> // begin of variable name
>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>
>>>> // ignores all "//" comments
>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>
>>>
>>> Ok,
>>>
>>> Just remember that being a 'Pure Funciton' isn't the actual
>>> requirement, the decider needs to be a Mathematical Computation,
>>> which means that all copies of it, when given the same inputs,
>>> generates the same outputs.
>>>
>>> You STILL have the error that you treat H as a 'pure simulator' when
>>> it is not, it is only a 'pure simulatior until' and as such, the
>>> behavior of the copy of H in H^ DOES have an affect on the behavior
>>> of that H^. Remember, a 'Pure Simulator' (aka a UTM) NEVER stops
>>> simulating until the machine it is simulating ends, even if that
>>> takes forever.
>>>
>>
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>>
>> _Infinite_Loop()
>> [00000ab0](01)  55              push ebp
>> [00000ab1](02)  8bec            mov ebp,esp
>> [00000ab3](02)  ebfe            jmp 00000ab3
>> [00000ab5](01)  5d              pop ebp
>> [00000ab6](01)  c3              ret
>> Size in bytes:(0007) [00000ab6]
>>
>> Are you saying that the only way that a simulating halt decider can
>> correctly decide that the above code will never stop running is to
>> wait until the end of time?
>>
>
> No. You seem to have a reading comprension problem.
>
> The Simulating Halt Decider is fully allowed to abort the simulation of
> the machine it is simulationg.
>
> The only issue is that IF it does so, it can't treat itself as if it was
> a UTM/Pure SImulator, and thus the fact that it never saw the comptation
> reach a halting state isn't proof of anything.

When a simulating halt decider acts as if it is a pure simulator and
watches the behavior of an infinite loop it can correctly abort the
simulation of this input and report that this input never halts. We can
generalize this simplest case of infinite execution to all other cases:

All that I am doing is generalizing this same idea. When-so-ever a
simulating halt decider can correctly axiomatically determine that its
input would never halt if it remained a pure simulator then it can abort
the simulation of this input and report that this input never halts.

When a simulating halt decider correctly axiomatically determines X then
we know that X is necessarily true.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/23/21 11:29 PM, olcott wrote:
> On 10/23/2021 10:19 PM, Richard Damon wrote:
>> On 10/23/21 10:16 PM, olcott wrote:
>>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>>
>>>> On 10/23/21 9:27 PM, olcott wrote:
>>>>> In order to make my halt decider a pure function it had to have a
>>>>> way to look at the inputs to function calls. In order to look at
>>>>> the inputs to function calls it had to know how many inputs that a
>>>>> function has.
>>>>>
>>>>> This is DFA analyzes C source code to provide the number of
>>>>> parameters of each function in the file. The number of parameters
>>>>> per function is the number of {vt} matches per {fn} match.
>>>>>
>>>>> The only thing that will change with this file is that the halt
>>>>> decider will use different halt deciding criteria so that the halt
>>>>> decider becomes a pure function.
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>> In computer programming, a pure function is a function that has the
>>>>> following properties:[1][2]
>>>>>
>>>>> (1) The function return values are identical for identical
>>>>> arguments (no variation with local static variables, non-local
>>>>> variables, mutable reference arguments or input streams).
>>>>>
>>>>> (2) The function application has no side effects (no mutation of
>>>>> local static variables, non-local variables, mutable reference
>>>>> arguments or input/output streams).
>>>>>
>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>
>>>>>
>>>>>
>>>>> //
>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>> //  of C function headers.
>>>>>
>>>>> // Character Classes
>>>>> //
>>>>>      EMPTY [0]
>>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>    NUMERIC [0123456789]
>>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>>     LPAREN [(]
>>>>>     RPAREN [)]
>>>>>   ASTERISK [*]
>>>>>      COMMA [,]
>>>>>    COMMENT [0x2f]
>>>>>    NEWLINE [0x0A]
>>>>>      ASCII [0x20-0x7e]
>>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>
>>>>>
>>>>> // Recognized Patterns
>>>>> //
>>>>> {et} Empty
>>>>> {ft} Function_Type
>>>>> {fn} Function_Name
>>>>> {vt} Variable_Type
>>>>> {vn} Variable_Name
>>>>> {fh} Function_Header
>>>>>
>>>>> // DFA Definition to recognize C function headers
>>>>>
>>>>> // begin of function type
>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>
>>>>> // begin of function name
>>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>>
>>>>> // begin of variable type
>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>>
>>>>> // begin of variable name
>>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>>
>>>>> // ignores all "//" comments
>>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>>
>>>>
>>>> Ok,
>>>>
>>>> Just remember that being a 'Pure Funciton' isn't the actual
>>>> requirement, the decider needs to be a Mathematical Computation,
>>>> which means that all copies of it, when given the same inputs,
>>>> generates the same outputs.
>>>>
>>>> You STILL have the error that you treat H as a 'pure simulator' when
>>>> it is not, it is only a 'pure simulatior until' and as such, the
>>>> behavior of the copy of H in H^ DOES have an affect on the behavior
>>>> of that H^. Remember, a 'Pure Simulator' (aka a UTM) NEVER stops
>>>> simulating until the machine it is simulating ends, even if that
>>>> takes forever.
>>>>
>>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> _Infinite_Loop()
>>> [00000ab0](01)  55              push ebp
>>> [00000ab1](02)  8bec            mov ebp,esp
>>> [00000ab3](02)  ebfe            jmp 00000ab3
>>> [00000ab5](01)  5d              pop ebp
>>> [00000ab6](01)  c3              ret
>>> Size in bytes:(0007) [00000ab6]
>>>
>>> Are you saying that the only way that a simulating halt decider can
>>> correctly decide that the above code will never stop running is to
>>> wait until the end of time?
>>>
>>
>> No. You seem to have a reading comprension problem.
>>
>> The Simulating Halt Decider is fully allowed to abort the simulation
>> of the machine it is simulationg.
>>
>> The only issue is that IF it does so, it can't treat itself as if it
>> was a UTM/Pure SImulator, and thus the fact that it never saw the
>> comptation reach a halting state isn't proof of anything.
>
> When a simulating halt decider acts as if it is a pure simulator and
> watches the behavior of an infinite loop it can correctly abort the
> simulation of this input and report that this input never halts. We can
> generalize this simplest case of infinite execution to all other cases:
>
> All that I am doing is generalizing this same idea. When-so-ever a
> simulating halt decider can correctly axiomatically determine that its
> input would never halt if it remained a pure simulator then it can abort
> the simulation of this input and report that this input never halts.
>
> When a simulating halt decider correctly axiomatically determines X then
> we know that X is necessarily true.
>
>

NO!

You are making an INCORRECT generalization. It is just like claiming
that log(a+b+c) is log(a) + log(b) + log(c) because we have the case
that log(1+2+3) = log(1) + log(2) + log(3).

You have made a claim, PROVE IT. Not just a rhetorical argument done
with vague words, but an honest to god actual analytical proof, using
the exact same accepted definitions of all the words. And then go and
prove that setup does meet the conditions required by the proof to use it.

You say 'axiomatically', but that is just YOUR DISHONEST DOGDE to insert
in a statement that is FALSE.

Now, part of the problem is that you make a number of small errors that
you continue to just ignore and these build up to your false conclusion.

Your statement would be correct if pronoun usage was correct and the
usage refered to just this one COPY being adjusted, and not the shared
copy being changed, which causes the change to change the supposed to be
fixed algorithm employed by the input being simulated. We know that for
THAT case, H is incorrect, as using an ACTUAL 'Pure Simulator' to
process this input (where H^ still uses the original H that does abort)
shows that H^ WILL HALT, and thus the claim "would not halt unless H
aborts the simulation" is incorrect.

These errors have been pointed out to you repeatedly, but you continue
to ignore them. Initially this could have just been passed off as
carelessness, but your continuing shows that it can't just be that, but
must be either stupidity, mental illness, or just that you are a liar.

On 10/23/21 9:27 PM, olcott wrote:
> In order to make my halt decider a pure function it had to have a way to
> look at the inputs to function calls. In order to look at the inputs to
> function calls it had to know how many inputs that a function has.
>
> This is DFA analyzes C source code to provide the number of parameters
> of each function in the file. The number of parameters per function is
> the number of {vt} matches per {fn} match.
>
> The only thing that will change with this file is that the halt decider
> will use different halt deciding criteria so that the halt decider
> becomes a pure function.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> In computer programming, a pure function is a function that has the
> following properties:[1][2]
>
> (1) The function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams).
>
> (2) The function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> https://en.wikipedia.org/wiki/Pure_function
>
>
>
> //
> //  Deterministic Finite Automaton (DFA) recognizer
> //  of C function headers.
>
> // Character Classes
> //
>     EMPTY [0]
>     ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>   NUMERIC [0123456789]
>        WS [0x09,0x0A,0x0D,0x20]
>    LPAREN [(]
>    RPAREN [)]
>  ASTERISK [*]
>     COMMA [,]
>   COMMENT [0x2f]
>   NEWLINE [0x0A]
>     ASCII [0x20-0x7e]
>   CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>
>
> // Recognized Patterns
> //
> {et} Empty
> {ft} Function_Type
> {fn} Function_Name
> {vt} Variable_Type
> {vn} Variable_Name
> {fh} Function_Header
>
> // DFA Definition to recognize C function headers
>
> // begin of function type
> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>
> // begin of function name
> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>
> // begin of variable type
> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>
> // begin of variable name
> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>
> // ignores all "//" comments
> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>

One thing that I just thought of, this routine that you are using is
going to need the SOURCE code of the machine. Is your decieer now going
to take the full source code of the machine as the input instead of the
compiled object file? Does that mean your decider now includes a full
compiler as part of it?

On 10/24/2021 5:40 AM, Richard Damon wrote:
> On 10/23/21 11:29 PM, olcott wrote:
>> On 10/23/2021 10:19 PM, Richard Damon wrote:
>>> On 10/23/21 10:16 PM, olcott wrote:
>>>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>>>
>>>>> On 10/23/21 9:27 PM, olcott wrote:
>>>>>> In order to make my halt decider a pure function it had to have a
>>>>>> way to look at the inputs to function calls. In order to look at
>>>>>> the inputs to function calls it had to know how many inputs that a
>>>>>> function has.
>>>>>>
>>>>>> This is DFA analyzes C source code to provide the number of
>>>>>> parameters of each function in the file. The number of parameters
>>>>>> per function is the number of {vt} matches per {fn} match.
>>>>>>
>>>>>> The only thing that will change with this file is that the halt
>>>>>> decider will use different halt deciding criteria so that the halt
>>>>>> decider becomes a pure function.
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>> In computer programming, a pure function is a function that has
>>>>>> the following properties:[1][2]
>>>>>>
>>>>>> (1) The function return values are identical for identical
>>>>>> arguments (no variation with local static variables, non-local
>>>>>> variables, mutable reference arguments or input streams).
>>>>>>
>>>>>> (2) The function application has no side effects (no mutation of
>>>>>> local static variables, non-local variables, mutable reference
>>>>>> arguments or input/output streams).
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>
>>>>>>
>>>>>>
>>>>>> //
>>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>>> //  of C function headers.
>>>>>>
>>>>>> // Character Classes
>>>>>> //
>>>>>>      EMPTY [0]
>>>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>    NUMERIC [0123456789]
>>>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>>>     LPAREN [(]
>>>>>>     RPAREN [)]
>>>>>>   ASTERISK [*]
>>>>>>      COMMA [,]
>>>>>>    COMMENT [0x2f]
>>>>>>    NEWLINE [0x0A]
>>>>>>      ASCII [0x20-0x7e]
>>>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>
>>>>>>
>>>>>> // Recognized Patterns
>>>>>> //
>>>>>> {et} Empty
>>>>>> {ft} Function_Type
>>>>>> {fn} Function_Name
>>>>>> {vt} Variable_Type
>>>>>> {vn} Variable_Name
>>>>>> {fh} Function_Header
>>>>>>
>>>>>> // DFA Definition to recognize C function headers
>>>>>>
>>>>>> // begin of function type
>>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>>
>>>>>> // begin of function name
>>>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>>>
>>>>>> // begin of variable type
>>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>>>
>>>>>> // begin of variable name
>>>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>>>
>>>>>> // ignores all "//" comments
>>>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>>>
>>>>>
>>>>> Ok,
>>>>>
>>>>> Just remember that being a 'Pure Funciton' isn't the actual
>>>>> requirement, the decider needs to be a Mathematical Computation,
>>>>> which means that all copies of it, when given the same inputs,
>>>>> generates the same outputs.
>>>>>
>>>>> You STILL have the error that you treat H as a 'pure simulator'
>>>>> when it is not, it is only a 'pure simulatior until' and as such,
>>>>> the behavior of the copy of H in H^ DOES have an affect on the
>>>>> behavior of that H^. Remember, a 'Pure Simulator' (aka a UTM) NEVER
>>>>> stops simulating until the machine it is simulating ends, even if
>>>>> that takes forever.
>>>>>
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>>    HERE: goto HERE;
>>>> }
>>>>
>>>> _Infinite_Loop()
>>>> [00000ab0](01)  55              push ebp
>>>> [00000ab1](02)  8bec            mov ebp,esp
>>>> [00000ab3](02)  ebfe            jmp 00000ab3
>>>> [00000ab5](01)  5d              pop ebp
>>>> [00000ab6](01)  c3              ret
>>>> Size in bytes:(0007) [00000ab6]
>>>>
>>>> Are you saying that the only way that a simulating halt decider can
>>>> correctly decide that the above code will never stop running is to
>>>> wait until the end of time?
>>>>
>>>
>>> No. You seem to have a reading comprension problem.
>>>
>>> The Simulating Halt Decider is fully allowed to abort the simulation
>>> of the machine it is simulationg.
>>>
>>> The only issue is that IF it does so, it can't treat itself as if it
>>> was a UTM/Pure SImulator, and thus the fact that it never saw the
>>> comptation reach a halting state isn't proof of anything.
>>
>> When a simulating halt decider acts as if it is a pure simulator and
>> watches the behavior of an infinite loop it can correctly abort the
>> simulation of this input and report that this input never halts. We
>> can generalize this simplest case of infinite execution to all other
>> cases:
>>
>> All that I am doing is generalizing this same idea. When-so-ever a
>> simulating halt decider can correctly axiomatically determine that its
>> input would never halt if it remained a pure simulator then it can
>> abort the simulation of this input and report that this input never
>> halts.
>>
>> When a simulating halt decider correctly axiomatically determines X
>> then we know that X is necessarily true.
>>
>>
>
> NO!
>
> You are making an INCORRECT generalization.

When-so-ever X is correct about Y then X is not incorrect about Y is
always true.

> t is just like claiming
> that log(a+b+c) is log(a) + log(b) + log(c) because we have the case
> that log(1+2+3) = log(1) + log(2) + log(3).
>
> You have made a claim, PROVE IT. Not just a rhetorical argument done
> with vague words, but an honest to god actual analytical proof, using
> the exact same accepted definitions of all the words. And then go and
> prove that setup does meet the conditions required by the proof to use it.
>
> You say 'axiomatically', but that is just YOUR DISHONEST DOGDE to insert
> in a statement that is FALSE.
>
> Now, part of the problem is that you make a number of small errors that
> you continue to just ignore and these build up to your false conclusion.
>
> Your statement would be correct if pronoun usage was correct and the
> usage refered to just this one COPY being adjusted, and not the shared
> copy being changed, which causes the change to change the supposed to be
> fixed algorithm employed by the input being simulated. We know that for
> THAT case, H is incorrect, as using an ACTUAL 'Pure Simulator' to
> process this input (where H^ still uses the original H that does abort)
> shows that H^ WILL HALT, and thus the claim "would not halt unless H
> aborts the simulation" is incorrect.
>

On 10/24/2021 6:59 AM, Richard Damon wrote:
> On 10/23/21 9:27 PM, olcott wrote:
>> In order to make my halt decider a pure function it had to have a way
>> to look at the inputs to function calls. In order to look at the
>> inputs to function calls it had to know how many inputs that a
>> function has.
>>
>> This is DFA analyzes C source code to provide the number of parameters
>> of each function in the file. The number of parameters per function is
>> the number of {vt} matches per {fn} match.
>>
>> The only thing that will change with this file is that the halt
>> decider will use different halt deciding criteria so that the halt
>> decider becomes a pure function.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> In computer programming, a pure function is a function that has the
>> following properties:[1][2]
>>
>> (1) The function return values are identical for identical arguments
>> (no variation with local static variables, non-local variables,
>> mutable reference arguments or input streams).
>>
>> (2) The function application has no side effects (no mutation of local
>> static variables, non-local variables, mutable reference arguments or
>> input/output streams).
>>
>> https://en.wikipedia.org/wiki/Pure_function
>>
>>
>>
>> //
>> //  Deterministic Finite Automaton (DFA) recognizer
>> //  of C function headers.
>>
>> // Character Classes
>> //
>>      EMPTY [0]
>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>    NUMERIC [0123456789]
>>         WS [0x09,0x0A,0x0D,0x20]
>>     LPAREN [(]
>>     RPAREN [)]
>>   ASTERISK [*]
>>      COMMA [,]
>>    COMMENT [0x2f]
>>    NEWLINE [0x0A]
>>      ASCII [0x20-0x7e]
>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>
>>
>> // Recognized Patterns
>> //
>> {et} Empty
>> {ft} Function_Type
>> {fn} Function_Name
>> {vt} Variable_Type
>> {vn} Variable_Name
>> {fh} Function_Header
>>
>> // DFA Definition to recognize C function headers
>>
>> // begin of function type
>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>
>> // begin of function name
>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>
>> // begin of variable type
>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>
>> // begin of variable name
>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>
>> // ignores all "//" comments
>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>
>
> One thing that I just thought of, this routine that you are using is
> going to need the SOURCE code of the machine. Is your decieer now going
> to take the full source code of the machine as the input instead of the
> compiled object file? Does that mean your decider now includes a full
> compiler as part of it?

The halt decider is merely provided with a function that tells it the
number of parameters that each function takes.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/24/21 10:04 AM, olcott wrote:
> On 10/24/2021 5:40 AM, Richard Damon wrote:
>> On 10/23/21 11:29 PM, olcott wrote:
>>> On 10/23/2021 10:19 PM, Richard Damon wrote:
>>>> On 10/23/21 10:16 PM, olcott wrote:
>>>>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 10/23/21 9:27 PM, olcott wrote:
>>>>>>> In order to make my halt decider a pure function it had to have a
>>>>>>> way to look at the inputs to function calls. In order to look at
>>>>>>> the inputs to function calls it had to know how many inputs that
>>>>>>> a function has.
>>>>>>>
>>>>>>> This is DFA analyzes C source code to provide the number of
>>>>>>> parameters of each function in the file. The number of parameters
>>>>>>> per function is the number of {vt} matches per {fn} match.
>>>>>>>
>>>>>>> The only thing that will change with this file is that the halt
>>>>>>> decider will use different halt deciding criteria so that the
>>>>>>> halt decider becomes a pure function.
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>> In computer programming, a pure function is a function that has
>>>>>>> the following properties:[1][2]
>>>>>>>
>>>>>>> (1) The function return values are identical for identical
>>>>>>> arguments (no variation with local static variables, non-local
>>>>>>> variables, mutable reference arguments or input streams).
>>>>>>>
>>>>>>> (2) The function application has no side effects (no mutation of
>>>>>>> local static variables, non-local variables, mutable reference
>>>>>>> arguments or input/output streams).
>>>>>>>
>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> //
>>>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>>>> //  of C function headers.
>>>>>>>
>>>>>>> // Character Classes
>>>>>>> //
>>>>>>>      EMPTY [0]
>>>>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>    NUMERIC [0123456789]
>>>>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>>>>     LPAREN [(]
>>>>>>>     RPAREN [)]
>>>>>>>   ASTERISK [*]
>>>>>>>      COMMA [,]
>>>>>>>    COMMENT [0x2f]
>>>>>>>    NEWLINE [0x0A]
>>>>>>>      ASCII [0x20-0x7e]
>>>>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>
>>>>>>>
>>>>>>> // Recognized Patterns
>>>>>>> //
>>>>>>> {et} Empty
>>>>>>> {ft} Function_Type
>>>>>>> {fn} Function_Name
>>>>>>> {vt} Variable_Type
>>>>>>> {vn} Variable_Name
>>>>>>> {fh} Function_Header
>>>>>>>
>>>>>>> // DFA Definition to recognize C function headers
>>>>>>>
>>>>>>> // begin of function type
>>>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>>>
>>>>>>> // begin of function name
>>>>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>>>>
>>>>>>> // begin of variable type
>>>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>>>>
>>>>>>> // begin of variable name
>>>>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>>>>
>>>>>>> // ignores all "//" comments
>>>>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>>>>
>>>>>>
>>>>>> Ok,
>>>>>>
>>>>>> Just remember that being a 'Pure Funciton' isn't the actual
>>>>>> requirement, the decider needs to be a Mathematical Computation,
>>>>>> which means that all copies of it, when given the same inputs,
>>>>>> generates the same outputs.
>>>>>>
>>>>>> You STILL have the error that you treat H as a 'pure simulator'
>>>>>> when it is not, it is only a 'pure simulatior until' and as such,
>>>>>> the behavior of the copy of H in H^ DOES have an affect on the
>>>>>> behavior of that H^. Remember, a 'Pure Simulator' (aka a UTM)
>>>>>> NEVER stops simulating until the machine it is simulating ends,
>>>>>> even if that takes forever.
>>>>>>
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>>    HERE: goto HERE;
>>>>> }
>>>>>
>>>>> _Infinite_Loop()
>>>>> [00000ab0](01)  55              push ebp
>>>>> [00000ab1](02)  8bec            mov ebp,esp
>>>>> [00000ab3](02)  ebfe            jmp 00000ab3
>>>>> [00000ab5](01)  5d              pop ebp
>>>>> [00000ab6](01)  c3              ret
>>>>> Size in bytes:(0007) [00000ab6]
>>>>>
>>>>> Are you saying that the only way that a simulating halt decider can
>>>>> correctly decide that the above code will never stop running is to
>>>>> wait until the end of time?
>>>>>
>>>>
>>>> No. You seem to have a reading comprension problem.
>>>>
>>>> The Simulating Halt Decider is fully allowed to abort the simulation
>>>> of the machine it is simulationg.
>>>>
>>>> The only issue is that IF it does so, it can't treat itself as if it
>>>> was a UTM/Pure SImulator, and thus the fact that it never saw the
>>>> comptation reach a halting state isn't proof of anything.
>>>
>>> When a simulating halt decider acts as if it is a pure simulator and
>>> watches the behavior of an infinite loop it can correctly abort the
>>> simulation of this input and report that this input never halts. We
>>> can generalize this simplest case of infinite execution to all other
>>> cases:
>>>
>>> All that I am doing is generalizing this same idea. When-so-ever a
>>> simulating halt decider can correctly axiomatically determine that
>>> its input would never halt if it remained a pure simulator then it
>>> can abort the simulation of this input and report that this input
>>> never halts.
>>>
>>> When a simulating halt decider correctly axiomatically determines X
>>> then we know that X is necessarily true.
>>>
>>>
>>
>> NO!
>>
>> You are making an INCORRECT generalization.
>
> When-so-ever X is correct about Y then X is not incorrect about Y is
> always true.

And if X is not correct about all Y then X is not correct for all Y.

On 10/24/21 10:07 AM, olcott wrote:
> On 10/24/2021 6:59 AM, Richard Damon wrote:
>> On 10/23/21 9:27 PM, olcott wrote:
>>> In order to make my halt decider a pure function it had to have a way
>>> to look at the inputs to function calls. In order to look at the
>>> inputs to function calls it had to know how many inputs that a
>>> function has.
>>>
>>> This is DFA analyzes C source code to provide the number of
>>> parameters of each function in the file. The number of parameters per
>>> function is the number of {vt} matches per {fn} match.
>>>
>>> The only thing that will change with this file is that the halt
>>> decider will use different halt deciding criteria so that the halt
>>> decider becomes a pure function.
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>> In computer programming, a pure function is a function that has the
>>> following properties:[1][2]
>>>
>>> (1) The function return values are identical for identical arguments
>>> (no variation with local static variables, non-local variables,
>>> mutable reference arguments or input streams).
>>>
>>> (2) The function application has no side effects (no mutation of
>>> local static variables, non-local variables, mutable reference
>>> arguments or input/output streams).
>>>
>>> https://en.wikipedia.org/wiki/Pure_function
>>>
>>>
>>>
>>> //
>>> //  Deterministic Finite Automaton (DFA) recognizer
>>> //  of C function headers.
>>>
>>> // Character Classes
>>> //
>>>      EMPTY [0]
>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>    NUMERIC [0123456789]
>>>         WS [0x09,0x0A,0x0D,0x20]
>>>     LPAREN [(]
>>>     RPAREN [)]
>>>   ASTERISK [*]
>>>      COMMA [,]
>>>    COMMENT [0x2f]
>>>    NEWLINE [0x0A]
>>>      ASCII [0x20-0x7e]
>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>
>>>
>>> // Recognized Patterns
>>> //
>>> {et} Empty
>>> {ft} Function_Type
>>> {fn} Function_Name
>>> {vt} Variable_Type
>>> {vn} Variable_Name
>>> {fh} Function_Header
>>>
>>> // DFA Definition to recognize C function headers
>>>
>>> // begin of function type
>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>
>>> // begin of function name
>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>
>>> // begin of variable type
>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>
>>> // begin of variable name
>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>
>>> // ignores all "//" comments
>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>
>>
>> One thing that I just thought of, this routine that you are using is
>> going to need the SOURCE code of the machine. Is your decieer now
>> going to take the full source code of the machine as the input instead
>> of the compiled object file? Does that mean your decider now includes
>> a full compiler as part of it?
>
> The halt decider is merely provided with a function that tells it the
> number of parameters that each function takes.
>

And if the input to the decider is an executable file, where does it get
this source code to send to the function?

Or, does your halt decider now have some other input besides the
encoding of the machine and its input to decide on, and thus isn't
anything like the halt decider of the Halting Problem?

On 10/23/2021 8:27 PM, olcott wrote:
> In order to make my halt decider a pure function it had to have a way to
> look at the inputs to function calls. In order to look at the inputs to
> function calls it had to know how many inputs that a function has.
>
> This is DFA analyzes C source code to provide the number of parameters
> of each function in the file. The number of parameters per function is
> the number of {vt} matches per {fn} match.
>
> The only thing that will change with this file is that the halt decider
> will use different halt deciding criteria so that the halt decider
> becomes a pure function.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> In computer programming, a pure function is a function that has the
> following properties:[1][2]
>
> (1) The function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams).
>
> (2) The function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> https://en.wikipedia.org/wiki/Pure_function
>
>
Enhancements: (Assumes that the C source code compiles)
(a) Ignores /* */ comments
(b) Ignores #define lines
(c) Correctly handles trailing space in: int Function_Name(void )

//
// Deterministic Finite Automaton (DFA) recognizer
// of C function headers.

// Character Classes
//
EMPTY [0]
ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
NUMERIC [0123456789]
WS [0x09,0x0A,0x0D,0x20]
LPAREN [(]
RPAREN [)]
POUND [#]
ASTERISK [*] // 0x2a
COMMA [,]

SLASH [0x2f] // "/"
NEWLINE [0x0A]
ASCII [0x20-0x7e]
ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
CONTROL [0x00-0x09,0x0b-0x1f,0x7f]

// Recognized Patterns
//
{et} Empty
{ft} Function_Type
{fn} Function_Name
{vt} Variable_Type
{vn} Variable_Name
{fh} Function_Header

// DFA Definition to recognize C function headers

// begin of function type
<00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
<01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
<02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)

// begin of function name
<03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
<04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
<05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)

// begin of variable type
<06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
<07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
<08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)

// begin of variable name
<09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
<10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
<11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)

// ignores all "//" comments
<12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
<13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)

// look for comment terminator "*/"
<14> ASCII_MINUS_ASTERISK(14) [*](15)
<15> ASCII_MINUS_SLASH(14) [/](00)

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/24/21 2:37 PM, olcott wrote:
> On 10/23/2021 8:27 PM, olcott wrote:
>> In order to make my halt decider a pure function it had to have a way
>> to look at the inputs to function calls. In order to look at the
>> inputs to function calls it had to know how many inputs that a
>> function has.
>>
>> This is DFA analyzes C source code to provide the number of parameters
>> of each function in the file. The number of parameters per function is
>> the number of {vt} matches per {fn} match.
>>
>> The only thing that will change with this file is that the halt
>> decider will use different halt deciding criteria so that the halt
>> decider becomes a pure function.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> In computer programming, a pure function is a function that has the
>> following properties:[1][2]
>>
>> (1) The function return values are identical for identical arguments
>> (no variation with local static variables, non-local variables,
>> mutable reference arguments or input streams).
>>
>> (2) The function application has no side effects (no mutation of local
>> static variables, non-local variables, mutable reference arguments or
>> input/output streams).
>>
>> https://en.wikipedia.org/wiki/Pure_function
>>
>>
> Enhancements: (Assumes that the C source code compiles)
> (a) Ignores /* */ comments
> (b) Ignores #define lines
> (c) Correctly handles trailing space in: int Function_Name(void   )
>
> //
> //  Deterministic Finite Automaton (DFA) recognizer
> //  of C function headers.
>
> // Character Classes
> //
>     EMPTY [0]
>     ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>   NUMERIC [0123456789]
>        WS [0x09,0x0A,0x0D,0x20]
>    LPAREN [(]
>    RPAREN [)]
>     POUND [#]
>  ASTERISK [*]     // 0x2a
>     COMMA [,]
>
>     SLASH [0x2f]  // "/"
>   NEWLINE [0x0A]
>     ASCII [0x20-0x7e]
>      ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>     ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>        ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>   CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>
> // Recognized Patterns
> //
> {et} Empty
> {ft} Function_Type
> {fn} Function_Name
> {vt} Variable_Type
> {vn} Variable_Name
> {fh} Function_Header
>
> // DFA Definition to recognize C function headers
>
> // begin of function type
> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>
> // begin of function name
> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>
> // begin of variable type
> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>
> // begin of variable name
> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00) [)]{fh}(00)
> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>
> // ignores all "//" comments
> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](14) [/](13)
> <13> ASCII_MINUS_NEWLINE(13)  [0x0A] (00)
>
> // look for comment terminator "*/"
> <14> ASCII_MINUS_ASTERISK(14) [*](15)
> <15>    ASCII_MINUS_SLASH(14) [/](00)
>
>
>

And again my question, what good is this if the halt decider is getting
the compiled version of the code as its input?

If H doesn't have the source code, it can't give what it doesn't have to
the DFA to get the data it wants.

Or, does the Halt Decider now get the source code and is compiling it
before running it?

olcott <NoOne@NoWhere.com> writes:

> Enhancements: (Assumes that the C source code compiles)
> (a) Ignores /* */ comments
> (b) Ignores #define lines
> (c) Correctly handles trailing space in: int Function_Name(void )
>
> //
> // Deterministic Finite Automaton (DFA) recognizer
> // of C function headers.
>
> // Character Classes
> //
> EMPTY [0]
> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
> NUMERIC [0123456789]
> WS [0x09,0x0A,0x0D,0x20]
> LPAREN [(]
> RPAREN [)]
> POUND [#]
> ASTERISK [*] // 0x2a
> COMMA [,]
> SLASH [0x2f] // "/"
> NEWLINE [0x0A]

Why don't you use these last seven?

> ASCII [0x20-0x7e]
> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>
> // Recognized Patterns
> //
> {et} Empty
> {ft} Function_Type
> {fn} Function_Name
> {vt} Variable_Type
> {vn} Variable_Name
> {fh} Function_Header
>
> // DFA Definition to recognize C function headers

No DFA can do that in general. You mean "recognise a very restricted
subset of C function headers".

> // begin of function type
> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)

What does that [*] mean? Judging by the other uses of []s, you seem to
be accepting *s and digits at the start of a C function header even
though they won't be taken to be one of your named matches. Why single
out *s and digits?

> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>
> // begin of function name
> <03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
> <05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)
>
> // begin of variable type
> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)

And all these uses of [*] are very odd. It seems that after seeing this
string:

*1*x x(*x x()

your DFA returns to state 0 having seen an {fh}. Is that right? Maybe
I've misunderstood the notation.

> // begin of variable name
> <09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
> <11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)
>
> // ignores all "//" comments
> <12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)
>
> // look for comment terminator "*/"
> <14> ASCII_MINUS_ASTERISK(14) [*](15)
> <15> ASCII_MINUS_SLASH(14) [/](00)

--
Ben.

On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Enhancements: (Assumes that the C source code compiles)
>> (a) Ignores /* */ comments
>> (b) Ignores #define lines
>> (c) Correctly handles trailing space in: int Function_Name(void )
>>
>> //
>> // Deterministic Finite Automaton (DFA) recognizer
>> // of C function headers.
>>
>> // Character Classes
>> //
>> EMPTY [0]
>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>> NUMERIC [0123456789]
>> WS [0x09,0x0A,0x0D,0x20]
>> LPAREN [(]
>> RPAREN [)]
>> POUND [#]
>> ASTERISK [*] // 0x2a
>> COMMA [,]
>> SLASH [0x2f] // "/"
>> NEWLINE [0x0A]
>
> Why don't you use these last seven?
>

I do use them.
I can refer to either the name or the definition of the character class.
ASCII and CONTROL may be used in the future.

>> ASCII [0x20-0x7e]
>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>
>> // Recognized Patterns
>> //
>> {et} Empty
>> {ft} Function_Type
>> {fn} Function_Name
>> {vt} Variable_Type
>> {vn} Variable_Name
>> {fh} Function_Header
>>
>> // DFA Definition to recognize C function headers
>
> No DFA can do that in general. You mean "recognise a very restricted
> subset of C function headers".
>

It recognizes everything that I will ever write.

>> // begin of function type
>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>
> What does that [*] mean? Judging by the other uses of []s, you seem to
> be accepting *s and digits at the start of a C function header even
> though they won't be taken to be one of your named matches. Why single
> out *s and digits?
>

int* M(int* N);

>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>
>> // begin of function name
>> <03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>> <05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)
>>
>> // begin of variable type
>> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>
> And all these uses of [*] are very odd. It seems that after seeing this
> string:
>
> *1*x x(*x x()
>

The DFA asumes that its input compiles as C, thus will never see that
string.

> your DFA returns to state 0 having seen an {fh}. Is that right? Maybe
> I've misunderstood the notation.
>

Yes. In the code that executes the DFA there are semantic actions.
This is the most important semantic action:

bool RecognizedFunctionHeader(u8 OneByte, int State)
{ return (OneByte == ')' &&
(State == 6 || State == 7 ||
State == 9 || State == 10 || State == 11));
}

>> // begin of variable name
>> <09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>> <11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)
>>
>> // ignores all "//" comments
>> <12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
>> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)
>>
>> // look for comment terminator "*/"
>> <14> ASCII_MINUS_ASTERISK(14) [*](15)
>> <15> ASCII_MINUS_SLASH(14) [/](00)
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/24/2021 12:37 PM, Richard Damon wrote:
> On 10/24/21 10:04 AM, olcott wrote:
>> On 10/24/2021 5:40 AM, Richard Damon wrote:
>>> On 10/23/21 11:29 PM, olcott wrote:
>>>> On 10/23/2021 10:19 PM, Richard Damon wrote:
>>>>> On 10/23/21 10:16 PM, olcott wrote:
>>>>>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 10/23/21 9:27 PM, olcott wrote:
>>>>>>>> In order to make my halt decider a pure function it had to have
>>>>>>>> a way to look at the inputs to function calls. In order to look
>>>>>>>> at the inputs to function calls it had to know how many inputs
>>>>>>>> that a function has.
>>>>>>>>
>>>>>>>> This is DFA analyzes C source code to provide the number of
>>>>>>>> parameters of each function in the file. The number of
>>>>>>>> parameters per function is the number of {vt} matches per {fn}
>>>>>>>> match.
>>>>>>>>
>>>>>>>> The only thing that will change with this file is that the halt
>>>>>>>> decider will use different halt deciding criteria so that the
>>>>>>>> halt decider becomes a pure function.
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>> In computer programming, a pure function is a function that has
>>>>>>>> the following properties:[1][2]
>>>>>>>>
>>>>>>>> (1) The function return values are identical for identical
>>>>>>>> arguments (no variation with local static variables, non-local
>>>>>>>> variables, mutable reference arguments or input streams).
>>>>>>>>
>>>>>>>> (2) The function application has no side effects (no mutation of
>>>>>>>> local static variables, non-local variables, mutable reference
>>>>>>>> arguments or input/output streams).
>>>>>>>>
>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> //
>>>>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>>>>> //  of C function headers.
>>>>>>>>
>>>>>>>> // Character Classes
>>>>>>>> //
>>>>>>>>      EMPTY [0]
>>>>>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>>    NUMERIC [0123456789]
>>>>>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>>>>>     LPAREN [(]
>>>>>>>>     RPAREN [)]
>>>>>>>>   ASTERISK [*]
>>>>>>>>      COMMA [,]
>>>>>>>>    COMMENT [0x2f]
>>>>>>>>    NEWLINE [0x0A]
>>>>>>>>      ASCII [0x20-0x7e]
>>>>>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>>
>>>>>>>>
>>>>>>>> // Recognized Patterns
>>>>>>>> //
>>>>>>>> {et} Empty
>>>>>>>> {ft} Function_Type
>>>>>>>> {fn} Function_Name
>>>>>>>> {vt} Variable_Type
>>>>>>>> {vn} Variable_Name
>>>>>>>> {fh} Function_Header
>>>>>>>>
>>>>>>>> // DFA Definition to recognize C function headers
>>>>>>>>
>>>>>>>> // begin of function type
>>>>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>>>>
>>>>>>>> // begin of function name
>>>>>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>>>>>
>>>>>>>> // begin of variable type
>>>>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>>>>>
>>>>>>>> // begin of variable name
>>>>>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>>>>>
>>>>>>>> // ignores all "//" comments
>>>>>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>>>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>>>>>
>>>>>>>
>>>>>>> Ok,
>>>>>>>
>>>>>>> Just remember that being a 'Pure Funciton' isn't the actual
>>>>>>> requirement, the decider needs to be a Mathematical Computation,
>>>>>>> which means that all copies of it, when given the same inputs,
>>>>>>> generates the same outputs.
>>>>>>>
>>>>>>> You STILL have the error that you treat H as a 'pure simulator'
>>>>>>> when it is not, it is only a 'pure simulatior until' and as such,
>>>>>>> the behavior of the copy of H in H^ DOES have an affect on the
>>>>>>> behavior of that H^. Remember, a 'Pure Simulator' (aka a UTM)
>>>>>>> NEVER stops simulating until the machine it is simulating ends,
>>>>>>> even if that takes forever.
>>>>>>>
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>>    HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00000ab0](01)  55              push ebp
>>>>>> [00000ab1](02)  8bec            mov ebp,esp
>>>>>> [00000ab3](02)  ebfe            jmp 00000ab3
>>>>>> [00000ab5](01)  5d              pop ebp
>>>>>> [00000ab6](01)  c3              ret
>>>>>> Size in bytes:(0007) [00000ab6]
>>>>>>
>>>>>> Are you saying that the only way that a simulating halt decider
>>>>>> can correctly decide that the above code will never stop running
>>>>>> is to wait until the end of time?
>>>>>>
>>>>>
>>>>> No. You seem to have a reading comprension problem.
>>>>>
>>>>> The Simulating Halt Decider is fully allowed to abort the
>>>>> simulation of the machine it is simulationg.
>>>>>
>>>>> The only issue is that IF it does so, it can't treat itself as if
>>>>> it was a UTM/Pure SImulator, and thus the fact that it never saw
>>>>> the comptation reach a halting state isn't proof of anything.
>>>>
>>>> When a simulating halt decider acts as if it is a pure simulator and
>>>> watches the behavior of an infinite loop it can correctly abort the
>>>> simulation of this input and report that this input never halts. We
>>>> can generalize this simplest case of infinite execution to all other
>>>> cases:
>>>>
>>>> All that I am doing is generalizing this same idea. When-so-ever a
>>>> simulating halt decider can correctly axiomatically determine that
>>>> its input would never halt if it remained a pure simulator then it
>>>> can abort the simulation of this input and report that this input
>>>> never halts.
>>>>
>>>> When a simulating halt decider correctly axiomatically determines X
>>>> then we know that X is necessarily true.
>>>>
>>>>
>>>
>>> NO!
>>>
>>> You are making an INCORRECT generalization.
>>
>> When-so-ever X is correct about Y then X is not incorrect about Y is
>> always true.
>
> And if X is not correct about all Y then X is not correct for all Y.

olcott <NoOne@NoWhere.com> writes:

> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Enhancements: (Assumes that the C source code compiles)
>>> (a) Ignores /* */ comments
>>> (b) Ignores #define lines
>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>
>>> //
>>> // Deterministic Finite Automaton (DFA) recognizer
>>> // of C function headers.
>>>
>>> // Character Classes
>>> //
>>> EMPTY [0]
>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>> NUMERIC [0123456789]
>>> WS [0x09,0x0A,0x0D,0x20]
>>> LPAREN [(]
>>> RPAREN [)]
>>> POUND [#]
>>> ASTERISK [*] // 0x2a
>>> COMMA [,]
>>> SLASH [0x2f] // "/"
>>> NEWLINE [0x0A]
>>
>> Why don't you use these last seven?
>
> I do use them.

I meant why not use them in the code you posted.

> I can refer to either the name or the definition of the character class.
> ASCII and CONTROL may be used in the future.
>
>>> ASCII [0x20-0x7e]
>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>
>>> // Recognized Patterns
>>> //
>>> {et} Empty
>>> {ft} Function_Type
>>> {fn} Function_Name
>>> {vt} Variable_Type
>>> {vn} Variable_Name
>>> {fh} Function_Header
>>>
>>> // DFA Definition to recognize C function headers
>>
>> No DFA can do that in general. You mean "recognise a very restricted
>> subset of C function headers".
>
> It recognizes everything that I will ever write.

Ah. That simplifies things, and alerts the reader not to check the DFA
since you can just say "I'd never write that!". However...

>>> // begin of function type
>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>
>> What does that [*] mean? Judging by the other uses of []s, you seem to
>> be accepting *s and digits at the start of a C function header even
>> though they won't be taken to be one of your named matches. Why single
>> out *s and digits?
>
> int* M(int* N);

This does not recognise the {fh} pattern. Putting the named
patterns into the string at the point the action would be triggered I
get

int* {ft}M({fn}int* {vt}N){vn}

(The ; does not help -- there is no specified transition for ';' is
state 0.)

Furthermore, this example does not explain why you permit digits. You
say you won't ever write them, but it's odd to permit them where they
are invalid. That "NUMERIC(00)" part looks like "cargo cult"
programming.

Kept for reference:
>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>
>>> // begin of function name
>>> <03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>> <05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)
>>>
>>> // begin of variable type
>>> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)

>>> // begin of variable name
>>> <09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>> <11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)
>>>
>>> // ignores all "//" comments
>>> <12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
>>> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)
>>>
>>> // look for comment terminator "*/"
>>> <14> ASCII_MINUS_ASTERISK(14) [*](15)
>>> <15> ASCII_MINUS_SLASH(14) [/](00)
>>

--
Ben.

On 10/25/21 11:02 AM, olcott wrote:
> On 10/24/2021 12:37 PM, Richard Damon wrote:
>> On 10/24/21 10:04 AM, olcott wrote:
>>> On 10/24/2021 5:40 AM, Richard Damon wrote:
>>>> On 10/23/21 11:29 PM, olcott wrote:
>>>>> On 10/23/2021 10:19 PM, Richard Damon wrote:
>>>>>> On 10/23/21 10:16 PM, olcott wrote:
>>>>>>> On 10/23/2021 8:49 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 10/23/21 9:27 PM, olcott wrote:
>>>>>>>>> In order to make my halt decider a pure function it had to have
>>>>>>>>> a way to look at the inputs to function calls. In order to look
>>>>>>>>> at the inputs to function calls it had to know how many inputs
>>>>>>>>> that a function has.
>>>>>>>>>
>>>>>>>>> This is DFA analyzes C source code to provide the number of
>>>>>>>>> parameters of each function in the file. The number of
>>>>>>>>> parameters per function is the number of {vt} matches per {fn}
>>>>>>>>> match.
>>>>>>>>>
>>>>>>>>> The only thing that will change with this file is that the halt
>>>>>>>>> decider will use different halt deciding criteria so that the
>>>>>>>>> halt decider becomes a pure function.
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In computer programming, a pure function is a function that has
>>>>>>>>> the following properties:[1][2]
>>>>>>>>>
>>>>>>>>> (1) The function return values are identical for identical
>>>>>>>>> arguments (no variation with local static variables, non-local
>>>>>>>>> variables, mutable reference arguments or input streams).
>>>>>>>>>
>>>>>>>>> (2) The function application has no side effects (no mutation
>>>>>>>>> of local static variables, non-local variables, mutable
>>>>>>>>> reference arguments or input/output streams).
>>>>>>>>>
>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> //
>>>>>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>>>>>> //  of C function headers.
>>>>>>>>>
>>>>>>>>> // Character Classes
>>>>>>>>> //
>>>>>>>>>      EMPTY [0]
>>>>>>>>>      ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>>>    NUMERIC [0123456789]
>>>>>>>>>         WS [0x09,0x0A,0x0D,0x20]
>>>>>>>>>     LPAREN [(]
>>>>>>>>>     RPAREN [)]
>>>>>>>>>   ASTERISK [*]
>>>>>>>>>      COMMA [,]
>>>>>>>>>    COMMENT [0x2f]
>>>>>>>>>    NEWLINE [0x0A]
>>>>>>>>>      ASCII [0x20-0x7e]
>>>>>>>>>    CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // Recognized Patterns
>>>>>>>>> //
>>>>>>>>> {et} Empty
>>>>>>>>> {ft} Function_Type
>>>>>>>>> {fn} Function_Name
>>>>>>>>> {vt} Variable_Type
>>>>>>>>> {vn} Variable_Name
>>>>>>>>> {fh} Function_Header
>>>>>>>>>
>>>>>>>>> // DFA Definition to recognize C function headers
>>>>>>>>>
>>>>>>>>> // begin of function type
>>>>>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12)
>>>>>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>>>>>
>>>>>>>>> // begin of function name
>>>>>>>>> <03> WS    (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>>>>>> <05> WS    (05) ALPHA(00) NUMERIC(00) [*](00) [(]    (06)
>>>>>>>>>
>>>>>>>>> // begin of variable type
>>>>>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>>>>>>>>
>>>>>>>>> // begin of variable name
>>>>>>>>> <09> WS    (09) ALPHA(10) NUMERIC(00) [*]    (00)
>>>>>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>>>>>> <11> WS    (11) ALPHA(00) NUMERIC(00) [,]    (06) [)]    (00)
>>>>>>>>>
>>>>>>>>> // ignores all "//" comments
>>>>>>>>> <12> WS     (00) ALPHA(01)  NUMERIC(00) [*](00) [/](13)
>>>>>>>>> <13> CONTROL(13) ASCII(13)  [0x0A] (00)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok,
>>>>>>>>
>>>>>>>> Just remember that being a 'Pure Funciton' isn't the actual
>>>>>>>> requirement, the decider needs to be a Mathematical Computation,
>>>>>>>> which means that all copies of it, when given the same inputs,
>>>>>>>> generates the same outputs.
>>>>>>>>
>>>>>>>> You STILL have the error that you treat H as a 'pure simulator'
>>>>>>>> when it is not, it is only a 'pure simulatior until' and as
>>>>>>>> such, the behavior of the copy of H in H^ DOES have an affect on
>>>>>>>> the behavior of that H^. Remember, a 'Pure Simulator' (aka a
>>>>>>>> UTM) NEVER stops simulating until the machine it is simulating
>>>>>>>> ends, even if that takes forever.
>>>>>>>>
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00000ab0](01)  55              push ebp
>>>>>>> [00000ab1](02)  8bec            mov ebp,esp
>>>>>>> [00000ab3](02)  ebfe            jmp 00000ab3
>>>>>>> [00000ab5](01)  5d              pop ebp
>>>>>>> [00000ab6](01)  c3              ret
>>>>>>> Size in bytes:(0007) [00000ab6]
>>>>>>>
>>>>>>> Are you saying that the only way that a simulating halt decider
>>>>>>> can correctly decide that the above code will never stop running
>>>>>>> is to wait until the end of time?
>>>>>>>
>>>>>>
>>>>>> No. You seem to have a reading comprension problem.
>>>>>>
>>>>>> The Simulating Halt Decider is fully allowed to abort the
>>>>>> simulation of the machine it is simulationg.
>>>>>>
>>>>>> The only issue is that IF it does so, it can't treat itself as if
>>>>>> it was a UTM/Pure SImulator, and thus the fact that it never saw
>>>>>> the comptation reach a halting state isn't proof of anything.
>>>>>
>>>>> When a simulating halt decider acts as if it is a pure simulator
>>>>> and watches the behavior of an infinite loop it can correctly abort
>>>>> the simulation of this input and report that this input never
>>>>> halts. We can generalize this simplest case of infinite execution
>>>>> to all other cases:
>>>>>
>>>>> All that I am doing is generalizing this same idea. When-so-ever a
>>>>> simulating halt decider can correctly axiomatically determine that
>>>>> its input would never halt if it remained a pure simulator then it
>>>>> can abort the simulation of this input and report that this input
>>>>> never halts.
>>>>>
>>>>> When a simulating halt decider correctly axiomatically determines X
>>>>> then we know that X is necessarily true.
>>>>>
>>>>>
>>>>
>>>> NO!
>>>>
>>>> You are making an INCORRECT generalization.
>>>
>>> When-so-ever X is correct about Y then X is not incorrect about Y is
>>> always true.
>>
>> And if X is not correct about all Y then X is not correct for all Y.
>
> Y is a specific unique instance.

On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Enhancements: (Assumes that the C source code compiles)
>>>> (a) Ignores /* */ comments
>>>> (b) Ignores #define lines
>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>
>>>> //
>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>> // of C function headers.
>>>>
>>>> // Character Classes
>>>> //
>>>> EMPTY [0]
>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>> NUMERIC [0123456789]
>>>> WS [0x09,0x0A,0x0D,0x20]
>>>> LPAREN [(]
>>>> RPAREN [)]
>>>> POUND [#]
>>>> ASTERISK [*] // 0x2a
>>>> COMMA [,]
>>>> SLASH [0x2f] // "/"
>>>> NEWLINE [0x0A]
>>>
>>> Why don't you use these last seven?
>>
>> I do use them.
>
> I meant why not use them in the code you posted.

They are used in the DFA shown below.

>
>> I can refer to either the name or the definition of the character class.
>> ASCII and CONTROL may be used in the future.
>>
>>>> ASCII [0x20-0x7e]
>>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>
>>>> // Recognized Patterns
>>>> //
>>>> {et} Empty
>>>> {ft} Function_Type
>>>> {fn} Function_Name
>>>> {vt} Variable_Type
>>>> {vn} Variable_Name
>>>> {fh} Function_Header
>>>>
>>>> // DFA Definition to recognize C function headers
>>>
>>> No DFA can do that in general. You mean "recognise a very restricted
>>> subset of C function headers".
>>
>> It recognizes everything that I will ever write.
>
> Ah. That simplifies things, and alerts the reader not to check the DFA
> since you can just say "I'd never write that!". However...
>
If I wanted a more robust function header recognizer I would adapt the
lex/yacc spec for C.

>>>> // begin of function type
>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>
>>> What does that [*] mean? Judging by the other uses of []s, you seem to
>>> be accepting *s and digits at the start of a C function header even
>>> though they won't be taken to be one of your named matches. Why single
>>> out *s and digits?
>>
>> int* M(int* N);
>
> This does not recognise the {fh} pattern. Putting the named
> patterns into the string at the point the action would be triggered I
> get

The above string would be rejected by the C compiler this never reach
the DFA reogonizer.

>
> int* {ft}M({fn}int* {vt}N){vn}
>
> (The ; does not help -- there is no specified transition for ';' is
> state 0.)
>
> Furthermore, this example does not explain why you permit digits.

It recognizes all valid C identifiers.

> You
> say you won't ever write them,

I did not say that I will not write digits.
I said that I don't need a full parser.

> but it's odd to permit them where they
> are invalid. That "NUMERIC(00)" part looks like "cargo cult"
> programming.
>

It was easiest to write this DFA from scratch when I explicitly
accounted for all of the character classes on every line.

This line skips white-space
matches the first char of a valid C identifier
ignores asterisk
matches the first char of a C comment
matches the first char of a C #define statement

>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)

> Kept for reference:
>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>
>>>> // begin of function name
>>>> <03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>> <05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)
>>>>
>>>> // begin of variable type
>>>> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>
>>>> // begin of variable name
>>>> <09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>> <11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)
>>>>
>>>> // ignores all "//" comments
>>>> <12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
>>>> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)
>>>>
>>>> // look for comment terminator "*/"
>>>> <14> ASCII_MINUS_ASTERISK(14) [*](15)
>>>> <15> ASCII_MINUS_SLASH(14) [/](00)
>>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>> (a) Ignores /* */ comments
>>>>> (b) Ignores #define lines
>>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>>
>>>>> //
>>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>>> // of C function headers.
>>>>>
>>>>> // Character Classes
>>>>> //
>>>>> EMPTY [0]
>>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>> NUMERIC [0123456789]
>>>>> WS [0x09,0x0A,0x0D,0x20]
>>>>> LPAREN [(]
>>>>> RPAREN [)]
>>>>> POUND [#]
>>>>> ASTERISK [*] // 0x2a
>>>>> COMMA [,]
>>>>> SLASH [0x2f] // "/"
>>>>> NEWLINE [0x0A]
>>>>
>>>> Why don't you use these last seven?
>>>
>>> I do use them.
>> I meant why not use them in the code you posted.
>
> They are used in the DFA shown below.

No they are not.

>>> I can refer to either the name or the definition of the character class.
>>> ASCII and CONTROL may be used in the future.
>>>
>>>>> ASCII [0x20-0x7e]
>>>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>
>>>>> // Recognized Patterns
>>>>> //
>>>>> {et} Empty
>>>>> {ft} Function_Type
>>>>> {fn} Function_Name
>>>>> {vt} Variable_Type
>>>>> {vn} Variable_Name
>>>>> {fh} Function_Header
>>>>>
>>>>> // DFA Definition to recognize C function headers
>>>>
>>>> No DFA can do that in general. You mean "recognise a very restricted
>>>> subset of C function headers".
>>>
>>> It recognizes everything that I will ever write.
>>
>> Ah. That simplifies things, and alerts the reader not to check the DFA
>> since you can just say "I'd never write that!". However...
>>
> If I wanted a more robust function header recognizer I would adapt the
> lex/yacc spec for C.

Your DFA does not even recognise the one example you gave!

>>>>> // begin of function type
>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>>
>>>> What does that [*] mean? Judging by the other uses of []s, you seem to
>>>> be accepting *s and digits at the start of a C function header even
>>>> though they won't be taken to be one of your named matches. Why single
>>>> out *s and digits?
>>>
>>> int* M(int* N);
>>
>> This does not recognise the {fh} pattern. Putting the named
>> patterns into the string at the point the action would be triggered I
>> get
>
> The above string would be rejected by the C compiler this never reach
> the DFA reogonizer.

Don't be silly, of course it won't be rejected. I thought you knew a
bit about C. But given that you thought it would be rejected, why give
it as an example or the need to handle *s.

Anyway, even "int f(int x)" does not get recognised as a function
header. I thought you knew a bit about DFAs.

>> int* {ft}M({fn}int* {vt}N){vn}
>> (The ; does not help -- there is no specified transition for ';' is
>> state 0.)
>> Furthermore, this example does not explain why you permit digits.
>
> It recognizes all valid C identifiers.

Do you really not understand the DFA you wrote? I am asking why you
single out digits to be accepted in state 0. They form part of
identifiers, but that's not what state 0 is doing. You skip digits,
spaces and *s in a position where digits are meaning less.

>> You
>> say you won't ever write them,
>
> I did not say that I will not write digits.

You said you would not write

*1*x x(*x x()

and I am asking why you accept digits in state 0. Why single them out?
They are never valid in that position, but then there are lots of other
characters you could pointlessly accept in state 0 as well.

> I said that I don't need a full parser.
>
>> but it's odd to permit them where they
>> are invalid. That "NUMERIC(00)" part looks like "cargo cult"
>> programming.
>
> It was easiest to write this DFA from scratch when I explicitly
> accounted for all of the character classes on every line.

Except you don't do that. You account for some of them in most of the
lines.

> This line skips white-space
> matches the first char of a valid C identifier
> ignores asterisk
> matches the first char of a C comment
> matches the first char of a C #define statement
>
>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)

and "ignores" digits for some unexplained reason.

>> Kept for reference:
>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>>>>> <02> WS{ft}(03) ALPHA(00) NUMERIC(00) [*](02)
>>>>>
>>>>> // begin of function name
>>>>> <03> WS (03) ALPHA(04) NUMERIC(00) [*](00)
>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>>>> <05> WS (05) ALPHA(00) NUMERIC(00) [*](00) [(] (06)
>>>>>
>>>>> // begin of variable type
>>>>> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>>>>> <07> WS{vt}(09) ALPHA(07) NUMERIC(07) [*](08) [)]{fh}(00)
>>>>> <08> WS{vt}(09) ALPHA(00) NUMERIC(00) [*](08)
>>
>>>>> // begin of variable name
>>>>> <09> WS (09) ALPHA(10) NUMERIC(00) [*] (00) [)]{fh}(00)
>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>>>>> <11> WS (11) ALPHA(00) NUMERIC(00) [,] (06) [)] (00)
>>>>>
>>>>> // ignores all "//" comments
>>>>> <12> WS (00) ALPHA(01) NUMERIC(00) [*](14) [/](13)
>>>>> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)
>>>>>
>>>>> // look for comment terminator "*/"
>>>>> <14> ASCII_MINUS_ASTERISK(14) [*](15)
>>>>> <15> ASCII_MINUS_SLASH(14) [/](00)

--
Ben.

On 10/25/2021 8:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>>> (a) Ignores /* */ comments
>>>>>> (b) Ignores #define lines
>>>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>>>
>>>>>> //
>>>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>>>> // of C function headers.
>>>>>>
>>>>>> // Character Classes
>>>>>> //
>>>>>> EMPTY [0]
>>>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>> NUMERIC [0123456789]
>>>>>> WS [0x09,0x0A,0x0D,0x20]
>>>>>> LPAREN [(]
>>>>>> RPAREN [)]
>>>>>> POUND [#]
>>>>>> ASTERISK [*] // 0x2a
>>>>>> COMMA [,]
>>>>>> SLASH [0x2f] // "/"
>>>>>> NEWLINE [0x0A]
>>>>>
>>>>> Why don't you use these last seven?
>>>>
>>>> I do use them.
>>> I meant why not use them in the code you posted.
>>
>> They are used in the DFA shown below.
>
> No they are not.

Here is LPAREN: [(]{fn}(06)
>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)

Here is RPAREN: [)]{fh}(00)
>>>>>> <06> WS (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)

Here is POUND: [#](13)
Here is SLASH: [/](12)
>>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)

Here is ASTERISK: [*](02)
>>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)

Here is COMMA: [,]{vn}(06)
>>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)

Here is NEWLINE: [0x0A] (00)
>>>>>> <13> ASCII_MINUS_NEWLINE(13) [0x0A] (00)

>>>> I can refer to either the name or the definition of the character class.
>>>> ASCII and CONTROL may be used in the future.
>>>>
>>>>>> ASCII [0x20-0x7e]
>>>>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>
>>>>>> // Recognized Patterns
>>>>>> //
>>>>>> {et} Empty
>>>>>> {ft} Function_Type
>>>>>> {fn} Function_Name
>>>>>> {vt} Variable_Type
>>>>>> {vn} Variable_Name
>>>>>> {fh} Function_Header
>>>>>>
>>>>>> // DFA Definition to recognize C function headers
>>>>>
>>>>> No DFA can do that in general. You mean "recognise a very restricted
>>>>> subset of C function headers".
>>>>
>>>> It recognizes everything that I will ever write.
>>>
>>> Ah. That simplifies things, and alerts the reader not to check the DFA
>>> since you can just say "I'd never write that!". However...
>>>
>> If I wanted a more robust function header recognizer I would adapt the
>> lex/yacc spec for C.
>
> Your DFA does not even recognise the one example you gave!
>

Why did you delete it? Here is is being correctly recognized:
int* M(int* N);

[i] State(00) NextState(01) LineNumber(0006)
[n] State(01) NextState(01) LineNumber(0006)
[t] State(01) NextState(01) LineNumber(0006)
[*] State(01) NextState(02) LineNumber(0006)
[ ] State(02) {ft} NextState(03) LineNumber(0006)
[M] State(03) NextState(04) LineNumber(0006)
[(] State(04) {fn} NextState(06) LineNumber(0006)
[i] State(06) NextState(07) LineNumber(0006)
[n] State(07) NextState(07) LineNumber(0006)
[t] State(07) NextState(07) LineNumber(0006)
[*] State(07) NextState(08) LineNumber(0006)
[ ] State(08) {vt} NextState(09) LineNumber(0006)
[N] State(09) NextState(10) LineNumber(0006)
[)] State(10) {vn} NextState(00) LineNumber(0006)
insert("M", 1);

>>>>>> // begin of function type
>>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>>>
>>>>> What does that [*] mean? Judging by the other uses of []s, you seem to
>>>>> be accepting *s and digits at the start of a C function header even
>>>>> though they won't be taken to be one of your named matches. Why single
>>>>> out *s and digits?
>>>>
>>>> int* M(int* N);
>>>
>>> This does not recognise the {fh} pattern. Putting the named
>>> patterns into the string at the point the action would be triggered I
>>> get
>>

Your:
*1*x x(*x x()
was rejected by the C compiler.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 10/25/21 9:54 PM, olcott wrote:
> On 10/25/2021 8:09 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>>>> (a) Ignores /* */ comments
>>>>>>> (b) Ignores #define lines
>>>>>>> (c) Correctly handles trailing space in: int Function_Name(void   )
>>>>>>>
>>>>>>> //
>>>>>>> //  Deterministic Finite Automaton (DFA) recognizer
>>>>>>> //  of C function headers.
>>>>>>>
>>>>>>> // Character Classes
>>>>>>> //
>>>>>>>        EMPTY [0]
>>>>>>>        ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>      NUMERIC [0123456789]
>>>>>>>           WS [0x09,0x0A,0x0D,0x20]
>>>>>>>       LPAREN [(]
>>>>>>>       RPAREN [)]
>>>>>>>        POUND [#]
>>>>>>>     ASTERISK [*]     // 0x2a
>>>>>>>        COMMA [,]
>>>>>>>        SLASH [0x2f]  // "/"
>>>>>>>      NEWLINE [0x0A]
>>>>>>
>>>>>> Why don't you use these last seven?
>>>>>
>>>>> I do use them.
>>>> I meant why not use them in the code you posted.
>>>
>>> They are used in the DFA shown below.
>>
>> No they are not.
>
> Here is LPAREN: [(]{fn}(06)
> >>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>
> Here is RPAREN: [)]{fh}(00)
> >>>>>> <06> WS    (06) ALPHA(07) NUMERIC(00) [*](00) [)]{fh}(00)
>
> Here is POUND: [#](13)
> Here is SLASH: [/](12)
> >>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>
> Here is ASTERISK: [*](02)
> >>>>>> <01> WS{ft}(03) ALPHA(01) NUMERIC(01) [*](02)
>
> Here is COMMA:  [,]{vn}(06)
> >>>>>> <10> WS{vn}(11) ALPHA(10) NUMERIC(10) [,]{vn}(06) [)]{vn}(00)
>
> Here is NEWLINE: [0x0A] (00)
> >>>>>> <13> ASCII_MINUS_NEWLINE(13)  [0x0A] (00)

You do understand that NONE of these cases are using the class
definitions you are talking about, just reference the same set of
characters that the class uses.
>
>>>>> I can refer to either the name or the definition of the character
>>>>> class.
>>>>> ASCII and CONTROL may be used in the future.
>>>>>
>>>>>>>        ASCII [0x20-0x7e]
>>>>>>>         ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>>>>>        ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>>>>>           ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>>>>>      CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>
>>>>>>> // Recognized Patterns
>>>>>>> //
>>>>>>> {et} Empty
>>>>>>> {ft} Function_Type
>>>>>>> {fn} Function_Name
>>>>>>> {vt} Variable_Type
>>>>>>> {vn} Variable_Name
>>>>>>> {fh} Function_Header
>>>>>>>
>>>>>>> // DFA Definition to recognize C function headers
>>>>>>
>>>>>> No DFA can do that in general.  You mean "recognise a very restricted
>>>>>> subset of C function headers".
>>>>>
>>>>> It recognizes everything that I will ever write.
>>>>
>>>> Ah.  That simplifies things, and alerts the reader not to check the DFA
>>>> since you can just say "I'd never write that!".  However...
>>>>
>>> If I wanted a more robust function header recognizer I would adapt the
>>> lex/yacc spec for C.
>>
>> Your DFA does not even recognise the one example you gave!
>>
>
> Why did you delete it? Here is is being correctly recognized:
> int* M(int* N);
>
>  [i]  State(00)        NextState(01)  LineNumber(0006)
>  [n]  State(01)        NextState(01)  LineNumber(0006)
>  [t]  State(01)        NextState(01)  LineNumber(0006)
>  [*]  State(01)        NextState(02)  LineNumber(0006)
>  [ ]  State(02)  {ft}  NextState(03)  LineNumber(0006)
>  [M]  State(03)        NextState(04)  LineNumber(0006)
>  [(]  State(04)  {fn}  NextState(06)  LineNumber(0006)
>  [i]  State(06)        NextState(07)  LineNumber(0006)
>  [n]  State(07)        NextState(07)  LineNumber(0006)
>  [t]  State(07)        NextState(07)  LineNumber(0006)
>  [*]  State(07)        NextState(08)  LineNumber(0006)
>  [ ]  State(08)  {vt}  NextState(09)  LineNumber(0006)
>  [N]  State(09)        NextState(10)  LineNumber(0006)
>  [)]  State(10)  {vn}  NextState(00)  LineNumber(0006)
>   insert("M", 1);
>
>
>>>>>>> // begin of function type
>>>>>>> <00> WS    (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>>>>
>>>>>> What does that [*] mean?  Judging by the other uses of []s, you
>>>>>> seem to
>>>>>> be accepting *s and digits at the start of a C function header even
>>>>>> though they won't be taken to be one of your named matches.  Why
>>>>>> single
>>>>>> out *s and digits?
>>>>>
>>>>> int* M(int* N);
>>>>
>>>> This does not recognise the {fh} pattern.  Putting the named
>>>> patterns into the string at the point the action would be triggered I
>>>> get
>>>
>
> Your:
> *1*x x(*x x()
> was rejected by the C compiler.
>

olcott <NoOne@NoWhere.com> writes:

> On 10/25/2021 8:09 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>>>> (a) Ignores /* */ comments
>>>>>>> (b) Ignores #define lines
>>>>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>>>>
>>>>>>> //
>>>>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>>>>> // of C function headers.
>>>>>>>
>>>>>>> // Character Classes
>>>>>>> //
>>>>>>> EMPTY [0]
>>>>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>> NUMERIC [0123456789]
>>>>>>> WS [0x09,0x0A,0x0D,0x20]
>>>>>>> LPAREN [(]
>>>>>>> RPAREN [)]
>>>>>>> POUND [#]
>>>>>>> ASTERISK [*] // 0x2a
>>>>>>> COMMA [,]
>>>>>>> SLASH [0x2f] // "/"
>>>>>>> NEWLINE [0x0A]
>>>>>>
>>>>>> Why don't you use these last seven?
>>>>>
>>>>> I do use them.
>>>>
>>>> I meant why not use them in the code you posted.
>>>
>>> They are used in the DFA shown below.
>>
>> No they are not.
>
> Here is LPAREN: [(]{fn}(06)
>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)

No. That state uses the definitions ALPHA and NUMERIC but it does not
use the definition LPAREN. The point, since I seem t have to spell it
out, is why name the class is you are not going to use the named
versions? It makes the read think you don't know how the notation
works.

>>>>> I can refer to either the name or the definition of the character class.
>>>>> ASCII and CONTROL may be used in the future.
>>>>>
>>>>>>> ASCII [0x20-0x7e]
>>>>>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>>>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>>>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>>>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>
>>>>>>> // Recognized Patterns
>>>>>>> //
>>>>>>> {et} Empty
>>>>>>> {ft} Function_Type
>>>>>>> {fn} Function_Name
>>>>>>> {vt} Variable_Type
>>>>>>> {vn} Variable_Name
>>>>>>> {fh} Function_Header
>>>>>>>
>>>>>>> // DFA Definition to recognize C function headers
>>>>>>
>>>>>> No DFA can do that in general. You mean "recognise a very restricted
>>>>>> subset of C function headers".
>>>>>
>>>>> It recognizes everything that I will ever write.
>>>>
>>>> Ah. That simplifies things, and alerts the reader not to check the DFA
>>>> since you can just say "I'd never write that!". However...
>>>>
>>> If I wanted a more robust function header recognizer I would adapt the
>>> lex/yacc spec for C.
>>
>> Your DFA does not even recognise the one example you gave!
>
> Why did you delete it?

I didn't. It is still quoted in the post you are replying to here and
you have kept in your reply and it is still there in this post.

> Here is is being correctly recognized:
> int* M(int* N);
>
> [i] State(00) NextState(01) LineNumber(0006)
> [n] State(01) NextState(01) LineNumber(0006)
> [t] State(01) NextState(01) LineNumber(0006)
> [*] State(01) NextState(02) LineNumber(0006)
> [ ] State(02) {ft} NextState(03) LineNumber(0006)
> [M] State(03) NextState(04) LineNumber(0006)
> [(] State(04) {fn} NextState(06) LineNumber(0006)
> [i] State(06) NextState(07) LineNumber(0006)
> [n] State(07) NextState(07) LineNumber(0006)
> [t] State(07) NextState(07) LineNumber(0006)
> [*] State(07) NextState(08) LineNumber(0006)
> [ ] State(08) {vt} NextState(09) LineNumber(0006)
> [N] State(09) NextState(10) LineNumber(0006)
> [)] State(10) {vn} NextState(00) LineNumber(0006)
> insert("M", 1);

It is not recognised as matching the {fh} pattern. That's (apparently)
the pattern for a function header. Some things do match the {fh}
pattern. For example "int M(void)".

Now you may have fudged things by making the action associated with the
{vn} action trigger whatever it is you want to with a function header,
but that's a hack. Or maybe you've hacked it to work in some other way,
but some function headers do match the correct named pattern, but most
don't.

>>>>>>> // begin of function type
>>>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>>>>
>>>>>> What does that [*] mean? Judging by the other uses of []s, you seem to
>>>>>> be accepting *s and digits at the start of a C function header even
>>>>>> though they won't be taken to be one of your named matches. Why single
>>>>>> out *s and digits?
>>>>>
>>>>> int* M(int* N);
>>>>
>>>> This does not recognise the {fh} pattern. Putting the named
>>>> patterns into the string at the point the action would be triggered I
>>>> get

This is where you should have show that example not being recognised and
then you would not accused me of deleting the example!

> Your:
> *1*x x(*x x()
> was rejected by the C compiler.

Yes. But right after I complained about your "int* M(int* N);" example
not matching as a header you said

"The above string would be rejected by the C compiler"

which is obviously not the case.

--
Ben.

On 10/26/2021 8:56 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/25/2021 8:09 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>>>>> (a) Ignores /* */ comments
>>>>>>>> (b) Ignores #define lines
>>>>>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>>>>>
>>>>>>>> //
>>>>>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>>>>>> // of C function headers.
>>>>>>>>
>>>>>>>> // Character Classes
>>>>>>>> //
>>>>>>>> EMPTY [0]
>>>>>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>> NUMERIC [0123456789]
>>>>>>>> WS [0x09,0x0A,0x0D,0x20]
>>>>>>>> LPAREN [(]
>>>>>>>> RPAREN [)]
>>>>>>>> POUND [#]
>>>>>>>> ASTERISK [*] // 0x2a
>>>>>>>> COMMA [,]
>>>>>>>> SLASH [0x2f] // "/"
>>>>>>>> NEWLINE [0x0A]
>>>>>>>
>>>>>>> Why don't you use these last seven?
>>>>>>
>>>>>> I do use them.
>>>>>
>>>>> I meant why not use them in the code you posted.
>>>>
>>>> They are used in the DFA shown below.
>>>
>>> No they are not.
>>
>> Here is LPAREN: [(]{fn}(06)
>>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>
> No. That state uses the definitions ALPHA and NUMERIC but it does not
> use the definition LPAREN.

I told you this before yet you did not notice because your entire focus
is on rebuttal with no weight what-so-ever to understand.

A character class can be referred to in the DFA by its name of by its
definition. Because [(] is more concise than LPAREN I used the
definition instead of the name.

> The point, since I seem t have to spell it
> out, is why name the class is you are not going to use the named
> versions? It makes the read think you don't know how the notation
> works.
>
>>>>>> I can refer to either the name or the definition of the character class.
>>>>>> ASCII and CONTROL may be used in the future.
>>>>>>
>>>>>>>> ASCII [0x20-0x7e]
>>>>>>>> ASCII_MINUS_NEWLINE [0x00-0x09,0x0b-0x7f]
>>>>>>>> ASCII_MINUS_ASTERISK [0x00-0x29,0x2b-0x7f]
>>>>>>>> ASCII_MINUS_SLASH [0x00-0x2e,0x30-0x7f]
>>>>>>>> CONTROL [0x00-0x09,0x0b-0x1f,0x7f]
>>>>>>>>
>>>>>>>> // Recognized Patterns
>>>>>>>> //
>>>>>>>> {et} Empty
>>>>>>>> {ft} Function_Type
>>>>>>>> {fn} Function_Name
>>>>>>>> {vt} Variable_Type
>>>>>>>> {vn} Variable_Name
>>>>>>>> {fh} Function_Header
>>>>>>>>
>>>>>>>> // DFA Definition to recognize C function headers
>>>>>>>
>>>>>>> No DFA can do that in general. You mean "recognise a very restricted
>>>>>>> subset of C function headers".
>>>>>>
>>>>>> It recognizes everything that I will ever write.
>>>>>
>>>>> Ah. That simplifies things, and alerts the reader not to check the DFA
>>>>> since you can just say "I'd never write that!". However...
>>>>>
>>>> If I wanted a more robust function header recognizer I would adapt the
>>>> lex/yacc spec for C.
>>>
>>> Your DFA does not even recognise the one example you gave!
>>
>> Why did you delete it?
>
> I didn't. It is still quoted in the post you are replying to here and
> you have kept in your reply and it is still there in this post.
>
>> Here is is being correctly recognized:
>> int* M(int* N);
>>
>> [i] State(00) NextState(01) LineNumber(0006)
>> [n] State(01) NextState(01) LineNumber(0006)
>> [t] State(01) NextState(01) LineNumber(0006)
>> [*] State(01) NextState(02) LineNumber(0006)
>> [ ] State(02) {ft} NextState(03) LineNumber(0006)
>> [M] State(03) NextState(04) LineNumber(0006)
>> [(] State(04) {fn} NextState(06) LineNumber(0006)
>> [i] State(06) NextState(07) LineNumber(0006)
>> [n] State(07) NextState(07) LineNumber(0006)
>> [t] State(07) NextState(07) LineNumber(0006)
>> [*] State(07) NextState(08) LineNumber(0006)
>> [ ] State(08) {vt} NextState(09) LineNumber(0006)
>> [N] State(09) NextState(10) LineNumber(0006)
>> [)] State(10) {vn} NextState(00) LineNumber(0006)
>> insert("M", 1);
>
> It is not recognised as matching the {fh} pattern. That's (apparently)

I already told you this before but because you only want to provide a
rebuttal and don't give a rat's ass about understanding what I say you
missed the explanition.

Because each state can only recognize a single pattern and state (10)
must recognize {vn} I use a separate semantic action to recognize {fh}.

> the pattern for a function header. Some things do match the {fh}
> pattern. For example "int M(void)".
>
> Now you may have fudged things by making the action associated with the
> {vn} action trigger whatever it is you want to with a function header,
> but that's a hack. Or maybe you've hacked it to work in some other way,
> but some function headers do match the correct named pattern, but most
> don't.
>
>>>>>>>> // begin of function type
>>>>>>>> <00> WS (00) ALPHA(01) NUMERIC(00) [*](00) [/](12) [#](13)
>>>>>>>
>>>>>>> What does that [*] mean? Judging by the other uses of []s, you seem to
>>>>>>> be accepting *s and digits at the start of a C function header even
>>>>>>> though they won't be taken to be one of your named matches. Why single
>>>>>>> out *s and digits?
>>>>>>
>>>>>> int* M(int* N);
>>>>>
>>>>> This does not recognise the {fh} pattern. Putting the named
>>>>> patterns into the string at the point the action would be triggered I
>>>>> get
>
> This is where you should have show that example not being recognised and
> then you would not accused me of deleting the example!
>
>> Your:
>> *1*x x(*x x()
>> was rejected by the C compiler.
>
> Yes. But right after I complained about your "int* M(int* N);" example
> not matching as a header you said
>

I already said that I have separate semantic actions that augment the
recognizer and you simply ignored that part because it was not useful
for your rebuttal.

This is the semantic action that recognizes Function Headers

bool RecognizedFunctionHeader(u8 OneByte, int State)
{ return (OneByte == ')' && (State == 6 || State == 7 || State == 9 ||
State == 10 || State == 11));
}

*1*x x(*x x()

> "The above string would be rejected by the C compiler"
>
> which is obviously not the case.
>

Why say something so foolish as that?

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 10/26/2021 8:56 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 10/25/2021 8:09 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 10/25/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 10/24/2021 8:08 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Enhancements: (Assumes that the C source code compiles)
>>>>>>>>> (a) Ignores /* */ comments
>>>>>>>>> (b) Ignores #define lines
>>>>>>>>> (c) Correctly handles trailing space in: int Function_Name(void )
>>>>>>>>>
>>>>>>>>> //
>>>>>>>>> // Deterministic Finite Automaton (DFA) recognizer
>>>>>>>>> // of C function headers.
>>>>>>>>>
>>>>>>>>> // Character Classes
>>>>>>>>> //
>>>>>>>>> EMPTY [0]
>>>>>>>>> ALPHA [ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz]
>>>>>>>>> NUMERIC [0123456789]
>>>>>>>>> WS [0x09,0x0A,0x0D,0x20]
>>>>>>>>> LPAREN [(]
>>>>>>>>> RPAREN [)]
>>>>>>>>> POUND [#]
>>>>>>>>> ASTERISK [*] // 0x2a
>>>>>>>>> COMMA [,]
>>>>>>>>> SLASH [0x2f] // "/"
>>>>>>>>> NEWLINE [0x0A]
>>>>>>>>
>>>>>>>> Why don't you use these last seven?
>>>>>>>
>>>>>>> I do use them.
>>>>>>
>>>>>> I meant why not use them in the code you posted.
>>>>>
>>>>> They are used in the DFA shown below.
>>>>
>>>> No they are not.
>>>
>>> Here is LPAREN: [(]{fn}(06)
>>>>>>>>> <04> WS{fn}(05) ALPHA(04) NUMERIC(04) [*](00) [(]{fn}(06)
>>
>> No. That state uses the definitions ALPHA and NUMERIC but it does not
>> use the definition LPAREN.
>
> I told you this before yet you did not notice because your entire
> focus is on rebuttal with no weight what-so-ever to understand.
>
> A character class can be referred to in the DFA by its name of by its
> definition. Because [(] is more concise than LPAREN I used the
> definition instead of the name.

Obviously. That's not the issue. You don't use the named definitions.
It looks sloppy to give definitions that you don't use. Just like it
looks sloppy to include "NUMERIC(00)" in state 0 when digits are invalid
at that point. Why single them out? It looks like writing code by
rote, rather than with careful consideration.

>>> Here is is being correctly recognized:
>>> int* M(int* N);
>>>
>>> [i] State(00) NextState(01) LineNumber(0006)
>>> [n] State(01) NextState(01) LineNumber(0006)
>>> [t] State(01) NextState(01) LineNumber(0006)
>>> [*] State(01) NextState(02) LineNumber(0006)
>>> [ ] State(02) {ft} NextState(03) LineNumber(0006)
>>> [M] State(03) NextState(04) LineNumber(0006)
>>> [(] State(04) {fn} NextState(06) LineNumber(0006)
>>> [i] State(06) NextState(07) LineNumber(0006)
>>> [n] State(07) NextState(07) LineNumber(0006)
>>> [t] State(07) NextState(07) LineNumber(0006)
>>> [*] State(07) NextState(08) LineNumber(0006)
>>> [ ] State(08) {vt} NextState(09) LineNumber(0006)
>>> [N] State(09) NextState(10) LineNumber(0006)
>>> [)] State(10) {vn} NextState(00) LineNumber(0006)
>>> insert("M", 1);
>>
>> It is not recognised as matching the {fh} pattern. That's (apparently)
>
> I already told you this before but because you only want to provide a
> rebuttal and don't give a rat's ass about understanding what I say you
> missed the explanition.
>
> Because each state can only recognize a single pattern and state (10)
> must recognize {vn} I use a separate semantic action to recognize
> {fh}.

The string you gave does not match the function header pattern. Your
"explanation" explains nothing. You just confirm confirming that the
DFA does not recognise "int* M(int* N)" as a function header. The DFA
stops after recognising a "vn" (variable name?).

>> Yes. But right after I complained about your "int* M(int* N);" example
>> not matching as a header you said
>
> I already said that I have separate semantic actions that augment the
> recognizer and you simply ignored that part because it was not useful
> for your rebuttal.
>
> This is the semantic action that recognizes Function Headers
>
> bool RecognizedFunctionHeader(u8 OneByte, int State)
> {
> return (OneByte == ')' && (State == 6 || State == 7 || State == 9 || State == 10 || State == 11));
> }
>
> *1*x x(*x x()
>
>> "The above string would be rejected by the C compiler"
>> which is obviously not the case.
>
> Why say something so foolish as that?

I know you are not above lying. I know you persist in dishonestly
omitting key parts of Linz's argument about halting. But I never
thought you'd edit and re-order a reply to score a cheap point. For
some reason it seems particularly shameful that you'd do this.

Here is the exchange:

|>> int* M(int* N);
|>
|> This does not recognise the {fh} pattern. Putting the named
|> patterns into the string at the point the action would be triggered I
|> get
|
|The above string would be rejected by the C compiler this never reach
|the DFA reogonizer.
|
|> int* {ft}M({fn}int* {vt}N){vn}

Just look at how you have re-edited that simple exchange.

You gave an example. I told you your DFA does not recognise it as a
function header. You say "the above string would be rejected by the C
compiler".

The string you dishonestly re-inserted into the exchange "*1*x x(*x x()"
does not even appear, quoted or otherwise, in your post so you don't
even have the excuse that "the above string" was supposed to refer to
something further above than the obvious candidate.

You rarely shock me anymore, but I'm shocked by this behaviour.

--
Ben.