vault backup: 2025-12-17 17:03:56
This commit is contained in:
Vendored
+2
-1
@@ -16,5 +16,6 @@
|
||||
"lilypond",
|
||||
"novel-word-count",
|
||||
"easy-copy",
|
||||
"anchor-display-text"
|
||||
"anchor-display-text",
|
||||
"calendar"
|
||||
]
|
||||
Vendored
+10
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"shouldConfirmBeforeCreate": true,
|
||||
"weekStart": "locale",
|
||||
"wordsPerDot": 250,
|
||||
"showWeeklyNote": true,
|
||||
"weeklyNoteFormat": "",
|
||||
"weeklyNoteTemplate": "",
|
||||
"weeklyNoteFolder": "",
|
||||
"localeOverride": "system-default"
|
||||
}
|
||||
Vendored
+4459
File diff suppressed because it is too large
Load Diff
+10
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"id": "calendar",
|
||||
"name": "Calendar",
|
||||
"description": "Calendar view of your daily notes",
|
||||
"version": "1.5.10",
|
||||
"author": "Liam Cain",
|
||||
"authorUrl": "https://github.com/liamcain/",
|
||||
"isDesktopOnly": false,
|
||||
"minAppVersion": "0.9.11"
|
||||
}
|
||||
+3
-3
@@ -31,16 +31,16 @@ Let $A$ and $B$ be sets
|
||||
sharing some but not all elements.
|
||||
|
||||
* $A \cap B \neq \varnothing$:
|
||||
The intersection of $A$ and $B$ is nonempty
|
||||
"The intersection of $A$ and $B$ is nonempty"
|
||||
(They share at least one element).
|
||||
|
||||
* $A \not\subseteq B$:
|
||||
$A$ is not a subset of $B$
|
||||
"$A$ is not a subset of $B$"
|
||||
($A$ has at least one element not in $B$).
|
||||
Equivalent to $A \setminus B \neq \varnothing$.
|
||||
|
||||
* $B \not\subseteq A$:
|
||||
$B$ is not a subset of $A$
|
||||
"$B$ is not a subset of $A$"
|
||||
($B$ has at least one element not in $A$).
|
||||
Equivalent to $B \setminus A \neq \varnothing$.
|
||||
|
||||
|
||||
+1
-9
@@ -12,12 +12,4 @@ title: 2025-12-08
|
||||
|
||||
## 2025-12-08 11:03
|
||||
|
||||
#topic/ambiguity
|
||||
|
||||
I hate to come off as pedantic,
|
||||
but I care a lot about standardized terminology
|
||||
because spending a few minutes to be more thoughtful in specification
|
||||
can save hundreds of people cumulative hours of confusion.
|
||||
And the problem with standardization, of course,
|
||||
is that sometimes it works,
|
||||
and undoing years of poor conditioning is... not easy.
|
||||
[[ambiguity-in-construction-estimating]]
|
||||
+1
-27
@@ -12,33 +12,7 @@ tags:
|
||||
|
||||
## 2025-12-09 10:43
|
||||
|
||||
### Overgeneralization via Hyperspecification
|
||||
|
||||
#topic/ambiguity
|
||||
|
||||
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.
|
||||
[[ambiguity]]
|
||||
|
||||
## 2025-12-09 10:52
|
||||
|
||||
|
||||
+37
-31
@@ -41,45 +41,51 @@ to the conceivably far more broad [spatial statistics](https://en.wikipedia.org/
|
||||
> such as in computer-aided design (CAD),
|
||||
> see [geometric modeling](https://en.wikipedia.org/wiki/Geometric_modeling "Geometric modeling").
|
||||
|
||||
### Common Fallacies
|
||||
### Ambiguity
|
||||
|
||||
* [Reification](https://en.wikipedia.org/wiki/Reification_(fallacy))
|
||||
New Note: [[ambiguity]]
|
||||
|
||||
> [!quote]
|
||||
> **Reification** ... is a fallacy of ambiguity,
|
||||
> ...it is the error of treating something that is not concrete...
|
||||
> as a concrete thing.
|
||||
## 2025-12-17 12:32
|
||||
|
||||
See ["the map is not the territory"](https://en.wikipedia.org/wiki/Map-territory_relation "Map-territory relation").
|
||||
#topic/ambiguity
|
||||
|
||||
> [!aside]
|
||||
> This one is very common among my peers in estimating.
|
||||
> The problem with fallacies, of course,
|
||||
> is that you can't simply say "Reification fallacy, booyah".
|
||||
> If some one is overgeneralizing,
|
||||
> they likely just have a different understanding of the term.
|
||||
> Certainty of definition only occurs with some quorum,
|
||||
> and I'd argue most of [[construction-estimating|ours]] don't meet it,
|
||||
> and that the choice of any term over another ought to be based on utility.
|
||||
>
|
||||
> > Note also that a term's definition can be certain ~~on some axis~~,
|
||||
> > but ambiguous ~~on another~~.
|
||||
> > See ["I know it when I see it"](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it)
|
||||
> > which, as far as I'm concerned, is a perfectly legitimate definition.
|
||||
A while ago I heard a minor coding influencer lament
|
||||
that frameworks, packages, and tools
|
||||
often have ridiculous sounding names
|
||||
|
||||
* [Equivocation](https://en.wikipedia.org/wiki/Equivocation "Equivocation")
|
||||
> `bubble-tea` and `ratatui`,
|
||||
> libraries for creating CLI's, come to my mind
|
||||
|
||||
The misleading use of a word with more than one meaning
|
||||
when, he suggests, they ought to just be called what they do.
|
||||
|
||||
* [Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition "Fallacy of composition")
|
||||
Unfortunately some people and organizations agree,
|
||||
giving us terms which mean both something very general
|
||||
and something very specific.
|
||||
|
||||
Assuming a whole has a property because its parts have that property
|
||||
> [[project-management-tm|"Project Management"]]
|
||||
> was my go to example, but weak
|
||||
> because it's difficult for me to articulate
|
||||
> the difference from construction project management
|
||||
> especially to someone un familiar with the specifics of either.
|
||||
|
||||
* [Division](https://en.wikipedia.org/wiki/Fallacy_of_division "Fallacy of division")
|
||||
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]],
|
||||
whereby the ignorant listener associates traits unique to the example
|
||||
to all things that the name could describe.
|
||||
|
||||
Assuming parts have a property because the whole has that property
|
||||
I thought to finally write about this problem
|
||||
while researching [[lighting-controls#Protocols|lighting control protocols]].
|
||||
The two most dominant examples:
|
||||
|
||||
> [!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".
|
||||
* [[lighting-controls#^dali|"Digital Addressable Lighting Interface (DALI)"]]
|
||||
* [[lighting-controls#^dmx|"Digital Multiplex (DMX)"]]
|
||||
|
||||
while notably different in topology,
|
||||
are could both be described accurately with the other's name.
|
||||
|
||||
> It is possible to avoid this problem
|
||||
> without the effort necessary to come up with a clever name.
|
||||
> Just stick an arbitrary, but reasonably unique word
|
||||
> in front of the generic description.
|
||||
> A person's name ("John's Digital Addressable Lighting Interface (JDALI)")
|
||||
> or your favorite animal ("Heron Digital Multiplex (HDMX)") are good options.
|
||||
|
||||
@@ -8,17 +8,17 @@ tags:
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- topic/risk
|
||||
- type/idea
|
||||
- type/cross-topic
|
||||
---
|
||||
# Actuarial Science for Construction Estimating
|
||||
|
||||
Cross-topic of [[actuarial-science]] and [[construction-estimating]].
|
||||
|
||||
For a contractor, construction projects are like _investments_
|
||||
in that they have a cost and return.
|
||||
However, for construction projects,
|
||||
**return** is known but **cost** must be estimated.
|
||||
In this way, projects are better compared to _insurance accounts_.
|
||||
|
||||
- cost of individual service is uncertain
|
||||
- cost to customer must be minimized
|
||||
|
||||
[[actuarial-science]]
|
||||
* cost of individual service is uncertain
|
||||
* cost to customer must be minimized
|
||||
|
||||
@@ -5,6 +5,7 @@ title: Actuarial Science
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/risk
|
||||
- type/encyclopedia
|
||||
---
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Ambiguity in Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/ambiguity
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- type/cross-topic
|
||||
---
|
||||
# Ambiguity in Construction Estimating
|
||||
|
||||
Cross-topic of [[ambiguity]] and [[construction-estimating]].
|
||||
|
||||
I hate to come off as pedantic,
|
||||
but I care a lot about standardized terminology
|
||||
because spending a few minutes to be more thoughtful in specification
|
||||
can save hundreds of people cumulative hours of confusion.
|
||||
And the problem with standardization, of course,
|
||||
is that sometimes it works,
|
||||
and undoing years of poor conditioning is... not easy.
|
||||
|
||||
## Naming Conventions (Use Case vs. Description)
|
||||
|
||||
Related: [[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_.
|
||||
|
||||
| Use Case | Description |
|
||||
| ------------------- | ------------- |
|
||||
| Hi-Hat | Daisy-Chain |
|
||||
| Furnished By Others | Rough-In Only |
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Ambiguity
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/ambiguity
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Ambiguity
|
||||
|
||||
Not to be confused with [[uncertainty]].
|
||||
|
||||
## Common Fallacies
|
||||
|
||||
### Reification Fallacy
|
||||
|
||||
> [!quote] [Reification](https://en.wikipedia.org/wiki/Reification_(fallacy))
|
||||
> **Reification** ... is a fallacy of ambiguity,
|
||||
> ...it is the error of treating something that is not concrete...
|
||||
> as a concrete thing.
|
||||
|
||||
See ["the map is not the territory"](https://en.wikipedia.org/wiki/Map-territory_relation "Map-territory relation").
|
||||
|
||||
> [!aside]
|
||||
> This one is very common among my peers in estimating.
|
||||
> The problem with fallacies, of course,
|
||||
> is that you can't simply say "Reification fallacy, booyah".
|
||||
> If some one is overgeneralizing,
|
||||
> they likely just have a different understanding of the term.
|
||||
> Certainty of definition only occurs with some quorum,
|
||||
> and I'd argue most of [[construction-estimating|ours]] don't meet it,
|
||||
> and that the choice of any term over another ought to be based on utility.
|
||||
>
|
||||
> > Note also that a term's definition can be certain ~~on some axis~~,
|
||||
> > but ambiguous ~~on another~~.
|
||||
> > See ["I know it when I see it"](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it)
|
||||
> > which, as far as I'm concerned, is a perfectly legitimate definition.
|
||||
|
||||
### Equivocation Fallacy
|
||||
|
||||
[Equivocation](https://en.wikipedia.org/wiki/Equivocation "Equivocation")
|
||||
|
||||
The misleading use of a word with more than one meaning
|
||||
|
||||
### Composition Fallacy
|
||||
|
||||
[Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition "Fallacy of composition")
|
||||
|
||||
Assuming a whole has a property because its parts have that property
|
||||
|
||||
### Division Fallacy
|
||||
|
||||
[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".
|
||||
|
||||
#### 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
@@ -3,7 +3,7 @@ id:
|
||||
aliases: []
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/automation
|
||||
- topic/estimating
|
||||
|
||||
@@ -5,7 +5,9 @@ title: Auction Theory
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/strategy
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Auction Theory
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ aliases: []
|
||||
title: Bid Process Strategy
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- destiny/fleeting
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- topic/risk
|
||||
|
||||
@@ -4,7 +4,7 @@ aliases: []
|
||||
title: Breakdown Objects
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/automation
|
||||
- topic/estimating
|
||||
|
||||
@@ -6,6 +6,7 @@ tags:
|
||||
- authorship/other
|
||||
- destiny/permanent
|
||||
- exclude-from-word-count
|
||||
- status/complete
|
||||
- topic/hobbies/poetry
|
||||
- type/media/poetry
|
||||
author: Karel Čapek
|
||||
|
||||
@@ -1,42 +1,71 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Consolidate Estimating Thoughts
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- topic/meta
|
||||
- type/task
|
||||
- authorship/original
|
||||
title: Consolidate Estimating Thoughts
|
||||
---
|
||||
# Consolidate Estimating Thoughts
|
||||
|
||||
My notes on construction estimating
|
||||
are currently disparate, disjointed, and redundant
|
||||
My notes on [[construction-estimating]]
|
||||
are currently disparate, disjointed, and redundant.
|
||||
|
||||
## TODO
|
||||
|
||||
### Legitimate Subtopics
|
||||
|
||||
* [[estimating-methodologies]]
|
||||
* [[construction-estimating-software]]
|
||||
* [[history-of-construction-estimating]]
|
||||
* [[labor-factoring]]
|
||||
|
||||
### New Cross-Topics
|
||||
|
||||
Remove estimating-specific content from irrelevant notes.
|
||||
|
||||
Create and use cross-topic notes for complex thoughts:
|
||||
|
||||
* [[actuarial-science-for-construction-estimating]]
|
||||
* [[risk-oriented-estimating]]
|
||||
|
||||
* [[risk-management-for-construction-estimating]]
|
||||
* [[risk-oriented-estimating]]: resource allocation
|
||||
|
||||
* [[auction-theory-for-construction-estimating]]
|
||||
* [[bid-process-strategy]]
|
||||
|
||||
* [[game-theory-for-construction-estimating]]
|
||||
* [[estimating-culture]]: estimator incentives
|
||||
|
||||
* [[project-management-for-construction-estimating]]
|
||||
* [[separating-estimating-concerns]]
|
||||
|
||||
* [[ambiguity-in-construction-estimating]]
|
||||
|
||||
* [[nontraditional-computing-for-construction-estimating]]
|
||||
* [[optimal-estimating-patterns]]
|
||||
|
||||
* [[object-oriented-programing-for-construction-estimating]]
|
||||
* [[assembly-philosophy]] - pare down
|
||||
* [[software-based-estimating]]
|
||||
* [[optimal-estimating-patterns]]
|
||||
|
||||
* [[statistical-modeling-for-construction-estimating]]
|
||||
|
||||
* [[transparency-in-construction-estimating]]
|
||||
* [[estimating-ethics]]
|
||||
|
||||
### Orphaned Notes
|
||||
|
||||
* [[estimating-philosophy]]
|
||||
* [[purpose-of-construction-estimating]]
|
||||
* [[traditional-estimating-methods]]
|
||||
|
||||
## Relevant Notes
|
||||
|
||||
![[estimating-thoughts.base]]
|
||||
|
||||
## Orphaned Topics
|
||||
|
||||
### Naming Conventions (Use Case vs. Description)
|
||||
|
||||
Related: [[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_.
|
||||
|
||||
| Use Case | Description |
|
||||
| ------------------- | ------------- |
|
||||
| Hi-Hat | Daisy-Chain |
|
||||
| Furnished By Others | Rough-In Only |
|
||||
![[estimating-thoughts.base#fleeting]]
|
||||
|
||||
@@ -2,16 +2,28 @@
|
||||
id:
|
||||
aliases: []
|
||||
tags:
|
||||
- destiny/uncertain
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- topic/software
|
||||
- type/philosophy
|
||||
- type/encyclopedia-entry
|
||||
- authorship/original
|
||||
title: Construction Estimating Software
|
||||
---
|
||||
# Construction Estimating Software
|
||||
|
||||
%%
|
||||
## TALK
|
||||
|
||||
This note is for describing _existing_, _conventional_
|
||||
construction estimating software and patterns.
|
||||
|
||||
## TODO
|
||||
|
||||
Remove philosophy.
|
||||
|
||||
%%
|
||||
|
||||
## Why Not Excel?
|
||||
|
||||
### "Spreadsheet Syndrome"
|
||||
|
||||
@@ -24,6 +24,26 @@ For philosophy see [[bid-process-strategy]]
|
||||
|
||||
[[estimating-ethics]]
|
||||
|
||||
## Topics
|
||||
|
||||
### Subtopics
|
||||
|
||||
* [[history-of-construction-estimating]]
|
||||
* [[estimating-methodologies]]
|
||||
* [[construction-estimating-software]]
|
||||
* [[labor-factoring]]
|
||||
|
||||
### Cross-Topics
|
||||
|
||||
* [[actuarial-science-for-construction-estimating]]
|
||||
* [[risk-management-for-construction-estimating]]
|
||||
* [[auction-theory-for-construction-estimating]]
|
||||
* [[game-theory-for-construction-estimating]]
|
||||
* [[project-management-for-construction-estimating]]
|
||||
* [[ambiguity-in-construction-estimating]]
|
||||
* [[nontraditional-computing-for-construction-estimating]]
|
||||
* [[object-oriented-programing-for-construction-estimating]]
|
||||
|
||||
## Misconceptions
|
||||
|
||||
### Standard Practices
|
||||
|
||||
@@ -26,10 +26,6 @@ use ENT and PVC as permitted.
|
||||
|
||||
In precast slab garages, use EMT.
|
||||
|
||||
## Lighting Control
|
||||
|
||||
See [[lighting-controls-takeoff]].
|
||||
|
||||
## Receptacles
|
||||
|
||||
## Floor Boxes
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
id:
|
||||
aliases: []
|
||||
tags:
|
||||
- destiny/uncertain
|
||||
- destiny/fleeting
|
||||
- status/draft
|
||||
- topic/estimating
|
||||
- topic/organization
|
||||
@@ -54,7 +54,7 @@ Such incentives therefore create a [[game-theory|competitive game]]
|
||||
between the estimator and the employer
|
||||
where the employer is hopelessly outmatched,
|
||||
and the estimator's [[strategy#Strictly Dominant Strategy|strictly dominant strategy]]---
|
||||
resisted only by their moral conviction---
|
||||
resisted only by their [[personal-values]]---
|
||||
is to abuse the system: to bid fast, lie often, take the bag, and leave.
|
||||
|
||||
## Collaboration
|
||||
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
tags:
|
||||
- destiny/uncertain
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- type/philosophy
|
||||
- authorship/original
|
||||
title: Estimating Detail
|
||||
---
|
||||
# Estimating Detail
|
||||
|
||||
The acceptable level of detail of an estimate
|
||||
in [[construction-estimating]] is a contentious subject.
|
||||
What's worse, estimators often disagree
|
||||
on what makes an estimate more detailed than another.
|
||||
|
||||
The commonly repeated answer is this:
|
||||
|
||||
> As detailed as possible,
|
||||
> given required turnaround and available estimating resources.
|
||||
|
||||
This analysis is flawed
|
||||
because it implies more time always ought to be preferred,
|
||||
when the reality is that when considering larger organizational factors,
|
||||
ideal estimate certainty is likely far lower than most expect.
|
||||
|
||||
The correct answer involves optimizing for these factors:
|
||||
* value of increased bid certainty
|
||||
* value of increased estimate volume
|
||||
|
||||
An estimate's detail is irrelevant to its quality.
|
||||
A less detailed estimate is a more [[risk|risky]] bid,
|
||||
but it is not the role of the estimator to determine acceptable risk.
|
||||
|
||||
## Experiment
|
||||
|
||||
Perform a system takeoff (lighting for example) in exacting detail,
|
||||
the maximum amount you would ever consider using,
|
||||
and measure the time required to do so,
|
||||
as well as the cost of the scope.
|
||||
|
||||
Have another estimator takeoff the same scope
|
||||
using the proposed time saving strategy.
|
||||
|
||||
Repeat the test on additional projects.
|
||||
|
||||
Treat the detailed takeoff as the true value
|
||||
and find the error of the time saving strategy.
|
||||
|
||||
$\frac{d\sigma}{dt}$
|
||||
|
||||
### Expectation
|
||||
|
||||
Time-saving strategies will overestimate or underestimate detailed takeoff
|
||||
depending on the assumptions used in their creation.
|
||||
|
||||
## Human Error
|
||||
|
||||
It is commonly understood that a "detailed takeoff"
|
||||
is more "accurate" than a square foot estimate.
|
||||
@@ -1,3 +1,6 @@
|
||||
filters:
|
||||
and:
|
||||
- file.hasTag("topic/estimating")
|
||||
formulas:
|
||||
destiny: file.tags.filter(value.contains("destiny"))
|
||||
status: file.tags.filter(value.contains("status"))
|
||||
@@ -5,21 +8,22 @@ formulas:
|
||||
linkText: (["[[",file.name,"]]"]).join("")
|
||||
views:
|
||||
- type: table
|
||||
name: Table
|
||||
name: fleeting
|
||||
filters:
|
||||
and:
|
||||
- file.hasTag("topic/estimating")
|
||||
- file.hasTag("authorship/original")
|
||||
- '!file.hasTag("type/media-commentary")'
|
||||
- '!file.hasTag("type/anecdote")'
|
||||
- file.hasTag("destiny/fleeting")
|
||||
order:
|
||||
- file.name
|
||||
- title
|
||||
- file.size
|
||||
- formula.destiny
|
||||
- formula.status
|
||||
- formula.type
|
||||
- formula.linkText
|
||||
sort:
|
||||
- property: formula.destiny
|
||||
direction: DESC
|
||||
- property: formula.status
|
||||
direction: ASC
|
||||
- property: formula.type
|
||||
@@ -28,5 +32,5 @@ views:
|
||||
direction: DESC
|
||||
columnSize:
|
||||
note.title: 290
|
||||
- type: table
|
||||
name: View
|
||||
- type: list
|
||||
name: all
|
||||
|
||||
+7
-6
@@ -39,12 +39,13 @@ tags:
|
||||
|
||||
4. [[units-takeoff]]
|
||||
5. [[fixtures-takeoff]]
|
||||
6. [[electrical-takeoff]]
|
||||
7. [[telecom-takeoff]]
|
||||
8. [[low-voltage-takeoff]]
|
||||
9. [[fire-alarm-takeoff]]
|
||||
10. [[standalone-systems-takeoff]]
|
||||
11. [[misc-budgets-takeoff]]
|
||||
6. [[lighting-controls-takeoff]]
|
||||
7. [[electrical-takeoff]]
|
||||
8. [[telecom-takeoff]]
|
||||
9. [[low-voltage-takeoff]]
|
||||
10. [[fire-alarm-takeoff]]
|
||||
11. [[standalone-systems-takeoff]]
|
||||
12. [[misc-budgets-takeoff]]
|
||||
|
||||
[[general-takeoff]]
|
||||
|
||||
|
||||
+3
-3
@@ -1,15 +1,15 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Gold Plating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- status/complete
|
||||
- topic/construction
|
||||
- topic/construction/electrical
|
||||
- topic/risk
|
||||
- type/encyclopedia
|
||||
title: Gold Plating
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Gold Plating
|
||||
|
||||
|
||||
+14
-16
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: grounding
|
||||
aliases: []
|
||||
title: Grounding Takeoff
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- occupational/takeoff/feeders
|
||||
- status/draft
|
||||
- type/guide
|
||||
title: Grounding Takeoff
|
||||
---
|
||||
# Grounding Takeoff
|
||||
|
||||
@@ -19,28 +19,26 @@ not especially consistent with the actual install.
|
||||
|
||||
### System Grounding
|
||||
|
||||
> `Area` = "01 - Feeders/Risers Building"
|
||||
* `Area` = "01 - Feeders/Risers Building"
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
|
||||
1. `COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
|
||||
* **Length:** Perimeter of the main electrical rooms plus length to each riser.
|
||||
* **Count:** Total number of electrical rooms
|
||||
|
||||
* Length: Perimeter of the main electrical rooms plus length to each riser.
|
||||
* Count: Total number of electrical rooms
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`(3) ... x 10' CU CLAD GRD ROD & 4"X12" GND BAR`
|
||||
|
||||
* Count: 1
|
||||
2. `COMMON ASSEMBLIES`/`GROUNDING`/`(3) ... x 10' CU CLAD GRD ROD & 4"X12" GND BAR`
|
||||
* **Count:** 1
|
||||
|
||||
### Riser
|
||||
|
||||
> `Area` = "Typical - Building All Electrical Riser Rooms"
|
||||
1. * `Area` = "Typical - Building All Electrical Riser Rooms"
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
|
||||
|
||||
* Length: 15
|
||||
* Count: 1
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
|
||||
* **Length:** 15
|
||||
* **Count:** 1
|
||||
|
||||
### Telecom Ground Bridge
|
||||
|
||||
Use only where shown.
|
||||
1. * `Area` = "01 - Feeders/Risers Building"
|
||||
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`TELE/DATA GND BRIDGE, ..., W/ COVER & (60') #6 THHN GREEN`
|
||||
`COMMON ASSEMBLIES`/`GROUNDING`/`TELE/DATA GND BRIDGE, ..., W/ COVER & (60') #6 THHN GREEN`
|
||||
* **Count:** Only as shown
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: History of Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# History of Construction Estimating
|
||||
@@ -6,6 +6,7 @@ tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/individualism
|
||||
- topic/organization
|
||||
- type/philosophy
|
||||
---
|
||||
@@ -47,4 +48,4 @@ familiarity requires maintenance.
|
||||
Expertise as heuristics and biases
|
||||
[Daniel Kahneman](https://en.wikipedia.org/wiki/Daniel_Kahneman)
|
||||
|
||||
%%
|
||||
%%
|
||||
|
||||
@@ -2,16 +2,55 @@
|
||||
id:
|
||||
aliases: []
|
||||
tags:
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/automation
|
||||
- topic/estimating
|
||||
- topic/software
|
||||
- type/idea
|
||||
- authorship/original
|
||||
title: Functional Labor Factoring
|
||||
title: Labor Factoring
|
||||
---
|
||||
# Functional Labor Factoring
|
||||
# Labor Factoring
|
||||
|
||||
%%
|
||||
## TODO
|
||||
|
||||
Discuss purpose and practice of labor factoring,
|
||||
briefly mention impracticality.
|
||||
|
||||
%%
|
||||
|
||||
## Resources
|
||||
|
||||
```bibtex
|
||||
@article{Hanna2018FactorsAL,
|
||||
author = {Hanna, Awad S.},
|
||||
title = {Factors Affecting Labor Productivity For Electrical Contractors},
|
||||
subtitle = {A Factor Approach To Productivity Impact},
|
||||
publisher = {Electrii International},
|
||||
month = {September},
|
||||
year = {2018},
|
||||
pages = {83}
|
||||
}
|
||||
|
||||
@article{Hanna2002BenchmarkingPI,
|
||||
author = {Hanna, Awad S. and Peterson, Pehr and Lee, Min-Jae},
|
||||
journal = {Journal of Construction Engineering and Management},
|
||||
month = {7},
|
||||
number = {4},
|
||||
pages = {331--337},
|
||||
title = {Benchmarking productivity Indicators for Electrical/Mechanical Projects},
|
||||
volume = {128},
|
||||
year = {2002},
|
||||
doi = {10.1061/(asce)0733-9364(2002)128:4(331},
|
||||
url = {https://doi.org/10.1061/(asce)0733-9364(2002)128:4(331)},
|
||||
}
|
||||
```
|
||||
|
||||
## Software Integration
|
||||
|
||||
%% TODO: move to more appropriate article. %%
|
||||
|
||||
calculate labor hours utilizing a comprehensive set of factors
|
||||
not practical with traditional methods.
|
||||
@@ -45,29 +84,3 @@ most sensitive to weight.
|
||||
Greater understanding of this relationship would make practical
|
||||
the prediction of labor of unstudied items.
|
||||
|
||||
## Resources
|
||||
|
||||
```bibtex
|
||||
@article{Hanna2018FactorsAL,
|
||||
author = {Hanna, Awad S.},
|
||||
title = {Factors Affecting Labor Productivity For Electrical Contractors},
|
||||
subtitle = {A Factor Approach To Productivity Impact},
|
||||
publisher = {Electrii International},
|
||||
month = {September},
|
||||
year = {2018},
|
||||
pages = {83}
|
||||
}
|
||||
|
||||
@article{Hanna2002BenchmarkingPI,
|
||||
author = {Hanna, Awad S. and Peterson, Pehr and Lee, Min-Jae},
|
||||
journal = {Journal of Construction Engineering and Management},
|
||||
month = {7},
|
||||
number = {4},
|
||||
pages = {331--337},
|
||||
title = {Benchmarking productivity Indicators for Electrical/Mechanical Projects},
|
||||
volume = {128},
|
||||
year = {2002},
|
||||
doi = {10.1061/(asce)0733-9364(2002)128:4(331},
|
||||
url = {https://doi.org/10.1061/(asce)0733-9364(2002)128:4(331)},
|
||||
}
|
||||
```
|
||||
@@ -24,111 +24,91 @@ title: Lighting Controls Takeoff
|
||||
Determine which Systems and Codes are required:
|
||||
* _IBC/IECC 2021 or later:_ all fixtures 0-10V dimmable.
|
||||
|
||||
## PDI Lighting Control Configurations
|
||||
* `System` = "LV - Lighting Control System"
|
||||
|
||||
> [!important]
|
||||
> This section is currently not practical
|
||||
## Wall Switches
|
||||
|
||||
### Stand Alone
|
||||
> [!tip]
|
||||
> For switch combinations not in `COMMON ASSEMBLIES`,
|
||||
> create [[heating-designations]] based on the most similar.
|
||||
|
||||
0-10V dim --- "LV cable" is 2 conductor
|
||||
## Analog Controls
|
||||
|
||||
Takeoff rough-in for switches and occupancy sensors
|
||||
* **Branch Length** = length of room
|
||||
24V sensors. Typical of BOH spaces too large for wall sensors.
|
||||
|
||||
Takeoff the lighting control relay (DLM)
|
||||
1. `COMMON ASSEMBLIES`/`SWITCHES`/`CEILING OCC SENSOR ...`
|
||||
**Count:** as shown.
|
||||
|
||||
Takeoff an additional controller if receptacles are controlled
|
||||
2. `COMMON ASSEMBLIES`/`SWITCHES`/`POWER PACK FOR OCC SENSOR ...`
|
||||
**Count:** each circuit controlled by analog sensors. Minimum 1 per sensor.
|
||||
|
||||
Takeoff homeruns to the DLM (one per controlled circuit)
|
||||
* Note: Not necessarily per room, several rooms may share a lighting circuit.
|
||||
## Digital Controls
|
||||
|
||||
### Networked
|
||||
Applicable to all digital control systems
|
||||
(i.e. "Standalone" and "Centralized", wired and wireless)
|
||||
|
||||
"LV Cable" is [[twisted-pair-cable]]
|
||||
|
||||
#### Room Controllers
|
||||
|
||||
No room controllers are necessary,
|
||||
lighting zones are switched from a central lighting control panel (LCP)
|
||||
|
||||
#### Switches and Sensors
|
||||
|
||||
Takeoff rough-in for switches and occupancy sensors
|
||||
|
||||
??
|
||||
(only if time based; length based on proximity to switch or occupancy sensor)
|
||||
??
|
||||
|
||||
#### Homeruns
|
||||
|
||||
Takeoff 1 circuit homerun per lighting zone.
|
||||
|
||||
### Wattstopper
|
||||
|
||||
PDI default configuration
|
||||
|
||||
#### Room Controllers
|
||||
|
||||
For all rooms with dimmable fixtures
|
||||
and/or automatically controlled receptacles,
|
||||
take off (1) of either or both as appropriate.
|
||||
|
||||
`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`DLM LTG RM CONTROLLER - ...`
|
||||
|
||||
`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`REC PLUG CONTROLLER - ...`
|
||||
### General
|
||||
|
||||
Takeoff normal power to the controlled load
|
||||
* Add LV cable to fixture branch
|
||||
* Use \#12/3 for controlled receptacles
|
||||
* Use switched assemblies (\#12/3) for controlled receptacles
|
||||
|
||||
Takeoff rough-in for both the occ sensors and the LV switch
|
||||
#### Digital Sensors
|
||||
|
||||
`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`... LV SW - WALL ROUGH IN ...`
|
||||
1. `COMMON ASSEMBLIES`/`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/...
|
||||
* `... LV SW - WALL ROUGH IN ...`
|
||||
* `... SENSOR LOW VOLTAGE - ROUGH IN ...`
|
||||
|
||||
`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`... SENSOR LOW VOLTAGE - ROUGH IN ...`
|
||||
### "Standalone" Systems
|
||||
|
||||
* Free air if possible
|
||||
* **Length** = length of room
|
||||
Room controllers distributed throughout controlled areas.
|
||||
|
||||
Cat cabling from the controllers on is likely provided by systems
|
||||
* Confirm with chief or quote language
|
||||
> [!important] "Room controllers"
|
||||
> As I have always understood it, and other manufacturers tend to agree,
|
||||
> a room controller _necessarily_ controls multiple zones
|
||||
> (otherwise "zone controller" would be better),
|
||||
> however PDI terminology is based on Wattstopper's.
|
||||
|
||||
#### Corridor Occupancy Sensors
|
||||
`COMMON ASSEMBLIES`/`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/...
|
||||
|
||||
If occupancy sensors are shown in the corridors:
|
||||
1. .../`DLM LTG RM CONTROLLER - ...`
|
||||
**Count:** each lighting control zone.
|
||||
|
||||
Takeoff homerun back to the electric room
|
||||
2. .../`REC PLUG CONTROLLER - ...`
|
||||
**Count:** each receptacle control zone.
|
||||
|
||||
Takeoff (1) DLM controller for each electric room
|
||||
3. `HEATING`/`Network Bridge - Blank 4SQ`
|
||||
**Count:** each controller.
|
||||
|
||||
`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`DLM LTG RM CONTROLLER - ...`
|
||||
Coordinate with PDS to determine if necessary.
|
||||
|
||||
??
|
||||
Run free-air down corridor
|
||||
??
|
||||
4. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_without_ dimming cable)
|
||||
**Count:** each _circuit_.
|
||||
|
||||
* **Length** = Length of corridor
|
||||
### "Centralized" Systems
|
||||
|
||||
Takeoff rough-in for each occupancy sensor shown.
|
||||
Zones switched and dimmed from central lighting control panel (LCP).
|
||||
|
||||
#### Network Bridge
|
||||
1. `COMMON ASSEMBLIES`/`DISTRIBUTION`/`LIGHTING CONTROL PANEL INSTALLATION`/...
|
||||
|
||||
Check systems quote to determine if network bridges are needed.
|
||||
2. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_with_ dimming cable)
|
||||
**Count:** each _lighting control zone_.
|
||||
|
||||
Takeoff (1) back box for every ==group of rooms you want together==
|
||||
%%
|
||||
|
||||
??
|
||||
If not showing, put one in every room with a controller
|
||||
??
|
||||
### Somewhere In Between
|
||||
|
||||
#### Homeruns
|
||||
The dichotomy of [[#"Standalone" Systems]] vs. [[#"Centralized" Systems]]
|
||||
assumes zones will be controlled either
|
||||
(1) right next to the fixture or (2) in the nearest electrical room.
|
||||
|
||||
Need a HR into the room for the controllers
|
||||
* Can link multiple controllers (aka rooms) together if you have the same circuit
|
||||
* Go back to closest electric room
|
||||
I think just as common is 3--5 circuit controllers above the ceiling.
|
||||
|
||||
## Custom Switch Boxes
|
||||
1. `HEATING`/`Lighting Control Room Controller - n Circuit`
|
||||
**Count:** each controller.
|
||||
|
||||
For switch combinations not in `COMMON ASSEMBLIES`,
|
||||
create [[heating-designations]] based on the most similar.
|
||||
2. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_without_ dimming cable)
|
||||
**Length:** route to room.
|
||||
**Count:** each circuit.
|
||||
|
||||
%%
|
||||
+52
-1
@@ -11,6 +11,9 @@ title: Lighting Controls
|
||||
---
|
||||
# Lighting Controls
|
||||
|
||||
## Protocols
|
||||
|
||||
|
||||
## Occupancy/Vacancy Sensor Technologies
|
||||
|
||||
* Passive Infrared (PIR)
|
||||
@@ -33,7 +36,53 @@ title: Lighting Controls
|
||||
|
||||
### Digital
|
||||
|
||||
Digital Light Management (DLM)
|
||||
#### Digital Addressable Lighting Interface (DALI) ^dali
|
||||
|
||||
[Digital Addressable Lighting Interface](https://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface)
|
||||
|
||||
Open protocol defined by [IEC 62386](https://www.dali-alliance.org/standards/IEC62386.html).
|
||||
|
||||
Includes wired (via [[twisted-pair-cable]] and 8P8C "RJ-45" connectors)
|
||||
and wireless topologies.
|
||||
|
||||
##### Proprietary DALI Clones
|
||||
|
||||
There exist several proprietary control ecosystems
|
||||
with feature sets and topologies identical to DALI.
|
||||
|
||||
> I suspect these exist to skirt the cost of DALI's testing requirements.
|
||||
|
||||
%%
|
||||
I'm less sure this is an apt description.
|
||||
The examples below are typical of some generic system,
|
||||
but it doesn't seem to be DALI.
|
||||
%%
|
||||
|
||||
Examples include:
|
||||
* [Legrand Wattstopper Digital Light Management (DLM)](https://www.legrand.us/solutions/digital-lighting-management)
|
||||
* [Acuity nLight®](https://nlight.acuitybrands.com/overview)
|
||||
* [Lutron Quantum](https://www.lutron.com/us/en/controls/systems/quantum)[^1]
|
||||
* [Lutron Athena][^2]
|
||||
* [Cooper Greengate](https://www.cooperlighting.com/global/brands/greengate)
|
||||
|
||||
[^1]: Maybe not. Sensors show 24V wiring.
|
||||
|
||||
[^2]: Can not verify. Website is down at time of writing.
|
||||
|
||||
#### Digital Multiplex (DMX) ^dmx
|
||||
|
||||
[DMX512](https://en.wikipedia.org/wiki/DMX512)
|
||||
|
||||
DMX512-A defined in ANSI E1.11-2008
|
||||
|
||||
Shielded [[twisted-pair-cable]] with XLR or 8P8C ("RJ-45") connectors
|
||||
|
||||
#### See Also
|
||||
|
||||
> [!quote] [BACnet](https://en.wikipedia.org/wiki/BACnet)
|
||||
> **BACnet** is a communication protocol
|
||||
> for building automation and control (BAC) networks.
|
||||
> It is defined by **ANSI/ASHRAE 135** and **ISO 16484-5**.
|
||||
|
||||
[[twisted-pair-cable]]
|
||||
|
||||
@@ -48,6 +97,8 @@ All these control methods are likely to appear in drawings.
|
||||
|
||||
### 0-10V Dimming
|
||||
|
||||
[0-10 V lighting control](https://en.wikipedia.org/wiki/0-10_V_lighting_control)
|
||||
|
||||
In conduit:
|
||||
|
||||
```
|
||||
|
||||
+2
-2
@@ -5,9 +5,9 @@ aliases:
|
||||
title: "Article 338 Service-Entrance Cable: Types SE and USE"
|
||||
tags:
|
||||
- authorship/other
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- exclude-from-word-count
|
||||
- status/incomplete
|
||||
- status/draft
|
||||
- topic/construction/electrical
|
||||
- type/media/reference
|
||||
---
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@ aliases:
|
||||
title: "Article 352 Rigid Polyvinyl Chloride Conduit: Type PVC"
|
||||
tags:
|
||||
- authorship/other
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- exclude-from-word-count
|
||||
- status/incomplete
|
||||
- topic/construction/electrical
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Nontraditional Computing for Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- type/cross-topic
|
||||
---
|
||||
# Nontraditional Computing for Construction Estimating
|
||||
|
||||
Cross-topic of [[nontraditional-computing]] and [[construction-estimating]].
|
||||
|
||||
### Sketch-Based Lookup
|
||||
|
||||
%% TODO:
|
||||
This section is a transcription of a dictation.
|
||||
To be condensed.
|
||||
%%
|
||||
|
||||
A better use for computer vision in estimating
|
||||
is sketch based assembly lookup.
|
||||
Probably the the biggest hang-up in the workflow
|
||||
is searching through available assemblies and items based on text,
|
||||
which has a number of problems,
|
||||
mostly that names, in electrical material for certain, are practically meaningless.
|
||||
|
||||
Trade names are incorrect, and there are often many different names for the same item.
|
||||
Basically, there's just so many problems with text-based lookup as a rule.
|
||||
That sketching and handwriting recognition would be more idiomatic.
|
||||
|
||||
Drawing lines for raceways, angles representing bends,
|
||||
squiggly lines representing flexible conduit, etc.
|
||||
All things that are common sketching conventions
|
||||
that estimators are probably drawing in their workflow anyway.
|
||||
|
||||
Many parts of the estimating workflow would be greatly benefited
|
||||
by the sort of non-traditional interface that Ink & Switch promotes.
|
||||
Traditionally estimating software is all tables and forms.
|
||||
|
||||
Suppose you were to sketch a takeoff indicating a run
|
||||
|
||||
1. from a panel
|
||||
2. up to the ceiling
|
||||
3. across the building
|
||||
4. down to a disconnect
|
||||
5. out through a flex connection
|
||||
6. to a piece of equipment
|
||||
|
||||
that's a very complex assembly,
|
||||
and despite how common it is,
|
||||
it can be very difficult to to get exactly that from databases.
|
||||
|
||||
Suppose instead you draw that that sketch
|
||||
and the application creates a graph
|
||||
of all the primitive parts of that assembly.
|
||||
|
||||
It may include the panel and the equipment by default
|
||||
but with the same stylus you used to draw the sketch,
|
||||
you just cross out the panel, the equipment,
|
||||
the parts that that you didn't intend to include.
|
||||
|
||||
1. Draw a line from start to end.
|
||||
* A canvas appears on top of the plans.
|
||||
2. Sketch the desired assembly with predetermined conventions.
|
||||
3. Draw a checkmark to confirm
|
||||
* A render of the interpreted assembly appears
|
||||
4. Draw a second checkmark to select.
|
||||
|
||||
A Non-Traditional Computing approach
|
||||
(journal-type, heavy-stylus-use),
|
||||
would would be great here, too.
|
||||
|
||||
Keyboards as a takeoff input device are an anti-pattern.
|
||||
Every time you're entering data is an interruption.
|
||||
|
||||
But perfect for that would be drawing takeoffs on the on the prints
|
||||
then using stylus based interaction patterns to edit them.
|
||||
Lasso selecting groups of takeoffs to change aspects of them.
|
||||
|
||||
There is so little typing necessary.
|
||||
Everything that you're typing is just short descriptors
|
||||
that, in a lot of cases, don't even need to exist.
|
||||
the language exists purely to roughly communicate ideas
|
||||
that are intuitive in even a crude sketch.
|
||||
|
||||
Estimating is a perfect use case
|
||||
for a purely stylus and handwriting recognition based workflow,
|
||||
probably more perfect than whatever Ink & Switch is using.
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Nontraditional Computing
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Nontraditional Computing
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Object Oriented Programming for Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- type/cross-topic
|
||||
---
|
||||
# Object Oriented Programming for Construction Estimating
|
||||
|
||||
Cross-topic of [[object-oriented-programing]] and [[construction-estimating]].
|
||||
|
||||
### Estimating As Code
|
||||
|
||||
#### Compared to Existing Frameworks
|
||||
|
||||
Traditional methods interact with an existing database.
|
||||
EaC builds a static database at runtime,
|
||||
allowing flexibility of input.
|
||||
|
||||
* define variables
|
||||
* search and replace
|
||||
* undo
|
||||
|
||||
#### Project Structure
|
||||
|
||||
Organizational info (items, assemblies) as submodules.
|
||||
Solves database conflicts by pinning estimates to a commit.
|
||||
|
||||
#### Related Notes
|
||||
|
||||
* [[breakdown-objects]]
|
||||
* [[assembly-objects]]
|
||||
* [[labor-factoring]]
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Object Oriented Programming
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- topic/software
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Object Oriented Programming
|
||||
@@ -35,120 +35,3 @@ Optimizing the takeoff process means:
|
||||
* _Maximizing_ organizational consistency
|
||||
|
||||
%%
|
||||
|
||||
## More "Innovative" Patterns
|
||||
|
||||
These ideas are farther out there
|
||||
in terms of what existing estimators may be willing to accept
|
||||
|
||||
### Estimating As Code
|
||||
|
||||
#### Compared to Existing Frameworks
|
||||
|
||||
Traditional methods interact with an existing database.
|
||||
EaC builds a static database at runtime,
|
||||
allowing flexibility of input.
|
||||
|
||||
* define variables
|
||||
* search and replace
|
||||
* undo
|
||||
|
||||
#### Project Structure
|
||||
|
||||
Organizational info (items, assemblies) as submodules.
|
||||
Solves database conflicts by pinning estimates to a commit.
|
||||
|
||||
#### Related Notes
|
||||
|
||||
* [[breakdown-objects]]
|
||||
* [[assembly-objects]]
|
||||
* [[functional-labor-factoring]]
|
||||
|
||||
### Bayesian Takeoff
|
||||
|
||||
#### User Story
|
||||
|
||||
Frank is estimating a 20-story high rise
|
||||
and notices that their are roughly, but not exactly,
|
||||
the same number of receptacles in the corridors of levels 2 to 19.
|
||||
Frank starts a new takeoff for duplex receptacles,
|
||||
typical of levels 2 to 19.
|
||||
He counts and inputs quantities for 3 levels,
|
||||
each adjusts the prior to calculate the expected quantity for all 18 levels.
|
||||
|
||||
### Sketch-Based Lookup
|
||||
|
||||
%% TODO:
|
||||
This section is a transcription of a dictation.
|
||||
To be condensed.
|
||||
%%
|
||||
|
||||
A better use for computer vision in estimating
|
||||
is sketch based assembly lookup.
|
||||
Probably the the biggest hang-up in the workflow
|
||||
is searching through available assemblies and items based on text,
|
||||
which has a number of problems,
|
||||
mostly that names, in electrical material for certain, are practically meaningless.
|
||||
|
||||
Trade names are incorrect, and there are often many different names for the same item.
|
||||
Basically, there's just so many problems with text-based lookup as a rule.
|
||||
That sketching and handwriting recognition would be more idiomatic.
|
||||
|
||||
Drawing lines for raceways, angles representing bends,
|
||||
squiggly lines representing flexible conduit, etc.
|
||||
All things that are common sketching conventions
|
||||
that estimators are probably drawing in their workflow anyway.
|
||||
|
||||
Many parts of the estimating workflow would be greatly benefited
|
||||
by the sort of non-traditional interface that Ink & Switch promotes.
|
||||
Traditionally estimating software is all tables and forms.
|
||||
|
||||
Suppose you were to sketch a takeoff indicating a run
|
||||
|
||||
1. from a panel
|
||||
2. up to the ceiling
|
||||
3. across the building
|
||||
4. down to a disconnect
|
||||
5. out through a flex connection
|
||||
6. to a piece of equipment
|
||||
|
||||
that's a very complex assembly,
|
||||
and despite how common it is,
|
||||
it can be very difficult to to get exactly that from databases.
|
||||
|
||||
Suppose instead you draw that that sketch
|
||||
and the application creates a graph
|
||||
of all the primitive parts of that assembly.
|
||||
|
||||
It may include the panel and the equipment by default
|
||||
but with the same stylus you used to draw the sketch,
|
||||
you just cross out the panel, the equipment,
|
||||
the parts that that you didn't intend to include.
|
||||
|
||||
1. Draw a line from start to end.
|
||||
* A canvas appears on top of the plans.
|
||||
2. Sketch the desired assembly with predetermined conventions.
|
||||
3. Draw a checkmark to confirm
|
||||
* A render of the interpreted assembly appears
|
||||
4. Draw a second checkmark to select.
|
||||
|
||||
A Non-Traditional Computing approach
|
||||
(journal-type, heavy-stylus-use),
|
||||
would would be great here, too.
|
||||
|
||||
Keyboards as a takeoff input device are an anti-pattern.
|
||||
Every time you're entering data is an interruption.
|
||||
|
||||
But perfect for that would be drawing takeoffs on the on the prints
|
||||
then using stylus based interaction patterns to edit them.
|
||||
Lasso selecting groups of takeoffs to change aspects of them.
|
||||
|
||||
There is so little typing necessary.
|
||||
Everything that you're typing is just short descriptors
|
||||
that, in a lot of cases, don't even need to exist.
|
||||
the language exists purely to roughly communicate ideas
|
||||
that are intuitive in even a crude sketch.
|
||||
|
||||
Estimating is a perfect use case
|
||||
for a purely stylus and handwriting recognition based workflow,
|
||||
probably more perfect than whatever Ink & Switch is using.
|
||||
|
||||
+6
-1
@@ -2,7 +2,12 @@
|
||||
id:
|
||||
aliases: []
|
||||
title: Personal Values
|
||||
tags: []
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/individualism
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Personal Values
|
||||
|
||||
|
||||
@@ -7,6 +7,7 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/organization
|
||||
- topic/individualism
|
||||
- type/philosophy
|
||||
---
|
||||
# Professionalism
|
||||
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Risk Management for Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- topic/risk
|
||||
- type/cross-topic
|
||||
---
|
||||
# Risk Management for Construction Estimating
|
||||
|
||||
Cross-topic of [[risk-management]] and [[construction-estimating]].
|
||||
|
||||
## Prioritizing Tasks
|
||||
|
||||
ROE prioritizes estimating tasks by their contribution to _cost certainty_.
|
||||
|
||||
### Estimating as Risk Mitigation
|
||||
|
||||
* reduce risk of wasted estimation effort due to bid loss
|
||||
(prefer lower bid)
|
||||
* reduce risk of project overrun
|
||||
(prefer higher bid)
|
||||
|
||||
Estimating resources are allocated by Return on Mitigation (RoM)
|
||||
|
||||
### Determining Necessary Detail
|
||||
|
||||
ROE determines the appropriate level of [[estimating-detail]]
|
||||
given an organization's [[risk#Risk Tolerance]].
|
||||
|
||||
#### EVI Takeoff
|
||||
|
||||
Expected value of information (EVI)
|
||||
|
||||
#### Takeoff Optimization
|
||||
|
||||
For systems where EVI analysis determines manual takeoff is still necessary,
|
||||
optimizations can be made to decrease the required effort of takeoff,
|
||||
and thus the opportunity cost of takeoff.
|
||||
|
||||
See [[optimal-estimating-patterns]] for more.
|
||||
|
||||
# Estimating Detail
|
||||
|
||||
The acceptable level of detail of an estimate
|
||||
in [[construction-estimating]] is a contentious subject.
|
||||
What's worse, estimators often disagree
|
||||
on what makes an estimate more detailed than another.
|
||||
|
||||
The commonly repeated answer is this:
|
||||
|
||||
> As detailed as possible,
|
||||
> given required turnaround and available estimating resources.
|
||||
|
||||
This analysis is flawed
|
||||
because it implies more time always ought to be preferred,
|
||||
when the reality is that when considering larger organizational factors,
|
||||
ideal estimate certainty is likely far lower than most expect.
|
||||
|
||||
The correct answer involves optimizing for these factors:
|
||||
* value of increased bid certainty
|
||||
* value of increased estimate volume
|
||||
|
||||
An estimate's detail is irrelevant to its quality.
|
||||
A less detailed estimate is a more [[risk|risky]] bid,
|
||||
but it is not the role of the estimator to determine acceptable risk.
|
||||
|
||||
## Experiment
|
||||
|
||||
Perform a system takeoff (lighting for example) in exacting detail,
|
||||
the maximum amount you would ever consider using,
|
||||
and measure the time required to do so,
|
||||
as well as the cost of the scope.
|
||||
|
||||
Have another estimator takeoff the same scope
|
||||
using the proposed time saving strategy.
|
||||
|
||||
Repeat the test on additional projects.
|
||||
|
||||
Treat the detailed takeoff as the true value
|
||||
and find the error of the time saving strategy.
|
||||
|
||||
$\frac{d\sigma}{dt}$
|
||||
|
||||
### Expectation
|
||||
|
||||
Time-saving strategies will overestimate or underestimate detailed takeoff
|
||||
depending on the assumptions used in their creation.
|
||||
|
||||
## Human Error
|
||||
|
||||
It is commonly understood that a "detailed takeoff"
|
||||
is more "accurate" than a square foot estimate.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
id: risk-oriented-estimating
|
||||
aliases: []
|
||||
tags:
|
||||
- destiny/permanent/entry-point
|
||||
- destiny/fleeting
|
||||
- status/incomplete
|
||||
- topic/estimating
|
||||
- topic/risk
|
||||
@@ -37,36 +37,6 @@ of critiquing common practice.
|
||||
|
||||
%%
|
||||
|
||||
## Prioritizing Tasks
|
||||
|
||||
ROE prioritizes estimating tasks by their contribution to _cost certainty_.
|
||||
|
||||
### Estimating as Risk Mitigation
|
||||
|
||||
* reduce risk of wasted estimation effort due to bid loss
|
||||
(prefer lower bid)
|
||||
* reduce risk of project overrun
|
||||
(prefer higher bid)
|
||||
|
||||
Estimating resources are allocated by Return on Mitigation (RoM)
|
||||
|
||||
## Determining Necessary Detail
|
||||
|
||||
ROE determines the appropriate level of [[estimating-detail]]
|
||||
given an organization's [[risk#Risk Tolerance]].
|
||||
|
||||
### EVI Takeoff
|
||||
|
||||
Expected value of information (EVI)
|
||||
|
||||
### Takeoff Optimization
|
||||
|
||||
For systems where EVI analysis determines manual takeoff is still necessary,
|
||||
optimizations can be made to decrease the required effort of takeoff,
|
||||
and thus the opportunity cost of takeoff.
|
||||
|
||||
See [[optimal-estimating-patterns]] for more.
|
||||
|
||||
## Potential Objections
|
||||
|
||||
Objections to the use of historical data in new estimates are not unfounded.
|
||||
|
||||
@@ -1,16 +1,33 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Statistical Modeling for Construction Estimating
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/construction/electrical
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
- type/idea
|
||||
title: Stochastic Branch Takeoff
|
||||
- topic/math/statistics
|
||||
- type/cross-topic
|
||||
---
|
||||
# Stochastic Branch Takeoff
|
||||
# Statistical Modeling for Construction Estimating
|
||||
|
||||
Cross-topic of [[statistical-modeling]] and [[construction-estimating]].
|
||||
|
||||
## Bayesian Takeoff
|
||||
|
||||
#### User Story
|
||||
|
||||
Frank is estimating a 20-story high rise
|
||||
and notices that their are roughly, but not exactly,
|
||||
the same number of receptacles in the corridors of levels 2 to 19.
|
||||
Frank starts a new takeoff for duplex receptacles,
|
||||
typical of levels 2 to 19.
|
||||
He counts and inputs quantities for 3 levels,
|
||||
each adjusts the prior to calculate the expected quantity for all 18 levels.
|
||||
|
||||
## Stochastic Branch Takeoff
|
||||
|
||||
generate a BOM from point loads distributed in a space.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Statistical Modeling
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/incomplete
|
||||
- topic/math/statistics
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Statistical Modeling
|
||||
|
||||
Bayesian inference is a method of statistical inference,
|
||||
the practice of analyzing and describing
|
||||
|
||||
stochasticity is the property of an outcome
|
||||
that can be described with a probability distribution
|
||||
|
||||
## Credibility
|
||||
|
||||
* [[statistical-significance]]
|
||||
@@ -6,6 +6,7 @@ tags:
|
||||
- authorship/other
|
||||
- destiny/permanent
|
||||
- exclude-from-word-count
|
||||
- status/incomplete
|
||||
- topic/math/statistics
|
||||
- topic/risk
|
||||
- type/media/book
|
||||
@@ -25,4 +26,4 @@ This note, with the exception of comments like this one
|
||||
consists only of content from the text.
|
||||
For commentary see the companion
|
||||
[[fooled-by-randomness]].
|
||||
%%
|
||||
%%
|
||||
|
||||
+2
-2
@@ -3,12 +3,12 @@ filters:
|
||||
- file.hasTag("type/task")
|
||||
- file.name != "tags"
|
||||
views:
|
||||
- type: table
|
||||
- type: list
|
||||
name: all
|
||||
sort:
|
||||
- property: file.name
|
||||
direction: ASC
|
||||
- type: table
|
||||
- type: list
|
||||
name: meta
|
||||
filters:
|
||||
and:
|
||||
|
||||
+7
-2
@@ -2,10 +2,15 @@
|
||||
id:
|
||||
aliases: []
|
||||
title: Utility
|
||||
tags: []
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/not-started
|
||||
- topic/risk
|
||||
- type/encyclopedia-entry
|
||||
---
|
||||
# Utility
|
||||
|
||||
[Utility](https://en.wikipedia.org/wiki/Utility)
|
||||
is a measure of a party's satisfaction
|
||||
with a certain state of the world.
|
||||
with a certain state of the world.
|
||||
|
||||
Reference in New Issue
Block a user