Cost, probablity and problem solving

[Doubt]

How much does it cost to solve a problem?

More precisely, how much does it cost to solve a problem when you don’t know ahead of time if your prospective solution works?

I have an idea here and would like to know if those who are better at math than me can tell me if I am on the right track. There is a very good chance that I am re-inventing the wheel here. Those familiar with this subject feel free to point me in the right direction. I suspect this is part of game theory. I have been out of school for a long time.

If I have two possible solutions to a problem, how do you pick between them?

As best I can figure, a formula like the following would be useful:

Predicted expenditure = [Total cost of solution A] + [(1 – probability of success of solution A) x (Total cost of solution B)]

With variables in place (I am using lower case here just to avoid subscripts):

Ea = A + [(1 – Pa) x B]

For the alternative solution:

Eb = B + [(1 – Pb) x A]

Where Ex is the likely cost of implementing a solution. A is the cost of solution A, B is the cost of solution B, Px is the probability that a given solution will solve the problem.

The key to this is idea is the cost of failure. (1 – Px) is the probability of a solution not working.

Assumptions:

1. Any solution that is not a complete success is a failure. (Either it works or it does not.)

2. There are only two likely solutions to the problem. (I have tried using a spread sheet for a third possibility but noticed that the cost changes for a third solution were not very large but the formula quickly became cumbersome.)

Okay gang. Have at it! Did I explain this well? Does this work? Who before me has come up with this? Do I have a hidden assumption here that I missed?

I suspect this would be part of game theory, but I have no training in that sort of thing other than knowing basic probabilities.

 

[Cuddles]

I think the biggest problem is that you are assuming you know the probability of the solution working.

 

[Doubt]

I think the biggest problem is that you are assuming you know the probability of the solution working.

True.

That is a problem, but does not render the idea useless. It possible to make assumptions about what types of solutions are more likely to work than others.

As an example, a solution that has worked in the past on a similar problem can be assigned a probability higher than a previously untried solution on an unfamiliar problem.

 

[drkitten]

I think the biggest problem is that you are assuming you know the probability of the solution working.

A bigger problem is the assumption that solution B will solve the problem.

It's not a bad quantification otherwise. If 'A' is the solution you'll try first, you'll spend the money on it no matter what. If you will then try solution 'B', you'll spend the money on it only if 'A didn't work (i.e. with probability failureProbabilityOf(A) which is 1-successProbabilityOf(A)).

If you have a third string to your bow, add a third term which is the cost of C times the failure probability for both A and B.

If you have a fourth, add a term which is the cost of D times the joint failure probabilities of A, B, and C.

And so forth.

 

[Doubt]

A bigger problem is the assumption that solution B will solve the problem.

It's not a bad quantification otherwise. If 'A' is the solution you'll try first, you'll spend the money on it no matter what. If you will then try solution 'B', you'll spend the money on it only if 'A didn't work (i.e. with probability failureProbabilityOf(A) which is 1-successProbabilityOf(A)).

If you have a third string to your bow, add a third term which is the cost of C times the failure probability for both A and B.

If you have a fourth, add a term which is the cost of D times the joint failure probabilities of A, B, and C.

And so forth.

I have played around with having a third option. Without a spreadsheet it would have been serious labor. With a spreadsheet, it was just an annoying pain in the rear.

To use it for a cost analysis, having a third option available does not have much effect on the Ex result. It was easier (for me at least) to run 3 pairs of of combinations rather than constructing sheets for more options.

Part of that may be doing it using a spreadsheet. But I am not going to start relearning programming again just to construct a program to select between several options since that is not what we usually run into.

My employer builds rather expensive equipment for factories and I am the guy in the field getting it all running. Having more than one option to try is not uncommon. Having three available in the middle of troubleshooting is rare. Getting the office to consider more than one option at a time is the real goal behind putting this idea together. And the solutions offered are often the lowest cost options without due consideration to the probability of success.

 

[Cuddles]

That is a problem, but does not render the idea useless. It possible to make assumptions about what types of solutions are more likely to work than others.

As an example, a solution that has worked in the past on a similar problem can be assigned a probability higher than a previously untried solution on an unfamiliar problem.

Sure, you can assume things. But then you have the whole problem of garbage in, garbage out. If you're going to make up the inputs, you may as well just make up the final answer and not bother with the maths in the middle.

 

[Doubt]

Sure, you can assume things. But then you have the whole problem of garbage in, garbage out. If you're going to make up the inputs, you may as well just make up the final answer and not bother with the maths in the middle.

I think you are missing the point to all of this. The idea here is not to predict the actual cost but determine the solution that is likely to cost the least between two alternatives. The following list is what I intend to use along with assumed probabilities assigned for each category:

1. Solution known to work in identical applications.
2. Solution known to work under similar circumstances on similar equipment.
3. Solution known to work on different equipment.
4. New solution to an old problem.
5. Solution should work based on available information.
6. Unique problem or solution.

Category 1 would be assigned the highest probability and category 6 the lowest. The order of 4 and 5 is questionable. Category 1 would be given an initial value of around 0.9. It could not be be given a 1.0 since room must be left for the possibility of the problem being incorrectly understood.

Over time, the assumed probabilities could be replaced by historical values if the success of the proposed solutions were tracked. But first their needs to be a reason to use the categories and track them.

So the numbers may not be precise to start with. But existing experience is enough to rank certain solutions as more likely to be successful than others. The assumed probabilities are a means to an end. I would avoid starting with assumed probabilities if I had hard numbers available. But nobody is going to track success rates if there is no application for them.

First I need the application. Then I can work on the accuracy.

 

[Myriad]

Another implicit assumption here is that there is no significant cost associated with the delay in implementing the solution, if the first method attempted should fail.

That may or may not be realistic, depending on the nature of the problem and the time scales involved in implementing the various contemplated solutions. The cost of delay might be very low or very high. (But it cannot be zero, or else you would not have a problem in the first place!)

That's why solutions like "hit it with a mallet" (for mechanical devices) or "try powering down and back up" (for electronic devices) are usually good choices to try first. Their cost is very low and they don't take much time, even when their probability of success is low.* In most situations if you order and install a replacement computer before even attempting to reboot the one you had, you're likely to be fired.

However, "wait indefinitely to see if the problem fixes itself" is an even lower cost solution and so would always come out as the choice to be tried first despite a very low probability of success, unless the cost of delaying an effective solution is taken into account.

*That is not to imply that the probability of success of these solutions is necessarily low.

Respectfully,
Myriad

 

[Doubt]

Another implicit assumption here is that there is no significant cost associated with the delay in implementing the solution, if the first method attempted should fail.

That may or may not be realistic, depending on the nature of the problem and the time scales involved in implementing the various contemplated solutions. The cost of delay might be very low or very high. (But it cannot be zero, or else you would not have a problem in the first place!)

That's why solutions like "hit it with a mallet" (for mechanical devices) or "try powering down and back up" (for electronic devices) are usually good choices to try first. Their cost is very low and they don't take much time, even when their probability of success is low.* In most situations if you order and install a replacement computer before even attempting to reboot the one you had, you're likely to be fired.

However, "wait indefinitely to see if the problem fixes itself" is an even lower cost solution and so would always come out as the choice to be tried first despite a very low probability of success, unless the cost of delaying an effective solution is taken into account.

*That is not to imply that the probability of success of these solutions is necessarily low.

Respectfully,
Myriad

I have given thought to that. A fair assessment of the cost must also involve the time involved. That also includes the associated expenses such as per diem, hotels and transportation.

Since I am the field guy, I can tell you that this would not be coming into play until after we got past the "hit it with a mallet" stage. From a practical view point, anything that does not involve new materials is going to get tried first just because that is easy. That can even involve re-writing software in the field, since I end up doing that a lot.

But once we get to the stage of handing the problem back to engineering, we need a better assessment.

One of the incidents that got me working on this was a case where we did a 24VDC controls system, which is what the customer wanted instead of the usual 110VAC system. Some large actuators failed repeatedly. Smaller DC relays in the system worked just fine. Engineering made 3 unsuccessful design changes for the large actuators to get them to work that involved a few new components and replacements for the fried coils in the actuators. I would classify there efforts under category 5 from my last post.

My co-worker and I in the field wanted to switch back to 110VAC actuators. The customer did not have a problem with that. We had 110VAC power available in the cabinet but would need new fuses and new actuators. I would have put this in Category 2 from my list. But the material cost was a little higher. This is what we ended up doing.

No head to head analysis of the solutions was done. We were trying to do what ever engineering came up with first rather than what we knew was most likely to succeed.