On Problems

While I am not an etymologist, I find it fascinating how wrongly myself and others use words to convey a meaning wholly different from their definition, or use so many words to convey no meaning, or limit their lexicon when there are so many beautful words. This is my attempt to convey the weight of the term problem.

Ontology

The Oxford English Dictionary defines problem in two main contexts, colloquial and mathematical. The colloquial definitions defines a problem as something that is unwelcome, harmful, or difficult to someone or group. This is how most will use the term problem, but this gives the term a negative connotation and encourages the use of "I [have]", less than "This [is]". The mathematical definition, gets much closer to the root of the term: "an inquiry starting from given conditions to investigate or demonstrate a fact...".

This gives a much more broad interpretation of the term, since we can apply this to really any situation in which conditions arise to satisfy some thing. There are dishes piling up in my sink. and In two months we have an investor call to discuss the technical implementation our moonshot application are both problems, but on radically different levels of scope, ease, and simplicity. Thus, there are clearly attributes to a problem that define their type and relationships, or more succintly: an ontology.

To provide a basis for analysis, I state that a problem is:

A statement¹ that necessitates one or more requirements² to shift the current condition to the satisfied condition³.

If we go back to our first example, it could be that:

Object	Dishes pilied up in a sink
Current condition	All dishes are dirty
Satisfied condition	All dishes are clean such that they can be eaten off of again
Requirement	Dishes be cleaned to the satisfied condition

We also, must have assumptions about the current condition, that we desire to eat off these plates again, aspects of the requirements, etc. More importantly, the requirement generates a nigh-infinite number of actions that we could possibly take to clean the dishes, with a simple action being using soap, water, and a rag to clean the dishes and let them dry for three hours. Thus, the satisfied condition is achieved. The combination of object-entity, naught and want condition, set of requirements, and set of assumptions then makes up the problem space.

Of course, this problem is trivial, but the anatomy of problem space specification maintains for very large problems. Still, it is important to classify problems so we can

a) develop patterns for solving that type of problem
b) understand how useful solving this problem actually is.

First is understanding the base attributes. Problems can be simple (or one braid) constrasted with complex (interleaving or many braids). This is distinct from the attribute of being easy (something that lies near) and hard (takes effort, strong).

Washing the dishes is easy, since there is only one requirement, and the actions generated are largely degenerate (there are only so many feasible ways you can wash dishes until they are clean). It is also quite simple, since the requirement is not interleaved with another problem. I want to be very catious here, since the astute would argue there could be problems with the amount of dish soap left, or having no sponges, or my house is on fire , that prevent implementing the requirement (and satisfying the condition) and thus this problem is complex.

My solution to this problem, is to draw a limit to my definition.

Any problem statement containing a problem arising from a requirement not asserted by the statement nor reasonably relevant to the context does not add complexity to the problem at hand.

Here, we absolve ourselves of the theoretical, sacrificing some rigour for actual progress. Complexity will still arise, since many sub-problems (problems derived from requirements) are relevant to the object, but this is intentional. Now we can confidently state that washing the dishes is primitive (the most simple: no sub-problems) in nature , whereas the second problem (moonshot application) is not, its is highly complex.

A mistake after this discussion might be classifying all problems as simple and easy, or hard and complex. While many problems do follow this classification, ignoring the orthogonal classifications (simple and hard and complex and easy) create issues for your life. Ease (easy to hard) is a measure of how much effort something takes to satisfy, and generally the more time or effort is spent on these problems the more likely you will satisfy the condition. For example, washing dishes takes a bit of effort and time, but not much skill. Ease is also a relative concept, since what lies near to me is not the same as you (say finding the location for a restroom in france - I don't know french).

Complexity (simple to complex) is a measure of how much interleaving or braids exist. Simple problems are not simple due to a lack of cardinality (i.e few requirements), but a lack of interleaving.

To use a few examples from computer science, methods are complex while functions are simple. State is complex. Abstraction is a unique construct in the sense that it can modify simplicity based on implementation. Complex problems are difficult, and thus are gauged not on the effort or time but skill or itellect.

Thus, we can see that there are many problems which are complex yet easy or simple yet hard. I need to gain 5 lbs. of muscle is a simple problem, but it is quite hard. It is simple since the requirements required to satisfy the condition (sleep, lifting schedule, cardio schedule, diet) are clear, and do not interleave much with eachother. While lifting performance is tied to sleep, there is not much dependency beyond sleep X hours. Meditation is the hardest simple problem.

Application

While the above section is important to understand, it is less important for those desiring to practice.

Practice is defined here as any operation that provides or improves the actor’s qualifiacation for the next performance of the same operation, whether it is declared as practice or not. Peter Sloterdijk

Statement

Writing a problem statement lies in the ability to know what the problem you are trying to solve is, and what is the solution you desire. These skills are in the minority.

Breath, relax, and capture. Prepare a unstructured survey of the space. Try to understand, why are you in this position, what are its conditions, and where would you like to be? Then conform this into a statement, of the form previously discussed.

Survey I am finding it hard to align my time with my broader goals of mine. And when I do, I have a hard time of remembering how much time I spent on solving something, or when, or how long blocks of time relate to what or how well I am solving something. I don't have a good repository of time tracking? When I have tried to use other techniques, many (like software) are too involved and require extensive planning. I don't desire to perform too much upkeep. (Myself, two weeks ago.)

Cleaving from this survey, a statement, a set of requirements, and null/satisfied conditions.

Object	My time spent on projects of seriousness.
Current condition	The object is unable to be logged, labeled, nor reviewed.
Satisfied condition	Inverse of current condition.
Requirement	Log a given time span for a specific task for a specific project.
Requirement	After a time span, comment on how well the work went.
Requirement	Be able to view the history of time spans for a given project
Requirement	Be able to view an aggregate or gantt of my time for a givem time window

To be able to log, label, and review aggregates of time I spend on my projects of serious.

Very few people are able to perform this without training. We are now able. We have developed a pattern for defining problem statements (a solution to a problem in-of-itself).

Decomposition

I have only listed four requirements, but in reality there are so many more. Most futher requirements for solving this time-tracking dilemma stem from these four basis requirements, effectively defining sub-requirements, or conditions to the requirement. In fact, the four requirements themselves are necessarily derived from the nature of resolving the null condition to the satisfied one (that is, there exists some basis requirements that follow a priori from conditions).

Thus, the skill of decomposition becomes as simple as applying, and reapplying our condition-based thinking to each requirements. Treat the requirement as the object (or the satisfied condition), and find the requirements to satisfy it. Limit looping, as it is not an exercise in atomicity, but in execution. I make no comment on the mode of execution (how you should work), there are myraid methods of that (project tracking, whiteboarding, first principles, etc), but decomposition allow us to de-abstract the problem into actions from requirements.

Patterns

Decomposition will generally simplify a problem, by unwinding interleaving in problem statements, but this process takes alot of mental energy. Thankfully, we have memory, collective and personal.

It is helpful to think of condition satisfying (problem solving) as a graph (particularly a dag), and that for a set of graphs of solved problems {P}, we can take a subset {P'} of related solutions to the problem we want to solve {u}, and partition a given path (condition satisfaction of one requirement in a given order) and compose that with others to form the solution to {u}. Or to keep it simple, can I solve this similar to anything anyone has done previous?. I encourage you to practice pattern matching problems, and when you find one, name it and write it down.

Corollary In every collection of solved problems exists the null operation, a problem solved by nothing. That is, after reviewing the requirements and conditions, you realise the best pattern to apply is not solving or ignoring the problem. It might be your best tool.

Ok

Relax, breath, and survey the situation. Form it into a statement of requirements for satisfying the condition of interest. Decompose and pattern match, then do. It's all possible.

Endnotes

1. My first proposed definition was: A statement put forth of one or more conditions to complete a requirement or demonstrate a fact. While this is satisfactory, "completing a requirement" is so vague that is not useful, and doesn't represeent how condition change is the true nature of a problem. Furthermore, a problem necessarily defines the requirements, not necessarily the conditions.
2. While I am relatively convinced of my recursion limit arguement for ignoring theoretical sub-problems, I have not given this enough though and look forward towards your responses.
3. I intentionally wrote very little on modes of solving, as test monograph was quite long already, and that it isn't very relevant to discussing problems. That seems contradictory (after all what is the point of problems if not to solve them), but that is a problem of perspective: you can draft a technically correct statement, utilise patterns based on concrete requirement orders, yet be terrible at doing anything (a.k.a. stroking the problem.). Vice versa, many genius will succeed with no planning.
4. Have you tried solving the problem?
5. Have you tried not having the problem?

Errata