On 8/8/2022 12:15 PM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>>> Why does the correctly simulated H(P,P) not similarly detect infinite
>>> recursion (inside the simulation) and return 0?
>>
>> Of the nested simulations the outermost one sees that the infinite
>> recursion criteria is met first.
>
> This seems to indicate your halting detector is reporting that
> H(P,P) did not halt, instead of reporting P(P) did not halt?
>

H itself halts. It is reporting that the correct simulation by H(P,P) of
its first argument would never reach the final state "return"
instruction of this simulated P and halt.

Example 05: P(P) halts because H(P,P) correctly determines that its
input never halts

This conclusively proves that H(P,P) correctly simulates its input and
that the behavior of the correctly simulated P is very different than
the directly executed P(P).

The correctly simulated P cannot possibly terminate normally by reaching
its own "return" instruction. The executed P does terminate normally and
reaches its own "return" instruction.

If you are not an expert in the x86 language then you lack the basis to
determine that the input to H(P,P) is not simulated correctly. The
strongest claim that you can make is that on the basis that you do not
understand the x86 language you do not understand the proof.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[0000143b](01) 55 push ebp
[0000143c](02) 8bec mov ebp,esp
[0000143e](01) 51 push ecx
[0000143f](03) 8b4508 mov eax,[ebp+08]
[00001442](01) 50 push eax
[00001443](03) 8b4d08 mov ecx,[ebp+08]
[00001446](01) 51 push ecx
[00001447](05) e8affcffff call 000010fb
[0000144c](03) 83c408 add esp,+08
[0000144f](03) 8945fc mov [ebp-04],eax
[00001452](04) 837dfc00 cmp dword [ebp-04],+00
[00001456](02) 7402 jz 0000145a
[00001458](02) ebfe jmp 00001458
[0000145a](02) 8be5 mov esp,ebp
[0000145c](01) 5d pop ebp
[0000145d](01) c3 ret
Size in bytes:(0035) [0000145d]

_main()
[0000146b](01) 55 push ebp
[0000146c](02) 8bec mov ebp,esp
[0000146e](05) 683b140000 push 0000143b
[00001473](05) e8c3ffffff call 0000143b
[00001478](03) 83c404 add esp,+04
[0000147b](02) 33c0 xor eax,eax
[0000147d](01) 5d pop ebp
[0000147e](01) c3 ret
Size in bytes:(0020) [0000147e]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000146b][00102428][00000000] 55 push ebp
[0000146c][00102428][00000000] 8bec mov ebp,esp
[0000146e][00102424][0000143b] 683b140000 push 0000143b // push P
[00001473][00102420][00001478] e8c3ffffff call 0000143b // call P
with argument on stack
[0000143b][0010241c][00102428] 55 push ebp // enter
executed P
[0000143c][0010241c][00102428] 8bec mov ebp,esp
[0000143e][00102418][00000000] 51 push ecx
[0000143f][00102418][00000000] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][00102414][0000143b] 50 push eax // push P
from eax
[00001443][00102414][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][00102410][0000143b] 51 push ecx // push P
from ecx
[00001447][0010240c][0000144c] e8affcffff call 000010fb // call
executed H with arguments on stack

H: Begin Simulation Execution Trace Stored at:1124d4
Address_of_H:10fb
[0000143b][001124c0][001124c4] 55 push ebp // enter
emulated P
[0000143c][001124c0][001124c4] 8bec mov ebp,esp
[0000143e][001124bc][00102490] 51 push ecx
[0000143f][001124bc][00102490] 8b4508 mov eax,[ebp+08] // load eax
with argument to P
[00001442][001124b8][0000143b] 50 push eax // push P
from eax
[00001443][001124b8][0000143b] 8b4d08 mov ecx,[ebp+08] // load ecx
with argument to P
[00001446][001124b4][0000143b] 51 push ecx // push P
from ecx
[00001447][001124b0][0000144c] e8affcffff call 000010fb // call
emulated H with arguments on stack
H: Infinitely Recursive Simulation Detected Simulation Stopped

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs its
“return” instruction and) terminate normally.
H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
When H sees that this otherwise infinitely
nested simulation would never end it aborts its simulation of P and
rejects P as non-halting.

[0000144c][00102418][00000000] 83c408 add esp,+08 //
return to executed P
[0000144f][00102418][00000000] 8945fc mov [ebp-04],eax // load
Halt_Status with return value
[00001452][00102418][00000000] 837dfc00 cmp dword [ebp-04],+00 // if
Halt_Status == 0
[00001456][00102418][00000000] 7402 jz 0000145a // goto
0000145a
[0000145a][0010241c][00102428] 8be5 mov esp,ebp
[0000145c][00102420][00001478] 5d pop ebp
[0000145d][00102424][0000143b] c3 ret //
return from executed P to main
[00001478][00102428][00000000] 83c404 add esp,+04
[0000147b][00102428][00000000] 33c0 xor eax,eax // set
eax to 0
[0000147d][0010242c][00000018] 5d pop ebp
[0000147e][00102430][00000000] c3 ret //
return from main to operating system
Number of Instructions Executed(998) == 15 Pages

The correctly simulated input to H(P,P) calls H(P,P) in infinite
recursion thus H never returns to P and P never reaches its own "return"
statement. The directly executed P(P) calls H(P,P) *not* in infinite
recursion thus H(P,P) returns to P.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Thursday, August 4, 2022 at 2:06:38 PM UTC-7, Jeff Barnett wrote:
> On 8/4/2022 2:28 AM, dklei...@gmail.com wrote:
> > On Wednesday, August 3, 2022 at 12:07:47 PM UTC-7, Jeff Barnett wrote:
> >> On 8/3/2022 3:05 AM, Malcolm McLean wrote:
> >>> On Wednesday, 3 August 2022 at 07:19:33 UTC+1, Jeff Barnett wrote:
> >>>> On 8/2/2022 12:17 PM, Mr Flibble wrote:
> >>>>> On Tue, 2 Aug 2022 11:54:34 -0600
> >>>> <SNIP>
> >>>>> You are wrong: I am extending the definition of what constitutes a
> >>>>> halt decider which is my right as both a computer scientist and a
> >>>>> software engineer.
> >>>> The only reasonable definition I ever heard for a "Software Engineer"
> >>>> was someone who cannot write code, doesn't do well with math, and has
> >>>> learned that telling others how to do technology is easier than making a
> >>>> fool of themself to make a living."
> >>>>
> >>> The economic problem was that software projects were delivered late and
> >>> over-budget, often abandoned, and when delivered they were full of bugs
> >>> which sometimes had a catastrophic impact on the customer.
> >>> So what to do about it? A quick analysis would have shown that the problem
> >>> wasn't that the programmers didn't know the programming language, or
> >>> even that their maths wasn't up to scratch.
> >>> The problem was rooted in management. What was much harder was defining
> >>> what strong management looked like. For a long time, most people thought
> >>> that the solution was to impose from the top down a "formal method". If
> >>> everyone adhered to the method, work would be delivered bug free, and on time.
> >>> When this gave disappointing results, the reason was that the formal method
> >>> wasn't adhered to strictly enough.
> >>> It was gradually realised that many successful projects were not build by teams
> >>> which followed these formal methods. Now the methods are much better. They
> >>> are less bureaucratic, they give more control to programmers or immediate
> >>> product managers wanting to add features quickly in response to a proposal or
> >>> request, the tolls for controlling changes to source code are much better, the
> >>> languages we use are higher-level.
> >>> We're still not there yet. Software is still notorious for being expensive to produce
> >>> and faulty. You still read of horror stories where many millions of pounds are
> >>> wasted.
> >>> But realising that the computer science side of the problem is usually the easy
> >>> part, and the integration, testing, and deployment the part that goes wrong, and
> >>> that it's not just about knocking out code but a much broader problem than that,
> >>> is what distinguishes "software engineering" from just "programming".
> >> A little history of SE, starting in the early days:
> >>
> >> By the early/middle 1950s the US Government had passionate interests in
> >> using computers to better their systems. Experience giving contracts to
> >> the military support community had been an expensive disaster in many
> >> instances. Problems: 1) lack of knowledge about what was easy and what
> >> was hard, 2) lack of understanding about how to form and map
> >> requirements into a system architecture, 3) lack of technical experience
> >> in the military support community, 4) lack of knowledge about how to
> >> write contracts for massive systems - who's really responsible for what
> >> and how to handle modifications of contracts that for system
> >> requirements that became obvious during system development, 5) ravenous
> >> desire for profits by the set of contractors available - their corporate
> >> goals and the government's were not close and the US ended up paying
> >> over and over again for contractor cock ups.
> >>
> >> At some point, the government approached RAND (the non profit with John
> >> von Neumann, Dick Bellman, Herb Simon, and many others there) and ask if
> >> RAND could sprout another division to experiment with and develop some
> >> needed defense systems. RAND had to decline for several reasons:
> >>
> >> 1) Their creation was controlled by an act of congress as a federally
> >> charted not for profit corporation and that charter included a hard cap
> >> on RAND's gross yearly income: $50M.
> >>
> >> 2) RAND had lines at their doors - cities, states, US agencies, non
> >> profits - wanting to buy their services and had money to pay.
> >>
> >> 3) Most RAND researchers picked the customers they wanted to work with
> >> and might leave if that wasn't possible. RAND employees never said they
> >> worked for RAND, rather the mantra was that RAND was their sponsor.
> >>
> >> The decision was made to create another federally chartered nonprofit,
> >> the System Development Corporation, down the street from RAND. There
> >> main business was research and developing military computer systems but
> >> they were also to do R&D in any/all computer related areas.
> >>
> >> The seeding of management and technical employees came from RAND and
> >> also included many human factors folks (HF). The first task at hand was
> >> to find people and turn them into programmers. Early on they tested,
> >> analyzed and guessed who would be good at it. The best discriminator
> >> found was a good old fashioned IQ test. It wasn't perfect but nothing
> >> else worked as well.
> >>
> >> SDC put employees wanted ads all over the place. The pitch was something
> >> like the following: "Take a test: If you pass you will be paid X to
> >> attend classes for 6 months. If you pass your class, you will be offered
> >> a job at a starting rate of Y. You will learn about exciting new
> >> technologies in a terrific environment, etc," I think X was something
> >> like $400+ a moth and Y was a few hundred more. Remember, this was in
> >> the late 1950s so this was good money. Using IQ test scores as the only
> >> criterion, a hell's angel and a prostitute were hired; a college
> >> professor was not.
> >>
> >> Since the programmers hired this way started leaking out to other places
> >> in the world, the reputation of computer folks as "strange dudes" was
> >> justified. And the above, in my opinion, was the reason for the skew in
> >> the inhabitants of our field. It was a MENSA collection that had 40
> >> hours a week parties. Not so today.
> >>
> >> SDC developed useful systems for the military as well as an
> >> understanding of requirements, change orders, and many mundane ideas
> >> about how to do the day by day business of system building.
> >>
> >> In the latish 1960s and 1970s, the idea of software engineering had
> >> sprouted and its leading voice was Dave Parnas. Parnas was very earnest
> >> but naive about software development. For example, he proffered a set of
> >> rules for good software that excluded the use of recursion by inference.
> >> He had never written a part of a compiler, device drivers, parallel
> >> process code, etc. His preferred rules were rigid and confrontations
> >> with solid counterexamples bounced off him with no mental penetration.
> >> One of the solid rules "was no GO forms". When asked, whether his SE
> >> rules would allow a form rewrite to produce a new form with a GO in it,
> >> he didn't think that was a good idea. Followup questions: How do you
> >> compile loops. Well you get the idea. Parnas was last seen arguing SE
> >> possibilities for the development of the Strategic Defense Initiative.
> >>
> >> Pretty soon, everyone was faking SE departments, (Why not, you could add
> >> the expense plus overhead and profit to your contracts.) SDC as well as
> >> other places were caught up in the idea. Most places decided that they
> >> couldn't afford to take good technical people and waste them in a make
> >> work organization. SE became a closet to stuff your failures in. We have
> >> had a continuous string of SE fad movements; new ones every few years.
> >> Aerospace and other defense contractors run classes for all their
> >> employees when each useless standard is released. Funny thing many years
> >> ago: some of us got together and were talking about this very subject.
> >> It turned out that at two different defense contractors these classes
> >> were being taught by employees that had been given their notices along
> >> with a few month optional extension if they would teach these god awful
> >> classes. I think at the time of this get together, ISO was promoting yet
> >> another standards fart.
> >>
> >> In the middle late 1970s, the US government decided 1) they now knew
> >> enough to write and manage large computer systems contracts and 2) that
> >> SDC as a federally charted non profit had an unfair advantage in seeking
> >> government business. Thus, SDC was ordered to make a plan to change. The
> >> way this was done was to create a nonprofit SDC foundation that held all
> >> the stock in the SDC company though some was granted to current
> >> employees as some sort of option. The nonprofit then put their stock up
> >> for sale. It was eventually bought by Burroughs Corporation who was
> >> later absorbed by Unisys. The SDC foundation still exists. It makes
> >> research grants and supports various interesting CS related activities.
> >>
> >> This was too long. However, my attitude in re SE was brewed over many
> >> decades. We are now in an era where most products are developed and sold
> >> without a detailed description of what the product does. Therefore, our
> >> software has no errors since there is no statement of what it should do.
> >> Is that a victory for SE? I wonder.
> >>
> > Thank You for the valuable history.
> >
> > I lived through that era and saw the same thing. Mostly I worked for General
> > Electric on one or more of their defense projects but I was marginally
> > involved with GE's attempt to become the dominant computer service
> > provider. Hiring competent programmers was a problem. GE started,
> > I think, with the nuclear-powered airplane project (before my time) which
> > was, unsurprisingly, a early bust.
> >
> > The introduction of FORTRAN was a crucial point. IBM had taught a set
> > of principles where an analyst studied a problem and wrote a set of flow
> > diagram for the solution then passed this on to a coding drudge for
> > actual code. FOTRAN destroyed this idea. The engineers had to learn
> > to write their own code. You can imagine the bad code that resulted.
> > So the coders were elevated to programmers and saved the day.
> >
> > It's been decades since I wrote any serious code. I was quite good
> > at it even if I never had "programmer" as a job title. No management
> > could face the notion of a programmer with a doctorate. So I had a
> > career in management. And I agree with everybody else - good
> > programmers are rare and should be treasured.
> Thanks for the information. To continue your last point, I'll add
> another SDC story. The hero of the story was Hal Sackman; Note, my
> spelling of his name might be off. He was one of those HF guys, with a
> PhD, and he did a lot of experimental stuff. We had one of the earliest
> timing sharing systems (MIT's project MAC' system beat ours by a month
> or so). When things were working very reliably, he decided to do an
> experiment to see if time sharing was "better" than batch for code
> development. Being a non profit, he could get his hands on tons of
> people with various levels of experience, education, etc., and it didn't
> cost his effort a dime.
>
> He made up two different program task classes: Class one was quick and
> dirty one day efforts but needed some insights. Class two problems took
> several days and needed some design work and tradeoff study. Each
> subject got one task in each class (one after the other) and was told
> which environment to use for a task. Class, order,and system (8
> possibilities) where randomized. I believe he graded on number of
> errors, time to finish, efficiency, etc.
>
> He published his results and concluded that time sharing was marginally
> a better development environment that batch.
>
> Another result, an elephant in the room, he did not draw and publish
> from the data because people wouldn't belief it, was as follows:
>
I was managing a team of programmers back then and it was part of the
folklore back then that good programmers could be twenty times better
than the drudges. But any kind of programmer was hard to find so we got
along with what we hade. Personally I eased out the incompetents as fast
as I could.

On 8/8/22 1:48 PM, olcott wrote:
> On 8/8/2022 12:15 PM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>>>> Why does the correctly simulated H(P,P) not similarly detect infinite
>>>> recursion (inside the simulation) and return 0?
>>>
>>> Of the nested simulations the outermost one sees that the infinite
>>> recursion criteria is met first.
>>
>> This seems to indicate your halting detector is reporting that
>> H(P,P) did not halt, instead of reporting P(P) did not halt?
>>
>
> H itself halts. It is reporting that the correct simulation by H(P,P) of
> its first argument would never reach the final state "return"
> instruction of this simulated P and halt.

And is WRONG, because P(P) Halt, and the input to H(P,P) MUST represent
P(P) or your P isn't the required program, so you whole example is wrong.

>
> Example 05:     P(P) halts because H(P,P) correctly determines that its
> input never halts

Which is just showing you are talking out of your arse and your logic is
inconsistent.

>
> This conclusively proves that H(P,P) correctly simulates its input and
> that the behavior of the correctly simulated P is very different than
> the directly executed P(P).

Then H and P aren't the required machine for the Halting Problem.

>
> The correctly simulated P cannot possibly terminate normally by reaching
> its own "return" instruction. The executed P does terminate normally and
> reaches its own "return" instruction.

No, it can, because your H aborts its simulation. That means that a
correct and complete simulation of the input to H (but not by H, but by
a real UTM) can continue and see the Halting state.

The aborted simulation proves NOTHING.

>
> If you are not an expert in the x86 language then you lack the basis to
> determine that the input to H(P,P) is not simulated correctly. The
> strongest claim that you can make is that on the basis that you do not
> understand the x86 language you do not understand the proof.

And you simulation is INCORRECT because it doesn't properly simulate the
call to H instruction, and the results thereafter.

The REAL and CORRECT simulation that would see H(P,P) eventually
returning 0,

H "simulates" that as never returning, which isn't the same as returning
0, and so is incorrect.

>
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [0000143b](01)  55             push ebp
> [0000143c](02)  8bec           mov ebp,esp
> [0000143e](01)  51             push ecx
> [0000143f](03)  8b4508         mov eax,[ebp+08]
> [00001442](01)  50             push eax
> [00001443](03)  8b4d08         mov ecx,[ebp+08]
> [00001446](01)  51             push ecx
> [00001447](05)  e8affcffff     call 000010fb
> [0000144c](03)  83c408         add esp,+08
> [0000144f](03)  8945fc         mov [ebp-04],eax
> [00001452](04)  837dfc00       cmp dword [ebp-04],+00
> [00001456](02)  7402           jz 0000145a
> [00001458](02)  ebfe           jmp 00001458
> [0000145a](02)  8be5           mov esp,ebp
> [0000145c](01)  5d             pop ebp
> [0000145d](01)  c3             ret
> Size in bytes:(0035) [0000145d]
>
> _main()
> [0000146b](01)  55             push ebp
> [0000146c](02)  8bec           mov ebp,esp
> [0000146e](05)  683b140000     push 0000143b
> [00001473](05)  e8c3ffffff     call 0000143b
> [00001478](03)  83c404         add esp,+04
> [0000147b](02)  33c0           xor eax,eax
> [0000147d](01)  5d             pop ebp
> [0000147e](01)  c3             ret
> Size in bytes:(0020) [0000147e]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [0000146b][00102428][00000000] 55         push ebp
> [0000146c][00102428][00000000] 8bec       mov ebp,esp
> [0000146e][00102424][0000143b] 683b140000 push 0000143b    // push P
> [00001473][00102420][00001478] e8c3ffffff call 0000143b    // call P
> with argument on stack
> [0000143b][0010241c][00102428] 55         push ebp         // enter
> executed P
> [0000143c][0010241c][00102428] 8bec       mov ebp,esp
> [0000143e][00102418][00000000] 51         push ecx
> [0000143f][00102418][00000000] 8b4508     mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][00102414][0000143b] 50         push eax         // push P
> from eax
> [00001443][00102414][0000143b] 8b4d08     mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][00102410][0000143b] 51         push ecx         // push P
> from ecx
> [00001447][0010240c][0000144c] e8affcffff call 000010fb    // call
> executed H with arguments on stack

And here the simulaton is not really accurate, as it REALLY needs to be
showing the code to H. This shows that your whole 'simulator' is broken.
>
> H: Begin Simulation   Execution Trace Stored at:1124d4
> Address_of_H:10fb
> [0000143b][001124c0][001124c4] 55         push ebp         // enter
> emulated P
> [0000143c][001124c0][001124c4] 8bec       mov ebp,esp
> [0000143e][001124bc][00102490] 51         push ecx
> [0000143f][001124bc][00102490] 8b4508     mov eax,[ebp+08] // load eax
> with argument to P
> [00001442][001124b8][0000143b] 50         push eax         // push P
> from eax
> [00001443][001124b8][0000143b] 8b4d08     mov ecx,[ebp+08] // load ecx
> with argument to P
> [00001446][001124b4][0000143b] 51         push ecx         // push P
> from ecx
> [00001447][001124b0][0000144c] e8affcffff call 000010fb    // call
> emulated H with arguments on stack
> H: Infinitely Recursive Simulation Detected Simulation Stopped

And H is wrong right here, as shown below, H(P,P) will return 0, and
thus doesn't indicate Infinitely Recursive Simulation.

FAIL.

>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

And (3) is just WRONG, ajnd show you are a pathological liar, or an IDIOT.

>
> The above shows that the simulated P cannot possibly (reachs its
> “return” instruction and) terminate normally.
> H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
> When H sees that this otherwise infinitely
> nested simulation would never end it aborts its simulation of P and
> rejects P as non-halting.

"otherwise infinitely nested" is NOT infinitely nest.

That is the source of your error.

You are just WRONG here, and the fact you use different definitions than
requried just proves that you are talking about POOP and not Halting.

>
> [0000144c][00102418][00000000] 83c408     add esp,+08            //
> return to executed P
> [0000144f][00102418][00000000] 8945fc     mov [ebp-04],eax       // load
> Halt_Status with return value
> [00001452][00102418][00000000] 837dfc00   cmp dword [ebp-04],+00 // if
> Halt_Status == 0
> [00001456][00102418][00000000] 7402       jz 0000145a            // goto
> 0000145a
> [0000145a][0010241c][00102428] 8be5       mov esp,ebp
> [0000145c][00102420][00001478] 5d         pop ebp
> [0000145d][00102424][0000143b] c3         ret                    //
> return from executed P to main
> [00001478][00102428][00000000] 83c404     add esp,+04
> [0000147b][00102428][00000000] 33c0       xor eax,eax            // set
> eax to 0
> [0000147d][0010242c][00000018] 5d         pop ebp
> [0000147e][00102430][00000000] c3         ret                    //
> return from main to operating system
> Number of Instructions Executed(998) == 15 Pages
>
> The correctly simulated input to H(P,P) calls H(P,P) in infinite
> recursion thus H never returns to P and P never reaches its own "return"
> statement. The directly executed P(P) calls H(P,P) *not* in infinite
> recursion thus H(P,P) returns to P.
>
>
>

On 8/8/2022 1:30 PM, dklei...@gmail.com wrote:
> On Thursday, August 4, 2022 at 2:06:38 PM UTC-7, Jeff Barnett wrote:
>> On 8/4/2022 2:28 AM, dklei...@gmail.com wrote:
>>> On Wednesday, August 3, 2022 at 12:07:47 PM UTC-7, Jeff Barnett wrote:
>>>> On 8/3/2022 3:05 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 3 August 2022 at 07:19:33 UTC+1, Jeff Barnett wrote:
>>>>>> On 8/2/2022 12:17 PM, Mr Flibble wrote:
>>>>>>> On Tue, 2 Aug 2022 11:54:34 -0600
>>>>>> <SNIP>
>>>>>>> You are wrong: I am extending the definition of what constitutes a
>>>>>>> halt decider which is my right as both a computer scientist and a
>>>>>>> software engineer.
>>>>>> The only reasonable definition I ever heard for a "Software Engineer"
>>>>>> was someone who cannot write code, doesn't do well with math, and has
>>>>>> learned that telling others how to do technology is easier than making a
>>>>>> fool of themself to make a living."
>>>>>>
>>>>> The economic problem was that software projects were delivered late and
>>>>> over-budget, often abandoned, and when delivered they were full of bugs
>>>>> which sometimes had a catastrophic impact on the customer.
>>>>> So what to do about it? A quick analysis would have shown that the problem
>>>>> wasn't that the programmers didn't know the programming language, or
>>>>> even that their maths wasn't up to scratch.
>>>>> The problem was rooted in management. What was much harder was defining
>>>>> what strong management looked like. For a long time, most people thought
>>>>> that the solution was to impose from the top down a "formal method". If
>>>>> everyone adhered to the method, work would be delivered bug free, and on time.
>>>>> When this gave disappointing results, the reason was that the formal method
>>>>> wasn't adhered to strictly enough.
>>>>> It was gradually realised that many successful projects were not build by teams
>>>>> which followed these formal methods. Now the methods are much better. They
>>>>> are less bureaucratic, they give more control to programmers or immediate
>>>>> product managers wanting to add features quickly in response to a proposal or
>>>>> request, the tolls for controlling changes to source code are much better, the
>>>>> languages we use are higher-level.
>>>>> We're still not there yet. Software is still notorious for being expensive to produce
>>>>> and faulty. You still read of horror stories where many millions of pounds are
>>>>> wasted.
>>>>> But realising that the computer science side of the problem is usually the easy
>>>>> part, and the integration, testing, and deployment the part that goes wrong, and
>>>>> that it's not just about knocking out code but a much broader problem than that,
>>>>> is what distinguishes "software engineering" from just "programming".
>>>> A little history of SE, starting in the early days:
>>>>
>>>> By the early/middle 1950s the US Government had passionate interests in
>>>> using computers to better their systems. Experience giving contracts to
>>>> the military support community had been an expensive disaster in many
>>>> instances. Problems: 1) lack of knowledge about what was easy and what
>>>> was hard, 2) lack of understanding about how to form and map
>>>> requirements into a system architecture, 3) lack of technical experience
>>>> in the military support community, 4) lack of knowledge about how to
>>>> write contracts for massive systems - who's really responsible for what
>>>> and how to handle modifications of contracts that for system
>>>> requirements that became obvious during system development, 5) ravenous
>>>> desire for profits by the set of contractors available - their corporate
>>>> goals and the government's were not close and the US ended up paying
>>>> over and over again for contractor cock ups.
>>>>
>>>> At some point, the government approached RAND (the non profit with John
>>>> von Neumann, Dick Bellman, Herb Simon, and many others there) and ask if
>>>> RAND could sprout another division to experiment with and develop some
>>>> needed defense systems. RAND had to decline for several reasons:
>>>>
>>>> 1) Their creation was controlled by an act of congress as a federally
>>>> charted not for profit corporation and that charter included a hard cap
>>>> on RAND's gross yearly income: $50M.
>>>>
>>>> 2) RAND had lines at their doors - cities, states, US agencies, non
>>>> profits - wanting to buy their services and had money to pay.
>>>>
>>>> 3) Most RAND researchers picked the customers they wanted to work with
>>>> and might leave if that wasn't possible. RAND employees never said they
>>>> worked for RAND, rather the mantra was that RAND was their sponsor.
>>>>
>>>> The decision was made to create another federally chartered nonprofit,
>>>> the System Development Corporation, down the street from RAND. There
>>>> main business was research and developing military computer systems but
>>>> they were also to do R&D in any/all computer related areas.
>>>>
>>>> The seeding of management and technical employees came from RAND and
>>>> also included many human factors folks (HF). The first task at hand was
>>>> to find people and turn them into programmers. Early on they tested,
>>>> analyzed and guessed who would be good at it. The best discriminator
>>>> found was a good old fashioned IQ test. It wasn't perfect but nothing
>>>> else worked as well.
>>>>
>>>> SDC put employees wanted ads all over the place. The pitch was something
>>>> like the following: "Take a test: If you pass you will be paid X to
>>>> attend classes for 6 months. If you pass your class, you will be offered
>>>> a job at a starting rate of Y. You will learn about exciting new
>>>> technologies in a terrific environment, etc," I think X was something
>>>> like $400+ a moth and Y was a few hundred more. Remember, this was in
>>>> the late 1950s so this was good money. Using IQ test scores as the only
>>>> criterion, a hell's angel and a prostitute were hired; a college
>>>> professor was not.
>>>>
>>>> Since the programmers hired this way started leaking out to other places
>>>> in the world, the reputation of computer folks as "strange dudes" was
>>>> justified. And the above, in my opinion, was the reason for the skew in
>>>> the inhabitants of our field. It was a MENSA collection that had 40
>>>> hours a week parties. Not so today.
>>>>
>>>> SDC developed useful systems for the military as well as an
>>>> understanding of requirements, change orders, and many mundane ideas
>>>> about how to do the day by day business of system building.
>>>>
>>>> In the latish 1960s and 1970s, the idea of software engineering had
>>>> sprouted and its leading voice was Dave Parnas. Parnas was very earnest
>>>> but naive about software development. For example, he proffered a set of
>>>> rules for good software that excluded the use of recursion by inference.
>>>> He had never written a part of a compiler, device drivers, parallel
>>>> process code, etc. His preferred rules were rigid and confrontations
>>>> with solid counterexamples bounced off him with no mental penetration.
>>>> One of the solid rules "was no GO forms". When asked, whether his SE
>>>> rules would allow a form rewrite to produce a new form with a GO in it,
>>>> he didn't think that was a good idea. Followup questions: How do you
>>>> compile loops. Well you get the idea. Parnas was last seen arguing SE
>>>> possibilities for the development of the Strategic Defense Initiative.
>>>>
>>>> Pretty soon, everyone was faking SE departments, (Why not, you could add
>>>> the expense plus overhead and profit to your contracts.) SDC as well as
>>>> other places were caught up in the idea. Most places decided that they
>>>> couldn't afford to take good technical people and waste them in a make
>>>> work organization. SE became a closet to stuff your failures in. We have
>>>> had a continuous string of SE fad movements; new ones every few years.
>>>> Aerospace and other defense contractors run classes for all their
>>>> employees when each useless standard is released. Funny thing many years
>>>> ago: some of us got together and were talking about this very subject.
>>>> It turned out that at two different defense contractors these classes
>>>> were being taught by employees that had been given their notices along
>>>> with a few month optional extension if they would teach these god awful
>>>> classes. I think at the time of this get together, ISO was promoting yet
>>>> another standards fart.
>>>>
>>>> In the middle late 1970s, the US government decided 1) they now knew
>>>> enough to write and manage large computer systems contracts and 2) that
>>>> SDC as a federally charted non profit had an unfair advantage in seeking
>>>> government business. Thus, SDC was ordered to make a plan to change. The
>>>> way this was done was to create a nonprofit SDC foundation that held all
>>>> the stock in the SDC company though some was granted to current
>>>> employees as some sort of option. The nonprofit then put their stock up
>>>> for sale. It was eventually bought by Burroughs Corporation who was
>>>> later absorbed by Unisys. The SDC foundation still exists. It makes
>>>> research grants and supports various interesting CS related activities.
>>>>
>>>> This was too long. However, my attitude in re SE was brewed over many
>>>> decades. We are now in an era where most products are developed and sold
>>>> without a detailed description of what the product does. Therefore, our
>>>> software has no errors since there is no statement of what it should do.
>>>> Is that a victory for SE? I wonder.
>>>>
>>> Thank You for the valuable history.
>>>
>>> I lived through that era and saw the same thing. Mostly I worked for General
>>> Electric on one or more of their defense projects but I was marginally
>>> involved with GE's attempt to become the dominant computer service
>>> provider. Hiring competent programmers was a problem. GE started,
>>> I think, with the nuclear-powered airplane project (before my time) which
>>> was, unsurprisingly, a early bust.
>>>
>>> The introduction of FORTRAN was a crucial point. IBM had taught a set
>>> of principles where an analyst studied a problem and wrote a set of flow
>>> diagram for the solution then passed this on to a coding drudge for
>>> actual code. FOTRAN destroyed this idea. The engineers had to learn
>>> to write their own code. You can imagine the bad code that resulted.
>>> So the coders were elevated to programmers and saved the day.
>>>
>>> It's been decades since I wrote any serious code. I was quite good
>>> at it even if I never had "programmer" as a job title. No management
>>> could face the notion of a programmer with a doctorate. So I had a
>>> career in management. And I agree with everybody else - good
>>> programmers are rare and should be treasured.
>> Thanks for the information. To continue your last point, I'll add
>> another SDC story. The hero of the story was Hal Sackman; Note, my
>> spelling of his name might be off. He was one of those HF guys, with a
>> PhD, and he did a lot of experimental stuff. We had one of the earliest
>> timing sharing systems (MIT's project MAC' system beat ours by a month
>> or so). When things were working very reliably, he decided to do an
>> experiment to see if time sharing was "better" than batch for code
>> development. Being a non profit, he could get his hands on tons of
>> people with various levels of experience, education, etc., and it didn't
>> cost his effort a dime.
>>
>> He made up two different program task classes: Class one was quick and
>> dirty one day efforts but needed some insights. Class two problems took
>> several days and needed some design work and tradeoff study. Each
>> subject got one task in each class (one after the other) and was told
>> which environment to use for a task. Class, order,and system (8
>> possibilities) where randomized. I believe he graded on number of
>> errors, time to finish, efficiency, etc.
>>
>> He published his results and concluded that time sharing was marginally
>> a better development environment that batch.
>>
>> Another result, an elephant in the room, he did not draw and publish
>> from the data because people wouldn't belief it, was as follows:
>>
> I was managing a team of programmers back then and it was part of the
> folklore back then that good programmers could be twenty times better
> than the drudges. But any kind of programmer was hard to find so we got
> along with what we hade. Personally I eased out the incompetents as fast
> as I could.
>
> The history of GE commercial time-sharing is mostly forgotten these days
> but it did happen.
>>
>> The performance for some programmers (normalized for education, time on
>> the job, and all the others of these sorts of metrics) were
>> better/faster at a ratio of 50 to 1 and their programs had hugely less
>> bugs. In no other technical profession did you see this sort of
>> interpersonal difference. Note that, for example, mathematicians and
>> physicists with these performance differences were not found in the same
>> work pool. Once you notice and accept this result, you come to the issue
>> of fair pay. Even if you pay proportional to the square root of the
>> difference, you would have your best programmers making more than Vice
>> Presidents in large aerospace companies.
>>
>> One of the pleasures of working at SDC, was meeting people like Sackman
>> and getting their stories from a decade before I was involved.
>
> As far as I know, practical time-sharing started with a term project at Dartmouth
> which Dartmouth sold to General Electric. We had to re-implement it because
> the students were not exactly the best programmers. I wrote the syntax part
> of the BASIC compiler. I don't think GE made any money from this first
> commercial time-sharing system but the second version may have. I didn't
> even stay with the first version.

On 8/8/2022 1:30 PM, dklei...@gmail.com wrote:

<SNIP>

> As far as I know, practical time-sharing started with a term project at Dartmouth
> which Dartmouth sold to General Electric. We had to re-implement it because
> the students were not exactly the best programmers. I wrote the syntax part
> of the BASIC compiler. I don't think GE made any money from this first
> commercial time-sharing system but the second version may have. I didn't
> even stay with the first version.

The above paragraph tickled an old memory. I may have some of this
confused but see if any of this cause a vibration in your head. I
believe there was a fellow named Dick Gellman(sp?) who implemented
Dartmouth FORTRAN and I think Basic too. We worked together the first
half of the 1970s at SDC. He was very good at mathematics and
programming. He also implemented the following hack in the FORTRAN at
Dartmouth:

Declare format integer array(20), 5x integer
10 Format(7x)=(16+1)

I've forgot most of FORTRAN, but the above is supposed to define format
as an integer array of 20 elements. Statement 10 is a format statement
where the six characters following the "7x", i.e., ")=(16+1", are
printed. However, statement 10 is an assignment of the 5x'th element of
the format array to 17 too! In Dick's FORTRAN, if control arrived at
statement 10, the assignment was executed; if statement 10 was
referenced from a print statement, it was used as a format. I believe
that Dick contacted some of the FORTRAN specifiers (at IBM?) and asked
what was supposed to happen; nobody knew so he did both.

I'm not sure whether this is a story more about Dick or about the god
awful state of FORTRAN specification in the 1960s.
--
Jeff Barnett

olcott <NoOne@NoWhere.com> wrote:

> On 8/8/2022 12:15 PM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>>>> Why does the correctly simulated H(P,P) not similarly detect infinite
>>>> recursion (inside the simulation) and return 0?
>>> Of the nested simulations the outermost one sees that the infinite
>>> recursion criteria is met first.
>> This seems to indicate your halting detector is reporting that
>> H(P,P) did not halt, instead of reporting P(P) did not halt?
>
> H itself halts. It is reporting that the correct simulation by H(P,P)
> of its first argument would never reach the final state "return"
> instruction of this simulated P and halt.

Unfortunately your software seems to depend so heavily on your compiler
environment (doesn't work correctly under Linux/gcc) that I am unable to
conduct tests on my own.

What is the result of H(P,P) with the following definition of P?

----

void P(ptr x) {
int Halt_Status = H(x, x);
return;
}

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

On 8/9/2022 7:27 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/8/2022 12:15 PM, Otto J. Makela wrote:
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>>>>> Why does the correctly simulated H(P,P) not similarly detect infinite
>>>>> recursion (inside the simulation) and return 0?
>>>> Of the nested simulations the outermost one sees that the infinite
>>>> recursion criteria is met first.
>>> This seems to indicate your halting detector is reporting that
>>> H(P,P) did not halt, instead of reporting P(P) did not halt?
>>
>> H itself halts. It is reporting that the correct simulation by H(P,P)
>> of its first argument would never reach the final state "return"
>> instruction of this simulated P and halt.
>
> Unfortunately your software seems to depend so heavily on your compiler
> environment (doesn't work correctly under Linux/gcc) that I am unable to
> conduct tests on my own.
>

The system used to compile under UBUNTU 16.04 gcc.
I am working on fixing this as my first priority.

Halt7.c must be compiled under Microsoft C to get a COFF object file.
This may make that unnecessary:
../objconv -fcoff Halt7.o Halt7.ooo

> What is the result of H(P,P) with the following definition of P?
>

Same result as detailed below. This version of H detects what is
essentially infinite recursion with itself as the first call of this
recursive sequence.

The earlier version is easier to understand, yet requires communication
through the levels of recursive simulation using static local memory in
the outermost level.

> ----
>
> void P(ptr x) {
> int Halt_Status = H(x, x);
> return;
> }
>

void P(ptr x) {
int Halt_Status = H(x, x);
return;
}

int main()
{ Output((char*)"Input_Halts = ", H(P, P));
}

_P()
[00000da6](01) 55 push ebp
[00000da7](02) 8bec mov ebp,esp
[00000da9](01) 51 push ecx
[00000daa](03) 8b4508 mov eax,[ebp+08]
[00000dad](01) 50 push eax
[00000dae](03) 8b4d08 mov ecx,[ebp+08]
[00000db1](01) 51 push ecx
[00000db2](05) e85ffeffff call 00000c16
[00000db7](03) 83c408 add esp,+08
[00000dba](03) 8945fc mov [ebp-04],eax
[00000dbd](02) 8be5 mov esp,ebp
[00000dbf](01) 5d pop ebp
[00000dc0](01) c3 ret
Size in bytes:(0027) [00000dc0]

_main()
[00000dc6](01) 55 push ebp
[00000dc7](02) 8bec mov ebp,esp
[00000dc9](05) 68a60d0000 push 00000da6
[00000dce](05) 68a60d0000 push 00000da6
[00000dd3](05) e83efeffff call 00000c16
[00000dd8](03) 83c408 add esp,+08
[00000ddb](01) 50 push eax
[00000ddc](05) 68d7030000 push 000003d7
[00000de1](05) e810f6ffff call 000003f6
[00000de6](03) 83c408 add esp,+08
[00000de9](02) 33c0 xor eax,eax
[00000deb](01) 5d pop ebp
[00000dec](01) c3 ret
Size in bytes:(0039) [00000dec]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000dc6][0010167d][00000000] 55 push ebp
[00000dc7][0010167d][00000000] 8bec mov ebp,esp
[00000dc9][00101679][00000da6] 68a60d0000 push 00000da6
[00000dce][00101675][00000da6] 68a60d0000 push 00000da6
[00000dd3][00101671][00000dd8] e83efeffff call 00000c16

H: Begin Simulation Execution Trace Stored at:111729
Address_of_H:c16
[00000da6][00111715][00111719] 55 push ebp
[00000da7][00111715][00111719] 8bec mov ebp,esp
[00000da9][00111711][001016e5] 51 push ecx
[00000daa][00111711][001016e5] 8b4508 mov eax,[ebp+08]
[00000dad][0011170d][00000da6] 50 push eax
[00000dae][0011170d][00000da6] 8b4d08 mov ecx,[ebp+08]
[00000db1][00111709][00000da6] 51 push ecx
[00000db2][00111705][00000db7] e85ffeffff call 00000c16
H: Infinitely Recursive Simulation Detected Simulation Stopped

[00000dd8][0010167d][00000000] 83c408 add esp,+08
[00000ddb][00101679][00000000] 50 push eax
[00000ddc][00101675][000003d7] 68d7030000 push 000003d7
[00000de1][00101675][000003d7] e810f6ffff call 000003f6
Input_Halts = 0
[00000de6][0010167d][00000000] 83c408 add esp,+08
[00000de9][0010167d][00000000] 33c0 xor eax,eax
[00000deb][00101681][00000018] 5d pop ebp
[00000dec][00101685][00000000] c3 ret
Number of Instructions Executed(978) == 15 Pages

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Tuesday, August 9, 2022 at 9:48:03 AM UTC-4, olcott wrote:
> On 8/9/2022 7:27 AM, Otto J. Makela wrote:
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 8/8/2022 12:15 PM, Otto J. Makela wrote:
> >>> olcott <No...@NoWhere.com> wrote:
> >>>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
> >>>>> Why does the correctly simulated H(P,P) not similarly detect infinite
> >>>>> recursion (inside the simulation) and return 0?
> >>>> Of the nested simulations the outermost one sees that the infinite
> >>>> recursion criteria is met first.
> >>> This seems to indicate your halting detector is reporting that
> >>> H(P,P) did not halt, instead of reporting P(P) did not halt?
> >>
> >> H itself halts. It is reporting that the correct simulation by H(P,P)
> >> of its first argument would never reach the final state "return"
> >> instruction of this simulated P and halt.
> >
> > Unfortunately your software seems to depend so heavily on your compiler
> > environment (doesn't work correctly under Linux/gcc) that I am unable to
> > conduct tests on my own.
> >
> The system used to compile under UBUNTU 16.04 gcc.
> I am working on fixing this as my first priority.
>
> Halt7.c must be compiled under Microsoft C to get a COFF object file.
> This may make that unnecessary:
> ./objconv -fcoff Halt7.o Halt7.ooo
> > What is the result of H(P,P) with the following definition of P?
> >
> Same result as detailed below. This version of H detects what is
> essentially infinite recursion with itself as the first call of this
> recursive sequence.

Which is the wrong result as H is not mapping the halting function as it is required to do if it claims to be a halt decider:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

>
> The earlier version is easier to understand, yet requires communication
> through the levels of recursive simulation using static local memory in
> the outermost level.
> > ----
> >
> > void P(ptr x) {
> > int Halt_Status = H(x, x);
> > return;
> > }
> >
>
> void P(ptr x) {
> int Halt_Status = H(x, x);
> return;
> }
> int main()
> {
> Output((char*)"Input_Halts = ", H(P, P));
> }
>
> _P()
> [00000da6](01) 55 push ebp
> [00000da7](02) 8bec mov ebp,esp
> [00000da9](01) 51 push ecx
> [00000daa](03) 8b4508 mov eax,[ebp+08]
> [00000dad](01) 50 push eax
> [00000dae](03) 8b4d08 mov ecx,[ebp+08]
> [00000db1](01) 51 push ecx
> [00000db2](05) e85ffeffff call 00000c16
> [00000db7](03) 83c408 add esp,+08
> [00000dba](03) 8945fc mov [ebp-04],eax
> [00000dbd](02) 8be5 mov esp,ebp
> [00000dbf](01) 5d pop ebp
> [00000dc0](01) c3 ret
> Size in bytes:(0027) [00000dc0]
>
> _main()
> [00000dc6](01) 55 push ebp
> [00000dc7](02) 8bec mov ebp,esp
> [00000dc9](05) 68a60d0000 push 00000da6
> [00000dce](05) 68a60d0000 push 00000da6
> [00000dd3](05) e83efeffff call 00000c16
> [00000dd8](03) 83c408 add esp,+08
> [00000ddb](01) 50 push eax
> [00000ddc](05) 68d7030000 push 000003d7
> [00000de1](05) e810f6ffff call 000003f6
> [00000de6](03) 83c408 add esp,+08
> [00000de9](02) 33c0 xor eax,eax
> [00000deb](01) 5d pop ebp
> [00000dec](01) c3 ret
> Size in bytes:(0039) [00000dec]
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00000dc6][0010167d][00000000] 55 push ebp
> [00000dc7][0010167d][00000000] 8bec mov ebp,esp
> [00000dc9][00101679][00000da6] 68a60d0000 push 00000da6
> [00000dce][00101675][00000da6] 68a60d0000 push 00000da6
> [00000dd3][00101671][00000dd8] e83efeffff call 00000c16
>
> H: Begin Simulation Execution Trace Stored at:111729
> Address_of_H:c16
> [00000da6][00111715][00111719] 55 push ebp
> [00000da7][00111715][00111719] 8bec mov ebp,esp
> [00000da9][00111711][001016e5] 51 push ecx
> [00000daa][00111711][001016e5] 8b4508 mov eax,[ebp+08]
> [00000dad][0011170d][00000da6] 50 push eax
> [00000dae][0011170d][00000da6] 8b4d08 mov ecx,[ebp+08]
> [00000db1][00111709][00000da6] 51 push ecx
> [00000db2][00111705][00000db7] e85ffeffff call 00000c16
> H: Infinitely Recursive Simulation Detected Simulation Stopped
> [00000dd8][0010167d][00000000] 83c408 add esp,+08
> [00000ddb][00101679][00000000] 50 push eax
> [00000ddc][00101675][000003d7] 68d7030000 push 000003d7
> [00000de1][00101675][000003d7] e810f6ffff call 000003f6
> Input_Halts = 0
> [00000de6][0010167d][00000000] 83c408 add esp,+08
> [00000de9][0010167d][00000000] 33c0 xor eax,eax
> [00000deb][00101681][00000018] 5d pop ebp
> [00000dec][00101685][00000000] c3 ret
> Number of Instructions Executed(978) == 15 Pages

om@iki.fi (Otto J. Makela) writes:

> What is the result of H(P,P) with the following definition of P?
>
> ----
>
> void P(ptr x) {
> int Halt_Status = H(x, x);
> return;
> }

You don't really have to ask. PO is not covering anything up. He has
been 100% clear that H(P,P) == 0 (for any P conventionally derived form
H) but that this is the "correct" answer because <insert the latest
mantra here>.

It's only the mantra that varies. It's been "P(P) would not halt if
line 15 were commented out". It's been "P(P) only halts because H halts
it". It's been "the input to H(P,P) never reaches it's halting state".
It's been lots of things. The constant: there are X and Y (usually both
P) such that H(X,Y) == 0 even though X(Y) halts.

--
Ben.

On 8/9/2022 9:45 AM, Ben Bacarisse wrote:
> om@iki.fi (Otto J. Makela) writes:
>
>> What is the result of H(P,P) with the following definition of P?
>>
>> ----
>>
>> void P(ptr x) {
>> int Halt_Status = H(x, x);
>> return;
>> }
>
> You don't really have to ask. PO is not covering anything up. He has
> been 100% clear that H(P,P) == 0 (for any P conventionally derived form
> H) but that this is the "correct" answer because <insert the latest
> mantra here>.
>
> It's only the mantra that varies. It's been "P(P) would not halt if
> line 15 were commented out". It's been "P(P) only halts because H halts
> it". It's been "the input to H(P,P) never reaches it's halting state".
> It's been lots of things. The constant: there are X and Y (usually both
> P) such that H(X,Y) == 0 even though X(Y) halts.
>

*AS I FIND CLEARER WORDS TO SAY SOMETHING I CHANGE THESE WORDS*
A halt decider must compute the mapping from its arguments to an accept
or reject state on the basis of the actual behavior that is actually
specified by the finite string machine description of its first argument.

*Unless one rejects the concept of UTM's*
A simulating halt decider determines the actual behavior specified by
correctly simulating the finite string machine description of its first
argument.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Tuesday, August 9, 2022 at 10:53:59 AM UTC-4, olcott wrote:
> On 8/9/2022 9:45 AM, Ben Bacarisse wrote:
> > o...@iki.fi (Otto J. Makela) writes:
> >
> >> What is the result of H(P,P) with the following definition of P?
> >>
> >> ----
> >>
> >> void P(ptr x) {
> >> int Halt_Status = H(x, x);
> >> return;
> >> }
> >
> > You don't really have to ask. PO is not covering anything up. He has
> > been 100% clear that H(P,P) == 0 (for any P conventionally derived form
> > H) but that this is the "correct" answer because <insert the latest
> > mantra here>.
> >
> > It's only the mantra that varies. It's been "P(P) would not halt if
> > line 15 were commented out". It's been "P(P) only halts because H halts
> > it". It's been "the input to H(P,P) never reaches it's halting state".
> > It's been lots of things. The constant: there are X and Y (usually both
> > P) such that H(X,Y) == 0 even though X(Y) halts.
> >
> *AS I FIND CLEARER WORDS TO SAY SOMETHING I CHANGE THESE WORDS*

It doesn't matter how you say it. We know what you mean.

> A halt decider must compute the mapping from its arguments to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by the finite string machine description of its first argument.

FALSE. A halt decider, *if one exists*, must compute the halting function:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

> *Unless one rejects the concept of UTM's*
> A simulating halt decider determines the actual behavior specified by
> correctly simulating the finite string machine description of its first
> argument.

FALSE. A simulating halt decider, like any halt decider, must compute the halting function:

H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

On Monday, August 8, 2022 at 11:23:33 PM UTC-7, Jeff Barnett wrote:
> On 8/8/2022 1:30 PM, dklei...@gmail.com wrote:
> <SNIP>
> > As far as I know, practical time-sharing started with a term project at Dartmouth
> > which Dartmouth sold to General Electric. We had to re-implement it because
> > the students were not exactly the best programmers. I wrote the syntax part
> > of the BASIC compiler. I don't think GE made any money from this first
> > commercial time-sharing system but the second version may have. I didn't
> > even stay with the first version.
> The above paragraph tickled an old memory. I may have some of this
> confused but see if any of this cause a vibration in your head. I
> believe there was a fellow named Dick Gellman(sp?) who implemented
> Dartmouth FORTRAN and I think Basic too. We worked together the first
> half of the 1970s at SDC. He was very good at mathematics and
> programming. He also implemented the following hack in the FORTRAN at
> Dartmouth:
>
> Declare format integer array(20), 5x integer
> 10 Format(7x)=(16+1)
>
> I've forgot most of FORTRAN, but the above is supposed to define format
> as an integer array of 20 elements. Statement 10 is a format statement
> where the six characters following the "7x", i.e., ")=(16+1", are
> printed. However, statement 10 is an assignment of the 5x'th element of
> the format array to 17 too! In Dick's FORTRAN, if control arrived at
> statement 10, the assignment was executed; if statement 10 was
> referenced from a print statement, it was used as a format. I believe
> that Dick contacted some of the FORTRAN specifiers (at IBM?) and asked
> what was supposed to happen; nobody knew so he did both.
>
> I'm not sure whether this is a story more about Dick or about the god
> awful state of FORTRAN specification in the 1960s.

If I read the Wikipedia article right Dartmouth developed BASIC because
they felt FORTRAN was too complicated for personal computers. The
first implementation was in 1964 and General Electric was already
involved. At least one GE component was selling time-sharing time
immediately thereafter and the corporation as a whole became involved
shortly thereafter (probably still in 1964). It is very hard to put a date on
when Project Mac was usable by outside users but its origins go back to
at least 1961. (FORTRAN appeared in 1956).

On Monday, August 8, 2022 at 5:28:59 PM UTC-7, Jeff Barnett wrote:
> On 8/8/2022 1:30 PM, dklei...@gmail.com wrote:
> > On Thursday, August 4, 2022 at 2:06:38 PM UTC-7, Jeff Barnett wrote:
> >> On 8/4/2022 2:28 AM, dklei...@gmail.com wrote:
> >>> On Wednesday, August 3, 2022 at 12:07:47 PM UTC-7, Jeff Barnett wrote:
> >>>> On 8/3/2022 3:05 AM, Malcolm McLean wrote:
> >>>>> On Wednesday, 3 August 2022 at 07:19:33 UTC+1, Jeff Barnett wrote:
> >>>>>> On 8/2/2022 12:17 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 2 Aug 2022 11:54:34 -0600
> >>>>>> <SNIP>
> >>>>>>> You are wrong: I am extending the definition of what constitutes a
> >>>>>>> halt decider which is my right as both a computer scientist and a
> >>>>>>> software engineer.
> >>>>>> The only reasonable definition I ever heard for a "Software Engineer"
> >>>>>> was someone who cannot write code, doesn't do well with math, and has
> >>>>>> learned that telling others how to do technology is easier than making a
> >>>>>> fool of themself to make a living."
> >>>>>>
> >>>>> The economic problem was that software projects were delivered late and
> >>>>> over-budget, often abandoned, and when delivered they were full of bugs
> >>>>> which sometimes had a catastrophic impact on the customer.
> >>>>> So what to do about it? A quick analysis would have shown that the problem
> >>>>> wasn't that the programmers didn't know the programming language, or
> >>>>> even that their maths wasn't up to scratch.
> >>>>> The problem was rooted in management. What was much harder was defining
> >>>>> what strong management looked like. For a long time, most people thought
> >>>>> that the solution was to impose from the top down a "formal method". If
> >>>>> everyone adhered to the method, work would be delivered bug free, and on time.
> >>>>> When this gave disappointing results, the reason was that the formal method
> >>>>> wasn't adhered to strictly enough.
> >>>>> It was gradually realised that many successful projects were not build by teams
> >>>>> which followed these formal methods. Now the methods are much better. They
> >>>>> are less bureaucratic, they give more control to programmers or immediate
> >>>>> product managers wanting to add features quickly in response to a proposal or
> >>>>> request, the tolls for controlling changes to source code are much better, the
> >>>>> languages we use are higher-level.
> >>>>> We're still not there yet. Software is still notorious for being expensive to produce
> >>>>> and faulty. You still read of horror stories where many millions of pounds are
> >>>>> wasted.
> >>>>> But realising that the computer science side of the problem is usually the easy
> >>>>> part, and the integration, testing, and deployment the part that goes wrong, and
> >>>>> that it's not just about knocking out code but a much broader problem than that,
> >>>>> is what distinguishes "software engineering" from just "programming".
> >>>> A little history of SE, starting in the early days:
> >>>>
> >>>> By the early/middle 1950s the US Government had passionate interests in
> >>>> using computers to better their systems. Experience giving contracts to
> >>>> the military support community had been an expensive disaster in many
> >>>> instances. Problems: 1) lack of knowledge about what was easy and what
> >>>> was hard, 2) lack of understanding about how to form and map
> >>>> requirements into a system architecture, 3) lack of technical experience
> >>>> in the military support community, 4) lack of knowledge about how to
> >>>> write contracts for massive systems - who's really responsible for what
> >>>> and how to handle modifications of contracts that for system
> >>>> requirements that became obvious during system development, 5) ravenous
> >>>> desire for profits by the set of contractors available - their corporate
> >>>> goals and the government's were not close and the US ended up paying
> >>>> over and over again for contractor cock ups.
> >>>>
> >>>> At some point, the government approached RAND (the non profit with John
> >>>> von Neumann, Dick Bellman, Herb Simon, and many others there) and ask if
> >>>> RAND could sprout another division to experiment with and develop some
> >>>> needed defense systems. RAND had to decline for several reasons:
> >>>>
> >>>> 1) Their creation was controlled by an act of congress as a federally
> >>>> charted not for profit corporation and that charter included a hard cap
> >>>> on RAND's gross yearly income: $50M.
> >>>>
> >>>> 2) RAND had lines at their doors - cities, states, US agencies, non
> >>>> profits - wanting to buy their services and had money to pay.
> >>>>
> >>>> 3) Most RAND researchers picked the customers they wanted to work with
> >>>> and might leave if that wasn't possible. RAND employees never said they
> >>>> worked for RAND, rather the mantra was that RAND was their sponsor.
> >>>>
> >>>> The decision was made to create another federally chartered nonprofit,
> >>>> the System Development Corporation, down the street from RAND. There
> >>>> main business was research and developing military computer systems but
> >>>> they were also to do R&D in any/all computer related areas.
> >>>>
> >>>> The seeding of management and technical employees came from RAND and
> >>>> also included many human factors folks (HF). The first task at hand was
> >>>> to find people and turn them into programmers. Early on they tested,
> >>>> analyzed and guessed who would be good at it. The best discriminator
> >>>> found was a good old fashioned IQ test. It wasn't perfect but nothing
> >>>> else worked as well.
> >>>>
> >>>> SDC put employees wanted ads all over the place. The pitch was something
> >>>> like the following: "Take a test: If you pass you will be paid X to
> >>>> attend classes for 6 months. If you pass your class, you will be offered
> >>>> a job at a starting rate of Y. You will learn about exciting new
> >>>> technologies in a terrific environment, etc," I think X was something
> >>>> like $400+ a moth and Y was a few hundred more. Remember, this was in
> >>>> the late 1950s so this was good money. Using IQ test scores as the only
> >>>> criterion, a hell's angel and a prostitute were hired; a college
> >>>> professor was not.
> >>>>
> >>>> Since the programmers hired this way started leaking out to other places
> >>>> in the world, the reputation of computer folks as "strange dudes" was
> >>>> justified. And the above, in my opinion, was the reason for the skew in
> >>>> the inhabitants of our field. It was a MENSA collection that had 40
> >>>> hours a week parties. Not so today.
> >>>>
> >>>> SDC developed useful systems for the military as well as an
> >>>> understanding of requirements, change orders, and many mundane ideas
> >>>> about how to do the day by day business of system building.
> >>>>
> >>>> In the latish 1960s and 1970s, the idea of software engineering had
> >>>> sprouted and its leading voice was Dave Parnas. Parnas was very earnest
> >>>> but naive about software development. For example, he proffered a set of
> >>>> rules for good software that excluded the use of recursion by inference.
> >>>> He had never written a part of a compiler, device drivers, parallel
> >>>> process code, etc. His preferred rules were rigid and confrontations
> >>>> with solid counterexamples bounced off him with no mental penetration.
> >>>> One of the solid rules "was no GO forms". When asked, whether his SE
> >>>> rules would allow a form rewrite to produce a new form with a GO in it,
> >>>> he didn't think that was a good idea. Followup questions: How do you
> >>>> compile loops. Well you get the idea. Parnas was last seen arguing SE
> >>>> possibilities for the development of the Strategic Defense Initiative.
> >>>>
> >>>> Pretty soon, everyone was faking SE departments, (Why not, you could add
> >>>> the expense plus overhead and profit to your contracts.) SDC as well as
> >>>> other places were caught up in the idea. Most places decided that they
> >>>> couldn't afford to take good technical people and waste them in a make
> >>>> work organization. SE became a closet to stuff your failures in. We have
> >>>> had a continuous string of SE fad movements; new ones every few years.
> >>>> Aerospace and other defense contractors run classes for all their
> >>>> employees when each useless standard is released. Funny thing many years
> >>>> ago: some of us got together and were talking about this very subject.
> >>>> It turned out that at two different defense contractors these classes
> >>>> were being taught by employees that had been given their notices along
> >>>> with a few month optional extension if they would teach these god awful
> >>>> classes. I think at the time of this get together, ISO was promoting yet
> >>>> another standards fart.
> >>>>
> >>>> In the middle late 1970s, the US government decided 1) they now knew
> >>>> enough to write and manage large computer systems contracts and 2) that
> >>>> SDC as a federally charted non profit had an unfair advantage in seeking
> >>>> government business. Thus, SDC was ordered to make a plan to change. The
> >>>> way this was done was to create a nonprofit SDC foundation that held all
> >>>> the stock in the SDC company though some was granted to current
> >>>> employees as some sort of option. The nonprofit then put their stock up
> >>>> for sale. It was eventually bought by Burroughs Corporation who was
> >>>> later absorbed by Unisys. The SDC foundation still exists. It makes
> >>>> research grants and supports various interesting CS related activities.
> >>>>
> >>>> This was too long. However, my attitude in re SE was brewed over many
> >>>> decades. We are now in an era where most products are developed and sold
> >>>> without a detailed description of what the product does. Therefore, our
> >>>> software has no errors since there is no statement of what it should do.
> >>>> Is that a victory for SE? I wonder.
> >>>>
> >>> Thank You for the valuable history.
> >>>
> >>> I lived through that era and saw the same thing. Mostly I worked for General
> >>> Electric on one or more of their defense projects but I was marginally
> >>> involved with GE's attempt to become the dominant computer service
> >>> provider. Hiring competent programmers was a problem. GE started,
> >>> I think, with the nuclear-powered airplane project (before my time) which
> >>> was, unsurprisingly, a early bust.
> >>>
> >>> The introduction of FORTRAN was a crucial point. IBM had taught a set
> >>> of principles where an analyst studied a problem and wrote a set of flow
> >>> diagram for the solution then passed this on to a coding drudge for
> >>> actual code. FOTRAN destroyed this idea. The engineers had to learn
> >>> to write their own code. You can imagine the bad code that resulted.
> >>> So the coders were elevated to programmers and saved the day.
> >>>
> >>> It's been decades since I wrote any serious code. I was quite good
> >>> at it even if I never had "programmer" as a job title. No management
> >>> could face the notion of a programmer with a doctorate. So I had a
> >>> career in management. And I agree with everybody else - good
> >>> programmers are rare and should be treasured.
> >> Thanks for the information. To continue your last point, I'll add
> >> another SDC story. The hero of the story was Hal Sackman; Note, my
> >> spelling of his name might be off. He was one of those HF guys, with a
> >> PhD, and he did a lot of experimental stuff. We had one of the earliest
> >> timing sharing systems (MIT's project MAC' system beat ours by a month
> >> or so). When things were working very reliably, he decided to do an
> >> experiment to see if time sharing was "better" than batch for code
> >> development. Being a non profit, he could get his hands on tons of
> >> people with various levels of experience, education, etc., and it didn't
> >> cost his effort a dime.
> >>
> >> He made up two different program task classes: Class one was quick and
> >> dirty one day efforts but needed some insights. Class two problems took
> >> several days and needed some design work and tradeoff study. Each
> >> subject got one task in each class (one after the other) and was told
> >> which environment to use for a task. Class, order,and system (8
> >> possibilities) where randomized. I believe he graded on number of
> >> errors, time to finish, efficiency, etc.
> >>
> >> He published his results and concluded that time sharing was marginally
> >> a better development environment that batch.
> >>
> >> Another result, an elephant in the room, he did not draw and publish
> >> from the data because people wouldn't belief it, was as follows:
> >>
> > I was managing a team of programmers back then and it was part of the
> > folklore back then that good programmers could be twenty times better
> > than the drudges. But any kind of programmer was hard to find so we got
> > along with what we hade. Personally I eased out the incompetents as fast
> > as I could.
> >
> > The history of GE commercial time-sharing is mostly forgotten these days
> > but it did happen.
> >>
> >> The performance for some programmers (normalized for education, time on
> >> the job, and all the others of these sorts of metrics) were
> >> better/faster at a ratio of 50 to 1 and their programs had hugely less
> >> bugs. In no other technical profession did you see this sort of
> >> interpersonal difference. Note that, for example, mathematicians and
> >> physicists with these performance differences were not found in the same
> >> work pool. Once you notice and accept this result, you come to the issue
> >> of fair pay. Even if you pay proportional to the square root of the
> >> difference, you would have your best programmers making more than Vice
> >> Presidents in large aerospace companies.
> >>
> >> One of the pleasures of working at SDC, was meeting people like Sackman
> >> and getting their stories from a decade before I was involved.
> >
> > As far as I know, practical time-sharing started with a term project at Dartmouth
> > which Dartmouth sold to General Electric. We had to re-implement it because
> > the students were not exactly the best programmers. I wrote the syntax part
> > of the BASIC compiler. I don't think GE made any money from this first
> > commercial time-sharing system but the second version may have. I didn't
> > even stay with the first version.
> As far as I know, practical (whatever that means) time sharing started
> in the early 1960s. MIT Project MAC was first and a few months later SDC
> was up and working. Both systems supported 20+ simultaneous users. The
> SDC system was built on an ANSQ 32 Computer; only a few were built by
> IBM for use on the Dew Line system and a few other applications.
>
> The Q32 was the first teeny tiny step into integrate circuits. (I think
> there were two flops and a few other pieces in each can. The CPU was
> triply redundant in an odd way: each bus was a three deep push down and
> all transfers were parity checked. If a hardware error was signaled,
> control transferred to a diagnostic and recover board where diagnostics
> were run. If the error was intermittent, execution was backed up a few
> instructions and time sharing was off and running; If the error was
> solid, a bit was flipped saying such and such an op code should be
> simulated by code on the recovery board then back a few instructions and
> continue time sharing.
>
> Because of the above described reliable hardware, some of the users were
> able to do combination hardware/software research during time sharing.
> One example was hand writing recognition research using a RAND tablet
> connected to the Q32 via a PDP 1(?). When they wanted to tune the
> tablet, they would just pull the connecting cable out of the Q32 which
> would quickly recover and go merrily on its way - later the would plug
> the tablet back in. A very early (and expensive) example of plug and
> play. Tablet experiments worked quite nicely in real time even though
> the programs might be competing with 15-20+ other users.
>
> The results produced on the MIT system were also spectacular. That
> system was built, used, and made "famous" by a group of kids that were
> given the title "MAC hackers". In those days "hacker" was a good word.
>
> In any event, I think both systems earned the right to be called
> "practical"!
>
The GE Commercial Time-sharing seems to have dropped out of the
industry memory. Not even Wikipedia has an account of it (that I
could find). How important one imagines it to have been depends on
one's relative allegiance to academia or business. I admit to a bias
that things bought and sold are more practical.

On 8/9/22 9:47 AM, olcott wrote:
> On 8/9/2022 7:27 AM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/8/2022 12:15 PM, Otto J. Makela wrote:
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 8/1/2022 8:54 AM, Otto J. Makela wrote:
>>>>>> Why does the correctly simulated H(P,P) not similarly detect infinite
>>>>>> recursion (inside the simulation) and return 0?
>>>>> Of the nested simulations the outermost one sees that the infinite
>>>>> recursion criteria is met first.
>>>> This seems to indicate your halting detector is reporting that
>>>> H(P,P) did not halt, instead of reporting P(P) did not halt?
>>>
>>> H itself halts. It is reporting that the correct simulation by H(P,P)
>>> of its first argument would never reach the final state "return"
>>> instruction of this simulated P and halt.
>>
>> Unfortunately your software seems to depend so heavily on your compiler
>> environment (doesn't work correctly under Linux/gcc) that I am unable to
>> conduct tests on my own.
>>
>
> The system used to compile under UBUNTU 16.04 gcc.
> I am working on fixing this as my first priority.
>
> Halt7.c must be compiled under Microsoft C to get a COFF object file.
> This may make that unnecessary:
> ./objconv -fcoff Halt7.o Halt7.ooo
>
>> What is the result of H(P,P) with the following definition of P?
>>
>
> Same result as detailed below. This version of H detects what is
> essentially infinite recursion with itself as the first call of this
> recursive sequence.
>
> The earlier version is easier to understand, yet requires communication
> through the levels of recursive simulation using static local memory in
> the outermost level.
>

And both are wrong because the both "simulate" the behavior of the call
to H(P,P) incorrectly, your current because it doesn't even simulat e it
at all but just assumes incorrect behaivor.

Since you show that H(P,P) returns 0, any correct simulation of the call
to H must be compatible with that behavior.

Deciding it is non-halting is just incorrect.

Sorry Charlie, your just wrong.

>> ----
>>
>> void P(ptr x) {
>>     int Halt_Status = H(x, x);
>>     return;
>> }
>>
>
> void P(ptr x) {
>    int Halt_Status = H(x, x);
>    return;
> }
>
> int main()
> {
>   Output((char*)"Input_Halts = ", H(P, P));
> }
>
> _P()
> [00000da6](01)  55             push ebp
> [00000da7](02)  8bec           mov ebp,esp
> [00000da9](01)  51             push ecx
> [00000daa](03)  8b4508         mov eax,[ebp+08]
> [00000dad](01)  50             push eax
> [00000dae](03)  8b4d08         mov ecx,[ebp+08]
> [00000db1](01)  51             push ecx
> [00000db2](05)  e85ffeffff     call 00000c16
> [00000db7](03)  83c408         add esp,+08
> [00000dba](03)  8945fc         mov [ebp-04],eax
> [00000dbd](02)  8be5           mov esp,ebp
> [00000dbf](01)  5d             pop ebp
> [00000dc0](01)  c3             ret
> Size in bytes:(0027) [00000dc0]
>
> _main()
> [00000dc6](01)  55             push ebp
> [00000dc7](02)  8bec           mov ebp,esp
> [00000dc9](05)  68a60d0000     push 00000da6
> [00000dce](05)  68a60d0000     push 00000da6
> [00000dd3](05)  e83efeffff     call 00000c16
> [00000dd8](03)  83c408         add esp,+08
> [00000ddb](01)  50             push eax
> [00000ddc](05)  68d7030000     push 000003d7
> [00000de1](05)  e810f6ffff     call 000003f6
> [00000de6](03)  83c408         add esp,+08
> [00000de9](02)  33c0           xor eax,eax
> [00000deb](01)  5d             pop ebp
> [00000dec](01)  c3             ret
> Size in bytes:(0039) [00000dec]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000dc6][0010167d][00000000] 55             push ebp
> [00000dc7][0010167d][00000000] 8bec           mov ebp,esp
> [00000dc9][00101679][00000da6] 68a60d0000     push 00000da6
> [00000dce][00101675][00000da6] 68a60d0000     push 00000da6
> [00000dd3][00101671][00000dd8] e83efeffff     call 00000c16
>
> H: Begin Simulation   Execution Trace Stored at:111729
> Address_of_H:c16
> [00000da6][00111715][00111719] 55             push ebp
> [00000da7][00111715][00111719] 8bec           mov ebp,esp
> [00000da9][00111711][001016e5] 51             push ecx
> [00000daa][00111711][001016e5] 8b4508         mov eax,[ebp+08]
> [00000dad][0011170d][00000da6] 50             push eax
> [00000dae][0011170d][00000da6] 8b4d08         mov ecx,[ebp+08]
> [00000db1][00111709][00000da6] 51             push ecx
> [00000db2][00111705][00000db7] e85ffeffff     call 00000c16
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> [00000dd8][0010167d][00000000] 83c408         add esp,+08
> [00000ddb][00101679][00000000] 50             push eax
> [00000ddc][00101675][000003d7] 68d7030000     push 000003d7
> [00000de1][00101675][000003d7] e810f6ffff     call 000003f6
> Input_Halts = 0
> [00000de6][0010167d][00000000] 83c408         add esp,+08
> [00000de9][0010167d][00000000] 33c0           xor eax,eax
> [00000deb][00101681][00000018] 5d             pop ebp
> [00000dec][00101685][00000000] c3             ret
> Number of Instructions Executed(978) == 15 Pages
>

On 8/9/22 10:53 AM, olcott wrote:
> On 8/9/2022 9:45 AM, Ben Bacarisse wrote:
>> om@iki.fi (Otto J. Makela) writes:
>>
>>> What is the result of H(P,P) with the following definition of P?
>>>
>>> ----
>>>
>>> void P(ptr x) {
>>>     int Halt_Status = H(x, x);
>>>     return;
>>> }
>>
>> You don't really have to ask.  PO is not covering anything up.  He has
>> been 100% clear that H(P,P) == 0 (for any P conventionally derived form
>> H) but that this is the "correct" answer because <insert the latest
>> mantra here>.
>>
>> It's only the mantra that varies.  It's been "P(P) would not halt if
>> line 15 were commented out".  It's been "P(P) only halts because H halts
>> it".  It's been "the input to H(P,P) never reaches it's halting state".
>> It's been lots of things.  The constant: there are X and Y (usually both
>> P) such that H(X,Y) == 0 even though X(Y) halts.
>>
>
> *AS I FIND CLEARER WORDS TO SAY SOMETHING I CHANGE THESE WORDS*
> A halt decider must compute the mapping from its arguments to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by the finite string machine description of its first argument.

And the behavior of the input to H(P,P) is P(P), or UTM(P,P), which Halt.

>
> *Unless one rejects the concept of UTM's*
> A simulating halt decider determines the actual behavior specified by
> correctly simulating the finite string machine description of its first
> argument.
>
>

Except that H isn't a UTM, by definition, since a UTM doesn't halt until
its input reaches the final state, and a H that answer 0 for ANY input,
had to stop before that.

FAIL.

On 8/9/2022 3:03 PM, dklei...@gmail.com wrote:
> On Monday, August 8, 2022 at 11:23:33 PM UTC-7, Jeff Barnett wrote:
>> On 8/8/2022 1:30 PM, dklei...@gmail.com wrote:
>> <SNIP>
>>> As far as I know, practical time-sharing started with a term project at Dartmouth
>>> which Dartmouth sold to General Electric. We had to re-implement it because
>>> the students were not exactly the best programmers. I wrote the syntax part
>>> of the BASIC compiler. I don't think GE made any money from this first
>>> commercial time-sharing system but the second version may have. I didn't
>>> even stay with the first version.
>> The above paragraph tickled an old memory. I may have some of this
>> confused but see if any of this cause a vibration in your head. I
>> believe there was a fellow named Dick Gellman(sp?) who implemented
>> Dartmouth FORTRAN and I think Basic too. We worked together the first
>> half of the 1970s at SDC. He was very good at mathematics and
>> programming. He also implemented the following hack in the FORTRAN at
>> Dartmouth:
>>
>> Declare format integer array(20), 5x integer
>> 10 Format(7x)=(16+1)
>>
>> I've forgot most of FORTRAN, but the above is supposed to define format
>> as an integer array of 20 elements. Statement 10 is a format statement
>> where the six characters following the "7x", i.e., ")=(16+1", are
>> printed. However, statement 10 is an assignment of the 5x'th element of
>> the format array to 17 too! In Dick's FORTRAN, if control arrived at
>> statement 10, the assignment was executed; if statement 10 was
>> referenced from a print statement, it was used as a format. I believe
>> that Dick contacted some of the FORTRAN specifiers (at IBM?) and asked
>> what was supposed to happen; nobody knew so he did both.
>>
>> I'm not sure whether this is a story more about Dick or about the god
>> awful state of FORTRAN specification in the 1960s.
>
> If I read the Wikipedia article right Dartmouth developed BASIC because
> they felt FORTRAN was too complicated for personal computers. The
> first implementation was in 1964 and General Electric was already
> involved. At least one GE component was selling time-sharing time
> immediately thereafter and the corporation as a whole became involved
> shortly thereafter (probably still in 1964). It is very hard to put a date on
> when Project Mac was usable by outside users but its origins go back to
> at least 1961. (FORTRAN appeared in 1956).

FORTRAN really wasn't too complicated; it was too untidy. It was my
"mother tongue". I next learned 7090/94 assembler. It was remarkable but
the assembler had macros and many more facilities than FORTRAN to help
write intelligible programs! That assembler convinced me that it was
possible to make more useful and more interesting languages.

Mistake: machine name was AN/FSQ-32. The TS system was working and in
daily use sometime in 1963. A paper by Jules Schwartz (JOVIAL = Jules
own version of the international algorithmic language), Clark Weissman,
and someone I don't know wrote a paper on the TS for the Spring(1964)
Joint Annual Computer Conference. I believe that paper won a best paper
in conference award.
--
Jeff Barnett

olcott <NoOne@NoWhere.com> wrote:

> On 8/9/2022 7:27 AM, Otto J. Makela wrote:
>> What is the result of H(P,P) with the following definition of P?
>> ----
>> void P(ptr x) {
>> int Halt_Status = H(x, x);
>> return;
>> }
>
> Same result as detailed below. This version of H detects what is
> essentially infinite recursion with itself as the first call of this
> recursive sequence.

I assume also a direct call of H(H,H) will produce the same
"non-halting" result?

The fact that your halting detector H() detects itself as infinitely
recursive (although it under normal circumstances produce a result,
without infinite recursion) would seem to indicate it does not always
produce correct results as originally defined.

I believe I understand the halting problem sufficiently to claim this is
one aspect of the impossibilty of creating a true halting detector.

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

On 8/10/2022 4:17 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/9/2022 7:27 AM, Otto J. Makela wrote:
>>> What is the result of H(P,P) with the following definition of P?
>>> ----
>>> void P(ptr x) {
>>> int Halt_Status = H(x, x);
>>> return;
>>> }
>>
>> Same result as detailed below. This version of H detects what is
>> essentially infinite recursion with itself as the first call of this
>> recursive sequence.
>
> I assume also a direct call of H(H,H) will produce the same
> "non-halting" result?
>

That is not in the domain of H.

> The fact that your halting detector H() detects itself as infinitely
> recursive

H(P,P) is not detecting itself as infinitely recursive, it is detecting
the P is called it in infinite recursion.

< (although it under normal circumstances produce a result,

No function called in infinite recursion ever returns to its caller.

> without infinite recursion) would seem to indicate it does not always
> produce correct results as originally defined.
>

H1(P,P) returns 1.

> I believe I understand the halting problem sufficiently to claim this is
> one aspect of the impossibilty of creating a true halting detector.
>

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass
its own source and its input to H and then specifically do the
opposite of what H predicts P will do.
*No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

H and P implement the exact pathological relationship to each
other as described above. Because H(P,P) does handle this
case the above halting problem undecidable input template has
been refuted.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

olcott <NoOne@NoWhere.com> wrote:

> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
>> I assume also a direct call of H(H,H) will produce the same
>> "non-halting" result?
>
> That is not in the domain of H.

Your halting decider H() will only work for a subset of halting
problems, any cases including itself (or programs using similar
methodology) are excluded?

This of course means it is not what was given in the original
specification of the problem, "an algorithm that ALWAYS correctly
decides whether, for a given ARBITRARY program and input, the program
halts when run with that input" (CAPITALIZATIONS added).

Do you remember the no-win "Kobayashi Maru" computer simulation scenario
on Star Trek, which only James Kirk was able to solve, by means of
hacking the original specification in a way that it became winnable?

https://en.wikipedia.org/wiki/Kobayashi_Maru

You have effectively done the same with your halting decider.

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

On 8/10/2022 9:02 AM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
>>> I assume also a direct call of H(H,H) will produce the same
>>> "non-halting" result?
>>
>> That is not in the domain of H.
>
> Your halting decider H() will only work for a subset of halting
> problems, any cases including itself (or programs using similar
> methodology) are excluded?
>

Every case that has conditional branches is excluded from my
implementation, yet not excluded from my underlying theory. It simply
takes too much more time to correctly handle conditional branches in
working code.

> This of course means it is not what was given in the original
> specification of the problem, "an algorithm that ALWAYS correctly
> decides whether, for a given ARBITRARY program and input, the program
> halts when run with that input" (CAPITALIZATIONS added).
>
> Do you remember the no-win "Kobayashi Maru" computer simulation scenario
> on Star Trek, which only James Kirk was able to solve, by means of
> hacking the original specification in a way that it became winnable?
>
> https://en.wikipedia.org/wiki/Kobayashi_Maru
>
> You have effectively done the same with your halting decider.
>

Not at all. As soon as I prove that the "impossible" input is decidable
all of the conventional HP proofs lose their basis and fail.

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass
its own source and its input to H and then specifically do the
opposite of what H predicts P will do.
*No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

H and P implement the exact pathological relationship to each
other as described above. Because H(P,P) does handle this
case the above halting problem undecidable input template has
been refuted.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, August 10, 2022 at 10:55:29 AM UTC-4, olcott wrote:
> On 8/10/2022 9:02 AM, Otto J. Makela wrote:
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
> >>> I assume also a direct call of H(H,H) will produce the same
> >>> "non-halting" result?
> >>
> >> That is not in the domain of H.
> >
> > Your halting decider H() will only work for a subset of halting
> > problems, any cases including itself (or programs using similar
> > methodology) are excluded?
> >
> Every case that has conditional branches is excluded from my
> implementation, yet not excluded from my underlying theory. It simply
> takes too much more time to correctly handle conditional branches in
> working code.

So in other words, you conveniently ignore anything that might show that you don't in fact have infinite simulation (specifically the code of Ha) to get the wrong answer and "declare" it correct.

> > This of course means it is not what was given in the original
> > specification of the problem, "an algorithm that ALWAYS correctly
> > decides whether, for a given ARBITRARY program and input, the program
> > halts when run with that input" (CAPITALIZATIONS added).
> >
> > Do you remember the no-win "Kobayashi Maru" computer simulation scenario
> > on Star Trek, which only James Kirk was able to solve, by means of
> > hacking the original specification in a way that it became winnable?
> >
> > https://en.wikipedia.org/wiki/Kobayashi_Maru
> >
> > You have effectively done the same with your halting decider.
> >
> Not at all. As soon as I prove that the "impossible" input is decidable
> all of the conventional HP proofs lose their basis and fail.

Which you haven't done because your H doesn't compute the halting function:

For *any* algorithm X and input Y:
H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass
> its own source and its input to H and then specifically do the
> opposite of what H predicts P will do.
> *No H can exist that handles this case*
> https://en.wikipedia.org/wiki/Halting_problem
>
> H and P implement the exact pathological relationship to each
> other as described above. Because H(P,P) does handle this
> case the above halting problem undecidable input template has
> been refuted.

On Wed, 10 Aug 2022 08:42:11 -0700 (PDT)
Dennis Bush <dbush.mobile@gmail.com> wrote:

> On Wednesday, August 10, 2022 at 10:55:29 AM UTC-4, olcott wrote:
> > On 8/10/2022 9:02 AM, Otto J. Makela wrote:
> > > olcott <No...@NoWhere.com> wrote:
> > >
> > >> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
> > >>> I assume also a direct call of H(H,H) will produce the same
> > >>> "non-halting" result?
> > >>
> > >> That is not in the domain of H.
> > >
> > > Your halting decider H() will only work for a subset of halting
> > > problems, any cases including itself (or programs using similar
> > > methodology) are excluded?
> > >
> > Every case that has conditional branches is excluded from my
> > implementation, yet not excluded from my underlying theory. It
> > simply takes too much more time to correctly handle conditional
> > branches in working code.
>
> So in other words, you conveniently ignore anything that might show
> that you don't in fact have infinite simulation (specifically the
> code of Ha) to get the wrong answer and "declare" it correct.
>
> > > This of course means it is not what was given in the original
> > > specification of the problem, "an algorithm that ALWAYS correctly
> > > decides whether, for a given ARBITRARY program and input, the
> > > program halts when run with that input" (CAPITALIZATIONS added).
> > >
> > > Do you remember the no-win "Kobayashi Maru" computer simulation
> > > scenario on Star Trek, which only James Kirk was able to solve,
> > > by means of hacking the original specification in a way that it
> > > became winnable?
> > >
> > > https://en.wikipedia.org/wiki/Kobayashi_Maru
> > >
> > > You have effectively done the same with your halting decider.
> > >
> > Not at all. As soon as I prove that the "impossible" input is
> > decidable all of the conventional HP proofs lose their basis and
> > fail.
>
> Which you haven't done because your H doesn't compute the halting
> function:
>
> For *any* algorithm X and input Y:
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
*and*
H(X,Y)==signal(exception) if and only if X(Y) is pathological

I have shown how a simulating halt decider can detect pathological
input without relying on Olcott's "infinite recursion detector".

/Flibble

olcott <NoOne@NoWhere.com> wrote:

> On 8/10/2022 9:02 AM, Otto J. Makela wrote:
>> olcott <NoOne@NoWhere.com> wrote:
>>> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
>>>> I assume also a direct call of H(H,H) will produce the same
>>>> "non-halting" result?
>>> That is not in the domain of H.
>> Your halting decider H() will only work for a subset of halting
>> problems, any cases including itself (or programs using similar
>> methodology) are excluded?
>
> Every case that has conditional branches is excluded from my
> implementation, yet not excluded from my underlying theory. It simply
> takes too much more time to correctly handle conditional branches in
> working code.

I see.

Why don't you get back to us once you've implemented also this part,
because without it, this is not even a toy implementation?

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

On 8/10/2022 3:15 PM, Otto J. Makela wrote:
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/10/2022 9:02 AM, Otto J. Makela wrote:
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
>>>>> I assume also a direct call of H(H,H) will produce the same
>>>>> "non-halting" result?
>>>> That is not in the domain of H.
>>> Your halting decider H() will only work for a subset of halting
>>> problems, any cases including itself (or programs using similar
>>> methodology) are excluded?
>>
>> Every case that has conditional branches is excluded from my
>> implementation, yet not excluded from my underlying theory. It simply
>> takes too much more time to correctly handle conditional branches in
>> working code.
>
> I see.
>
> Why don't you get back to us once you've implemented also this part,
> because without it, this is not even a toy implementation?
>

Because it is moot. I have proven that H does correctly determine the
halt status of the HP's impossible input, thus correctly refuted these
proofs.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, August 10, 2022 at 1:55:17 PM UTC-7, olcott wrote:
> On 8/10/2022 3:15 PM, Otto J. Makela wrote:
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 8/10/2022 9:02 AM, Otto J. Makela wrote:
> >>> olcott <No...@NoWhere.com> wrote:
> >>>> On 8/10/2022 4:17 AM, Otto J. Makela wrote:
> >>>>> I assume also a direct call of H(H,H) will produce the same
> >>>>> "non-halting" result?
> >>>> That is not in the domain of H.
> >>> Your halting decider H() will only work for a subset of halting
> >>> problems, any cases including itself (or programs using similar
> >>> methodology) are excluded?
> >>
> >> Every case that has conditional branches is excluded from my
> >> implementation, yet not excluded from my underlying theory. It simply
> >> takes too much more time to correctly handle conditional branches in
> >> working code.
> >
> > I see.
> >
> > Why don't you get back to us once you've implemented also this part,
> > because without it, this is not even a toy implementation?
> >
> Because it is moot. I have proven that H does correctly determine the
> halt status of the HP's impossible input, thus correctly refuted these
> proofs.

Once again - just exactly what are you trying to prove?