Uncertainty and probability issues

[gcassel]

Uncertainty is a fundamental aspect of natural sciences, and an important although IMO underdeveloped part of game theory. (Not underdeveloped so much because of lack of awareness or interest, but because it's damn tricky stuff.)

I bumped into this new blog: https://medium.com/guesstimate-blog/introducing-guesstimate-a-spreadsheet-for-things-that-aren-t-certain-2fa54aa9340#.xloa48kaf I'm not aware of anything quite like it: an open source project for probability-based spreadsheeting. I reckon that such tools can quite easily be misused, but can also be fundamentally useful.

I think that expressions of uncertainty should ideally be be available for recipes and plans in Processes, especially for physical processes and models of natural systems. Like I said earlier, probability in game theory is damn tricky, and this inevitably influences systems (designed OR naturally emergent) which are at least partly described by input-types by Agents in one or more defined roles. I reckon this practically limits the applicability of probability not only to multi-Agent Processes, but also to Economic Actions.

A few questions:

1. Does anyone think there are any rational places in the existing Value Flows taxonomies to apply the concept of uncertainty?
2. Does anyone foresee that uncertainty will fit in to taxonomies which haven't developed here yet?
3. Is anyone aware of anything else like that Guesstimate project?

[ahdinosaur]

cc @donlewi, since we just had a conversation about using Value Flows to model operational risk.

[bhaugen]

Back in the day, in PERT charts, "each task has three time estimates: the optimistic time estimate (o), the most likely or normal time estimate (m), and the pessimistic time estimate (p)." https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

In practice, I don't know anybody except maybe military projects that used them. Critical paths were useful, but all of those estimates were always wrong and thus were wasted effort. In real life, the best way to manage projects was a lighter-weight schedule, watch dependencies, and coordinate them constantly.

[gcassel]

I'm not personally thinking of uncertainty in time estimates. I agree that the lighter-weight schedule with coordination, such as kanban, makes much more sense. I think of uncertainty more with respect to people deciding which objectives to pursue, and which processes to invest in, to begin with.

[danalexilewis]

So I definitely see a need for being able to model possibilities within VF. I see it as modeling the effect on resources and/or agents given a certain event.

Use case type: Operational risk assessment Given a set of resources And a set of hypothetical events and consequences When I apply the model Than I can see the outcome on the resources

Use case: Taxi Driver Given I have a taxi of value 50k And I make 2k per week And I have no plan for what to do if my car breaks down for 1 week, 2 weeks or 3 weeks When I apply the model Than I can see I would lose 2k, 4k and 6k respectively

Use case: Taxi Driver Given I have a taxi of value 50k And I make 2k per week And I plan to use the mechanics car for 1 week, hire a car for $500/w if its 2 or 3 weeks When I apply the model Than I would earn 2k, 3k and 4.5k respectively

etc...

I am not a trained risk assessor - my cousin is. I just get the gist of the process. The next step is you start assigning risk likelihoods to scenarios and than can do some math to tell you which scenario is the best to put energy into changing.

Another use case: When to sell my car? I want to a live model that tells we when to keep driving and when to sell it and buy again. The variable inputs would be the cost of running it: fuel consumption, maintenance cost and cost of replacement. The point is there would be a model that would inform me whether the sell event should occur. I think this model belongs to the resource, I have been using the word plan to describe this.

So @gcassel i am not sure if this is what you meant by uncertainty? It is what I think you are meaning. modeling the consequences of an uncertain event.

@bhaugen Pert looks pretty cool - definitely going to look at that a bit more.

[gcassel]

Yes @donlewi , everything you wrote above is right up the tree I was barking at!

[gcassel]

I believe that people incorporate probability and risk assessment into their decision processes, both individually and collectively, whether it's formalized or not. Usually it's entirely informal, and for good reason.

For instance, I may quite roughly intuit that there's roughly a '50/50' chance that I'll fall to my death if climb along the edge of a certain cliff. In all likelihood, it would be an extremely unrealistic waste of time to ambitiously try to calculate a specific probability of fatality, even if I applied a broad standard deviation to the number I generated. I'm probably just going to stay away from that cliff edge.

It's only rational to calculate probabilities when our intuitions, and/or qualitative analyses, fail to clearly suggest which decisions or actions are preferable, and the cost of calculation seems to be lower than the cost of not calculating. -- The cost of calculating is much more likely to be justified during the development of standardized recipes or models of organization, than it would be in dealing with relatively specific or unique situations.

With all that in mind, I tend to guess that PERT time estimation was essentially a good concept which was way overdone. It's irrational to spend much time developing predictions about future events which will involve many unpredictably changing conditions along the way. (Which is the case IMO with all multi-agent systems.) However, it's rational to make rough estimates before decisively investing significant resources in any objective or plan, such as a minimum viable product experiment which may iterate heavily based on ongoing feedback-- or, an industrial system which incorporates coordinating signal systems such as kanban.

My specific criticism against excessive probability/risk assessment seems applicable to excessively detailed planning of any sort, as in 'waterfall' design vs. lean and agile processes. I am 'just' choosing not to ignore potentially predictable uncertainties.

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/49.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.