Negroponte, N. (1972). HUNCH – An Experiment in Sketch
`Recognition. In Environmental Design: Research and Practice,
`Proceedings of the EDRA 3/ar 8 Conference, University of
`California at Los Angeles.
`
`22: MAN-MACHINE SYSTEMS
`
`Valve Exhibit 1053
`Valve v. Immersion
`
`

`

`HUNCH
`AN EXPERIMENT IN SKETCH RECOGNITION
`
`The Architecture Machine Group
`Department of Architecture
`Massachusetts Institute of Technology
`
`Nicholas Negroponte
`Leon B. Grois.ser
`James Taggart
`
`This paper highlights the operations and
`problems of a set of computer programs
`called HUNCH. The specific goal of HU(cid:173)
`NCH is to be able to recognize and make
`inferences about a user's sloppy, in(cid:173)
`complete and equivocal drawings without
`that user having to be more explicit or
`categ,:irical than he would be with an on(cid:173)
`looking human colleague. Steps toward
`this goal are being made within a par(cid:173)
`ticular context -- architecture -- that
`furnishes a "knowledge base" or "assum(cid:173)
`ption base" from which programs can pro(cid:173)
`cure (rather than develop) those heuris(cid:173)
`tics necessary to handle two dimensional
`and three dimensional ambiguities.
`
`While HUNCH is indeed an exercize in
`"computer graphics", we believe that
`a great many of its operating princi-
`ples are characteristic of all kinds of
`future systems that will be expected to
`cope with vague information and to deal
`with nebulous ideas. For example, 1) we
`not only expect the program to make er(cid:173)
`rors, but also to benefit from errors
`(ie: to improve its recognition ability
`and context handling ability); 2) we ex(cid:173)
`pect the program to support an evergrow(cid:173)
`ing acquaintence with the user (ie: a
`knowledge of his ideosyncracies, habits,
`whims); 3) we anticipate that the program
`will have many channels of access to the
`real world (to the extent of recognizing
`gestures and smiles); 4) we insist that
`the program puruse a multiplicity of can(cid:173)
`didate "solutions", sorted and selected
`by "criticizer" programs.
`
`Since 1967, the authorsl have argued that
`computer-aided design is an issue of
`artificial intelligence, that machines
`have to understand the meaning of deci(cid:173)
`sions in order to be partners in making
`them. We have advocated the exploration
`of artificial intelligence and have con(cid:173)
`demned computerized solution generation
`which does not consider it. One severe
`consequence of this position is that there
`remains very little to work on both bec(cid:173)
`ause of the state of the art of computer
`sciences in general, and because intell(cid:173)
`igence per se cannot be tackled in parts.
`
`22-1-1
`
`Sketch recognition has provided us an
`interim domain. While it is certainly
`difficult to shift between wanting to
`deal with "partially formed ideas" and
`wanting a program to find corners (which
`is what most
`this paper is about),
`it is a topic that has inherent uncer(cid:173)
`tainties and ambiguities at all levels.
`It is representative of a class of pro(cid:173)
`blems that can be tackled with modesty,
`but in the ultimate case, require an
`intelligence.
`
`Acknowledgements
`Precursory work commenced in 1966 in
`a project called URBANS jointly spons(cid:173)
`ored by IBM and MIT. Actual work,how(cid:173)
`ever, started only in early 1970 with
`the Bachelor of Architecture thesis of
`Mr. James Taggart. This work was con(cid:173)
`ducted within the Architecture Machine
`Group at MIT and was supported by the
`Ford Foundation. The more concentra(cid:173)
`ted effort began in the summer of 1970
`with a grant from the Graham Foundation
`for Advanced Study in the Fine Arts and
`major support from MIT's Project MAC
`(Advanced Research Projects Administra(cid:173)
`tion contract N0014-70-A-001).
`
`At present HUNCH is being developed as
`an integrated package to act as a front
`end for any system for "Computer Aids
`to Participatory Architecture",2 spon(cid:173)
`sored by the National Science Founda(cid:173)
`tion.
`
`Along with these many generous sponsors,
`the authors would like to thank Dr. Gor(cid:173)
`don Pask who, in spring 1971, provided
`radical inputs, which guided the project
`into new directions.
`
`Introduction
`We view the problem of sketch recognition
`as the step by step resolution of the
`mismatch between the user's intentions
`(of which he himself may not be aware)
`and his graphical articulations.
`In a de(cid:173)
`sign context, the convergence to a match
`between the meaning and the graphical state(cid:173)
`ment of that meaning is complicated
`
`

`

`by continually changing intentions
`tnat result from the user's viewing his
`own graphic statements.
`In some sense,
`the sketch acts as a form of memory for
`the ·user while he loops, so to speak,
`into the real (physical) world to gain
`a better understanding of his problem.
`Consequently, the nature of his drawing
`(ie:the wobbliness of the lines, the
`collections of overtracings, the dark(cid:173)
`ness of the lines) has important mean(cid:173)
`ings for the most part overlooked in
`computer graphics. We have already
`proposed that: "A straight line 'sketch'
`on a cathode ray tube could trigger an
`aura of completeness injurious to the
`designer as well as antagonistic to the
`design."3
`
`HUNCH tries to take into account some
`usually overlooked (or not taken ser(cid:173)
`iously) graphic subtlties such as: sp(cid:173)
`eed of drawing, pressure upon the pen,
`and crookedness of lines. At present,
`this is for the purpose of making those
`transformations necessary to pass from
`a drawing that is meaningful to the
`user (figure 1) to an interpretation
`(figure 2) which is both managable by
`the machine and appropriate for first
`approximations, guesses and extrapola(cid:173)
`tions. Later, we expect to employ gr(cid:173)
`aphical innuendoes for the purpose of
`having the machine recognize attributes
`which have to do with the user's atti(cid:173)
`tude toward his own project, his confi(cid:173)
`dence in a solution and the like.
`
`Figure 1.
`
`22-1-2
`
`Figure 2.
`We believe that HUNCH will have general
`applicability as a front end to computer
`systems that require the graphical input
`of ideas which are not well formed.
`It
`should have particular importance for
`architectural applications inasmuch as
`present day computer applications are
`always hampered by the means of imput.
`The architect interested in computer(cid:173)
`aided design techniques must either 1)
`do a design away from the machine, and
`at some level of completion initiate the
`usually clumsy procedures necessary to
`make it readable by the machine; or
`2) must stymie his own design behavior
`and subject himself to drawing techni(cid:173)
`ques which are inappropriate for "crea(cid:173)
`tive" thought. Neither is suitable.
`
`Within the next two years, HUNCH is ex(cid:173)
`pected to handle true sketches (figure
`3), drawings marked by inaccuracies,
`missing information and even coffee
`stains. We propose to do this by: 1)
`providing the user with a broad range of
`amenable hardware interfaces with the
`machine; 2) developing programs that get
`to know the particular user better and
`better; 3) creating an inference-making
`system that capitalizes upon a history
`of encounters with many users as well
`as with the particular user.
`
`The following pages should be viewed as
`an interim report.
`
`Configuration
`We start with a description of the conf(cid:173)
`iguration of our hardware because we be(cid:173)
`lieve that each device has unique oper(cid:173)
`ational characteristics built into it.
`
`

`

`disk, the MULTICS time-sharing system,
`an IMLAC display unit and a three dim(cid:173)
`ensional positioning device called SEEK.
`The reader should note that this config(cid:173)
`uration is highly redund~~t and, while
`it ermlov:; a nlurali tv of devices, it is
`i'larkec! by a v~ry low cost, approximate-
`$40,000 purchase price.
`
`Sylvania Tablet
`The Svlvania Tablet, with its stylus,
`is th~ primary input medium of the sys
`tern (figure 5). The tablet operates in
`a manner that is crucial to HUNCH.
`It
`issues to the minicomputer a constant
`number of X and Y (and even Z) coordin(cid:173)
`ates per second (in our case 200 hun(cid:173)
`dred per second). This constant rate
`acts as a form of a clock.
`
`: _::ure 3
`depend very heavily upon these inherent
`atures for the purpose of recognition
`as well as of intensive, congenial inter(cid:173)
`-cion. The hardware described is a sub-
`t of what we call "The Architecture Ma(cid:173)
`___ 2.ne" (figure 4).
`
`:ie diagram illustrates the subset of The
`• ·-chi tecture Machine used for HUNCH as well
`as the interconnections among the seven
`elements: a Sylvania Tablet, an
`Remote Display Station (ARDS), an
`model 5 minicomputer, a DisEstor
`
`Disk
`
`SEEK
`
`Figure 5
`
`Figure 4
`
`22-1-3
`
`

`

`It means that lines drawn slowly will
`have digitized points closely spaced,
`whereas lines drawn rapidly will have
`them more dispersed. As a result, we
`have a built~in record of the speed at
`which each part of a drawing is created.
`We subsequently employ this parameter
`as a major criterion for determining
`the user's graphical intentions: "did
`he mean this to be ... a straight line,
`a square, a corner, etc?".
`In effect,
`we are correlating the user's speed of
`drawing with his purposefulness.
`
`This provides an ability for drawing
`without the computations necessary for
`pen tracking \which is necessary for
`light pens). Second, it has a li~ited
`three uimensional .ca:,,abi li ty because it
`can record three levels of Z (~here the
`range of each level is variable with a
`screw driver). At this time we make
`only limited use of this last feature
`(for example, we determine the probable
`beginnings and ends of pictures and op(cid:173)
`portune moments to write information on
`the disk).
`
`We also associate intentions with the
`user's pressure upon the stylus. This
`feature has been added to the Sylvania
`Tablet by Wade Shaw as rart of his El(cid:173)
`ectrical Engineering Thesis, Textural
`Input and Definition for Graphic Dis(cid:173)
`play. A pressure sensing gage placed
`within the shaft of the pen measures
`how hard the user is pressing down.
`When connected with the focus control
`of the display, this feature simulates
`pushing harder on a pencil to get a
`blacker line. We believe that this is
`particularly important to sketching
`because it is quite common to over(cid:173)
`trace lines, and thus without erasing,
`to make the most up-to-date lines em(cid:173)
`phatically dark.
`
`It is important to note that both speed
`and pressure provide inputs .which would
`not really be available to an onlooking
`human, especially if he were looking
`at the sketch after the fact.
`Some ar(cid:173)
`gue that it is more appropriate or mean(cid:173)
`ingful to artificial intelligence to use
`only those cues available to humans.
`We don't.
`
`The tablet has two further important fe(cid:173)
`atures: First, it has a transparent
`surface which permits it to be used ver(cid:173)
`tically in front of the display with the
`minor inconvenience of a half inch
`paralax (figure 6).
`
`Figure 6
`
`22-1-4
`
`Advanced Remote Display Station
`ARDS was the first storage tube system
`developed (figure 7). The advantage of
`a storage tube is that it maintains the
`image on the face of the scope without
`"refreshing" it and thus without the as(cid:173)
`sociated computations necessary to con(cid:173)
`tinually redraw the image.
`(Hence its
`convenience to time-sharing.) Its draw(cid:173)
`back is its resulting inability to loc(cid:173)
`ally erase, that is to remove a part of
`the picture without erasing the whole
`and redrawing it.
`
`Figure 7
`This does not pose a problem in our con(cid:173)
`text; consider whether you can locally
`erase with a felt tip pen, or how often
`you erase pencil lines. Furthermore, a
`storage tube allows an unlimited number
`of vectors to be displayed (in contrast
`to the more expensive "dynamic displays"
`that allow only a few seconds of sketch(cid:173)
`ing before flicker sets in because so
`many points must be continually drawn).
`
`Storage
`thru".
`itiated
`fects a
`
`tubes have the ability to Tiwrite
`This mode of operation can be in(cid:173)
`under computer control.
`It af(cid:173)
`low beam voltage which produces
`
`

`

`":ectors that are not stored. Therefore,
`-~ha minicomputer at hand you can par(cid:173)
`tially circumvent the local erase prob(cid:173)
`~e~ and maintain a certain number of
`",-ectors dynamically -- we employ this
`~or editing and moving about elements of
`~:-.e picture. (It should be noted that
`~his feature varies dramatically with
`~he brand of storage display station.
`~he ARDS is the least appropriate in
`~hat it steps vectors, rather than sweep(cid:173)
`~ng them, and hence cannot display lines
`as fast as other brands.) A drawback of
`cf write thru mode is that storage tubes
`are inherently dim, write thru is even
`:iimmer, and consequently when using it
`the user must operate in a partially
`darkened room.
`
`Interdata
`~he Interdata Model 5 computer is typical
`of any good minicomputer; it is very
`=ast and provides very cheap computing
`power. The processor and memory is
`sim(cid:173)
`ilar to that employed for HUNCH and can
`be purchased for $10,000. Since the In(cid:173)
`terdata
`is faster than both the Tablet
`and the ARDS, it can pe_rform background
`operations, in effect, dealing with the
`sketch in parallel with the user creating
`it.
`Its drawback (not inherent in the
`computer) is its comparatively small mem(cid:173)
`ory. Given 200 points per second (4800
`bits per second), a 16K memory is filled
`in only 16 seconds of sketching; hence
`an auxiliary memory is necessary.
`
`DisE'.stor
`The DisEstor is a removable disk pack
`system, with single surface disks (512K
`bytes per side) and fixed heads, one per
`track. The fixed heads eliminate "seek
`time" making the disk extremely fast.
`This feature permits the disk to accept
`the initial sketch as if the tablet were
`c9nnected directly to core memory. With
`the disk, the user can draw continuously
`for over an hour. However, since noth(cid:173)
`ing is stored when the pen is lifted off
`the tablet, this means about four or five
`hours of natural sketching.
`
`MULTICS
`MULTICS is a time-sharing system develop(cid:173)
`ed by MIT's Project MAC on a GE645 comput(cid:173)
`er. It has powerful file-sharing abilit(cid:173)
`ies and caters heavily to systems pro(cid:173)
`gramming.
`
`It may be argued that time-sharing will
`not be cost effective when, in ten or
`twenty years, minicomputers sell for $200.
`Its future role may well be that of com(cid:173)
`munications and of sharing large data
`bases, and then only by machines
`
`22-1-5
`
`(ie minicomputers)not people. Neverthe(cid:173)
`less, presently it is particularly use(cid:173)
`ful because it makes available high level
`languages and their software support:
`these usually are not available on mini(cid:173)
`computers.
`It is for this reason that
`we use MULTICS. The list processing
`and recursive features of the MULTICS
`version of PL/1 are necessary for map(cid:173)
`ping a perspective sketch from two dim(cid:173)
`ensions.
`
`We also employ the time-sharing system as
`a communications medium between the ARDS
`Interdata display and the IMLAC.
`
`IMLAC
`An IMLAC is a display unit which has a
`self-contained processor memory and dis(cid:173)
`play processor that can support up to
`inches of vectors (depending upon
`available memory and other options).
`It has recently been added to the HUNCH
`configuration in order to experiment
`with those dynamic features usually av(cid:173)
`ailable only on very expensive display
`uni ts. At present we 'are programming it
`to present the results of the mapping
`into three dimensions performed on MUL(cid:173)
`TICS. This includes rotations, trans(cid:173)
`lations, etc., and a limited ability to
`change proportions by moving planes while
`keeping the topology constant.
`
`SEEK
`SEEK is a homemade, three dimensional
`positioning device that can build phy(cid:173)
`sical models using predescribed blocks
`of wood (figure 8).
`
`Figure 8.
`
`

`

`It receives its instructions from the
`Interdata which in turn has received
`from MULTICS the X,Y, and Z coordinates
`of -the centroids of the blocks necess(cid:173)
`ary to best approximate the sketched
`image.
`In some sense it is a punchline
`to the demonstration program we employ
`to demonstrate the present workings of
`HUNCH; it is not an integral part of
`sketch recognition. However, consider
`the spectacle: you sketch a perspective
`of an assemblage of housing uni ts; be(cid:173)
`hind you a machine is building them.
`You change your sketch; the physical
`model is changed.
`
`Ooerations
`In this section we take some liberty in
`mingling the present and future tense
`with respect to what is and what is
`about to be operational. A great deal
`of IIUNCH is presently working and de(cid:173)
`monstrable at the lowest levels of re(cid:173)
`cognition; very little is developed at
`the upper end. The operations are
`carried out in a somewhat sequential
`manner and are presented following that
`order. However, it is important to re(cid:173)
`cognize that the initial data and the
`subsequent tr;1nsformations are saved
`on disk. This permits interactive re(cid:173)
`examination of the data in order to
`build evidence that "he meant this"or
`"he meant that". This contradicts the
`sequential nature of the following pre(cid:173)
`sentation and the present demonstration
`program. Being able to look back, to
`collect more evidence, and to alter pre(cid:173)
`vious (nov1 proved erroneous) decisions
`are all crucial to sketch recognition.
`
`Initiation
`HUNCH is being developed to be trained
`(we use the word advisedly) by a par(cid:173)
`ticular user. This training will occur
`both implicitly and explicitly through
`reinforcing an evergrowing model of the
`user and his method of work (particu(cid:173)
`larly his method of drawing).
`In or-
`der to start the program, some initial(cid:173)
`ization is necessary when the user and
`HUNCH first meet. No two people draw
`in the same manner and HUNCH would fl(cid:173)
`ounder without some means of correlating
`the pressure and speed of a given user
`with his graphical intent ions. In the
`early days we saw this dramatically
`demonstrated when the initiation pro(cid:173)
`cedures did not exist and the program
`was tuned to the hand of its chief pro(cid:173)
`grammer, Mr. James Taggart.
`If another
`member of the Architecture Machine Gr(cid:173)
`oup would try to demonstrate HUNCH, the
`result would be embarassing.
`
`22-1-6
`
`Therefore, a simple scenario precedes
`the first sitting.
`"Draw me a square,"
`says !!UNCH. The user draws a square and
`HUNCH proceeds to vary its own parameters
`of speed and pressure until it manages
`to compose a square out of the stream
`(let's say 600 hundred or so) of x's and
`y's. Then it asks in turn for a fast
`square and slow square. Eventually en(cid:173)
`ough parameters will have been set to en(cid:173)
`able HUNCH to proceed with the different
`levels of recognition and data compres(cid:173)
`sion.
`
`Diagrams
`After initialization, the first operation
`which must be performed on the stream
`of data (ie:sketch) is the recognition
`necessary to separate diagrammatic ele(cid:173)
`ments from projections (either ortho(cid:173)
`graphic or perspective).
`In projections,
`the vectors delineating a figure repres(cid:173)
`ent the intersection of planes or delim(cid:173)
`iting contours of physical bodies; in
`diagrams, they do not. Letters of the
`alphabet, arrows and symbolic notations
`are examples of diagrammatic elements.
`Plans,sections and perspectives are ty(cid:173)
`pical projections. At present we han-
`dle only one kind of diagram -- the squ(cid:173)
`iggle. We anticipate handling many oth(cid:173)
`ers including a character recognition
`ability.
`
`"Squiggles" must be distinguished from in(cid:173)
`tentional wavy lines. This can be done
`with uncanny accuracy simply by ~,alys(cid:173)
`ing the speed and the accelerations at
`the corners. Once recognized as an auth(cid:173)
`entic squiggle, we consider it to be onlv
`one of two things: 1)
`shading; 2) a rub(cid:173)
`bing out gesture.
`
`It is important to recognize shading, not
`only to avoid processing it "projective(cid:173)
`ly~ but also to have it as future evi(cid:173)
`dence for guesses about solidarity and
`orientation (figures 9 and 10). The dir(cid:173)
`ection of the sun, the parallelism of its
`rays, and the interpositioning necessary
`for shadows are simple concepts, easily
`included in programs (though we would
`prefer that the programs could develop
`the concepts themselves). Such an anal(cid:173)
`ysis affords excellent evidences for lo(cid:173)
`cating the ground plane or perceiving
`depth.
`
`The rubbing out gesture is particularly
`important for editing. This technique
`of rubbing out using squiggles, is faun=
`as far back as 1969 in the Grail Langua(cid:173)
`ge 4 developed by the Rand Corporation.
`It is distinguished from shading by con-
`
`

`

`~~gure 9.
`
`Figure 11.
`
`Figure 10.
`sidering when (in the sequence of cons(cid:173)
`tructing or editing an image) it is drawn,
`and by the location of its centroid (ie:
`is it on top of a line or within a sur(cid:173)
`face?)
`
`Data Compression
`Data compression is a major element in
`the presently operating version of HUN(cid:173)
`CH. Figure 11 represents 4128 core loca(cid:173)
`tions as raw data; figure 12, the same
`drawing, represents 128 locations after
`data compression. This operation is im(cid:173)
`portant for subsequent inference making
`and for transmitting the image to the
`time-sharing system at 1200 bits per
`
`Figure 12.
`second. The adjacent image would take
`half a minute to transmit unstraighten(cid:173)
`ed, and less than a second after data
`compression.
`
`Line straightening is not a trival oper(cid:173)
`ation. The problem is that decisions on
`the straightness of a line cannot be
`made by looking only at a given point and
`its immediate neighbors (let's say within
`an eighth inch radius). Local nicks
`and bumps caused by a shaking of the wrist,
`a bump on the paper, or simple noise in
`the tablet could indicate corners that
`were indeed unintended.
`Instead, it is
`necessary to connect, for example, every
`
`22-1-7
`
`

`

`tenth point and look for violent changes
`in angle (arctangent) among the result(cid:173)
`ing line segments.
`
`This procedure is greatly assisted by
`considering the speed of drawing; a
`hastily drawn square with rounded cor(cid:173)
`ners (figure 13) will be assumed to be
`a closed straight line figure, whereas
`one drawn slowly, of identical shape,
`will be interpreted as a figure meant,
`to be rounded.
`
`In fact, it is interesting to note that
`a stream of incoming graphical data can
`be examined solely for peaks and troughs
`in speed and that if the points of slow(cid:173)
`est velocity were interconnected, the
`resulting image has about 80% fit with
`the intended image!
`
`to draw an actual curve (versus a wobbly
`straight line) the straightened interpre(cid:173)
`tation will be dramatically different
`when different speed factors are employed.
`If a user intended to draw an oval, the
`straightened version is almost unpredic(cid:173)
`table: we can be assured, however, that
`each straightened version will be marked(cid:173)
`ly different from the others. Figure 14
`shows a curve straightened employing
`three different weightings for the speed
`parameter. Figure 15 shows a curve that
`has been recognized and subsequently left
`unstraightened.
`In effect, what we are
`capitalizing upon is the results furn(cid:173)
`ished by a procedure given a task it was
`not meant to handle.
`
`Figure 13.
`Curve Recognition
`We have ignored curves for a long time.
`They are not indiginous to architecture;
`we don't believe that sophisticated com(cid:173)
`puter graphics techniques will lead to
`a proliferation of Gaudiesque architec(cid:173)
`ture (in fact we might want to discourage
`it). However, in any demonstration we
`have ever conducted, the visitor/user
`inevitably draws cruves. Thus we are
`willing to recognize them, but in no
`sense to try to "fit"them.
`
`Fortuitously, as a <lirect result of the
`above data compression procedures,
`curve recognition is relatively simple.
`The method we employ is to slightly vary
`those parameters that control the impor(cid:173)
`tance of speed.
`If the user intended
`
`22-1-8
`
`Figure 14.
`
`Figure 15.
`
`

`

`Latching
`Our first approach was that the latching
`of lines should be purely a function of
`velocity. Two linc,s that almost meet,
`but that were drawn slowly (~~ere slow
`and fast are in the vernacular of the
`particular user) were not to be connec(cid:173)
`ted.
`
`However, this approach turned out to be
`wrong when users composed s~all, in(cid:173)
`tricate drawings. The mullions of a
`window, for example, would inevitably
`latch onto the corner of the sill, of(cid:173)
`fering absurd interpretations of the
`sketch. The error resulted from the
`philospohical oversight of not looking
`for all the candidates (for latching,
`in this case) and choosing the most
`appropriate (or none at all). There
`are obvious and important determinants
`for latching beyond simply speed: is
`it a connected body? is the shape clo(cid:173)
`sing upon itself? what does this do to
`horizontality and verticality? and so
`on. The result is a much more timid
`"latcher", but a much more correct one.
`(More farreaching consequences are dis(cid:173)
`cussed in Section IV.)
`Intersections
`After a sequence of lines have been st(cid:173)
`raightened (ie:compressed), the lines
`are represented only by their end points
`(See Appendix). HUNCH then locates in(cid:173)
`tersections, and breaks the intersec(cid:173)
`ting lines into line segments. Thus a
`five pointed star results in
`fifteen
`line segments with ten end points.
`
`22-1-9
`
`The problem that we suspect may arise
`will be when we want to recognize a star
`or "starness" which is certainly intrin(cid:173)
`sically more than a five sided "thing".
`
`Nevertheless, in some contexts, inter(cid:173)
`sections are crucial, especially when
`a line segment meets another line at
`other than an end point. This occurr(cid:173)
`ence results in a so-called T joint.
`This is also a problem because an al(cid:173)
`most meeting Tor an overshot Tis made
`to end exactly at the line (as a func(cid:173)
`tion of velocity and pressure).
`It is
`interesting to note, however, that non(cid:173)
`perpendicular T's are often unlatched
`by later "mapping" operations since they
`are good evidence that one body or plane
`lies behind the other.
`
`0
`
`Inference Making
`In the jargon of SketchpaJ5 and Sketch(cid:173)
`pad III 6 making inferences is "constr(cid:173)
`aint resolution"; in our case, it is
`handled implicitly. We consider, for
`Lhe time being, only four types of in(cid:173)
`ferences that the machine makes without
`the user's explicit request: !)horizon(cid:173)
`tal/vertical, 2) parallel/perpendicular,
`3) continuities, 4)overtracing.
`
`When almost horizontal and almost verti(cid:173)
`cal lines are made plumb, the picture
`takes on a drammatically different char(cid:173)
`acter. This is particularly true inas(cid:173)
`much as the preceeding routines, straigh(cid:173)
`tening and latching, frequently operate
`at the expense of intended horizontality
`and verticality as dramatized in figures
`16, 17 and 18. The operation is espec(cid:173)
`ially important in the context of archi(cid:173)
`tecture, where verticality and horizontal(cid:173)
`ity have structural meaning.
`In areas
`of industrial or city design, this op(cid:173)
`eration would have less propriety.
`
`Par·allelism and perpendicularity, on the
`other hand, are more context dependent.
`Inferring that two almost parallel or
`perpendicular lines were meant to be
`parallel or perpendicular is more dif(cid:173)
`ficult. This is because the positional
`relationship between two lines must be
`cons{dered.
`In the case of parallelism,
`
`

`

`I'igure 16
`
`.
`Figure 17
`for example, the paradox exists that
`distant lines that happen to be near-
`ly parallel are less likely to be in(cid:173)
`tended to be parallel (especially if
`they are short and many other lines in(cid:173)
`tervene); however, it is more diffi(cid:173)
`cult to draw lines parallel when they
`are far apart, no matter how careful-
`ly it is done, (again, especially
`when they are short). The problem is
`only nanageable by the fact that over(cid:173)
`enthusiastic orthogonalizing and par(cid:173)
`allelizing does not produce drastic
`errors (as does a nontimid latcher)
`
`Continuities are once again rather
`architectural in nature. They are
`heavily reinforced by the sequence
`of the-drawing and have very little
`
`22-1-10
`
`speed.
`
`Inferring continuities is a good exam(cid:173)
`ple of where it is necessary to go back
`to the original raw data because inten(cid:173)
`ded continuities arr cftcn broken by
`straightening, hocizontalizing and the
`like. The comoutation problem is messy
`as it demands extending each line seg(cid:173)
`ment within the bounds of the picture
`and then making good guesses at inten(cid:173)
`tions of co-lineality. This operation
`can be greatly reinforced by the know(cid:173)
`ing of the user and his methods of work
`(architectural, in this case, rather
`
`than simply graphical). ---
`
`Overtracing, on the other hand, is
`straightfoward because it is very
`much a function of velocity, sequen(cid:173)
`ce and pressure. Two lines drawn
`side by side, one after the other, very
`slowly, are probably intended to be
`two closely spaced parallel lines. Two
`lines which are drawn rapidly in succ(cid:173)
`ession and are almost coincident are
`probably meant to be a single line, eic(cid:173)
`phasized or corrected. Lines drawn in
`succession, but one over the other witt
`greater force can be viewed as a form
`of implicit editing (a good guess would
`be that the overtracing implied eras(cid:173)
`ure).
`
`

`

`Editing
`T:--,ere are two forms of editing: altering
`your drawing and altering the machine's
`interpretation of your drawing.
`Some
`people might argue that the latter res(cid:173)
`ults only from the ineptitude of the mach(cid:173)
`ine and a good "sketch recognizer" would
`not need that sort of editing.
`
`On the contrary, we believe that theed(cid:173)
`itor, over the next two years, will e(cid:173)
`volve into one of the most important
`parts of the system, not to facilitate
`correcting a stupid machine, but to in(cid:173)
`clude some features of learning. Theed(cid:173)
`itor should ask better
`and better qu(cid:173)
`estions. It should analyse erroneous in(cid:173)
`terpretations as a means of altering its
`model of the user and of reinforcing its
`propensity to be a surrogate hand/pencil.
`
`At present, the editor is a modest fac(cid:173)
`ility for graphical changes of either
`kind.
`It permits adding and subtrac-
`ting lines and corners, moving segments
`of the picture (figure 19, time lapse
`photograph) and explicitly evoking any
`of the routines included in inference
`making.
`It exercizes write thru mode,
`which, in the case of ARDS, can support
`four or five vectors of modest length.
`(This limitation is not true for other
`brands of storage tubes.)
`
`Figure 19.
`Communications
`All the operations discussed above take
`place in the Interdata, using only lo-
`cal computing power; they are programmed
`in Interdata machine language, a 360-like
`language.
`Most of the remaining op-
`erations require higher level languages
`and are performed on a remote time-sh(cid:173)
`aring system, MULTICS.
`
`22-1-11
`
`Communications operations are util(cid:173)
`ities that make the Interdata look
`like a 2741 typewriter terminal (135
`bits per second) or like a stand alone
`ARDS
`(1200 bits per second), depending
`upon which port is available (it pre(cid:173)
`fers the latter).
`In one case, the
`compressed data is transmitted in EBC(cid:173)
`IC, in the other USACII: the user and
`the other operations are unaware of
`which is being used. At present, the
`only requirement for the user is that
`he dial up MULTICS by phone (shortly
`this will be replaced with an automat(cid:173)
`ic dial up system that will work under
`computer control).
`
`Projection Recognizer
`At MULTICS, the operations no longer
`take place in "real time", but are at
`the mercy of the time of day, the num(cid:173)
`ber of other users and the load on the
`system. All programming at MULTICS is
`done in a MULTICS version of PL/1.
`
`The projection recognizer is fundamen(cid:173)
`tally a branching procedure that seeks
`to recognize what kind of drawing it
`is receiving. (Note that this entire
`problem could be easily circumvented
`by simply requiring the minor incon(cid:173)
`venience of a label, but in keepin