Principle
Associate a costs to actions, thus giving the basis for an economical system, in order to provide the necessary support for incentive on usage and optimization from improvements. High leverage actions should naturally be preferred over low impact hight requirements actions. Also, the system would favor an increasingly precise estimation of costs (which is probably why this can not be delegated even to AWS#MechanicalTurk).
Solutions
Use include (limited by line numbers) to highlight the current main focus and the Site.AllRecentChanges page to show current activity (potentially related).
Demo
Goal
note that this demo has been largely superseeded by the (internally visible only) http://127.0.0.1/wiki/PBES/PotentialTasks
Last actions undertaken
- PersonalInformationStream.WithoutNotesDecember2024 . . . December 14, 2024, at 04:57 AM by PIM_Trydactil:
- Analysis.PrinciplesForPrototypingWithEmergingTechnologies . . . December 11, 2024, at 02:18 PM by Fabien:
- Cookbook.Hydroponics . . . December 06, 2024, at 02:56 PM by Fabien: images
- Analysis.AgainstPoorArtificialIntelligencePractices . . . December 05, 2024, at 01:34 PM by Fabien:
- Analysis.BacktrackingGenerativeAI . . . December 05, 2024, at 01:33 PM by Fabien:
Example
Ordered list of actions for strategy S (at t0)
| Ordered list of actions for strategy S (at t0+1)
|
starting point
| Action C realized
|
- x credits = action A (from project P)
- y credits = action B (from project P)
- z credits = action C (from project Q)
- a credits = estimated cost of action C (from project Q)
- b credits = estimated impact of action C (from project Q)
x>y>z>>a>b>0 proportional to the ROI of each action
|
- x' credits = action A (from project P)
- y' credits = action B (from project P)
z credits = action C (from project Q)
- a' credits = estimated cost of action C (from project Q)
- b' credits = estimated impact of action C (from project Q)
|
Account=A
| Account=A+z
|
Dilbert comic strip for 04/18/2010
Structure
- isolate an action A (atomic unit with clearly defined limits)
- parent
- expected impact of the realization
- default=1/number of actions from the parent
- impossibility to short-circuit the system and consider global impact
- ultimately should be convertible to unit of energy
- estimated cost
- default=2300Kcal
- shortcuts convertible to unit of energy
- day of work for me
- amount of money
- amount of objects
- combination of some shortcuts
- ... (simple to add)
- a ridiculously higher amount for the infrastructure
- housing, administrative overhead, insurances, ...
- return on investment (ROI)
- expected impact of the realization/estimated cost
- Hierarchy of actions
Remarks
- there is no short-term incentive to price and since it is a complex thus costly function, the system is not being used
- closure must be taken into account in order to
- make projects "safe" from side-effects
- lower the cognitive cost of comparing a long list of actions
- overall costs is too complex to evaluate and update
- consequently, consider the cost for each project
- unit of energy in general as absolute value in one moment in time, as opposed to taking time into account, might be too simplified
- as the price of a unit of energy is a function of time
- especially important if strategy takes into account homeostatis for which
- energy can be stored only to a limited extend
- energy can not be consumed instantly
- estimate waste by conversion
- in both direction
- in cost, waste of management
- in estimated impact, energetic waste in order to get the final product
- EROEI alone can provide a basis for optimization
- use an estimated base EROEI and tend to perpetually improve it
- Usability threshold
- every process including chores would be there but even theoretically there is a usability threshold
- small repetitive yet required tasks are probably under a threshold of resource required
- managing them would require more energy than just doing it (cf EROEI) since they usually have low dependencies, it's not a complex network of effects and the consequence of doing or not doing them are highly predictable
- example
"breathe in, breathe out" despite its fundamental importance as it is a default background task
- yet how to breathe in and out in an optimal way sustaining the system could go in the dedicated Health page and hopefuly in Augmented Reality Heuristics System too
Credit earned by
Debit to spend on
To do
See also
Inspired by