Talk:Efficient frontier analysis: Difference between revisions

    From Consumerium development wiki R&D Wiki
    (don't know don't care issues)
    No edit summary
    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]] and earlier more technical papers like "is consistency of choice bizarre?")


    -------------
    -------------

    Revision as of 17:41, 7 April 2004

    Other actual uses for EFA or risk as regret methods include:


    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 devices.