Formalism, correctness, cost

Introduction

Idea
- Many ways of doing things
- Better the method, formalism
- Better the deliverable
- Better the correctness
Proposal
- A good / better definition of
- Formalism and correctness

Process

When we do something
We execute a process
- Which yields deliverables
- Based on an input

\[\begin{gather*} Input\xrightarrow[\text{}]{\text{Process}}Deliverables \end{gather*}\]

\[\begin{gather*} Problem\xrightarrow[\text{}]{\text{Thinking}}Solution \end{gather*}\]

\[\begin{gather*} Design\xrightarrow[\text{}]{\text{Programming}}Code \end{gather*}\]

Many ways of doing

When we do something
We can do it in many ways
- For the same Input
- We can have different Output

\[\begin{gather*} Input\xrightarrow[\text{}]{\text{Process 1}}\text{Deliverable 1} \end{gather*}\]

\[\begin{gather*} Input\xrightarrow[\text{}]{\text{Process 2}}\text{Deliverable 2} \end{gather*}\]

Method

The way of doing it
Affects the deliverables
- Quality
- Quantity
- Cost
- etc.

\[\begin{gather*} \tiny{\text{Method 1 (quality 1, cost 1, ...)}}\\ \text{Input }\to\boxed{\xrightarrow[\text{}]{\text{Process 1}}\text{Deliverable 1}} \end{gather*}\]

\[\begin{gather*} \tiny{\text{Method 2 (quality 2, cost 2, ...)}}\\ \text{Input }\to\boxed{\xrightarrow[\text{}]{\text{Process 2}}\text{Deliverable 2}} \end{gather*}\]

Examples

Input	Process	Deliverable
Names of capitals	Information gathering	Table
What is an LLM?	Understanding	Document
A to-do list app	Software development	Code

Names of capitals

Process / Method	Cost	Deliverable	Correctness
Remembering	Minimal	Table Incomplete	Probably not
Gathering data from Wikipedia	Affordable	Table Complete	Yes

What is an LLM?

Process	Method	Cost	Deliverable	Correctness
Reading	Taking notes	Minimal	Document Plain English	Subjective understanding Not verifiable
Reading	The scientific method ¹	Affordable	Document Structured	Objective understanding Verifiable by peers
Reading	Formal method ² ³	Expensive	Math model	Theorem provers Fully verifiable

To-do list app

Process: MVP-style ¹ software development ²

Step ³	Method	Cost	Deliverables	Correctness
Specification	Taking notes	Minimal	Document Plain English	Subjective understanding Not verifiable
Implementation	Just write code	Minimal	Code Imperative	Verifiable by tests
Verification	Write some tests	Affordable	Test suite	By 100% code coverage

To-do list app

Process: Production-ready software development

Step	Method	Cost	Deliverables	Correctness
Specification	Design in practice ¹	Affordable	Document Structured	Objective understanding Verifiable by peers
Implementation	Finite-state machine ² Pattern matching ³	Affordable	Code Declarative⁴	Built-in correctness mechanisms The rest verifiable by tests
Verification	Property-based testing ⁵	Affordable	Test suite	100% code coverage

To-do list app

Process: Mission critical ¹ software development

Step ²	Method	Cost	Deliverables	Correctness
Specification	Formal specification ³ Theorem building	Expensive	Math model	Yes
Verification	Formal proof Theorem proover	Expensive	Math model	Yes
Implementation	Obtained ⁴	Affordable	Code	Yes

Chaotic, complex

Methods	16	Remembering Gathering data Taking notes …
Deliverables	8	Table Document Code …
Correctness	9	Probably not Subjective understanding Not verifiable …

Let’s start with deliverables
Familiar, less chaotic

Deliverables

Country	Capital
Abkhazia	Sukhumi
Afghanistan	Kabul
…	…
Zimbabwe	Harare

Table

"""Migrate a Sim to a Sim2"""
def migrate_sim(sim::Sim):
  init_sys = System2(sim.cell, sim.atoms)
  final_sys = unknown(init_sys.cell.pbc)
  return Sim2(sim.calc, init_sys, final_sys)

for old_sim in get_sims(old_db_cxn):
  insert_sim(migrate_sim(old_sim), new_db_cxn)

new_query = "SELECT S1.pth, S2.pth FROM ..."

Code

it("Works, with default props", () => {
  const result = generateId(validInputData);
  expect(result).not.toBeNull();
});

it("Fails safely, with invalid or missing props", () => {
  const result = generateId();
  expect(result).not.toBeNull();
});

Test suite

Syntax

All deliverables have a
- Form
- Format
- Syntax
These forms are all different
- Because they represent
- Different levels of formalism

Formalism

Syntax	Formalism	Notes
Table	Strong	Row, column, cell
Document Plain english	None	Free form Typographic structure only
Document Structured	Some	Strict form Follows the scientific method
Code Test suite Math model	Strong	Precise, formal language

Syntax, formalism, correctness

Syntax	Formalism	Correctness
Table	Strong	Yes
Document Plain english	None	Subjective understanding Not verifiable
Document Structured	Some	Objective understanding Verifiable by peers
Code	Strong	Yes Built-in correctness mechanisms The rest verifiable by tests
Test suite	Strong	Yes 100% code coverage
Math model	Strong	Fully verifiable Theorem provers

The stronger the formalism
Better the deliverable, syntax
Better the outcome, the correctness

Syntax alone is not full correctness

A deliverable might be syntactically correct
Yet completelly wrong

Country	Capital
Abkhazia	~~Sukhumi~~ `Washington, DC`
Afghanistan	Kabul
…	…
Zimbabwe	Harare

Semantics

It’s meaning
It’s obtained from syntax

Deliverable = Syntax + Semantics

Every deliverable has
- A form
- Format
- Syntax
Which when executed gives
- The meaning
- The semantics

Verification, correctness

If both the
- Syntax
- Semantics
Is correct
Then the deliverable is correct

Correctness

It’s complex
- The product of a long process
There is no
- Generic definition of correctness ¹
Every deliverable type
- Has its own definition of correctness ²

Deliverable type	Defintion of correctness
Table	Rows, columns, cells must be correct
Structured document for understaning	Must follow the Scientific method ¹ Observation -> Question -> Hypothesis -> …
Formal specification ²	Logically consistent Accurate Complete
Code ³	Functional correctness Partial correctness Total correctness

Can we simplify correctness?

The notion, the concept
To have a general definition
Compatible with all deliverable types

Something like in formal methods ¹

Formal methods already connect deliverable types and levels of correctness

Method	Deliverable	Correctness
Informal	Free form, natural language	Ambiguity and lack of organization can lead to incompleteness, inconsistency, and misunderstandings
Formatted (Semi formal)	Standardized syntax	Basic consistency and completeness checks Imprecise semantics implies other sources of error may still be present
Formal	Syntax and semantics rigorously defined Precise form, perhaps mathematical	Eliminate imprecision and ambiguity Provide basis for mathematically verifying equivalence between specification and implementation

A proposal

Types of correctness

Provably correct
- As in exact sciences
- Like math, physics
Likely correct
- As in non-exact sciences
- Like sociology
Maybe correct
- No scientific method behind
- Might be correct, or not

Provably correct

From formal / natural sciences
- Mathematics, optics, astronomy, physics
- Linguistics, comparative philology
“Absolute precision in their results” ¹
“Applying a purer form of the scientific method” ²

Likely correct

From social science ¹, social research ²
- Anthropology, archaeology, …
- Economics, communication science, …
Applying the scientific method ³
- The hypothesis is supported, but it’s not proven

Likely correct

As an example, suppose we have the hypothesis that all apples are red, and we test this hypothesis by examining a group of ten apples and seeing what color they are. If all ten apples are red, our hypothesis is supported, but it’s not proven: if we looked at more apples, some of them might turn out to be green. ¹

Provably vs likely

Provably correct
- Always works
- There is a rock solid proof
Likely correct
- It works most of the cases
- It might break on edge cases

\[\begin{gather*} \tiny{\text{Provably correct, it's a proof}}\\ \text{Input }\to\boxed{\xrightarrow[\text{}]{\text{Process 1}}\text{Works 100%}} \end{gather*}\]

\[\begin{gather*} \tiny{\text{Likely correct, fails on edge cases}}\\ \text{Input }\to\boxed{\xrightarrow[\text{}]{\text{Process 2}}\text{Works 100% - edges}} \end{gather*}\]

Correctness and formalism

Provably correct ⬅️➡️ Formal method
Likely correct ⬅️➡️ Semi-formal method
Maybe correct ⬅️➡️ Informal method

\[\begin{gather*} \tiny{\text{Formal method, Provably correct}}\\ \text{Input }\to\boxed{\xrightarrow[\text{Semantics ✅}]{\text{Syntax ✅}}\text{Works 100%}} \end{gather*}\]

\[\begin{gather*} \tiny{\text{Semi-formal method, Likely correct}}\\ \text{Input }\to\boxed{\xrightarrow[\text{Semantics ❓}]{\text{Syntax ✅}}\text{Works 100% - edges}} \end{gather*}\]

Cost ¹

Theorem provers may be used to undertake fully formal machine-checked proofs. Despite improving tools and declining costs, this can be very expensive and is only practically worthwhile if the cost of mistakes is very high (e.g., in critical parts of operating system or microprocessor design).