Bureaucrats, developer, Administrators
9,842
edits
Talk:Efficient frontier analysis: Difference between revisions
m
typo
No edit summary |
m (typo) |
||
| Line 4: | Line 4: | ||
*parallel [[buyer's regret]] (i.e. if you don't live up to your [[individual buying criteria]], and discover that after the fact, what regret do you feel?) | *parallel [[buyer's regret]] (i.e. if you don't live up to your [[individual buying criteria]], and discover that after the fact, what regret do you feel?) | ||
*[[ecological yield]] and permissible harvest calculations | *[[ecological yield]] and permissible harvest calculations | ||
*reconciling [[economic choice]] with [[ethical choice]] (see [[Amartya Sen]]'s analyses of this in [[Development as Freedom]] | *reconciling [[economic choice]] with [[ethical choice]] (see [[Amartya Sen]]'s analyses of this in [[Development as Freedom]]) | ||
------------- | ------------- | ||
| Line 10: | Line 10: | ||
The issue of "whether to rank "null" cells (often signifying unknown data) above or below "non-null" ones" is sometimes called the "don't know as don't care decision". The word "null" is inexact and fails to make a critical distinction: To not know a number, and to not care about a number, are two completely different assertions. If one cares about not knowing, then, it is a don't know. If one doesn't care, it's a don't care. Consumerium may have so few "don't cares" that a simpler model that doesn't include it may be fine... but from a data gathering standpoint there are good reasons to keep both possibilities. | The issue of "whether to rank "null" cells (often signifying unknown data) above or below "non-null" ones" is sometimes called the "don't know as don't care decision". The word "null" is inexact and fails to make a critical distinction: To not know a number, and to not care about a number, are two completely different assertions. If one cares about not knowing, then, it is a don't know. If one doesn't care, it's a don't care. Consumerium may have so few "don't cares" that a simpler model that doesn't include it may be fine... but from a data gathering standpoint there are good reasons to keep both possibilities. | ||
For one thing there may be other applications that have quite different lists of what to care about: All [[buying criteria]] are basically lists of what is cared about, and by implication everything else that might be cared about, that isn't on the list of criteria but could have been, must be a "don't care". So overlays of these could play a large role in the design. In [[relational database]] terms these are "views", which are identical in object oriented terms to "classes" - each has an "instance" of the filter as applied to some product which yields the "form" or "object" the user sees. A good system would make the data simple enough to read even on [[worn device]]s. | |||