public:t-720-atai:atai-16:lecture_notes_f-12_19.02.2016
Table of Contents
T-720-ATAI-2016
Lecture Notes, F-12 19.02.2016
Constructionist AI
What it is | Monicker that refers to software development methodologies that require an intelligent designer – the software programmer as “construction worker”. |
Why it's important | All traditional software development methodologies are constructionist methodologies. |
What it's good for | Works well for constructing controllers of Closed Problems where (a) the Solution Space can be defined fully or largely before the controller is constructed, (b) there is a single identifiable and clearly definable top-level Goal, and ( c) the Task assigned to the controller will not change throughout its lifetime (i.e. the controller does not have to generate new sub-Goals). |
Key Implementation Method | Hand-coding using programming language and methods targeted for human-level intelligences. |
Limitations | Key limitation is reliance on hand-coding – the requirement of human-level intelligence. Another way to look at it: Over-reliance on an outside designer. |
Result | In the context of artificial intelligences that can handle highly novel Tasks, Problems, Situations, Environments and Worlds, no constructionist methodology will suffice. |
Contrast with | Constructivist AI |
Key Limitations of Manual Coding
Static | System components that are fairly static. Manual construction limits the complexity that can be built into each component. |
Size | The sheer number of components that can form a single architecture is limited by what a designer or team can handle. |
Scaling | The components and their interconnections in the architecture are managed by algorithms that are hand-crafted themselves, and thus also of limited flexibility. |
Result | Together these three problems remove hopes of autonomous architectural adaptation and system growth. |
EOF
/var/www/cadia.ru.is/wiki/data/pages/public/t-720-atai/atai-16/lecture_notes_f-12_19.02.2016.txt · Last modified: 2016/02/17 15:03 by thorisson2