Saturday, November 13, 2021

Digest for comp.lang.c++@googlegroups.com - 13 updates in 5 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 13 10:24AM -0800

Juha Nieminen <nospam@thanks.invalid> writes:
 
[..wanting to solve the halting problem..]
 
> Pretty much every single unsolved mathematical hypothesis that can
> be expressed as a computer program could be solved just like that.
> [...] The Collatz conjecture? Solved. [...]
 
Can you explain what program would serve to provide a solution to
the Collatz conjecture?
olcott <NoOne@NoWhere.com>: Nov 13 12:34PM -0600

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
>> someone solved it, it would be the Holy Grail of mathematics?
>> Pretty much every single unsolved mathematical hypothesis that can
>> be expressed as a computer program could be solved just like that.
 
I do understand that is simply not the way it works.
If you want to continue discussing this reply to the follow-up group.
 
Flibble agrees that I am correct:
[Why has the argument with Olcott gone on for so long?]
On 11/13/2021 10:57 AM, Mr Flibble wrote:
 
--
Copyright 2021 Pete Olcott
 
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
Tim Woodall <news001@woodall.me.uk>: Nov 13 07:09PM

>> [...] The Collatz conjecture? Solved. [...]
 
> Can you explain what program would serve to provide a solution to
> the Collatz conjecture?
 
#include <halting.h>
 
auto collatzN = [](int i) {
while (i != 1) {
if (i&1) i = 3 * i + 1;
else i /= 2;
}
 
auto collatz = []() {
int n = 1;
while(1) {
if (!HALTS(collatzN(n)))
return n;
++n;
}
}
 
int main() {
if (HALTS(collatz())) {
std::cout << "conjecture is false." << std::endl;
std::cout << "finding smallest counterexample" << std::endl;
std::cout << collatz() << std::endl;
} else {
std::cout << "conjecture is true." << std::endl;
}
}
 
 
Obviously there are much more efficient ways of finding the smallest
counterexample if you have HALTS but I think this answers your question.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 13 12:48PM -0800


> Obviously there are much more efficient ways of finding the
> smallest counterexample if you have HALTS but I think this
> answers your question.
 
Nice formulation. The idea of nested calls to HALTS did not
occur to me. Also the idea of being able to call HALTS on
a particular function, rather than the program as a whole,
is a useful one, and not one I remember seeing before (at
least not so clearly).
 
A hearty round of applause and thank yous.
Richard Damon <Richard@Damon-Family.org>: Nov 13 04:04PM -0500

On 11/13/21 3:48 PM, Tim Rentsch wrote:
> is a useful one, and not one I remember seeing before (at
> least not so clearly).
 
> A hearty round of applause and thank yous.
 
The key is you call Halts on what could be A program (and each function,
when combined with HALTS is able to be a 'program')
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 13 01:49PM -0800


>> A hearty round of applause and thank yous.
 
> The key is you call Halts on what could be A program (and each
> function, when combined with HALTS is able to be a 'program')
 
Right. Obvious in retrospect. Now if I could just figure
out a way to get my foresight as good as my hindsight....
olcott <NoOne@NoWhere.com>: Nov 13 04:29PM -0600

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
 
> [..wanting to solve the halting problem..]
 
>> You do understand that if the halting problem were solvable, and
>> someone solved it,
 
Because I didn't see these last three words my reply was incorrect.
 
I am not trying to solve the halting problem merely show how this
simplest possible equivalent to the halting theorem counter-examples can
have its halt status correctly decided by H.
 
int H(ptr x, ptr y)
{
x(y); // direct execution of P(P)
return 1;
}
 
// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{
H(x, x);
}
 
int main(void)
{
H(P, P);
}
 
H simulates its input and as soon as its input calls H with the same
parameters that H was called with H aborts this simulation and returns 0
for not halting, infinite recursion detected. It took me 16,000 hours
since 2004 to get it this simple.
 
 
 
--
Copyright 2021 Pete Olcott
 
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 13 10:26AM -0800

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
 
[...]
 
> Ill formed program doesn't compile, and always causes a diagnostic.
 
The C++ standard identifies several sets of circumstances that
cause a program to be ill formed, but explicitly and specifically
do not require a diagnostic.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 13 10:27AM -0800

> When a program is ill-formed, that qualifies as a violation of a
> diagnosable rule, and as such, the standard imposes one requirement:
> that at least one diagnostic message be generated.(4.1p2).
 
The C++ standard identifies several sets of circumstances that
cause a program to be ill formed, but explicitly and specifically
do not require a diagnostic.
David Brown <david.brown@hesbynett.no>: Nov 13 09:36PM +0100

On 13/11/2021 19:26, Tim Rentsch wrote:
 
> The C++ standard identifies several sets of circumstances that
> cause a program to be ill formed, but explicitly and specifically
> do not require a diagnostic.
 
I think that breaking the "One definition rule" would count here. Are
there any others that you are thinking about?
Sam <sam@email-scan.com>: Nov 13 03:30PM -0500

I had to do the following to be able to use string views to poke at
unordered maps with strings for their keys.
 
I was expecting to simply be able to use std::hash<void>, but gcc 11.2 was
not happy. And I find no evidence of std::hash<void>'s existence on
cppreference.com.
 
So, does it exist but not documented, and not implemented in gcc, or is this
a rather glaring hole in the standard.
 
If I can have std::equal_to<void>, I see no reason not to have
std::hash<void>, instead of resorting to such hackery:
 
#include <unordered_map>
#include <string>
#include <string_view>
#include <utility>
#include <iostream>
 
struct transparent_hash {
 
template<typename T,
typename=std::void_t<decltype(
std::hash<std::remove_cvref_t<T>>{}(
std::declval<std::remove_cvref_t<T> &>()
))>>
auto operator()(T && t) const
{
std::hash<std::remove_cvref_t<T>> h;
 
return h(std::forward<T>(t));
}
 
typedef void is_transparent;
};
 
std::unordered_map<std::string, int,
transparent_hash,
std::equal_to<void>> lookup;
 
auto find(const std::string_view &f)
{
return lookup.find(f);
}
 
int main()
{
lookup[std::string{"a"}]=4;
 
if (find("a")->second == 4)
{
std::cout << "It works" << std::endl;
}
 
return 0;
}
olcott <NoOne@NoWhere.com>: Nov 13 11:45AM -0600

On 11/13/2021 10:57 AM, Mr Flibble wrote:
> of failing to recognize a category error is an argument that goes
> nowhere and never ends.
 
> /Flibble
 
Hence my new signature line:
 
--
Copyright 2021 Pete Olcott
 
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 13 08:20AM

On Thu, 2021-11-11, Paavo Helde wrote:
>>> number will be a '.'. The locale might change strtof() to assume
>>> it's ',' instead, and you'll get weird results (where the
>>> decimal part isn't parsed, and ends the parsing at the dot.)
 
There's also the difference between what the locale says and what
users really expect. Here in LC_NUMERIC=sv_SE, pi is officially
written 3,14:
 
% LC_NUMERIC=sv_SE printf "%f\n" 3.14159265
3,141593
 
But noone writes it that way when the context is computing or
engineering. It's not just programmers who expect to write 3.14 in
their programs: almost /anyone/ using a computer or even a pocket
calculator expect to see a dot.
 
I still feel the locale system, as designed, was a mistake. But it's
too late to do anything about it, except adding locale-less interfaces
like we see here.
 
...
> In practice one should use functions like strtof() for locale-specific
> things, and functions like from_chars() for fixed data formats. As an
> extra bonus, the latter often work significantly faster.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)