• Re: Yet another contribution to the P-NP question

    From =?UTF-8?B?QW5kcsOpIEcuIElzYWFr?=@21:1/5 to All on Thu Sep 26 11:57:35 2024
    On 2024-09-26 08:57, nnymous109 wrote:
    Please forgive me, for I may not be able to review your own proof at the moment. Moreover, the links you provide point to things that seem like software packages. Might you be able to direct me to the PDF (or a
    similar sort of file)?

    Regarding the DOI I provided, you should be able to use it by inputting
    it into this website: https://dx.doi.org/

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link: https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    Neither of those methods work. I don't think you correctly uploaded the
    file.

    André

    --
    To email remove 'invalid' & replace 'gm' with well known Google mail
    service.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to All on Thu Sep 26 20:09:04 2024
    On 26/09/2024 18:57, Andr� G. Isaak wrote:
    On 2024-09-26 08:57, nnymous109 wrote:
    Please forgive me, for I may not be able to review your own proof at the
    moment. Moreover, the links you provide point to things that seem like
    software packages. Might you be able to direct me to the PDF (or a
    similar sort of file)?

    Regarding the DOI I provided, you should be able to use it by inputting
    it into this website: https://dx.doi.org/

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    Neither of those methods work. I don't think you correctly uploaded the file.

    Andr�


    The following worked for me:

    <https://doi.org/10.6084/m9.figshare.27106759>

    You can view the doc ("On Higher Order Recursions") in the browser, or there is a link on the page
    to download a PDF.

    Regards,
    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?QW5kcsOpIEcuIElzYWFr?=@21:1/5 to Mike Terry on Thu Sep 26 13:44:12 2024
    On 2024-09-26 13:09, Mike Terry wrote:
    On 26/09/2024 18:57, André G. Isaak wrote:
    On 2024-09-26 08:57, nnymous109 wrote:
    Please forgive me, for I may not be able to review your own proof at the >>> moment. Moreover, the links you provide point to things that seem like
    software packages. Might you be able to direct me to the PDF (or a
    similar sort of file)?

    Regarding the DOI I provided, you should be able to use it by inputting
    it into this website: https://dx.doi.org/

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    Neither of those methods work. I don't think you correctly uploaded
    the file.

    André


    The following worked for me:

      <https://doi.org/10.6084/m9.figshare.27106759>

    You can view the doc ("On Higher Order Recursions") in the browser, or
    there is a link on the page to download a PDF.

    Hmmm

    If I turn off my VPN it works. Apparently the VPN was the culprit.

    André

    --
    To email remove 'invalid' & replace 'gm' with well known Google mail
    service.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Mike Terry on Sun Sep 29 01:30:02 2024
    Mike Terry <[email protected]> writes:

    On 27/09/2024 23:42, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done >>>> sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are >>>> points later on that confirm that this is not a typo) then you need to >>>> explain why early on. You are free to define what you want, but a paper >>>> that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to represent >>> the accept and reject states, not tape symbols? Calling them symbols is >>> like calling q_0 a symbol, which seems harmless to me - is it just that you >>> want to call them "labels" or something other than "symbols"?
    Later he/she writes
    (Omega U {q_accept, q_reject})*
    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are
    used to make "strings" with other tape symbols.
    I agree that what the states actually are is irrelevant, but that two of
    them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs >>> have tape symbols and states, but I don't see any state transition
    table!
    Right, but that's line 2 and I was starting at line 1!
    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols
    but apparently not.

    Not a joke, for sure. Stuff like the integral sign needs explanation. Paragraph [5] looks like a definition? or is it standard in some branch of computation theory? I haven't seen it used like that, but wouldn't really know.

    When someone turns up from outside the established academic establishment with their own proof it can be hard work deciphering what they're really trying to say - so many private notations to clarify and so on. Many
    experts reasonably decide they're unable/unwilling to invest enough time on something very likely to turn out a lost cause. Anyhow, I hope this thread gets somewhere as it's likely I'll learn something here!

    I tried to make one major suggestion to the author: explain (in English)
    in what way the core of the argument differs from the usual "it must
    examine all the cases" non-proofs that keep cropping up.

    Of course the paper is very very likely wrong, and likely for a common underlying reason for such proof attempts, but the author says as much and asks for assistance rather than insisting they know better than all the experts - so a million miles from the usual class of usenet cranks we typically see. [PO, WM, AP, Nam/KD, JSH etc... all duffers in the sense of lacking background + ability to express themselves and reason technically, but not recognising this for whatever reasons. Ok, WM might be in his own category as he supposedly has more background than those others.].

    But there are some worrying signs. If someone knows little mathematics,
    why describe a mapping as a homomorphism when there is no topology in
    play? Does he or she just mean a bjection? What has continuity to do
    with it? There's a whiff of "that's a nice sounding word, I'll use it"
    here.

    It's funny - this group has had years and years of the likes of PO and his nonsense claims. It might seem almost like providence that just a couple
    of days after PO moves on (as it appears he has?)

    I have been filtering his posts for some time, but now you mention it,
    yes he's vanished. I fear he was telling the truth about his health and
    he may be very ill now.

    someone should turn up
    with a new thread containing (hopefully) actual logical argument rather
    than a succession of PO-non-logical claim after claim with no logic!
    Almost like this is what a group like this was originally meant for!
    :)

    I'm prepared to take it seriously for a while.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Keith Thompson on Sun Sep 29 02:10:42 2024
    On 29/09/2024 01:50, Keith Thompson wrote:
    Ben Bacarisse <[email protected]> writes:
    Mike Terry <[email protected]> writes:
    [...]
    It's funny - this group has had years and years of the likes of PO and his >>> nonsense claims. It might seem almost like providence that just a couple >>> of days after PO moves on (as it appears he has?)

    I have been filtering his posts for some time, but now you mention it,
    yes he's vanished. I fear he was telling the truth about his health and
    he may be very ill now.
    [...]

    His most recent post was from Sep 21, 7 days ago, subject "Enough of
    losers stuck in rebuttal mode", no body.

    ... which reads to me as a "goodbye and good riddence!" note. After all the time posters have
    donated to PO, we might have hoped at least for a more cheery "so long and thanks for all the fish",
    but I guess PO doesn't see things that way. Anyway he's disappeared in the past for long periods
    (months) then finally returned, so we'll see.


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Sun Sep 29 01:16:42 2024
    [email protected] (nnymous109) writes:

    On Fri, 27 Sep 2024 22:42:31 +0000, Ben Bacarisse wrote:

    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done >>>> sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are >>>> points later on that confirm that this is not a typo) then you need to >>>> explain why early on. You are free to define what you want, but a paper >>>> that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to
    represent
    the accept and reject states, not tape symbols? Calling them symbols is >>> like calling q_0 a symbol, which seems harmless to me - is it just that
    you
    want to call them "labels" or something other than "symbols"?

    Later he/she writes

    (Omega U {q_accept, q_reject})*

    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are
    used to make "strings" with other tape symbols.

    I agree that what the states actually are is irrelevant, but that two of
    them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs >>> have tape symbols and states, but I don't see any state transition
    table!

    Right, but that's line 2 and I was starting at line 1!

    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols
    but apparently not.

    Okay, Ben. Please allow me to try again.

    I'm not completely sure how to use USENET to reply to portions of
    replies, so I will try to answer some of your queries here since the
    other reply is much longer.

    I didn't query anything here, did I? All my significant points were in
    mt reply to you.

    I don't actually use the Turing machines formalism at all in my
    arguments until about point 22, so throughout the document I'm not
    thinking about Turing machine states and Turing machine symbols and
    Turing machine configurations, at all.

    You don't use it in point 22 either. You use the words Turing and
    machine but you don't use any TM formalism there.

    But in trying to discuss with others, I tend to just cast the entire
    argument in the language of Turing machines, since I felt that that
    would be more familiar. Maybe I shouldn't have done that.

    Your key audience (editors of prestigious journals) will be familiar
    with every formalism. There's nothing to be gained by trying to make
    the argument somehow familiar. Use whatever formalism best explains the
    key points.

    It's probably more accurate to say that I am trying to come up with a
    string re-writing model of computation as you pick up on. So everything
    is a string, and everything that can be used to form a string is a
    symbol, so there's no semantic difference between the following strings:

    0 0 1 0 0 0 1

    1 1 q_a r_e 0 0 2 3 d

    q_accept q_reject q_accept 1 1 q_reject 0 0 0 d f g


    Then we have some rules that tell us to replace substrings of any given string with another string. That's the entire recursion idea (and yes,
    we could do this with a Turing machine, but I'm asking us to forget
    about Turing machines momentarily).

    That's fine. No reader you care about should have any trouble with your discussing string re-writing. They will all have trouble with the
    points I made in my reply to you.

    Also, rather than do a wall of text like last time, I think I should
    pause and ask for criticisms here, and then answer them/proceed as is necessary.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Ben Bacarisse on Sun Sep 29 03:40:25 2024
    On 29/09/2024 01:30, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 23:42, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done >>>>> sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the >>>>> first line. If you want two of the states to be symbols (and there are >>>>> points later on that confirm that this is not a typo) then you need to >>>>> explain why early on. You are free to define what you want, but a paper >>>>> that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to represent >>>> the accept and reject states, not tape symbols? Calling them symbols is >>>> like calling q_0 a symbol, which seems harmless to me - is it just that you
    want to call them "labels" or something other than "symbols"?
    Later he/she writes
    (Omega U {q_accept, q_reject})*
    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are
    used to make "strings" with other tape symbols.
    I agree that what the states actually are is irrelevant, but that two of >>> them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs >>>> have tape symbols and states, but I don't see any state transition
    table!
    Right, but that's line 2 and I was starting at line 1!
    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols
    but apparently not.

    Not a joke, for sure. Stuff like the integral sign needs explanation.
    Paragraph [5] looks like a definition? or is it standard in some branch of >> computation theory? I haven't seen it used like that, but wouldn't really >> know.

    When someone turns up from outside the established academic establishment
    with their own proof it can be hard work deciphering what they're really
    trying to say - so many private notations to clarify and so on. Many
    experts reasonably decide they're unable/unwilling to invest enough time on >> something very likely to turn out a lost cause. Anyhow, I hope this thread >> gets somewhere as it's likely I'll learn something here!

    I tried to make one major suggestion to the author: explain (in English)
    in what way the core of the argument differs from the usual "it must
    examine all the cases" non-proofs that keep cropping up.

    Of course the paper is very very likely wrong, and likely for a common
    underlying reason for such proof attempts, but the author says as much and >> asks for assistance rather than insisting they know better than all the
    experts - so a million miles from the usual class of usenet cranks we
    typically see. [PO, WM, AP, Nam/KD, JSH etc... all duffers in the sense of >> lacking background + ability to express themselves and reason technically, >> but not recognising this for whatever reasons. Ok, WM might be in his own >> category as he supposedly has more background than those others.].

    But there are some worrying signs. If someone knows little mathematics,
    why describe a mapping as a homomorphism when there is no topology in
    play? Does he or she just mean a bjection? What has continuity to do
    with it? There's a whiff of "that's a nice sounding word, I'll use it"
    here.

    Like PO using words like "isomorphic" and "tautology" without any understanding of their technical
    meanings. That's possible...

    It looks like you might be confusing "homomorphism" and "homeomorphism" though. God knows they
    deserve to be muddled! Who invents these names? :)

    "homeomorphism" (with the 'e') is used in topology and is all to do with continuity. "homomorphism"
    (no 'e') is a general algebra term (applied to groups/fields/whatever), not based on continuity.

    <https://en.wikipedia.org/wiki/Homomorphism>
    <https://en.wikipedia.org/wiki/Homeomorphism>

    (This aside, you point could still apply.)

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Mike Terry on Sun Sep 29 22:56:24 2024
    Mike Terry <[email protected]> writes:

    On 29/09/2024 01:30, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 23:42, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>>>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done >>>>>> sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the >>>>>> first line. If you want two of the states to be symbols (and there are >>>>>> points later on that confirm that this is not a typo) then you need to >>>>>> explain why early on. You are free to define what you want, but a paper >>>>>> that starts "let 2 < 1" will have the reader wrong-footed from the >>>>>> start.

    You mean q_accept and q_reject? It looks like they are just to represent >>>>> the accept and reject states, not tape symbols? Calling them symbols is >>>>> like calling q_0 a symbol, which seems harmless to me - is it just that you
    want to call them "labels" or something other than "symbols"?
    Later he/she writes
    (Omega U {q_accept, q_reject})*
    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are >>>> used to make "strings" with other tape symbols.
    I agree that what the states actually are is irrelevant, but that two of >>>> them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs >>>>> have tape symbols and states, but I don't see any state transition
    table!
    Right, but that's line 2 and I was starting at line 1!
    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols >>>> but apparently not.

    Not a joke, for sure. Stuff like the integral sign needs explanation.
    Paragraph [5] looks like a definition? or is it standard in some branch of >>> computation theory? I haven't seen it used like that, but wouldn't really >>> know.

    When someone turns up from outside the established academic establishment >>> with their own proof it can be hard work deciphering what they're really >>> trying to say - so many private notations to clarify and so on. Many
    experts reasonably decide they're unable/unwilling to invest enough time on >>> something very likely to turn out a lost cause. Anyhow, I hope this thread >>> gets somewhere as it's likely I'll learn something here!
    I tried to make one major suggestion to the author: explain (in English)
    in what way the core of the argument differs from the usual "it must
    examine all the cases" non-proofs that keep cropping up.

    Of course the paper is very very likely wrong, and likely for a common
    underlying reason for such proof attempts, but the author says as much and >>> asks for assistance rather than insisting they know better than all the
    experts - so a million miles from the usual class of usenet cranks we
    typically see. [PO, WM, AP, Nam/KD, JSH etc... all duffers in the sense of >>> lacking background + ability to express themselves and reason technically, >>> but not recognising this for whatever reasons. Ok, WM might be in his own >>> category as he supposedly has more background than those others.].
    But there are some worrying signs. If someone knows little mathematics,
    why describe a mapping as a homomorphism when there is no topology in
    play? Does he or she just mean a bjection? What has continuity to do
    with it? There's a whiff of "that's a nice sounding word, I'll use it"
    here.

    Like PO using words like "isomorphic" and "tautology" without any understanding of their technical meanings. That's possible...

    It looks like you might be confusing "homomorphism" and "homeomorphism" though. God knows they deserve to be muddled! Who invents these names?
    :)

    You are right. I had seen "homeomorphism" where it was absent.
    ...

    (This aside, you point could still apply.)

    It's unclear as the algebra is unspecified. There's a lot that's unclear.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Mon Sep 30 00:27:36 2024
    [email protected] (nnymous109) writes:

    I tried to make one major suggestion to the author: explain (in English)
    in what way the core of the argument differs from the usual "it must
    examine all the cases" non-proofs that keep cropping up.

    And there's what I most unsure of. I've heard of these "examine all
    cases" non-proofs, but I don't know what exactly makes them fail (is it
    just that they don't give any reason why we must examine all the cases
    or is it something deeper?)

    Yes, just that. Nothing deep at all (though it's obviously very hard to
    give a sound reason or the P/NP question would have been settled long
    ago).

    I hope you will forgive me, but I have limited time and this discussion
    is already spread across two sub-threads so I plan to reply (from no on)
    only in the main sub-thread where I've commented on your argument in
    some detail.

    If I've missed something here that you think it crucial, please repeat
    it in that sub-thread.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Mike Terry on Mon Sep 30 00:30:23 2024
    Mike Terry <[email protected]> writes:

    On 29/09/2024 01:50, Keith Thompson wrote:
    Ben Bacarisse <[email protected]> writes:
    Mike Terry <[email protected]> writes:
    [...]
    It's funny - this group has had years and years of the likes of PO and his >>>> nonsense claims. It might seem almost like providence that just a couple >>>> of days after PO moves on (as it appears he has?)

    I have been filtering his posts for some time, but now you mention it,
    yes he's vanished. I fear he was telling the truth about his health and >>> he may be very ill now.
    [...]
    His most recent post was from Sep 21, 7 days ago, subject "Enough of
    losers stuck in rebuttal mode", no body.

    ... which reads to me as a "goodbye and good riddence!" note.

    Oh yes, so it does. (As I said, I filter his posts.)

    After all
    the time posters have donated to PO, we might have hoped at least for a
    more cheery "so long and thanks for all the fish", but I guess PO doesn't
    see things that way. Anyway he's disappeared in the past for long periods (months) then finally returned, so we'll see.

    That's also true, and I had forgotten.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Mon Sep 30 00:19:02 2024
    [email protected] (nnymous109) writes:

    On Sun, 29 Sep 2024 0:16:42 +0000, Ben Bacarisse wrote:

    [email protected] (nnymous109) writes:

    On Fri, 27 Sep 2024 22:42:31 +0000, Ben Bacarisse wrote:

    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>>>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done >>>>>> sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the >>>>>> first line. If you want two of the states to be symbols (and there are >>>>>> points later on that confirm that this is not a typo) then you need to >>>>>> explain why early on. You are free to define what you want, but a paper >>>>>> that starts "let 2 < 1" will have the reader wrong-footed from the >>>>>> start.

    You mean q_accept and q_reject? It looks like they are just to
    represent
    the accept and reject states, not tape symbols? Calling them symbols is >>>>> like calling q_0 a symbol, which seems harmless to me - is it just that >>>>> you
    want to call them "labels" or something other than "symbols"?

    Later he/she writes

    (Omega U {q_accept, q_reject})*

    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are >>>> used to make "strings" with other tape symbols.

    I agree that what the states actually are is irrelevant, but that two of >>>> them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs >>>>> have tape symbols and states, but I don't see any state transition
    table!

    Right, but that's line 2 and I was starting at line 1!

    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols >>>> but apparently not.

    Okay, Ben. Please allow me to try again.

    I'm not completely sure how to use USENET to reply to portions of
    replies, so I will try to answer some of your queries here since the
    other reply is much longer.

    I didn't query anything here, did I? All my significant points were in
    mt reply to you.

    I don't actually use the Turing machines formalism at all in my
    arguments until about point 22, so throughout the document I'm not
    thinking about Turing machine states and Turing machine symbols and
    Turing machine configurations, at all.

    You don't use it in point 22 either. You use the words Turing and
    machine but you don't use any TM formalism there.

    But in trying to discuss with others, I tend to just cast the entire
    argument in the language of Turing machines, since I felt that that
    would be more familiar. Maybe I shouldn't have done that.

    Your key audience (editors of prestigious journals) will be familiar
    with every formalism. There's nothing to be gained by trying to make
    the argument somehow familiar. Use whatever formalism best explains the
    key points.

    It's probably more accurate to say that I am trying to come up with a
    string re-writing model of computation as you pick up on. So everything
    is a string, and everything that can be used to form a string is a
    symbol, so there's no semantic difference between the following strings: >>>
    0 0 1 0 0 0 1

    1 1 q_a r_e 0 0 2 3 d

    q_accept q_reject q_accept 1 1 q_reject 0 0 0 d f g


    Then we have some rules that tell us to replace substrings of any given
    string with another string. That's the entire recursion idea (and yes,
    we could do this with a Turing machine, but I'm asking us to forget
    about Turing machines momentarily).

    That's fine. No reader you care about should have any trouble with your
    discussing string re-writing. They will all have trouble with the
    points I made in my reply to you.

    Also, rather than do a wall of text like last time, I think I should
    pause and ask for criticisms here, and then answer them/proceed as is
    necessary.

    Okay, I have noted all that you have said. If there's something worth preserving in any of the ideas I have, I am perfectly happy to rewrite
    these things using more idiomatic expressions.

    With that introduction out of the way, we're right at the heart of the
    thing. Given a string x and a recursion M, if y is the resultant string
    upon the action of the recursion, we write M(x) = y.

    If M(y) = z, then M(M(x)) = z, and equivalently M^2(x) = z.

    Using S. as the integral symbol*, we let S.(M(x)) be the infinite tuple
    <x, M(x), M^2(x), M^3(x), ...>.

    Tuples are finite. S.(M(x)) is an infinite sequence.

    More terminology... This is usually referred to as iteration. The map M
    is iterated to generate the sequence s_i = M^i(x).

    We call S.(M(x)) the computation of x by M.

    I hope you say a lot about what M can be because, left open, the result
    might not be what we would want to call a computation! Presumably, your
    M is the function that maps one TM configuration to the next, yes?

    If U_M is the set of symbols over which M recurses over,

    I don't see why you say "recurses over". M is a map from strings to
    strings. But using the term is merely a bit confusing. I don't think
    you are trying to say anything significant by using it.

    a property, P,
    of M is a subset of U_M.

    (you corrected this to U_M*)

    S.(M(x)) satisfies P if some substring of some
    element of it is in P.

    Weird, but OK. Substring seems to be rather weak, but maybe that's
    important later on.

    Writing [M] as an appropriate string representation of M and fixing a P,
    we can define the set

    L_P = {[M] such that there exists an x such that S.(M(x)) satisfies P}

    OK.

    With the assertion** that any recursion that decides that a
    computation satisfies some property

    What does that mean? So far we all we know is that a recursion (let's
    call one R to save overusing the letter M) defines, for any string s, a sequence R^i(s). What does it mean to say that R decides anything?
    Explain what you mean with a simple trivial case. Don't jump right into explaining what "decides that a computation satisfies some property"
    means.

    My guess: if a "recursion" is indeed the map from one TM configuration
    to the next, then R decides membership of a set S like this:

    s in S iff exists(i) such that R^i(s) = ...q_accept...
    s not in S iff exists(i) such that R^i(s) = ...q_reject...

    Is my guess right? If not, you need to say a lot more.

    With the assertion** that any recursion that decides that a
    computation satisfies some property necessarily yields at least one
    element of the computation***, I am suggesting that it is easier to
    check for inclusion in this set that it is to check for exclusion.

    ** - I should have liked to call this a proof, but everything I come up
    with ends up being circular, so I took the assertion on its face (which
    kind of feels like cheating). Indeed, this is where I most need
    validation.

    Yes, this might be a fatal flaw, but I am not yet sure there is even an argument to be fatally flawed because I don't yet know what your central
    term, "decides that a computation satisfies some property means". This
    would seem, at the very least, to require that both "recursions" /and/ properties be encoded. How do you plan to do that?

    And that's really the core of the idea. The definitions serve to handle
    the technicalities that arise in the details, and to make sure that
    existing concepts can be subsumed into the new scheme we have. If this
    path doesn't sound promising, then it is unlikely that I have a proof
    after all.

    It might have a fatal "the only way to do X is Y" assumption in it.

    But I have another question. Why all the new terms? Unless I am way
    off-base with what I think you mean, all this can be written using the
    accepted and familiar terminology of Turing machines. If you simply
    don't know enough about how to talk about TMs, I would be happy to help
    you re-write what you are saying in more conventional language (time permitting).

    * - In my handwritten notes, I have this as some stylized left bracket.
    I couldn't find what I was looking for when typing it out, so it became
    the integral sign, but there's absolutely no relation with calculus.


    *** - We can be even more restrictive with the assertion: the recursion necessarily yields at least some substring of at least one element of
    the computation.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Tue Oct 1 01:27:37 2024
    [email protected] (nnymous109) writes:

    On Sun, 29 Sep 2024 23:19:02 +0000, Ben Bacarisse wrote:


    Tuples are finite. S.(M(x)) is an infinite sequence.

    Ok, noted. Is it that it is a tuple whenever it is finite, but when that constrained is relaxed and it is allowed to be a infinite, it is more appropriate to call it a sequence?

    Not really. The term tuple has been accepted as the way to talk about
    finite ordered lists (pairs, triples, etc.). The term sequence has
    always been used for infinite indexed... well... sequences.

    More terminology... This is usually referred to as iteration. The map M
    is iterated to generate the sequence s_i = M^i(x).

    I see. I shall use iterations instead.

    I hope you say a lot about what M can be because, left open, the result
    might not be what we would want to call a computation! Presumably, your
    M is the function that maps one TM configuration to the next, yes?


    Yes, provided you're interpreting something like 'q_0 1 1 1 0' that I
    would a call a string as just a TM configuration.

    Yes. A TM configuration is the often seen as a tuple -- for example the
    triple consisting of the tape, the head position (an index) and the
    current state. You can represent that as a string, of course so that is
    can be operated on by "iterations" -- i.e. another TM.

    I don't see why you say "recurses over". M is a map from strings to
    strings. But using the term is merely a bit confusing. I don't think
    you are trying to say anything significant by using it.

    Okay, would 'iterates over' be better?

    Not for me. The problem word is "over". It is not the usual term for
    the domain of a map, but it's not a daft term either. The problem is
    just the reader will go "what does the author mean here if not simply
    the domain of the mapping?".

    What I'm trying to get is say we have some string

    G = 0 q z 1 0 1 and z is not in U_M,

    M can still act on G in the following manner: if M contains a rule that
    '0 q e' should be transformed into '1 1 q_b' where e is the empty
    string,

    M(G) = 1 1 q_b z 1 0 1

    OK. So "over" is hiding something. M is not a map from U_M* to U_M*.
    That's messy and seems to be unnecessary. What is the problem in saying
    that strings M maps? Why not simply allow M's domain to contain all the
    string that it might "operate on"?

    Weird, but OK. Substring seems to be rather weak, but maybe that's
    important later on.

    It allows us to extend things like halting.

    I was talking about the details. They look clumsy to me. What you say
    below is straightforward and obvious.

    It allows us to extend things like halting. Say I build M using the transition table of a Turing machine and at some point in the
    computation, M^i(x) is 0 1 q_accept 1 1. Because we built M from a TM,
    it will be the case that M^(i+1)(x) = M^i(x)

    That's fine and not all surprising. This does not require the odd
    detail that M's domain does include all the string it might be applied
    to!

    Then we can say that S.(M(x)) satisfies the property {q_accept} and
    becomes stationary at iteration i to capture the same halting idea.

    Yes, I can see you might want to do that. I suspect there will be a
    simpler way to describe the properties you are interested in, but that's
    not important right now.

    With the assertion** that any recursion that decides that a
    computation satisfies some property

    What does that mean? So far we all we know is that a recursion (let's
    call one R to save overusing the letter M) defines, for any string s, a
    sequence R^i(s). What does it mean to say that R decides anything?
    Explain what you mean with a simple trivial case. Don't jump right into
    explaining what "decides that a computation satisfies some property"
    means.

    My guess: if a "recursion" is indeed the map from one TM configuration
    to the next, then R decides membership of a set S like this:

    s in S iff exists(i) such that R^i(s) = ...q_accept...
    s not in S iff exists(i) such that R^i(s) = ...q_reject...

    Is my guess right? If not, you need to say a lot more.



    Okay, if I may re-render your guess using my terminology, we would have

    s in S iff S.(R(s)) satisfies P1 = {q_accept}
    s not in S iff S.(R(s)) satisfies P2 = {q_reject}

    Fine. By the way, you don't need to name everything:

    s in S iff S.(R(s)) satisfies {q_accept}
    s not in S iff S.(R(s)) satisfies {q_reject}

    though you really should make it clear that {q_accept} is not what it
    appears -- a set containing a state -- it's a set containing a string of
    length one.

    which is almost correct except for three points

    1) We need to specify that the property satisfaction takes place after
    the computation has become stationary.

    That is not part of your definition of "satisfies" but it will, of
    course, follow from the fact that the result of your iterations are TM configurations and they always become constant when that state is either q_accept or q_reject.

    If did not go off into your own notation, there would be no need to
    worry about this being obvious.

    2) Also, R need not be constructed from a TM or have q_accept or
    q_reject in U_R (i.e., in the set it "recurses" over), so P1 and P2 need
    only be two properties that a computation cannot both satisfy at the
    same time when it is stationary*.

    OK. You've lost me. I thought R (and iteration) was always a TM
    configuration transition function.

    This must be cleared up, because non-computable maps are going to take
    you into all kinds of murky waters.

    3) And R need not act on S directly, we only need a surjective function,
    f, to map strings that R can "recurse" over, that is from (U_R)* to some superset of S [*]

    Again you've lost me. I no longer know what it means for an iteration
    (what was a recursion) to decided something.

    So, to decide L_P,

    Ah, this sudden stop made me go look to see of there was another post.
    And there is, and it suggests you plan to offer a different argument. I
    hope I have not wasted my time here.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Fri Sep 27 00:34:30 2024
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link: https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    I am hoping that this is a joke. If it is a joke, then I say well done
    sir (or madam)[*].

    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are
    points later on that confirm that this is not a typo) then you need to
    explain why early on. You are free to define what you want, but a paper
    that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    [*] I once went to a contemporary art exhibition where the "catalogue"
    was a set of "theorems" using real mathematical notations but it made no
    sense. It was fabulous.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Ben Bacarisse on Fri Sep 27 02:53:28 2024
    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    I am hoping that this is a joke. If it is a joke, then I say well done
    sir (or madam)[*].

    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are points later on that confirm that this is not a typo) then you need to explain why early on. You are free to define what you want, but a paper
    that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to represent the accept and reject
    states, not tape symbols? Calling them symbols is like calling q_0 a symbol, which seems harmless
    to me - is it just that you want to call them "labels" or something other than "symbols"?

    I don't fully get the notation though - e.g. it seems to me that the TMs have tape symbols and
    states, but I don't see any state transition table!

    Basically, I could probably ask questions and get to grips with details like that, but in the end I
    don't know the whole P / NP field (definitions, basic results/claims etc.) well enough
    (understatement!) to offer any kind of review of the paper.

    Mike.



    [*] I once went to a contemporary art exhibition where the "catalogue"
    was a set of "theorems" using real mathematical notations but it made no sense. It was fabulous.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Mike Terry on Fri Sep 27 23:42:31 2024
    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done
    sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are
    points later on that confirm that this is not a typo) then you need to
    explain why early on. You are free to define what you want, but a paper
    that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to represent
    the accept and reject states, not tape symbols? Calling them symbols is
    like calling q_0 a symbol, which seems harmless to me - is it just that you want to call them "labels" or something other than "symbols"?

    Later he/she writes

    (Omega U {q_accept, q_reject})*

    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are
    used to make "strings" with other tape symbols.

    I agree that what the states actually are is irrelevant, but that two of
    them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs
    have tape symbols and states, but I don't see any state transition
    table!

    Right, but that's line 2 and I was starting at line 1!

    I thought it might be joke because of the way the author just piles
    definition on definition using bizarre notations like integral symbols
    but apparently not.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to [email protected] on Sat Sep 28 00:12:22 2024
    [email protected] (nnymous109) writes:

    On Thu, 26 Sep 2024 23:34:30 +0000, Ben Bacarisse wrote:

    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access
    the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237

    I am hoping that this is a joke. If it is a joke, then I say well done
    sir (or madam)[*].

    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are
    points later on that confirm that this is not a typo) then you need to
    explain why early on. You are free to define what you want, but a paper
    that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    [*] I once went to a contemporary art exhibition where the "catalogue"
    was a set of "theorems" using real mathematical notations but it made no
    sense. It was fabulous.


    Thank you for your reply and for considering the document.

    In Mike Terry's words, I'm just using q_accept and q_reject as labels
    (i.e., aside from where they are entered into the transition table, they aren't any different from 0 or 1). The reason I fix them beforehand is
    that somewhere in the first construction I make, I want to have the
    q_accept and q_reject of every machine be the same symbol.

    (1) You could have called them states and no one would have been
    startled by the first line of your impenetrable text.

    (2) Later, you used as apparent symbols is that Omega U {q_accept,
    q_reject} is used to make finite symbol strings. This is peculiar.

    I made a companion post on Reddit (but my replies are being blocked by
    their spam filters), and I was told to give a general idea of what I was doing, so I provided the following:

    I agree. Mathematical notation should be used where is help clarify
    what you mean. You seem to use it to obscure what you mean. You should
    be able to explain, in broad terms, how your paper relates to P and NP
    using simple language. At the very least, you need an abstract that
    give the broad outline.

    -----

    My strategy is to define a language over the string representations of
    Turing machines.
    A machine is then admitted into this language if there
    is an input for which the machine assumes a certain configuration in the computation of that input.
    The language is in NP because we can give some input as the certificate
    of a machine. It is not in P because I'm arguing for some kind of independence between machine configurations, so that the verifier needs
    to spit out all the configurations to assess them.

    Pretty much every P=/=NP proof fails because of the assumption about
    what a decider needs to do.

    I would not bother with any other part of the paper until you can a
    certain that you have a proof about what a "verifier needs to do". Note
    that almost everyone wold say that it's obvious that a SAT decider much
    check all assignments, but "obvious" is not a proof. Nothing else
    matters but this key step. All the rest is technical detail.

    The verbosity (which I apologize for) comes from my attempts to make
    precise these ideas, and to ensure some technicalities (like the
    verifier always halting) hold.

    You need to spell out how it is that this one language has the so far
    unique property that it's decider can't be polynomial.

    -----

    The reason I have this scheme of 'recursions' is because I was looking
    for a natural way (at least, to me) to observe the configurations of
    Turing machines. Say we have the machine's configuration (which doubles
    as the input) as:

    0 q_a 0 1 0 0 1 ....

    "Doubles as" is wrong here. This input is a string. The configuration
    is a string, a position and a state. I know you know this (you've
    written the state in the middle of a string to show that you know this.

    where the first element beside the q_a is the current symbol scanned.
    Say that symbol and state are updated, and the machine head moves to the right, the next configuration (and input for the second iteration)
    becomes:

    0 1 q_b 1 0 0 1 ....

    But we can also see this as some substring of the previous configuration getting replaced with (transformed into) another string. That is, the substring '0 q_a 0' is replaced with '0 1 q_b'.

    Yes. There are TM-equivalent computational models that simply do string re-writing.

    Now, q_a is a first-order symbol,

    It's a state. But if you also want to treat it as a symbol then you
    either need another set of TM's that have their own state sets but that
    have symbol sets that include all the q_i of the other kinds of TMs, or
    you need to explicitly define a string representation for all the q_i
    using only {0, 1}. I didn't see either being done in the paper, but
    then I found it impenetrable.

    so the substring that was transformed
    is only three symbols long. A second order symbol, r_b, could transform substrings seven symbols long, something like: '0 1 q_a r_b 0 1 1' to
    'q_f 1 q_j r_c 0 0 1'. Notice that the second order symbols have 'power'
    over all symbols with lower order: 1-order symbols (q_*), and 0-order
    symbols (0 and 1).

    Your words are doing too much work. Symbols don't transform anything.
    And you are not using first and second order in any reasonable way. At
    the very least, define what you mean by "order". If you just refer me
    to your paper, I'll bow out now.

    The way I've imagined it: first the zero-order symbols do their thing

    How you imagine a symbol "doing it's thing" is useless to me. To me,
    symbols don't "do" anything. You have to explain what a symbol "doing" something even means.

    (they can only change substrings of length 1 [themselves], so if we
    want

    Symbols don't change anything either.

    I think you are edging your way towards a string re-writing model of computation, but the words you currently use don't make sense.

    I have to stop here, because I have no idea how symbols "do" things, so
    you've lost me...

    them fixed, we just have the iteration rules of the 0-order symbols be empty), then the first-order symbols do their own thing, and so on and
    so forth, and we call the resulting process an iteration.

    With this scheme, all sorts of things could now be valid inputs, e.g., q_accept q_reject 0 1 q_a 0 0 0, so things like standard strings, etc.,
    are my way of identifying subsets of inputs that are relevant for the discussion at hand, e.g., strings like q_0 0 1 1 1 1 where q_0 is what
    would ordinarily be an initial state are standard per q_0.

    Now, I will bet that this scheme is too general for what we do with it
    in the end (all of this is equivalent to some Turing machine, as I note
    in 9), so the reason it's this way is two-fold:

    First, when I started, I wasn't completely sure where I was headed and
    what I would get in the end, and it just felt easier (at least at the
    time) to think about it this way (the state is identified with the input
    and with the configuration of the machine). Then we get to the end, and,
    with the benefit of hindsight, I am pretty sure there is an easier path
    to our final conclusion.

    The second reason, and why I didn't just do a full re-write, is that I'm nursing dreams of one day doing work in Statistical Physics/Complex
    Systems, and the scheme is reminiscent of that of cellular automata (to
    my mind, at least). So, we have nice things (to my mind, again) like the iterations going on to infinity, except that at some point, the strings
    don't change anymore, so there are very very faint ideas of some notion
    of equilibrium that I would like to think some more about (probably
    using a more general scheme).

    But I suppose if you've somehow convinced (deluded?) yourself that
    you've said something about P ?= NP, you ought to stop and tell someone
    :)


    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Ben Bacarisse on Sat Sep 28 03:10:20 2024
    On 27/09/2024 23:42, Ben Bacarisse wrote:
    Mike Terry <[email protected]> writes:

    On 27/09/2024 00:34, Ben Bacarisse wrote:
    [email protected] (nnymous109) writes:

    Also, I did not know this yesterday, but alternatively, you can access >>>> the document directly through the following link:
    https://figshare.com/articles/preprint/On_Higher_Order_Recursions_25SEP2024/27106759?file=49414237
    I am hoping that this is a joke. If it is a joke, then I say well done
    sir (or madam)[*].
    But I fear it is not a joke, in which case I have a problem with the
    first line. If you want two of the states to be symbols (and there are
    points later on that confirm that this is not a typo) then you need to
    explain why early on. You are free to define what you want, but a paper >>> that starts "let 2 < 1" will have the reader wrong-footed from the
    start.

    You mean q_accept and q_reject? It looks like they are just to represent
    the accept and reject states, not tape symbols? Calling them symbols is
    like calling q_0 a symbol, which seems harmless to me - is it just that you >> want to call them "labels" or something other than "symbols"?

    Later he/she writes

    (Omega U {q_accept, q_reject})*

    where * is, presumably, the Kleene closure. Omega is the set of
    non-blank tape symbols of the TMs under discussion so these states are
    used to make "strings" with other tape symbols.

    I agree that what the states actually are is irrelevant, but that two of
    them are later used like this is presumably important.

    I don't fully get the notation though - e.g. it seems to me that the TMs
    have tape symbols and states, but I don't see any state transition
    table!

    Right, but that's line 2 and I was starting at line 1!

    I thought it might be joke because of the way the author just piles definition on definition using bizarre notations like integral symbols
    but apparently not.

    Not a joke, for sure. Stuff like the integral sign needs explanation. Paragraph [5] looks like a
    definition? or is it standard in some branch of computation theory? I haven't seen it used like
    that, but wouldn't really know.

    When someone turns up from outside the established academic establishment with their own proof it
    can be hard work deciphering what they're really trying to say - so many private notations to
    clarify and so on. Many experts reasonably decide they're unable/unwilling to invest enough time on
    something very likely to turn out a lost cause. Anyhow, I hope this thread gets somewhere as it's
    likely I'll learn something here!

    Of course the paper is very very likely wrong, and likely for a common underlying reason for such
    proof attempts, but the author says as much and asks for assistance rather than insisting they know
    better than all the experts - so a million miles from the usual class of usenet cranks we typically
    see. [PO, WM, AP, Nam/KD, JSH etc... all duffers in the sense of lacking background + ability to
    express themselves and reason technically, but not recognising this for whatever reasons. Ok, WM
    might be in his own category as he supposedly has more background than those others.].

    It's funny - this group has had years and years of the likes of PO and his nonsense claims. It
    might seem almost like providence that just a couple of days after PO moves on (as it appears he
    has?) someone should turn up with a new thread containing (hopefully) actual logical argument rather
    than a succession of PO-non-logical claim after claim with no logic! Almost like this is what a
    group like this was originally meant for! :)

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeff Barnett@21:1/5 to All on Fri Sep 27 21:24:07 2024
    T24gOS8yNy8yMDI0IDg6MTAgUE0sIE1pa2UgVGVycnkgd3JvdGU6DQo+IE9uIDI3LzA5LzIw MjQgMjM6NDIsIEJlbiBCYWNhcmlzc2Ugd3JvdGU6DQo+PiBNaWtlIFRlcnJ5IDxuZXdzLmRl YWQucGVyc29uLnN0b25lc0BkYXJqZWVsaW5nLnBsdXMuY29tPiB3cml0ZXM6DQo+Pg0KPj4+ IE9uIDI3LzA5LzIwMjQgMDA6MzQsIEJlbiBCYWNhcmlzc2Ugd3JvdGU6DQo+Pj4+IG5ueW1v dXMxMDlAZ21haWwuY29tIChubnltb3VzMTA5KSB3cml0ZXM6DQo+Pj4+DQo+Pj4+PiBBbHNv LCBJIGRpZCBub3Qga25vdyB0aGlzIHllc3RlcmRheSwgYnV0IGFsdGVybmF0aXZlbHksIHlv dSBjYW4gYWNjZXNzDQo+Pj4+PiB0aGUgZG9jdW1lbnQgZGlyZWN0bHkgdGhyb3VnaCB0aGUg Zm9sbG93aW5nIGxpbms6DQo+Pj4+PiBodHRwczovL2ZpZ3NoYXJlLmNvbS9hcnRpY2xlcy9w cmVwcmludC9Pbl9IaWdoZXJfT3JkZXJfUmVjdXJzaW9uc18yNVNFUDIwMjQvMjcxMDY3NTk/ ZmlsZT00OTQxNDIzNw0KPj4+PiBJIGFtIGhvcGluZyB0aGF0IHRoaXMgaXMgYSBqb2tlLsKg IElmIGl0IGlzIGEgam9rZSwgdGhlbiBJIHNheSB3ZWxsIGRvbmUNCj4+Pj4gc2lyIChvciBt YWRhbSlbKl0uDQo+Pj4+IEJ1dCBJIGZlYXIgaXQgaXMgbm90IGEgam9rZSwgaW4gd2hpY2gg Y2FzZSBJIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhlDQo+Pj4+IGZpcnN0IGxpbmUuwqAgSWYg eW91IHdhbnQgdHdvIG9mIHRoZSBzdGF0ZXMgdG8gYmUgc3ltYm9scyAoYW5kIHRoZXJlIGFy ZQ0KPj4+PiBwb2ludHMgbGF0ZXIgb24gdGhhdCBjb25maXJtIHRoYXQgdGhpcyBpcyBub3Qg YSB0eXBvKSB0aGVuIHlvdSBuZWVkIHRvDQo+Pj4+IGV4cGxhaW4gd2h5IGVhcmx5IG9uLsKg IFlvdSBhcmUgZnJlZSB0byBkZWZpbmUgd2hhdCB5b3Ugd2FudCwgYnV0IGEgDQo+Pj4+IHBh cGVyDQo+Pj4+IHRoYXQgc3RhcnRzICJsZXQgMiA8IDEiIHdpbGwgaGF2ZSB0aGUgcmVhZGVy IHdyb25nLWZvb3RlZCBmcm9tIHRoZQ0KPj4+PiBzdGFydC4NCj4+Pg0KPj4+IFlvdSBtZWFu IHFfYWNjZXB0IGFuZCBxX3JlamVjdD/CoCBJdCBsb29rcyBsaWtlIHRoZXkgYXJlIGp1c3Qg dG8gDQo+Pj4gcmVwcmVzZW50DQo+Pj4gdGhlIGFjY2VwdCBhbmQgcmVqZWN0IHN0YXRlcywg bm90IHRhcGUgc3ltYm9scz/CoCBDYWxsaW5nIHRoZW0gc3ltYm9scyBpcw0KPj4+IGxpa2Ug Y2FsbGluZyBxXzAgYSBzeW1ib2wsIHdoaWNoIHNlZW1zIGhhcm1sZXNzIHRvIG1lIC0gaXMg aXQganVzdCANCj4+PiB0aGF0IHlvdQ0KPj4+IHdhbnQgdG8gY2FsbCB0aGVtICJsYWJlbHMi IG9yIHNvbWV0aGluZyBvdGhlciB0aGFuICJzeW1ib2xzIj8NCj4+DQo+PiBMYXRlciBoZS9z aGUgd3JpdGVzDQo+Pg0KPj4gwqDCoMKgIChPbWVnYSBVIHtxX2FjY2VwdCwgcV9yZWplY3R9 KSoNCj4+DQo+PiB3aGVyZSAqIGlzLCBwcmVzdW1hYmx5LCB0aGUgS2xlZW5lIGNsb3N1cmUu wqAgT21lZ2EgaXMgdGhlIHNldCBvZg0KPj4gbm9uLWJsYW5rIHRhcGUgc3ltYm9scyBvZiB0 aGUgVE1zIHVuZGVyIGRpc2N1c3Npb24gc28gdGhlc2Ugc3RhdGVzIGFyZQ0KPj4gdXNlZCB0 byBtYWtlICJzdHJpbmdzIiB3aXRoIG90aGVyIHRhcGUgc3ltYm9scy4NCj4+DQo+PiBJIGFn cmVlIHRoYXQgd2hhdCB0aGUgc3RhdGVzIGFjdHVhbGx5IGFyZSBpcyBpcnJlbGV2YW50LCBi dXQgdGhhdCB0d28gb2YNCj4+IHRoZW0gYXJlIGxhdGVyIHVzZWQgbGlrZSB0aGlzIGlzIHBy ZXN1bWFibHkgaW1wb3J0YW50Lg0KPj4NCj4+PiBJIGRvbid0IGZ1bGx5IGdldCB0aGUgbm90 YXRpb24gdGhvdWdoIC0gZS5nLiBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBUTXMNCj4+PiBo YXZlIHRhcGUgc3ltYm9scyBhbmQgc3RhdGVzLCBidXQgSSBkb24ndCBzZWUgYW55IHN0YXRl IHRyYW5zaXRpb24NCj4+PiB0YWJsZSENCj4+DQo+PiBSaWdodCwgYnV0IHRoYXQncyBsaW5l IDIgYW5kIEkgd2FzIHN0YXJ0aW5nIGF0IGxpbmUgMSENCj4+DQo+PiBJIHRob3VnaHQgaXQg bWlnaHQgYmUgam9rZSBiZWNhdXNlIG9mIHRoZSB3YXkgdGhlIGF1dGhvciBqdXN0IHBpbGVz DQo+PiBkZWZpbml0aW9uIG9uIGRlZmluaXRpb24gdXNpbmcgYml6YXJyZSBub3RhdGlvbnMg bGlrZSBpbnRlZ3JhbCBzeW1ib2xzDQo+PiBidXQgYXBwYXJlbnRseSBub3QuDQo+Pg0KPiBO b3QgYSBqb2tlLCBmb3Igc3VyZS7CoCBTdHVmZiBsaWtlIHRoZSBpbnRlZ3JhbCBzaWduIG5l ZWRzIGV4cGxhbmF0aW9uLiAgDQo+IFBhcmFncmFwaCBbNV0gbG9va3MgbGlrZSBhIGRlZmlu aXRpb24/IG9yIGlzIGl0IHN0YW5kYXJkIGluIHNvbWUgYnJhbmNoIA0KPiBvZiBjb21wdXRh dGlvbiB0aGVvcnk/wqAgSSBoYXZlbid0IHNlZW4gaXQgdXNlZCBsaWtlIHRoYXQsIGJ1dCB3 b3VsZG4ndCANCj4gcmVhbGx5IGtub3cuDQo+IA0KPiBXaGVuIHNvbWVvbmUgdHVybnMgdXAg ZnJvbSBvdXRzaWRlIHRoZSBlc3RhYmxpc2hlZCBhY2FkZW1pYyANCj4gZXN0YWJsaXNobWVu dCB3aXRoIHRoZWlyIG93biBwcm9vZiBpdCBjYW4gYmUgaGFyZCB3b3JrIGRlY2lwaGVyaW5n IHdoYXQgDQo+IHRoZXkncmUgcmVhbGx5IHRyeWluZyB0byBzYXkgLSBzbyBtYW55IHByaXZh dGUgbm90YXRpb25zIHRvIGNsYXJpZnkgYW5kIA0KPiBzbyBvbi7CoCBNYW55IGV4cGVydHMg cmVhc29uYWJseSBkZWNpZGUgdGhleSdyZSB1bmFibGUvdW53aWxsaW5nIHRvIA0KPiBpbnZl c3QgZW5vdWdoIHRpbWUgb24gc29tZXRoaW5nIHZlcnkgbGlrZWx5IHRvIHR1cm4gb3V0IGEg bG9zdCBjYXVzZS4gIA0KPiBBbnlob3csIEkgaG9wZSB0aGlzIHRocmVhZCBnZXRzIHNvbWV3 aGVyZSBhcyBpdCdzIGxpa2VseSBJJ2xsIGxlYXJuIA0KPiBzb21ldGhpbmcgaGVyZSENCj4g DQo+IE9mIGNvdXJzZSB0aGUgcGFwZXIgaXMgdmVyeSB2ZXJ5IGxpa2VseSB3cm9uZywgYW5k IGxpa2VseSBmb3IgYSBjb21tb24gDQo+IHVuZGVybHlpbmcgcmVhc29uIGZvciBzdWNoIHBy b29mIGF0dGVtcHRzLCBidXQgdGhlIGF1dGhvciBzYXlzIGFzIG11Y2ggDQo+IGFuZCBhc2tz IGZvciBhc3Npc3RhbmNlIHJhdGhlciB0aGFuIGluc2lzdGluZyB0aGV5IGtub3cgYmV0dGVy IHRoYW4gYWxsIA0KPiB0aGUgZXhwZXJ0cyAtIHNvIGEgbWlsbGlvbiBtaWxlcyBmcm9tIHRo ZSB1c3VhbCBjbGFzcyBvZiB1c2VuZXQgY3JhbmtzIA0KPiB3ZSB0eXBpY2FsbHkgc2VlLsKg IFtQTywgV00sIEFQLCBOYW0vS0QsIEpTSCBldGMuLi4gYWxsIGR1ZmZlcnMgaW4gdGhlIA0K PiBzZW5zZSBvZiBsYWNraW5nIGJhY2tncm91bmQgKyBhYmlsaXR5IHRvIGV4cHJlc3MgdGhl bXNlbHZlcyBhbmQgcmVhc29uIA0KPiB0ZWNobmljYWxseSwgYnV0IG5vdCByZWNvZ25pc2lu ZyB0aGlzIGZvciB3aGF0ZXZlciByZWFzb25zLsKgIE9rLCBXTSANCj4gbWlnaHQgYmUgaW4g aGlzIG93biBjYXRlZ29yeSBhcyBoZSBzdXBwb3NlZGx5IGhhcyBtb3JlIGJhY2tncm91bmQg dGhhbiANCj4gdGhvc2Ugb3RoZXJzLl0uDQo+IA0KPiBJdCdzIGZ1bm55IC0gdGhpcyBncm91 cCBoYXMgaGFkIHllYXJzIGFuZCB5ZWFycyBvZiB0aGUgbGlrZXMgb2YgUE8gYW5kIA0KPiBo aXMgbm9uc2Vuc2UgY2xhaW1zLsKgIEl0IG1pZ2h0IHNlZW0gYWxtb3N0IGxpa2UgcHJvdmlk ZW5jZSB0aGF0IGp1c3QgYSANCj4gY291cGxlIG9mIGRheXMgYWZ0ZXIgUE8gbW92ZXMgb24g KGFzIGl0IGFwcGVhcnMgaGUgaGFzPykgc29tZW9uZSBzaG91bGQgDQo+IHR1cm4gdXAgd2l0 aCBhIG5ldyB0aHJlYWQgY29udGFpbmluZyAoaG9wZWZ1bGx5KSBhY3R1YWwgbG9naWNhbCBh cmd1bWVudCANCj4gcmF0aGVyIHRoYW4gYSBzdWNjZXNzaW9uIG9mIFBPLW5vbi1sb2dpY2Fs IGNsYWltIGFmdGVyIGNsYWltIHdpdGggbm8gDQo+IGxvZ2ljIcKgIEFsbW9zdCBsaWtlIHRo aXMgaXMgd2hhdCBhIGdyb3VwIGxpa2UgdGhpcyB3YXMgb3JpZ2luYWxseSBtZWFudCANCj4g Zm9yISA6KQ0KKzENCi0tIA0KSmVmZiBCYXJuZXR0DQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to All on Sat Oct 12 01:15:21 2024
    [email protected] (nnymous109) writes:

    I am going to reply here just to give you some general advice. I don't
    have a lot of time, so depending on whether you want to continue or not,
    I may re-activate the more detailed thread we were engaged later.

    I was talking about the details. They look clumsy to me. What you say
    below is straightforward and obvious.

    Could you explain what you mean by clumsy? To be fair, I'd probably also
    need to understand what you meant by 'weak' first.

    First, please try to keep attribution lines in your replies. These are
    the lines like "[email protected] (nnymous109) writes:" (and their
    quoted versions). That helps a reader (like me!) know who wrote the ">"
    and ">>" passages.

    Second. Keep more context -- i.e. don't cut quite so much material. To
    answer your question -- what I mean by clumsy -- I'd have to go up the
    thread and remind myself what you wrote and what it was I thought was
    clumsy. That's making me do work that I would not need to do if the
    quotes were still in the message I am replying to. I don't have time to
    do that so I can't answer your question.

    2) Also, R need not be constructed from a TM or have q_accept or
    q_reject in U_R (i.e., in the set it "recurses" over), so P1 and P2 need >>> only be two properties that a computation cannot both satisfy at the
    same time when it is stationary*.

    OK. You've lost me. I thought R (and iteration) was always a TM
    configuration transition function.

    This must be cleared up, because non-computable maps are going to take
    you into all kinds of murky waters.

    Yup, I should have left this out until we started talking specifics, but
    in general R need not be a TM configuration transition function. It's
    just a bunch of tuples that have some structure and R(s) is some result
    you get if you apply the rules prescribed by R.

    But we've been talking about specifics all along, At least that's been
    my hope. I want specifics. Since it seems I'm wrong about what a
    "recursion" is -- to the extent that it might no even be commutable -- I
    want specifics even more! What is the hell is it? "A bunch of tuples
    with some structure" tells me almost nothing about the central object
    you are discussing.

    Note: being specific does not make what you are talking about any less
    general than you'd like. It just means pinning it down so we both know
    what's being talked about -- se we know just how general it really it.
    What you call a recursion might be something absurdly general and
    extremely abstract, but I still want you to be specific about what it
    is.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)