vault backup: 2026-03-23 17:15:27
This commit is contained in:
@@ -31,7 +31,7 @@ Related topic: [[heuristics#Realism vs. Instrumentalism]]
|
||||
Naming by use case is intuitive for those without estimating or field experience,
|
||||
but has the side effect that those accustomed to the names
|
||||
will inevitably _treat them as descriptive_,
|
||||
leading to [[ambiguity#Category Mistake|category mistake]].
|
||||
leading to [[category-mistake]].
|
||||
|
||||
| Use Case | Description |
|
||||
| ------------------- | ------------- |
|
||||
|
||||
@@ -57,38 +57,3 @@ Assuming a whole has a property because its parts have that property
|
||||
[Division](https://en.wikipedia.org/wiki/Fallacy_of_division "Fallacy of division")
|
||||
|
||||
Assuming parts have a property because the whole has that property
|
||||
|
||||
### Category Mistake
|
||||
|
||||
> [!quote] [Category mistake](https://en.wikipedia.org/wiki/Category_mistake)
|
||||
> An example is a person learning that the game of cricket involves team spirit,
|
||||
> 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]"
|
||||
|
||||
[^1]: **synecdoche:** Using the name of a part to refer to the whole, or vice versa.
|
||||
|
||||
Much of my issue with terminology
|
||||
can be blamed on **overgeneralization via hyperspecification**,
|
||||
|
||||
[Proprietary eponyms](https://en.wiktionary.org/wiki/proprietary_eponym)
|
||||
(synonym: [genericized trademark](https://en.wiktionary.org/wiki/genericized_trademark))
|
||||
are usually[^2] an example of such,
|
||||
and are prominent in electrical construction.[^3]
|
||||
|
||||
[^2]: I'm not a complete pedant, Cadweld is a perfectly unambiguous substitution.
|
||||
"Caddy", "Hilti", and "Vitalink" are my real complaints,
|
||||
where the word only gets me marginally closer
|
||||
to creating a concrete image in my head.
|
||||
|
||||
The general acceptance of "band-aid"
|
||||
compared to the rejection of "coke"
|
||||
may be related.
|
||||
|
||||
[^3]: See [Database of American Proprietary Eponyms](https://www.searstower.org/rkrause/brands.html)
|
||||
for examples.
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
### Category Mistake
|
||||
|
||||
> [!quote] [Category mistake](https://en.wikipedia.org/wiki/Category_mistake)
|
||||
> An example is a person learning that the game of cricket involves team spirit,
|
||||
> 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]"
|
||||
|
||||
[^1]: **synecdoche:** Using the name of a part to refer to the whole, or vice versa.
|
||||
|
||||
Much of my issue with terminology
|
||||
can be blamed on **overgeneralization via hyperspecification**,
|
||||
|
||||
[Proprietary eponyms](https://en.wiktionary.org/wiki/proprietary_eponym)
|
||||
(synonym: [genericized trademark](https://en.wiktionary.org/wiki/genericized_trademark))
|
||||
are usually[^2] an example of such,
|
||||
and are prominent in electrical construction.[^3]
|
||||
|
||||
[^2]: I'm not a complete pedant, Cadweld is a perfectly unambiguous substitution.
|
||||
"Caddy", "Hilti", and "Vitalink" are my real complaints,
|
||||
where the word only gets me marginally closer
|
||||
to creating a concrete image in my head.
|
||||
|
||||
The general acceptance of "band-aid"
|
||||
compared to the rejection of "coke"
|
||||
may be related.
|
||||
|
||||
[^3]: See [Database of American Proprietary Eponyms](https://www.searstower.org/rkrause/brands.html)
|
||||
for examples.
|
||||
+1
-1
@@ -81,7 +81,7 @@ Inexcusable, though, is conflating semitone increments with intervals.
|
||||
Wikipedia music theory articles frequently link "half step" and "whole step"
|
||||
to [minor second](https://en.wikipedia.org/wiki/Minor_second)
|
||||
and [major second](https://en.wikipedia.org/wiki/Major_second) respectively,
|
||||
which is a [[ambiguity#Category Mistake|category mistake]].
|
||||
which is a [[category-mistake]].
|
||||
|
||||
#### Accidentals
|
||||
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Sensitivity
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- topic/estimating
|
||||
- topic/strategy
|
||||
---
|
||||
# Sensitivity
|
||||
|
||||
In estimating, **sensitivity** describes the influence of a particular input on the output.
|
||||
@@ -28,7 +28,7 @@ and something very specific.[^3]
|
||||
especially to someone unfamiliar with the specifics of either.
|
||||
|
||||
For lack of a better term I've been thinking of this as an SEO problem,
|
||||
but the bigger problem is that it invites [[ambiguity#Category Mistake|Category Mistake]],
|
||||
but the bigger problem is that it invites [[category-mistake]],
|
||||
whereby the ignorant listener associates traits unique to the example
|
||||
to all things that the name could describe.
|
||||
|
||||
|
||||
@@ -30,6 +30,6 @@ That is, quantifying the influence of an input on the output.
|
||||
When an estimator says that some factor is not worth consideration ("it's pennies")
|
||||
it is usually meant that the estimate is not especially **sensitive** to that factor.
|
||||
|
||||
Sensitivity, I think, is a much quicker concept to grasp
|
||||
than [[uncertainty#Value of Information|the value of information]],
|
||||
[[sensitivity|Sensitivity]], I think, is a much quicker concept to grasp
|
||||
than [[value-of-information|the value of information]],
|
||||
even if VOI can explain the same motivations and more completely.
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: 2026-03-23T12:48:49-04:00
|
||||
aliases: []
|
||||
title: 2026-03-23 12:48:49
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
date-created: 2026-03-23T12:48:49-04:00
|
||||
daily: "[[2026-03-23]]"
|
||||
weekly: "[[2026-W13]]"
|
||||
monthly: "[[2026-03]]"
|
||||
quarterly: "[[2026-Q1]]"
|
||||
yearly: "[[2026]]"
|
||||
---
|
||||
# 2026-03-23 12:48:49
|
||||
|
||||
Joel asked me to give feedback on the project engineer
|
||||
I've had shadowing and helping me on [[charlotte-south-end-hotel]].
|
||||
|
||||
They've been exceptionally engaged,
|
||||
with an impressive ability to follow along with procedures
|
||||
that are based in electrical and general construction considerations
|
||||
that they weren't already familiar with.
|
||||
I told Joel the same.
|
||||
|
||||
I added that I appreciated that their engagement extends
|
||||
to my explanations of my thought processes during takeoff,
|
||||
which can be quite abstract.
|
||||
|
||||
I found the PE's receptivity
|
||||
a pleasant surprise.
|
||||
|
||||
In my experience training estimating,
|
||||
both at Ace and PDI,
|
||||
I have to be _very_ careful with my words
|
||||
to prevent unintended interpretation.
|
||||
More than once I have said casually
|
||||
that some low-[[sensitivity]] consideration "doesn't matter",
|
||||
finding later that the student has over-generalized the direction
|
||||
and is not properly discriminating
|
||||
between significantly different cases.
|
||||
Other times,
|
||||
the student continues to discriminate between nearly identical cases
|
||||
even despite repeated instruction
|
||||
that consideration of the differences is not worth their effort.
|
||||
|
||||
I think both behaviors indicate an inability for abstract thinking.
|
||||
The first case seems like over-abstraction,
|
||||
but in practice it is usually rooted in the principle of least effort.
|
||||
That is, the student assumes
|
||||
that considerations that would be _unpleasant_ to account for
|
||||
are the same as those that are not worth accounting for,
|
||||
which is a [[category-mistake]].
|
||||
+1
-46
@@ -27,52 +27,7 @@ The term "uncertainty" refers to the possibility of multiple outcomes.
|
||||
In statistical inference and [[strategy]],
|
||||
**information** is the resolution of uncertainty.
|
||||
|
||||
### Value of Information
|
||||
|
||||
> [!quote]
|
||||
> **Value of information** (VOI or VoI)
|
||||
> is the amount a decision maker would be willing to pay
|
||||
> for information prior to making a decision.
|
||||
|
||||
Suppose information $I$ is available to a decision maker.
|
||||
Consider these two scenarios:
|
||||
|
||||
1. the decision maker does not purchase the information
|
||||
and makes \$9,000. $P(D)=9000$
|
||||
|
||||
2. the decision maker purchases the information
|
||||
and makes \$10,000 $P(D)|I=10000$
|
||||
|
||||
The monetary value of $I$ is the difference between the payout
|
||||
without ($P(D)$) and with ($P(D)|I$) the information $I$.
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
V(I) &= P(D)|I - P(D) \\
|
||||
&= (10000) - (9000) \\
|
||||
&= 1000
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
When forecasting, the payout of decisions is unknown,
|
||||
thus
|
||||
|
||||
$$
|
||||
\mathbb{E}\left[V(I)\right] = \mathbb{E}\left[P(D)\right] - \mathbb{E}\left[P(D)|I\right]
|
||||
$$
|
||||
|
||||
### Expected Value of Perfect Information
|
||||
|
||||
Expected value of perfect information (EVPI)
|
||||
is the price that one would be willing to pay
|
||||
in order to gain access to perfect information.
|
||||
|
||||
> [!info] Perfect Information
|
||||
> Perfect information is hypothetical information
|
||||
> that would eliminate all uncertainty.
|
||||
|
||||
The perceived _value_ of decreased uncertainty
|
||||
must be weighed against its _cost_.
|
||||
[[value-of-information]]
|
||||
|
||||
## Types of Uncertainty
|
||||
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Value of Information
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/strategy
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Value of Information
|
||||
|
||||
In [[decision-theory]],
|
||||
the **value of information** (VOI or VoI)
|
||||
is a framework for quantifying the impact
|
||||
of some reduction in [[uncertainty]].
|
||||
It is the amount a rational party would be willing to pay
|
||||
to gain access to information prior to making a decision.
|
||||
|
||||
## Example
|
||||
|
||||
Suppose information $I$ is available to a decision maker.
|
||||
Consider these two scenarios:
|
||||
|
||||
1. the decision maker does not purchase the information
|
||||
and makes \$9,000. $P(D)=9000$
|
||||
|
||||
2. the decision maker purchases the information
|
||||
and makes \$10,000 $P(D)|I=10000$
|
||||
|
||||
The monetary value of $I$ is the difference between the payout
|
||||
without ($P(D)$) and with ($P(D)|I$) the information $I$.
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
V(I) &= P(D)|I - P(D) \\
|
||||
&= (10000) - (9000) \\
|
||||
&= 1000
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
When forecasting, the payout of decisions is unknown,
|
||||
thus
|
||||
|
||||
$$
|
||||
\mathbb{E}\left[V(I)\right] = \mathbb{E}\left[P(D)\right] - \mathbb{E}\left[P(D)|I\right]
|
||||
$$
|
||||
|
||||
### Expected Value of Perfect Information
|
||||
|
||||
Expected value of perfect information (EVPI)
|
||||
is the price that one would be willing to pay
|
||||
in order to gain access to perfect information.
|
||||
|
||||
> [!info] Perfect Information
|
||||
> Perfect information is hypothetical information
|
||||
> that would eliminate all uncertainty.
|
||||
|
||||
The perceived _value_ of decreased uncertainty
|
||||
must be weighed against its _cost_.
|
||||
|
||||
## See Also
|
||||
|
||||
* [[sensitivity]]
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: XY Problem
|
||||
tags:
|
||||
- authorship/other-for-now
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- topic/transparency
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# XY Problem
|
||||
|
||||
> [!quote] [Wikipedia](https://en.wikipedia.org/wiki/XY_problem)
|
||||
> The XY problem is a communication problem ...
|
||||
> where the question is about an end user's attempted solution (X)
|
||||
> rather than the root problem itself (Y).
|
||||
|
||||
> [!quote] [How To Ask Questions The Smart Way_ "Questions Not To Ask"](http://www.catb.org/~esr/faqs/smart-questions.html#classic)
|
||||
> **Q:** How can I use X to do Y?
|
||||
>
|
||||
> **A:** If what you want is to do Y,
|
||||
> you should ask that question without pre-supposing the use of a method
|
||||
> that may not be appropriate.
|
||||
> Questions of this form often indicate a person who is not merely ignorant about X,
|
||||
> but confused about what problem Y they are solving
|
||||
> and too fixated on the details of their particular situation.
|
||||
|
||||
> [!quote] [_How To Ask Questions The Smart Way_ "Describe the goal, not the step"](http://www.catb.org/~esr/faqs/smart-questions.html#goal)
|
||||
> If you are trying to find out how to do something
|
||||
> (as opposed to reporting a bug),
|
||||
> begin by describing the goal.
|
||||
> Only then describe the particular step towards it
|
||||
> that you are blocked on.
|
||||
>
|
||||
> Often, people who need technical help
|
||||
> have a high-level goal in mind
|
||||
> and get stuck on what they think is one particular path towards the goal.
|
||||
> They come for help with the step,
|
||||
> but don't realize that the path is wrong.
|
||||
> It can take substantial effort to get past this.
|
||||
>
|
||||
> **Stupid:** How do I get the color-picker on the FooDraw program
|
||||
> to take a hexadecimal RGB value?
|
||||
>
|
||||
> **Smart:** I'm trying to replace the color table on an image with values of my choosing.
|
||||
> Right now the only way I can see to do this is by editing each table slot,
|
||||
> but I can't get FooDraw's color picker to take a hexadecimal RGB value.
|
||||
>
|
||||
> The second version of the question is smart.
|
||||
> It allows an answer that suggests a tool better suited to the task.
|
||||
Reference in New Issue
Block a user