On 4/22/25 6:19 PM, olcott wrote:

On 4/22/2025 4:58 PM, Andy Walker wrote:

On 22/04/2025 15:57, Mr Flibble wrote:

On Tue, 22 Apr 2025 15:43:27 +0100, Andy Walker wrote:

The "real" Mr Flibble is a malevolent penguin.  I wonder why
contributors take him so seriously?  If you want to debate with a
penguin, that's your prerogative, but to me it makes more sense to add >>>> several pinches of salt and smile or groan as appropriate to everything >>>> he writes.  He has a knack for writing things that are just about
plausible, which is enviable, but one response to anything interesting >>>> is surely enough?

Mr Flibble is very cross.

     He shouldn't be.  As hinted above, being able to write successful >> satire is a rare skill.  But it loses its point if too many people take
it seriously.

Flibble <is> factually correct.

All computation is defined to be represented as finite string
transformations to finite strings.

Except you are doing the logic backward.

This <is> how Turing Machine computable functions actually work.
Outputs are forced to correspond to inputs when finite string
transformation rules are applied to inputs to derive outputs.

And you need to know that the function *IS* computable to use that.

What the machine actually produces will be computable.

What the machine is SUPPOSED to produce might not be.

   a function is computable if there exists an algorithm
   that can do the job of the function, i.e. given an input
   of the function domain it can return the corresponding
   output. https://en.wikipedia.org/wiki/Computable_function

Which says if a machine exists, it is conputable.

The machine does not need to exist.

This seems to be a flaw in your logic, you seem to think there is a
Truth Faerie that can magically make the impossible happen.

On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.

Yes, so the results can only BE what is computable, but as pointed out,
the correct answer need not be.

People here stupidly assume that the outputs are not
required to correspond to the inputs. That comes from
learn-by-rote with zero depth of understanding.

The outputs DO need to correspond to the input, but not necessarily by a computable transform.

That only exists if the function is, in fact, computable.

Nearly all "random" functions will not be, by a simple counting
argument, There are more functions/mapping (Aleph-1) that can be asked
for than machines (Aleph-0) to do the mapping. Therefore only a
infintisimal fraction of all possible mappings are in fact computable.

Now, when we limit ourselves to mapping that have a use, it seems we
find a lot that do have a mapping, but not all.

There is no computation that can compute for *ALL* possible programs, if
that progran will halt when run. Turing proves that by showing for every possible decider that we might think can do it, that we can make a
program for it to decide on that it will get wrong.

Thus the mapping must be uncomputable.

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

On 4/23/25 12:14 AM, olcott wrote:

On 4/22/2025 9:33 PM, Richard Damon wrote:

On 4/22/25 6:19 PM, olcott wrote:

On 4/22/2025 4:58 PM, Andy Walker wrote:

On 22/04/2025 15:57, Mr Flibble wrote:

On Tue, 22 Apr 2025 15:43:27 +0100, Andy Walker wrote:

The "real" Mr Flibble is a malevolent penguin.  I wonder why
contributors take him so seriously?  If you want to debate with a >>>>>> penguin, that's your prerogative, but to me it makes more sense to >>>>>> add
several pinches of salt and smile or groan as appropriate to
everything
he writes.  He has a knack for writing things that are just about >>>>>> plausible, which is enviable, but one response to anything
interesting
is surely enough?

Mr Flibble is very cross.

     He shouldn't be.  As hinted above, being able to write successful
satire is a rare skill.  But it loses its point if too many people take >>>> it seriously.

Flibble <is> factually correct.

All computation is defined to be represented as finite string
transformations to finite strings.

Except you are doing the logic backward.

This <is> how Turing Machine computable functions actually work.
Outputs are forced to correspond to inputs when finite string
transformation rules are applied to inputs to derive outputs.

And you need to know that the function *IS* computable to use that.

What the machine actually produces will be computable.

What the machine is SUPPOSED to produce might not be.

    a function is computable if there exists an algorithm
    that can do the job of the function, i.e. given an input
    of the function domain it can return the corresponding
    output. https://en.wikipedia.org/wiki/Computable_function

Which says if a machine exists, it is conputable.

The machine does not need to exist.

This seems to be a flaw in your logic, you seem to think there is a
Truth Faerie that can magically make the impossible happen.

On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.

Yes, so the results can only BE what is computable, but as pointed
out, the correct answer need not be.

That would seem to indicate an error in the original
problem specification.

No, just in your understanding of it.

Whatever can be derived by applying finite string
transformation to input finite strings <is> computable.

No, and the problem is you don't actually understand the meaning of the
words you are using.

The point it that your phrase "Computations are finite string
transformations" is not a definition, but just a description. All
computations can be viewed as a finite string transformation, but not
all finite string transformations are computations. The name for a
process that maps finite strings to finite strings is a function, as a
function is basically a mapping of (possibly a countably infinite set)
strings to strings. Like in this case Descriptions of Turing Machines to
their Halting Status. This can be specified in several manners, it could
be specified by a finite algorithm (which makes it a computation), It
could be an unbounded algorithm (run the machine specified and see if it
ever halts) which by itself is NOT a computation (and thus doesn't make
it computable) but there might be a finite algorithm that creates it, or
it might just be an arbitrary mapping specified by an infinite number of
finite string to finite string mappings. Note, that last case creates an UNCOUNTABLE INFINITE number of mappings.

A Computable Function, is a function where there exists a (finite)
algorithm, that can produce each mapping in a finite number of steps.

Thus, not all "Functions" (which are the mappings) are by that
definition computable, as some can be defined by non-finite algorithms
or even be among the uncountable number of arbitrary mappings.

People here stupidly assume that the outputs are not
required to correspond to the inputs. That comes from
learn-by-rote with zero depth of understanding.

The outputs DO need to correspond to the input, but not necessarily by
a computable transform.

Yes necessarily by a computable transform.

Nope, see above. It can only DO a computable transform, but the problem
isn't limited to such, but can be ANY transform, even one that needs an unbounded process to perform.

That only exists if the function is, in fact, computable.

Uncomputable functions are an incoherent idea when
computable functions are defined by deriving outputs
by applying finite string transformations to input
finite strings.

Your mind is skipping over a term there. It is only a computable
function if there exists the ALGORITMM that computes it, and the
implications of that term in this context are finite description using
finite time. Not all string transformations can so be processed.

This seems to be a common problem for you, if you don't understand a
piece of something, you just ignore it but still think you know what it
means.

I guess this comes from your failure to understand things like Rules,
Reality, Truth, or Logic.

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

On 4/23/25 12:27 PM, olcott wrote:

On 4/23/2025 6:15 AM, Richard Damon wrote:

On 4/23/25 12:14 AM, olcott wrote:

On 4/22/2025 9:33 PM, Richard Damon wrote:

On 4/22/25 6:19 PM, olcott wrote:

On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.

Yes, so the results can only BE what is computable, but as pointed
out, the correct answer need not be.

That would seem to indicate an error in the original
problem specification.

No, just in your understanding of it.

Whatever can be derived by applying finite string
transformation to input finite strings <is> computable.

No, and the problem is you don't actually understand the meaning of
the words you are using.

The point it that your phrase "Computations are finite string
transformations" is not a definition, but just a description.

int sum(int x, int y) { return x + y; }

It does conclusively prove that HHH is not allowed
to report on the behavior of the direct execution
of DD for the same reason that sum(3,2) cannot report
on the sum of 4 + 3.

How?

That is the DEFINITION of the answer to the input requested.

Your HHH is loke:

int sum(int x, int y) { return x*y; }

Since it doesn't return about the halting behavor of its input.

Also, you ignore part of the input, thinking that DDD calls an HHH that
doesn't abort, when the HHH that it calls does abort

Thus, all you are doing is proving that you are just a stupid liar that
doesn't know what he is talking about.

The finite string transformations to the machine code
of DD according the definition of the x86 language
ALREADY SPECIFIES BEHAVIOR THE IS NOT THE BEHAVIOR
OF THE DIRECTLY EXECUTED DD.

But it *IS* the behavior of the directly executed DD, at least when you complete it to make it a progeram by including the code for the actual
HHH tha it calls.

Your DD that excludes the code for HHH as not part of the input just
doens't have behavior and is a category error.

Note, NOTHING in the definition of the X86 language says that a call to
a function at the address of HHH means to emulate the code at the
address given as a parameter.

Sorry, you are just showing your stupid ignorance of what you are
talking about.

The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.

The call to HHH(DD) from DD simulated by HHH doesn't return only do to
the failure of HHH to correctly emulate its input.

You can't blame DD on that failure of HHH.

All you are doing is proving your stupid ignorance of what you are
talking about.

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