# Refining 'simplicity'

Sun, Aug 30, 2020 ❝Refining the definition of simplicity: 'specific' becomes 'dedicated', 'deoptimized' becomes 'unoptimized'.❞## Contents

**2021-10-24** Most if not everything in this post has been superseeded on account of further insight into the subject. It is best to skip this post, as it will likely add confusion rather than clarification.

In “The definition of simplicity” I explained my proposal for how to define simplicity, such that this “intangible” concept can be expressed as a property triple. A good definition of simplicity should “feel” correct in the same way we all “*feel*” what it is for something to be “*simple*”.

Original definition:

simple = specialized & deoptimized & reduced

Previously I defined *simplicity* as such and explained how all three properties are complementary. However, one property ‘*specialized*’ was difficult to define. Or rather, the meaning is okay but the word, chosen to represent this property, seemed “*off*”. Furthermore, ‘*unoptimized*’ is preferred over ‘*deoptimized*’.

## Definition

The new definition for simplicity:

`simple = dedicated & unoptimized & reduced`

## Property *Dedicated* (prev: *specialized*)

*Dedicated* - more than *specialized* - expresses this requirement for *simplicity*.

The example `power(x, 2)`

shows how a function capable of arbitrary-size power computations can do a power-of-2 computation. However, the formula `x * x`

is more dedicated to the problem at hand.

The generalized `power(x, 2)`

-computation can *also* compute a power-of-2 computation and *will* produce a correct result. It is, however, intended for arbitrary-size computation of powers. A more dedicated method fits the problem more precisely. It expresses the intention and illustrates the original problem more clearly. The more variation possible, the less dedication to the problem at hand. This shows in more elaborate ways of computing, more cases to distinguish, and therefore more complication.

## Property *Unoptimized* (prev: *deoptimized*)

*Unoptimized* rather than *deoptimized* better represents the property, because *deoptimized* suggests that there was already some optimization performed that needs to be undone. This is typically not the case. Instead, *unoptimized* better indicates that *optimization* has not yet been performed.

The example `x << (log₂ x)`

to square `x`

shows an optimized solution. This works given the way in which the number is stored. In *unoptimized* form, it is:

```
x * x
```

## Changelog

**2021-10-13**:

- in Questioning the scope of simplicity we double-down on the choice to use “dedicated” as the name for a property. We conclude that the question influences the upper bound of the quality of an answer. “
*specific*” as we mention here, actually refers to the question, while “specialized” refers to the corresponding answer. - in the post Bad example demonstrates failure in complexity a mistake in a trivial math expression was documented. The remnant of that is fixed.