On 11/3/2025 3:36 PM, Tristan Wibberley wrote:
On 03/11/2025 20:19, Alan Mackenzie wrote:
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 03/11/2025 10:05, Mikko wrote:
Identical codes mean the same and specify identical behaviours.
... with respect to closure.
You've used the word "closure" quite a number of times. What do you
mean by it? It's beyond my powers of guessing from context.
Well, we can see it from a couple of perspectives and find the same
result so I'll avoid the hours of checking what I say and be a bit loose.
A program (or subprogram) that doesn't define everything itself refers
to a definition provided elsewhere. In essence, the provision of the
missing piece is closing with a closure. Some of them are lexical, some dynamic, I'm sure there are other kinds. Personally I also don't see I/O
as being an awful lot different but I don't know what meaning is
assigned conventionally everywhere.
I feel even procedure arguments can be seen as a closure though we tend
not to talk about them like that in programming as seen conteporarily.
In formal systems the concept of closure appears when defining its
objects and it seems to me to be highly related. The meaning of an
operation that constructs an object is progressively completed by
applying its arguments until the consequence of the operation is fully specified whereupon it is closed and the arguments were its closure.
To go further into how it applies here and where it might but isn't
relevant is a whole essay with lots of care needed, so I won't. I don't
say this to sound all secretly knowledgable because I'm not, but I mean
to point to what I think is the relevant concept for understanding
Olcott's situation statement without saying anything egregiously wrong
and without taking forever.
I tested my terse position statement with the LLM's
and only Claude AI got it.
When I got ChatGPT to get it I got ChatGPT to write up
its understanding so that it would get it right away in
a future session. Grok didn't quite get this so below
is the simplest version that they all understand.
It may simply be that the people here just don't have
enough attention span to make sure that they pay 100%
complete attention to ALL of these details.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The function H is a simulating termination analyzer:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated
"return" statement: return 1.
When given a function P, it literally simulates each
step of executing P() to see whether that simulated
execution ever reaches a return statement. Now let H
simulate D. Based only on the outcome of that literal
simulation (not on reasoning about what should happen),
what result should H(D) produce?
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)