Re: filling area by color atack safety

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On 16/03/2024 13:55, Ben Bacarisse wrote:

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
 

Recursion make programs harder to reason about and prove correct.

Are you prepared to offer any evidence to support this astonishing
statement or can we just assume it's another Malcolmism?

>
Example given. A recursive algorithm which is hard to reason about and
prove correct, because we don't really know whether under perfectly
reasonable assumptions it will or will not blow the stack.

Had you offered a proof that your code neither "blows the stack" nor
runs out of any other resource we'd have a starting point for
comparison, but you have not done that.

Mind you, had you done that, we would have something that might
eventually become only one piece of evidence for what is an
astonishingly general remark.  Broadly applicable remarks require either
broadly applicable evidence or a wealth of distinct cases.

Your "rule" suggests that all reasoning is impeded by the presence of
recursion and I don't think you can support that claim.  This is
characteristic of many of your remarks -- they are general "rules" that
often remain rules even when there is evidence to the contrary.

I'll make another point in the hope of clarifying the matter.  An
algorithm or code is usually proved correct (or not!) under the
assumption that it has adequate resources -- usually time and storage.
Further reasoning may then be done to determine the resource
requirements since this is so often dependent on context.  This
separation is helpful as you don't usually want to tie "correctness" to
some specific installation.  The code might run on a system with a
dynamically allocated stack, for example, that has very similar
limitations to "heap" memory.

To put is more generally, we often want to prove properties of code that
are independent of physical constraints.  Your remark includes this kind
reasoning.  Did you intend it to?

--
Ben.