The halting problem as defined is erroneous: it is effectively a
category error.

The categories involved in the category error are:

1) A program
2) The source code for a program
3) A decider
4) That which is being decided.

Until this category error is resolved any further discussion of the
halting problem is pointless.

/Flibble

On 11/14/2021 3:33 PM, Mr Flibble wrote:
> The halting problem as defined is erroneous: it is effectively a
> category error.
>
> The categories involved in the category error are:
>
> 1) A program
> 2) The source code for a program
> 3) A decider
> 4) That which is being decided.
>
> Until this category error is resolved any further discussion of the
> halting problem is pointless.
>
> /Flibble
>

If you know both C and the x86 language quite well then this is complete
proof that the counter-examples to the halting theorem are decidable as
infinite recursion:

Simulating partial halt decider H correctly decides that P(P) never
halts (V1)

#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

Proof that H(P,P)==0 is correct for every possible H at machine address
00001a7e that simulates or executes the precise byte sequence shown below:

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

P is defined as the above precise byte sequence.
The x86 language is the entire inference basis.

For every possible H defined at machine address 00001a7e that has input
(P,P) when the input to H(P,P) is executed or simulated this input is
either infinitely recursive or aborted at some point. In no case does
the input ever reach its final state of 00001a72.

Now that we have verified that the input to H(P,P) never halts we know
that the correct return value for any correct halt decider H(P,P) must
be 0.

To determine the correct halt status of the input to H(P,P) H merely
needs to simulate its input one instruction at a time until H sees P
call itself with the same parameters that it was called with. When H
sees this H correctly returns 0 for not halting.

If the above is so simple that it doesn't even look like it applies to
the halting problem this paper has slightly more complex examples and
much more analysis and reasoning.

Halting problem undecidability and infinitely nested simulation (V2)
November 2021 PL Olcott

https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

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

On 11/14/21 5:26 PM, olcott wrote:
> On 11/14/2021 3:33 PM, Mr Flibble wrote:
>> The halting problem as defined is erroneous: it is effectively a
>> category error.
>>
>> The categories involved in the category error are:
>>
>> 1) A program
>> 2) The source code for a program
>> 3) A decider
>> 4) That which is being decided.
>>
>> Until this category error is resolved any further discussion of the
>> halting problem is pointless.
>>
>> /Flibble
>>
>
> If you know both C and the x86 language quite well then this is complete
> proof that the counter-examples to the halting theorem are decidable as
> infinite recursion:
>
>
> Simulating partial halt decider H correctly decides that P(P) never
> halts (V1)
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);  // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> Proof that H(P,P)==0 is correct for every possible H at machine address
> 00001a7e that simulates or executes the precise byte sequence shown below:
>
> _P()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b4508          mov eax,[ebp+08]
> [00001a64](01)  50              push eax        // push P
> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
> [00001a68](01)  51              push ecx        // push P
> [00001a69](05)  e810000000      call 00001a7e   // call H
> [00001a6e](03)  83c408          add esp,+08
> [00001a71](01)  5d              pop ebp
> [00001a72](01)  c3              ret
> Size in bytes:(0021) [00001a72]
>
> P is defined as the above precise byte sequence.
> The x86 language is the entire inference basis.
>
> For every possible H  defined at machine address 00001a7e that has input
> (P,P) when the input to H(P,P) is executed or simulated this input is
> either infinitely recursive or aborted at some point. In no case does
> the input ever reach its final state of 00001a72.
>
> Now that we have verified that the input to H(P,P) never halts we know
> that the correct return value for any correct halt decider H(P,P) must
> be 0.

Except that if H(P,P) returns 0, then the computation represented by the
input P(P) halts, which is what the Halting Problem is asking about.

FAIL.

>
> To determine the correct halt status of the input to H(P,P) H merely
> needs to simulate its input one instruction at a time until H sees P
> call itself with the same parameters that it was called with. When H
> sees this H correctly returns 0 for not halting.
>

No that is NOT a valid proof, because H is assuming that H will never
abort its simulation, while H will abort its simulation.

FAIL

> If the above is so simple that it doesn't even look like it applies to
> the halting problem this paper has slightly more complex examples and
> much more analysis and reasoning.
>
> Halting problem undecidability and infinitely nested simulation (V2)
> November 2021 PL Olcott
>
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>
>

Mr Flibble <flibble@reddwarf.jmc> writes:

> The halting problem as defined is erroneous: it is effectively a
> category error.
>
> The categories involved in the category error are:
>
> 1) A program
> 2) The source code for a program
> 3) A decider
> 4) That which is being decided.
>
> Until this category error is resolved any further discussion of the
> halting problem is pointless.

Some exercises for you, none of which refer to programs, source code,
deciders or that which is being decided...

Consider the singleton alphabet Sigma = {x}
and the set, M, of all Turing machines with that input alphabet.

(a) Show that M is countable, i.e. that there is a bijection m: N -> M.

(b) Show that the language X = { x^i | x^i in L(m(i)) } is
recursively enumerable.

(Notation: x^n is the string of n xs, and L(M) is the language accepted
by Turing machine M.)

(c) Show that the complement of X, ~X = { x^i | x^i not in L(m(i)) }, is
not recursively enumerable.

(d) Show that X is a recursively enumerable language that is not
recursive.

(e) Show that the halting theorem is a corollary of (d).

I chose these because they constitute the actual proof given in Linz --
the one that no crank ever seems to read.

--
Ben.

On Sun, 14 Nov 2021 23:05:28 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > The halting problem as defined is erroneous: it is effectively a
> > category error.
> >
> > The categories involved in the category error are:
> >
> > 1) A program
> > 2) The source code for a program
> > 3) A decider
> > 4) That which is being decided.
> >
> > Until this category error is resolved any further discussion of the
> > halting problem is pointless.
>
> Some exercises for you [snip]

Some exercises for me? Mate, fuck off.

/Flibble

On 11/14/2021 5:19 PM, Mr Flibble wrote:
> On Sun, 14 Nov 2021 23:05:28 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> The halting problem as defined is erroneous: it is effectively a
>>> category error.
>>>
>>> The categories involved in the category error are:
>>>
>>> 1) A program
>>> 2) The source code for a program
>>> 3) A decider
>>> 4) That which is being decided.
>>>
>>> Until this category error is resolved any further discussion of the
>>> halting problem is pointless.
>>
>> Some exercises for you [snip]
>
> Some exercises for me? Mate, fuck off.
>
> /Flibble
>
>

This is the key element of my simplest possibly refutation of the
halting problem proofs.

#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

--
Copyright 2021 Pete Olcott

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

On 11/14/21 6:42 PM, olcott wrote:
> On 11/14/2021 5:19 PM, Mr Flibble wrote:
>> On Sun, 14 Nov 2021 23:05:28 +0000
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>
>>>> The halting problem as defined is erroneous: it is effectively a
>>>> category error.
>>>>
>>>> The categories involved in the category error are:
>>>>
>>>> 1) A program
>>>> 2) The source code for a program
>>>> 3) A decider
>>>> 4) That which is being decided.
>>>>
>>>> Until this category error is resolved any further discussion of the
>>>> halting problem is pointless.
>>>
>>> Some exercises for you [snip]
>>
>> Some exercises for me? Mate, fuck off.
>>
>> /Flibble
>>
>>
>
> This is the key element of my simplest possibly refutation of the
> halting problem proofs.
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);  // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
>

Except that this H doesn't return any answer, and if you change H you
have changed the computation you are looking at, so you haven't proved
anything about it.

You just don't understand what you are saying and what you need to do.

On 11/14/2021 6:19 PM, Richard Damon wrote:
> On 11/14/21 6:42 PM, olcott wrote:
>> On 11/14/2021 5:19 PM, Mr Flibble wrote:
>>> On Sun, 14 Nov 2021 23:05:28 +0000
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>
>>>>> The halting problem as defined is erroneous: it is effectively a
>>>>> category error.
>>>>>
>>>>> The categories involved in the category error are:
>>>>>
>>>>> 1) A program
>>>>> 2) The source code for a program
>>>>> 3) A decider
>>>>> 4) That which is being decided.
>>>>>
>>>>> Until this category error is resolved any further discussion of the
>>>>> halting problem is pointless.
>>>>
>>>> Some exercises for you [snip]
>>>
>>> Some exercises for me? Mate, fuck off.
>>>
>>> /Flibble
>>>
>>>
>>
>> This is the key element of my simplest possibly refutation of the
>> halting problem proofs.
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y);  // direct execution of P(P)
>>    return 1;
>> }
>>
>> // Minimal essence of Linz(1990) Ĥ
>> // and Strachey(1965) P
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>>
>
> Except that this H doesn't return any answer,

Flibble has ignored my longer anwers so I provided a shorter incomplete
answer.

> and if you change H you
> have changed the computation you are looking at, so you haven't proved
> anything about it.
>
> You just don't understand what you are saying and what you need to do.

--
Copyright 2021 Pete Olcott

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

On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:
> On 11/14/2021 6:19 PM, Richard Damon wrote:
> > On 11/14/21 6:42 PM, olcott wrote:
> >> On 11/14/2021 5:19 PM, Mr Flibble wrote:
> >>> On Sun, 14 Nov 2021 23:05:28 +0000
> >>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >>>
> >>>> Mr Flibble <fli...@reddwarf.jmc> writes:
> >>>>
> >>>>> The halting problem as defined is erroneous: it is effectively a
> >>>>> category error.
> >>>>>
> >>>>> The categories involved in the category error are:
> >>>>>
> >>>>> 1) A program
> >>>>> 2) The source code for a program
> >>>>> 3) A decider
> >>>>> 4) That which is being decided.
> >>>>>
> >>>>> Until this category error is resolved any further discussion of the
> >>>>> halting problem is pointless.
> >>>>
> >>>> Some exercises for you [snip]
> >>>
> >>> Some exercises for me? Mate, fuck off.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> This is the key element of my simplest possibly refutation of the
> >> halting problem proofs.
> >>
> >> #include <stdint.h>
> >> typedef void (*ptr)();
> >>
> >> int H(ptr x, ptr y)
> >> {
> >> x(y); // direct execution of P(P)
> >> return 1;
> >> }
> >>
> >> // Minimal essence of Linz(1990) Ĥ
> >> // and Strachey(1965) P
> >> void P(ptr x)
> >> {
> >> H(x, x);
> >> }
> >>
> >> int main(void)
> >> {
> >> H(P, P);
> >> }
> >>
> >>
> >
> > Except that this H doesn't return any answer,
> Flibble has ignored my longer anwers so I provided a shorter incomplete
> answer.
> > and if you change H you
> > have changed the computation you are looking at, so you haven't proved
> > anything about it.
> >
> > You just don't understand what you are saying and what you need to do.
> --
> Copyright 2021 Pete Olcott
>
> Talent hits a target no one else can hit;
> Genius hits a target no one else can see.
> Arthur Schopenhauer
do all programming language interpreters and therefore compilers
have a similar bug to rplaca in lisp like functional evaluators?

On 11/14/21 8:06 PM, olcott wrote:
> On 11/14/2021 6:19 PM, Richard Damon wrote:
>> On 11/14/21 6:42 PM, olcott wrote:
>>> On 11/14/2021 5:19 PM, Mr Flibble wrote:
>>>> On Sun, 14 Nov 2021 23:05:28 +0000
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>
>>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>>>
>>>>>> The halting problem as defined is erroneous: it is effectively a
>>>>>> category error.
>>>>>>
>>>>>> The categories involved in the category error are:
>>>>>>
>>>>>> 1) A program
>>>>>> 2) The source code for a program
>>>>>> 3) A decider
>>>>>> 4) That which is being decided.
>>>>>>
>>>>>> Until this category error is resolved any further discussion of the
>>>>>> halting problem is pointless.
>>>>>
>>>>> Some exercises for you [snip]
>>>>
>>>> Some exercises for me? Mate, fuck off.
>>>>
>>>> /Flibble
>>>>
>>>>
>>>
>>> This is the key element of my simplest possibly refutation of the
>>> halting problem proofs.
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y);  // direct execution of P(P)
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>>
>>
>> Except that this H doesn't return any answer,
>
> Flibble has ignored my longer anwers so I provided a shorter incomplete
> answer.
>

But it is still wrong. As is your longer one.

If an H can show that its P(P) is non-halting, then it never tells
anyone that answer and is wrong.

If H does return 0 indicating that P(P) is non-halting then when P is
run as an independent computation, as required by the definition to
determine halting, H also returns to that P that so P will Halt.

You FALSELY assume that the fact that an aborted simulation never
reached the halting state says something about the machine reprented by
the input to be non-halting.

NO H give a correct answer of non-halting for the P that uses it, which
is the P that it needs to get right to be a refutation.

FAIL.

>>  and if you change H you have changed the computation you are looking
>> at, so you haven't proved anything about it.
>>
>> You just don't understand what you are saying and what you need to do.
>
>

On 11/14/2021 6:32 PM, Daniel Pehoushek wrote:
> On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:

<SNIP>

> do all programming language interpreters and therefore compilers
> have a similar bug to rplaca in lisp like functional evaluators?

rplaca isn't a bug, it's an operator; a very normal one. Assume you are
using a programming language language where you can define a simple two
field structure or object, named cons, as

structure cons (car pointer, cdr pointer);

and you have a variable x of type cons. Do you think a statement such as

x.car <- some pointer producing expression;

is an error? The slight difference between that assignment and rplaca is
that rplaca returns x, while the statement (used as an expression if
allowed) will usually return either the new or old value in x.car -
depends on the language. By the way, common Lisp, allows the statement
or expression form and returns the new value.

If you do not like assignments to structures (in the same way you do not
like cap letters), take that as your choice but nobodies error.

I'm curious: In your code, do you every assign a value to a field in a
structure or mutate an object? In other words do you use rplaca in your
own code?

BTW You might be interested that a fellow by the name of Erwin Book
coined the phrase "rplaca in haste, repent at your leisure!" in the late
1950s or early 1960s.
--
Jeff Barnett

On Sunday, 14 November 2021 at 23:19:46 UTC, Mr Flibble wrote:
> On Sun, 14 Nov 2021 23:05:28 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>
> > Mr Flibble <fli...@reddwarf.jmc> writes:
> >
> > > The halting problem as defined is erroneous: it is effectively a
> > > category error.
> > >
> > > The categories involved in the category error are:
> > >
> > > 1) A program
> > > 2) The source code for a program
> > > 3) A decider
> > > 4) That which is being decided.
> > >
> > > Until this category error is resolved any further discussion of the
> > > halting problem is pointless.
> >
> > Some exercises for you [snip]
>
> Some exercises for me? Mate, fuck off.
>
I'm surprised that Ben responds to you at all, given your potty mouth.

On 11/15/2021 3:53 AM, Malcolm McLean wrote:
> On Sunday, 14 November 2021 at 23:19:46 UTC, Mr Flibble wrote:
>> On Sun, 14 Nov 2021 23:05:28 +0000
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>
>>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>>
>>>> The halting problem as defined is erroneous: it is effectively a
>>>> category error.
>>>>
>>>> The categories involved in the category error are:
>>>>
>>>> 1) A program
>>>> 2) The source code for a program
>>>> 3) A decider
>>>> 4) That which is being decided.
>>>>
>>>> Until this category error is resolved any further discussion of the
>>>> halting problem is pointless.
>>>
>>> Some exercises for you [snip]
>>
>> Some exercises for me? Mate, fuck off.
>>
> I'm surprised that Ben responds to you at all, given your potty mouth.
>

Ben is condescending.

--
Copyright 2021 Pete Olcott

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

On Monday, November 15, 2021 at 12:10:46 AM UTC-5, Jeff Barnett wrote:
> On 11/14/2021 6:32 PM, Daniel Pehoushek wrote:
> > On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:
> <SNIP>
> > do all programming language interpreters and therefore compilers
> > have a similar bug to rplaca in lisp like functional evaluators?
> rplaca isn't a bug, it's an operator; a very normal one. Assume you are
> using a programming language language where you can define a simple two
> field structure or object, named cons, as
>
> structure cons (car pointer, cdr pointer);
>
> and you have a variable x of type cons. Do you think a statement such as
>
> x.car <- some pointer producing expression;
>
> is an error? The slight difference between that assignment and rplaca is
> that rplaca returns x, while the statement (used as an expression if
> allowed) will usually return either the new or old value in x.car -
> depends on the language. By the way, common Lisp, allows the statement
> or expression form and returns the new value.
>
> If you do not like assignments to structures (in the same way you do not
> like cap letters), take that as your choice but nobodies error.
>
> I'm curious: In your code, do you every assign a value to a field in a
> structure or mutate an object? In other words do you use rplaca in your
> own code?
>
> BTW You might be interested that a fellow by the name of Erwin Book
> coined the phrase "rplaca in haste, repent at your leisure!" in the late
> 1950s or early 1960s.
> --
> Jeff Barnett
dear jeff
when i aced as a sophomore at leland stanford junior university
professor john mccarthys graduate level lisp course
the rplaca bug was an unsolvable problem in eval
i am wondering if the bug is general to all or some
computation by interpreters then compilers?
and as i say i may have a solution by
spelling symbols out letter by letter
using the new lisp function untern
(defun untern (u n t e r n))
daniel gres 2380

On Saturday, November 20, 2021 at 12:14:23 AM UTC-5, Daniel Pehoushek wrote:
> On Monday, November 15, 2021 at 12:10:46 AM UTC-5, Jeff Barnett wrote:
> > On 11/14/2021 6:32 PM, Daniel Pehoushek wrote:
> > > On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:
> > <SNIP>
> > > do all programming language interpreters and therefore compilers
> > > have a similar bug to rplaca in lisp like functional evaluators?
> > rplaca isn't a bug, it's an operator; a very normal one. Assume you are
> > using a programming language language where you can define a simple two
> > field structure or object, named cons, as
> >
> > structure cons (car pointer, cdr pointer);
> >
> > and you have a variable x of type cons. Do you think a statement such as
> >
> > x.car <- some pointer producing expression;
> >
> > is an error? The slight difference between that assignment and rplaca is
> > that rplaca returns x, while the statement (used as an expression if
> > allowed) will usually return either the new or old value in x.car -
> > depends on the language. By the way, common Lisp, allows the statement
> > or expression form and returns the new value.
> >
> > If you do not like assignments to structures (in the same way you do not
> > like cap letters), take that as your choice but nobodies error.
> >
> > I'm curious: In your code, do you every assign a value to a field in a
> > structure or mutate an object? In other words do you use rplaca in your
> > own code?
> >
> > BTW You might be interested that a fellow by the name of Erwin Book
> > coined the phrase "rplaca in haste, repent at your leisure!" in the late
> > 1950s or early 1960s.
> > --
> > Jeff Barnett
> dear jeff
> when i aced as a sophomore at leland stanford junior university
> professor john mccarthys graduate level lisp course
> the rplaca bug was an unsolvable problem in eval
> i am wondering if the bug is general to all or some
> computation by interpreters then compilers?
> and as i say i may have a solution by
> spelling symbols out letter by letter
> using the new lisp function untern
> (defun untern (u n t e r n))
> daniel gres 2380
dear jeff
my qspace solver uses fprintf one num at a time over all formulas in all files of just a single directory until freddy krueger day occurs in theory and probably in reality
daniel

On Saturday, November 20, 2021 at 12:19:35 AM UTC-5, Daniel Pehoushek wrote:
> On Saturday, November 20, 2021 at 12:14:23 AM UTC-5, Daniel Pehoushek wrote:
> > On Monday, November 15, 2021 at 12:10:46 AM UTC-5, Jeff Barnett wrote:
> > > On 11/14/2021 6:32 PM, Daniel Pehoushek wrote:
> > > > On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:
> > > <SNIP>
> > > > do all programming language interpreters and therefore compilers
> > > > have a similar bug to rplaca in lisp like functional evaluators?
> > > rplaca isn't a bug, it's an operator; a very normal one. Assume you are
> > > using a programming language language where you can define a simple two
> > > field structure or object, named cons, as
> > >
> > > structure cons (car pointer, cdr pointer);
> > >
> > > and you have a variable x of type cons. Do you think a statement such as
> > >
> > > x.car <- some pointer producing expression;
> > >
> > > is an error? The slight difference between that assignment and rplaca is
> > > that rplaca returns x, while the statement (used as an expression if
> > > allowed) will usually return either the new or old value in x.car -
> > > depends on the language. By the way, common Lisp, allows the statement
> > > or expression form and returns the new value.
> > >
> > > If you do not like assignments to structures (in the same way you do not
> > > like cap letters), take that as your choice but nobodies error.
> > >
> > > I'm curious: In your code, do you every assign a value to a field in a
> > > structure or mutate an object? In other words do you use rplaca in your
> > > own code?
> > >
> > > BTW You might be interested that a fellow by the name of Erwin Book
> > > coined the phrase "rplaca in haste, repent at your leisure!" in the late
> > > 1950s or early 1960s.
> > > --
> > > Jeff Barnett
> > dear jeff
> > when i aced as a sophomore at leland stanford junior university
> > professor john mccarthys graduate level lisp course
> > the rplaca bug was an unsolvable problem in eval
> > i am wondering if the bug is general to all or some
> > computation by interpreters then compilers?
> > and as i say i may have a solution by
> > spelling symbols out letter by letter
> > using the new lisp function untern
> > (defun untern (u n t e r n))
> > daniel gres 2380
> dear jeff
> my qspace solver uses fprintf one num at a time over all formulas in all files of just a single directory until freddy krueger day occurs in theory and probably in reality
> daniel
// here is sublinear pattern recognition essence from 1997 after #P=#Q before aaai2000 and satisfiability 2002
// optimal identity recognition: (m + n/m) time
num hash(num shift,nums& syms,num p,num& lgm){/*0*/num answer=zero;for(num h=zero;h<lgm;h++){when(p+h<syms.size())answer=answer*shift+(syms[p+h]);}return(answer);}
num found = zero;// just count all finds one by one
num hashfind(nums& word,nums& stream,num& alphasize,numnums* work) //
{/*1*/num lgm=zero;num m=word.size();num n=stream.size();{num b=one;num tmp=m;while(tmp=tmp/alphasize){lgm++;b=b*alphasize;}for(num g=(*work).size();g<b;g++)(*work).add(new nums);}/*order of lgm*/
/*2*/for(num g=zero;g+lgm<m;g++)(*(*work)[hash(alphasize,word,g,lgm)]).add(g);/*order of m lgm*/
/*3*/for(num j=m+one-lgm;j+lgm<n;j=j+m+one-lgm){nums* bucket=(*work)[hash(alphasize,stream,j,lgm)]; for(num k=zero;k<(*bucket).size();k++){num beginat=j-(*bucket)[k];num there=one;for(num g=zero;g<m;g++){when(stream[beginat+g]==word[g])continue;there=zero;escLoop}when(there) found++;}}/*order of n lgm over m*/
/*4*/for(num g=zero;g<(*work).size();g++)(*(*work)[g]).clear();/*order of m */ return found; }//order (m + n/m)

On Saturday, November 20, 2021 at 12:39:03 AM UTC-5, Daniel Pehoushek wrote:
> On Saturday, November 20, 2021 at 12:19:35 AM UTC-5, Daniel Pehoushek wrote:
> > On Saturday, November 20, 2021 at 12:14:23 AM UTC-5, Daniel Pehoushek wrote:
> > > On Monday, November 15, 2021 at 12:10:46 AM UTC-5, Jeff Barnett wrote:
> > > > On 11/14/2021 6:32 PM, Daniel Pehoushek wrote:
> > > > > On Sunday, November 14, 2021 at 8:06:42 PM UTC-5, olcott wrote:
> > > > <SNIP>
> > > > > do all programming language interpreters and therefore compilers
> > > > > have a similar bug to rplaca in lisp like functional evaluators?
> > > > rplaca isn't a bug, it's an operator; a very normal one. Assume you are
> > > > using a programming language language where you can define a simple two
> > > > field structure or object, named cons, as
> > > >
> > > > structure cons (car pointer, cdr pointer);
> > > >
> > > > and you have a variable x of type cons. Do you think a statement such as
> > > >
> > > > x.car <- some pointer producing expression;
> > > >
> > > > is an error? The slight difference between that assignment and rplaca is
> > > > that rplaca returns x, while the statement (used as an expression if
> > > > allowed) will usually return either the new or old value in x.car -
> > > > depends on the language. By the way, common Lisp, allows the statement
> > > > or expression form and returns the new value.
> > > >
> > > > If you do not like assignments to structures (in the same way you do not
> > > > like cap letters), take that as your choice but nobodies error.
> > > >
> > > > I'm curious: In your code, do you every assign a value to a field in a
> > > > structure or mutate an object? In other words do you use rplaca in your
> > > > own code?
> > > >
> > > > BTW You might be interested that a fellow by the name of Erwin Book
> > > > coined the phrase "rplaca in haste, repent at your leisure!" in the late
> > > > 1950s or early 1960s.
> > > > --
> > > > Jeff Barnett
> > > dear jeff
> > > when i aced as a sophomore at leland stanford junior university
> > > professor john mccarthys graduate level lisp course
> > > the rplaca bug was an unsolvable problem in eval
> > > i am wondering if the bug is general to all or some
> > > computation by interpreters then compilers?
> > > and as i say i may have a solution by
> > > spelling symbols out letter by letter
> > > using the new lisp function untern
> > > (defun untern (u n t e r n))
> > > daniel gres 2380
> > dear jeff
> > my qspace solver uses fprintf one num at a time over all formulas in all files of just a single directory until freddy krueger day occurs in theory and probably in reality
> > daniel
> // here is sublinear pattern recognition essence from 1997 after #P=#Q before aaai2000 and satisfiability 2002
> // optimal identity recognition: (m + n/m) time
> num hash(num shift,nums& syms,num p,num& lgm){/*0*/num answer=zero;for(num h=zero;h<lgm;h++){when(p+h<syms.size())answer=answer*shift+(syms[p+h]);}return(answer);}
> num found = zero;// just count all finds one by one
> num hashfind(nums& word,nums& stream,num& alphasize,numnums* work) //
> {/*1*/num lgm=zero;num m=word.size();num n=stream.size();{num b=one;num tmp=m;while(tmp=tmp/alphasize){lgm++;b=b*alphasize;}for(num g=(*work).size();g<b;g++)(*work).add(new nums);}/*order of lgm*/
> /*2*/for(num g=zero;g+lgm<m;g++)(*(*work)[hash(alphasize,word,g,lgm)]).add(g);/*order of m lgm*/
> /*3*/for(num j=m+one-lgm;j+lgm<n;j=j+m+one-lgm){nums* bucket=(*work)[hash(alphasize,stream,j,lgm)]; for(num k=zero;k<(*bucket).size();k++){num beginat=j-(*bucket)[k];num there=one;for(num g=zero;g<m;g++){when(stream[beginat+g]==word[g])continue;there=zero;escLoop}when(there) found++;}}/*order of n lgm over m*/
> /*4*/for(num g=zero;g<(*work).size();g++)(*(*work)[g]).clear();/*order of m */ return found; }//order (m + n/m)
when after i wrote stanford qlisp when i deeply studied fibonacci
i did nay tell the professor that i had written an improved common lisp version of the mit emacs editor he used to love because
i wanted to read garey and johnson five times in graduate school then came the cheese man and oh boy was it
franco has surveyed that completely
daniel