 |
 |
terry, glen, fil. the idea of defining a set of variables and then explore all possibilities that these variables offer is consistent with the rationalist (cartesian) theory of problem solving. defining a set of variables creates a theoretical space of possibilities, nothing more. if you are varying variables independent of each other, which gives you maximum freedom, this space will be of orthogonal dimensionality. this space is always confined to the variables you happen to have chosen. any such choice amounts to a restriction on the solutions you could possibly find by this method. having defined this space and thereby delineated all possible variations, to find a solution by automatic means requires an algorithm that selects the best solution from among all those possible. humans are very good at deciding what may work or what would be a solution to a given problem, but they are not so good at processing huge numbers of alternatives. the problem with this theory, therefore is to find an algorithm that replicates this human judgment and can go through huge numbers of possibilities. it is a challenge to write such an algorithm. most efforts of this kind have failed or are only weak approximation of what humans can decide rather easily if presented with small numbers of alternatives. herbert simon's modified rationalist theory acknowledges that the space created by allowing variables to vary freely is far too big to be explored case by case and that, in order to get something from this approach, one would have to lower the criterion and find a solution that is merely satisfactory, not the best, but the first found among a smaller number of alternatives within the space defined by the selected variables. this is where finding of automatic solutions is stuck: (a) by the conception of a cartesian space, (b) by the necessarily non-automatic (human) definition of what is considered variable, (c) by the size of the space created. and (d) by the difficulty if not impossibility to define an algorithm that replicates human judgment of the variations this method creates. to talk about automatig or computational design means overcomings all four problems. good luck klaus -----Original Message----- From: PhD-Design - This list is for discussion of PhD studies and related research in Design [mailto:[log in to unmask]]On Behalf Of Filippo Salustri Sent: Saturday, January 14, 2006 12:33 PM To: [log in to unmask] Subject: Re: Automata and redefinition of design practice (was: Robotic thought) Terry, Glenn, et al: I think I get the automata arguments. But let me try this: I don't see how, in the general case, one can enumerate the variables needed to entirely describe a design problem. To design something right the first time (as opposed to the 'fast failure' approach) would pretty much require that level of knowledge. At it seems to me that sufficient information simply isn't available at the outset. So the 'fast failure' approach is really the only reasonable way to go about it. Cheers. Fil Terence Love wrote: > Hi Glenn, > > > The automata problem also fascinated me. The conclusions I came to was that > it isn't intrinsically a conflict. It doesn't 'automate' design, and, it > points up a problem in the politics of how design has been defined. > Radically, the automata problem suggests a need to redefine design activity > in a way that is independent of the hegemony of traditions of design > practice and the education of practitioners. > > My reasoning on it went something like this (it's in my PhD thesis): > > The solution to the problem is pointed to by one theorem of finite automata > that states (If I remember right it's something like!), > > "If a problem can be expressed in variables in the language of finite > automata then a solution can be found by manipulation of those variables > using that language" > > One way of looking at this, is that the use of automata does not automate > the activity of designing as a whole and human design activity does not > disappear. Simply, the location of design activity and the types of design > skills required to 'do design' change. > > The locus of design problems changes to 'designing the original _problem_ as > a representation in the language of finite automata' (rather than designing > representations of solutions in the languages of sketching, engineering > drawing, etc). > > The skills required of a design practitioner are then the skills to envisage > a solution, which is the representation of the original problem in the > language of finite automata. These design skills are very different skills > from those currently taught to budding designers or possessed by the current > generation of 'traditional' design practitioners. The gap is not so great > when seen from within engineering design fields b3casue there has already > been an historical shift from craft tools to more abstract representational > manipulation in for example understanding shape, movement and product > behaviours, and in optimising solutions. > > This idea that the scope if design activity changes is also a useful > perspective for solving several other problems in the area of defining 'what > is design'. In particular, it mutually locates the activities of design > practice and design research. The focus of design research is to improve and > 'automate' current design practices and skills. This offers the possibility > and opportunity for designers to drop old design practices and to take up > new, more effective, more advanced, design practices. > > Locating the automata issue in a longer-term picture, design practices have > changed a lot over time. The changes over single generations, however, have > been relatively small and accommodated by professional development. This has > lead in each generation to an illusion and a desire among practitioners and > educators to define 'design' as whatever design practitioners do at this > moment. Taking the long view and including the automata issue suggests it is > better to define 'design' independently of what we as designers think is > design from looking at our practice. > > Thoughts? > > Cheers, > Terry > > === > (c) Dr. Terence Love > Dept of Design > Curtin University > Tel/Fax: +61 (0)8 9305 7629 (Home office) > Mobile: 0434975 848 > [log in to unmask] > === -- Filippo A. Salustri, Ph.D., P.Eng. Department of Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON, M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: [log in to unmask] http://deed.ryerson.ca/~fil/