vault backup: 2026-01-20 17:02:44
This commit is contained in:
+3
-1
@@ -12,7 +12,9 @@ title: ""
|
||||
|
||||
## 2025-12-04 09:51
|
||||
|
||||
#topic/automation #topic/automation
|
||||
#topic/automation
|
||||
|
||||
* [ ] TODO: Build test case estimating helper html app ➕ 2026-12-04
|
||||
|
||||
It may be possible
|
||||
to replicate the behavior of my takeoff workbooks
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-01-20
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/daily
|
||||
---
|
||||
# 2026-01-20
|
||||
|
||||
## 2026-01-20 09:09
|
||||
|
||||
Stumbled upon this line while waiting on my computer to restart.
|
||||
|
||||
> [!quote] [[hubbard_2020_failure#The Measurement Inversion]]
|
||||
> Unless we estimate the value of information,
|
||||
> we may go down the deep rabbit hole of adding more and more detail to a model
|
||||
> and trying to gather data on less relevant issues.
|
||||
|
||||
## 2026-01-20 10:10
|
||||
|
||||
I was reminded again of [[2025-12-04#2025-12-04 09:51]].
|
||||
I added a [[small-tasks|task]] for it.
|
||||
|
||||
[html-calculators](https://github.com/ZaneMeyers/html-calculators)
|
||||
|
||||
I'm now certain that common estimating calculators
|
||||
(e.g. voltage drop)
|
||||
could be easily replaced with documents like this one.
|
||||
|
||||
## 2026-01-20 14:25
|
||||
|
||||
Jfarrari The Unknowing (Acoustic)
|
||||
|
||||
[[music-analysis]]
|
||||
@@ -64,6 +64,8 @@ Assuming parts have a property because the whole has that property
|
||||
> and after being given a demonstration of each player's role,
|
||||
> asking which player performs the "team spirit".
|
||||
|
||||
All squares are rectangles, but not all rectangles are squares.
|
||||
|
||||
#### Overgeneralization via Hyperspecification
|
||||
|
||||
Or "inappropriate synecdoche[^1]"
|
||||
|
||||
@@ -11,11 +11,13 @@ title: _Electrical Estimators Manual_
|
||||
---
|
||||
# _Electrical Estimators Manual_
|
||||
|
||||
Electrical Estimators Manual:
|
||||
How to Estimate Electrical Construction Projects Including Everyday Labor Installation Rates
|
||||
(William Penn)
|
||||
|
||||
199 page book
|
||||
```yaml
|
||||
type: book
|
||||
title: Electrical Estimators Manual
|
||||
subtitle: How to Estimate Electrical Construction Projects Including Everyday Labor Installation Rates
|
||||
authors:
|
||||
- William Penn
|
||||
```
|
||||
|
||||
## Pros
|
||||
|
||||
|
||||
+1
-1
@@ -80,7 +80,7 @@ add 20ft in addition to previously mentioned adders.
|
||||
|
||||
## Bus Duct
|
||||
|
||||
`COMMON ASSEMBLIES`/`DISTRIBUTION`/`BUS DUCT`
|
||||
`COMMON ASSEMBLIES`/`DISTRIBUTION`/`BUS DUCT`/...
|
||||
|
||||
## Conductor Support
|
||||
|
||||
|
||||
+19
-3
@@ -17,7 +17,7 @@ in lieu of detail sufficient for standard takeoff (e.g. a grounding riser).
|
||||
Note that the material provided in this system is intended to be budgetary,
|
||||
not especially consistent with the actual install.
|
||||
|
||||
### System Grounding
|
||||
## System Grounding
|
||||
|
||||
* `Area` = "01 - Feeders/Risers Building"
|
||||
|
||||
@@ -28,7 +28,7 @@ not especially consistent with the actual install.
|
||||
2. `COMMON ASSEMBLIES`/`GROUNDING`/`(3) ... x 10' CU CLAD GRD ROD & 4"X12" GND BAR`
|
||||
* **Count:** 1
|
||||
|
||||
### Riser
|
||||
## Riser
|
||||
|
||||
1. * `Area` = "Typical - Building All Electrical Riser Rooms"
|
||||
|
||||
@@ -36,9 +36,25 @@ not especially consistent with the actual install.
|
||||
* **Length:** 15
|
||||
* **Count:** 1
|
||||
|
||||
### Telecom Ground Bridge
|
||||
## Telecom Ground Bridge
|
||||
|
||||
1. * `Area` = "01 - Feeders/Risers Building"
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`TELE/DATA GND BRIDGE, ..., W/ COVER & (60') #6 THHN GREEN`
|
||||
* **Count:** Only as shown
|
||||
|
||||
## Pool Bonding
|
||||
|
||||
> [!important]
|
||||
> This scope is included here for its similarity in content.
|
||||
> It may be more appropriate in [[electrical-takeoff]]
|
||||
|
||||
> [!quote] Joel Jansen 2026-01-20T16:30 (pp.)
|
||||
> Josh Ford prefers it in electrical, but I'm not concerned.
|
||||
> So long as it's named "Pool Bonding" it's fine.
|
||||
|
||||
1. * `Area` = _Contentious_
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 ...
|
||||
* **Length:** Perimeter of the pool plus length to nearest riser.
|
||||
* **Count:** 1?
|
||||
|
||||
@@ -419,6 +419,92 @@ outperforms the alternative model, such as intuition.
|
||||
|
||||
#### The Measurement Inversion
|
||||
|
||||
Consider a decision analysis model for a new product.
|
||||
You have uncertainties about the cost and duration of development, materials costs once production starts, demand in different markets, and so on.
|
||||
This would be just like a typical cost-benefit analysis with a cash flow but instead of exact numbers, we use probability distributions to represent our uncertainty.
|
||||
We can even include the probability of a development project failure (no viable product was developed and the project was cancelled) or even more disastrous scenarios such as a major product recall.
|
||||
Any of these variables could be measured further with some cost and effort.
|
||||
So, which one would you measure first and how much would you be willing to spend?
|
||||
For years, I've been computing the value of additional information on every uncertain variable in a model.
|
||||
|
||||
Suppose we ran ten thousand scenarios in a simulation and determined that 1,500 of these scenarios resulted in a net loss.
|
||||
If we decide to go ahead with this product development, and we get one of these undesirable scenarios, the amount of money we would lose is the *opportunity loss (OL)*---the cost of making the wrong choice.
|
||||
If we didn't lose money, then the OL was zero.
|
||||
We can also have an OL if we decide not to approve the product but then find out we *could* have made money.
|
||||
In the case of rejecting the product, the OL is the difference between the lease and the money we made on the widgets if we would have made money---zero if the equipment did not make money (in which case we were right to reject the idea).
|
||||
|
||||
The *expected opportunity loss (EOL)* is each possible opportunity loss times the chance of that loss---in other words, the chance of being wrong times the cost of being wrong.
|
||||
In our Monte Carlo simulation, we simply average the OL for all of the scenarios.
|
||||
For now, let's say that given the current level of uncertainty about this product, you still think the lease is a good idea.
|
||||
So we average all 1500 scenarios the OL was positive (we lost money) and 8500 scenarios where OL was zero (me made the right choice).
|
||||
Suppose we find that the EOL is about $600,000.
|
||||
|
||||
The EOL is equivalent to another term called the *expected value of perfect information (EVPI)*.
|
||||
The EVPI is the most you would reasonably be willing to pay if you could eliminate all uncertainty about this decision.
|
||||
Although it is almost impossible to ever get perfect information and eliminate all uncertainty, this value is useful as an absolute upper bound.
|
||||
If we can reduce the $600,000 EOL by half with a market survey that would cost $18,000, then the survey is probably a good deal.
|
||||
If you want to see a spreadsheet calculation of this type of problem, go to this book's website at [www.howtomeasureanything.com/riskmanagement](http://www.howtomeasureanything.com/riskmanagement).
|
||||
|
||||
This becomes more enlightening when we compute the value of information for each variable in a model, especially when the models get very large.
|
||||
This way we not only get an idea for how much to spend on measurement but also which specific variables we need to measure and how much we might be willing to spend on them.
|
||||
I have done this calculation for more than 150 quantitative decision models in which most had about fifty to one hundred variables (for a total of about 10,000 variables, conservatively).
|
||||
From this, I've seen patterns that still persist every time I add more analysis to my library.
|
||||
The two main findings are:
|
||||
|
||||
* Relatively few variables require further measurement---
|
||||
but there are almost always *some*.
|
||||
|
||||
* The uncertain variables with the highest EVPI
|
||||
(highest value for further measurement)
|
||||
tend to be those that the organization almost never measures,
|
||||
*and* the variables they *have* been measuring have, on average, the lowest EVPI.
|
||||
|
||||
I call this second finding the *measurement inversion*,
|
||||
and I've seen it in IT portfolios, military logistics, environmental policy,
|
||||
venture capital, market forecasts, and every other place I've looked.
|
||||
|
||||
> [!info] The Measurement Inversion
|
||||
> The persistent tendency to focus on the least valuable measurements
|
||||
> at the expense of those more likely to improve decisions.
|
||||
|
||||
It seems that almost everybody, everywhere,
|
||||
is systematically measuring all the wrong things.
|
||||
It is so pervasive and impactful
|
||||
that I have to wonder how much this affects the gross domestic product.
|
||||
Organizations appear to measure what they know how to measure
|
||||
without wondering whether they should learn new measurement methods for very-high-value uncertainties.
|
||||
|
||||
How does tendency toward a measurement inversion
|
||||
affect risk assessment and, in turn, risk management?
|
||||
Highly uncertain and impactful risks
|
||||
may tend to get much less analysis than the easier-to-list, mundane events.
|
||||
The possibility of existential risks due to a major product recall,
|
||||
corporate scandal, major project failure, or factory disaster
|
||||
get less attention than the listing of much more routine and less impactful events.
|
||||
Conventional risk matrices are often populated with risks
|
||||
that are estimated to be so likely that they should happen several times a year.
|
||||
I've even seen risks estimated to be 80 percent, 90 percent,
|
||||
or even 100 percent probable in the next twelve months.
|
||||
At that level, that is more of a reliable cost of doing business.
|
||||
Of course, cost control is also important but it's not the same as risk management.
|
||||
If it is something you routinely *budget* for, it might not be the kind of risk
|
||||
upper management needs to see in a risk assessment.
|
||||
|
||||
Also, as an analyst myself as well as a manager of many analysts,
|
||||
I can tell you that analysts are not immune to wanting to use a modeling method
|
||||
because it uses the latest buzzwords.
|
||||
Perhaps an analyst just recently learned about random forests, Bayesian networks, or deep learning.
|
||||
If she finds it interesting and wants to use it,
|
||||
she can find a way to make it part of the solution.
|
||||
The measurement inversion shows that our intuition fails us
|
||||
regarding where we need to spend more time reducing uncertainty in probabilistic models.
|
||||
Unless we estimate the value of information,
|
||||
we may go down the deep rabbit hole of adding more and more detail to a model
|
||||
and trying to gather data on less relevant issues.
|
||||
|
||||
Periodically, we just need to back up and ask if we are really capturing the main risks
|
||||
and if we are adding detail where it informs decisions most.
|
||||
|
||||
#### Is Monte Carlo Too Complicated?
|
||||
|
||||
#### Notes
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
# Music Analysis
|
||||
|
||||
Refers to methods for determining the composition of,
|
||||
and purpose of compositional elements in, music.
|
||||
|
||||
Sonic Visualizer
|
||||
+20
-18
@@ -54,9 +54,11 @@ In equal temperament tuning, all pitch classes are---
|
||||
according to human perception---equally spaced.
|
||||
There is no missing half between E and F or B and C,
|
||||
because there are no halves at all.
|
||||
C# is as legitimate a pitch class as C,
|
||||
and in some disciplines, accidentals are marked on every note,
|
||||
even "redundantly", in acknowledgement of this fact.
|
||||
C# is as legitimate a pitch class as C.
|
||||
|
||||
> [!info]
|
||||
> In some disciplines, accidentals are marked on every note,
|
||||
> even "redundantly", in acknowledgement of this fact.
|
||||
|
||||
What is meant by the poor terminology is this:
|
||||
|
||||
@@ -86,7 +88,7 @@ which is a [[ambiguity#Category Mistake|category mistake]].
|
||||
| ----- | ------- | -------- | ------------ |
|
||||
| bb | 𝄫 | eses | double flat |
|
||||
| b | ♭ | es | flat |
|
||||
| | ♮ | | natural |
|
||||
| | ♮ | ! | natural |
|
||||
| # | ♯ | is | sharp |
|
||||
| x | 𝄪 | isis | double sharp |
|
||||
|
||||
@@ -146,7 +148,7 @@ The common intervals
|
||||
| 6 | 11 | M7 | Major seventh |
|
||||
| 7 | 12 | P8 | Perfect octave |
|
||||
|
||||
[^1]: difference in staff position (interval number)
|
||||
[^1]: difference in staff position (interval number - 1)
|
||||
[^2]: difference in semitones
|
||||
|
||||
#### Augmented and Diminished Intervals
|
||||
@@ -178,22 +180,22 @@ A **key** is a [[set-theory|set]] of pitch classes
|
||||
created by modifying a starting pitch class (the **tonic**)
|
||||
according to some sequence of intervals.
|
||||
|
||||
| Key | Interval Sequence |
|
||||
| ------------- |:-----------------:|
|
||||
| Major | W--W--H--W--W--W--H |
|
||||
| Natural Minor | W--H--W--W--H--W--W |
|
||||
| Key | Interval Sequence |
|
||||
| ------------- |:-------------------:|
|
||||
| Major | W--W--H--W--W--W--H |
|
||||
| Natural Minor | W--H--W--W--H--W--W |
|
||||
|
||||
### Modes
|
||||
|
||||
| Mode | Interval Sequence |
|
||||
| ---------- |:-----------------:|
|
||||
| Ionian | W--W--H--W--W--W--H |
|
||||
| Dorian | W--H--W--W--W--H--W |
|
||||
| Phrygian | H--W--W--W--H--W--W |
|
||||
| Lydian | W--W--W--H--W--W--H |
|
||||
| Mixolydian | W--W--H--W--W--H--W |
|
||||
| Aeolian | W--H--W--W--H--W--W |
|
||||
| Locrian | H--W--W--H--W--W--W |
|
||||
| Mode | Interval Sequence |
|
||||
| ---------- |:-------------------:|
|
||||
| Ionian | W--W--H--W--W--W--H |
|
||||
| Dorian | W--H--W--W--W--H--W |
|
||||
| Phrygian | H--W--W--W--H--W--W |
|
||||
| Lydian | W--W--W--H--W--W--H |
|
||||
| Mixolydian | W--W--H--W--W--H--W |
|
||||
| Aeolian | W--H--W--W--H--W--W |
|
||||
| Locrian | H--W--W--H--W--W--W |
|
||||
|
||||
### Scale
|
||||
|
||||
|
||||
+5
-3
@@ -54,7 +54,7 @@ polymer concrete enclosure
|
||||
|
||||
Alternative
|
||||
|
||||
1. `COMMON ASSEMBLIES`/`POLES / EXCAVATION / CORING / UG PULL BX`/`MANHOLES / PULL BOXES / EXCAVATION / CONCRETE`/...
|
||||
1. `COMMON ASSEMBLIES`/`POLES / EXCAVATION / CORING / UG PULL BX`/`MANHOLES / PULL BOXES / EXCAVATION / CONCRETE`/`QUAZITE UG PULL BOXES`/...
|
||||
|
||||
## Backbone Riser
|
||||
|
||||
@@ -113,12 +113,14 @@ Alternative
|
||||
|
||||
## Devices
|
||||
|
||||
As shown on plans. Ignore floor boxes, other electrical scope.
|
||||
As shown on plans.
|
||||
Ignore scope shared with [[electrical-takeoff|electrical]].
|
||||
(e.g. floor boxes)
|
||||
|
||||
1. `COMMON ASSEMBLIES`/`TELECOM SYSTEMS`/...
|
||||
* .../`BOH / AMENITY ASSEMBLIES`
|
||||
* .../`SCREWLESS DECORA COVERS UNITS / BOH`
|
||||
* .../`ROUGH IN ASSY`
|
||||
|
||||
If system is included, take off _both_ rough-in and device assemblies
|
||||
If _system_ is included, take off _both_ rough-in and device assemblies
|
||||
in amenity areas.
|
||||
|
||||
Reference in New Issue
Block a user