Information Technology Reference
In-Depth Information
analyse its output and publish the results, then nothing would happen—which is not
a good sign that the software is autonomously creative. This is a valid criticism.
However, it is one that we can manage by repeatedly asking ourselves: what am I
using the software for now? Once we identify why we are using the software, we can
take a step back, and write code that allows the software to use itself for the same
purpose. We call this process climbing the meta-mountain. If we can repeatedly ask,
answer, and code software to take on increasing amounts of creative responsibility,
it will eventually climb a meta-mountain, and begin to create autonomously for a
purpose, with little or no human involvement.
1.3.5 The Creativity Tripod
In many domains, in particular the visual arts, how an artefact is produced is very
much taken into account when people assess the value of the artefact. This leads
to a genuine, and understandable, bias towards human artefacts over computer gen-
erated ones, and this feeling is impervious to any Turing test, which demonstrates
that people cannot tell the difference between human and computer generated arte-
facts when they are presented out of context. This isn't a fatal problem, though, as
long as we are happy to manage the public's impression of how our software works.
In our many dealings with (well meaning) critics of Computational Creativity, we
have found that the main criticisms levelled at programs purporting to be creative is
that they lack skill, or they lack appreciation, or they lack imagination. We should
therefore manage these misconceptions by describing our software along these di-
mensions. Moreover, we should regularly ask ourselves: if I were to describe my
software using this supporting tripod of creativity terms, where would the weakest
link be? In identifying and addressing such weak links, we can build better software
both in terms of what it is able to achieve practically, and what it appears to be
doing.
As described in Colton (
2008b
), managing people's perception of creativity in
software is as important as building more intelligent algorithms in domains where
cultural, contextual and historical precedents play an important role. Hence, if you
have software which doesn't appreciate its own work, or the work of others, or its
subject material, etc., then you should write code which achieves this. If you have
software which isn't particularly inventive, then you should implement some rou-
tines which could be described as imaginative, and so on. Using this tripod, we've
managed to devise a baseline test for creativity in software which is defensible. We
suppose that the software is regularly producing artefacts with certain behaviours
being exhibited simultaneously or in sequence during the production process. If
from these behaviours, one could genuinely be described as skillful, one could be
described as appreciative, and one could be described as imaginative, then we argue
that the software should be described as creative. There are two caveats here: firstly,
this is not a prescription for creativity in people; secondly, this is a baseline test, i.e.,
it doesn't mean that the software is highly creative. Indeed, it is our responsibility to
