[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <file>, <megalon!xanadu!us>
- Subject: Amusing anecdote
- From: John Walker <acad!throop!kelvin>
- Date: Thu, 1 Feb 90 02:09:01 PST
Mark Miller sez...
>> John Walker has an amusing story about experience with users of
>> AutoCad utilizing multiple layers in unexpected ways (which he might
>> relate if he sees this. John?)
Ok...well I haven't responded sooner because I was trying to bash out
the Atlas Project before this Thursday's Let It Be meeting. Well, that
clearly isn't going to happen, and besides with 10 "bad header/sector not
found" messages in the console file, it's an opportune time to bring the
backups up to date and catch up on mail.
The amusing story I think Mark is referring to involves "layers" in the
CAD sense rather than the way you use them (as in terms of layered
protocols or other computer-related terminology). In CAD, "layers"
derive directly from the pin-registered mylar or acetate overlays upon
which most modern drafting is done. With registration mechanically
assured and a medium sufficiently transparent to allow stacking up to
10 layers with acceptable readability, one can develop drafting systems
that, even though they are manual, permit substantial delegation of
responsibility and collaborative work.
Every CAD system in the world maps these overlays into "layers" (AutoCAD's
term), "levels" (IGES terminology), or something equivalent. Some systems
(such as AutoCAD, at present) consider an object as "belonging" to a layer
with their visibility governed by its being switched on or off, while others
(the IGES model, in particular), consider an object as existing on a set
of layers, the visibility of any of which renders it visible. (Actually,
it's more complicated than that--I'm oversimplifying because it isn't
terribly relevant to what follows. Also, sorry if this seems elementary or
tedious--this kind of stuff is, in the CAD world, equivalent to "back up one
character in the file" in the text processing business but, to those who
haven't spent the last 8 years coming to terms with it, understandably
foreign. If I tend to overexplain, it's because it took me an awfully long
time to osmotically transfer these concepts through my cement cranium.)
Anyhoo...the first release of AutoCAD provided a mind-boggling 256
layers. Far out! Who could possibly ever use all of them? Just try
that with Mylar and ProPins! Well, before long, IC designers started
coming up to us at shows and, while complimenting us on the freedom that
64 bit floating point co-ordinates gave them in expressing geometry that
ranged from submicron junctions to metre-scale cabinets, they immediately
bashed us about the "ridiculous limit" of 128 layers. It turned out that
they were using layers as attributes of objects (something we didn't have
at the time, and remedied only much later), and they wanted _lots_ of
them in a complex chip design.
Well...why not? In AutoCAD 2.0 (Release 5, October 1984) we said, "Layers
now have user-chosen names (up to 31 characters), and there is no limit
to the number of layers in a drawing". (Well, obviously, there was a limit:
67^31 possible names, but that oughta hold 'em.)
So, we shipped it, and sales went through the roof and everything was
hunky-dory until after Thanksgiving when we went to Comdex and our dealer
in Miami came up to me and said,
"When are you going to fix the limit on the number of layers?"
"Where have you been, under a rock? We fixed it! No more 256
layers. You can have as many as you want. Enjoy!"
"Oh, I know about that. I mean the limit of 5100 layers."
"About that, depending on what drivers I have loaded and so
forth. Anyway, as soon as you go much past 5000, you're treading
on thin ice."
Having the engineer's perspective of looking more than angstrom beyond
the stone obvious, I thought about this for a while and asked,
"Uhhhh...why, exactly, do you need more than 5000 layers?"
The answer was fascinating.
It turns out that one of their customers was in the business of preparing
custom demographic maps to support political campaigns. If you walked in
and said "where are the districts I should target with more than 50%
registered Democrats which voted Republican in the last gubernatorial
race, where the average age exceeds 40", they'd crank out a map for you
to direct your money and staff.
Well, it turns out that computing and generating the hatch patterns for those
maps is a terribly time-consuming process. (Welcome to the CAD world--there
seems to be a rule that things that seem terribly mundane such as intersecting
a cross-hatch pattern with an edge boundary turn out to probe the limits
of current university research efforts. "But QuickDraw does that!", they
say at Hackers'. "On a 3D bicubic surface, with a parametrically defined
cubic boundary projected upon it? To 15 decimal places?", says the
CAD veteran." Silence....) Look at your telephone handset; the real
world ain't polygons.
Faced with these painful facts, and possessed of zillions of idle CPU cycles
between requests for specific maps, the solution was obvious: PRECOMPUTE all
the obvious requests in available idle time, then select the appropriate
layer from the bitmap that describes it and produce the plot in no time.
It may say something about the current state of public discourse that
while 5100 layers are inadequate to encompass the Burning Issues Of Our
Time, 65536 do the job quite nicely, thank you. So, we fixed it, and I've
not heard another squawk about this point.
It's kinda' like the comment at the very first Autodesk/Xanadu meeting
(I think it was from Mark Miller, but it was very late and my memory is
much consumed by Atlas these days), "2^64 is infinity". Indeed, there is
a point, at a given moment, that a design choice seems
wildly beyond the bounds of any reasonable application. The lesson of
this anecdote is that it's very difficult for any designer to appreciate
what constitutes a "reasonable application".
* * *
In the last couple of weeks I've been coming to appreciate the scope
of the problems in making a truly international product. (This should concern
you at least as much as it does me, but you have more time to think about
it...I'm already into the tree chipper up to the shoulder.) It kind of sets
you back when you discover that there are two different, incompatible encodings
of Japanese Kanji into 8 bit ASCII streams: one used by Kanji DOS machines
(JISCII), the other used by Kanji Unix workstations (EUC--Extended Unix Code).
Today we are in the crazy situation that AutoCAD BINARY databases are
interchangeable among all machines (because the Sausalito fascists prescribe
the JISCII encoding), but text files used with AutoCAD are not.
You ask a simple question like this,
"Is there, anywhere on this planet and particularly at a
shy place somewhere on Crow Canyon Road, a table that
bidirectionally maps the glyphs used to encode all nake
languages into 16 (or, Hell, I'm easy, 32) bit numbers?
Now something like this should clearly lie at the heart of a multilingual
word processor, or any system that purports to store arbitrary text.
I would very much like to know of any such neutral format, as it could
solve problems we're falling deeper into by the minute and, I suspect, will
afflict Xanadu even more.