• Re: A New Turing Machine Model

    From Ben Bacarisse@21:1/5 to wij on Wed Feb 12 23:28:10 2025
    wij <wyniijj5@gmail.com> writes:

    Many should have been annoyed by the low-level-ness of the traditional Turing Machine. Spu comes to the rescue.

    The low-level is useful because it simplifies a lot of proofs, but when something higher-level is needed Turing equivalence and other results
    like the Curry-Howard correspondence mean that there is no shortage of higher-level models to work with.

    Spu is a simple C++ class, the significance is that it can also be used as a theoretical TM model, greatly simplifies deduction and statement based on TM and also significantly provides a way of mechanical verification.

    Do you have an example deduction you can present?

    https://sourceforge.net/projects/cscall/

    Where is Spu? That project appears to have nothing by that name.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Feb 13 07:17:15 2025
    On 2/12/25 11:24 PM, olcott wrote:
    On 2/12/2025 5:28 PM, Ben Bacarisse wrote:
    wij <wyniijj5@gmail.com> writes:

    Many should have been annoyed by the low-level-ness of the
    traditional Turing
    Machine. Spu comes to the rescue.

    The low-level is useful because it simplifies a lot of proofs, but when
    something higher-level is needed Turing equivalence and other results
    like the Curry-Howard correspondence mean that there is no shortage of
    higher-level models to work with.


    https://en.wikipedia.org/wiki/Random-access_stored-program_machine
    Concise, precise and easily mapped to many higher level language.
    I have simply assumed that C maps to RASP and then used C.


    The problem is that while you can build a RASP machine from a Turing
    Machine (since it is Turing Compatible), a RASP machine ISN'T a Turing
    machine, and RASP code doesn't have all the nice properties of Turing
    COde, the big one being that *ALL* Turing Machine code fragments perform comupuations (a defined mapping of input to output) that can not be said
    of RASP program fragments.

    The key point is that the fundamental structure of a Turing Machine puts
    a clear line between what is the "input" and what is the "internal
    program state", and what is the program, and a given program always
    starts at the same internal state.

    Once you mix input and program state into a common bucket, you lose that
    nice property.

    So, we get to your fundamental problem, that what you call the "program" D/DD/DDD isn't actually a program, but a program fragment, and when we
    run it, it ends up using "code" outside of itself, and thus violates the definition of a computation. In the same way, your decider, due to your
    "bug" that makes it not pure code, also uses data outside of its input,
    and thus is also not actually a "program" in the required meaning.

    That you refuese to see this, just proves that you are totally ignorant
    of what you are talking about, and to stupid to understand your ignorance.

    This is what comes by speaking rote phrases that you never learned their meaning.

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