Saturday, November 21, 2020

Digest for comp.lang.c++@googlegroups.com - 9 updates in 3 topics

Bonita Montero <Bonita.Montero@gmail.com>: Nov 21 12:34PM +0100

I want an API to list the supproted locales of my implementation.
scott@slp53.sl.home (Scott Lurndal): Nov 21 03:41PM

>I want an API to list the supproted locales of my implementation.
 
And I want a million dollars. Neither of us are likely to get our wish
without working for it first.
Manfred <noname@add.invalid>: Nov 21 11:07PM +0100

On 11/20/2020 8:58 PM, James Kuyper wrote:
> "locale -a" corresponds to one of the 5 languages that I can read, and
> for which I've installed fonts. There are, for instance, 22 different
> locales for Spanish, which is how the total comes to 61.
 
On one of my systems locale -a gives 867 locales, but there's nothing in
/usr/share/i18n/locales/
 
On Linux file locations are rather 'fluid'.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 21 04:28AM -0800

> inconsistent.
 
> A proof that it doesn't halt would be the same as proving ZFC is
> consistent.
 
This doesn't surprise me. There are other such TMs for many open
questions in mathematics - if the TM halts then a counterexample
was found and the conjecture is false, or if the conjecture is
true then there is no counterexample to be found, and the TM will
run forever.
 
What do you think that implies, if anything, about my earlier
statement?
Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 21 12:43PM

> was found and the conjecture is false, or if the conjecture is
> true then there is no counterexample to be found, and the TM will
> run forever.
 
To me, the surprising thing is the size. And the size has come down.
Another 2 symbol TM with less than 800 states is known with the same
properties. Of course getting the size down is just a matter of
ingenuity, but it's still what we technically refer to as gob smacking.
 
> What do you think that implies, if anything, about my earlier
> statement?
 
Maybe the issue is what you mean by "[it] is always possible to answer
the question". Finite sets are decidable, but I would not have phrased
it as you did (assuming that is all you meant).
 
--
Ben.
Tim Woodall <news001@woodall.me.uk>: Nov 21 02:52PM

> run forever.
 
> What do you think that implies, if anything, about my earlier
> statement?
 
I'm responding to your claim:
>>> It
>>> is always possible to answer the question of halting for a single
>>> Turing Machine input, or indeed any finite collection of inputs.
 
I believe this to be false. I believe there are (relatively) small
turing machines for which the halting status is undecidable.
 
We already know that the question is undecidable in general, which
implies that there exists a TM whose halting status is undecidable in
particular. I'm contending that not only do such TM machines exist, but
that they're relatively small and some (whose halting status is
undecidable) are already known.
 
 
The consistency of ZFC cannot be proved from within ZFC. So any proof
that this (fairly small) TM doesn't halt on a ZFC inconsistency will
require a proof from outside the relm of computing if such a proof can
exist at all.
 
Even some relatively simple things - e.g. counting up to the value of
BB(8000) - must be impossible because we know that any <8k state TM
must halt in less than BB(8000) steps or run forever.
 
And yet it's trivial to construct a TM that given a unary number N on
its input tape writes N-1, N-2, N-3 ... 1 after it (each number
separated by a blank) and then terminates.
 
Therefore BB(8000) must be "unknowable"
Tim Woodall <news001@woodall.me.uk>: Nov 21 03:13PM

> its input tape writes N-1, N-2, N-3 ... 1 after it (each number
> separated by a blank) and then terminates.
 
> Therefore BB(8000) must be "unknowable"
 
That was a bit "confused".
 
The halting problem is for a machine with a blank tape. While the
"counting down" machine doesn't start with a blank tape. But the
argument shows that if you know BB(8000) you can count up to it but
being able to count up to it is the same as being able to decide the
halting status of a 8k state machine that starts with a blank tape. And
being able to decide the halting status of an 8k machine by just running
it for BB(8k) steps is inside ZFC.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 21 12:05AM

On 20/11/2020 18:11, olcott wrote:
> then Halts() has made a correct not-halting decision on this input.
 
> I just finished enough of the programming of my x86utm operating system so that it collects the actual execution trace of every line of user code that is executed. Of the 10,671 lines that are actually executed only 35 lines are relevant to the halt decider's halting decision. All of these lines are shown below.
 
> Anyone with a bachelors degree in computer science would understand that every Turing machine that has infinite recursion would never stop running. That I show exactly how to decide the previously undecidable input: (H_Hat shown below) proves that I have refuted all of the conventional halting problem proofs.
 
1) Infinite recursion isn't the only cause of non-halting behaviour;
2) If your solution is based on finite RAM and register state being repeated then you are not testing a UTM as your so-called "UTM" is not an arbitrary TM nor is it acting on arbitrary input.
 
Still nothing to see here.
 
/Flibble
 
--
¬
olcott <NoOne@NoWhere.com>: Nov 20 06:34PM -0600

On 11/20/2020 6:05 PM, Mr Flibble wrote:
>> input: (H_Hat shown below) proves that I have refuted all of the
>> conventional halting problem proofs.
 
> 1) Infinite recursion isn't the only cause of non-halting behaviour;
 
You are correct, yet in the case at hand H_Hat() would never halt unless
the halt decider stops simulating it.
 
> 2) If your solution is based on finite RAM and register state being
> repeated then you are not testing a UTM as your so-called "UTM" is not
> an arbitrary TM nor is it acting on arbitrary input.
 
x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
 
None-the-less the equivalence between computations under my x86utm
operating system and those of an actual UTM continues to exist for all
computations not requiring more memory than is available.
 
The conventional halting problem counter-example embodied by H_Hat() is
such a computation.
 
 
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: