Tuesday 12 February 2008

On correctness -- Correct is Good!

Radical engineering principle: on correctness

Memento:

Engineering principles are true by good convention.

Principle:

Correct is good! Period.

Comment:

As far as it passes systems testing, a system is "correct", and the problem becomes "good" testing.

Extended:

We do solve the halting problem in everyday life, though asymptotically: up to the next failure.

Hint:

Consider the full set of systems for a given problem: IS* = S + oo + 0/0, where S is the set of bounded correct systems, oo is the set of full-correct systems, and 0/0 is the set of failing systems. IS* so defined can be treated in terms of interval arithmetic.

References:

G.W. Walster, "Introduction to Interval Arithmetic", 1997 (slightly adapted):

The interval paradigm has a number of valuable characteristics, including:
1. Fallible data can be represented using intervals.
2. Any arithmetic computation can be performed with guaranteed bounds on the set of all possible results.
3. Bounds can be provided on errors from all sources:
  • observation or measurement errors;
  • modeling errors;
  • machine rounding errors; and
  • interactions among all of the above and the inherent instability of the problem.
4. Problems can and have been solved that are otherwise thought by many mathematicians, scientists and engineers to be in principle unsolvable. Exemplars include:
  • nonlinear systems of equations; and
  • nonlinear programming (or nonlinear global optimization).
For additional information on interval arithmetic and how it can and has been used to compute guaranteed bounds on answers to otherwise unsolvable problems, see:

[*] As an alternative link: http://web.archive.org/.../walster-papers.html

Credits:

Thanks to the invaluable support I got from the sci.math group (no endorsement implied): Computing infinity modulus and zero modulus.

Monday 11 February 2008

On refactoring -- You should clean up!

Radical engineering principle: on refactoring

Memento:

Engineering principles are true by good convention.

Principle:

You shouldn't refactor, you should clean up!

Comment:

You can refactor when finished, i.e. never.

Extended:

Clean up before and after yourself.

Hint:

You can be many, but you can't be one.