Daily Shaarli

All links of one day in a single page.

June 4, 2021

Business, The Octopus Game - Commonplace - The Commoncog Blog

What makes this doubly hard is that you’re competing with every other player for a central pool of resources and actions. Being denied access to a particular resource or action prevents you from completing the necessary improvements in time, which then blocks the development of other elements of your farm. For example, feeding your family with livestock is a very efficient way of generating food, but this strategy requires a cooking hearth, which in turn requires clay and a build action, and of course an assortment of animals (sheep/pigs/cows). Collecting livestock requires fencing in portions of your farm to hold them, which in turn requires wood, which in turn requires taking turns to collect the wood, which prevents you from developing other parts of your farm you’ll be scored on like tilling land and sowing grain/vegetables.

The Most Expensive Number in Engineering - An Engineering Self-Study

n essence, you gather up all the inputs you can think that might affect your structure. Then, rather than determining a single number for that input, you assign a probability function to it. Instead of saying that a chair will experience 150 pounds of force, you say that the chair will experience anywhere from 100 to 200 pounds, with a 10% chance of it being 100 lbs, 50% chance of it being 150 lbs and so on. That probability function requires data -- you might look up statistics on people’s weights or survey your friends.

Once you’ve determined the probability functions for all of your inputs, you condense them down into two functions. One that describes the forces at work and one that describes the structure’s strength. The part of the graph where they overlap is where the forces might exceed the strength, and your structure might break. That overlap can be measured to give a firm number -- the probability of failure.

That is the biggest difference between the two approaches. Probabilistic design acknowledges that there is always a probability of failure -- even if it’s infinitesimally small. The factor of safety is much more black and white. Clear a certain bar and your structure is deemed safe, without qualification or nuance. Of course, nothing ever has a zero chance of failure.

Probabilistic design also allows you to measure the effect of changes on safety. You can determine how much safer your chair is if you tighten its manufacturing tolerances or forbid your friend Bill from sitting in it.  On the flip side, it requires more information as well. There must be good data or the result will be as arbitrary as the factor of safety, without the benefit of decades of experience.

A bigger issue, and the one I think has prevented more widespread adoption, is that probabilistic design doesn’t account for fluke events -- the unknowables. If you don’t know what could happen, you obviously can’t assign that event a probability.

The ideal approach might be a hybrid. Probabilistic design could be responsible for covering simplifications and a reduced safety factor could cover the unknowables. Of course, there’s no simple way to determine how much of the current factor covers simplifications, so reducing the factor would still be a risky endeavor.

For my projects, I intend to embrace the empirical nature of safety factors and not think too hard about it. If a factor already exists for the area I’m exploring, I’ll use that. If not, I’ll use something like the image below as a starting point and test until I’m satisfied.